https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87162
ma.jiang at zte dot com.cn changed:
What|Removed |Added
CC||ma.jiang at zte dot com.cn
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78772
--- Comment #12 from ma.jiang at zte dot com.cn ---
(In reply to Jim Wilson from comment #11)
Hi Jim,
Thank you for your patient explanations.
>
> If you have code with a lot of pointer casts, you should probably be
> compiling
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78772
--- Comment #9 from ma.jiang at zte dot com.cn ---
(In reply to Jim Wilson from comment #8)
> Looking at the 2011 ISO C standard, section 6.5 Expressions, paragraph 7,
> says "An object shall have its stored value accessed only b
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78772
--- Comment #7 from ma.jiang at zte dot com.cn ---
(In reply to Markus Trippelsdorf from comment #5)
Hi Markus,
> These optimizations are not dangerous if you use standard conforming code.
I think these optimizations are dangerous beca
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78772
--- Comment #4 from ma.jiang at zte dot com.cn ---
(In reply to Markus Trippelsdorf from comment #3)
> Please no.
> There are many other cases where optimizations could introduce issues that
> you will not notice when you compil
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78772
--- Comment #1 from ma.jiang at zte dot com.cn ---
Created attachment 40308
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40308&action=edit
proposed patch
Priority: P3
Component: driver
Assignee: unassigned at gcc dot gnu.org
Reporter: ma.jiang at zte dot com.cn
Target Milestone: ---
Hi all,
"-fstrict-aliasing" which is turned on at O2 level, May create wrong codes.
But, GCC does not give a warning for it
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65449
--- Comment #4 from ma.jiang at zte dot com.cn ---
Hi Bernd,
Thanks for your apply.
(In reply to Bernd Edlinger from comment #3)
> Yes, but that is not the fault of the strict volatile code path any more.
// Sure,I agree with you.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65449
--- Comment #2 from ma.jiang at zte dot com.cn ---
(In reply to Bernd Edlinger from comment #1)
> Hi Richard,
>
> the invalid/different code for -O2 -fstrict-volatile-bitfields will be
> fixed with my proposed patch, because the mi
: target
Assignee: unassigned at gcc dot gnu.org
Reporter: ma.jiang at zte dot com.cn
Hi all,
The munaligned-access option on ARM can not stop gcc from producing split
access codes. A very simple test
char mt[20];
void main()
{
void *mm=&(mt[1]);
*(( int *)m
Severity: normal
Priority: P3
Component: middle-end
Assignee: unassigned at gcc dot gnu.org
Reporter: ma.jiang at zte dot com.cn
Hi,all.
It seems that -fstrict-volatile-bitfields can affect volatile pointer
dereference. However, the gcc manual said this
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61241
--- Comment #4 from ma.jiang at zte dot com.cn ---
(In reply to ktkachov from comment #3)
> Can you please send the patch to gcc-patc...@gcc.gnu.org including a
> ChangeLog
Done! Thanks.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61241
--- Comment #2 from ma.jiang at zte dot com.cn ---
Created attachment 32823
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=32823&action=edit
testcase
should be put into gcc/testsuite/gcc.target/arm
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61241
--- Comment #1 from ma.jiang at zte dot com.cn ---
Created attachment 32822
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=32822&action=edit
proposed patch
Priority: P3
Component: rtl-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: ma.jiang at zte dot com.cn
Compiled with -O2,
#include
extern int off;
void *test(char *a1, char* a2)
{
memset(a2, 123, 123);
return a2 + off;
}
gives
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59785
--- Comment #2 from ma.jiang at zte dot com.cn ---
Ok, Thanks for the reply. I know what you mean. A atomic_store is not
responsible for loading the source operand atomically as it is just a store.
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: ma.jiang at zte dot com.cn
gcc provide a atomic_store interface as below.
void __atomic_store (type *ptr, type *val, int memmodel)
In manual, There is only a simple description ---"This is the generic version
of an a
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59000
--- Comment #3 from ma.jiang at zte dot com.cn ---
(In reply to Richard Biener from comment #2)
> This works on trunk, but of course symtab merging is pre-empted here by
tree
> merging I think. The error can be reproduced on trunk with
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59000
--- Comment #1 from ma.jiang at zte dot com.cn ---
Created attachment 31157
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=31157&action=edit
second source
y: P3
Component: lto
Assignee: unassigned at gcc dot gnu.org
Reporter: ma.jiang at zte dot com.cn
Created attachment 31156
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=31156&action=edit
first source
User defined built-in implementation cause lto error.
Use source
20 matches
Mail list logo
