Eric Botcazou writes:
>> Thanks for doing this. FWIW I agree it's probably the best stop-gap fix.
>> But the implication seems to be that unspec_volatile and volatile asms
>> are volatile in different ways. IMO they're volatile in the same way
>> and the problems for volatile asms apply to unspe
On Mon, Mar 03, 2014 at 10:20:10AM +0800, lin zuojian wrote:
> I saw
>
> http://www.phoronix.com/scan.php?page=article&item=llvm34_gcc49_compilers&num=1
> And LLVM/clang beaten gcc in serval tests.But I ran that
> tests,e.g.SciMark,it didn't appear to be like this on my i7 machine.
Hi Jakub,
Any comments on this patch?
--
Regards
lin zuojian
On Tue, Feb 25, 2014 at 03:28:14PM +0800, lin zuojian wrote:
> Sorry,I have forgot setting another shadow_mem's align.And many strbs
> bump up.
> Here 's patch v4.(last one contains html,damn thunderbird).
>
> --
> Without aligning
On Fri, Feb 28, 2014 at 08:47:56AM +0100, Bernd Edlinger wrote:
> I see the problem too.
>
> But I think it is not necessary to change the stack alignment
> to solve the problem.
>
> It appears to me that the code in asan_emit_stack_protection
> is just wrong. It uses SImode when the memory is no
On Sat, Mar 01, 2014 at 08:22:32PM +0100, Bernd Edlinger wrote:
> So, that is what I mean: this patch makes the stack grow by
> 32 bytes, just because the emit_stack_protection uses SImode,
> with unaligned addresses which is not possible for ARM, and
> not optimal for X86_64.
Incorrect, for this
On Mon, Mar 03, 2014 at 04:51:20PM +0800, lin zuojian wrote:
> Hi Jakub,
> Any comments on this patch?
Can you please repost the patch (+ ChangeLog entry) as attachment?
Or use saner MUA? When all tabs are eaten and other whitespace crippled,
it is impossible to look at the formatting.
Hi Jakub,
> No. As I wrote earlier, the alternative is to use unaligned stores for ARM,
> I've asked Lin to benchmark that compared to his patch, but haven't seen
> that done yet.
>
> Jakub
I have not benchmark yet.But according to what I hear from an ARM Engineer in
Huawei,
unaligned acc
On Mon, Mar 03, 2014 at 05:04:45PM +0800, lin zuojian wrote:
> > No. As I wrote earlier, the alternative is to use unaligned stores for ARM,
> > I've asked Lin to benchmark that compared to his patch, but haven't seen
> > that done yet.
> I have not benchmark yet.But according to what I hear from
Okay,I will use mutt as my MUA.
--
Regards
lin zuojian
On Mon, Mar 03, 2014 at 09:58:59AM +0100, Jakub Jelinek wrote:
> On Mon, Mar 03, 2014 at 04:51:20PM +0800, lin zuojian wrote:
> > Hi Jakub,
> > Any comments on this patch?
>
> Can you please repost the patch (+ ChangeLog entry) as attachm
On Sat, Mar 1, 2014 at 2:32 AM, Peter Bergner wrote:
> I'd like to ask for permission to backport the following two LIBITM bug
> fixes to the FSF 4.8 branch. Although these are not technically fixing
> regressions, they do fix the libitm.c/reentrant.c testsuite failure on
> s390 and powerpc (or a
Hi Jakub,
On Mon, Mar 03, 2014 at 10:08:53AM +0100, Jakub Jelinek wrote:
> On Mon, Mar 03, 2014 at 05:04:45PM +0800, lin zuojian wrote:
> > > No. As I wrote earlier, the alternative is to use unaligned stores for
> > > ARM,
> > > I've asked Lin to benchmark that compared to his patch, but haven'
On Sat, Feb 22, 2014 at 12:48:40AM -0500, Jason Merrill wrote:
> There's no reason why we wouldn't check for dependent scopes when
> parsing the target of an alias declaration, and indeed not doing so
> led to the ICE here.
>
> The rest of the patch improves the diagnostic for this testcase (and
>
On Sat, Mar 1, 2014 at 3:33 PM, Marc Glisse wrote:
> Hello,
>
> again, a stage 1 patch that I will ping then, but early comments are
> welcome.
>
> PR 59100 was asking to transform n?rotate(x,n):x to rotate(x,n) (because it
> can be hard to write a strictly valid rotate in plain C). The operation
The atxmega16x1 AVR variant doesn't exist, but the device name got
into the device list in gcc/config/avr/avr-mcus.def. This patch removes the
non-existent device.
If ok, could someone commit please? I don't have commit access.
Regards
Senthil
2014-03-03 Senthil Kumar Selvaraj
* conf
On Fri, Feb 28, 2014 at 11:48 PM, Marc Glisse wrote:
> Hello,
>
> this is a stage 1 patch, and I'll ping it then, but if you have comments
> now...
>
> Passes bootstrap+testsuite on x86_64-linux-gnu.
>
> 2014-02-28 Marc Glisse
>
> PR tree-optimization/57742
> gcc/
> * tree-ssa-f
On Sat, Mar 1, 2014 at 11:23 PM, Paulo J. Matos wrote:
>
> This patch fixes lto/55113 for powerpc.
> Combining -fshort-double with -flto is now working fine.
>
> I attach patch and testcase (unsure if testcase is in the right place).
> Tested with target powerpc-abispe.
>
>
> 2014-03-01 Paulo Mat
Hi,
in this -std=c++1y regression we ICE on invalid code during error recovery:
60376.C: In function ‘void bar()’:
60376.C:8:9: error: expected nested-name-specifier before ‘(’ token
using (A().foo);
^
60376.C:8:9: error: expected unqualified-id before ‘(’ token
60376.C:8:9: error: expected ‘;’
On Mon, Mar 3, 2014 at 9:01 AM, Richard Sandiford
wrote:
> Eric Botcazou writes:
>>> Thanks for doing this. FWIW I agree it's probably the best stop-gap fix.
>>> But the implication seems to be that unspec_volatile and volatile asms
>>> are volatile in different ways. IMO they're volatile in th
> non-local labels should block most optimizations by the fact they
> are a receiver of control flow and thus should have an abnormal
> edge coming into them. If that's not the case (no abnormal edge)
> then that's the bug to fix.
It's (of course) more complicated, you need to look at HP's fix an
Eric Botcazou writes:
>> non-local labels should block most optimizations by the fact they
>> are a receiver of control flow and thus should have an abnormal
>> edge coming into them. If that's not the case (no abnormal edge)
>> then that's the bug to fix.
>
> It's (of course) more complicated, y
Hi!
I've committed following testcase for an ICE fixed by r200376
on the trunk. When the fix is backported to 4.8/4.7 branches,
the testcase should be added there too.
2014-03-03 Jakub Jelinek
PR preprocessor/60400
* c-c++-common/cpp/pr60400.c: New test.
* c-c++-commo
> ...it's so loosely defined. If non-local labels are the specific problem,
> I think it'd be better to limit the flush to that.
No, there was "e.g." written so non-local labels are not the only problem.
> I'm back to throwing examples around, sorry, but take the MIPS testcase:
>
> volatile
On Fri, Feb 28, 2014 at 8:37 PM, Mircea Namolaru
wrote:
> Hi,
>
> Thanks. Here is the updated patch.
Boostrapped / tested on x86_64-unknown-linux-gnu and applied.
Thanks,
Richard.
> 2014-02-26 Tobias Grosser
> Mircea Namolaru
>
> PR tree-optimization/58028
> * graphit
On 03/03/2014 12:39 PM, Richard Biener wrote:
On Fri, Feb 28, 2014 at 8:37 PM, Mircea Namolaru
wrote:
Hi,
Thanks. Here is the updated patch.
Boostrapped / tested on x86_64-unknown-linux-gnu and applied.
Thanks Richard!
Tobias
On 27/02/14 12:33, Marcus Shawcroft wrote:
On 24 February 2014 09:49, Renlin Li wrote:
gcc/testsuite/ChangeLog:
2014-02-03 Renlin Li
* gcc.target/aarch64/aapcs64/validate_memory.h: Move f32in64 and
i32in128 cases
outside special big-endian processing block.
This is is a fix for
The new gcc.target/i386/prefetchwt1-1.c test currently FAILs on Solaris 9/x86:
FAIL: gcc.target/i386/prefetchwt1-1.c (test for excess errors)
Excess errors:
/var/gcc/regression/trunk/9-gcc-gas/build/gcc/include/xmmintrin.h:1195:1: error:
inlining failed in call to always_inline '_mm_prefetch': ta
The new g++.dg/abi/anon2.C test currently causes lots of noise in
mail-report.log:
UNRESOLVED: g++.dg/abi/anon2.C -std=c++98 scan-assembler .weak(_definition)?[
\\t]_?_ZN2N11D1C3fn1ENS0_1BE
UNRESOLVED: g++.dg/abi/anon2.C -std=c++98 scan-assembler .weak(_definition)?[
\\t]_?_ZN2N11D1C3fn2ES1_
U
http://gcc.gnu.org/ml/gcc-patches/2014-02/msg01402.html
fixes -mapcs-frame -g ICEs.
ok for trunk ?
On Fri, 2014-02-28 at 19:32 -0600, Peter Bergner wrote:
> I'd like to ask for permission to backport the following two LIBITM bug
> fixes to the FSF 4.8 branch. Although these are not technically fixing
> regressions, they do fix the libitm.c/reentrant.c testsuite failure on
> s390 and powerpc (or
---
gcc/config/i386/i386.md | 49 +
1 file changed, 49 insertions(+)
diff --git a/gcc/config/i386/i386.md b/gcc/config/i386/i386.md
index b9f1320..86ab025 100644
--- a/gcc/config/i386/i386.md
+++ b/gcc/config/i386/i386.md
@@ -18535,6 +18535,55 @@
Hi,
In this patch I only add ChangeLog.
--
Without aligning the asan stack base,this base will only 64-bit aligned in ARM
machines.
But asan require 256-bit aligned base because of this:
1.right shift take ASAN_SHADOW_SHIFT(which is 3) bits are zeros
2.store multiple/load multiple instructions
Eric Botcazou writes:
>>> ...it's so loosely defined. If non-local labels are the specific problem,
>> I think it'd be better to limit the flush to that.
>
> No, there was "e.g." written so non-local labels are not the only problem.
What are the others though? As discussed in the other subthrea
On Mon, Mar 03, 2014 at 09:10:28PM +0800, lin zuojian wrote:
> +2014-03-03 lin zuojian
Capital letters at the beginning of name/surname please.
One empty line after the date/name/mail line.
> + Fix PR middle-end/60281
Remove "Fix ", just
PR middle-end/60281
> + * asan.c (asan_
Alan Modra writes:
> On Mon, Mar 03, 2014 at 02:14:51PM +1030, Alan Modra wrote:
>> I'll post update-copyright.py separately.
Thanks for doing this, looks good to me FWIW. I don't know whether
we want to keep a single script for both GCC and binutils+gdb or fork,
but probably separate copies mak
On Mon, 3 Mar 2014, Richard Biener wrote:
That's a bit much of ad-hoc pattern-matching ... wouldn't be
p = malloc (n);
memset (p, 0, n);
transform better suited to the strlen opt pass? After all that tracks
what 'string' is associated with a SSA name pointer through
arbitrary satements using a
Hi,
Patch v1 is just wrong.
--
Regards
lin zuojian
---
gcc/config/i386/i386.md | 50 +
1 file changed, 50 insertions(+)
diff --git a/gcc/config/i386/i386.md b/gcc/config/i386/i386.md
index b9f1320..e44fb14 100644
--- a/gcc/config/i386/i386.md
+
The test g++.dg/abi/anon2.C introduced at r208157 causes:
UNRESOLVED: g++.dg/abi/anon2.C -std=c++98 scan-assembler .weak(_definition)?[
\\t]_?_ZN2N11D1C3fn1ENS0_1BE
UNRESOLVED: g++.dg/abi/anon2.C -std=c++98 scan-assembler .weak(_definition)?[
\\t]_?_ZN2N11D1C3fn2ES1_
UNRESOLVED: g++.dg/abi/ano
On Mon, Mar 03, 2014 at 04:49:24PM +0100, Dominique Dhumieres wrote:
> The test g++.dg/abi/anon2.C introduced at r208157 causes:
>
> UNRESOLVED: g++.dg/abi/anon2.C -std=c++98 scan-assembler
> .weak(_definition)?[ \\t]_?_ZN2N11D1C3fn1ENS0_1BE
> UNRESOLVED: g++.dg/abi/anon2.C -std=c++98 scan-asse
2014-03-03 13:41 GMT+04:00 Senthil Kumar Selvaraj
:
> The atxmega16x1 AVR variant doesn't exist, but the device name got
> into the device list in gcc/config/avr/avr-mcus.def. This patch removes the
> non-existent device.
>
> If ok, could someone commit please? I don't have commit access.
>
> Regar
David Edelsohn wrote:
> On Fri, Feb 28, 2014 at 7:11 PM, Bill Schmidt
> wrote:
> > * config/rs6000/rs6000.c (rs6000_preferred_reload_class): Disallow
> > PLUS rtx's from reloading into a superset of FLOAT_REGS; relax
> > constraint on constants to only prevent them from bei
OK, thanks.
Jason
2014-03-03 13:34 GMT+04:00 S, Pitchumani :
> Hi,
>
> Few AVR Xmega devices have specific instruction support than the architecture
> it belongs to. For example atxmega128b1 device has RMW instructions (XCH,LAC,
> LAS and LAT) support, but not all avrxmega6 devices have.
>
> Now, avr-gcc passes arch
On 03/03/2014 04:48 AM, Torvald Riegel wrote:
> Should I add myself as maintainer for libitm?
Yes.
> Does this come with any other responsibilities than reviewing patches?
No.
r~
Uli, thanks. Sorry I misunderstood what you said the first time. I'm
currently testing this version, which I've verified fixes the bug. I'll
plan to commit the new version after testing provided neither you nor
David objects.
Thanks!
Bill
On Mon, 2014-03-03 at 17:17 +0100, Ulrich Weigand wrote
I've been looking how to make the precompiled header mechanism allow
me to use the
ARC -misize option (which outputs additional information about gcc's
idea of instruction
addresses for the purpose of branch shortening, to help debugging the
latter) in a
compilation involving precompiled headers.
I
Committed to branch dmalcolm/jit:
gcc/jit/
* libgccjit++.h (gccjit::function::operator()): Add overload for
a call with 3 arguments.
(gccjit::block::add_call): Likewise for 4 arguments.
(gccjit::rvalue::cast_to): New method.
(gccjit::rvalue::operator[]): New
On Mon, 3 Mar 2014, Joern Rennecke wrote:
> be ignored for the purpose of checking pch validity.
>
> The attached patch implements this as PchIgnore.
>
> bootstrapped on i686-pc-linux.gnu.
>
> OK to apply?
OK.
--
Joseph S. Myers
jos...@codesourcery.com
Hi,
Currently most or all of the libsanitizer tests fail for
powerpc64le-linux-gnu, and we won't be able to address this in GCC 4.9.
(We do plan to look at this in the next release.) Richard Biener
suggested we mark it as unsupported, as this patch implements.
Bootstrapped and tested on powerp
On Mon, Mar 03, 2014 at 01:21:47PM -0600, Bill Schmidt wrote:
> Currently most or all of the libsanitizer tests fail for
> powerpc64le-linux-gnu, and we won't be able to address this in GCC 4.9.
> (We do plan to look at this in the next release.) Richard Biener
> suggested we mark it as unsupporte
OK.
Jason
I've committed patch to libgo to update to the Go 1.2.1 release. This
is a small patch that fixes a couple of serious bugs that have no source
code workarounds. Bootstrapped and ran Go testsuite on
x86_64-unknown-linux-gnu. Committed to mainline.
Ian
diff -r eb03648db396 libgo/MERGE
--- a/libg
I committed this patch to the web site to mention that GCC 4.9 supports
Go 1.2.1.
Ian
Index: gcc-4.9/changes.html
===
RCS file: /cvs/gcc/wwwdocs/htdocs/gcc-4.9/changes.html,v
retrieving revision 1.57
diff -u -r1.57 changes.html
--- g
On Mar 1, 2014, at 6:36 AM, Eric Botcazou wrote:
> It introduces a new, temporary predicate really_volatile_insn_p
really is a really horrible name. Hint, if cs domain specific wikipedia
describe what you were doing, what would the page be called? really is
unlikely to be it.
On 27/02/14 22:32, Marcus Shawcroft wrote:
> On 21 February 2014 04:24, Kugan wrote:
>
>> Compiling inline asm results in ICE (PR60034). Alignment calculation in
>> aarch64_classify_address for (symbol_ref:DI ("*.LANCHOR4") [flags
>> 0x182])) seems wrong here.
>
> Hi Kugan,
>
> + else if (
AIUI:
(1) The main point of http://gcc.gnu.org/ml/gcc-patches/2012-10/msg01172.html
was that we had:
emit_move_insn (virtual_stack_vars_rtx, hard_frame_pointer_rtx);
/* This might change the hard frame pointer in ways that aren't
apparent to early optimization passes, so
On Mon, 2014-03-03 at 13:48 +0100, Torvald Riegel wrote:
> On Fri, 2014-02-28 at 19:32 -0600, Peter Bergner wrote:
> > I'd like to ask for permission to backport the following two LIBITM bug
> > fixes to the FSF 4.8 branch. Although these are not technically fixing
> > regressions, they do fix the
On Mon, Mar 3, 2014 at 1:10 PM, Rainer Orth
wrote:
> The new gcc.target/i386/prefetchwt1-1.c test currently FAILs on Solaris 9/x86:
>
> FAIL: gcc.target/i386/prefetchwt1-1.c (test for excess errors)
> Excess errors:
> /var/gcc/regression/trunk/9-gcc-gas/build/gcc/include/xmmintrin.h:1195:1:
> e
> That doesn't really answer the question though. What's the correct
> behaviour for an unspec volatile in a loop? I don't think it's what
> we did in the example above, since it doesn't seem self-consistent.
> And "not spending too much time" is again a bit vague in terms of
> saying what's righ
On Mon, Mar 3, 2014 at 11:27 PM, Uros Bizjak wrote:
>> The new gcc.target/i386/prefetchwt1-1.c test currently FAILs on Solaris
>> 9/x86:
>>
>> FAIL: gcc.target/i386/prefetchwt1-1.c (test for excess errors)
>> Excess errors:
>> /var/gcc/regression/trunk/9-gcc-gas/build/gcc/include/xmmintrin.h:119
On Tue, Mar 4, 2014 at 12:31 AM, Uros Bizjak wrote:
>>> The new gcc.target/i386/prefetchwt1-1.c test currently FAILs on Solaris
>>> 9/x86:
>>>
>>> FAIL: gcc.target/i386/prefetchwt1-1.c (test for excess errors)
>>> Excess errors:
>>> /var/gcc/regression/trunk/9-gcc-gas/build/gcc/include/xmmintrin
In Go, unlike C, there can be mutually recursive static initializers.
For type descriptors, those initializers can be common, in the sense
that they can appear in multiple object files. This is done using
make_decl_one_only. That function only computes relocation information
correctly when the in
Hi,
This patch fixes wrong formatting as Jakub points out.
--
Regards
lin zuojian
--
Without aligning the asan stack base,this base will only 64-bit aligned in ARM
machines.
But asan require 256-bit aligned base because of this:
1.right shift take ASAN_SHADOW_SHIFT(which is 3) bits are zeros
Hi,
This patch removes trailing whitespaces.
--
Regards
lin zuojian
--
Without aligning the asan stack base,this base will only 64-bit aligned in ARM
machines.
But asan require 256-bit aligned base because of this:
1.right shift take ASAN_SHADOW_SHIFT(which is 3) bits are zeros
2.store multi
Hi,
Patch v1 v2 all have problem.Checkout v3.
--
Regards
lin zuojian
---
gcc/config/i386/i386.md | 49 +
1 file changed, 49 insertions(+)
diff --git a/gcc/config/i386/i386.md b/gcc/config/i386/i386.md
index b9f1320..80d3bf7 100644
--- a/gcc/con
On Mon, Mar 3, 2014 at 5:02 AM, lin zuojian wrote:
Testcase?
How about making a generic pass which does this?
See http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23684 also. At the
same time this can be used to do the store pair optimization for
ARM/AARCH64 too.
Thanks,
Andrew
>
> ---
> gcc/con
On Mon, Mar 03, 2014 at 07:19:51PM -0800, Andrew Pinski wrote:
> On Mon, Mar 3, 2014 at 5:02 AM, lin zuojian wrote:
>
> Testcase?
The test case is the same with
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23684.
> How about making a generic pass which does this?
Maybe GIMPLE should add a pass abo
Gerald's script pointed out that I forgot to add a to my recent
patch to gcc-4.9/changes.html. Fixed with the appended. Committed.
Ian
Index: gcc-4.9/changes.html
===
RCS file: /cvs/gcc/wwwdocs/htdocs/gcc-4.9/changes.html,v
retrie
I merged GCC trunk revision 208301 to the gccgo branch.
Ian
And please note that my patch is for the situation where expansion has
been done.Like instrumentation.
--
Regards
lin zuojian
On Tue, Mar 04, 2014 at 11:44:06AM +0800, lin zuojian wrote:
> On Mon, Mar 03, 2014 at 07:19:51PM -0800, Andrew Pinski wrote:
> > On Mon, Mar 3, 2014 at 5:02 AM, lin zuojia
Richard Sandiford writes:
> I'll run a full test overnight, but does this look like it might be
> a way out, at least for 4.9?
FWIW, it passed testing on x86_64-linux-gnu ({,-m32}, all,ada).
Here it is again with an updated cselib.c comment. OK to install?
Thanks,
Richard
gcc/
* built
Eric Botcazou writes:
>> That doesn't really answer the question though. What's the correct
>> behaviour for an unspec volatile in a loop? I don't think it's what
>> we did in the example above, since it doesn't seem self-consistent.
>> And "not spending too much time" is again a bit vague in te
On Mon, Mar 03, 2014 at 07:19:51PM -0800, Andrew Pinski wrote:
> On Mon, Mar 3, 2014 at 5:02 AM, lin zuojian wrote:
>
> Testcase?
> How about making a generic pass which does this?
>
> See http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23684 also. At the
> same time this can be used to do the stor
Hi Tobias!
I fixed my patches. Could you review them?
I'd use "integer" instead of "INTEGER" as it is not a 'reserved' word
OpenMP implementation uses capital letters, so, perhaps, we also should
do this, for consistency?
--
Ilmir.
OpenACC 1.0 fortran FE support -- matching and resolving.
* gcc/fortran/openmp.c
(gfc_free_omp_clauses): Remove also OpenACC clauses.
(gfc_free_expr_list): New function to clear expression list.
(match_oacc_expr_list): New function to match expression list.
(match_oacc_cla
OpenACC 1.0 fortran FE support -- translation to GENERIC.
gcc/fortran/
* trans-decl.c
(gfc_generate_function_code): Insert OACC_DECLARE GENERIC node.
* trans-openmp.c (gfc_convert_expr_to_tree): New helper function.
(gfc_trans_omp_array_reduction): Support also OpenACC. Ad
On Tue, Mar 04, 2014 at 08:48:40AM +0100, Jakub Jelinek wrote:
> On Mon, Mar 03, 2014 at 07:19:51PM -0800, Andrew Pinski wrote:
> > On Mon, Mar 3, 2014 at 5:02 AM, lin zuojian wrote:
> >
> > Testcase?
> > How about making a generic pass which does this?
> >
> > See http://gcc.gnu.org/bugzilla/sh
76 matches
Mail list logo
