On Wed, Mar 12, 2014 at 11:45:03AM +0800, Thomas Preud'homme wrote:
> > From: Jakub Jelinek [mailto:ja...@redhat.com]
> >
> > In theory you could have __CHAR_BIT__ different from 8 and what you care
> > about is that uint32_t has exactly 32 bits, so the check would need to be
> > if (sizeof (uin
On Wed, Mar 12, 2014 at 11:43:00AM +0800, Joey Ye wrote:
> 4.8 also has this bug. OK to backport?
Yes.
Jakub
On Tue, Mar 11, 2014 at 04:16:13PM -0700, Cong Hou wrote:
> This patch is fixing PR60505 in which the vectorizer may produce
> unnecessary epilogues.
>
> Bootstrapped and tested on a x86_64 machine.
>
> OK for trunk?
That looks wrong. Consider the case where the loop isn't versioned,
if you dis
> Thanks, and to Bernd for the review. I went ahead and applied it to trunk.
Thanks. We need something for the 4.8 branch as well, probably the builtins.c
hunk and the reversion of the cse.c/cselib.c/dse.c changes to the 4.7 state.
--
Eric Botcazou
On Tue, 11 Mar 2014, Jakub Jelinek wrote:
> Hi!
>
> As described in the PR, the r208165 change regressed following test.
> The problem is that VRP inserts a useless ASSERT_EXPR right before
> __builtin_unreachable () (obviously, the uses of the ASSERT_EXPR
> lhs aren't and can't be used by anythi
On Tue, 11 Mar 2014, Jakub Jelinek wrote:
> Hi!
>
> This patch fixes the ssa-ifcombine-10.c regression.
> The thing is that the uselessly added ASSERT_EXPR makes vrp1 change
> the cfg slightly like this:
>:
>_4 = x_3(D) & 1;
>if (_4 == 0)
> goto ;
>else
> goto ;
>
>
On Tue, 11 Mar 2014, Jakub Jelinek wrote:
> Hi!
>
> build_low_bits_mask doesn't work for vector types (even TYPE_PRECISION
> alone on it is meaningless), but what we actually want is a constant with
> all bits set.
>
> Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?
Ok.
Th
On Wed, 12 Mar 2014, Jakub Jelinek wrote:
> On Tue, Mar 11, 2014 at 04:16:13PM -0700, Cong Hou wrote:
> > This patch is fixing PR60505 in which the vectorizer may produce
> > unnecessary epilogues.
> >
> > Bootstrapped and tested on a x86_64 machine.
> >
> > OK for trunk?
>
> That looks wrong.
Hi Kugan
On 3 March 2014 21:56, Kugan wrote:
> gcc/
>
> 2014-03-03 Kugan Vivekanandarajah
>
> PR target/60034
> * aarch64/aarch64.c (aarch64_classify_address): Fix alignment for
> section anchor.
>
>
>
> gcc/testsuite/
>
> 2014-03-03 Kugan Vivekanandarajah
>
>
On 12/03/14 20:07, Marcus Shawcroft wrote:
> Hi Kugan
>
>
> On 3 March 2014 21:56, Kugan wrote:
>
>> gcc/
>>
>> 2014-03-03 Kugan Vivekanandarajah
>>
>> PR target/60034
>> * aarch64/aarch64.c (aarch64_classify_address): Fix alignment for
>> section anchor.
>>
>>
>>
>
On 11 March 2014 11:48, Kyrill Tkachov wrote:
>> - if test x$target_cpu_cname = x
>> + if test x"$target_cpu_cname" != x
>>
>> I think the addition of quoting here is orthogonal to the issue you
>> are fixing. There are several other references to target_cpu_cname in
>> config.gcc none of which a
On Wed, Mar 12, 2014 at 09:51:46AM +0100, Richard Biener wrote:
> Ok in principle, but is there a possibility to factor this a bit?
> It looks like a lot of cut&paste (without looking too close for subtle
> differences).
Like this?
2014-03-12 Jakub Jelinek
* tree-ssa-ifcombine.c (forw
>> + else if (SYMBOL_REF_HAS_BLOCK_INFO_P (sym)
>>
>> This test makes sense.
>>
>> + && SYMBOL_REF_ANCHOR_P (sym)
>>
>> Do we need this test or is the patch being conservative? I would
>> have thought that it is sufficient to drop this test and just take the
>> block alignment...
>>
>
Richard Biener writes:
> On Mon, 10 Mar 2014, Rainer Orth wrote:
>
>> Richard Biener writes:
>>
>> > Ouch. But as lto-plugin is a host module it should link against
>> > the host libgcc, no? During stage1, that is. So the question is
>> > why does it use the gcc/ compiler?
>> >
>> > For
Hello!
Attached patch cleans include/dwarf2-signal.h to avoid
./include/java-signal.h:26:19: warning: declaration 'class
java::lang::Throwable' does not declare anything
./include/java-signal.h:24:42: warning: unused parameter '_sip'
[-Wunused-parameter]
./include/java-signal.h:26:19: warning: de
Richard Biener writes:
> On Mon, 10 Mar 2014, Rainer Orth wrote:
>
>> Rainer Orth writes:
>>
>> > It does use the host compiler for me, too.
>> >
>> >> but maybe _that_ is the issue for you? (see also how it uses
>> >> -static-libgcc, for me it doesn't even depend on libgcc_s)
>> >
>> > But as
On March 12, 2014 10:52:23 AM CET, Jakub Jelinek wrote:
>On Wed, Mar 12, 2014 at 09:51:46AM +0100, Richard Biener wrote:
>> Ok in principle, but is there a possibility to factor this a bit?
>> It looks like a lot of cut&paste (without looking too close for
>subtle
>> differences).
>
>Like this?
Y
Hi,
in this regression (Jakub figured out that it started with r72165) we
ICE during error recovery:
60254_1.C: In function ‘bool foo(T)’:
60254_1.C:4:3: error: non-constant condition for static assertion
static_assert(foo(i), "Error");
^
60254_1.C:4:3: internal compiler error: unexpected expr
This fixes a problem because cc_plus and cc_minus are in the wrong places in
calls of avr_out_plus_1. This is important when avr_out_plus is called from
notice_update_cc. This means that cc_status might be determined incorrectly.
In the vast majority of cases this leads to performance regress
On Tue, Mar 11, 2014 at 09:12:53PM +, John Carr wrote:
> Will Deacon wrote:
> > On Tue, Mar 11, 2014 at 02:54:18AM +, John Carr wrote:
> > > A comment in arm/sync.md notes "We should consider issuing a inner
> > > shareability zone barrier here instead." Here is my first attempt
> > > at
Hi!
On Fri, 21 Feb 2014 21:32:14 +0100, I wrote:
> --- gcc/omp-low.c
> +++ gcc/omp-low.c
> @@ -1499,6 +1499,30 @@ scan_sharing_clauses (tree clauses, omp_context *ctx)
> {
>tree c, decl;
>bool scan_array_reductions = false;
> + bool offloaded;
> + switch (gimple_code (ctx->stmt))
> +
Hi!
On Wed, 4 Sep 2013 20:54:47 +0200, Jakub Jelinek wrote:
> This patch implements #pragma omp {target{, data, update},teams} lowering
> and expansion, and adds stub calls into libgomp, so that (for now
> unconditionally) we can at least always fall back to host execution.
> 2013-09-04 Jakub J
Ping~
Possible for stage-4 as a bug-fix?
Thanks,
Yufeng
On 02/24/14 14:05, Yufeng Zhang wrote:
Hi Marcus,
On 01/14/14 12:30, Marcus Shawcroft wrote:
On 6 January 2014 12:30, Yufeng Zhang wrote:
This patch fixes the implementation of vcvtmd_s64_f64 and vcvtpd_s64_f64 in
arm_neon.h to use l
Hi,
On 03/08/2014 03:50 PM, Ilya Verbin wrote:
Here is updated patch for libgomp. It assumes that there is a constructor with
a call to GOMP_offload_register in every target image, created by mkoffload
tool. How does this look?
LGTM. Shall I start committing my changes to the branch?
Bernd
Ping~
Originally posted here:
http://gcc.gnu.org/ml/gcc-patches/2014-02/msg01673.html
Thanks,
Yufeng
On 02/28/14 17:44, Yufeng Zhang wrote:
Hi,
The attached patch fixes a bug in ./src/aarch64/sysv.S:ffi_closure_SYSV
where stack unwinding information was not generated correctly. The
change
On 28/02/14 17:44, Yufeng Zhang wrote:
Hi,
The attached patch fixes a bug in ./src/aarch64/sysv.S:ffi_closure_SYSV
where stack unwinding information was not generated correctly. The
change has been reviewed, approved and merged into the stand-alone
libffi release tree**.
OK for the trunk?
Tha
On 24/02/14 14:05, Yufeng Zhang wrote:
Hi Marcus,
On 01/14/14 12:30, Marcus Shawcroft wrote:
On 6 January 2014 12:30, Yufeng Zhang wrote:
This patch fixes the implementation of vcvtmd_s64_f64 and vcvtpd_s64_f64 in
arm_neon.h to use llfloor and llceil instead, which are ILP32-friendly.
This p
On Wed, Mar 12, 2014 at 02:32:36PM +, Marcus Shawcroft wrote:
> >>OK, but we should wait for stage-1 now.
> >
> >Although the ILP32 is an experimental feature for 4.9, I think as a bug
> >fix the patch shall go in for stage-4.
>
> OK provided there is no RM objection in the next 24 hours.
Ok.
Hi,
The test infrastructure for gcc.dg/tree-prof reports relative paths
for all test outcomes except UNSUPPORTED, for which it reports the
absolute path of the test case. This patch ensure a relative path is
reported consistently reducing noise in regression test comparisons.
I'd like this to
On Wed, Mar 12, 2014 at 02:39:15PM +, Marcus Shawcroft wrote:
> 2014-03-12 Marcus Shawcroft
>
> * lib/profopt.exp (profopt-execute): Use $testcase in
> unsupported.
Ok, thanks.
> --- a/gcc/testsuite/lib/profopt.exp
> +++ b/gcc/testsuite/lib/profopt.exp
> @@ -277,7 +277,7 @
2014-03-12 18:12 GMT+04:00 Bernd Schmidt :
> LGTM. Shall I start committing my changes to the branch?
Yes, I think you should commit your changes.
And we will rewrite our part to use the new configure approach.
-- Ilya
I've been doing some local testing using this patch as a basis for some of my
own work on NEON intrinsics, and it seems good to me. A couple of points:
(1) Re. the comment that "If two vectors, we end up with a wierd mixed-endian
mode on NEON": firstly "wierd" should be spelt "weird";
secondly, i
Perhaps we need a require_potential_rvalue_constant_expression?
Jason
On Wed, Mar 12, 2014 at 02:27:12PM +, Marcus Shawcroft wrote:
> On 28/02/14 17:44, Yufeng Zhang wrote:
> >** http://github.com/atgreen/libffi
> >
> >
> >2014-02-28 Yufeng Zhang
> >
> > * src/aarch64/sysv.S (ffi_closure_SYSV): Use x29 as the
> > main CFA reg; update cfi_rel_offset.
>
Hi!
Apparently 435.gromacs benchmark is very sensitive (of course with
-ffast-math) to reassociation ordering.
We were sorting on SSA_NAME_VERSIONs, which has the disadvantage that we
reuse SSA_NAME_VERSIONs from SSA_NAMEs dropped by earlier optimization
passes and thus even minor changes in unre
Hi,
On 03/12/2014 04:01 PM, Jason Merrill wrote:
Perhaps we need a require_potential_rvalue_constant_expression?
Something like the below? Interesting, that should also save some
duplicate work. Note however, that, besides the trivial adjustment of
static_assert3.C, we produce slightly differe
Hi,
The attached patch fixes what seems to me as a bug in emitting a
DW_TAG_imported_declaration corresponding to 'using' statements in a
class.
Consider the following:
class A
{
public:
int a;
int method (int i);
};
int
A::method (int i)
{
return i + a;
}
class B : public A
{
public:
This patch is to fix the problem described here:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58066
The original patch is here:
http://gcc.gnu.org/ml/gcc-patches/2014-03/msg00369.html
The attached patch addresses HJ's comment.
bootstrap, regression test is ok. perf test in plain mode is ok. ok
for
Thanks Cary for the comments.
Patch updated, an also added a tool in contrib/ to dump the profile
annotation coverage.
Dehao
>
>
> On Wed, Mar 12, 2014 at 9:48 AM, Cary Coutant wrote:
>>
>> +void autofdo_source_profile::write_annotated_count () const
>> +{
>> + switch_to_section (get_section (
Thank you for pointing it out. I didn't realized that alias analysis
has influences on this issue.
The current problem is that the epilogue may be unnecessary if the
loop bound cannot be larger than the number of iterations of the
vectorized loop multiplied by VF when the vectorized loop is suppos
Hi Thomas,
Here is a new version of this patch (it was discussed in other thread:
http://gcc.gnu.org/ml/gcc-patches/2014-03/msg00573.html ) with ChangeLog.
Bootstrap and make check passed.
Ok to commit?
libgomp/ChangeLog.gomp | 29
libgomp/libgomp.map|1 +
libgomp/plugin-hos
On March 7, 2014 11:45, Ilmir Usmanov wrote:
OpenACC 1.0 support to fortran FE -- core.
Looks good to me. As Thomas is also fine with the patch set [1], the
patch can now go into the branch :-)
Previously and still approved are Part 3 and 4 [2] of the series. I will
separately reply to Part
Hi Ilmir,
Ilmir Usmanov wrote:
> Is it OK now?
Yes. Thanks for the patches - and the patience!
Tobias
Jerry DeLisle wrote:
+ if (dtp->common.unit == 0)
+ {
+ len = string_len_trim (dtp->internal_unit_len,
+dtp->internal_unit);
+ if (len > 0)
+ dtp->internal_unit_len = len;
+ iunit->recl = dtp->internal_unit_len;
+
On Fri, Mar 7, 2014 at 2:33 PM, Wei Mi wrote:
> Yes, x32 has the same problem. It should be tested. Fixed.
>
> Thanks,
> Wei.
>
>
> On Fri, Mar 7, 2014 at 2:06 PM, H.J. Lu wrote:
>> On Fri, Mar 7, 2014 at 1:26 PM, Wei Mi wrote:
>>> Hi,
>>>
>>> This patch is to fix the problem described here:
>>>
> There are several problems with this:
>
> 1. It doesn't work with C.
Ok, I will change the testcase using C.
> 2. IA32 has the same issue and isn't fixed.
I thought IA32 didn't have the same issue because abi only requires 32
bit alignment for stack starting address.
oh, I found the old pat
On Wed, Mar 12, 2014 at 2:03 PM, Wei Mi wrote:
>> There are several problems with this:
>>
>> 1. It doesn't work with C.
>
> Ok, I will change the testcase using C.
>
>> 2. IA32 has the same issue and isn't fixed.
>
> I thought IA32 didn't have the same issue because abi only requires 32
> bit a
Le 11/03/2014 10:25, Janus Weil a écrit :
>> Regression-tested on x86_64-unknown-linux-gnu.
>> This is not a regression as far as I know, but quite a severe
>> wrong-code, albeit limited to the corner case of transpose and
>> assumed shape and contiguous. OK for trunk/4.8/4.7 anyway ?
>
> I would
On 03/12/2014 12:12 PM, Paolo Carlini wrote:
- cxx_constant_value (condition);
+ require_potential_rvalue_constant_expression (condition);
We need both, actually; cxx_constant_value catches some cases that the
other doesn't.
Jason
Hi H.J.,
Could you show me why you postpone the setting
ix86_tls_descriptor_calls_expanded_in_cfun until reload_complete and
use ix86_tls_descriptor_calls_expanded_in_cfun instead of
ix86_current_function_calls_tls_descriptor? Isn't
ix86_current_function_calls_tls_descriptor useful to consider the
On Wed, Mar 12, 2014 at 2:36 PM, Wei Mi wrote:
> Hi H.J.,
>
> Could you show me why you postpone the setting
> ix86_tls_descriptor_calls_expanded_in_cfun until reload_complete and
> use ix86_tls_descriptor_calls_expanded_in_cfun instead of
> ix86_current_function_calls_tls_descriptor? Isn't
> ix86
On Sun, Mar 09, 2014 at 08:35:43PM +, Zoran Jovanovic wrote:
> Hello,
> This is new patch version.
> Approach suggested by Richard Biener with lowering bit-field accesses instead
> of modifying gimple trees is implemented.
> New command line option "-fmerge-bitfields" is introduced.
>
> Te
Oh, I see. Thanks!
Wei.
On Wed, Mar 12, 2014 at 2:42 PM, H.J. Lu wrote:
> On Wed, Mar 12, 2014 at 2:36 PM, Wei Mi wrote:
>> Hi H.J.,
>>
>> Could you show me why you postpone the setting
>> ix86_tls_descriptor_calls_expanded_in_cfun until reload_complete and
>> use ix86_tls_descriptor_calls_expa
This is the updated testcase.
Thanks,
Wei.
===
--- testsuite/gcc.dg/pr58066.c (revision 0)
+++ testsuite/gcc.dg/pr58066.c (revision 0)
@@ -0,0 +1,18 @@
+/* { dg-do compile { target {{ i?86-*-* x86_64-*-* } && { ! ia32 } } } } */
+/*
On Wed, Mar 12, 2014 at 2:58 PM, Wei Mi wrote:
> This is the updated testcase.
Does my patch fix the original problem?
> Thanks,
> Wei.
>
> ===
> --- testsuite/gcc.dg/pr58066.c (revision 0)
> +++ testsuite/gcc.dg/pr58066.c (revision
Hi,
On 03/12/2014 10:28 PM, Jason Merrill wrote:
On 03/12/2014 12:12 PM, Paolo Carlini wrote:
- cxx_constant_value (condition);
+ require_potential_rvalue_constant_expression (condition);
We need both, actually; cxx_constant_value catches some cases that the
other doesn't.
Ok, I th
On Wed, Mar 12, 2014 at 3:07 PM, H.J. Lu wrote:
> On Wed, Mar 12, 2014 at 2:58 PM, Wei Mi wrote:
>> This is the updated testcase.
>
> Does my patch fix the original problem?
Yes, it works. I am doing bootstrap and regression test for your patch. Thanks!
>
>> Thanks,
>> Wei.
>>
>> ==
ARM build (on chrome) is broken because of duplicate entries in arm.md
and unspecs.md. Fixed by removing duplication and merge those in
arm.md into unspecs.md.
(We had a similar fix for google/gcc-4_8 here -
http://gcc.gnu.org/viewcvs/gcc?view=revision&revision=198650)
Tested by building arm cros
Looks good to me.
Dehao
On Wed, Mar 12, 2014 at 3:35 PM, Hán Shěn (沈涵) wrote:
> ARM build (on chrome) is broken because of duplicate entries in arm.md
> and unspecs.md. Fixed by removing duplication and merge those in
> arm.md into unspecs.md.
>
> (We had a similar fix for google/gcc-4_8 here -
Committed (r208519 on trunk and r208520 on 4.8) after approval posted
in http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59392.
Only the dates are changed from what I posted originally.
Thanks,
Roland
On Fri, Dec 6, 2013 at 3:24 PM, Roland McGrath wrote:
> [This patch is on the git-only branch rola
Why is it not enough to emit warnings during build time when source
code changes signifcantly?
David
On Tue, Mar 11, 2014 at 4:27 PM, Dehao Chen wrote:
> During AutoFDO annotation, we want to record the annotation stats into
> an elf section, so that we can calculate how much percentage of the
>
> > This patch fixes the latest 58678 testcase by avoiding speculative
> > devirtualization to the destructor of an abstract class, which can
> > never succeed: you can't create an object of an abstract class, so
> > the pointer must point to an object of a derived class, and the
> > derived class
Dehao explained that the data needs to merged during link time to give
meaningful diagnostics.
Ok for google branch.
David
On Wed, Mar 12, 2014 at 3:55 PM, Xinliang David Li wrote:
> Why is it not enough to emit warnings during build time when source
> code changes signifcantly?
>
> David
>
>
On Wed, Mar 12, 2014 at 5:20 PM, Michael Meissner
wrote:
> Internally within IBM, the people wanting to use the new 128-bit integer
> instructions (and the integer decimal support instructions that I will be
> doing
> soon), asked for a new type to do the calculations in, rather than depend on
>
I noticed that the lto-wrapper is a little noisy without the -v option
when -save-temps is used. E.g.,
$ gcc main.c -flto -save-temps
[Leaving LTRANS /tmp/ccSEvaB7.args]
[Leaving LTRANS /tmp/ccQomDzb.ltrans.out]
[Leaving LTRANS /tmp/ccVzWdGZ.args]
[Leaving LTRANS /tmp/ccQomDzb.ltrans0.o]
Those me
>> Does my patch fix the original problem?
>
> Yes, it works. I am doing bootstrap and regression test for your patch.
> Thanks!
>
The patch passes bootstrap and regression test on x86_64-linux-gnu.
Thanks,
Wei.
On Wed, Mar 12, 2014 at 5:28 PM, Wei Mi wrote:
>>> Does my patch fix the original problem?
>>
>> Yes, it works. I am doing bootstrap and regression test for your patch.
>> Thanks!
>>
>
> The patch passes bootstrap and regression test on x86_64-linux-gnu.
>
My patch fails to handle ia32. Here is
On 03/11/2014 05:08 PM, Jan Hubicka wrote:
Jason, I was looking into this and I think I have patch that works. I would
just like to verify I inderstnad things right. First thing I implemented is to
consistently skip dtors of abstract classes as per the comment in
abstract_class_dtor_p there is
OK.
Jason
On 03/12/2014 11:46 AM, Tobias Burnus wrote:
> Jerry DeLisle wrote:
>> + if (dtp->common.unit == 0)
>> +{
>> + len = string_len_trim (dtp->internal_unit_len,
>> + dtp->internal_unit);
>> + if (len > 0)
>> +dtp->internal_unit_len = len;
>> + iunit-
I saw the problem last patch had on ia32. Without explicit call in rtl
template, scheduler may schedule the sp adjusting insn across tls
descriptor and break the alignment assumption.
I am testing the updated patch on x86_64.
Can we combine the last two patches, both adding call explicitly in
rtl
71 matches
Mail list logo
