[Bug target/71208] [6 regression] mmix: C++ code fails to link

[yselkowi at redhat dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71208

--- Comment #10 from Yaakov Selkowitz  ---
A fix for PR ld/20125, set for the 2.29.1 release, has been committed.  Does
anything further need to happen on the gcc side?

[Bug bootstrap/79771] [7 Regression] in-tree zlib breaks build

[yselkowi at redhat dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79771

--- Comment #6 from Yaakov Selkowitz  ---
(In reply to Jakub Jelinek from comment #5)
> Do you really need even the zlib.def change?

For standalone zlib, yes; if you try to export a symbol which doesn't exist, ld
errors out.

> That part has been added 5 years ago, so it would surprise me if it didn't
> build even with that.

For standalone zlib, no, we've just been patching it out all this time.

Note that my patch was for the standalone zlib.  OTOH, in-tree zlib should be
built static-only, so zlib.def isn't used either way.

> If that works, the gzguts.h and zlib.h changes is something we can apply to
> gcc's copy until it is resolved upstream.

Ultimately, IMHO we should be encouraging --with-system-zlib on Cygwin (like
most other *NIX), but by all means, feel free to take the patch.

[Bug bootstrap/79771] [7 Regression] in-tree zlib breaks build

[yselkowi at redhat dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79771

--- Comment #4 from Yaakov Selkowitz  ---
This is an upstream issue in the recent zlib releases, here's a patch:

https://github.com/cygwinports/zlib/blob/master/1.2.11-gzopen_w.patch

Configuring with --with-system-zlib avoids this, as long as gcc doesn`t try
using the Win32-only gzopen_w on Cygwin (which it hasn't in the past).

[Bug other/77409] CVE-2016-4973 Targets using libssp for SSP are missing -D_FORTIFY_SOURCE functionality

[yselkowi at redhat dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77409

Yaakov Selkowitz  changed:

   What|Removed |Added

 Status|RESOLVED|UNCONFIRMED
 Resolution|INVALID |---

--- Comment #9 from Yaakov Selkowitz  ---
(In reply to Andrew Pinski from comment #7)
> This is a bug in newlib and MinGW (Cygwin and RTEMS uses newlib) rather than
> in GCC for not supporting -D_FORTIFY_SOURCE .  ssp should not be the one
> supplying this support (it just happens to does not mean it does for all
> things).

The entire point of libssp is to provide this support on systems whose libc
does not include it, so that both -D_FORTIFY_SOURCE and -fstack-protector*
functionality would be available cross-platform.

Also note that you can't say "just add it to libc" for either MinGW or
commercial *NIXs.

[Bug other/77409] CVE-2016-4973 Targets using libssp for SSP are missing -D_FORTIFY_SOURCE functionality

[yselkowi at redhat dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77409

--- Comment #8 from Yaakov Selkowitz  ---
(In reply to Andrew Pinski from comment #3)
> In fact this is by design.  NetBSD for an example has ssp/stdio.h where you
> use that to get the fority.

This does not apply where the libc provides its own SSP functionality.  In
fact, part of the fix for this will be noconfigdirs+=target-libssp on such
targets, as the libssp implementation conflicts.

(In reply to Andrew Pinski from comment #4)
> What I am trying to say is there is no security hole that this can cause,
> only the badly written applications where the security holes are located.

This was judged CVE worthy because a security barrier did not function as
expected.

> Also this looks like it was by design.

Then the design is poor, as it does not work.


(In reply to Andrew Pinski from comment #6)
> And really not true even for the current version of netbsd but they do:
> 1.70  kristerw  596: #if _FORTIFY_SOURCE > 0
> 1.69  tls   597: #include 
> 1.70  kristerw  598: #endif
> 
> http://cvsweb.netbsd.org/bsdweb.cgi/src/include/stdio.h#rev1.69
> 
> So again I don't see this as a bug but rather the person thinking
> -D_FORTIFY_SOURCE  works without including ssp/*.h on some targets.

No, as documented, the only necessary intervention is to define
_FORTIFY_SOURCE; the location of the headers is implementation specific.

[Bug other/77409] CVE-2016-4973 Targets using libssp for SSP are missing -D_FORTIFY_SOURCE functionality

[yselkowi at redhat dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77409

--- Comment #2 from Yaakov Selkowitz  ---
(In reply to Andrew Pinski from comment #1)
> I don't think this is a security hole at all.  In fact the security holes
> should be on the applications side rather than the library side.

The compiler is the cause and where this needs to be fixed first, therefore the
CVE was assigned to gcc.

[Bug other/77409] New: CVE-2016-4973 Targets using libssp for SSP are missing -D_FORTIFY_SOURCE functionality

[yselkowi at redhat dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77409

Bug ID: 77409
   Summary: CVE-2016-4973 Targets using libssp for SSP are missing
-D_FORTIFY_SOURCE functionality
   Product: gcc
   Version: 6.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: other
  Assignee: unassigned at gcc dot gnu.org
  Reporter: yselkowi at redhat dot com
CC: jon_y at users dot sourceforge.net, ktietz at gcc dot 
gnu.org
  Target Milestone: ---

Targets that use libssp for SSP (e.g. newlib, Cygwin, RTEMS, MinGW, but not
e.g. Glibc, Bionic, NetBSD which provide SSP in libc) are mistakenly missing
out on -D_FORTIFY_SOURCE functionality even when explicitly specified. The
problem is in gcc libssp/Makefile.am:

libsubincludedir =
$(libdir)/gcc/$(target_noncanonical)/$(gcc_version)/include
nobase_libsubinclude_HEADERS = ssp/ssp.h ssp/string.h ssp/stdio.h
ssp/unistd.h

Headers are structured so that they should be in $(libsubincludedir), instead
of $(libsubincludedir)/ssp where they are currently placed.

Demonstration:

$ cat fortify_test.c
/* example from bug 50460 */
#include 
#include 

const char *str1 = "JIHGFEDCBA";

int
main ()
{
struct A { char buf1[9]; char buf2[1]; } a;
strcpy (a.buf1 + (0 + 4), str1 + 5);
printf("%s %s\n", a.buf1, a.buf2);
return 0;
}

$ gcc -D_FORTIFY_SOURCE=2 -fstack-protector-strong -o fortify_test -O2
fortify_test.c
$ nm -C fortify_test | grep strcpy
U __strcpy_chk@@GLIBC_2.3.4

$ i686-w64-mingw32-gcc -D_FORTIFY_SOURCE=2 -fstack-protector-strong -o
fortify_test.exe -O2 fortify_test.c
$ i686-w64-mingw32-nm -C fortify_test.exe | grep strcpy
004061e8 I _imp__strcpy
00402624 T strcpy

If headers are moved, we can see:

$ i686-w64-mingw32-gcc -D_FORTIFY_SOURCE=2 -fstack-protector-strong -o
fortify_test.exe -O2 fortify_test.c
$ i686-w64-mingw32-nm -C fortify_test.exe | grep strcpy
00406200 I _impstrcpy_chk
00401590 T __strcpy_chk

Red Hat Product Security has assigned CVE-2016-4973 to this issue.

Further discussion: https://bugzilla.redhat.com/show_bug.cgi?id=1324759

[Bug target/71208] [6 regression] mmix: C++ code fails to link

[yselkowi at redhat dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71208

Yaakov Selkowitz  changed:

   What|Removed |Added

   See Also||https://sourceware.org/bugz
   ||illa/show_bug.cgi?id=20125

--- Comment #2 from Yaakov Selkowitz  ---
(In reply to Richard Biener from comment #1)
> Note this still looks like a binutils issue, so please report it against
> binutils as well.

Done: https://sourceware.org/bugzilla/show_bug.cgi?id=20125

Note that reverting to binutils 2.25.1 does not help either.

[Bug target/71208] New: [6 regression] mmix: C++ code fails to link

[yselkowi at redhat dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71208

Bug ID: 71208
   Summary: [6 regression] mmix: C++ code fails to link
   Product: gcc
   Version: 6.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: yselkowi at redhat dot com
  Target Milestone: ---
  Host: x86_64-cygwin
Target: mmix-knuth-mmixware
 Build: x86_64-cygwin

Created attachment 38530
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=38530&action=edit
Test case

Even simple C++ code fails to link when compiled with mmix g++ 6.1.0, binutils
2.26 and newlib 2.4.0:

$ mmix-g++ hello.cc
/usr/lib/gcc/mmix/6.1.0/../../../../mmix/bin/ld: BFD (GNU Binutils)
2.26.20160125 internal error, aborting at bfd/elf64-mmix.c:1043 in
mmix_elf_perform_relocation

Compiling with 5.3.0 (and the same binutils and newlib) succeeds.

[Bug libstdc++/71135] rl78-elf libstdc++ FTBFS with some multilibs

[yselkowi at redhat dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71135

--- Comment #5 from Yaakov Selkowitz  ---
Possible patch included in attachment 38505 for bug 71133.

[Bug libstdc++/71133] msp430-elf -mlarge FTBFS in libstdc++-v3

[yselkowi at redhat dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71133

--- Comment #1 from Yaakov Selkowitz  ---
Created attachment 38505
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=38505&action=edit
Draft patch for 6.1

The results of this test are (so far) used only in the code that will later
fail to compile on <32-bit-pointer targets anyway (bug 71135).  There's
probably a much better way of doing this, but the attached patch seems to be a
workaround.

[Bug libstdc++/71135] rl78-elf libstdc++ FTBFS with some multilibs

[yselkowi at redhat dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71135

--- Comment #4 from Yaakov Selkowitz  ---
(In reply to Yaakov Selkowitz from comment #3)
> It seems that #define _GLIBCXX_USE_WEAK_REF 1 would fix this; the question
> is where exactly it should go (config/os/generic/os_defines.h ?) and under
> what conditions.

Sorry, that should be #define _GLIBCXX_USE_WEAK_REF 0 and (due to
--with-newlib) in config/os/newlib/os_defines.h (which is already defined
inside an ifdef __CYGWIN__ block).

[Bug libstdc++/71135] rl78-elf libstdc++ FTBFS with some multilibs

[yselkowi at redhat dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71135

--- Comment #3 from Yaakov Selkowitz  ---
It seems that #define _GLIBCXX_USE_WEAK_REF 1 would fix this; the question is
where exactly it should go (config/os/generic/os_defines.h ?) and under what
conditions.

[Bug libstdc++/71135] rl78-elf libstdc++ FTBFS with some multilibs

[yselkowi at redhat dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71135

--- Comment #2 from Yaakov Selkowitz  ---
(In reply to Jonathan Wakely from comment #1)
> I think we just want to disable TM library support for such targets.

Okay, h8300-elf and xstormy16-elf are both similarly affected.  msp430-elf
probably will be as well once configure works again (bug 71133).

[Bug libstdc++/71135] New: rl78-elf libstdc++ FTBFS with some multilibs

[yselkowi at redhat dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71135

Bug ID: 71135
   Summary: rl78-elf libstdc++ FTBFS with some multilibs
   Product: gcc
   Version: 6.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: yselkowi at redhat dot com
  Target Milestone: ---
  Host: x86_64-cygwin
Target: rl78-elf
 Build: x86_64-cygwin

rl78-elf FTBFS in GCC 6.1 libstdc++-v3 (but not in recent 4.x or 5) due to
r232454:

src/c++11/cow-stdexcept.cc: In function ‘void* txnal_read_ptr(void* const*)’:
src/c++11/cow-stdexcept.cc:274:3: error: static assertion failed: Pointers must
be 32 bits or 64 bits wide
   static_assert(sizeof(uint64_t) == sizeof(void*)
   ^

rl78 has 16-bit pointers.

[Bug libstdc++/71133] New: msp430-elf -mlarge FTBFS in libstdc++-v3

[yselkowi at redhat dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71133

Bug ID: 71133
   Summary: msp430-elf -mlarge FTBFS in libstdc++-v3
   Product: gcc
   Version: 6.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: yselkowi at redhat dot com
  Target Milestone: ---

Building gcc 6.1.0 with newlib 2.4.0 for target msp430-elf fails during
configure-target-libstdc++-v3 in the 'large' multilib:

checking how size_t is mangled... x
configure: error: Unknown underlying type for size_t

Where the relevant information that GLIBCXX_CHECK_SIZE_T_MANGLING doesn't know
how to handle appears to be:

#define __SIZE_TYPE__ __int20 unsigned

[Bug target/64375] m32c ICE building newlib in calls.cL3638

[yselkowi at redhat dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64375

--- Comment #2 from Yaakov Selkowitz  ---
Still not working with 6.1.0 m32c-elf at calls.c:3679.

[Bug target/64400] iq2000-elf: ICE in dwarf2out_var_location, at dwarf2out.c:21266

[yselkowi at redhat dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64400

Yaakov Selkowitz  changed:

   What|Removed |Added

Version|5.2.0   |6.1.0

--- Comment #2 from Yaakov Selkowitz  ---
Issue remains in 6.1.0, now at dwarf2out.c:24439.

[Bug target/21530] libstdc++ not supported on h8

[yselkowi at redhat dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=21530

Yaakov Selkowitz  changed:

   What|Removed |Added

 CC||yselkowi at redhat dot com

--- Comment #9 from Yaakov Selkowitz  ---
This is also an issue with h8300-elf in GCC 6 (but not in later 4.x or 5) due
to r232454.

[Bug libstdc++/51749] Including pollutes global namespace

[yselkowi at redhat dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=51749

--- Comment #32 from Yaakov Selkowitz  ---
In an effort to enable C99-in-C++ functionality on newlib-based targets
(including Cygwin and RTEMS), we just overhauled our feature test macros to be
functionally compatible with glibc's.  Ignoring the lack of missing long double
real and complex math functions (which are anyways guarded separately), we were
able to thereby enable the rest of _GLIBCXX_USE_C99* functionality without the
-D_GNU_SOURCE hack.

Our approach was (in glibc terms):

* enable __USE_ISOC99 in features.h if defined(__cplusplus), for C99-in-TR1;

* enable __USE_ISOC11 in features.h if __cplusplus >= 201103L, for *quick_exit
in C++11.

* define the _POSIX_* capability macros in  regardless of
__USE_POSIX*, for gthr-posix.h.

Note that the public -D_ISOC*_SOURCE macros were NOT defined in g++.

However, we don't need ftello64 (Cygwin's off_t is naturally 64-bit) nor do we
have the locale_t group of functions, which according to the Linux man-pages
are SUSv4.  These functions may be best served by their own special guards.

[Bug target/65501] [5 Regression] v850 ICE at c_register_pragma_1, at c-family/c-pragma.c:1317

[yselkowi at redhat dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65501

--- Comment #6 from Yaakov Selkowitz  ---
Created attachment 37849
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=37849&action=edit
patch for gcc-5

(In reply to Jeffrey A. Law from comment #5)
> Fixed on the trunk by the change for 68271.  I'm not currently planning to
> backport to gcc-5.

Thanks, those commits fixed the build of v850-elf.  I'm attaching a backport
for 5.3.0 in case anyone wants it.

[Bug target/64402] mep-elf ICE in pre_and_rev_post_order_compute, at cfganal.c:1022

[yselkowi at redhat dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64402

--- Comment #4 from Yaakov Selkowitz  ---
(In reply to Bernd Edlinger from comment #3)
> Created attachment 37172 [details]
> Patch to fix ICE and make interrupt restore r0

That allows me to finish the --without-headers build of 5.3.0 and subsequently
build newlib.  However, once I rebuild gcc *with* newlib installed, I get:

/usr/src/ports/cross-gcc/cross-gcc-5.3.0-1.x86_64/build/mep-elf/./gcc/xgcc
-B/usr/src/ports/cross-gcc/cross-gcc-5.3.0-1.x86_64/build/mep-elf/./gcc/
-B/usr/mep-elf/bin/ -B/usr/mep-elf/lib/ -isystem /usr/mep-elf/include -isystem
/usr/mep-elf/sys-include -mlibrary-g -O2 -mel -O2  -g -O2 -DIN_GCC 
-DCROSS_DIRECTORY_STRUCTURE  -W -Wall -Wno-narrowing -Wwrite-strings
-Wcast-qual -Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition 
-isystem ./include -mlibrary  -g -DIN_LIBGCC2 -fbuilding-libgcc
-fno-stack-protector   -I. -I. -I../../.././gcc
-I/usr/src/ports/cross-gcc/cross-gcc-5.3.0-1.x86_64/src/gcc-5.3.0/libgcc
-I/usr/src/ports/cross-gcc/cross-gcc-5.3.0-1.x86_64/src/gcc-5.3.0/libgcc/.
-I/usr/src/ports/cross-gcc/cross-gcc-5.3.0-1.x86_64/src/gcc-5.3.0/libgcc/../gcc
-I/usr/src/ports/cross-gcc/cross-gcc-5.3.0-1.x86_64/src/gcc-5.3.0/libgcc/../include
 -DHAVE_CC_TLS -DUSE_EMUTLS -o _gcov_indirect_call_topn_profiler.o -MT
_gcov_indirect_call_topn_profiler.o -MD -MP -MF
_gcov_indirect_call_topn_profiler.dep -DL_gcov_indirect_call_topn_profiler -c
/usr/src/ports/cross-gcc/cross-gcc-5.3.0-1.x86_64/src/gcc-5.3.0/libgcc/libgcov-profiler.c
/usr/src/ports/cross-gcc/cross-gcc-5.3.0-1.x86_64/src/gcc-5.3.0/libgcc/libgcov-profiler.c:
In function ‘__gcov_topn_value_profiler_body’:
/usr/src/ports/cross-gcc/cross-gcc-5.3.0-1.x86_64/src/gcc-5.3.0/libgcc/libgcov-profiler.c:194:1:
internal compiler error: in create_trace_edges, at dwarf2cfi.c:2409
 }
 ^
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.
Makefile:880: recipe for target '_gcov_indirect_call_topn_profiler.o' failed
make[4]: *** [_gcov_indirect_call_topn_profiler.o] Error 1

[Bug target/65501] [5/6 Regression] v850 ICE at c_register_pragma_1, at c-family/c-pragma.c:1317

[yselkowi at redhat dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65501

Yaakov Selkowitz  changed:

   What|Removed |Added

 CC||yselkowi at redhat dot com

--- Comment #3 from Yaakov Selkowitz  ---
This does indeed occur on v850-elf with 5.2.

[Bug target/67061] sh64-elf: internal compiler error: in sh_find_set_of_reg, at config/sh/sh-protos.h:235

[yselkowi at redhat dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67061

--- Comment #3 from Yaakov Selkowitz  ---
(In reply to Kazumoto Kojima from comment #2)
> Does the patch below work?

Yes, this patch in combination of that from bug 67049 allows me to complete the
sh64-elf toolchain and does not break the sh-elf toolchain.  Thank you for your
assistance.

[Bug target/67049] sh64-elf: internal compiler error: in df_uses_record, at df-scan.c:3001

[yselkowi at redhat dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67049

--- Comment #2 from Yaakov Selkowitz  ---
(In reply to Kazumoto Kojima from comment #1)
> My bad.  Could you please try this patch?

That gets me through libgcc, but when I get to newlib I see bug 67061.

[Bug target/67061] New: sh64-elf: internal compiler error: in sh_find_set_of_reg, at config/sh/sh-protos.h:235

[yselkowi at redhat dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67061

Bug ID: 67061
   Summary: sh64-elf: internal compiler error: in
sh_find_set_of_reg, at config/sh/sh-protos.h:235
   Product: gcc
   Version: 5.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: yselkowi at redhat dot com
  Target Milestone: ---
  Host: x86_64-cygwin
Target: sh64-elf
 Build: x86_64-cygwin

After the proposed fix to bug 67049, I see the following when building
newlib-2.2.0.20150623 for sh64-elf with gcc-5.2.0:

sh64-elf-gcc
-B/usr/src/ports/cross-newlib/cross-newlib-2.2.0.20150623-1.x86_64/build/sh64-elf/sh64-elf/m5-compact-nofpu/newlib/
-isystem
/usr/src/ports/cross-newlib/cross-newlib-2.2.0.20150623-1.x86_64/build/sh64-elf/sh64-elf/m5-compact-nofpu/newlib/targ-include
-isystem
/usr/src/ports/cross-newlib/cross-newlib-2.2.0.20150623-1.x86_64/src/newlib-2.2.0.20150623/newlib/libc/include
-B/usr/src/ports/cross-newlib/cross-newlib-2.2.0.20150623-1.x86_64/build/sh64-elf/sh64-elf/m5-compact-nofpu/libgloss/sh64
-L/usr/src/ports/cross-newlib/cross-newlib-2.2.0.20150623-1.x86_64/build/sh64-elf/sh64-elf/m5-compact-nofpu/libgloss/libnosys
-L/usr/src/ports/cross-newlib/cross-newlib-2.2.0.20150623-1.x86_64/src/newlib-2.2.0.20150623/libgloss/sh64
 -m5-compact-nofpu -DPACKAGE_NAME=\"newlib\" -DPACKAGE_TARNAME=\"newlib\"
-DPACKAGE_VERSION=\"2.2.0\" -DPACKAGE_STRING=\"newlib\ 2.2.0\"
-DPACKAGE_BUGREPORT=\"\" -DPACKAGE_URL=\"\" -I.
-I/usr/src/ports/cross-newlib/cross-newlib-2.2.0.20150623-1.x86_64/src/newlib-2.2.0.20150623/newlib/libc/stdlib
-fno-builtin  -g -ggdb -O2 -pipe -Wimplicit-function-declaration
-fdebug-prefix-map=/usr/src/ports/cross-newlib/cross-newlib-2.2.0.20150623-1.x86_64/build=/usr/src/debug/cross-newlib-2.2.0.20150623-1
-fdebug-prefix-map=/usr/src/ports/cross-newlib/cross-newlib-2.2.0.20150623-1.x86_64/src/newlib-2.2.0.20150623=/usr/src/debug/cross-newlib-2.2.0.20150623-1
 -m5-compact-nofpu -c -o lib_a-strtod.o `test -f 'strtod.c' || echo
'/usr/src/ports/cross-newlib/cross-newlib-2.2.0.20150623-1.x86_64/src/newlib-2.2.0.20150623/newlib/libc/stdlib/'`strtod.c
/usr/src/ports/cross-newlib/cross-newlib-2.2.0.20150623-1.x86_64/src/newlib-2.2.0.20150623/newlib/libc/stdlib/strtod.c:
In function ‘strtof’:
/usr/src/ports/cross-newlib/cross-newlib-2.2.0.20150623-1.x86_64/src/newlib-2.2.0.20150623/newlib/libc/stdlib/strtod.c:1272:1:
internal compiler error: in sh_find_set_of_reg, at config/sh/sh-protos.h:235
 }
 ^
Please submit a full bug report,
with preprocessed source if appropriate.
See <http://gcc.gnu.org/bugs.html> for instructions.
Makefile:874: recipe for target 'lib_a-strtod.o' failed
make[8]: *** [lib_a-strtod.o] Error 1
sh64-elf-gcc
-B/usr/src/ports/cross-newlib/cross-newlib-2.2.0.20150623-1.x86_64/build/sh64-elf/sh64-elf/m5-compact-nofpu/newlib/
-isystem
/usr/src/ports/cross-newlib/cross-newlib-2.2.0.20150623-1.x86_64/build/sh64-elf/sh64-elf/m5-compact-nofpu/newlib/targ-include
-isystem
/usr/src/ports/cross-newlib/cross-newlib-2.2.0.20150623-1.x86_64/src/newlib-2.2.0.20150623/newlib/libc/include
-B/usr/src/ports/cross-newlib/cross-newlib-2.2.0.20150623-1.x86_64/build/sh64-elf/sh64-elf/m5-compact-nofpu/libgloss/sh64
-L/usr/src/ports/cross-newlib/cross-newlib-2.2.0.20150623-1.x86_64/build/sh64-elf/sh64-elf/m5-compact-nofpu/libgloss/libnosys
-L/usr/src/ports/cross-newlib/cross-newlib-2.2.0.20150623-1.x86_64/src/newlib-2.2.0.20150623/libgloss/sh64
 -m5-compact-nofpu -DPACKAGE_NAME=\"newlib\" -DPACKAGE_TARNAME=\"newlib\"
-DPACKAGE_VERSION=\"2.2.0\" -DPACKAGE_STRING=\"newlib\ 2.2.0\"
-DPACKAGE_BUGREPORT=\"\" -DPACKAGE_URL=\"\" -I.
-I/usr/src/ports/cross-newlib/cross-newlib-2.2.0.20150623-1.x86_64/src/newlib-2.2.0.20150623/newlib/libc/stdlib
-fno-builtin  -g -ggdb -O2 -pipe -Wimplicit-function-declaration
-fdebug-prefix-map=/usr/src/ports/cross-newlib/cross-newlib-2.2.0.20150623-1.x86_64/build=/usr/src/debug/cross-newlib-2.2.0.20150623-1
-fdebug-prefix-map=/usr/src/ports/cross-newlib/cross-newlib-2.2.0.20150623-1.x86_64/src/newlib-2.2.0.20150623=/usr/src/debug/cross-newlib-2.2.0.20150623-1
 -m5-compact-nofpu -c -o lib_a-wcstod.o `test -f 'wcstod.c' || echo
'/usr/src/ports/cross-newlib/cross-newlib-2.2.0.20150623-1.x86_64/src/newlib-2.2.0.20150623/newlib/libc/stdlib/'`wcstod.c
/usr/src/ports/cross-newlib/cross-newlib-2.2.0.20150623-1.x86_64/src/newlib-2.2.0.20150623/newlib/libc/stdlib/wcstod.c:
In function ‘_wcstof_r’:
/usr/src/ports/cross-newlib/cross-newlib-2.2.0.20150623-1.x86_64/src/newlib-2.2.0.20150623/newlib/libc/stdlib/wcstod.c:210:1:
internal compiler error: in sh_find_set_of_reg, at config/sh/sh-protos.h:235
 }
 ^
Please submit a 

[Bug libgcc/64401] avr-elf crtbegin.o fails to compile

[yselkowi at redhat dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64401

Yaakov Selkowitz  changed:

   What|Removed |Added

 Status|WAITING |RESOLVED
 Resolution|--- |FIXED

--- Comment #2 from Yaakov Selkowitz  ---
Fixed sometime prior to 5.2.

[Bug target/64424] cr16-elf ICE in gen_rtx_SUBREG, at emit-rtl.c:748

[yselkowi at redhat dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64424

Yaakov Selkowitz  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |FIXED

--- Comment #1 from Yaakov Selkowitz  ---
Apparently fixed sometime prior to 5.2.

[Bug target/64403] m32c-elf ICE in final_scan_insn, at final.c:2891 with -mcpu=m32cm and cleanup

[yselkowi at redhat dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64403

Yaakov Selkowitz  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |FIXED

--- Comment #1 from Yaakov Selkowitz  ---
Fixed sometime prior to 5.2.

[Bug target/67049] New: sh64-elf: internal compiler error: in df_uses_record, at df-scan.c:3001

[yselkowi at redhat dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67049

Bug ID: 67049
   Summary: sh64-elf: internal compiler error: in df_uses_record,
at df-scan.c:3001
   Product: gcc
   Version: 5.2.0
Status: UNCONFIRMED
  Keywords: ice-on-valid-code
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: yselkowi at redhat dot com
  Target Milestone: ---
  Host: x86_64-cygwin
Target: sh64-elf
 Build: x86_64-cygwin

The following occurred when building 5.2.0 --target=sh64-elf --without-headers:

/usr/src/ports/cross-gcc/cross-gcc-5.2.0-1.x86_64/build/sh64-elf/./gcc/xgcc
-B/usr/src/ports/cross-gcc/cross-gcc-5.2.0-1.x86_64/build/sh64-elf/./gcc/
-B/usr/sh64-elf/bin/ -B/usr/sh64-elf/lib/ -isystem /usr/sh64-elf/include
-isystem /usr/sh64-elf/sys-include-g -O2 -ml -O2 -g -O2 -DIN_GCC 
-DCROSS_DIRECTORY_STRUCTURE  -W -Wall -Wno-narrowing -Wwrite-strings
-Wcast-qual -Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition 
-isystem ./include  -I. -I. -I../../.././gcc
-I/usr/src/ports/cross-gcc/cross-gcc-5.2.0-1.x86_64/src/gcc-5.2.0/libgcc
-I/usr/src/ports/cross-gcc/cross-gcc-5.2.0-1.x86_64/src/gcc-5.2.0/libgcc/.
-I/usr/src/ports/cross-gcc/cross-gcc-5.2.0-1.x86_64/src/gcc-5.2.0/libgcc/../gcc
-I/usr/src/ports/cross-gcc/cross-gcc-5.2.0-1.x86_64/src/gcc-5.2.0/libgcc/../include
  -g0 -finhibit-size-directive -fno-inline -fno-exceptions
-fno-zero-initialized-in-bss -fno-toplevel-reorder -fno-tree-vectorize
-fbuilding-libgcc -fno-stack-protector  -Dinhibit_libc -I. -I. -I../../.././gcc
-I/usr/src/ports/cross-gcc/cross-gcc-5.2.0-1.x86_64/src/gcc-5.2.0/libgcc
-I/usr/src/ports/cross-gcc/cross-gcc-5.2.0-1.x86_64/src/gcc-5.2.0/libgcc/.
-I/usr/src/ports/cross-gcc/cross-gcc-5.2.0-1.x86_64/src/gcc-5.2.0/libgcc/../gcc
-I/usr/src/ports/cross-gcc/cross-gcc-5.2.0-1.x86_64/src/gcc-5.2.0/libgcc/../include
 -o crtbeginS.o -MT crtbeginS.o -MD -MP -MF crtbeginS.dep  -fPIC -c
/usr/src/ports/cross-gcc/cross-gcc-5.2.0-1.x86_64/src/gcc-5.2.0/libgcc/crtstuff.c
-DCRT_BEGIN -DCRTSTUFFS_O
/usr/src/ports/cross-gcc/cross-gcc-5.2.0-1.x86_64/src/gcc-5.2.0/libgcc/crtstuff.c:
In function ‘deregister_tm_clones’:
/usr/src/ports/cross-gcc/cross-gcc-5.2.0-1.x86_64/src/gcc-5.2.0/libgcc/crtstuff.c:303:1:
internal compiler error: in df_uses_record, at df-scan.c:3001
 }
 ^
Please submit a full bug report,
with preprocessed source if appropriate.
See <http://gcc.gnu.org/bugs.html> for instructions.
Makefile:990: recipe for target 'crtbeginS.o' failed
make[4]: *** [crtbeginS.o] Error 1
/usr/src/ports/cross-gcc/cross-gcc-5.2.0-1.x86_64/build/sh64-elf/./gcc/xgcc
-B/usr/src/ports/cross-gcc/cross-gcc-5.2.0-1.x86_64/build/sh64-elf/./gcc/
-B/usr/sh64-elf/bin/ -B/usr/sh64-elf/lib/ -isystem /usr/sh64-elf/include
-isystem /usr/sh64-elf/sys-include-g -O2 -ml -O2 -g -O2 -DIN_GCC 
-DCROSS_DIRECTORY_STRUCTURE  -W -Wall -Wno-narrowing -Wwrite-strings
-Wcast-qual -Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition 
-isystem ./include  -I. -I. -I../../.././gcc
-I/usr/src/ports/cross-gcc/cross-gcc-5.2.0-1.x86_64/src/gcc-5.2.0/libgcc
-I/usr/src/ports/cross-gcc/cross-gcc-5.2.0-1.x86_64/src/gcc-5.2.0/libgcc/.
-I/usr/src/ports/cross-gcc/cross-gcc-5.2.0-1.x86_64/src/gcc-5.2.0/libgcc/../gcc
-I/usr/src/ports/cross-gcc/cross-gcc-5.2.0-1.x86_64/src/gcc-5.2.0/libgcc/../include
  -g0 -finhibit-size-directive -fno-inline -fno-exceptions
-fno-zero-initialized-in-bss -fno-toplevel-reorder -fno-tree-vectorize
-fbuilding-libgcc -fno-stack-protector  -Dinhibit_libc -I. -I. -I../../.././gcc
-I/usr/src/ports/cross-gcc/cross-gcc-5.2.0-1.x86_64/src/gcc-5.2.0/libgcc
-I/usr/src/ports/cross-gcc/cross-gcc-5.2.0-1.x86_64/src/gcc-5.2.0/libgcc/.
-I/usr/src/ports/cross-gcc/cross-gcc-5.2.0-1.x86_64/src/gcc-5.2.0/libgcc/../gcc
-I/usr/src/ports/cross-gcc/cross-gcc-5.2.0-1.x86_64/src/gcc-5.2.0/libgcc/../include
 -o crtendS.o -MT crtendS.o -MD -MP -MF crtendS.dep  -fPIC -c
/usr/src/ports/cross-gcc/cross-gcc-5.2.0-1.x86_64/src/gcc-5.2.0/libgcc/crtstuff.c
-DCRT_END -DCRTSTUFFS_O
/usr/src/ports/cross-gcc/cross-gcc-5.2.0-1.x86_64/src/gcc-5.2.0/libgcc/crtstuff.c:
In function ‘__do_global_ctors_aux’:
/usr/src/ports/cross-gcc/cross-gcc-5.2.0-1.x86_64/src/gcc-5.2.0/libgcc/crtstuff.c:708:1:
internal compiler error: in df_uses_record, at df-scan.c:3001
 }
 ^
Please submit a full bug report,
with preprocessed source if appropriate.
See <http://gcc.gnu.org/bugs.html> for instructions.
Makefile:993: recipe for target 'crtendS.o' failed
make[4]: *** [crtendS.o] Error 1
dest=../../.././gcc/include/tmp$$-unwind.h; \
cp unwind.h $dest; \
chmod a+r $dest; \
sh
/usr/src/ports/cross-gcc/cross-gcc-5.2.0-1.x86_64/src/gcc-5.2.0/libgcc/../move-if-change
$dest ../../.././gcc/include/unwind.h
make[4]: Target 'all' not remade because of errors.
make[4]: Leaving directory
'/usr/src

[Bug target/64375] m32c ICE building newlib in calls.cL3638

[yselkowi at redhat dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64375

Yaakov Selkowitz  changed:

   What|Removed |Added

 CC||yselkowi at redhat dot com

--- Comment #1 from Yaakov Selkowitz  ---
Ditto for 5.2.0 m32c-elf at calls.c:3681.

[Bug target/64402] mep-elf ICE in pre_and_rev_post_order_compute, at cfganal.c:1022

[yselkowi at redhat dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64402

Yaakov Selkowitz  changed:

   What|Removed |Added

Version|4.9.2   |5.2.0

--- Comment #1 from Yaakov Selkowitz  ---
Same in 5.2.0, at cfganal.c:1033.

[Bug target/64400] iq2000-elf: ICE in dwarf2out_var_location, at dwarf2out.c:21266

[yselkowi at redhat dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64400

Yaakov Selkowitz  changed:

   What|Removed |Added

Version|4.9.2   |5.2.0

--- Comment #1 from Yaakov Selkowitz  ---
Same issue in 5.2.0; error is now reported at dwarf2out.c:21837.

[Bug target/64408] fr30-elf ICE in extract_insn, at recog.c:2202

[yselkowi at redhat dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64408

--- Comment #3 from Yaakov Selkowitz  ---
(In reply to Nick Clifton from comment #2)
> Fixed by:
> 
> https://gcc.gnu.org/ml/gcc-patches/2015-02/msg00247.html

Fix confirmed with 4.9.2; thanks.

[Bug target/57295] target c6x-elf // internal compiler error: in extract_insn, at recog.c:2150

[yselkowi at redhat dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57295

--- Comment #4 from Yaakov Selkowitz  ---
This still occurs with 4.9.2, and the patch in comment 2 fixes it.

[Bug target/64451] tic6x-elf: ICE in extract_insn, at recog.c:2202

[yselkowi at redhat dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64451

Yaakov Selkowitz  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |DUPLICATE

--- Comment #3 from Yaakov Selkowitz  ---
(In reply to Wojciech Migda from comment #2)
> Can you please check if this patch fixes your problem?
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57295#c2
> A suspect a duplicate. An attachment with a failing code would be welcome.

You are correct, this is a dup and that patch fixes it, thank you.

*** This bug has been marked as a duplicate of bug 57295 ***

[Bug target/57295] target c6x-elf // internal compiler error: in extract_insn, at recog.c:2150

[yselkowi at redhat dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57295

Yaakov Selkowitz  changed:

   What|Removed |Added

 CC||yselkowi at redhat dot com

--- Comment #3 from Yaakov Selkowitz  ---
*** Bug 64451 has been marked as a duplicate of this bug. ***

[Bug target/63681] ICE in cfg_layout_initialize, at cfgrtl.c:4233

[yselkowi at redhat dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63681

--- Comment #6 from Yaakov Selkowitz  ---
(In reply to Mikael Pettersson from comment #5)
> The ICE on bfin-elf started for 4.9 with r204985, and stopped for 5.0 with
> r210683.  Backporting r210683 to current 4.9 branch is easy and fixes the
> ICE there too.  I haven't checked c6x.

r210683 fixes this particular issue in 4.9.2 for both bfin-elf and tic6x-elf. 
(There is another, seemingly unrelated issue with the latter, see bug 64451.) 
Any chance this could get into 4.9.3?

[Bug target/64451] New: tic6x-elf: ICE in extract_insn, at recog.c:2202

[yselkowi at redhat dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64451

Bug ID: 64451
   Summary: tic6x-elf: ICE in extract_insn, at recog.c:2202
   Product: gcc
   Version: 4.9.2
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: yselkowi at redhat dot com

While building gcc-4.9.2 --target=tic6x-elf with newlib-2.2.0:

libtool: compile: 
/usr/src/ports/cross-gcc/cross-gcc-4.9.2-1.x86_64/build/tic6x-elf/./gcc/xgcc
-B/usr/src/ports/cross-gcc/cross-gcc-4.9.2-1.x86_64/build/tic6x-elf/./gcc/
-B/usr/tic6x-elf/bin/ -B/usr/tic6x-elf/lib/ -isystem /usr/tic6x-elf/include
-isystem /usr/tic6x-elf/sys-include -DHAVE_CONFIG_H -I.
-I/usr/src/ports/cross-gcc/cross-gcc-4.9.2-1.x86_64/src/gcc-4.9.2/libssp -Wall
-g -ggdb -O2 -pipe -Wimplicit-function-declaration -MT ssp.lo -MD -MP -MF
.deps/ssp.Tpo -c
/usr/src/ports/cross-gcc/cross-gcc-4.9.2-1.x86_64/src/gcc-4.9.2/libssp/ssp.c -o
ssp.o
/usr/src/ports/cross-gcc/cross-gcc-4.9.2-1.x86_64/src/gcc-4.9.2/libssp/ssp.c:
In function ‘fail.isra.0’:
/usr/src/ports/cross-gcc/cross-gcc-4.9.2-1.x86_64/src/gcc-4.9.2/libssp/ssp.c:163:1:
error: unrecognizable insn:
 }
 ^
(insn 111 110 112 16 (set (mem/v:SI (reg/f:SI 111) [3 MEM[(volatile int
*)4294967295B]+0 S4 A8])
(unspec:SI [
(reg:SI 112)
] UNSPEC_MISALIGNED_ACCESS))
/usr/src/ports/cross-gcc/cross-gcc-4.9.2-1.x86_64/src/gcc-4.9.2/libssp/ssp.c:156
-1
 (nil))
/usr/src/ports/cross-gcc/cross-gcc-4.9.2-1.x86_64/src/gcc-4.9.2/libssp/ssp.c:163:1:
internal compiler error: in extract_insn, at recog.c:2202

[Bug target/64424] New: cr16-elf ICE in gen_rtx_SUBREG, at emit-rtl.c:748

[yselkowi at redhat dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64424

Bug ID: 64424
   Summary: cr16-elf ICE in gen_rtx_SUBREG, at emit-rtl.c:748
   Product: gcc
   Version: 4.9.2
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: yselkowi at redhat dot com
  Host: x86_64-cygwin
Target: cr16-elf
 Build: x86_64-cygwin

While compiling gcc-4.9.2 --target=cr16-elf with binutils-2.25 and newlib-2.2.0

libtool: compile: 
/usr/src/ports/cross-gcc/cross-gcc-4.9.2-1.x86_64/build/cr16-elf/./gcc/xgcc
-shared-libgcc
-B/usr/src/ports/cross-gcc/cross-gcc-4.9.2-1.x86_64/build/cr16-elf/./gcc
-nostdinc++
-L/usr/src/ports/cross-gcc/cross-gcc-4.9.2-1.x86_64/build/cr16-elf/cr16-elf/libstdc++-v3/src
-L/usr/src/ports/cross-gcc/cross-gcc-4.9.2-1.x86_64/build/cr16-elf/cr16-elf/libstdc++-v3/src/.libs
-L/usr/src/ports/cross-gcc/cross-gcc-4.9.2-1.x86_64/build/cr16-elf/cr16-elf/libstdc++-v3/libsupc++/.libs
-B/usr/cr16-elf/bin/ -B/usr/cr16-elf/lib/ -isystem /usr/cr16-elf/include
-isystem /usr/cr16-elf/sys-include
-I/usr/src/ports/cross-gcc/cross-gcc-4.9.2-1.x86_64/src/gcc-4.9.2/libstdc++-v3/../libgcc
-I/usr/src/ports/cross-gcc/cross-gcc-4.9.2-1.x86_64/build/cr16-elf/cr16-elf/libstdc++-v3/include/cr16-elf
-I/usr/src/ports/cross-gcc/cross-gcc-4.9.2-1.x86_64/build/cr16-elf/cr16-elf/libstdc++-v3/include
-I/usr/src/ports/cross-gcc/cross-gcc-4.9.2-1.x86_64/src/gcc-4.9.2/libstdc++-v3/libsupc++
-fno-implicit-templates -Wall -Wextra -Wwrite-strings -Wcast-qual -Wabi
-fdiagnostics-show-location=once -ffunction-sections -fdata-sections
-frandom-seed=ctype.lo -g -ggdb -O2 -pipe -c
/usr/src/ports/cross-gcc/cross-gcc-4.9.2-1.x86_64/src/gcc-4.9.2/libstdc++-v3/src/c++98/ctype.cc
-o ctype.o
/usr/src/ports/cross-gcc/cross-gcc-4.9.2-1.x86_64/src/gcc-4.9.2/libstdc++-v3/src/c++98/ctype.cc:
In member function ‘void std::ctype::_M_narrow_init() const’:
/usr/src/ports/cross-gcc/cross-gcc-4.9.2-1.x86_64/src/gcc-4.9.2/libstdc++-v3/src/c++98/ctype.cc:84:3:
internal compiler error: in gen_rtx_SUBREG, at emit-rtl.c:748
   }
   ^

[Bug target/64408] New: fr30-elf ICE in extract_insn, at recog.c:2202

[yselkowi at redhat dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64408

Bug ID: 64408
   Summary: fr30-elf ICE in extract_insn, at recog.c:2202
   Product: gcc
   Version: 4.9.2
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: yselkowi at redhat dot com
  Host: x86_64-cygwin
Target: fr30-elf
 Build: x86_64-cygwin

Created attachment 34334
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=34334&action=edit
preprocessed source

While compiling newlib-2.2.0 with gcc-4.9.2 --target=fr30-elf:

fr30-elf-gcc
-B/usr/src/ports/cross-newlib/cross-newlib-2.2.0-1.x86_64/build/fr30-elf/fr30-elf/newlib/
-isystem
/usr/src/ports/cross-newlib/cross-newlib-2.2.0-1.x86_64/build/fr30-elf/fr30-elf/newlib/targ-include
-isystem
/usr/src/ports/cross-newlib/cross-newlib-2.2.0-1.x86_64/src/newlib-2.2.0/newlib/libc/include
-B/usr/src/ports/cross-newlib/cross-newlib-2.2.0-1.x86_64/build/fr30-elf/fr30-elf/libgloss/fr30
-L/usr/src/ports/cross-newlib/cross-newlib-2.2.0-1.x86_64/build/fr30-elf/fr30-elf/libgloss/libnosys
-L/usr/src/ports/cross-newlib/cross-newlib-2.2.0-1.x86_64/src/newlib-2.2.0/libgloss/fr30
   -DPACKAGE_NAME=\"newlib\" -DPACKAGE_TARNAME=\"newlib\"
-DPACKAGE_VERSION=\"2.2.0\" -DPACKAGE_STRING=\"newlib\ 2.2.0\"
-DPACKAGE_BUGREPORT=\"\" -DPACKAGE_URL=\"\" -I.
-I/usr/src/ports/cross-newlib/cross-newlib-2.2.0-1.x86_64/src/newlib-2.2.0/newlib/libc/stdlib
-fno-builtin  -g -Os -c -o lib_a-dtoa.o `test -f 'dtoa.c' || echo
'/usr/src/ports/cross-newlib/cross-newlib-2.2.0-1.x86_64/src/newlib-2.2.0/newlib/libc/stdlib/'`dtoa.c
/usr/src/ports/cross-newlib/cross-newlib-2.2.0-1.x86_64/src/newlib-2.2.0/newlib/libc/stdlib/dtoa.c:
In function ‘_dtoa_r’:
/usr/src/ports/cross-newlib/cross-newlib-2.2.0-1.x86_64/src/newlib-2.2.0/newlib/libc/stdlib/dtoa.c:862:1:
error: unrecognizable insn:
 }
 ^
(insn 211 210 212 2 (set (reg/v:DI 326 [ d ])
(subreg:DI (reg/v:DF 331 [ _d ]) 0))
/usr/src/ports/cross-newlib/cross-newlib-2.2.0-1.x86_64/src/newlib-2.2.0/newlib/libc/stdlib/dtoa.c:236
-1
 (nil))
/usr/src/ports/cross-newlib/cross-newlib-2.2.0-1.x86_64/src/newlib-2.2.0/newlib/libc/stdlib/dtoa.c:862:1:
internal compiler error: in extract_insn, at recog.c:2202

[Bug target/64407] ICE in simplify_const_unary_operation, at simplify-rtx.c:1730

[yselkowi at redhat dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64407

--- Comment #1 from Yaakov Selkowitz  ---
Created attachment 34333
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=34333&action=edit
preprocessed source

[Bug target/64407] New: ICE in simplify_const_unary_operation, at simplify-rtx.c:1730

[yselkowi at redhat dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64407

Bug ID: 64407
   Summary: ICE in simplify_const_unary_operation, at
simplify-rtx.c:1730
   Product: gcc
   Version: 4.9.2
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: yselkowi at redhat dot com
  Host: x86_64-cygwin
Target: xstormy16-elf
 Build: x86_64-cygwin

While compiling newlib-2.2.0 with gcc-4.9.2 --target=xstormy16-elf:

xstormy16-elf-gcc
-B/usr/src/ports/cross-newlib/cross-newlib-2.2.0-1.x86_64/build/xstormy16-elf/xstormy16-elf/newlib/
-isystem
/usr/src/ports/cross-newlib/cross-newlib-2.2.0-1.x86_64/build/xstormy16-elf/xstormy16-elf/newlib/targ-include
-isystem
/usr/src/ports/cross-newlib/cross-newlib-2.2.0-1.x86_64/src/newlib-2.2.0/newlib/libc/include
-B/usr/src/ports/cross-newlib/cross-newlib-2.2.0-1.x86_64/build/xstormy16-elf/xstormy16-elf/libgloss/xstormy16
-L/usr/src/ports/cross-newlib/cross-newlib-2.2.0-1.x86_64/build/xstormy16-elf/xstormy16-elf/libgloss/libnosys
-L/usr/src/ports/cross-newlib/cross-newlib-2.2.0-1.x86_64/src/newlib-2.2.0/libgloss/xstormy16
   -DPACKAGE_NAME=\"newlib\" -DPACKAGE_TARNAME=\"newlib\"
-DPACKAGE_VERSION=\"2.2.0\" -DPACKAGE_STRING=\"newlib\ 2.2.0\"
-DPACKAGE_BUGREPORT=\"\" -DPACKAGE_URL=\"\" -I.
-I/usr/src/ports/cross-newlib/cross-newlib-2.2.0-1.x86_64/src/newlib-2.2.0/newlib/libm/math
-I/usr/src/ports/cross-newlib/cross-newlib-2.2.0-1.x86_64/src/newlib-2.2.0/newlib/libm/math/../common
-DMALLOC_PROVIDED -DPREFER_SIZE_OVER_SPEED -fno-builtin  -g -ggdb -O2 -pipe
-Wimplicit-function-declaration -c -o lib_a-e_log.o `test -f 'e_log.c' || echo
'/usr/src/ports/cross-newlib/cross-newlib-2.2.0-1.x86_64/src/newlib-2.2.0/newlib/libm/math/'`e_log.c
/usr/src/ports/cross-newlib/cross-newlib-2.2.0-1.x86_64/src/newlib-2.2.0/newlib/libm/math/e_log.c:
In function ‘__ieee754_log’:
/usr/src/ports/cross-newlib/cross-newlib-2.2.0-1.x86_64/src/newlib-2.2.0/newlib/libm/math/e_log.c:144:1:
internal compiler error: in simplify_const_unary_operation, at
simplify-rtx.c:1730
 }
 ^

[Bug target/64403] New: m32c-elf ICE with -mcpu=m32cm and cleanup

[yselkowi at redhat dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64403

Bug ID: 64403
   Summary: m32c-elf ICE with -mcpu=m32cm and cleanup
   Product: gcc
   Version: 4.9.2
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: yselkowi at redhat dot com
  Host: x86_64-cygwin
Target: m32c-elf, m32c-rtems
 Build: x86_64-cygwin

While building 4.9.2 with binutils-2.25 for m32c-{elf,rtems} targets, the m32cm
multilib libgcc configure (but not the main one) fails during the SjLj
exceptions test:

$ cat conftest.c
void bar ();
void clean (int *);
void foo ()
{
  int i __attribute__ ((cleanup (clean)));
  bar();
}

$ ./gcc/xgcc -B gcc -c -fexceptions -save-temps conftest.c
[succeeds]
$ ./gcc/xgcc -B gcc -c -mcpu=m32cm -fexceptions -save-temps conftest.c
conftest.c: In function ‘foo’:
conftest.c:7:1: error: insn does not satisfy its constraints:
 }
 ^
(insn 52 38 23 (set (reg:SI 2 r1 [29])
(reg:SI 4 a0)) 99 {movsi_24}
 (nil))
conftest.c:7:1: internal compiler error: in final_scan_insn, at final.c:2891
Please submit a full bug report,
with preprocessed source if appropriate.
See <http://gcc.gnu.org/bugs.html> for instructions.

[Bug target/64402] New: mep-elf ICE in libgcc/unwind-dw2.c

[yselkowi at redhat dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64402

Bug ID: 64402
   Summary: mep-elf ICE in libgcc/unwind-dw2.c
   Product: gcc
   Version: 4.9.2
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: yselkowi at redhat dot com
  Host: x86_64-cygwin
Target: mep-elf
 Build: x86_64-cygwin

While building 4.9.2 with --target=mep-elf --without-headers, in apparently all
multilibs:

/usr/src/ports/cross-gcc/cross-gcc-4.9.2-1.x86_64/build/mep-elf/./gcc/xgcc
-B/usr/src/ports/cross-gcc/cross-gcc-4.9.2-1.x86_64/build/mep-elf/./gcc/
-B/usr/mep-elf/bin/ -B/usr/mep-elf/lib/ -isystem /usr/mep-elf/include -isystem
/usr/mep-elf/sys-include -mlibrary-g -ggdb -O2 -pipe
-Wimplicit-function-declaration -mel -O2  -g -ggdb -O2 -pipe
-Wimplicit-function-declaration -DIN_GCC  -DCROSS_DIRECTORY_STRUCTURE  -W -Wall
-Wno-narrowing -Wwrite-strings -Wcast-qual -Wstrict-prototypes
-Wmissing-prototypes -Wold-style-definition  -isystem ./include -mlibrary  -g
-DIN_LIBGCC2 -fbuilding-libgcc -fno-stack-protector -Dinhibit_libc  -I. -I.
-I../../.././gcc
-I/usr/src/ports/cross-gcc/cross-gcc-4.9.2-1.x86_64/src/gcc-4.9.2/libgcc
-I/usr/src/ports/cross-gcc/cross-gcc-4.9.2-1.x86_64/src/gcc-4.9.2/libgcc/.
-I/usr/src/ports/cross-gcc/cross-gcc-4.9.2-1.x86_64/src/gcc-4.9.2/libgcc/../gcc
-I/usr/src/ports/cross-gcc/cross-gcc-4.9.2-1.x86_64/src/gcc-4.9.2/libgcc/../include
 -DHAVE_CC_TLS -DUSE_EMUTLS -o unwind-dw2.o -MT unwind-dw2.o -MD -MP -MF
unwind-dw2.dep -fexceptions -c
/usr/src/ports/cross-gcc/cross-gcc-4.9.2-1.x86_64/src/gcc-4.9.2/libgcc/unwind-dw2.c
-fvisibility=hidden -DHIDE_EXPORTS
In file included from
/usr/src/ports/cross-gcc/cross-gcc-4.9.2-1.x86_64/src/gcc-4.9.2/libgcc/unwind-dw2.c:1698:0:
/usr/src/ports/cross-gcc/cross-gcc-4.9.2-1.x86_64/src/gcc-4.9.2/libgcc/unwind.inc:
In function ‘_Unwind_RaiseException’:
/usr/src/ports/cross-gcc/cross-gcc-4.9.2-1.x86_64/src/gcc-4.9.2/libgcc/unwind.inc:136:1:
internal compiler error: in pre_and_rev_post_order_compute, at cfganal.c:1022
 }
 ^

[Bug target/45360] arm: -mhard-float != -mfloat-abi=hard during linking

[yselkowi at redhat dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=45360

Yaakov Selkowitz  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |FIXED

--- Comment #4 from Yaakov Selkowitz  ---
arm-elf is an obsolete target now, but I checked this with target arm-eabi on
4.9.2 and it is working.

[Bug target/57636] cr16: ICE while building libgcc

[yselkowi at redhat dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57636

--- Comment #6 from Yaakov Selkowitz  ---
This is working in 4.9.2, so it seems that indeed fixed it.

[Bug target/63681] bfin-rtems ICE in cfg_layout_initialize, at cfgrtl.c:4233

[yselkowi at redhat dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63681

--- Comment #3 from Yaakov Selkowitz  ---
I'm seeing an ICE in the same code on the tic6x-elf target as well.

[Bug target/63681] bfin-rtems ICE in cfg_layout_initialize, at cfgrtl.c:4233

[yselkowi at redhat dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63681

Yaakov Selkowitz  changed:

   What|Removed |Added

 CC||yselkowi at redhat dot com

--- Comment #2 from Yaakov Selkowitz  ---
Still occurs with 4.9.2 GA with both bfin-elf and bfin-rtems targets.

[Bug libgcc/64401] New: avr-elf crtbegin.o fails to compile

[yselkowi at redhat dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64401

Bug ID: 64401
   Summary: avr-elf crtbegin.o fails to compile
   Product: gcc
   Version: 4.9.2
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libgcc
  Assignee: unassigned at gcc dot gnu.org
  Reporter: yselkowi at redhat dot com
  Host: x86_64-cygwin
Target: avr-elf
 Build: x86_64-cygwin

Building gcc-4.9.2 with --target=avr-elf --without-headers using binutils-2.25,
libgcc.a itself and crtend.o are built, but not crtbegin.o:

/usr/src/ports/cross-gcc/cross-gcc-4.9.2-1.x86_64/build/avr-elf/./gcc/xgcc
-B/usr/src/ports/cross-gcc/cross-gcc-4.9.2-1.x86_64/build/avr-elf/./gcc/
-B/usr/avr-elf/bin/ -B/usr/avr-elf/lib/ -isystem /usr/avr-elf/include -isystem
/usr/avr-elf/sys-include-g -ggdb -O2 -pipe -Wimplicit-function-declaration
-mmcu=avr25 -O2 -g -ggdb -O2 -pipe -Wimplicit-function-declaration -DIN_GCC 
-DCROSS_DIRECTORY_STRUCTURE  -W -Wall -Wno-narrowing -Wwrite-strings
-Wcast-qual -Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition 
-isystem ./include  -I. -I. -I../../.././gcc
-I/usr/src/ports/cross-gcc/cross-gcc-4.9.2-1.x86_64/src/gcc-4.9.2/libgcc
-I/usr/src/ports/cross-gcc/cross-gcc-4.9.2-1.x86_64/src/gcc-4.9.2/libgcc/.
-I/usr/src/ports/cross-gcc/cross-gcc-4.9.2-1.x86_64/src/gcc-4.9.2/libgcc/../gcc
-I/usr/src/ports/cross-gcc/cross-gcc-4.9.2-1.x86_64/src/gcc-4.9.2/libgcc/../include
  -g0 -finhibit-size-directive -fno-inline -fno-exceptions
-fno-zero-initialized-in-bss -fno-toplevel-reorder -fno-tree-vectorize
-fno-stack-protector -Dinhibit_libc -I. -I. -I../../.././gcc
-I/usr/src/ports/cross-gcc/cross-gcc-4.9.2-1.x86_64/src/gcc-4.9.2/libgcc
-I/usr/src/ports/cross-gcc/cross-gcc-4.9.2-1.x86_64/src/gcc-4.9.2/libgcc/.
-I/usr/src/ports/cross-gcc/cross-gcc-4.9.2-1.x86_64/src/gcc-4.9.2/libgcc/../gcc
-I/usr/src/ports/cross-gcc/cross-gcc-4.9.2-1.x86_64/src/gcc-4.9.2/libgcc/../include
 -o crtbegin.o -MT crtbegin.o -MD -MP -MF crtbegin.dep  -c
/usr/src/ports/cross-gcc/cross-gcc-4.9.2-1.x86_64/src/gcc-4.9.2/libgcc/crtstuff.c
-DCRT_BEGIN
/usr/src/ports/cross-gcc/cross-gcc-4.9.2-1.x86_64/src/gcc-4.9.2/libgcc/crtstuff.c:
In function ‘__do_global_ctors_1’:
/usr/src/ports/cross-gcc/cross-gcc-4.9.2-1.x86_64/src/gcc-4.9.2/libgcc/crtstuff.c:571:13:
error: expected ‘)’ before ‘:’ token
   __asm ("" : "=g" (jcr_list) : "0" (__JCR_LIST__));
 ^

[Bug bootstrap/64400] New: Unable to bootstrap for iq2000-elf target

[yselkowi at redhat dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64400

Bug ID: 64400
   Summary: Unable to bootstrap for iq2000-elf target
   Product: gcc
   Version: 4.9.2
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: bootstrap
  Assignee: unassigned at gcc dot gnu.org
  Reporter: yselkowi at redhat dot com

With binutils-2.25, bootstrapping gcc-4.9.2 with --target=iq2000-elf
--without-headers fails:

/usr/src/ports/cross-gcc/cross-gcc-4.9.2-1.x86_64/build/iq2000-elf/./gcc/xgcc
-B/usr/src/ports/cross-gcc/cross-gcc-4.9.2-1.x86_64/build/iq2000-elf/./gcc/
-B/usr/iq2000-elf/bin/ -B/usr/iq2000-elf/lib/ -isystem /usr/iq2000-elf/include
-isystem /usr/iq2000-elf/sys-include-g -ggdb -O2 -pipe
-Wimplicit-function-declaration -O2  -g -ggdb -O2 -pipe
-Wimplicit-function-declaration -DIN_GCC  -DCROSS_DIRECTORY_STRUCTURE  -W -Wall
-Wno-narrowing -Wwrite-strings -Wcast-qual -Wstrict-prototypes
-Wmissing-prototypes -Wold-style-definition  -isystem ./include   -g
-DIN_LIBGCC2 -fbuilding-libgcc -fno-stack-protector -Dinhibit_libc  -I. -I.
-I../.././gcc
-I/usr/src/ports/cross-gcc/cross-gcc-4.9.2-1.x86_64/src/gcc-4.9.2/libgcc
-I/usr/src/ports/cross-gcc/cross-gcc-4.9.2-1.x86_64/src/gcc-4.9.2/libgcc/.
-I/usr/src/ports/cross-gcc/cross-gcc-4.9.2-1.x86_64/src/gcc-4.9.2/libgcc/../gcc
-I/usr/src/ports/cross-gcc/cross-gcc-4.9.2-1.x86_64/src/gcc-4.9.2/libgcc/../include
 -DHAVE_CC_TLS -DUSE_EMUTLS -o _absvsi2.o -MT _absvsi2.o -MD -MP -MF
_absvsi2.dep -DL_absvsi2 -c
/usr/src/ports/cross-gcc/cross-gcc-4.9.2-1.x86_64/src/gcc-4.9.2/libgcc/libgcc2.c
-fvisibility=hidden -DHIDE_EXPORTS
/usr/src/ports/cross-gcc/cross-gcc-4.9.2-1.x86_64/src/gcc-4.9.2/libgcc/libgcc2.c:
In function ‘__absvsi2’:
/usr/src/ports/cross-gcc/cross-gcc-4.9.2-1.x86_64/src/gcc-4.9.2/libgcc/libgcc2.c:232:1:
internal compiler error: in dwarf2out_var_location, at dwarf2out.c:21266
 }
 ^
Please submit a full bug report,
with preprocessed source if appropriate.
See <http://gcc.gnu.org/bugs.html> for instructions.
Makefile:463: recipe for target '_absvsi2.o' failed
make[2]: *** [_absvsi2.o] Error 1
/usr/src/ports/cross-gcc/cross-gcc-4.9.2-1.x86_64/build/iq2000-elf/./gcc/xgcc
-B/usr/src/ports/cross-gcc/cross-gcc-4.9.2-1.x86_64/build/iq2000-elf/./gcc/
-B/usr/iq2000-elf/bin/ -B/usr/iq2000-elf/lib/ -isystem /usr/iq2000-elf/include
-isystem /usr/iq2000-elf/sys-include-g -ggdb -O2 -pipe
-Wimplicit-function-declaration -O2  -g -ggdb -O2 -pipe
-Wimplicit-function-declaration -DIN_GCC  -DCROSS_DIRECTORY_STRUCTURE  -W -Wall
-Wno-narrowing -Wwrite-strings -Wcast-qual -Wstrict-prototypes
-Wmissing-prototypes -Wold-style-definition  -isystem ./include   -g
-DIN_LIBGCC2 -fbuilding-libgcc -fno-stack-protector -Dinhibit_libc  -I. -I.
-I../.././gcc
-I/usr/src/ports/cross-gcc/cross-gcc-4.9.2-1.x86_64/src/gcc-4.9.2/libgcc
-I/usr/src/ports/cross-gcc/cross-gcc-4.9.2-1.x86_64/src/gcc-4.9.2/libgcc/.
-I/usr/src/ports/cross-gcc/cross-gcc-4.9.2-1.x86_64/src/gcc-4.9.2/libgcc/../gcc
-I/usr/src/ports/cross-gcc/cross-gcc-4.9.2-1.x86_64/src/gcc-4.9.2/libgcc/../include
 -DHAVE_CC_TLS -DUSE_EMUTLS -o _absvdi2.o -MT _absvdi2.o -MD -MP -MF
_absvdi2.dep -DL_absvdi2 -c
/usr/src/ports/cross-gcc/cross-gcc-4.9.2-1.x86_64/src/gcc-4.9.2/libgcc/libgcc2.c
-fvisibility=hidden -DHIDE_EXPORTS
/usr/src/ports/cross-gcc/cross-gcc-4.9.2-1.x86_64/src/gcc-4.9.2/libgcc/libgcc2.c:
In function ‘__absvdi2’:
/usr/src/ports/cross-gcc/cross-gcc-4.9.2-1.x86_64/src/gcc-4.9.2/libgcc/libgcc2.c:271:1:
internal compiler error: in dwarf2out_var_location, at dwarf2out.c:21266
 }
 ^
Please submit a full bug report,
with preprocessed source if appropriate.
See <http://gcc.gnu.org/bugs.html> for instructions.
Makefile:463: recipe for target '_absvdi2.o' failed
make[2]: *** [_absvdi2.o] Error 1
/usr/src/ports/cross-gcc/cross-gcc-4.9.2-1.x86_64/build/iq2000-elf/./gcc/xgcc
-B/usr/src/ports/cross-gcc/cross-gcc-4.9.2-1.x86_64/build/iq2000-elf/./gcc/
-B/usr/iq2000-elf/bin/ -B/usr/iq2000-elf/lib/ -isystem /usr/iq2000-elf/include
-isystem /usr/iq2000-elf/sys-include-g -ggdb -O2 -pipe
-Wimplicit-function-declaration -O2  -g -ggdb -O2 -pipe
-Wimplicit-function-declaration -DIN_GCC  -DCROSS_DIRECTORY_STRUCTURE  -W -Wall
-Wno-narrowing -Wwrite-strings -Wcast-qual -Wstrict-prototypes
-Wmissing-prototypes -Wold-style-definition  -isystem ./include   -g
-DIN_LIBGCC2 -fbuilding-libgcc -fno-stack-protector -Dinhibit_libc  -I. -I.
-I../.././gcc
-I/usr/src/ports/cross-gcc/cross-gcc-4.9.2-1.x86_64/src/gcc-4.9.2/libgcc
-I/usr/src/ports/cross-gcc/cross-gcc-4.9.2-1.x86_64/src/gcc-4.9.2/libgcc/.
-I/usr/src/ports/cross-gcc/cross-gcc-4.9.2-1.x86_64/src/gcc-4.9.2/libgcc/../gcc
-I/usr/src/ports/cross-gcc/cross-gcc-4.9.2-1.x86_64/src/gcc-4.9.2/libgcc/../include
 -DHAVE_CC_TLS -DUSE_EMUTLS -o _addvsi3.o -MT _addvsi3.o -MD -MP -MF
_addvsi3.dep -DL_addvsi3 -c
/usr/src/ports/cross-gcc/cross-gcc-4.9.2-1.x86_64/src/gcc-4.9.2/libgcc/libgcc2.c
-fvisib