[Bug c/98634] gcc 4.8.5 - 9.3.0 on target x86_64, when compile a exe and linking with a so, and exe's source file extern a var, the final exe has the var with the same name with the one in the so file

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98634 --- Comment #6 from zuogang --- (In reply to Jakub Jelinek from comment #5) > No RHEL or Fedora compilers are -pie by default, I hate when such important > details change silently under you. > Instead of changing the GCC default in these distros

[Bug c/98634] gcc 4.8.5 - 9.3.0 on target x86_64, when compile a exe and linking with a so, and exe's source file extern a var, the final exe has the var with the same name with the one in the so file

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98634 --- Comment #4 from zuogang --- (In reply to Jakub Jelinek from comment #1) > And the bug is? > This is due to copy relocations. > And, it has nothing to do with the compiler, it is how linker handles it. thanks for the reply, can you explain wh

[Bug c/98634] gcc 4.8.5 - 9.3.0 on target x86_64, when compile a exe and linking with a so, and exe's source file extern a var, the final exe has the var with the same name with the one in the so file

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98634 --- Comment #3 from zuogang --- (In reply to Andrew Pinski from comment #2) > This is called a copy relocation. I suspect the GCC you are using is > defaulting to PIE too. the gcc in centos 7 maybe is not pie-default? this verion is also has t

[Bug c/98634] New: gcc 4.8.5 - 9.3.0 on target x86_64, when compile a exe and linking with a so, and exe's source file extern a var, the final exe has the var with the same name with the one in the so

name with the one in the so file Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: c Assignee: unassigned at gcc dot gnu.org Reporter: zuogang at huawei do

[Bug c/82999] New: a func has two entrys: one inlined, another is normal

Component: c Assignee: unassigned at gcc dot gnu.org Reporter: zuogang at huawei dot com Target Milestone: --- centos 7 kernel: 3.10.0-693.2.2.el7.x86_64 global func tcp_v4_mtu_reduced has two entrys , one is inlined when called in the same file (such as func tcp_v4_err call

[Bug c/68329] [4.8 4.9]gcc using array index to accelerate loop running , why turn off at gcc 5.X

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68329 zuogang changed: What|Removed |Added Target||amd64 ppwerpc32 (tested) |

[Bug c/68329] New: [4.8 4.9]gcc using array index to accelerate loop running , why turn off at gcc 5.X

Severity: normal Priority: P3 Component: c Assignee: unassigned at gcc dot gnu.org Reporter: zuogang at huawei dot com Target Milestone: ---

[Bug target/52911] [4.5/4.6/4.7/4.8 Regression] gcc 4.7.0 (ppc32 e500mc) when compile a c file, after a lot of time, gcc failed and internal compiler error occurs.

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52911 --- Comment #6 from zuogang 2012-07-02 12:11:15 UTC --- (In reply to comment #5) > The 4.5 branch is being closed, adjusting target milestone. the bug is recured when using gcc4.7.1. [zoge@localhost test-exec-record]$ gcc -Wall -W -Wshadow -Isr

[Bug target/52911] [4.5/4.6/4.7/4.8 Regression] gcc 4.7.0 (ppc32 e500mc) when compile a c file, after a lot of time, gcc failed and internal compiler error occurs.

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52911 --- Comment #4 from zuogang 2012-05-30 02:59:22 UTC --- (In reply to comment #3) > The testcase needs reduction. 1: save the attached file into test-gcc47-c.c,then cd the folder contain the C file; 2: gcc -Wall -W -Wshadow -Isrc/headers -O3 -fun

[Bug target/52911] [4.5/4.6/4.7/4.8 Regression] gcc 4.7.0 (ppc32 e500mc) when compile a c file, after a lot of time, gcc failed and internal compiler error occurs.

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52911 --- Comment #2 from zuogang 2012-04-11 15:01:55 UTC --- use another gcc(4.5.1) runing on the ppc e500v2 box (ship with Sourcery pdts), everything is ok! root@P2020RDB:/dev/shm> gcc -v Reading specs from /usr/bin/../lib/gcc/powerpc-linux-gnu/4.5.

[Bug c/52911] New: gcc 4.7.0 (ppc32 e500mc) when compile a c file, after a lot of time, gcc failed and internal compiler error occurs.

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52911 Bug #: 52911 Summary: gcc 4.7.0 (ppc32 e500mc) when compile a c file, after a lot of time, gcc failed and internal compiler error occurs. Classification: Unclassified Pr

[Bug middle-end/38274] why the option "-fstack-protector-all" doesn't works?

--- Comment #2 from zuogang at huawei dot com 2008-12-01 10:13 --- (In reply to comment #1) > Works for me with the trunk on i386-darwin8.11: > [236:~] apinski% ~/local-gcc/bin/gcc t.c -fstack-protector-all > [236:~] apinski% ./a.out > ?,a:-1,b2 > *** stack sm

[Bug c/38274] New: why the option "-fstack-protector-all" doesn't works?

n "-fstack-protector-all" doesn't works? Product: gcc Version: 4.1.2 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: zuogang at h

[Bug debug/26908] -g3 (-ggdb3) emits broken calls to asm-defined functions

--- Comment #5 from zuogang at huawei dot com 2008-11-21 02:15 --- (In reply to comment #4) > *** Bug 38186 has been marked as a duplicate of this bug. *** I post the bug 38186; I want to know why the asm-defined func is placed in .debug_macinfo section, is it correct? info from

[Bug c/38187] New: when using gcc compile the code with option "-g3", I find the inline assemble code are palced in section .debug_macinfo

portedBy: zuogang at huawei dot com GCC host triplet: dell workstation x http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38187

[Bug c/38186] New: when using gcc compile the code with option "-g3", I find the inline assemble code are palced in section .debug_macinfo

portedBy: zuogang at huawei dot com GCC host triplet: dell workstation x http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38186