[Bug other/70428] -fdebug-prefix-map did not support to remap sources with relative path
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70428 hongxu jia changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |INVALID --- Comment #4 from hongxu jia --- (In reply to jos...@codesourcery.com from comment #3) > On Wed, 30 Mar 2016, hongxu.jia at windriver dot com wrote: > > > Do you mean the combination of using *"relative path" source to compile* > > and *"absolute path" in -fdebug-prefix-map to remap* is not proper? > > It's perfectly proper. But the absolute path passed to -fdebug-prefix-map > must be the actual pwd of the build or an absolute path passed to the > compiler, or a prefix of one of those. It must not be some canonicalized > version that was never seen by the compiler and combines fragments of > paths handled differently by the compiler. I don't think the compiler > ever does anything with a path such as /folk/hjia/test1/test2, or ever > interprets what "../../" means in the path to source files. You need to > pass /folk/hjia/dir1/dir2 or a prefix thereof to -fdebug-prefix-map in > your example, and the resulting debug info will still contain references > to ../../test1/test2/test.c (so you need to make sure that the remapped > path is one relative to which ../../test1/test2/test.c is valid, on the > system where the debug info is interpreted). Ok, thanks to point it out
[Bug other/70428] -fdebug-prefix-map did not support to remap sources with relative path
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70428 --- Comment #2 from hongxu jia --- (In reply to jos...@codesourcery.com from comment #1) > I don't think -fdebug-prefix-map is meant to cover this case; you're meant > to use it with paths in the form in which they appear in debug info, which > means passing such an option with the pwd (and options with absolute -I > paths etc.), not an option with a combination of the pwd and a path passed > to the compiler. Do you mean the combination of using *"relative path" source to compile* and *"absolute path" in -fdebug-prefix-map to remap* is not proper? In my case, there are lots of sources with relative/absolute paths, and we want to set '-fdebug-prefix-map' to remap in globally. Rather than set specific '-fdebug-prefix-map' according to the path of sources (relative or absolute). BTW, I come from OpenEmbedded community (https://www.yoctoproject.org/), and we use the powerful gcc for cross compilation. We use -fdebug-prefix-map to remap build dir to target dir, so we could use gdb to debug on target and it could work with sources. //Hongxu
[Bug other/70428] New: -fdebug-prefix-map did not support to remap sources with relative path
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70428
Bug ID: 70428
Summary: -fdebug-prefix-map did not support to remap sources
with relative path
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: other
Assignee: unassigned at gcc dot gnu.org
Reporter: hongxu.jia at windriver dot com
Target Milestone: ---
1. Prepare sources and build dir
$ pwd
/folk/hjia
$ mkdir dir1/dir2 test1/test2/ -p
$ cat > test1/test2/test.c << ENDOF
#include "test.h"
int main(int argc, char *argv[])
{
func();
return 0;
}
ENDOF
$ cat > test1/test2/test.h << ENDOF
void func()
{
return;
}
ENDOF
$ cd dir1/dir2
2. Enter build dir to compile with relative path sources
$ gcc ../../test1/test2/test.c -g -o test.o
$ objdump -g test.o | less
<0>: Abbrev Number: 1 (DW_TAG_compile_unit)
DW_AT_producer: (indirect string, offset: 0x47): GNU C 4.8.4
-mtune=generic -march=x86-64 -g -fstack-protector
<10> DW_AT_language: 1(ANSI C)
<11> DW_AT_name: (indirect string, offset: 0x5):
../../test1/test2/test.c
<15> DW_AT_comp_dir: (indirect string, offset: 0x1e):
/folk/hjia/dir1/dir2
Contents of the .debug_str section:
3. Compile with option -fdebug-prefix-map, it could not remap sources with
relative path
$ gcc ../../test1/test2/test.c
-fdebug-prefix-map=/folk/hjia/test1/test2=/usr/src -g -o test.o
$ objdump -g test.o | less
<0>: Abbrev Number: 1 (DW_TAG_compile_unit)
DW_AT_producer: (indirect string, offset: 0x47): GNU C 4.8.4
-mtune=generic -march=x86-64 -g
-fdebug-prefix-map=/folk/hjia/test1/test2=/usr/src -fstack-protector
<10> DW_AT_language: 1(ANSI C)
<11> DW_AT_name: (indirect string, offset: 0x5):
../../test1/test2/test.c
<15> DW_AT_comp_dir: (indirect string, offset: 0x1e):
/folk/hjia/dir1/dir2
What we expected is:
<11> DW_AT_name: (indirect string, offset: 0x5): /usr/src/test.c
<15> DW_AT_comp_dir: (indirect string, offset: 0x15):
/folk/hjia/dir1/dir2
[Bug other/70268] add option -ffile-prefix-map to map one directory name (old) to another (new) in __FILE__, __BASE_FILE__and __builtin_FILE()
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70268 --- Comment #6 from hongxu jia --- (In reply to rguent...@suse.de from comment #5) > On Thu, 17 Mar 2016, hongxu.jia at windriver dot com wrote: > > > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70268 > > > > --- Comment #3 from hongxu jia --- > > (In reply to Richard Biener from comment #2) > > > IMHO it doesn't make sense to prune system header paths here and having > > > them > > > is desired. > > > > Hi Richard, > > > > It is just a simple example to explain the requirements. > > > > In our OpenEmbedded project, we do many cross complication, > > and have very complex build path. > > > > Here is the actual use of option '-fdebug-prefix-map' in our project: > > > > DEBUG_FLAGS="-g -feliminate-unused-debug-types > > -fdebug-prefix-map=/buildarea/raid0/hjia/build-20160316-yocto-buildpath-2/tmp/work/core2-64-poky-linux/service/0.1-r0/service-0.1=/usr/src/service > > -fdebug-prefix-map=/buildarea/raid0/hjia/build-20160316-yocto-buildpath-2/tmp/work/core2-64-poky-linux/service/0.1-r0/service-0.1=/usr/src/service > > -fdebug-prefix-map=/buildarea/raid0/hjia/build-20160316-yocto-buildpath-2/tmp/sysroots/x86_64-linux= > > -fdebug-prefix-map=/buildarea/raid0/hjia/build-20160316-yocto-buildpath-2/tmp/sysroots/qemux86-64= > > " > > I see. Care to propose a patch then? Yes, also sent to gcc-patc...@gcc.gnu.org for review //Hongxu
[Bug other/70268] New: add option -ffile-prefix-map to map one directory name (old) to another (new) in __FILE__, __BASE_FILE__and __builtin_FILE()
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70268
Bug ID: 70268
Summary: add option -ffile-prefix-map to map one directory name
(old) to another (new) in __FILE__, __BASE_FILE__and
__builtin_FILE()
Product: gcc
Version: 6.0
Status: UNCONFIRMED
Severity: enhancement
Priority: P3
Component: other
Assignee: unassigned at gcc dot gnu.org
Reporter: hongxu.jia at windriver dot com
Target Milestone: ---
Hi all,
I come from OpenEmbedded community (https://www.yoctoproject.org/),
and we use the powerful gcc for cross compilation. Previously, with
the help of Richard Biener and Jakub Jelinek, PR69821 was fixed which
do not expose the build path to others while '-g' used.
But there is another similar issue, while '__FILE__' used, this macro
expands to the name of the current input file which has build path.
I know the tradition solution is using relative path to compile.
(Such as instead of 'gcc /full/path/to/test.c',
try 'cd /full/path/to; gcc test.c; cd -;')
But if '__FILE__' exists in included header file and the header
file in standard system directories, the above way doesn't work.
Here is my test case:
---
1. Prepare a C source file and a C include file
$ cat << ENDOF > test.c
#include
#include
int main(int argc, char *argv[])
{
printf("__FILE__ %s\n", __FILE__);
test();
return 0;
}
ENDOF
$ cat << ENDOF > test.h
#include
void test(void)
{
printf("__FILE__ %s\n", __FILE__);
return;
}
ENDOF
2. Move include file to standard system directory.
$ sudo mv test.h /usr/include/
3. Compile C source file
$ gcc ./test.c -o test
4. Execute and the output shows full path header file.
$ ./test
__FILE__ ./test.c
__FILE__ /usr/include/test.h
---
[Bug other/70268] add option -ffile-prefix-map to map one directory name (old) to another (new) in __FILE__, __BASE_FILE__and __builtin_FILE()
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70268 --- Comment #1 from hongxu jia --- So I suggest gcc could provide a option '-ffile-prefix-map==' to map directory in __FILE__ and replace it with directory. It is similar to '-fdebug-prefix-map==', but the latter is used for DWARF, and the newly added option only works on '__FILE__', '__BASE_FILE__' and '__builtin_FILE()' --- 5. Compile C source file with '-ffile-prefix-map' $ gcc ./test.c -ffile-prefix-map=/usr/include= -o test 4. Execute and the header file is not pull path. $ ./test __FILE__ ./test.c __FILE__ /test.h ---
[Bug other/70268] add option -ffile-prefix-map to map one directory name (old) to another (new) in __FILE__, __BASE_FILE__and __builtin_FILE()
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70268 --- Comment #4 from hongxu jia --- Created attachment 37995 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=37995=edit Implement patch
[Bug other/70268] add option -ffile-prefix-map to map one directory name (old) to another (new) in __FILE__, __BASE_FILE__and __builtin_FILE()
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70268 --- Comment #3 from hongxu jia --- (In reply to Richard Biener from comment #2) > IMHO it doesn't make sense to prune system header paths here and having them > is desired. Hi Richard, It is just a simple example to explain the requirements. In our OpenEmbedded project, we do many cross complication, and have very complex build path. Here is the actual use of option '-fdebug-prefix-map' in our project: DEBUG_FLAGS="-g -feliminate-unused-debug-types -fdebug-prefix-map=/buildarea/raid0/hjia/build-20160316-yocto-buildpath-2/tmp/work/core2-64-poky-linux/service/0.1-r0/service-0.1=/usr/src/service -fdebug-prefix-map=/buildarea/raid0/hjia/build-20160316-yocto-buildpath-2/tmp/work/core2-64-poky-linux/service/0.1-r0/service-0.1=/usr/src/service -fdebug-prefix-map=/buildarea/raid0/hjia/build-20160316-yocto-buildpath-2/tmp/sysroots/x86_64-linux= -fdebug-prefix-map=/buildarea/raid0/hjia/build-20160316-yocto-buildpath-2/tmp/sysroots/qemux86-64= " //Hongxu
[Bug other/69821] -fdebug-prefix-map doesn't affect gcc command line switches in DWARF DW_AT_producer.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69821 --- Comment #8 from hongxu jia --- (In reply to Jakub Jelinek from comment #7) > It is not a regression and is user visible change, so I think changing it > just in GCC 6 is sufficient. Got it, thanks for pointing it out. I will backport to our Yocto. //Hongxu
[Bug other/69821] -fdebug-prefix-map doesn't affect gcc command line switches in DWARF DW_AT_producer.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69821 --- Comment #3 from hongxu jia --- (In reply to Andrew Pinski from comment #2) > Patches should be sent to gcc-patches@. Got it //Hongxu
[Bug other/69821] -fdebug-prefix-map doesn't affect gcc command line switches in DWARF DW_AT_producer.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69821 --- Comment #1 from hongxu jia --- Created attachment 37691 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=37691=edit add option Compile without this fix: objdump -g packages-split/lib32-glibc-dev/usr/lib/gcrt1.o ... |<5f> DW_AT_producer: (indirect string, offset: 0x1b): GNU C99 5.3.0 -m32-march=core2 -mtune=core2 -msse3 -mfpmath=sse -mpreferred-stack-boundary=4 -g -O2 -std=gnu99 -fgnu89-inline -fdebug-prefix-map=/buildarea/raid0/hjia/buil d-20160127-yocto-buildpath-2/tmp/sysroots/lib32-qemux86-64= -feliminate-unused-debug-types -fmerge-all-constants -frounding-math -ftls-model=initial-exec ... Compile with this fix: objdump -g packages-split/lib32-glibc-dev/usr/lib/gcrt1.o ... |<5f> DW_AT_producer: (indirect string, offset: 0xa1): GNU C99 5.3.0 -m32 -march=core2 -mtune=core2 -msse3 -mfpmath=sse -mpreferred-stack-boundary=4 -g -O2 -std=gnu99 -fgnu89-inline -feliminate-unused-debug-types -fmerge-all-constants -frounding-math -ftls-model=initial-exec ...
[Bug other/69821] New: -fdebug-prefix-map doesn't affect gcc command line switches in DWARF DW_AT_producer.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69821 Bug ID: 69821 Summary: -fdebug-prefix-map doesn't affect gcc command line switches in DWARF DW_AT_producer. Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: other Assignee: unassigned at gcc dot gnu.org Reporter: hongxu.jia at windriver dot com Target Milestone: --- Hi all, I come from OpenEmbedded community (https://www.yoctoproject.org/), thanks the powerful gcc, it helps us to do lots of compiling staff. While cross compilation, we add '-g' to record debugging info, and lots of build path existed in debugging info. We do not want to expose the build path to others. So add '-fdebug-prefix-map=old=new' to replace the build path with target path. But the option '-fdebug-prefix-map=old=new' itself which included build path still exists in gcc command line switches in DWARF DW_AT_producer. I know we could use '-gno-record-gcc-switches' to not record all gcc command line switches in DWARF DW_AT_producer. But we would like to keep the others and only remove '-fdebug-prefix-map=old=new'. So I suggested to add a new option '-gno-record-debug-prefix-map' which don't record '-fdebug-prefix-map' in gcc command line switches in DWARF DW_AT_producer. Thanks Hongxu
[Bug debug/60643] ICE with -O1 and -g on mips (internal compiler error: in dwarf2out_var_location, at dwarf2out.c:20810)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60643 hongxu jia hongxu.jia at windriver dot com changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #15 from hongxu jia hongxu.jia at windriver dot com --- I have done the test, the defect has fixed //Hongxu
[Bug debug/60643] ICE with -O1 and -g on mips (internal compiler error: in dwarf2out_var_location, at dwarf2out.c:20810)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60643 hongxu jia hongxu.jia at windriver dot com changed: What|Removed |Added Status|RESOLVED|UNCONFIRMED Resolution|WORKSFORME |--- --- Comment #13 from hongxu jia hongxu.jia at windriver dot com --- Khem Raj gave more details, so I reopen it (but without that option, choose unconfirmed to instead)
[Bug bootstrap/61899] gcc/Makefile.in: compile failure occasionally while parallel make enabled
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61899 --- Comment #2 from hongxu jia hongxu.jia at windriver dot com --- The previous fix is incorrect, it caused other build failure. Here is the new solution: The gcc-ar.o, gcc-nm.o, gcc-ranlib.o and errors.o included config.h which was a generated file. But no explicity rule to clarify the dependency. There was potential building failure while parallel make. For gcc-ar.o, gcc-nm.o and gcc-ranlib.o, they were compiled from one C source file gcc-ar.c, we add them to ALL_HOST_BACKEND_OBJS, so the '$(ALL_HOST_OBJS) : | $(generated_files)' rule could work for these objects. For errors.o, it is part of gengtype, and the gengtype generator program is special: Two versions are built. One is for the build machine, and one is for the host. We refered what gengtype-parse.o did (which also is part of gengtype). Signed-off-by: Hongxu Jia hongxu@windriver.com --- gcc/Makefile.in | 7 ++- 1 file changed, 6 insertions(+), 1 deletion(-) diff --git a/gcc/Makefile.in b/gcc/Makefile.in index a726109..cdaa406 100644 --- a/gcc/Makefile.in +++ b/gcc/Makefile.in @@ -1491,13 +1491,16 @@ OBJS-libcommon-target = $(common_out_object_file) prefix.o params.o \ opts.o opts-common.o options.o vec.o hooks.o common/common-targhooks.o \ hash-table.o file-find.o +# Objects compiled from one C source file gcc-ar.c +OBJS-gcc-ar = gcc-ar.o gcc-nm.o gcc-ranlib.o + # This lists all host objects for the front ends. ALL_HOST_FRONTEND_OBJS = $(foreach v,$(CONFIG_LANGUAGES),$($(v)_OBJS)) ALL_HOST_BACKEND_OBJS = $(GCC_OBJS) $(OBJS) $(OBJS-libcommon) \ $(OBJS-libcommon-target) @TREEBROWSER@ main.o c-family/cppspec.o \ $(COLLECT2_OBJS) $(EXTRA_GCC_OBJS) $(GCOV_OBJS) $(GCOV_DUMP_OBJS) \ - $(GCOV_TOOL_OBJS) lto-wrapper.o collect-utils.o + $(GCOV_TOOL_OBJS) lto-wrapper.o collect-utils.o $(OBJS-gcc-ar) # This lists all host object files, whether they are included in this # compilation or not. @@ -2447,6 +2450,8 @@ gengtype-lex.o: $(CONFIG_H) $(BCONFIG_H) CFLAGS-gengtype-lex.o += -DGENERATOR_FILE build/gengtype-lex.o: $(BCONFIG_H) +errors.o : $(CONFIG_H) + gengtype-parse.o build/gengtype-parse.o : gengtype-parse.c gengtype.h \ $(SYSTEM_H) gengtype-parse.o: $(CONFIG_H)
[Bug c/61899] New: gcc/Makefile.in: compile failure occasionally while parallel make enabled
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61899 Bug ID: 61899 Summary: gcc/Makefile.in: compile failure occasionally while parallel make enabled Product: gcc Version: 4.10.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c Assignee: unassigned at gcc dot gnu.org Reporter: hongxu.jia at windriver dot com Created attachment 33182 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=33182action=edit compile failure log Reproduce steps 1. Manually modify gcc/Makefile.in to delay the generation of config.h: ... diff --git a/gcc/Makefile.in b/gcc/Makefile.in index c4daf69..c502898 100644 --- gcc-4.9.0/gcc/Makefile.in +++ gcc-4.9.0/gcc/Makefile.in @@ -1622,9 +1622,12 @@ tm.h: cs-tm.h ; @true tm_p.h: cs-tm_p.h ; @true cs-config.h: Makefile + @echo start to generate config.h `date` + sleep 10 TARGET_CPU_DEFAULT= \ HEADERS=$(host_xm_include_list) DEFINES=$(host_xm_defines) \ $(SHELL) $(srcdir)/mkconfig.sh config.h + @echo config.h generated `date` cs-bconfig.h: Makefile TARGET_CPU_DEFAULT= \ ... 2. configure and compile gcc failure ... ../../gcc-4.10-20140720/gcc/hwint.h:237:8: error: ‘HOST_WIDE_INT’ does not name a type ../../gcc-4.10-20140720/gcc/hwint.h:241:15: error: ‘HOST_WIDE_INT’ does not name a type ../../gcc-4.10-20140720/gcc/hwint.h:256:1: error: expected initializer before ‘zext_hwi’ make[3]: *** [errors.o] Error 1 ... ../../gcc-4.10-20140720/gcc/hwint.h:237:8: error: ‘HOST_WIDE_INT’ does not name a type ../../gcc-4.10-20140720/gcc/hwint.h:241:15: error: ‘HOST_WIDE_INT’ does not name a type ../../gcc-4.10-20140720/gcc/hwint.h:256:1: error: expected initializer before ‘zext_hwi’ make[3]: *** [gcc-ar.o] Error 1 ...
[Bug c/61899] gcc/Makefile.in: compile failure occasionally while parallel make enabled
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61899 --- Comment #1 from hongxu jia hongxu.jia at windriver dot com --- Here is my solution: gcc/Makefile.in: add missing errors.o/gcc-ar.o/gcc-nm.o/gcc-ranlib.o to OBJS While parallel make, the '$(ALL_HOST_OBJS) : | $(generated_files)' rule doesn't work for these missing objects. And there was potential compile failure. Signed-off-by: Hongxu Jia hongxu@windriver.com --- gcc/Makefile.in | 4 1 file changed, 4 insertions(+) diff --git a/gcc/Makefile.in b/gcc/Makefile.in index a726109..e753ebd 100644 --- a/gcc/Makefile.in +++ b/gcc/Makefile.in @@ -1224,6 +1224,7 @@ OBJS = \ dwarf2out.o \ emit-rtl.o \ et-forest.o \ + errors.o \ except.o \ explow.o \ expmed.o \ @@ -1233,6 +1234,9 @@ OBJS = \ fold-const.o \ function.o \ fwprop.o \ + gcc-ar.o \ + gcc-nm.o \ + gcc-ranlib.o \ gcse.o \ ggc-common.o \ gimple.o \
[Bug debug/60643] ICE with -O1 and -g on mips (internal compiler error: in dwarf2out_var_location, at dwarf2out.c:20810)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60643 --- Comment #10 from hongxu jia hongxu.jia at windriver dot com --- (In reply to Andrew Pinski from comment #8) Works for me with an unmodified GCC 4.8.2. So please try removing all of the Open-embedded patches since one of them is causing this bug. I have removed all of the Open-embedded patches, and cross-compiling mip-gcc on x86-64 host. But the problem still existed. //Hongxu
[Bug debug/60643] New: ICE with -O1 and -g on mips (internal compiler error: in dwarf2out_var_location, at dwarf2out.c:20810)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60643
Bug ID: 60643
Summary: ICE with -O1 and -g on mips (internal compiler error:
in dwarf2out_var_location, at dwarf2out.c:20810)
Product: gcc
Version: 4.8.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: debug
Assignee: unassigned at gcc dot gnu.org
Reporter: hongxu.jia at windriver dot com
Created attachment 32440
-- http://gcc.gnu.org/bugzilla/attachment.cgi?id=32440action=edit
the config.log of mips-poky-linux-gcc
I have hit a ICE and could reduce it to the following minimal example:
1. Only the size of array assigned with 2 caused the issue:
$ cat mipgcc-test.c END
#include stdio.h
#define ARRAY_SIZE_MAX 2
int main (int argc, char **argv)
{
char *pStrArry[ARRAY_SIZE_MAX] = {hello};
int i = 0;
while(pStrArry[i] iARRAY_SIZE_MAX)
{
printf(%s\n, pStrArry[i]);
i++;
}
return 0;
}
END
2. Only -O1 and -g on mips caused the issue:
$ mips-poky-linux-gcc -O1 -g -o mipgcc-test mipgcc-test.c
mipgcc-test.c: In function 'main':
mipgcc-test.c:18:1: internal compiler error: in dwarf2out_var_location, at
dwarf2out.c:20810
}
^
Please submit a full bug report,
with preprocessed source if appropriate.
See http://gcc.gnu.org/bugs.html for instructions
[Bug debug/60643] ICE with -O1 and -g on mips (internal compiler error: in dwarf2out_var_location, at dwarf2out.c:20810)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60643 hongxu jia hongxu.jia at windriver dot com changed: What|Removed |Added Target||mips-wrs-linux Host||x86_64-linux Build||x86_64-linux --- Comment #1 from hongxu jia hongxu.jia at windriver dot com --- Build Configuration: BUILD_SYS = x86_64-linux NATIVELSBSTRING = Ubuntu-12.04 TARGET_SYS= mips-wrs-linux
[Bug debug/60643] ICE with -O1 and -g on mips (internal compiler error: in dwarf2out_var_location, at dwarf2out.c:20810)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60643 --- Comment #4 from hongxu jia hongxu.jia at windriver dot com --- Created attachment 32441 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=32441action=edit the open-embedded patches
