files changed, 53 insertions(+)
create mode 100644 gcc/testsuite/gcc.dg/Wstrict-aliasing-inline-parameter.C
diff --git a/gcc/ChangeLog b/gcc/ChangeLog
index 8ccdde2..f584567 100644
--- a/gcc/ChangeLog
+++ b/gcc/ChangeLog
@@ -1,3 +1,8 @@
+2014-08-19 Lin Zuojian
+ * tree-inline.c (global
Hi Andrew,
I configure my gcc only to c language family. Sorry for my sloppy. I
have not run the test yet either. I only run my test manually.
That will be patch v2 soon.
--
Lin Zuojian
100644
--- a/gcc/ChangeLog
+++ b/gcc/ChangeLog
@@ -1,3 +1,14 @@
+2014-08-19 Lin Zuojian
+
+ * tree-inline.c (setup_one_parameter): Add strict aliasing check.
+ * c-family/c-common.c (strict_aliasing_warning): Move to alias.c.
+ * c-family/c-common.h (strict_aliasing_warning): Move to
rates these code. That make
it difficult to debug.
---
Lin Zuojian
), len / 2);
^
1.cpp:29:70: warning: during inlining function int hash2(const short unsigned
int*, int) into function int foo(int, int, int) [-Wstrict-aliasing]
It is clear what is going on.
On Tue, Aug 19, 2014 at 04:49:57PM +0800, lin zuojian wrote:
> Hi Richard,
> > General
/ChangeLog
index e1b655f..4338e2b 100644
--- a/gcc/ChangeLog
+++ b/gcc/ChangeLog
@@ -1,3 +1,14 @@
+2014-08-21 Lin Zuojian
+
+ * tree-inline.c (setup_one_parameter): Add strict aliasing check.
+ * c-family/c-common.c (strict_aliasing_warning): Move to alias.c.
+ * c-family/c-common.h
fix this test. And commit my code.
---
Lin Zuojian
insertions(+), 79 deletions(-)
create mode 100644
gcc/testsuite/g++.dg/warn/Wstrict-aliasing-inline-parameter.C
diff --git a/gcc/ChangeLog b/gcc/ChangeLog
index 1067203..bff6354 100644
--- a/gcc/ChangeLog
+++ b/gcc/ChangeLog
@@ -1,3 +1,14 @@
+2014-08-21 Lin Zuojian
+
+ * tree-inline.c
Hi Andrew,
What do you think of the current patch? If you thought it was find to
commit to trunk, please commit it for me.
--
Lin Zuojian
Hi Richard,
Do you think this version is good enough to commit to trunk? I have
asked Andrew to commit for me. If it is not good enough, I may ask
him not to do this.
---
Lin Zuojian
Hi,
Currently warning about strict aliasing is not strict enough. It has not
considered tbaa. So a test case emit addition error. This patch
is not good for commit.
--
Lin Zuojian
d for committing.
---
Lin Zuojian
(base);
size: 32, bpos: 0
B (base);
size: 32, bpos: 32
C:: s;
size: 32, bpos: 64
int c;
size: 32, bpos: 96
That helps to identify the field access, the assembly:
movl12(%rax), %edx
may mean accessing the field c of struct C.
It helps a lot.
--
lin zuojian
Hi,
This crash is due to fail to consider the exception situation that
the insn variable may not be a insn at all.
arm.c (thumb1_reorg): if the
selected insn is not a insn, continue to next bb.
---
gcc/config/arm/arm.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/
Thanks Richard,
I didn't aware that patch.
--
Lin Zuojian
* class.c (dump_class_hierarchy_1): dump fields after hierarchy information.
---
gcc/cp/class.c | 38 ++
1 file changed, 38 insertions(+)
diff --git a/gcc/cp/class.c b/gcc/cp/class.c
index 14780e7..13579ac 100644
--- a/gcc/cp/class.c
+++ b/gcc/cp/class.c
@
lowest 5 bits should be zeros.That means 32 bytes or 256
bits aligned.
* asan.c (asan_emit_stack_protection): Forcing the base to align to 256 bits
* cfgexpand.c (expand_used_vars): Leaving a space in the stack frame for
alignment
Signed-off-by: lin zuojian
---
gcc/asan.c | 6 ++
gcc
> On Thu, Feb 20, 2014 at 04:19:12PM +0800, lin zuojian wrote:
>> Without aligning the asan stack base,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 ar
If you don't mind my realigning on STRICT_ALIGNMENT machines,I will make
patch v2 soon.
>> On Thu, Feb 20, 2014 at 04:19:12PM +0800, lin zuojian wrote:
>>> Without aligning the asan stack base,base will only 64-bit aligned in
>>> ARM machines.
>>> But asan r
the first place.Of course aligned str
can be peepholed into aligned str multiple.
--
lin zuojian
于 2014年02月20日 19:05, Ramana Radhakrishnan 写道:
>>> Or, if ARM supports unaligned loads/stores using special instructions,
>>> perhaps you should also benchmark the alternative of not realigning, but
>>> instead making sure those unaligned instructions are used for the shadow
>>> memory loads/stores
Hi,
I have misunderstood the meaning of STRICT_ALIGNMENT.Sorry for that Jakub.
I think patch v2 have modified as Jakub suggested.
---
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
Hi everyone,
no comments for my patch?
于 2014年02月21日 10:43, lin zuojian 写道:
> Hi,
> I have misunderstood the meaning of STRICT_ALIGNMENT.Sorry for that Jakub.
> I think patch v2 have modified as Jakub suggested.
>
>
> ---
> Without aligning the asan stack base,this base wil
I reviewed the patch, and found a major bug in setting shadow_mem's
alignment.So I release patch v3.
Addition to the bug I mention,a trailing whitespace is also removed.
---
Without aligning the asan stack base,this base will only 64-bit aligned
in ARM machines.
But asan require 256-bit aligned ba
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 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 shif
mbine into one set mem:SI
X1,REG:SI Y1,if X is not mentioned as SI mode aligned.
To make sure X is SI mode algined,virtual register base must be realigned.
For this patch,I only intent to make it right.Making it best is next task.
--
Regards
lin zuojian.
于 2014年02月28日 15:47, Bernd Edlinger 写道:
于 2014年02月28日 15:58, lin zuojian 写道:
> Hi Bernd,
> I agree you with the mode problem.
>
> And I have not change the stack alignment.What I change is the virtual
> register base's alignment.
> Realignment must be make in !STRICT_ALIGNMENT machine,or emitting the
> ef
igned addresses which is not possible for ARM, and
> not optimal for X86_64.
It's because of the realignment,as my comment said.I have to make room
for virtual registers's realignment,or they(or the spilled registers) will
get damaged by the other subroutine.
--
Regards
lin zuojian
Hi Bernd,
You may send a patch too.Your idea will be more clear.
--
Regards
lin zuojian
On Sun, Mar 02, 2014 at 10:24:52AM +0800, lin zuojian wrote:
> Hi Bernd,
>
> set_mem_align is not working like magic.
>
> set_mem_align just set the alignment of a memory rtx.And You must a
Hi,
my mail is not achived by
http://gcc.gnu.org/ml/gcc-patches/2014-02/. What's happening?
--
Regards
lin zuojian
Hi,
I forgot now is Mar.I thought it's Feb.Sorry.
--
Regards
lin zuojian
On Sun, Mar 02, 2014 at 10:57:15AM +0800, lin zuojian wrote:
> Hi,
> my mail is not achived by
> http://gcc.gnu.org/ml/gcc-patches/2014-02/. What's happening?
>
> --
> Regards
> lin zuojian
Yeah, I have realized that.
On Sat, Mar 01, 2014 at 10:01:41PM -0500, Patrick Palka wrote:
> On Sat, Mar 1, 2014 at 9:57 PM, lin zuojian wrote:
> > Hi,
> > my mail is not achived by
> > http://gcc.gnu.org/ml/gcc-patches/2014-02/. What's happening?
>
> That's last month's archive.
e.The gcc peephole
pass will do its job.These constant moves will get combined.
So Maybe the best mode is not so important.
--
Regards
lin zuojian
Hi,
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.Was that
article written by Apple?
--
Regards
lin zuojian
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).
>
&
eer in
Huawei,
unaligned accessing usually slow.And not recommand to use too much.
--
Regards
lin zuojian
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 (
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 benchm
---
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 @@
STRICT_ALIGNMENT.
* cfgexpand.c (expand_stack_vars): set base_align appropriately when
asan is
on.
(expand_used_vars): Leaving a space in the stack frame for alignment if
STRICT_ALIGNMENT.
Signed-off-by: lin zuojian
---
gcc/ChangeLog | 10 ++
gcc/asan.c
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
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
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
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 shoul
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:0
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?
> >
&g
On Tue, Mar 04, 2014 at 09:04:56AM +0100, Jakub Jelinek wrote:
> On Tue, Mar 04, 2014 at 11:11:45AM +0800, lin zuojian wrote:
> > Without aligning the asan stack base,this base will only 64-bit aligned in
> > ARM machines.
> > But asan require 256-bit aligned base because
Thanks Jakub
--
Regards
lin zuojian
On Tue, Mar 04, 2014 at 10:15:31AM +0100, Jakub Jelinek wrote:
> On Tue, Mar 04, 2014 at 04:44:57PM +0800, lin zuojian wrote:
> > On Tue, Mar 04, 2014 at 09:04:56AM +0100, Jakub Jelinek wrote:
> > > On Tue, Mar 04, 2014 at 11:11:45AM +0800,
Hi,
I have summited a patch in this ml.But the difficult part may be the
code formatting.I am using vim as my editor.
--
Regards
lin zuojian.
On Wed, Mar 05, 2014 at 07:28:35AM +0100, Marek Polacek wrote:
> On Wed, Mar 05, 2014 at 11:31:59AM +0800, lin zuojian wrote:
> > Hi,
> > I have summited a patch in this ml.But the difficult part may be the
> > code formatting.I am using vim as my editor.
>
> I
On Wed, Mar 05, 2014 at 11:29:07AM +0400, Yury Gribov wrote:
> >That is not true. The indentation style is:
> >http://www.gnu.org/prep/standards/standards.html#Formatting
> >...
> >The above also mentions particular options
> >for GNU indent which set various rules.
>
> Ah, good to know. So, are
to test this idea yet.If you are interested in that way,please
test this one.It's always better when there is an option.
--
Regards
lin zuojian
Hi Bernd,
Seem we are not talking the same problem.You should first make sure
what has been going wrong first.
And I will sign it.
--
Regards
lin zuojian
Hi Bernd,
I am asking them if they would accept a scaned image version.Post
station is so 90's
--
Regards
lin zuojian
Hi Bernd,
Post stations are not that 90's,and they charge.It took me $30 to
post the file to USA.It's so inconvenient and expensive that I can't
send a scaned version.
--
Regards
lin zuojian
On Wed, Apr 09, 2014 at 06:47:56PM +0800, lin zuojian wrote:
> Hi Bernd,
So,I don't think asan is available on ARM.
Anyway I have signed the FSF copyright form.I hope my patch will be
apply on newer GCC.
--
Regards
lin zuojian
far, and which new files have you written
so far?]
gcc/asan.c
gcc/ChangeLog
gcc/cfgexpand.c
Okay, you may review my patch again, if there is no problem, please
commit it for me.
--
Regards
lin zuojian
+), 2 deletions(-)
diff --git a/gcc/ChangeLog b/gcc/ChangeLog
index da35be8..30a2b33 100644
--- a/gcc/ChangeLog
+++ b/gcc/ChangeLog
@@ -1,3 +1,12 @@
+2014-04-18 Lin Zuojian
+ PR middle-end/60281
+ * asan.c (asan_emit_stack_protection): Force the base to align to
+ appropriate
ffect x86.
c) When you compare the test results with and without the patch, were there any
regressions?
Only the bug has gone. My app can run on my Android ARM system.
On Fri, Apr 18, 2014 at 12:21:50PM +0800, lin zuojian wrote:
> Hi,
> Here is the patch after the Jakub's r
Hi Jakub,
On Fri, Apr 18, 2014 at 09:09:17AM +0200, Jakub Jelinek wrote:
> Extra line missing before the PR line.
Should I post PATCH v9 or someone helps adding one when committing
the patch?
--
Regards
lin zuojian
61 matches
Mail list logo
