[Bug target/65647] [5 Regression] GCC won't stop when compile for armv6-m
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65647 Yvan Roux changed: What|Removed |Added CC||yroux at gcc dot gnu.org --- Comment #4 from Yvan Roux --- I was about to report the same issue which occurs during the build of videolan x264 build. Vlad patch fixes the issue on trunk, but with that testcase the problem is also present in 4.9 branch (it occurs this time in ARM mode on armv6 architecture). To be backported on 4.9 the rematerialization code as to be removed from the patch, I'll submit the patch on the mailing list. command line to reproduce the problem: cc1 -O3 -marm -march=armv6 -std=c99 a.c
[Bug target/65647] [5 Regression] GCC won't stop when compile for armv6-m
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65647 --- Comment #5 from Yvan Roux --- Created attachment 35229 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=35229&action=edit testcase that fails also on 4.9
[Bug fortran/59016] f951: internal compiler error: Segmentation fault
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59016 --- Comment #15 from drikosev at otenet dot gr --- Created attachment 35230 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=35230&action=edit altered patch for the regressions reported in comment 11 Hi, As it seems the problem with the program bug.f90 is that the generic attribute is set in a symbol as the parser tries to match a declaration type specification; but finally, the statement isn't matched as such and the generic attribute wasn't cleared. So, the attached patch makes the cleanup, without causing the regressions listed in comment 9. The question here is if gfortran had to print an error message for this program: module types public :: undefined end module types write (*,*) "undefined types!" end --- PS: I've not checked out the source code from a repo, so the attached patch is just the output of the diff command (not svn diff).
[Bug libstdc++/61347] std::distance(list.first(),list.end()) in O(1)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61347 --- Comment #4 from Marc Glisse --- Created attachment 35231 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=35231&action=edit Overload of __distance Here is one way to do it (I will probably protect the new code with defined(__OPTIMIZE__) as well, if we keep __builtin_constant_p). (Looking at the generated code, I was surprised to notice that _M_hook and _M_unhook are in src, they seem rather small for that)
[Bug fortran/59016] f951: internal compiler error: Segmentation fault
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59016
--- Comment #16 from Dominique d'Humieres ---
> As it seems the problem with the program bug.f90 is that the generic
> attribute is set in a symbol as the parser tries to match a declaration
> type specification; but finally, the statement isn't matched as such
> and the generic attribute wasn't cleared.
>
> So, the attached patch makes the cleanup, without causing the regressions
> listed in comment 9.
IMO the patch addresses the root of the problem and prevents the ICEs in the
PRs listed in comment 9. However it causes 3000+ failures in the test suite, so
the filter you apply is not narrow enough.
> The question here is if gfortran had to print an error message for
> this program:
>
> module types
> public :: undefined
> end module types
> write (*,*) "undefined types!"
> end
Why should it without "implicit none"?
Your patches do not follow the GNU coding standards:
http://www.gnu.org/prep/standards/
The last patch should look as
--- ../_clean/gcc/fortran/decl.c2015-03-25 14:07:04.0 +0100
+++ gcc/fortran/decl.c2015-04-05 13:02:38.0 +0200
@@ -4427,6 +4427,31 @@ ok:
gfc_free_data_all (gfc_current_ns);
cleanup:
+ // in gfc_match_data_decl; cleanup the garbages
+ gfc_symbol *csym = NULL;
+ if (current_ts.u.derived && current_ts.u.derived->name)
+{
+ char iname[129];
+ iname[128] = 0;
+ for (int i = 0; i < 128; i++)
+{
+ iname[i] = current_ts.u.derived->name[i];
+ if (current_ts.u.derived->name[i] == 0)
+break;
+}
+ iname[0] = TOLOWER(iname[0]);
+ for (int i = 0; i < 4; i++)
+{
+ gfc_find_symbol (iname, NULL, i, &csym) ;
+ if (csym && csym->generic
+ && (csym->generic->sym == current_ts.u.derived))
+ {
+ csym->generic = NULL;
+ break;
+ }
+}
+}
+ //
gfc_free_array_spec (current_as);
current_as = NULL;
return m;
(note that I may have done some errors myself). In addition you should comment
what you are trying to do.
[Bug fortran/59016] f951: internal compiler error: Segmentation fault
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59016 --- Comment #17 from Dominique d'Humieres --- I have forgotten to give a sample of the failing tests with the patch in comment 15: FAIL: gfortran.dg/coarray/alloc_comp_3.f90 -fcoarray=single -O2 -latomic (test for excess errors) FAIL: gfortran.dg/coarray/alloc_comp_3.f90 -fcoarray=lib -O2 -lcaf_single -latomic (test for excess errors) FAIL: gfortran.dg/coarray/poly_run_1.f90 -fcoarray=single -O2 -latomic (test for excess errors) FAIL: gfortran.dg/coarray/poly_run_1.f90 -fcoarray=lib -O2 -lcaf_single -latomic (test for excess errors) FAIL: gfortran.dg/coarray/poly_run_2.f90 -fcoarray=single -O2 -latomic (test for excess errors) FAIL: gfortran.dg/coarray/poly_run_2.f90 -fcoarray=lib -O2 -lcaf_single -latomic (test for excess errors) FAIL: gfortran.dg/abstract_type_3.f03 -O (test for errors, line 38) FAIL: gfortran.dg/abstract_type_3.f03 -O (test for errors, line 44) FAIL: gfortran.dg/abstract_type_3.f03 -O (test for errors, line 48) FAIL: gfortran.dg/abstract_type_3.f03 -O (test for excess errors) FAIL: gfortran.dg/abstract_type_4.f03 -O (test for excess errors) FAIL: gfortran.dg/abstract_type_6.f03 -O (test for excess errors) FAIL: gfortran.dg/alloc_comp_assign_12.f03 -O0 (test for excess errors) FAIL: gfortran.dg/alloc_comp_assign_12.f03 -O1 (test for excess errors) FAIL: gfortran.dg/alloc_comp_assign_12.f03 -O2 (test for excess errors) FAIL: gfortran.dg/alloc_comp_assign_12.f03 -O3 -fomit-frame-pointer (test for excess errors) FAIL: gfortran.dg/alloc_comp_assign_12.f03 -O3 -fomit-frame-pointer -funroll-loops (test for excess errors) FAIL: gfortran.dg/alloc_comp_assign_12.f03 -O3 -fomit-frame-pointer -funroll-all-loops -finline-functions (test for excess errors) FAIL: gfortran.dg/alloc_comp_assign_12.f03 -O3 -g (test for excess errors) FAIL: gfortran.dg/alloc_comp_assign_12.f03 -Os (test for excess errors) FAIL: gfortran.dg/alloc_comp_assign_12.f03 -g -flto (test for excess errors) FAIL: gfortran.dg/alloc_comp_assign_13.f08 -O0 (test for excess errors) FAIL: gfortran.dg/alloc_comp_assign_13.f08 -O1 (test for excess errors) FAIL: gfortran.dg/alloc_comp_assign_13.f08 -O2 (test for excess errors) FAIL: gfortran.dg/alloc_comp_assign_13.f08 -O3 -fomit-frame-pointer (test for excess errors) FAIL: gfortran.dg/alloc_comp_assign_13.f08 -O3 -fomit-frame-pointer -funroll-loops (test for excess errors) FAIL: gfortran.dg/alloc_comp_assign_13.f08 -O3 -fomit-frame-pointer -funroll-all-loops -finline-functions (test for excess errors) FAIL: gfortran.dg/alloc_comp_assign_13.f08 -O3 -g (test for excess errors) FAIL: gfortran.dg/alloc_comp_assign_13.f08 -Os (test for excess errors) FAIL: gfortran.dg/alloc_comp_assign_13.f08 -g -flto (test for excess errors) FAIL: gfortran.dg/alloc_comp_assign_14.f08 -O0 (test for excess errors) FAIL: gfortran.dg/alloc_comp_assign_14.f08 -O1 (test for excess errors) FAIL: gfortran.dg/alloc_comp_assign_14.f08 -O2 (test for excess errors) FAIL: gfortran.dg/alloc_comp_assign_14.f08 -O3 -fomit-frame-pointer (test for excess errors) FAIL: gfortran.dg/alloc_comp_assign_14.f08 -O3 -fomit-frame-pointer -funroll-loops (test for excess errors) FAIL: gfortran.dg/alloc_comp_assign_14.f08 -O3 -fomit-frame-pointer -funroll-all-loops -finline-functions (test for excess errors) FAIL: gfortran.dg/alloc_comp_assign_14.f08 -O3 -g (test for excess errors) FAIL: gfortran.dg/alloc_comp_assign_14.f08 -Os (test for excess errors) FAIL: gfortran.dg/alloc_comp_assign_14.f08 -g -flto (test for excess errors) FAIL: gfortran.dg/alloc_comp_assign_2.f90 -O0 (test for excess errors) FAIL: gfortran.dg/alloc_comp_assign_2.f90 -O1 (test for excess errors) FAIL: gfortran.dg/alloc_comp_assign_2.f90 -O2 (test for excess errors) FAIL: gfortran.dg/alloc_comp_assign_2.f90 -O3 -fomit-frame-pointer (test for excess errors) FAIL: gfortran.dg/alloc_comp_assign_2.f90 -O3 -fomit-frame-pointer -funroll-loops (test for excess errors) FAIL: gfortran.dg/alloc_comp_assign_2.f90 -O3 -fomit-frame-pointer -funroll-all-loops -finline-functions (test for excess errors) FAIL: gfortran.dg/alloc_comp_assign_8.f90 -O0 (test for excess errors) FAIL: gfortran.dg/alloc_comp_assign_2.f90 -O3 -g (test for excess errors) FAIL: gfortran.dg/alloc_comp_assign_8.f90 -O1 (test for excess errors) FAIL: gfortran.dg/alloc_comp_assign_2.f90 -Os (test for excess errors) FAIL: gfortran.dg/alloc_comp_assign_8.f90 -O2 (test for excess errors) FAIL: gfortran.dg/alloc_comp_assign_2.f90 -g -flto (test for excess errors) FAIL: gfortran.dg/alloc_comp_assign_8.f90 -O3 -fomit-frame-pointer (test for excess errors) FAIL: gfortran.dg/alloc_comp_assign_3.f90 -O0 (test for excess errors) FAIL: gfortran.dg/alloc_comp_assign_8.f90 -O3 -fomit-frame-pointer -funroll-loops (test for excess errors) FAIL: gfortran.dg/alloc_comp_assign_3.f90 -O1 (test for excess errors) FAIL: g
[Bug fortran/59016] f951: internal compiler error: Segmentation fault
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59016
--- Comment #18 from Dominique d'Humieres ---
With an additional filtering on (m == MATCH_ERROR), i.e. with the following
patch, the ICEs are fixed without regression
--- ../_clean/gcc/fortran/decl.c2015-03-25 14:07:04.0 +0100
+++ gcc/fortran/decl.c2015-04-05 16:17:34.0 +0200
@@ -4427,6 +4437,32 @@ ok:
gfc_free_data_all (gfc_current_ns);
cleanup:
+ // in gfc_match_data_decl; cleanup the garbages
+ gfc_symbol *csym = NULL;
+ if ((m == MATCH_ERROR) && current_ts.u.derived
+ && current_ts.u.derived->name)
+{
+ char iname[129];
+ iname[128] = 0;
+ for (int i = 0; i < 128; i++)
+{
+ iname[i] = current_ts.u.derived->name[i];
+ if (current_ts.u.derived->name[i] == 0)
+break;
+}
+ iname[0] = TOLOWER(iname[0]);
+ for (int i = 0; i < 4; i++)
+{
+ gfc_find_symbol (iname, NULL, i, &csym) ;
+ if (csym && csym->generic
+ && (csym->generic->sym == current_ts.u.derived))
+ {
+ csym->generic = NULL;
+ break;
+ }
+}
+}
+ //
gfc_free_array_spec (current_as);
current_as = NULL;
return m;
Further testing in progress. A few comments:
(1) The patch could probably be simplified,
(2) Its conformity with the GNU coding style has to be checked.
(3) It has to go to fort...@gcc.gnu.org and gcc-patc...@gcc.gnu.org for review.
[Bug sanitizer/65662] AddressSanitizer CHECK failed: ../../../../gcc/libsanitizer/sanitizer_common/sanitizer_allocator.h:835 "((res)) < ((kNumPossibleRegions))" (0x3ffb49, 0x80000)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65662 vekumar at gcc dot gnu.org changed: What|Removed |Added CC||vekumar at gcc dot gnu.org --- Comment #6 from vekumar at gcc dot gnu.org --- For 42 bit VA, I have to change the SANITIZER_MMAP_RANGE_SIZE to 1 <<42. Also compiler has to add the shadow offset instead of Oring it. I am planning to post a patch in LLVM. As Kostya said we can discuss in that thread.
[Bug fortran/59016] f951: internal compiler error: Segmentation fault
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59016 --- Comment #19 from drikosev at otenet dot gr --- Ok, I'll send a patch to the recommended addresses as soon as I read the GNU coding standards. Yet, my impression is that perhaps the patch should be a bit more complex; in example, I think that the generic interface is introduced to a list and one has to remove it and restore to old value of the field "generic" to the symbol. Also, I think that the additional test could be: "( m != MATCH_OK )" Thank you for your patience to run the tests.
[Bug fortran/59016] f951: internal compiler error: Segmentation fault
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59016 --- Comment #20 from Dominique d'Humieres --- > Also, I think that the additional test could be: "( m != MATCH_OK )" I don't think so: the block in the patch will be reached for (m == MATCH_NO) and I think this leads to the regressions.
[Bug middle-end/65665] [5.0 Regression]: g++.dg/torture/pr64378.C -O2 -flto -fno-use-linker-plugin -flto-partition=none
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65665 --- Comment #9 from Martin Liška --- Author: marxin Date: Sun Apr 5 17:17:29 2015 New Revision: 221872 URL: https://gcc.gnu.org/viewcvs?rev=221872&root=gcc&view=rev Log: Fix PR ipa/65665 PR ipa/65665 * ipa-icf.c (sem_function::equals_wpa): Verify that IPA CP has computed data structure. (sem_item_optimizer::update_hash_by_addr_refs): Likewise. Modified: trunk/gcc/ChangeLog trunk/gcc/ipa-icf.c
[Bug middle-end/65665] [5.0 Regression]: g++.dg/torture/pr64378.C -O2 -flto -fno-use-linker-plugin -flto-partition=none
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65665 Martin Liška changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #10 from Martin Liška --- Fixed in 5.0.
[Bug target/65535] powerpc64-freebsd build failure
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65535
Martin Sebor changed:
What|Removed |Added
Target|powerpc64-freebsd |*-*-freebsd
--- Comment #4 from Martin Sebor ---
This isn't powerpc64 specific. I didn't specify a FreeBSD version when
configuring gcc (i.e., I set --target=powerpc64-freebsd) assuming configure
would default to some supported version. The code in gcc/config.gcc then
results in FBSD_MAJOR being defined but empty. The patch below lets me build
stage1 (I don't have a FreeBSD sysroot to do a full bootstrap):
index cb08a5c..c668738 100644
--- a/gcc/config.gcc
+++ b/gcc/config.gcc
@@ -664,7 +664,7 @@ case ${target} in
gas=yes
gnu_ld=yes
fbsd_major=`echo ${target} | sed -e 's/.*freebsd//g' | sed -e 's/\..*//g'`
- tm_defines="${tm_defines} FBSD_MAJOR=${fbsd_major}"
+ tm_defines="${tm_defines} FBSD_MAJOR=${fbsd_major:-3}"
tmake_file="t-slibgcc"
case ${enable_threads} in
no)
If supplying a default version doesn't seem like a good idea another option
might be to fail early, during the configure step.
[Bug testsuite/65484] FAIL: g++.dg/vect/pr36648.cc on powerpc64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65484 Martin Sebor changed: What|Removed |Added Severity|minor |normal
[Bug testsuite/65484] FAIL: g++.dg/vect/pr36648.cc on powerpc64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65484 Martin Sebor changed: What|Removed |Added Severity|normal |minor
[Bug target/65535] powerpc64-freebsd build failure
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65535 Martin Sebor changed: What|Removed |Added Severity|normal |minor
[Bug target/65647] [5 Regression] GCC won't stop when compile for armv6-m
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65647 --- Comment #6 from Yvan Roux --- Author: yroux Date: Sun Apr 5 19:06:43 2015 New Revision: 221873 URL: https://gcc.gnu.org/viewcvs?rev=221873&root=gcc&view=rev Log: gcc/ 2015-04-05 Yvan Roux Backport from trunk r221867 2015-04-04 Vladimir Makarov PR target/65647 * lra.c (lra): Stop updating lra_constraint_new_regno_start after switching off inheritance. gcc/testsuite/ 2015-04-05 Yvan Roux Backport from trunk r221867 2015-04-04 Vladimir Makarov PR target/65647 * gcc.target/arm/pr65647.c: New. * gcc.target/arm/pr65647-2.c: New. Added: branches/gcc-4_9-branch/gcc/testsuite/gcc.target/arm/pr65647-2.c branches/gcc-4_9-branch/gcc/testsuite/gcc.target/arm/pr65647.c Modified: branches/gcc-4_9-branch/gcc/ChangeLog branches/gcc-4_9-branch/gcc/lra.c branches/gcc-4_9-branch/gcc/testsuite/ChangeLog
[Bug fortran/59016] f951: internal compiler error: Segmentation fault
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59016 --- Comment #21 from drikosev at otenet dot gr --- Created attachment 35232 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=35232&action=edit cleanup if a declaration type spec is erroneous Finally, I've sent for review to the recommended recipients the attached patch, which is suitable for gcc5.
[Bug c++/63579] New attribute for empty member optimization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63579 Marc Glisse changed: What|Removed |Added Attachment #33750|0 |1 is obsolete|| --- Comment #2 from Marc Glisse --- Created attachment 35233 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=35233&action=edit Handle empty members as bases Slight update to mark classes with only empty members as empty, and reject the attribute when it is applied to something that isn't a field declaration.
[Bug sanitizer/65662] AddressSanitizer CHECK failed: ../../../../gcc/libsanitizer/sanitizer_common/sanitizer_allocator.h:835 "((res)) < ((kNumPossibleRegions))" (0x3ffb49, 0x80000)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65662 --- Comment #7 from Jakub Jelinek --- (In reply to vekumar from comment #6) > For 42 bit VA, I have to change the SANITIZER_MMAP_RANGE_SIZE to 1 <<42. Sure. > Also compiler has to add the shadow offset instead of Oring it. You don't, see my patch. As I said, the hard part is making sure all 3 layouts work with the same libasan library - the problem is that the library assumes some decisions (like whether to use 32-bit or 64-bit allocator) have to be done at library compile time, when for aarch64 they really have to be done at runtime.
[Bug target/65647] [5 Regression] GCC won't stop when compile for armv6-m
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65647 --- Comment #7 from Jakub Jelinek --- So fixed?
[Bug target/65674] New: stack smashing protector must be controllable per-function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65674 Bug ID: 65674 Summary: stack smashing protector must be controllable per-function Product: gcc Version: unknown Status: UNCONFIRMED Severity: enhancement Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: stsp at users dot sourceforge.net Hello. On x86 (both 32 and 64), linux doesn't set FS and GS registers to the sane values when invoking the signal handler. Therefore the first thing the sig handler should do is to restore these registers if the program itself can ever modify them. Unfortunately gcc uses them in prolog/epilog for ssp, and so the "stack smashing detected". I think attribute "no_instrument_function" or "naked" should do that, but currently they don't, which is almost a bug, at least "no_instrument_function" is supported but doesn't give the desired effect. I can't even think of any reasonable work-around. For example I could do the small asm wrapper that restores these regs, but on x86_64 this is not enough: you need to set their base separately, via the prctl() syscall. Doing this all from asm is too nasty, I really think gcc should allow writing the proper sighandler.
[Bug fortran/59016] f951: internal compiler error: Segmentation fault
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59016 --- Comment #22 from drikosev at otenet dot gr --- Created attachment 35234 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=35234&action=edit cleanup if a declaration type spec is erroneous Let's see if the function names are properly printed into the context surrounding changes; the GNU patch guidelines suggest it!
[Bug ipa/65478] [5 regression] crafty performance regression
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65478 --- Comment #25 from Jan Hubicka --- Crafty perfomrance is back (with a combination of better heuristics and increase of inlining limits), eon is not, at least not in all configurations. We have separate eon PR, so I am closing this one.
[Bug sanitizer/65662] AddressSanitizer CHECK failed: ../../../../gcc/libsanitizer/sanitizer_common/sanitizer_allocator.h:835 "((res)) < ((kNumPossibleRegions))" (0x3ffb49, 0x80000)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65662 --- Comment #8 from vekumar at gcc dot gnu.org --- (In reply to Jakub Jelinek from comment #7) > (In reply to vekumar from comment #6) > > For 42 bit VA, I have to change the SANITIZER_MMAP_RANGE_SIZE to 1 <<42. > > Sure. > > > Also compiler has to add the shadow offset instead of Oring it. > > You don't, see my patch. > As I said, the hard part is making sure all 3 layouts work with the same > libasan library - the problem is that the library assumes some decisions > (like whether to use 32-bit or 64-bit allocator) have to be done at library > compile time, when for aarch64 they really have to be done at runtime. Hi Jakub, It was decided to make ASAN work for 42 bit VA without changing the default allocator (32bit) and the default shadow offset (1<<36). Please see thread https://groups.google.com/forum/#!topic/address-sanitizer/YzYRJEvVimw. On 42 bit VA with default settings, I found that some cases (LLVM ASAN tests) were failing because the compiler (LLVM) does Oring of shadow offset and ASAN library code adds the shadow offset. Both access resulted in valid memory and but we were poisoning the wrong shadow memory. Now your patch turns on the 64 bit allocator. I agree to do this we need to dynamically detect VA at runtime. Can you please join the thread and post your comments there.
[Bug libstdc++/65675] New: make bootstrap fails when configured with --disable-hosted-libstdcxx
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65675 Bug ID: 65675 Summary: make bootstrap fails when configured with --disable-hosted-libstdcxx Product: gcc Version: 4.8.4 Status: UNCONFIRMED Severity: blocker Priority: P3 Component: libstdc++ Assignee: unassigned at gcc dot gnu.org Reporter: ian at ianshome dot com Linux Ubuntu-14-04 3.13.0-46-generic ../gcc_4_8_4/configure --enable-cxx-flags=-fno-exceptions \ --prefix=/opt/gcc_4_8_4 \ --enable-languages=c,c++ \ --disable-hosted-libstdcxx make bootstrap ... Fails with: Entering directory `/mnt/gcc-build/gcc' /mnt/gcc-build/./prev-gcc/xg++ -B/mnt/gcc-build/./prev-gcc/ -B/opt/gcc_4_8_4/x86_64-unknown-linux-gnu/bin/ -nostdinc++ -B/mnt/gcc-build/prev-x86_64-unknown-linux-gnu/libstdc++-v3/src/.libs -B/mnt/gcc-build/prev-x86_64-unknown-linux-gnu/libstdc++-v3/libsupc++/.libs -I/mnt/gcc-build/prev-x86_64-unknown-linux-gnu/libstdc++-v3/include/x86_64-unknown-linux-gnu -I/mnt/gcc-build/prev-x86_64-unknown-linux-gnu/libstdc++-v3/include -I/mnt/gcc/libstdc++-v3/libsupc++ -L/mnt/gcc-build/prev-x86_64-unknown-linux-gnu/libstdc++-v3/src/.libs -L/mnt/gcc-build/prev-x86_64-unknown-linux-gnu/libstdc++-v3/libsupc++/.libs -g -O2 -gtoggle -DIN_GCC-fno-exceptions -fno-rtti -fasynchronous-unwind-tables -W -Wall -Wno-narrowing -Wwrite-strings -Wcast-qual -Wmissing-format-attribute -pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -DHAVE_CONFIG_H -DGENERATOR_FILE -static-libstdc++ -static-libgcc -o build/genmddeps \ build/genmddeps.o build/read-md.o build/errors.o .././libiberty/libiberty.a /usr/bin/ld: cannot find -lstdc++ collect2: error: ld returned 1 exit status make[3]: *** [build/genmddeps] Error 1 make[3]: Leaving directory `/mnt/gcc-build/gcc' make[2]: *** [all-stage2-gcc] Error 2 make[2]: Leaving directory `/mnt/gcc-build' make[1]: *** [stage2-bubble] Error 2 make[1]: Leaving directory `/mnt/gcc-build' make: *** [bootstrap] Error 2
