[Bug sanitizer/61071] Compiling with AddressSanitizer with 4.9 breaks printng some variables in gdb
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61071 --- Comment #1 from Krzysztof Kundzicz --- Same with gcc 4.9.1 + gdb 7.7.1
[Bug fortran/61881] ICE in gfc_conv_intrinsic_to_class with assumed-rank CLASS(*)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61881 --- Comment #3 from Tobias Burnus --- The draft patch does not fully work: a) "class._data = desc" assignment is missing tmp = gfc_build_addr_expr (NULL_TREE, tmp); plus the moved gfc_add_modify works in the scalar case; for the array case, one additionally needs a prior gfc_conv_class_to_class call. b) It mishandles class(*) :: foo[*] dummy arguments for which wrongly an array descriptor is passed, one needs an additional && class_ts.u.derived->components->as->type == AS_ASSUMED_RANK
[Bug fortran/61881] ICE in gfc_conv_intrinsic_to_class with assumed-rank CLASS(*)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61881 --- Comment #2 from Tobias Burnus --- Draft patch: --- a/gcc/fortran/trans-expr.c +++ b/gcc/fortran/trans-expr.c @@ -591,4 +591,10 @@ gfc_conv_intrinsic_to_class (gfc_se *parmse, gfc_expr *e, gfc_conv_expr_reference (parmse, e); - tmp = fold_convert (TREE_TYPE (ctree), parmse->expr); - gfc_add_modify (&parmse->pre, ctree, tmp); + if (class_ts.u.derived->components->as && e->rank == 0) +tmp = gfc_conv_scalar_to_descriptor (parmse, parmse->expr, + gfc_expr_attr (e)); + else +{ + tmp = fold_convert (TREE_TYPE (ctree), parmse->expr); + gfc_add_modify (&parmse->pre, ctree, tmp); +} } @@ -599,3 +605,10 @@ gfc_conv_intrinsic_to_class (gfc_se *parmse, gfc_expr *e, gfc_conv_expr_descriptor (parmse, e); - gfc_add_modify (&parmse->pre, ctree, parmse->expr); + if (class_ts.u.derived->components->as->rank != e->rank) +{ + tmp = fold_build1_loc (input_location, VIEW_CONVERT_EXPR, + TREE_TYPE (ctree), parmse->expr); + gfc_add_expr_to_block (&parmse->pre, tmp); +} + else +gfc_add_modify (&parmse->pre, ctree, parmse->expr); }
[Bug ipa/61085] [4.9/4.10 Regression] wrong code with -O2 -fno-early-inlining (maybe wrong devirtualization)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61085 --- Comment #10 from Zdenek Sojka --- (In reply to Richard Biener from comment #9) > Can you open a new bug for that? Opened PR61884 for that.
[Bug ipa/61884] New: [4.10 Regression] g++.dg/ipa/pr61085.C FAILs with -Os
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61884 Bug ID: 61884 Summary: [4.10 Regression] g++.dg/ipa/pr61085.C FAILs with -Os Product: gcc Version: 4.10.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: ipa Assignee: unassigned at gcc dot gnu.org Reporter: zsojka at seznam dot cz Created attachment 33174 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=33174&action=edit preprocessed source (g++.dg/ipa/pr61085.C) Output: $ g++ -Os pr61085.ii $ ./a.out Aborted valgrind doesn't output any errors Tested revisions: 4.10 r212913 - FAIL 4.9 r212703 - OK 4.8 r212702 - OK
[Bug regression/61548] [4.10 Regression] FAIL: gcc.dg/tls/alias-1.c (internal compiler error)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61548 --- Comment #7 from wangzheyu --- I have a simpler test case to reproduce this bug, it should be an old bug for the tree-emutls pass. The way this pass mapping the control vars and tls vars hasn't consider that there may more than one alias for a tls var. For target supports tls, the code can compile successfully, but the target doesn't support tls will fail. struct __res_state { char x[123]; }; __thread struct __res_state foo; extern __thread struct __res_state bar __attribute__ ((alias ("foo"))); extern __thread struct __res_state baz __attribute__ ((alias ("foo"))); int main() { bar.x[0] = 0; baz.x[1] = 1; return 0; }
[Bug regression/61548] [4.10 Regression] FAIL: gcc.dg/tls/alias-1.c (internal compiler error)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61548 Andrew Pinski changed: What|Removed |Added Target Milestone|--- |4.10.0 Summary|FAIL: gcc.dg/tls/alias-1.c |[4.10 Regression] FAIL: |(internal compiler error) |gcc.dg/tls/alias-1.c ||(internal compiler error)
[Bug target/61883] [4.10 Regression]ICE for gcc.dg/tls/alias-1.c on arm target
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61883 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |DUPLICATE --- Comment #2 from Andrew Pinski --- Dup of bug 61548. *** This bug has been marked as a duplicate of bug 61548 ***
[Bug regression/61548] FAIL: gcc.dg/tls/alias-1.c (internal compiler error)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61548 Andrew Pinski changed: What|Removed |Added CC||tony.wang at arm dot com --- Comment #6 from Andrew Pinski --- *** Bug 61883 has been marked as a duplicate of this bug. ***
[Bug target/61883] [4.10 Regression]ICE for gcc.dg/tls/alias-1.c on arm target
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61883 --- Comment #1 from wangzheyu --- For target don't support tls, the above simple test case will fail for the same reason of gcc.dg/tls/alias-1.c.
[Bug target/61883] New: [4.10 Regression]ICE for gcc.dg/tls/alias-1.c on arm target
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61883 Bug ID: 61883 Summary: [4.10 Regression]ICE for gcc.dg/tls/alias-1.c on arm target Product: gcc Version: 4.10.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: tony.wang at arm dot com The trunk will ICE when user declare tls variables with alias name on run-time need to generate emutls variables. How to reproduce: /work/tonwan01/test_alias$ /work/tonwan01/gcc/gcc-arm-none-eabi-4_9-2014q2-20140515/install-native/lib/gcc/arm-none-eabi/4.10.0/cc1 -quiet -v -D_USES_INITFINI_ alias-1-clean.c -quiet -dumpbase alias-1-clean.c -mthumb -mcpu=cortex-m0 -auxbase-strip alias-1.exe -version -o /tmp/cc0AHQ0g.s alias-1.c:24:3: internal compiler error: Segmentation fault _attribute_ ((visibility ("hidden"))); ^ 0xbdde7f crash_signal /work/tonwan01/gcc/gcc-arm-none-eabi-4_9-2014q2-20140515/src/gcc/gcc/toplev.c:337 0x78b390 symtab_alias_target /work/tonwan01/gcc/gcc-arm-none-eabi-4_9-2014q2-20140515/src/gcc/gcc/cgraph.h:1535 0x78d629 verify_symtab_base(symtab_node*) /work/tonwan01/gcc/gcc-arm-none-eabi-4_9-2014q2-20140515/src/gcc/gcc/symtab.c:830 0x78d7bb verify_symtab_node(symtab_node*) /work/tonwan01/gcc/gcc-arm-none-eabi-4_9-2014q2-20140515/src/gcc/gcc/symtab.c:863 0x78d823 verify_symtab() /work/tonwan01/gcc/gcc-arm-none-eabi-4_9-2014q2-20140515/src/gcc/gcc/symtab.c:881 0x9e6e85 symtab_remove_unreachable_nodes(bool, _IO_FILE*) /work/tonwan01/gcc/gcc-arm-none-eabi-4_9-2014q2-20140515/src/gcc/gcc/ipa.c:592 0x7a09f3 ipa_passes /work/tonwan01/gcc/gcc-arm-none-eabi-4_9-2014q2-20140515/src/gcc/gcc/cgraphunit.c:2065 0x7a0d70 compile() /work/tonwan01/gcc/gcc-arm-none-eabi-4_9-2014q2-20140515/src/gcc/gcc/cgraphunit.c:2187 0x7a107c finalize_compilation_unit() /work/tonwan01/gcc/gcc-arm-none-eabi-4_9-2014q2-20140515/src/gcc/gcc/cgraphunit.c:2342 0x60ba71 c_write_global_declarations() /work/tonwan01/gcc/gcc-arm-none-eabi-4_9-2014q2-20140515/src/gcc/gcc/c/c-decl.c:10452 The reason for this bug is that in the tree-emutls.c pass, the code imply a default sequence of tls symbol and its corresponding control symbol. Some patch now move the symtab node generation to a very early stage, so the sequence of the node in varpool changed which leads to the wrong mapping of tls var and control var. For case gcc.dg/tls/alias-1.c Before: tls_vars[0]:bar(alias foo) tls_vars[1]:foo control_vars[0]:_emutls_v.foo control_vars[1]:_emutls_v.bar(alias _emutls_v.foo) So when generate the reference list of main, the actual reference of bar would be _emutls_v.foo which is correct. After: tls_vars[1]:bar(alias foo) tls_vars[0]:foo control_vars[0]:_emutls_v.foo control_vars[1]:_emutls_v.bar(alias _emutls_v.foo) The reference list of main will point to the alias symbol node _emutls_v.bar, which finally cause the segment fault. I also a simpler test case to reproduce this bug, it should be an old bug for the tree-emutls pass. The way this pass mapping the control vars and tls vars hasn't consider that there may more than one alias for a tls var. For run time support tls, the code can compile successfully. struct __res_state { char x[123]; }; __thread struct __res_state foo; extern __thread struct __res_state bar __attribute__ ((alias ("foo"))); extern __thread struct __res_state baz __attribute__ ((alias ("foo"))); int main() { bar.x[0] = 0; baz.x[1] = 1; return 0; }
[Bug debug/55641] debug info for the type of a reference declared with a typedef has spurious 'const'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55641 Tom Tromey changed: What|Removed |Added CC||tromey at gcc dot gnu.org --- Comment #8 from Tom Tromey --- You don't need a typedef: int x; int &g(x); <1><37>: Abbrev Number: 2 (DW_TAG_variable) <38> DW_AT_name: g <3a> DW_AT_decl_file : 1 <3b> DW_AT_decl_line : 2 <3c> DW_AT_type: <0x4a> <40> DW_AT_external: 1 <40> DW_AT_location: 9 byte block: 3 0 0 0 0 0 0 0 0 (DW_OP_addr: 0) <1><4a>: Abbrev Number: 4 (DW_TAG_const_type) <4b> DW_AT_type: <0x4f> [...]
[Bug testsuite/61826] [4.10 regression] gcc.dg/pr44024.c UNRESOLVED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61826 Uroš Bizjak changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Component|middle-end |testsuite Resolution|--- |FIXED --- Comment #1 from Uroš Bizjak --- Fixed by [1]. [1] https://gcc.gnu.org/ml/gcc-patches/2014-07/msg01417.html
[Bug target/61878] Missing intrinsic functions in avx512intrin.h
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61878 Uroš Bizjak changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2014-07-22 CC||kyukhin at gcc dot gnu.org Target Milestone|--- |4.9.2 Ever confirmed|0 |1 --- Comment #1 from Uroš Bizjak --- Confirmed.
[Bug testsuite/61748] imm-devirt-2.C failed on arm-linux
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61748 Uroš Bizjak changed: What|Removed |Added Status|NEW |RESOLVED Component|middle-end |testsuite Resolution|--- |FIXED --- Comment #6 from Uroš Bizjak --- Fixed by [1]. [1] https://gcc.gnu.org/ml/gcc-patches/2014-07/msg01417.html
[Bug c/61861] Incorrect column number for -Wdiscarded-qualifiers
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61861 --- Comment #3 from Marek Polacek --- The same for __DATE__, __TIME__, __LINE__.
[Bug fortran/61881] ICE in gfc_conv_intrinsic_to_class with assumed-rank CLASS(*)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61881 Dominique d'Humieres changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2014-07-22 Ever confirmed|0 |1 --- Comment #1 from Dominique d'Humieres --- After deletion the line program test I get the ICE which at the same place as the tests in pr49802 comments 5 and 8.
[Bug c/61861] Incorrect column number for -Wdiscarded-qualifiers
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61861 --- Comment #2 from Marek Polacek --- Seems that the location of __FILE__ is generally broken, e.g. on extern void foo (int i); void f (void) { foo (__FILE__); } the column info is wrong as well.
[Bug c/61579] -Wwrite-strings does not behave as a warning option
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61579 Marek Polacek changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2014-07-22 CC||mpolacek at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #2 from Marek Polacek --- Confirmed. I might possibly get to this.
[Bug middle-end/61734] [4.10 Regression] Regression in ABS_EXPR recognition
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61734 --- Comment #7 from Eric Botcazou --- > Eric, dou you have any plans regarding this issue? Sure, see comment #3.
[Bug c++/61882] New: attribute weak ignored for function templates
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61882 Bug ID: 61882 Summary: attribute weak ignored for function templates Product: gcc Version: 4.8.2 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: msebor at gmail dot com In GCC 4.5 and later, and at -O and above, attribute weak (but not weak alias) is silently ignored on declarations of function templates and calls to specializations of such templates are inlined into their callers. The program below shows that GCC inlines calls to the function template specialization instantiated from the weak primary template baz, but emits a weak symbol for the weak alias foo. GCC 4.2 honored the attribute and emitted a weak symbol for both foo and baz. Clang 3.4 also emits a weak symbol for both as expected. Disabling optimization changes the current behavior to match that of GCC 4.2.1 and Clang 3.4. The GCC documentation of attribute weak doesn't say whether or not the attribute is intended to have the same effect on specializations of function templates as it does on ordinary functions. If the current GCC behavior is intended, the documentation should be updated to make it clear when attribute weak is ignored, and GCC should be enhanced to issue a warning when the attribute is ignored. $ (set -x; cc=/auto/compiler-dev/msebor/contrib/cel-5.50/bin/g++; cat z.c && $cc -c -fpic -DFOO=1 -O -Wall -Wextra z.c && $cc -fpic -Wall -Wextra z.c z.o && ./a.out) + cc=/auto/compiler-dev/msebor/contrib/cel-5.50/bin/g++ + cat z.c template void foo (T); template void baz (T); void foobar (); #if FOO template void __attribute__ ((weak, alias ("bar"))) foo (T); static void bar (int) { } template void __attribute__ ((weak)) baz (T) { } void foobar () { foo (0), baz (0); } #else # include template <> void foo (int) { puts (__func__); } template <> void baz (int) { puts (__func__); } int main (void) { foobar (); } #endif + /auto/compiler-dev/msebor/contrib/cel-5.50/bin/g++ -c -fpic -DFOO=1 -O -Wall -Wextra z.c + /auto/compiler-dev/msebor/contrib/cel-5.50/bin/g++ -fpic -Wall -Wextra z.c z.o + ./a.out foo
[Bug lto/61802] [4.10 Regression] AArch64 execute.exp failures with LTO after r212467
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61802 --- Comment #8 from Andrew Pinski --- (In reply to Jan Hubicka from comment #7) > Actually at the cauldron discussion I got an idea that it may be issue with > anchor generation > not bringing in all the constructors. Is the problem there that constructors > of static vairables > are empty in the final binary? yes.
[Bug lto/61802] [4.10 Regression] AArch64 execute.exp failures with LTO after r212467
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61802 --- Comment #7 from Jan Hubicka --- Actually at the cauldron discussion I got an idea that it may be issue with anchor generation not bringing in all the constructors. Is the problem there that constructors of static vairables are empty in the final binary? Honza
[Bug ipa/61160] [4.9/4.10 Regression] wrong code with -O3 (or ICE: verify_cgraph_node failed: edge points to wrong declaration)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61160 --- Comment #14 from Martin Jambor --- Author: jamborm Date: Tue Jul 22 16:20:25 2014 New Revision: 212915 URL: https://gcc.gnu.org/viewcvs?rev=212915&root=gcc&view=rev Log: 2014-07-22 Martin Jambor PR ipa/61160 * g++.dg/ipa/pr61160-3.C (main): Return zero. Modified: trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/g++.dg/ipa/pr61160-3.C
[Bug c/61861] Incorrect column number for -Wdiscarded-qualifiers
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61861 Marek Polacek changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2014-07-22 CC||mpolacek at gcc dot gnu.org Assignee|unassigned at gcc dot gnu.org |mpolacek at gcc dot gnu.org Target Milestone|--- |4.10.0 Ever confirmed|0 |1 --- Comment #1 from Marek Polacek --- Mine.
[Bug fortran/61881] New: ICE in gfc_conv_intrinsic_to_class with assumed-rank CLASS(*)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61881 Bug ID: 61881 Summary: ICE in gfc_conv_intrinsic_to_class with assumed-rank CLASS(*) Product: gcc Version: 4.10.0 Status: UNCONFIRMED Keywords: ice-on-valid-code Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: burnus at gcc dot gnu.org CC: pault at gcc dot gnu.org The following code uses assumed-rank and CLASS(*) and ICEs. Such a code might get used for GCC's OpenACC implementation. foo.f90:3:0: internal compiler error: in fold_convert_loc, at fold-const.c:2074 call test(4) ^ 0x87556c fold_convert_loc(unsigned int, tree_node*, tree_node*) ../../gcc/fold-const.c:2074 0x69f570 gfc_conv_intrinsic_to_class(gfc_se*, gfc_expr*, gfc_typespec) ../../gcc/fortran/trans-expr.c:592 program test implicit none call test(4) call test([4]) contains subroutine test(a) class(*), dimension(..) :: a end subroutine test end
[Bug c/61864] Feature Request, -Wcovered-switch-default to identify "dead" default branch
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61864 Marek Polacek changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2014-07-22 CC||mpolacek at gcc dot gnu.org Target Milestone|--- |4.10.0 Ever confirmed|0 |1 --- Comment #1 from Marek Polacek --- Confirmed.
[Bug go/61880] New: Linking with external functions in C does not work in GO when using gccgo, while it works in gc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61880 Bug ID: 61880 Summary: Linking with external functions in C does not work in GO when using gccgo, while it works in gc Product: gcc Version: 4.9.2 Status: UNCONFIRMED Severity: normal Priority: P3 Component: go Assignee: ian at airs dot com Reporter: lists at kambanaria dot org CC: cmang at google dot com Created attachment 33173 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=33173&action=edit tiniest GOPATH demoing the problem (28 nonempty lines, 6 in C, 22 in GO including comments) This is continuation of issue reported here: https://code.google.com/p/gofrontend/issues/detail?id=36 Since I have changed the test case to be extremely simple with no external references to any libraries or applications, I am moving the bug here. 1. Demo of the issue: tar xvfz CGO_FALURE.tar.gz cd CGO_FALURE export GOPATH=`pwd` go run -compiler gccgo src/cgo_problem/demo.go results in: # command-line-arguments /tmp/go-build280712483/cgo_problem/example.com/libdemo.a(_cgo_export.o): In function `Dummy': /tmp/go-build280712483/cgo_problem/example.com/demo/_obj/_cgo_export.c:5: undefined reference to `cgo_problem_example_com_demo.Cgoexp_Dummy' collect2: error: ld returned 1 exit status 2. Compare with the behavior of gc: go run -compiler gccgo src/cgo_problem/demo.go results in: Address of function Dummy: 0x400f30 The issue can be worked around by renaming the example.com/demo package to example_com/demo mv src/cgo_problem/example.com src/cgo_problem/example.com sed -i 's/example[.]com/example_com/' src/cgo_problem/demo.go 3. The problem stems from: The _cgo_export.h file that is emitted by cgo. The first part of the name given to __asm__ macro is generated by the gccgoSymbolPrefix method here: http://golang.org/src/cmd/cgo/out.go#L985 Perhaps the runes that get emitted directly should include the dot '.' - it is the domain delimiter character which is reused in package names. 4. gcc versions 4.8, 4.9, 4.10 suffer from this issue: 4.8: COLLECT_LTO_WRAPPER=/usr/libexec/gcc/x86_64-redhat-linux/4.8.3/lto-wrapper Target: x86_64-redhat-linux Configured with: ../configure --prefix=/usr --mandir=/usr/share/man --infodir=/usr/share/info --with-bugurl=http://bugzilla.redhat.com/bugzilla --enable-bootstrap --enable-shared --enable-threads=posix --enable-checking=release --with-system-zlib --enable-__cxa_atexit --disable-libunwind-exceptions --enable-gnu-unique-object --enable-linker-build-id --with-linker-hash-style=gnu --enable-languages=c,c++,objc,obj-c++,java,fortran,ada,go,lto --enable-plugin --enable-initfini-array --enable-java-awt=gtk --disable-dssi --with-java-home=/usr/lib/jvm/java-1.5.0-gcj-1.5.0.0/jre --enable-libgcj-multifile --enable-java-maintainer-mode --with-ecj-jar=/usr/share/java/eclipse-ecj.jar --disable-libjava-multilib --with-isl=/builddir/build/BUILD/gcc-4.8.3-20140624/obj-x86_64-redhat-linux/isl-install --with-cloog=/builddir/build/BUILD/gcc-4.8.3-20140624/obj-x86_64-redhat-linux/cloog-install --with-tune=generic --with-arch_32=i686 --build=x86_64-redhat-linux Thread model: posix gcc version 4.8.3 20140624 (Red Hat 4.8.3-1) (GCC) 4.9: COLLECT_GCC=gcc COLLECT_LTO_WRAPPER=/home/ashopov/WORK/GCC/libexec/gcc/x86_64-linux-gnu/4.9.1/lto-wrapper Target: x86_64-linux-gnu Configured with: ../configure --prefix=/home/ashopov/WORK/GCC --build=x86_64-linux-gnu --disable-browser-plugin --disable-libgcj --disable-libmudflap --disable-vtable-verify --disable-libunwind-exceptions --enable-checking=release --disable-bootstrap --enable-__cxa_atexit --enable-gnu-unique-object --enable-languages=c,c++,go,lto --enable-linker-build-id --enable-multilib --enable-plugin --enable-shared --enable-threads=posix --with-linker-hash-style=gnu --with-system-zlib --with-tune=generic --enable-multiarch Thread model: posix gcc version 4.9.1 20140709 (prerelease) (GCC) 4.10: Using built-in specs. COLLECT_GCC=gcc COLLECT_LTO_WRAPPER=/home/ashopov/WORK/GCC-TRUNK/libexec/gcc/x86_64-linux-gnu/4.10.0/lto-wrapper Target: x86_64-linux-gnu Configured with: ./configure --prefix=/home/ashopov/WORK/GCC-TRUNK --build=x86_64-linux-gnu --disable-browser-plugin --disable-libgcj --disable-libmudflap --disable-vtable-verify --disable-libunwind-exceptions --enable-checking=release --disable-bootstrap --enable-__cxa_atexit --enable-gnu-unique-object --enable-languages=c,c++,go,lto --enable-linker-build-id --enable-multilib --enable-plugin --enable-shared --enable-threads=posix --with-linker-hash-style=gnu --with-system-zlib --with-tune=generic --enable-multiarch Thread model: posix gcc version 4.10.0 20140721 (experimental) (GCC) 5. System is: Linux ashopov-dev 3.15.6-200.fc20.x86_64 #1 SMP Fri Jul 18 02:36:27 UTC 2014 x86_64 x86_64 x86_64 GNU/Linux - up to da
[Bug fortran/61831] [4.9/ 4.10 Regression] runtime error: pointer being freed was not allocated
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61831 --- Comment #34 from paul.richard.thomas at gmail dot com --- Hi Dominique, Should one be getting false? It seems to me that the code looks right. within the do loop: new_prt_spec ([string_t's]) produces an array of string_t's whose char.data is null. It does nothing with the input array. This output string is fed to process configuration, which does nothing to it. This is surprising in itself :-) Finally, your patch comes into play. This should do nothing if the char.data's are null, which they should be. Mystified Paul On 21 July 2014 21:56, dominiq at lps dot ens.fr wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61831 > > --- Comment #33 from Dominique d'Humieres --- > Dear Paul, > >> I cannot see yet, where it comes in nor when it was introduced. > > Unfortunately I has been introduced by me, see comment 5. The code is > > + if (expr->ts.type == BT_DERIVED && expr->rank > + && !gfc_is_finalizable (expr->ts.u.derived, NULL) > + && expr->ts.u.derived->attr.alloc_comp > + && expr->expr_type != EXPR_VARIABLE) > +{ > + tree tmp; > + > + tmp = build_fold_indirect_ref_loc (input_location, se->expr); > + tmp = gfc_deallocate_alloc_comp (expr->ts.u.derived, tmp, expr->rank); > + > + /* The components shall be deallocated before > + their containing entity. */ > + gfc_prepend_expr_to_block (&se->post, tmp); > +} > > Question: what condition should be added to the 'if' to get a false for > 'expr->expr_type == EXPR_ARRAY' and an elemental function? > > -- > You are receiving this mail because: > You are on the CC list for the bug.
[Bug middle-end/61879] New: [4.10 Regression] GCC gives "note: non-delegitimized UNSPEC UNSPEC_GOTOFF (1) found in variable location"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61879 Bug ID: 61879 Summary: [4.10 Regression] GCC gives "note: non-delegitimized UNSPEC UNSPEC_GOTOFF (1) found in variable location" Product: gcc Version: 4.10.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: middle-end Assignee: unassigned at gcc dot gnu.org Reporter: d.g.gorbachev at gmail dot com Target: i686-pc-linux-gnu Created attachment 33172 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=33172&action=edit Testcase GCC 4.10.0 20140720 (experimental). $ gcc -S -march=pentium4 -g -O2 -fpie bug.c bug.c: In function 'foo': bug.c:11:5: note: non-delegitimized UNSPEC UNSPEC_GOTOFF (1) found in variable location int foo(int *p) ^ bug.c:11:5: note: non-delegitimized UNSPEC UNSPEC_GOTOFF (1) found in variable location Appeared in 210914 < r <= 211358.
[Bug lto/53808] Undefined symbol when building a library with lto
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53808 --- Comment #12 from Rafael Avila de Espindola --- Note that this bug is present once more when -fno-use-all-virtuals is used. With the original testcase gcc again produces an undefined reference to _ZN3barD0Ev. Is -fno-use-all-virtuals intended to be an abi breaking option? If so it would be nice to document that.
[Bug c/61878] New: Missing intrinsic functions in avx512intrin.h
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61878 Bug ID: 61878 Summary: Missing intrinsic functions in avx512intrin.h Product: gcc Version: 4.10.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c Assignee: unassigned at gcc dot gnu.org Reporter: agner at agner dot org A few compare functions are missing in avx512intrin.h, e.g. _mm512_cmpgt_epu32_mask and _mm512_cmpgt_epu64_mask All intrinsic functions for typecasting are also missing. Please add these functions, as they are indispensable. See https://software.intel.com/en-us/node/513903 and https://software.intel.com/sites/landingpage/IntrinsicsGuide/ for documentation of these functions. Definitions copied from Intel's zmmintrin.h: /* Conversion from one type to another, no change in value. */ extern __m512 __ICL_INTRINCC _mm512_castpd_ps(__m512d); extern __m512i __ICL_INTRINCC _mm512_castpd_si512(__m512d); extern __m512d __ICL_INTRINCC _mm512_castps_pd(__m512); extern __m512i __ICL_INTRINCC _mm512_castps_si512(__m512); extern __m512 __ICL_INTRINCC _mm512_castsi512_ps(__m512i); extern __m512d __ICL_INTRINCC _mm512_castsi512_pd(__m512i); * Casts from a larger type to a smaller type. */ extern __m128d __ICL_INTRINCC _mm512_castpd512_pd128(__m512d); extern __m128 __ICL_INTRINCC _mm512_castps512_ps128(__m512); extern __m128i __ICL_INTRINCC _mm512_castsi512_si128(__m512i); extern __m256d __ICL_INTRINCC _mm512_castpd512_pd256(__m512d); extern __m256 __ICL_INTRINCC _mm512_castps512_ps256(__m512); extern __m256i __ICL_INTRINCC _mm512_castsi512_si256(__m512i); /* * Casts from a smaller type to a larger type. * Upper elements of the result are undefined. */ extern __m512d __ICL_INTRINCC _mm512_castpd128_pd512(__m128d); extern __m512 __ICL_INTRINCC _mm512_castps128_ps512(__m128); extern __m512i __ICL_INTRINCC _mm512_castsi128_si512(__m128i); extern __m512d __ICL_INTRINCC _mm512_castpd256_pd512(__m256d); extern __m512 __ICL_INTRINCC _mm512_castps256_ps512(__m256); extern __m512i __ICL_INTRINCC _mm512_castsi256_si512(__m256i);
[Bug libgcc/61752] on cygwin, aborts during exit() with a dynamically loaded C++ library
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61752 --- Comment #2 from jon.turney at dronecode dot org.uk --- Better patch: https://cygwin.com/ml/cygwin/2014-07/msg00180.html
[Bug tree-optimization/61822] gcc.dg/vect/vect-cond-reduc-1.c FAILs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61822 --- Comment #5 from Kirill Yukhin --- Author: kyukhin Date: Tue Jul 22 12:53:04 2014 New Revision: 212911 URL: https://gcc.gnu.org/viewcvs?rev=212911&root=gcc&view=rev Log: gcc/testsuite PR tree-optimization/61822 * gcc.dg/vect/cond-reduc-1.c: Add missed dg directive. Modified: trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gcc.dg/vect/vect-cond-reduc-1.c
[Bug c++/61870] internal compiler error: in get_expr_operands, at tree-ssa-operands.c:1035
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61870 Marek Polacek changed: What|Removed |Added CC||mpolacek at gcc dot gnu.org --- Comment #2 from Marek Polacek --- I can't reproduce it with 4.7 (that is not supported anymore), neither with 4.8. 4.9 and trunk reject this code.
[Bug c++/61873] with -openmp, -E does not produce preprocessed output on stdout
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61873 Marek Polacek changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||mpolacek at gcc dot gnu.org Resolution|--- |INVALID --- Comment #1 from Marek Polacek --- Of course, because it's "-fopenmp". -o specifies output file, in this case "penmp".
[Bug tree-optimization/61822] gcc.dg/vect/vect-cond-reduc-1.c FAILs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61822 --- Comment #4 from ro at CeBiTec dot Uni-Bielefeld.DE --- > --- Comment #3 from Yuri Rumyantsev --- > Hi Rainer, > > Could you try attached patch to check if it helps (test should not be > run for sparc). Indeed, the test is UNSUPPORTED now. Thanks. Rainer
[Bug go/61877] [4.10 Regression]: reflect: cannot use []string as type string in Call
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61877 --- Comment #1 from Alexander Shopov --- I will provide additional information if necessary
[Bug go/61877] New: [4.10 Regression]: reflect: cannot use []string as type string in Call
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61877 Bug ID: 61877 Summary: [4.10 Regression]: reflect: cannot use []string as type string in Call Product: gcc Version: 4.10.0 Status: UNCONFIRMED Severity: major Priority: P3 Component: go Assignee: ian at airs dot com Reporter: lists at kambanaria dot org CC: cmang at google dot com Created attachment 33171 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=33171&action=edit test case that can be executed with "go test -compiler gccgo -test.v reflect_test" There is a regression in the runtime behavior of the reflection module. Attached is a very simple ( < 30 lines) test case (that can be execured via go test command). I hope this can be included in the normal test suite Expected behavior: go run -compiler gccgo src/ref_main.go go test -compiler gccgo -test.v reflect_test should result in: === RUN TestFindingVarargMethod --- PASS: TestFindingVarargMethod (0.00 seconds) PASS ok Actual behavior: === RUN TestFindingVarargMethod --- FAIL: TestFindingVarargMethod (0.00 seconds) panic: reflect: cannot use []string as type string in Call [recovered] panic: reflect: cannot use []string as type string in Call goroutine 20 [running]: testing.$nested5 ../.././libgo/go/testing/testing.go:406 reflect.call.N13_reflect.Value ../.././libgo/go/reflect/value.go:494 reflect.Call.N13_reflect.Value ../.././libgo/go/reflect/value.go:412 reflect.call.pN20_reflect.makeFuncImpl ../.././libgo/go/reflect/makefunc.go:198 reflect.MakeFuncStubGo ../.././libgo/go/reflect/makefuncgo_amd64.go:322 reflect_test_test.TestFindingVarargMethod /home/ashopov/WORK/GO/src/reflect_test/finder_test.go:19 testing.tRunner ../.././libgo/go/testing/testing.go:422 created by testing.RunTests ../.././libgo/go/testing/testing.go:504 goroutine 16 [chan receive]: testing.RunTests ../.././libgo/go/testing/testing.go:505 testing.Main ../.././libgo/go/testing/testing.go:435 main.main /tmp/go-build886615920/reflect_test/_test/_testmain.go:47 created by main ../.././libgo/runtime/go-main.c:42 goroutine 18 [finalizer wait]: created by runtime_createfing ../.././libgo/runtime/mgc0.c:2596 exit status 2 FAILreflect_test0.058s This test case is WORKING fine with: 1. golang-pkg-bin-linux-amd64-1.2.2-7 distributed with Fedora 20 which corresponds to 2. gcc 4.9: gcc -v Using built-in specs. COLLECT_GCC=gcc COLLECT_LTO_WRAPPER=/home/ashopov/WORK/GCC/libexec/gcc/x86_64-linux-gnu/4.9.1/lto-wrapper Target: x86_64-linux-gnu Configured with: ../configure --prefix=/home/ashopov/WORK/GCC --build=x86_64-linux-gnu --disable-browser-plugin --disable-libgcj --disable-libmudflap --disable-vtable-verify --disable-libunwind-exceptions --enable-checking=release --disable-bootstrap --enable-__cxa_atexit --enable-gnu-unique-object --enable-languages=c,c++,go,lto --enable-linker-build-id --enable-multilib --enable-plugin --enable-shared --enable-threads=posix --with-linker-hash-style=gnu --with-system-zlib --with-tune=generic --enable-multiarch Thread model: posix gcc version 4.9.1 20140709 (prerelease) (GCC) This test case is FAILING with: 1. gcc 4.10 gcc -v Using built-in specs. COLLECT_GCC=gcc COLLECT_LTO_WRAPPER=/home/ashopov/WORK/GCC-TRUNK/libexec/gcc/x86_64-linux-gnu/4.10.0/lto-wrapper Target: x86_64-linux-gnu Configured with: ./configure --prefix=/home/ashopov/WORK/GCC-TRUNK --build=x86_64-linux-gnu --disable-browser-plugin --disable-libgcj --disable-libmudflap --disable-vtable-verify --disable-libunwind-exceptions --enable-checking=release --disable-bootstrap --enable-__cxa_atexit --enable-gnu-unique-object --enable-languages=c,c++,go,lto --enable-linker-build-id --enable-multilib --enable-plugin --enable-shared --enable-threads=posix --with-linker-hash-style=gnu --with-system-zlib --with-tune=generic --enable-multiarch Thread model: posix gcc version 4.10.0 20140721 (experimental) (GCC) Machine used for tests: uname -a Linux ashopov-dev 3.15.6-200.fc20.x86_64 #1 SMP Fri Jul 18 02:36:27 UTC 2014 x86_64 x86_64 x86_64 GNU/Linux
[Bug middle-end/61876] Converting __builtin_round + cast into __builtin_lround is not always equivalent in regards to math errno
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61876 ktkachov at gcc dot gnu.org changed: What|Removed |Added Keywords||missed-optimization Component|tree-optimization |middle-end --- Comment #1 from ktkachov at gcc dot gnu.org --- This particular example is given for aarch64 but I imagine it could occur for any other target. >From what I understand lround can potentially set errno on a domain error whereas round is valid everywhere and the cast to long int could be undefined behaviour if the double is not valid, but undefined behaviour is not the same as setting errno...
[Bug tree-optimization/61876] New: Converting __builtin_round + cast into __builtin_lround is not always equivalent in regards to math errno
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61876 Bug ID: 61876 Summary: Converting __builtin_round + cast into __builtin_lround is not always equivalent in regards to math errno Product: gcc Version: 4.10.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: tree-optimization Assignee: unassigned at gcc dot gnu.org Reporter: ktkachov at gcc dot gnu.org Consider code: long int foo (double a) { return __builtin_round (a); } With an aarch64-none-elf toolchain this compiles to: foo: fcvtas x0, d0 ret whereas with an aarch64-linux toolchain this compiles to: foo: b lround The linux (glibc) toolchain does not inline the lround implementation. The suspicious starting point is this code in convert.c: CASE_FLT_FN (BUILT_IN_ROUND): /* Only convert in ISO C99 mode. */ if (!targetm.libc_has_function (function_c99_misc)) break; if (outprec < TYPE_PRECISION (integer_type_node) || (outprec == TYPE_PRECISION (integer_type_node) && !TYPE_UNSIGNED (type))) fn = mathfn_built_in (s_intype, BUILT_IN_IROUND); else if (outprec == TYPE_PRECISION (long_integer_type_node) && !TYPE_UNSIGNED (type)) fn = mathfn_built_in (s_intype, BUILT_IN_LROUND); else if (outprec == TYPE_PRECISION (long_long_integer_type_node) && !TYPE_UNSIGNED (type)) fn = mathfn_built_in (s_intype, BUILT_IN_LLROUND); break; Basically it does the conversion of (cast to long int + round) == lround But later on in builtins.c the lround does not get expanded into the sfix optab unless -fno-math-errno is specified: /* There's no easy way to detect the case we need to set EDOM. */ if (!flag_errno_math) { rtx result = gen_reg_rtx (mode); /* Wrap the computation of the argument in a SAVE_EXPR, as we may need to expand the argument again. This way, we will not perform side-effects more the once. */ CALL_EXPR_ARG (exp, 0) = arg = builtin_save_expr (arg); op0 = expand_expr (arg, NULL, VOIDmode, EXPAND_NORMAL); start_sequence (); if (expand_sfix_optab (result, op0, builtin_optab)) { /* Output the entire sequence. */ insns = get_insns (); end_sequence (); emit_insn (insns); return result; } I think if the cast+round -> lround transformation is done it should be assumed in that case that lround will not set errno. Another approach would be to not do the transformation unless -fno-math-errno
[Bug tree-optimization/61822] gcc.dg/vect/vect-cond-reduc-1.c FAILs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61822 --- Comment #3 from Yuri Rumyantsev --- Hi Rainer, Could you try attached patch to check if it helps (test should not be run for sparc). Thanks ahead. Yuri.. 2014-07-16 19:20 GMT+04:00 ro at gcc dot gnu.org : > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61822 > > --- Comment #1 from Rainer Orth --- > Created attachment 33128 > --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=33128&action=edit > vect dump > > -- > You are receiving this mail because: > You are on the CC list for the bug.
[Bug c++/61867] gcc can't detect obviously false test
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61867 --- Comment #4 from Jonathan Wakely --- (In reply to David Binderman from comment #3) > I think that all that needs to happen is a warning is produced > where either the detection or reduction takes place. There is no single place, it's a result of constant propagation and a whole range of optimisations cooperating. Those optimisations are a good thing, you don't want to spit out a warning every time the compiler decides it can remove part of the code, you'd end up with either hundreds of warnings for correct code or disabling all optimisations. > As ever, users are free to ignore warnings. egrep -v is > useful, I find. egrep is useless for ignoring warnings. It might help on the command line, but not if you run the compiler from an editor or IDE, or with -Werror etc. Just because you don't mind ignoring warnings doesn't mean it is appropriate for GCC to start spitting out poor quality warnings.
[Bug sanitizer/61875] ATRIBUTE_NONNULL macro error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61875 Tatiana Udalova changed: What|Removed |Added CC||t.udalova at samsung dot com --- Comment #3 from Tatiana Udalova --- You can fix problem in Tizen via deletting -fexceptions flag from the default flags for gcc, cross-gcc and cross-gcc-accel packages: OPT_FLAGS=`echo "$OPT_FLAGS" | sed -e 's/-fexceptions / /'`
[Bug c++/51312] [C++0x] Wrong interpretation of converted constant expressions (for enumerator initializers)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=51312 --- Comment #9 from Marc Glisse --- (In reply to Paolo Carlini from comment #6) > Marc, are you going to send your patch to the mailing list (CC Jason)? Sorry, I don't remember this patch at all. I may try again to understand what it does at some point, but you seem to have a much better understanding of what is going on, so don't hesitate to take this bug.
[Bug preprocessor/60723] Line directives with incorrect system header flag
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60723 ktkachov at gcc dot gnu.org changed: What|Removed |Added CC||ktkachov at gcc dot gnu.org --- Comment #24 from ktkachov at gcc dot gnu.org --- (In reply to Dodji Seketeli from comment #22) > So finally the two patches that have been proposed at > https://gcc.gnu.org/ml/gcc-patches/2014-07/msg01063.html and > https://gcc.gnu.org/ml/gcc-patches/2014-07/msg01064.html have been accepted > and committed to trunk. > > I'll wait before closing this bug that the stakeholders following this test > the tree with the new patches. This breaks building ncurses. I've filed PR 61832 for this, but now trying to reduce a testcase. > > In the mean time, I'll look at the additional issue PR61817. > > Thanks.
[Bug sanitizer/61875] ATRIBUTE_NONNULL macro error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61875 Marat Zakirov changed: What|Removed |Added CC||m.zakirov at samsung dot com --- Comment #2 from Marat Zakirov --- We had the same problem in Tizen. But my Q to asan and gcc maintainers is wider. Do we consider that asan in gcc should build with option -fexeptions? Or should it ignore this option? Or fail as it is for know?
[Bug sanitizer/61875] ATRIBUTE_NONNULL macro error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61875 Yury Gribov changed: What|Removed |Added CC||y.gribov at samsung dot com --- Comment #1 from Yury Gribov --- I think the error may be caused by compiling gcc with -fexceptions. Here is a short repro: $ cat tmp.cpp int f () throw (); int f (); $ g++ -fexceptions tmp.cpp -c tmp.cpp:2:8: error: declaration of ‘int f()’ has a different exception specifier tmp.cpp:1:5: error: from previous declaration ‘int f() throw ()’ The error is well known, here's link to Perl bug with proposed solution: https://rt.perl.org/Public/Bug/Display.html?id=121151
[Bug middle-end/61734] [4.10 Regression] Regression in ABS_EXPR recognition
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61734 Igor Zamyatin changed: What|Removed |Added CC||izamyatin at gmail dot com --- Comment #6 from Igor Zamyatin --- Eric, dou you have any plans regarding this issue?
[Bug sanitizer/61875] New: ATRIBUTE_NONNULL macro error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61875 Bug ID: 61875 Summary: ATRIBUTE_NONNULL macro error Product: gcc Version: 4.9.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: sanitizer Assignee: unassigned at gcc dot gnu.org Reporter: parkch98 at gmail dot com CC: dodji at gcc dot gnu.org, dvyukov at gcc dot gnu.org, jakub at gcc dot gnu.org, kcc at gcc dot gnu.org When I tried to build below flags, I found a error to build gcc. CFLAGS='-O2 -g2 -feliminate-unused-debug-types -pipe -fexceptions --param=ssp-buffer-size=32 -Wformat -Wformat-security -fmessage-length=0 -march=corei7 -msse4.2 -mtune=corei7-avx -mfpmath=sse -fasynchronous-unwind-tables -fno-omit-frame-pointer -fipa-cp-clone -U_FORTIFY_SOURCE' \ CXXFLAGS='-O2 -g2 -feliminate-unused-debug-types -pipe -fexceptions --param=ssp-buffer-size=32 -Wformat -Wformat-security -fmessage-length=0 -march=corei7 -msse4.2 -mtune=corei7-avx -mfpmath=sse -fasynchronous-unwind-tables -fno-omit-frame-pointer -fipa-cp-clone -U_FORTIFY_SOURCE' \ XCFLAGS='-O2 -g2 -feliminate-unused-debug-types -pipe -fexceptions --param=ssp-buffer-size=32 -Wformat -Wformat-security -fmessage-length=0 -march=corei7 -msse4.2 -mtune=corei7-avx -mfpmath=sse -fasynchronous-unwind-tables -fno-omit-frame-pointer -fipa-cp-clone -U_FORTIFY_SOURCE' \ TCFLAGS='-O2 -g2 -feliminate-unused-debug-types -pipe -fexceptions --param=ssp-buffer-size=32 -Wformat -Wformat-security -fmessage-length=0 -march=corei7 -msse4.2 -mtune=corei7-avx -mfpmath=sse -fasynchronous-unwind-tables -fno-omit-frame-pointer -fipa-cp-clone -U_FORTIFY_SOURCE' \ GCJFLAGS='-O2 -g2 -feliminate-unused-debug-types -pipe -fexceptions --param=ssp-buffer-size=32 -Wformat -Wformat-security -fmessage-length=0 -march=corei7 -msse4.2 -mtune=corei7-avx -mfpmath=sse -fasynchronous-unwind-tables -fno-omit-frame-pointer -fipa-cp-clone -U_FORTIFY_SOURCE ' \ ../configure --prefix=/usr --infodir=/usr/share/info --mandir=/usr/share/man --libdir=/usr/lib64 --libexecdir=/usr/lib64 --disable-bootstrap --enable-languages=c,c++,objc,fortran,obj-c++,go --enable-checking=release --with-gxx-include-dir=/usr/include/c++/4.9 --enable-ssp --disable-libssp --disable-libvtv --disable-plugin --with-bugurl=http://bugs.tizen.org/ --with-pkgversion=Tizen --disable-libgcj --with-slibdir=/lib64 --with-system-zlib --enable-__cxa_atexit --enable-libstdcxx-allocator=new --disable-libstdcxx-pch --enable-version-specific-runtime-libs --enable-linker-build-id --enable-linux-futex --program-suffix=-4.9 --without-system-libunwind --with-arch-32=i586 --with-tune=generic --disable-multilib --build=x86_64-tizen-linux --host=x86_64-tizen-linux make STAGE1_CFLAGS=-g 'BOOT_CFLAGS=-O2 -g2 -feliminate-unused-debug-types -pipe -fexceptions --param=ssp-buffer-size=32 -Wformat -Wformat-security -fmessage-length=0 -march=corei7 -msse4.2 -mtune=corei7-avx -mfpmath=sse -fasynchronous-unwind-tables -fno-omit-frame-pointer -fipa-cp-clone -U_FORTIFY_SOURCE' -j8 -l16 = The error is : libtool: compile: /opt/opensource/gcc/build/./gcc/xgcc -shared-libgcc -B/opt/opensource/gcc/build/./gcc -nostdinc++ -L/opt/opensource/gcc/build/x86_64-tizen-linux/libstdc++-v3/src -L/opt/opensource/gcc/build/x86_64-tizen-linux/libstdc++-v3/src/.libs -L/opt/opensource/gcc/build/x86_64-tizen-linux/libstdc++-v3/libsupc++/.libs -B/usr/x86_64-tizen-linux/bin/ -B/usr/x86_64-tizen-linux/lib/ -isystem /usr/x86_64-tizen-linux/include -isystem /usr/x86_64-tizen-linux/sys-include -D_GNU_SOURCE -D_DEBUG -D__STDC_CONSTANT_MACROS -D__STDC_FORMAT_MACROS -D__STDC_LIMIT_MACROS -I. -I../../../../libsanitizer/sanitizer_common -I.. -I ../../../../libsanitizer/include -isystem ../../../../libsanitizer/include/system -Wall -W -Wno-unused-parameter -Wwrite-strings -pedantic -Wno-long-long -fPIC -fno-builtin -fno-exceptions -fno-rtti -fomit-frame-pointer -funwind-tables -fvisibility=hidden -Wno-variadic-macros -I../../libstdc++-v3/include -I../../libstdc++-v3/include/x86_64-tizen-linux -I../../../../libsanitizer/../libstdc++-v3/libsupc++ -DSANITIZER_LIBBACKTRACE -DSANITIZER_CP_DEMANGLE -I ../../../../libsanitizer/../libbacktrace -I ../libbacktrace -I ../../../../libsanitizer/../include -include ../../../../libsanitizer/libbacktrace/backtrace-rename.h -g -O2 -g2 -feliminate-unused-debug-types -pipe -fexceptions --param=ssp-buffer-size=32 -Wformat -Wformat-security -fmessage-length=0 -march=corei7 -msse4.2 -mtune=corei7-avx -mfpmath=sse -fasynchronous-unwind-tables -fno-omit-frame-pointer -fipa-cp-clone -U_FORTIFY_SOURCE -D_GNU_SOURCE -MT sanitizer_symbolizer_libbacktrace.lo -MD -MP -MF .deps/sanitizer_symbolizer_libbacktrace.Tpo -c ../../../../libsanitizer/sanitizer_common/sanitizer_symbolizer_libbacktrace.cc -fPIC -DPIC -o .libs/sanitizer_symbolizer_libbacktrace.o In file included from ../../../../libsanitizer/