https://gcc.gnu.org/bugzilla/show_bug.cgi?id=28901
--- Comment #22 from Chen Gang ---
(In reply to Mark Wielaard from comment #21)
[...]
> Although in C a static const is not really like a #define I suspect that
> there are cases where they are used as such in header files. If that is the
> maj
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69573
--- Comment #3 from Chen Gang ---
Created attachment 37625
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=37625&action=edit
Under my Darwin mac book OS X Yosemite 10.10.4, it looks short wide alignas for
long wide type will cause issue.
Un
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69573
--- Comment #4 from Chen Gang ---
(In reply to Chen Gang from comment #3)
> Created attachment 37625 [details]
> Under my Darwin mac book OS X Yosemite 10.10.4, it looks short wide alignas
> for long wide type will cause issue.
Oh, sorry, it is
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69573
--- Comment #5 from Chen Gang ---
(In reply to Martin Sebor from comment #2)
> Patch posted for review:
> https://gcc.gnu.org/ml/gcc-patches/2016-01/msg02372.html
I do not known why let __SIZEOF_LONG_DOUBLE__ == 12 ?
I guess we need use __SIZEO
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69573
--- Comment #6 from Chen Gang ---
(In reply to Chen Gang from comment #5)
>
> I guess we need use __SIZEOF_LONG_DOUBLE__ != 4 instead of.
>
Oh, sorry again, the above is incorrect.
Under my x86_64 Darwin, for m32, __SIZEOF_LONG_DOUBLE__ is 16.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69573
--- Comment #7 from Chen Gang ---
Can we check __APPLE_CC__ instead of __SIZEOF_LONG_DOUBLE__ ?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61053
--- Comment #11 from Chen Gang ---
(In reply to Martin Sebor from comment #10)
> On second thought, since the test isn't failing because _Alignas isn't
> working but rather because the DejaGnu directive in it is wrong, it this bug
> can be resolv
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69573
--- Comment #14 from Chen Gang ---
(In reply to Martin Sebor from comment #2)
> Patch posted for review:
> https://gcc.gnu.org/ml/gcc-patches/2016-01/msg02372.html
For your original patch, my test result is below (only compare 5 result files,
be
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69573
--- Comment #15 from Chen Gang ---
(In reply to Martin Sebor from comment #9)
> I built the x86_64-apple-darwin15.3.0 cross-compiler to better understand
> what the problem is but I don't see it. The cross compiler says the size
> and alignment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69573
--- Comment #18 from Chen Gang ---
(In reply to Martin Sebor from comment #17)
> Patch committed in r233564.
Sorry for replying late (I am in holiday during these days, and no any x86
environments). Your patch is OK to me. But I guess, providing
: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: gang.chen.5i5j at gmail dot com
Target Milestone: ---
Created attachment 38591
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=38591&
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71331
--- Comment #1 from Chen Gang ---
Oh, lucky enough! The diff below should be OK for this issue.
diff --git a/gcc/config/tilegx/tilegx.c b/gcc/config/tilegx/tilegx.c
index 06c832c..bc41105 100644
--- a/gcc/config/tilegx/tilegx.c
+++ b/gcc/config
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78222
--- Comment #1 from Chen Gang ---
The root cause is: in tilegx_gen_bundle, gcc will lose prev insn when it
deletes useless insns.
The related insns before tilegx_gen_bbundle (it is correct).
249 (insn:TI 71 68 75 4 (set (mem:DI (reg/f:DI 10 r10
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: gang.chen.5i5j at gmail dot com
Target Milestone: ---
Host: chroot ubuntu 15.10 under Android 5.1 x86_64
Target: tilegx
Build: Just building, use the latest version
1. Version
: target
Assignee: unassigned at gcc dot gnu.org
Reporter: gang.chen.5i5j at gmail dot com
[root@localhost c6x]# cat test.i
int oxu_driver_init(void)
{
*(volatile unsigned int *)(-1) = *(unsigned int *)(-1);
}
[root@localhost c6x]#
/upstream/release-c6x/libexec/gcc/tic6x
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65510
Chen Gang changed:
What|Removed |Added
CC||gang.chen.5i5j at gmail dot com
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65510
--- Comment #2 from Chen Gang ---
For test.i:
int oxu_driver_init(void)
{
*(volatile unsigned int *)(-1) = *(unsigned int *)(-1);
}
If test.i use a valid number (>= 0x10) or normal variable instead of "-1", it
will be OK (the insns are almost
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65510
--- Comment #3 from Chen Gang ---
(In reply to Chen Gang from comment #2)
> For test.i:
>
> int oxu_driver_init(void)
> {
> *(volatile unsigned int *)(-1) = *(unsigned int *)(-1);
> }
>
> If test.i use a valid number (>= 0x10) or normal variab
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65510
--- Comment #4 from Chen Gang ---
In gcc/config/c6x/c6x.md, if we remove (clober ...) for
movmisalign_store, it will be OK (just symmetric with
movmisalign_load which is OK).
(define_insn_and_split "movmisalign_store"
[(set (match_operand
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65510
--- Comment #5 from Chen Gang ---
After remove clobber (match_scratch ...), it will generate the correct assembly
code (I guess it is):
.file "test.i"
.c6xabi_attribute Tag_ABI_array_object_alignment, 0
.c6xabi_attribut
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: gang.chen.5i5j at gmail dot com
The code:
[root@localhost gcc]# cat lbalance.i
struct a {
short count;
};
struct reiserfs_de_head {
unsigned short deh_location
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: gang.chen.5i5j at gmail dot com
The code:
[root@localhost gcc]# cat stacktrace.i
register unsigned long current_frame_pointer asm("FP");
void save_stack_
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66620
Chen Gang changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65804
Chen Gang changed:
What|Removed |Added
CC||gang.chen.5i5j at gmail dot com
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63510
--- Comment #12 from Chen Gang ---
The patch passes "make check". I guess, it should be OK.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65804
--- Comment #2 from Chen Gang ---
It is about git commit "e52beba PR debug/54694". I am just consulting about it
in gcc-help mailing list.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54694
Chen Gang changed:
What|Removed |Added
CC||gang.chen.5i5j at gmail dot com
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63510
--- Comment #13 from Chen Gang ---
gcc version 6.0.0 20151023 (experimental) (GCC) has no this issue (I guess, the
reason is that it calls gimple_simplify instead of fold_binary).
For me, this issue can be closed.
Thanks.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63326
--- Comment #14 from Chen Gang ---
For gcc version 6.0.0 20151121 (experimental) (GCC), this issue is still
existant. I shall try to fix it within this month (2015-11-30).
Hope I can succeed.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63326
--- Comment #15 from Chen Gang ---
For me, comment #9 is the reasonable fixing way. In real world, C/C++
programmers will/should not use #pragma in this way (use #pragma in place of
the statement following an if, while, do, switch, or label).
An
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=42979
--- Comment #3 from Chen Gang ---
For "The taskwait directive may not be used in place of the statement following
an if, while, do, switch, or label."
if "if, while, do, switch, or label" is just flowed with a code block which let
"#pragma omp t
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63326
--- Comment #16 from Chen Gang ---
Our C++ has no this issue. For precisely saying: cc1 has the issue, but cc1plus
has no the issue (if use g++ build c programs, it has no issue; if use gcc
build c++ programs, it has no issue, either).
But still
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63326
--- Comment #17 from Chen Gang ---
I guess the diff below should be OK, I shall give a make check test.
diff --git a/gcc/c/c-parser.c b/gcc/c/c-parser.c
index 7b10764..257 100644
--- a/gcc/c/c-parser.c
+++ b/gcc/c/c-parser.c
@@ -5170,7 +5170
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63326
--- Comment #19 from Chen Gang ---
(In reply to Andrew Pinski from comment #18)
> (In reply to Chen Gang from comment #17)
> > I guess the diff below should be OK, I shall give a make check test.
>
> I would rather have the C front-end behavior
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63326
--- Comment #20 from Chen Gang ---
(In reply to Andrew Pinski from comment #18)
> (In reply to Chen Gang from comment #17)
> > I guess the diff below should be OK, I shall give a make check test.
>
> I would rather have the C front-end behavior
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63510
--- Comment #3 from Chen Gang ---
It still exists in gcc version 5.0.0 20141109 (experimental) (GCC), I shall try
to solve it.
Hope I can finish within 2 months.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63510
--- Comment #4 from Chen Gang ---
For gcc version 5.0.0 20150109 (experimental) (GCC), can not find this warnings
again.
So at present, for me, this bug can be closed.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58256
--- Comment #13 from Chen Gang ---
For gcc version 5.0.0 20150109 (experimental) (GCC), can not find this issue
again. So at present, we can close it.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58256
Chen Gang changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58400
--- Comment #9 from Chen Gang ---
(In reply to Jorn Wolfgang Rennecke from comment #8)
> Created attachment 32285 [details]
> patch made as an example how to debug gcc
>
> here is a patch - not regtested.
> you might also consider to put the thr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58400
Chen Gang changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58400
--- Comment #13 from Chen Gang ---
(In reply to Jeffrey A. Law from comment #12)
> Please leave the bug open until a fix is committed to the trunk.
OK, thanks.
Could any members help to commit the related patch to the trunk? I guess, I am
not t
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58400
--- Comment #16 from Chen Gang ---
(In reply to Jeffrey A. Law from comment #15)
> The patch needs to be reviewed. It's been a long time since I thought about
> the _STRICT variants of the REG_OK_ macros and how all that's supposed to
> work. I
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: gang.chen.5i5j at gmail dot com
The related source file:
# cat r100.i
#pragma pack()
struct r100_cs_cube_info {
char a[17];
unsigned int width;
unsigned int height
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65117
--- Comment #1 from Chen Gang ---
The root cause is in function 'find_reload' (at least it should be a real
cause):
- 'this_alternative_match_win' is not initialized before use it -- for the
first looping 0, it initializes 'this_alternative_matc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65117
--- Comment #2 from Chen Gang ---
Oh, sorry, one typo issue: 'this_alternative_match_win' is incorrect, it should
be 'this_alternative_win'.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63326
--- Comment #22 from Chen Gang ---
(In reply to Jakub Jelinek from comment #21)
> Author: jakub
> Date: Fri Nov 27 08:59:55 2015
> New Revision: 230999
>
> URL: https://gcc.gnu.org/viewcvs?rev=230999&root=gcc&view=rev
This way looks OK to me.
Assignee: unassigned at gcc dot gnu.org
Reporter: gang.chen.5i5j at gmail dot com
Target Milestone: ---
The latest gcc version introduce a new issue which has no issue before (e.g.
for gcc_5_3_0_release branch, it has no this issue).
The related file is gcc/testsuite/gcc.c-torture
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68917
--- Comment #2 from Chen Gang ---
(In reply to Bernd Edlinger from comment #1)
> does something like this help?
>
Oh, sorry for replying late.
I shall try to give a test within this month.
Thanks. :-)
> Index: tilegx.md
> ==
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68917
--- Comment #4 from Chen Gang ---
(In reply to Bernd Edlinger from comment #3)
> by the way, did you have also trouble to build the
> libgcc multilib configuration or did you --disable-multilib?
> this seems completely broken too...
Yes, I did.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68917
--- Comment #5 from Chen Gang ---
(In reply to Bernd Edlinger from comment #1)
> does something like this help?
>
OK, it has effect, :-)
And pass gcc testsuite. The related result is below:
[root@localhost contrib]# ./compare_tests ../../buil
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=28901
--- Comment #19 from Chen Gang ---
I build linux kernel with allyesconfig under x86_64 for linux-next tree
20160122. I can find some related cases for BUG28901 (but they are not quite
much), one case is below:
CC drivers/acpi/sbshc.o
In f
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=28901
--- Comment #20 from Chen Gang ---
(In reply to Chen Gang from comment #19)
> I build linux kernel with allyesconfig under x86_64 for linux-next tree
> 20160122. I can find some related cases for BUG28901 (but they are not quite
> much), one case
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65803
--- Comment #3 from Chen Gang ---
It is about JUMP_LABEL, gcc should set the JUMP_LABEL before use it. If we set
the label as soon as it is generated, it can build the issue code successfully.
diff --git a/gcc/config/bfin/bfin.c b/gcc/config/bf
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65803
--- Comment #4 from Chen Gang ---
Reference to gccint.pdf Page 268 for jump_isn, we know that JUMP_LABLE() must
be defined after optimization completed. In our case, we are just doing
optimization, and is almost finished, so we need set JUMP_LABL
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: gang.chen.5i5j at gmail dot com
Target Milestone: ---
[root@localhost gcc]# cat lpt_commit.i
struct ubifs_nnode {
int iip;
int level;
int nbranch[4];
};
struct ubifs_nnode
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66620
--- Comment #2 from Chen Gang ---
(In reply to Mikhail Maltsev from comment #1)
> Started with r208165.
OK, thanks. Really it is, it is valuable to me (it can generate the correct
insns for comparing). And also if remove "-fno-reorder-blocks", i
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66620
--- Comment #3 from Chen Gang ---
Created attachment 35862
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=35862&action=edit
The insns for our issue.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66620
--- Comment #4 from Chen Gang ---
Created attachment 35863
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=35863&action=edit
The correct insns without -fno-reorder-blocks
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66620
--- Comment #5 from Chen Gang ---
Created attachment 35864
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=35864&action=edit
The correct insns should be with -fno-reorder-blocks
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66620
--- Comment #6 from Chen Gang ---
1st call in hwloop_optimize() in gcc/config/bfin/bfin.c, the input insns are
correct (just the same as insns-should_be.log), but the output insns are
incorrect (just the same as insns-issue.log).
Then 2nd call i
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66620
--- Comment #7 from Chen Gang ---
(In reply to Chen Gang from comment #2)
> (In reply to Mikhail Maltsev from comment #1)
> > Started with r208165.
>
> OK, thanks. Really it is, it is valuable to me (it can generate the correct
> insns for compa
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66620
--- Comment #8 from Chen Gang ---
Created attachment 35866
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=35866&action=edit
Full insns for without "-fno-reorder-blocks".
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66620
--- Comment #9 from Chen Gang ---
After check the assembly result for the without "-fno-reorder-block", it is OK.
It is for lsetup optimization.
And for having "-fno-reorder-block", the insns are also correct, and after skip
the related assert()
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66620
--- Comment #10 from Chen Gang ---
Created attachment 35867
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=35867&action=edit
The result after skip the assert() for having "-fno-reorder-block"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66620
--- Comment #11 from Chen Gang ---
Created attachment 35868
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=35868&action=edit
The result when without "-fno-reorder-block"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66620
--- Comment #12 from Chen Gang ---
Created attachment 35869
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=35869&action=edit
The result before lsetup optimization
The lsetup information is below:
lsetup (loop_begin, loop_end) count.
R0 w
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63510
--- Comment #8 from Chen Gang ---
For the latest gcc, it still has this issue, I shall try to fix it during these
days (hope can fix it within this month).
Thanks.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63510
--- Comment #9 from Chen Gang ---
We need call warning_at() instead of warnings() in fold_overflow_warning() in
gcc/fold-const.c.
The related location parameter of warning_at() should be calculated, just like
another gcc files has done: e.g. gcc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63510
--- Comment #10 from Chen Gang ---
Need use gimple_location(stmt) for it. The stmt is the variable in
gcc/tree-ssa-sccvn.c before call fold_binary(). But unlucky, it is not passed
into fold_binary(), we can not get it directly.
After try a tempo
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63510
--- Comment #11 from Chen Gang ---
Created attachment 36267
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=36267&action=edit
The related fix patch for it.
The related fix patch for it: current input_location isn't precise for
reporting war
71 matches
Mail list logo
