[Bug go/113143] Remove usage of ucontext.h

[joel at gcc dot gnu.org via Gcc-bugs]

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

Joel Sherrill  changed:

   What|Removed |Added

 CC||joel at gcc dot gnu.org

--- Comment #13 from Joel Sherrill  ---
RTEMS also had support for Go a long time ago -- it was a GSoC 2010 project. It
worked until the dependency on  was added. RTEMS has tracked the
lack of  needed for Go for 7 years
(https://gitlab.rtems.org/rtems/rtos/rtems/-/issues/2832). It was likely broken
for a while before one of us filed the ticket.

We use newlib and looking at the source Cygwin has its own . My
msys2 install has that version of the file in /usr/include. 

RTEMS does not have . The ticket we have encourages porting the
implementation from *BSD but that will only address a handful of the 18
architectures we currently support.

I agree it is obsolete per POSIX and not universally supported. I also give Ian
the benefit of doubt that there is no adequate replacement -- certainly not in
POSIX. That leaves the solution of having an alternative in Go or an
implementation that is easy to drop into OSes other than Linux or *BSD.

Looks like neither RTEMS nor Haiku has seen someone step up as a volunteer in
the long time this has been an issue.

[Bug target/115874] sh.c appears to be missing include of stdio.h

[joel at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #3 from Joel Sherrill  ---
config.h includes auto-host.h which appears to be defining the macros:

/* Define to 1 if we found a declaration for 'fputc_unlocked', otherwise
   define to 0. */
#ifndef USED_FOR_TARGET
#define HAVE_DECL_FPUTC_UNLOCKED 1
#endif


/* Define to 1 if we found a declaration for 'fputs_unlocked', otherwise
   define to 0. */
#ifndef USED_FOR_TARGET
#define HAVE_DECL_FPUTS_UNLOCKED 1
#endif

If I add a #error before each of those defines, the compile gets there and hits
the #error. I made this chance to sh.cc and got the #error:

#include "config.h"
#ifdef HAVE_DECL_FPUTS_UNLOCKED
#error "joel"
#endif

I think that means the right feature macro is defined. What else might be
wrong?

[Bug target/115874] sh.c appears to be missing include of stdio.h

[joel at gcc dot gnu.org via Gcc-bugs]

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

Joel Sherrill  changed:

   What|Removed |Added

   Host||cygwin
 Target||sh-rtems6

--- Comment #1 from Joel Sherrill  ---
I tried adding include of  and then  but never directly solved
the problem. fputs_unlocked() is under a __GNU_VISIBLE guard. I added a define
of _GNU_SOURCE above the include of  but that didn't help.

[Bug target/115874] New: sh.c appears to be missing include of stdio.h

[joel at gcc dot gnu.org via Gcc-bugs]

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

Bug ID: 115874
   Summary: sh.c appears to be missing include of stdio.h
   Product: gcc
   Version: 13.3.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: joel at gcc dot gnu.org
  Target Milestone: ---

Target: sh-rtems6
Host: Cygwin

We have not seen this failure on Linux. stdio.h must be implicitly included.
This is the error on Cygwin. Is adding an include  the right solution?

g++ -O2 -g -pipe
-I/home/jrs007/rtems-work/rtems-source-builder/rtems/build/tmp/sb-1049590/tools/rtems-default-tools/tmp/mkefs/include
-I/home/jrs007/rtems-work/rtems-source-builder/rtems/build/tmp/sb-1049590-internal/include
 -fno-PIE -c   -g -O2 -DIN_GCC  -DCROSS_DIRECTORY_STRUCTURE  
-fno-exceptions -fno-rtti -fasynchronous-unwind-tables -W -Wall -Wno-narrowing
-Wwrite-strings -Wcast-qual-DHAVE_CONFIG_H -I. -Ianalyzer
-I../../gcc-13.3.0/gcc -I../../gcc-13.3.0/gcc/analyzer
-I../../gcc-13.3.0/gcc/../include  -I../../gcc-13.3.0/gcc/../libcpp/include
-I../../gcc-13.3.0/gcc/../libcody
-I/home/jrs007/rtems-work/rtems-source-builder/rtems/build/sh-rtems6-gcc-13.3.0-newlib-1ed1516-x86_64-pc-cygwin-1/gcc-13.3.0/mpc/src
 -I../../gcc-13.3.0/gcc/../libdecnumber
-I../../gcc-13.3.0/gcc/../libdecnumber/dpd -I../libdecnumber
-I../../gcc-13.3.0/gcc/../libbacktrace
-I/home/jrs007/rtems-work/rtems-source-builder/rtems/build/sh-rtems6-gcc-13.3.0-newlib-1ed1516-x86_64-pc-cygwin-1/build/./isl/include
-I/home/jrs007/rtems-work/rtems-source-builder/rtems/build/sh-rtems6-gcc-13.3.0-newlib-1ed1516-x86_64-pc-cygwin-1/gcc-13.3.0/isl/include
 -o analyzer/call-string.o -MT analyzer/call-string.o -MMD -MP -MF
analyzer/.deps/call-string.TPo ../../gcc-13.3.0/gcc/analyzer/call-string.cc
In file included from ../../gcc-13.3.0/gcc/config/sh/sh.cc:28:
../../gcc-13.3.0/gcc/config/sh/sh.cc: In function ‘void sh_print_operand(FILE*,
rtx, int)’:
../../gcc-13.3.0/gcc/system.h:150:33: error: ‘fputs_unlocked’ was not declared
in this scope; did you mean ‘fputc_unlocked’?
  150 | #  define fputs(String, Stream) fputs_unlocked (String, Stream)
  | ^~
../../gcc-13.3.0/gcc/config/sh/sh.cc:1180:11: note: in expansion of macro
‘fputs’
 1180 |   fputs ("/u", stream);
  |   ^
../../gcc-13.3.0/gcc/system.h:150:33: error: ‘fputs_unlocked’ was not declared
in this scope; did you mean ‘fputc_unlocked’?
  150 | #  define fputs(String, Stream) fputs_unlocked (String, Stream)
  | ^~
../../gcc-13.3.0/gcc/config/sh/sh.cc:1186:11: note: in expansion of macro
‘fputs’
 1186 |   fputs ("\t! target: ", stream);
  |   ^
../../gcc-13.3.0/gcc/system.h:150:33: error: ‘fputs_unlocked’ was not declared
in this scope; did you mean ‘fputc_unlocked’?
  150 | #  define fputs(String, Stream) fputs_unlocked (String, Stream)
  | ^~
../../gcc-13.3.0/gcc/config/sh/sh.cc:1203:11: note: in expansion of macro
‘fputs’
 1203 |   fputs (reg_names[regno], (stream));
  |   ^
../../gcc-13.3.0/gcc/system.h:150:33: error: ‘fputs_unlocked’ was not declared
in this scope; did you mean ‘fputc_unlocked’?
  150 | #  define fputs(String, Stream) fputs_unlocked (String, Stream)
  | ^~
../../gcc-13.3.0/gcc/config/sh/sh.cc:1230:11: note: in expansion of macro
‘fputs’
 1230 |   fputs (reg_names[regno], (stream));
  |   ^
../../gcc-13.3.0/gcc/system.h:150:33: error: ‘fputs_unlocked’ was not declared
in this scope; did you mean ‘fputc_unlocked’?
  150 | #  define fputs(String, Stream) fputs_unlocked (String, Stream)
  | ^~
../../gcc-13.3.0/gcc/config/sh/sh.cc:1257:11: note: in expansion of macro
‘fputs’
 1257 |   fputs (reg_names[REGNO (x) + 1], (stream));
  |   ^
../../gcc-13.3.0/gcc/system.h:150:33: error: ‘fputs_unlocked’ was not declared
in this scope; did you mean ‘fputc_unlocked’?
  150 | #  define fputs(String, Stream) fputs_unlocked (String, Stream)
  | ^~
../../gcc-13.3.0/gcc/config/sh/sh.cc:1290:21: note: in expansion of macro
‘fputs’
 1290 | case PLUS:  fputs ("add", stream); break;
  | ^
../../gcc-13.3.0/gcc/system.h:150:33: error: ‘fputs_unlocked’ was not declared
in this scope; did you mean ‘fputc_unlocked’?
  150 | #  define fputs(String, Stream) fputs_unlocked (String, Stream)
  | ^~
../../gcc-13.3.0/gcc/config/sh/sh.cc:1309:28: note: in expansion of macro
‘fputs’
 1309 | case E_QImode: fputs (".b", stream); break;
  |^~

[Bug libquadmath/91559] New: math/x2y2m1q.c assumes FE_TONEAREST defined

[joel at gcc dot gnu.org]

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

Bug ID: 91559
   Summary: math/x2y2m1q.c assumes FE_TONEAREST defined
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libquadmath
  Assignee: unassigned at gcc dot gnu.org
  Reporter: joel at gcc dot gnu.org
  Target Milestone: ---

newlib has been updated to always provide an fenv.h with prototypes for the
required methods. Unfortunately, this has triggered code in math/x2y2m1q.c
which incorrectly assumes FE_TONEAREST is always defined. Per POSIX, the
rounding mode and exception mode constants only need to be supported if they
are defined. A check for existence of fenv.h is an insufficient check.

http://pubs.opengroup.org/onlinepubs/9699919799/basedefs/fenv.h.html

../../../../gnu-mirror-gcc-0f81292cb0a/libquadmath/math/x2y2m1q.c:57:26: 
error: 'FE_TONEAREST' undeclared (first use in this function)
57 |   SET_RESTORE_ROUNDF128 (FE_TONEAREST);
   |  ^~~~

This showed up on x86_64 but is likely to show up on all newlib targets which
do not have the target specific fenv support. 

The solution is just to wrap all calls using fenv.h constants with an #ifdef on
the constant used as POSIX indicates.

[Bug target/91303] powerpc-rtems compile error libgcc

[joel at gcc dot gnu.org]

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

--- Comment #3 from Joel Sherrill  ---
Pursuing the assumption that the e500 files shouldn't be build, I decided to
remove them from the t-savresfgpr files. With this patch, powerpc-rtems5 builds
again:

diff --git a/libgcc/config/rs6000/t-savresfgpr
b/libgcc/config/rs6000/t-savresfg
index a8455ae..e252cc8 100644
--- a/libgcc/config/rs6000/t-savresfgpr
+++ b/libgcc/config/rs6000/t-savresfgpr
@@ -7,17 +7,4 @@ LIB2ADD_ST += \
   $(srcdir)/config/rs6000/crtresxfpr.S \
   $(srcdir)/config/rs6000/crtresxgpr.S \
   $(srcdir)/config/rs6000/crtsavevr.S \
-  $(srcdir)/config/rs6000/crtrestvr.S \
-  $(srcdir)/config/rs6000/e500crtres32gpr.S \
-  $(srcdir)/config/rs6000/e500crtres64gpr.S \
-  $(srcdir)/config/rs6000/e500crtres64gprctr.S \
-  $(srcdir)/config/rs6000/e500crtrest32gpr.S \
-  $(srcdir)/config/rs6000/e500crtrest64gpr.S \
-  $(srcdir)/config/rs6000/e500crtresx32gpr.S \
-  $(srcdir)/config/rs6000/e500crtresx64gpr.S \
-  $(srcdir)/config/rs6000/e500crtsav32gpr.S \
-  $(srcdir)/config/rs6000/e500crtsav64gpr.S \
-  $(srcdir)/config/rs6000/e500crtsav64gprctr.S \
-  $(srcdir)/config/rs6000/e500crtsavg32gpr.S \
-  $(srcdir)/config/rs6000/e500crtsavg64gpr.S \
-  $(srcdir)/config/rs6000/e500crtsavg64gprctr.S
+  $(srcdir)/config/rs6000/crtrestvr.S

[Bug target/91303] powerpc-rtems compile error libgcc

[joel at gcc dot gnu.org]

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

--- Comment #2 from Joel Sherrill  ---
I admit to being completely confused by the multitude of PwerPC variants but if
the e500 was deleted, why does libgcc/config.host still include
libgcc/config/rs6000/t-savresfgpr for multiple powerpc targets and t-savresfgpr
still list files which have e500 in the name?

[Bug libgcc/91303] New: powerpc-rtems compile error libgcc

[joel at gcc dot gnu.org]

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

Bug ID: 91303
   Summary: powerpc-rtems compile error libgcc
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libgcc
  Assignee: unassigned at gcc dot gnu.org
  Reporter: joel at gcc dot gnu.org
  Target Milestone: ---

Building off the git master, powerpc gave this compile error:

(GCC) 10.0.0 20190730 (experimental)

I forgot to update yesterday and it was also broken with "(GCC) 10.0.0 20190620
(experimental)"


/home/joel/test-gcc/b-powerpc-rtems5-gcc/./gcc/xgcc
-B/home/joel/test-gcc/b-powerpc-rtems5-gcc/./gcc/ -nostdinc
-B/home/joel/test-gcc/b-powerpc-rtems5-gcc/powerpc-rtems5/newlib/ -isystem
/home/joel/test-gcc/b-powerpc-rtems5-gcc/powerpc-rtems5/newlib/targ-include
-isystem /home/joel/test-gcc/gcc/newlib/libc/include
-B/home/joel/test-gcc/install-master/powerpc-rtems5/bin/
-B/home/joel/test-gcc/install-master/powerpc-rtems5/lib/ -isystem
/home/joel/test-gcc/install-master/powerpc-rtems5/include -isystem
/home/joel/test-gcc/install-master/powerpc-rtems5/sys-include-g -O2
-mcpu=8540 -O2 -I../../../../gcc/libgcc/../newlib/libc/sys/rtems/include -g -O2
-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../../../../gcc/libgcc
-I../../../../gcc/libgcc/. -I../../../../gcc/libgcc/../gcc
-I../../../../gcc/libgcc/../include  -DHAVE_CC_TLS  -o e500crtsav64gprctr_s.o
-MT e500crtsav64gprctr_s.o -MD -MP -MF e500crtsav64gprctr_s.dep -DSHARED -c
-xassembler-with-cpp ../../../../gcc/libgcc/config/rs6000/e500crtsav64gprctr.S
../../../../gcc/libgcc/config/rs6000/crtresfpr.S: Assembler messages:
../../../../gcc/libgcc/config/rs6000/crtresfpr.S:41: Error: unrecognized
opcode: `lfd'
../../../../gcc/libgcc/config/rs6000/crtresfpr.S:42: Error: unrecognized
opcode: `lfd'
../../../../gcc/libgcc/config/rs6000/crtresfpr.S:43: Error: unrecognized
opcode: `lfd'
../../../../gcc/libgcc/config/rs6000/crtresfpr.S:44: Error: unrecognized
opcode: `lfd'
../../../../gcc/libgcc/config/rs6000/crtresfpr.S:45: Error: unrecognized
opcode: `lfd'
../../../../gcc/libgcc/config/rs6000/crtresfpr.S:46: Error: unrecognized
opcode: `lfd'
../../../../gcc/libgcc/config/rs6000/crtresfpr.S:47: Error: unrecognized
opcode: `lfd'
../../../../gcc/libgcc/config/rs6000/crtresfpr.S:48: Error: unrecognized
opcode: `lfd'
../../../../gcc/libgcc/config/rs6000/crtresfpr.S:49: Error: unrecognized
opcode: `lfd'
../../../../gcc/libgcc/config/rs6000/crtresfpr.S:50: Error: unrecognized
opcode: `lfd'
../../../../gcc/libgcc/config/rs6000/crtresfpr.S:51: Error: unrecognized
opcode: `lfd'
../../../../gcc/libgcc/config/rs6000/crtresfpr.S:52: Error: unrecognized
opcode: `lfd'
../../../../gcc/libgcc/config/rs6000/crtsavfpr.S:
../../../../gcc/libgcc/config/rs6000/crtresfpr.S:53: Error: unrecognized
opcode: `lfd'
Assembler messages:
../../../../gcc/libgcc/config/rs6000/crtsavfpr.S:41: Error: unrecognized
opcode: `stfd'
../../../../gcc/libgcc/config/rs6000/crtresfpr.S:54: Error: unrecognized
opcode: `lfd'
../../../../gcc/libgcc/config/rs6000/crtresfpr.S:55: Error: unrecognized
opcode: `lfd'
../../../../gcc/libgcc/config/rs6000/crtsavfpr.S:42: Error: unrecognized
opcode: `stfd'

[Bug target/50928] m32c ICE building RTEMS

[joel at gcc dot gnu.org]

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

--- Comment #20 from Joel Sherrill  ---
I filed this in 2011 and we dropped RTEMS support for the m32c last year for
our next release. If you all think it is fixed, please feel free to close it.

[Bug c/87795] Excessive alignment permitted for functions and labels

[joel at gcc dot gnu.org]

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

Joel Sherrill  changed:

   What|Removed |Added

 CC||joel at gcc dot gnu.org

--- Comment #4 from Joel Sherrill  ---
I added myself as a CC because I want to see if these become errors or
warnings. For core parts of RTEMS, I can see wanting these to be errors since
it indicates we did something in core OS code that did not achieve the desired
results. But in application code, it might not be as well considered or
necessary.

So ultimately, it's a hard decision on how to treat mistakes in alignment
requests

[Bug target/81804] m32c ICE during configure at leaf_function_p, at final.c:4317

[joel at gcc dot gnu.org]

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

--- Comment #1 from Joel Sherrill  ---
Version: (GCC) 8.0.0 20171120
target: m32c-rtems, likely for m32c-elf

Still happens. line number has moved in the source file but ICE is still the
same.

[Bug target/83090] New: ICE on lm32-rtems building newlib libm (in require, at machmode.h:282)

[joel at gcc dot gnu.org]

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

Bug ID: 83090
   Summary: ICE on lm32-rtems building newlib libm (in require, at
machmode.h:282)
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: joel at gcc dot gnu.org
  Target Milestone: ---

Created attachment 42670
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=42670&action=edit
Preprocessed output of file causing ICE

Target: lm32-rtems5
gcc master: 8 79218abbbc680d3329b2e3d460bb0414333f3889

The build fails during newlib's libm. Compiles at -O1 and -Os but not at -O2.

/home/joel/test-gcc/b-lm32-rtems5-gcc/./gcc/xgcc
-B/home/joel/test-gcc/b-lm32-rtems5-gcc/./gcc/ -nostdinc
-B/home/joel/test-gcc/b-lm32-rtems5-gcc/lm32-rtems5/mmultiply-enabled/newlib/
-isystem
/home/joel/test-gcc/b-lm32-rtems5-gcc/lm32-rtems5/mmultiply-enabled/newlib/targ-include
-isystem /home/joel/test-gcc/gcc/newlib/libc/include
-B/home/joel/test-gcc/install-master/lm32-rtems5/bin/
-B/home/joel/test-gcc/install-master/lm32-rtems5/lib/ -isystem
/home/joel/test-gcc/install-master/lm32-rtems5/include -isystem
/home/joel/test-gcc/install-master/lm32-rtems5/sys-include  -mmultiply-enabled
-DPACKAGE_NAME=\"newlib\" -DPACKAGE_TARNAME=\"newlib\"
-DPACKAGE_VERSION=\"2.5.0\" -DPACKAGE_STRING=\"newlib\ 2.5.0\"
-DPACKAGE_BUGREPORT=\"\" -DPACKAGE_URL=\"\" -I.
-I../../../../../../gcc/newlib/libm/math
-I../../../../../../gcc/newlib/libm/math/../common -D_COMPILING_NEWLIB
-DCLOCK_PROVIDED -DMALLOC_PROVIDED -DEXIT_PROVIDED -DSIGNAL_PROVIDED
-DREENTRANT_SYSCALLS_PROVIDED -DHAVE_NANOSLEEP -DHAVE_BLKSIZE -DHAVE_FCNTL
-DHAVE_ASSERT_FUNC -D_NO_GETLOGIN -D_NO_GETPWENT -D_NO_GETUT -D_NO_GETPASS
-D_NO_SIGSET -D_NO_WORDEXP -D_NO_POPEN -D_NO_POSIX_SPAWN -fno-builtin  -g
-O2  -mmultiply-enabled -c -o lib_a-e_j0.o `test -f 'e_j0.c' || echo
'../../../../../../gcc/newlib/libm/math/'`e_j0.c
during RTL pass: reload
../../../../../../gcc/newlib/libm/math/e_j0.c: In function 'pzero':
../../../../../../gcc/newlib/libm/math/e_j0.c:349:1: internal compiler error:
in require, at machmode.h:282
 }
 ^
0x59f48b opt_mode::require() const
../../gcc/gcc/machmode.h:282
0x59f48b replace_reg_with_saved_mem
../../gcc/gcc/caller-save.c:1151
0x59ffb6 mark_referenced_regs
../../gcc/gcc/caller-save.c:1073
0x59ffb6 mark_referenced_regs
../../gcc/gcc/caller-save.c:1073
0x59ffb6 mark_referenced_regs
../../gcc/gcc/caller-save.c:1073
0x59ffb6 mark_referenced_regs
../../gcc/gcc/caller-save.c:1073
0x5a1065 save_call_clobbered_regs()
../../gcc/gcc/caller-save.c:895
0x9b5498 reload(rtx_insn*, int)
../../gcc/gcc/reload1.c:980
0x853a3e do_reload
../../gcc/gcc/ira.c:5458
0x853a3e execute
../../gcc/gcc/ira.c:5630
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See <https://gcc.gnu.org/bugs/> for instructions.

[Bug fortran/34040] Support for DOUBLE_TYPE_SIZE != 64 targets

[joel at gcc dot gnu.org]

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

--- Comment #16 from Joel Sherrill  ---
I assume this ICE during a build of bfin-rtems on the master is indicative of
the same underlying problem. I have reported this before on the sh2e but didn't
know of this PR.

libtool: compile:  /home/joel/test-gcc/b-bfin-rtems5-gcc/./gcc/xgcc
-B/home/joel/test-gcc/b-bfin-rtems5-gcc/./gcc/ -nostdinc
-B/home/joel/test-gcc/b-bfin-rtems5-gcc/bfin-rtems5/newlib/ -isystem
/home/joel/test-gcc/b-bfin-rtems5-gcc/bfin-rtems5/newlib/targ-include -isystem
/home/joel/test-gcc/gcc/newlib/libc/include
-B/home/joel/test-gcc/install-master/bfin-rtems5/bin/
-B/home/joel/test-gcc/install-master/bfin-rtems5/lib/ -isystem
/home/joel/test-gcc/install-master/bfin-rtems5/include -isystem
/home/joel/test-gcc/install-master/bfin-rtems5/sys-include -DHAVE_CONFIG_H -I.
-I../../../gcc/libgfortran -iquote../../../gcc/libgfortran/io
-I../../../gcc/libgfortran/../gcc -I../../../gcc/libgfortran/../gcc/config
-I../.././gcc -I../../../gcc/libgfortran/../libgcc -I../libgcc
-I../../../gcc/libgfortran/../libbacktrace -I../libbacktrace -I../libbacktrace
-std=gnu11 -Wall -Wstrict-prototypes -Wmissing-prototypes
-Wold-style-definition -Wextra -Wwrite-strings
-Werror=implicit-function-declaration -Werror=vla -fcx-fortran-rules
-ffunction-sections -fdata-sections -g -O2 -MT sum_c8.lo -MD -MP -MF
.deps/sum_c8.Tpo -c ../../../gcc/libgfortran/generated/sum_c8.c -o sum_c8.o
during RTL pass: reload
../../../gcc/libgfortran/generated/sum_c8.c: In function 'sum_c8':
../../../gcc/libgfortran/generated/sum_c8.c:191:1: internal compiler error: in
require, at machmode.h:282
 }
 ^
0x59f58c opt_mode::require() const
../../gcc/gcc/machmode.h:282
0x59f58c replace_reg_with_saved_mem
../../gcc/gcc/caller-save.c:1151
0x5a00c6 mark_referenced_regs
../../gcc/gcc/caller-save.c:1073
0x5a00c6 mark_referenced_regs
../../gcc/gcc/caller-save.c:1073
0x5a1105 save_call_clobbered_regs()
../../gcc/gcc/caller-save.c:895
0x9ba530 reload(rtx_insn*, int)
../../gcc/gcc/reload1.c:980
0x8540ce do_reload
../../gcc/gcc/ira.c:5458
0x8540ce execute
../../gcc/gcc/ira.c:5630
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.
make[3]: *** [sum_c8.lo] Error 1

[Bug libgcc/66032] RTEMS MIPS build fails on FreeBSD

[joel at gcc dot gnu.org]

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

Joel Sherrill  changed:

   What|Removed |Added

 CC||joel at gcc dot gnu.org

--- Comment #9 from Joel Sherrill  ---
Yes. I believe it is the same bug. Use of GNU sed specifics on a system without
GNU sed.

I don't know if that changes the resolution.

[Bug target/81804] New: m32c ICE during configure at leaf_function_p, at final.c:4317

[joel at gcc dot gnu.org]

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

Bug ID: 81804
   Summary: m32c ICE during configure at leaf_function_p, at
final.c:4317
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: joel at gcc dot gnu.org
  Target Milestone: ---

Version: (GCC) 8.0.0 20170809
target: m32c-rtems, likely for m32c-elf

checking for m32c-rtems4.12-gcc...
/home/joel/test-gcc/b-m32c-rtems4.12-gcc/./gcc/xgcc
-B/home/joel/test-gcc/b-m32c-rtems4.12-gcc/./gcc/ -nostdinc
-B/home/joel/test-gcc/b-m32c-rtems4.12-gcc/m32c-rtems4.12/newlib/ -isystem
/home/joel/test-gcc/b-m32c-rtems4.12-gcc/m32c-rtems4.12/newlib/targ-include
-isystem /home/joel/test-gcc/gcc/newlib/libc/include
-B/home/joel/test-gcc/install-master/m32c-rtems4.12/bin/
-B/home/joel/test-gcc/install-master/m32c-rtems4.12/lib/ -isystem
/home/joel/test-gcc/install-master/m32c-rtems4.12/include -isystem
/home/joel/test-gcc/install-master/m32c-rtems4.12/sys-include   
checking for suffix of object files... configure: error: in
`/home/joel/test-gcc/b-m32c-rtems4.12-gcc/m32c-rtems4.12/libgcc':
configure: error: cannot compute suffix of object files: cannot compile
See `config.log' for more details.

config.log contains:

configure:3471: /home/joel/test-gcc/b-m32c-rtems4.12-gcc/./gcc/xgcc
-B/home/joel/test-gcc/b-m32c-rtems4.12-gcc/./gcc/ -nostdinc
-B/home/joel/test-gcc/b-m32c-rtems4.12-gcc/m32c-rtems4.12/newlib/ -isystem
/home/joel/test-gcc/b-m32c-rtems4.12-gcc/m32c-rtems4.12/newlib/targ-include
-isystem /home/joel/test-gcc/gcc/newlib/libc/include
-B/home/joel/test-gcc/install-master/m32c-rtems4.12/bin/
-B/home/joel/test-gcc/install-master/m32c-rtems4.12/lib/ -isystem
/home/joel/test-gcc/install-master/m32c-rtems4.12/include -isystem
/home/joel/test-gcc/install-master/m32c-rtems4.12/sys-include-o conftest -g
-O2   conftest.c  >&5
during RTL pass: pro_and_epilogue
conftest.c: In function 'main':
conftest.c:16:1: internal compiler error: in leaf_function_p, at final.c:4317
 }
 ^
0x6e67c5 leaf_function_p()
../../gcc/gcc/final.c:4317
0xd484ac m32c_leaf_function_p
../../gcc/gcc/config/m32c/m32c.c:4016
0xd484ac m32c_emit_prologue()
../../gcc/gcc/config/m32c/m32c.c:4070
0xe8573a gen_prologue()
../../gcc/gcc/config/m32c/prologue.md:26
0xd44c58 target_gen_prologue
../../gcc/gcc/config/m32c/blkmov.md:359
0x734b47 make_prologue_seq
../../gcc/gcc/function.c:5835
0x734d03 thread_prologue_and_epilogue_insns()
../../gcc/gcc/function.c:5952
0x7353c2 rest_of_handle_thread_prologue_and_epilogue
../../gcc/gcc/function.c:6443
0x7353c2 execute
../../gcc/gcc/function.c:6485
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See <https://gcc.gnu.org/bugs/> for instructions.
configure:3474: $? = 1
configure:3662: checking for suffix of object files

[Bug target/79391] sh ICE in in eligible_for_delay, at config/sh/sh.md:564

[joel at gcc dot gnu.org]

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

--- Comment #2 from Joel Sherrill  ---
It builds on the gcc head and the 7 branch now. 

Should we just go ahead and close this or does it matter when it was fixed?

[Bug target/79391] New: sh ICE in in eligible_for_delay, at config/sh/sh.md:564

[joel at gcc dot gnu.org]

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

Bug ID: 79391
   Summary: sh ICE in in eligible_for_delay, at
config/sh/sh.md:564
   Product: gcc
   Version: 7.0.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: joel at gcc dot gnu.org
  Target Milestone: ---

xgcc (GCC) 7.0.1 20170205 (experimental)

using newlib and binutils master

/home/joel/test-gcc/b-sh-rtems4.12-gcc/./gcc/xgcc
-B/home/joel/test-gcc/b-sh-rtems4.12-gcc/./gcc/ -nostdinc
-B/home/joel/test-gcc/b-sh-rtems4.12-gcc/sh-rtems4.12/m4-single/newlib/
-isystem
/home/joel/test-gcc/b-sh-rtems4.12-gcc/sh-rtems4.12/m4-single/newlib/targ-include
-isystem /home/joel/test-gcc/gcc/newlib/libc/include
-B/home/joel/test-gcc/install-master/sh-rtems4.12/bin/
-B/home/joel/test-gcc/install-master/sh-rtems4.12/lib/ -isystem
/home/joel/test-gcc/install-master/sh-rtems4.12/include -isystem
/home/joel/test-gcc/install-master/sh-rtems4.12/sys-include  -m4-single
-DPACKAGE_NAME=\"newlib\" -DPACKAGE_TARNAME=\"newlib\"
-DPACKAGE_VERSION=\"2.5.0\" -DPACKAGE_STRING=\"newlib\ 2.5.0\"
-DPACKAGE_BUGREPORT=\"\" -DPACKAGE_URL=\"\" -I.
-I../../../../../../gcc/newlib/libc/stdlib -D_COMPILING_NEWLIB
-DMALLOC_PROVIDED -DEXIT_PROVIDED -DSIGNAL_PROVIDED
-DREENTRANT_SYSCALLS_PROVIDED -DHAVE_NANOSLEEP -DHAVE_BLKSIZE -DHAVE_FCNTL
-DHAVE_ASSERT_FUNC -D_NO_GETLOGIN -D_NO_GETPWENT -D_NO_GETUT -D_NO_GETPASS
-D_NO_SIGSET -D_NO_WORDEXP -D_NO_POPEN -D_NO_POSIX_SPAWN
-D_I386MACH_ALLOW_HW_INTERRUPTS -fno-builtin  -g -O2  -m4-single -c -o
lib_a-wcstod.o `test -f 'wcstod.c' || echo
'../../../../../../gcc/newlib/libc/stdlib/'`wcstod.c
../../../../../../gcc/newlib/libc/stdlib/wcstod.c: In function '_wcstod_l':
../../../../../../gcc/newlib/libc/stdlib/wcstod.c:234:1: internal compiler
error: in eligible_for_delay, at config/sh/sh.md:564

[Bug target/78480] m68k-rtems compile error in libgfortran

[joel at gcc dot gnu.org]

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

--- Comment #1 from Joel Sherrill  ---
Still occurs on:

gcc (GCC) 7.0.1 20170205 (experimental)

[Bug target/78478] Compile Error for i386-rtems

[joel at gcc dot gnu.org]

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

--- Comment #24 from Joel Sherrill  ---
Would you mind applying this to the 6.x branch? That was where the issue was
initially spotted.

I don't know what to do about this extra line in rtemself.h though. It was not
present in the master 

#define IX86_NO_LIBGCC_TFMODE

[Bug target/78478] Compile Error for i386-rtems

[joel at gcc dot gnu.org]

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

--- Comment #20 from Joel Sherrill  ---
(In reply to Uroš Bizjak from comment #19)
> (In reply to Joel Sherrill from comment #18)
> > I changed that line to 
> > 
> > #ifdef _SOFT_FLOAT
> > #include "config/fpu-generic.h"
> > 
> > and it built. Is that OK?
> 
> Yes.

Looks like it works, Thanks.

Based on my testing,  these need to be applied to both the gcc 6 branch and
master. Should I just commit them with the PR noted or do they need to go
through gcc-patches first?

[Bug target/78478] Compile Error for i386-rtems

[joel at gcc dot gnu.org]

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

--- Comment #18 from Joel Sherrill  ---
(In reply to Uroš Bizjak from comment #17)
> (In reply to Joel Sherrill from comment #16)
> > Thanks for all the feedback. With this patch, it now builds. Is the style of
> > change to configure.host OK?
> 

> +#ifdef _SOFT_FLOAT
> +#include "fpu-generic.h"
> +
This seems like a good solution but the build can't find fpu-generic.h

In file included from ../../../../gcc/libgfortran/runtime/fpu.c:29:0:
./fpu-target.h:27:25: fatal error: fpu-generic.h: No such file or directory
 #include "fpu-generic.h"

I changed that line to 

#ifdef _SOFT_FLOAT
#include "config/fpu-generic.h"

and it built. Is that OK?

[Bug target/78478] Compile Error for i386-rtems

[joel at gcc dot gnu.org]

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

--- Comment #16 from Joel Sherrill  ---
Thanks for all the feedback. With this patch, it now builds. Is the style of
change to configure.host OK?

I need to check how far back this impacts. A user reported it with a released
gcc. Since we don't build fortran by default, this might have been broken a
while. 

diff --git a/gcc/config/i386/rtemself.h b/gcc/config/i386/rtemself.h
index 9516c45..e8eade2 100644
--- a/gcc/config/i386/rtemself.h
+++ b/gcc/config/i386/rtemself.h
@@ -28,6 +28,3 @@ along with GCC; see the file COPYING3.  If not see
builtin_assert ("system=rtems");\
 }  \
   while (0)
-
-#undef LONG_DOUBLE_TYPE_SIZE
-#define LONG_DOUBLE_TYPE_SIZE (TARGET_80387 ? 80 : 64)
diff --git a/libgfortran/configure.host b/libgfortran/configure.host
index 0a12a32..e594f31 100644
--- a/libgfortran/configure.host
+++ b/libgfortran/configure.host
@@ -37,11 +37,16 @@ if test "x${have_feenableexcept}" = "xyes"; then
 fi

 # x86 asm should be used instead of glibc, since glibc doesn't support
-# the x86 denormal exception.
+# the x86 denormal exception. But RTEMS uses newlib and this doesn't apply.
 case "${host_cpu}" in
   i?86 | x86_64)
-fpu_host='fpu-387'
-ieee_support='yes'
+case "${host_os}" in
+  rtems*) ;;
+  *)
+fpu_host='fpu-387'
+ieee_support='yes'
+;;
+esac
 ;;
 esac

[Bug target/78478] Compile Error for i386-rtems

[joel at gcc dot gnu.org]

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

--- Comment #14 from Joel Sherrill  ---
(In reply to H.J. Lu from comment #13)
> The problem is config/i386/rtemself.h has
> 
> #define LONG_DOUBLE_TYPE_SIZE (TARGET_80387 ? 80 : 64)
> 
> XFmode isn't available with -msoft-float even when -mlong-double-80 is used.
> IA MCU defaults long double to double and XFmode is available with
> -mlong-double-80.

I had no idea how that got there so did a git blame.

8a3edb334 (uros2013-11-05 16:08:30 + 31) 
8a3edb334 (uros2013-11-05 16:08:30 + 32) #undef LONG_DOUBLE_TYPE_SIZE
8a3edb334 (uros2013-11-05 16:08:30 + 33) #define LONG_DOUBLE_TYPE_SIZE
(TARGET_80387 ? 80 : 64)

Anyway, removing that let it get to libgfortran for i386-rtems and fail with
this:

=
libtool: compile:  /home/joel/test-gcc/b-i386-rtems4.12-gcc/./gcc/xgcc
-B/home/joel/test-gcc/b-i386-rtems4.12-gcc/./gcc/ -nostdinc
-B/home/joel/test-gcc/b-i386-rtems4.12-gcc/i386-rtems4.12/newlib/ -isystem
/home/joel/test-gcc/b-i386-rtems4.12-gcc/i386-rtems4.12/newlib/targ-include
-isystem /home/joel/test-gcc/gcc/newlib/libc/include
-B/home/joel/test-gcc/install-master/i386-rtems4.12/bin/
-B/home/joel/test-gcc/install-master/i386-rtems4.12/lib/ -isystem
/home/joel/test-gcc/install-master/i386-rtems4.12/include -isystem
/home/joel/test-gcc/install-master/i386-rtems4.12/sys-include -DHAVE_CONFIG_H
-I. -I../../../../gcc/libgfortran -iquote../../../../gcc/libgfortran/io
-I../../../../gcc/libgfortran/../gcc
-I../../../../gcc/libgfortran/../gcc/config
-I../../../../gcc/libgfortran/../libquadmath -I../../.././gcc
-I../../../../gcc/libgfortran/../libgcc -I../../libgcc
-I../../../../gcc/libgfortran/../libbacktrace -I../../libbacktrace
-I../libbacktrace -std=gnu11 -Wall -Wstrict-prototypes -Wmissing-prototypes
-Wold-style-definition -Wextra -Wwrite-strings
-Werror=implicit-function-declaration -Werror=vla -fcx-fortran-rules
-ffunction-sections -fdata-sections -g -O2 -msoft-float -MT fpu.lo -MD -MP -MF
.deps/fpu.Tpo -c ../../../../gcc/libgfortran/runtime/fpu.c -o fpu.o
In file included from ../../../../gcc/libgfortran/runtime/fpu.c:29:0:
./fpu-target.h: In function 'set_fpu_except_flags':
./fpu-target.h:110:7: error: impossible constraint in 'asm'
   __asm__ __volatile__ ("fdiv\t{%y0, %0|%0, %y0}" : "+t" (f));
   ^~~
./fpu-target.h:130:7: error: impossible constraint in 'asm'
   __asm__ __volatile__ ("fdivs\t%1" : "+t" (f) : "m" (g));
   ^~~
./fpu-target.h:158:7: error: impossible constraint in 'asm'
   __asm__ __volatile__ ("fdivs\t%1" : "+t" (f) : "m" (g));
   ^~~
make[6]: *** [fpu.lo] Error 1
=

Has anyone built i386-elf? What embedded target can I build as a comparable?

I tried to build i386-elf but it failed because there was no crt0.o. This was
in libbacktrace. 

==
configure:2999: /home/joel/test-gcc/b-i386-elf-gcc/./gcc/xgcc
-B/home/joel/test-gcc/b-i386-elf-gcc/./gcc/ -nostdinc
-B/home/joel/test-gcc/b-i386-elf-gcc/i386-elf/newlib/ -isystem
/home/joel/test-gcc/b-i386-elf-gcc/i386-elf/newlib/targ-include -isystem
/home/joel/test-gcc/gcc/newlib/libc/include
-B/home/joel/test-gcc/b-i386-elf-gcc/i386-elf/libgloss/i386
-L/home/joel/test-gcc/b-i386-elf-gcc/i386-elf/libgloss/libnosys
-L/home/joel/test-gcc/gcc/libgloss/i386
-B/home/joel/test-gcc/install-master/i386-elf/bin/
-B/home/joel/test-gcc/install-master/i386-elf/lib/ -isystem
/home/joel/test-gcc/install-master/i386-elf/include -isystem
/home/joel/test-gcc/install-master/i386-elf/sys-include-g -O2   conftest.c 
>&5
/home/joel/test-gcc/install-master/i386-elf/bin/ld: cannot find crt0.o: No such
file or directory
collect2: error: ld returned 1 exit status

==

[Bug bootstrap/79120] New: lm32 ICE in dwarf2out_frame_debug_expr, at dwarf2cfi.c:1747

[joel at gcc dot gnu.org]

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

Bug ID: 79120
   Summary: lm32 ICE in dwarf2out_frame_debug_expr, at
dwarf2cfi.c:1747
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: bootstrap
  Assignee: unassigned at gcc dot gnu.org
  Reporter: joel at gcc dot gnu.org
  Target Milestone: ---

Target: lm32-rtems
GCC git master: acb9fddd8093a3f623837ac25f6d50f52d9a80eb
Newlib git master: e02866a1b43fae39d6842bd182de79e54d8e74cd

The ICE occurs when compiling libgfortran.

libtool: compile:  /home/joel/test-gcc/b-lm32-rtems4.12-gcc/./gcc/xgcc
-B/home/joel/test-gcc/b-lm32-rtems4.12-gcc/./gcc/ -nostdinc
-B/home/joel/test-gcc/b-lm32-rtems4.12-gcc/lm32-rtems4.12/newlib/ -isystem
/home/joel/test-gcc/b-lm32-rtems4.12-gcc/lm32-rtems4.12/newlib/targ-include
-isystem /home/joel/test-gcc/gcc/newlib/libc/include
-B/home/joel/test-gcc/install-master/lm32-rtems4.12/bin/
-B/home/joel/test-gcc/install-master/lm32-rtems4.12/lib/ -isystem
/home/joel/test-gcc/install-master/lm32-rtems4.12/include -isystem
/home/joel/test-gcc/install-master/lm32-rtems4.12/sys-include -DHAVE_CONFIG_H
-I. -I../../../gcc/libgfortran -iquote../../../gcc/libgfortran/io
-I../../../gcc/libgfortran/../gcc -I../../../gcc/libgfortran/../gcc/config
-I../.././gcc -I../../../gcc/libgfortran/../libgcc -I../libgcc
-I../../../gcc/libgfortran/../libbacktrace -I../libbacktrace -I../libbacktrace
-std=gnu11 -Wall -Wstrict-prototypes -Wmissing-prototypes
-Wold-style-definition -Wextra -Wwrite-strings
-Werror=implicit-function-declaration -Werror=vla -fcx-fortran-rules
-ffunction-sections -fdata-sections -ffast-math -ftree-vectorize -funroll-loops
--param max-unroll-times=4 -g -O2 -MT matmul_i1.lo -MD -MP -MF
.deps/matmul_i1.Tpo -c ../../../gcc/libgfortran/generated/matmul_i1.c -o
matmul_i1.o
../../../gcc/libgfortran/generated/matmul_i1.c: In function 'matmul_i1':
../../../gcc/libgfortran/generated/matmul_i1.c:2835:1: internal compiler error:
in dwarf2out_frame_debug_expr, at dwarf2cfi.c:1747
 }
 ^
0x62fc69 dwarf2out_frame_debug_expr
../../gcc/gcc/dwarf2cfi.c:1745
0x630354 dwarf2out_frame_debug
../../gcc/gcc/dwarf2cfi.c:2119
0x630354 scan_insn_after
../../gcc/gcc/dwarf2cfi.c:2463
0x631f86 scan_trace
../../gcc/gcc/dwarf2cfi.c:2620
0x632b46 create_cfi_notes
../../gcc/gcc/dwarf2cfi.c:2659
0x632b46 execute_dwarf2_frame
../../gcc/gcc/dwarf2cfi.c:3022
0x632b46 execute
../../gcc/gcc/dwarf2cfi.c:3502
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See <http://gcc.gnu.org/bugs.html> for instructions.

[Bug debug/63741] lm32 ICE in dwarf2out_frame_debug_expr, at dwarf2cfi.c:1677

[joel at gcc dot gnu.org]

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

Joel Sherrill  changed:

   What|Removed |Added

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

--- Comment #9 from Joel Sherrill  ---
See previous comment. Appears to be fixed.

[Bug debug/63741] lm32 ICE in dwarf2out_frame_debug_expr, at dwarf2cfi.c:1677

[joel at gcc dot gnu.org]

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

--- Comment #8 from Joel Sherrill  ---
We are using gcc 4.9.3 for RTEMS 4.11 and gcc 6.3.0 on RTEMS 4.12. This doesn't
happen on either GCC. So closing.

[Bug target/78478] Compile Error for i386-rtems

[joel at gcc dot gnu.org]

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

--- Comment #9 from Joel Sherrill  ---
(In reply to jos...@codesourcery.com from comment #5)
> On Tue, 22 Nov 2016, ubizjak at gmail dot com wrote:
> 
> > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78478
> > 
> > --- Comment #2 from Uroš Bizjak  ---
> > For 7.0, somebody changed i[34567]86-*-rtems* entry in libgcc/config.host to
> > use t-softfp-sfdftf. Please test the following patch:
> 
> The change was by design meant to ensure that _Float128 was always 
> available on x86, so that __float128 can always be aliased to _Float128.  
> Making _Float128 always available means making libgcc support for TFmode 
> always available.
> 
> I.e., the bug was enabling unintended soft-fp usage of XFmode at the same 
> time as enabling usage of TFmode.  The TFmode functions should be kept in 
> libgcc while disabling the conversions between XFmode and TFmode for this 
> case.

Any thoughts on how to fix this? I would love a proper fix. 

But ... My initial reaction is that soft-float on the x86 is of marginal
utility anymore and that removing the soft-float multilib on this target for at
least rtems is an acceptable solution. Soft float seems to be the thing that
breaks on x86 and I don't know that there is really a CPU that needs it
anymore.(In reply to Uroš Bizjak from comment #8)
> (In reply to jos...@codesourcery.com from comment #7)
> > On Tue, 17 Jan 2017, joel at gcc dot gnu.org wrote:
> > 
> > > > I.e., the bug was enabling unintended soft-fp usage of XFmode at the 
> > > > same 
> > > > time as enabling usage of TFmode.  The TFmode functions should be kept 
> > > > in 
> > > > libgcc while disabling the conversions between XFmode and TFmode for 
> > > > this 
> > > > case.
> > > 
> > > Any thoughts on how to fix this? I would love a proper fix. 
> > 
> > Well, you need to distinguish a genuine sfdftf case from sfdfxftf which it 
> > appears this t- file really is.  Distinguish by some configure test that 
> > determines whether there is XFmode support for the multilib being 
> > compiled, I suppose (look at the other tmake_file settings in config.host 
> > based on variables set by configure tests).
> 
> Maybe just add a new t-file without any XFmode and add it to
> i[34567]86-*-rtems*) instead of t-sfdftf.

I could pursue this but is soft-float on the x86 target really worth the
investment of any effort? AFAIK we would be looking at a very old CPU at this
point. 

I only see soft-float listed as a multilib in t-rtems. 

Is there any reason to keep it? :)

[Bug target/78478] Compile Error for i386-rtems

[joel at gcc dot gnu.org]

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

--- Comment #6 from Joel Sherrill  ---
(In reply to jos...@codesourcery.com from comment #5)
> On Tue, 22 Nov 2016, ubizjak at gmail dot com wrote:
> 
> > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78478
> > 
> > --- Comment #2 from Uroš Bizjak  ---
> > For 7.0, somebody changed i[34567]86-*-rtems* entry in libgcc/config.host to
> > use t-softfp-sfdftf. Please test the following patch:
> 
> The change was by design meant to ensure that _Float128 was always 
> available on x86, so that __float128 can always be aliased to _Float128.  
> Making _Float128 always available means making libgcc support for TFmode 
> always available.
> 
> I.e., the bug was enabling unintended soft-fp usage of XFmode at the same 
> time as enabling usage of TFmode.  The TFmode functions should be kept in 
> libgcc while disabling the conversions between XFmode and TFmode for this 
> case.

Any thoughts on how to fix this? I would love a proper fix. 

But ... My initial reaction is that soft-float on the x86 is of marginal
utility anymore and that removing the soft-float multilib on this target for at
least rtems is an acceptable solution. Soft float seems to be the thing that
breaks on x86 and I don't know that there is really a CPU that needs it
anymore.

[Bug bootstrap/79063] New: GCC Master fails to build for sh

[joel at gcc dot gnu.org]

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

Bug ID: 79063
   Summary: GCC Master fails to build for sh
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: bootstrap
  Assignee: unassigned at gcc dot gnu.org
  Reporter: joel at gcc dot gnu.org
  Target Milestone: ---

7.0.0 20170111

Nothing particularly special about the build. Just fails early with ICE.

/home/joel/test-gcc/b-sh-elf-gcc/./gcc/xgcc
-B/home/joel/test-gcc/b-sh-elf-gcc/./gcc/ -nostdinc
-B/home/joel/test-gcc/b-sh-elf-gcc/sh-elf/newlib/ -isystem
/home/joel/test-gcc/b-sh-elf-gcc/sh-elf/newlib/targ-include -isystem
/home/joel/test-gcc/gcc/newlib/libc/include
-B/home/joel/test-gcc/b-sh-elf-gcc/sh-elf/libgloss/sh
-L/home/joel/test-gcc/b-sh-elf-gcc/sh-elf/libgloss/libnosys
-L/home/joel/test-gcc/gcc/libgloss/sh
-B/home/joel/test-gcc/install-master/sh-elf/bin/
-B/home/joel/test-gcc/install-master/sh-elf/lib/ -isystem
/home/joel/test-gcc/install-master/sh-elf/include -isystem
/home/joel/test-gcc/install-master/sh-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   -g -DIN_LIBGCC2 -fbuilding-libgcc -fno-stack-protector
-Dinhibit_libc  -I. -I. -I../../.././gcc -I../../../../gcc/libgcc
-I../../../../gcc/libgcc/. -I../../../../gcc/libgcc/../gcc
-I../../../../gcc/libgcc/../include  -DHAVE_CC_TLS  -o _mul_df.o -MT _mul_df.o
-MD -MP -MF _mul_df.dep -DFINE_GRAINED_LIBRARIES -DL_mul_df  -c
../../../../gcc/libgcc/fp-bit.c -fvisibility=hidden -DHIDE_EXPORTS
../../../../gcc/libgcc/fp-bit.c: In function '__muldf3':
../../../../gcc/libgcc/fp-bit.c:944:1: error: invalid rtl sharing found in the
insn
 }
 ^
(insn 768 291 296 29 (set (reg:SI 147 t)
(eq:SI (and:SI (subreg:SI (reg/v:DI 205 [ high ]) 0)
(const_int 1 [0x1]))
(const_int 0 [0]))) "../../../../gcc/libgcc/fp-bit.c":881 -1
 (nil))
../../../../gcc/libgcc/fp-bit.c:944:1: error: shared rtx
(subreg:SI (reg/v:DI 205 [ high ]) 0)
../../../../gcc/libgcc/fp-bit.c:944:1: internal compiler error: internal
consistency failure
0x68b8c8 verify_rtx_sharing
../../gcc/gcc/emit-rtl.c:2774
0x68b7ef verify_rtx_sharing
../../gcc/gcc/emit-rtl.c:2789
0x68b7ef verify_rtx_sharing
../../gcc/gcc/emit-rtl.c:2789
0x68b7ef verify_rtx_sharing
../../gcc/gcc/emit-rtl.c:2789
0x68bbeb verify_insn_sharing
../../gcc/gcc/emit-rtl.c:2860
0x6900e7 verify_rtl_sharing()
../../gcc/gcc/emit-rtl.c:2883
0x920acb execute_function_todo
../../gcc/gcc/passes.c:1982
0x9214a5 execute_todo
../../gcc/gcc/passes.c:2015
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See <http://gcc.gnu.org/bugs.html> for instructions.

[Bug target/78478] Compile Error for i386-rtems

[joel at gcc dot gnu.org]

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

--- Comment #4 from Joel Sherrill  ---
FWIW I haven't been able to build this far using i386-elf. It fails in
libbacktrace doing a configure probe because there isn't a crt0.o. I can't
figure out why it isn't building libgloss. I have it and newlib symlinked into
the gcc tree and am configuring with --with-newlib. I don't see any magic
putting it into the noconfigdirs for this target.

I was hoping to reproduce on a target that wasn't rtems.

[Bug target/78478] Compile Error for i386-rtems

[joel at gcc dot gnu.org]

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

--- Comment #3 from Joel Sherrill  ---
That patch gets the build further but there is more wrong. __float128 isn't
defined.

/home/joel/test-gcc/b-i386-rtems4.12-gcc/./gcc/xgcc
-B/home/joel/test-gcc/b-i386-rtems4.12-gcc/./gcc/ -nostdinc
-B/home/joel/test-gcc/b-i386-rtems4.12-gcc/i386-rtems4.12/newlib/ -isystem
/home/joel/test-gcc/b-i386-rtems4.12-gcc/i386-rtems4.12/newlib/targ-include
-isystem /home/joel/test-gcc/gcc/newlib/libc/include
-B/home/joel/test-gcc/install-master/i386-rtems4.12/bin/
-B/home/joel/test-gcc/install-master/i386-rtems4.12/lib/ -isystem
/home/joel/test-gcc/install-master/i386-rtems4.12/include -isystem
/home/joel/test-gcc/install-master/i386-rtems4.12/sys-include -DHAVE_CONFIG_H
-I. -I../../../gcc/libgfortran -iquote../../../gcc/libgfortran/io
-I../../../gcc/libgfortran/../gcc -I../../../gcc/libgfortran/../gcc/config
-I../.././gcc -I../../../gcc/libgfortran/../libgcc -I../libgcc
-I../../../gcc/libgfortran/../libbacktrace -I../libbacktrace -I../libbacktrace
-std=gnu11 -Wall -Wstrict-prototypes -Wmissing-prototypes
-Wold-style-definition -Wextra -Wwrite-strings
-Werror=implicit-function-declaration -Werror=vla -fcx-fortran-rules
-ffunction-sections -fdata-sections -g -O2 -MT single.lo -MD -MP -MF
.deps/single.Tpo -c ../../../gcc/libgfortran/caf/single.c -o single.o
In file included from ./kinds.h:69:0,
 from ../../../gcc/libgfortran/libgfortran.h:232,
 from ../../../gcc/libgfortran/caf/libcaf.h:33,
 from ../../../gcc/libgfortran/caf/single.c:26:
../../../gcc/libgfortran/kinds-override.h:40:5: error: #error "Where has
__float128 gone?"
 #   error "Where has __float128 gone?"
 ^

[Bug target/78480] New: m68k-rtems compile error in libgfortran

[joel at gcc dot gnu.org]

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

Bug ID: 78480
   Summary: m68k-rtems compile error in libgfortran
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: joel at gcc dot gnu.org
  Target Milestone: ---

$ ./gcc/xgcc --version
xgcc (GCC) 7.0.0 20161121 (experimental)

I think the key is -mcpu=5206 has double and long double to be the same but
_LDBL_EQ_DBL. Craig Howland suggested adding this to newlib's ieeefp.h which
detected that it wasn't defined.

#if (DBL_MANT_DIG == LDBL_MANT_DIG)  &&  (LDBL_MIN_EXP == DBL_MIN_EXP)  && \
 (LDBL_MAX_EXP == DBL_MAX_EXP)
   #define _LDBL_EQ_DBL
  #else
   #error "LDBL != DBL"
#endif
#endif


m68k-rtems4.12/sys-include -DHAVE_CONFIG_H -I. -I../../../../gcc/libgfortran
-iquote../../../../gcc/libgfortran/io -I../../../../gcc/libgfortran/../gcc
-I../../../../gcc/libgfortran/../gcc/config -I../../.././gcc
-I../../../../gcc/libgfortran/../libgcc -I../../libgcc
-I../../../../gcc/libgfortran/../libbacktrace -I../../libbacktrace
-I../libbacktrace -std=gnu11 -Wall -Wstrict-prototypes -Wmissing-prototypes
-Wold-style-definition -Wextra -Wwrite-strings
-Werror=implicit-function-declaration -Werror=vla -fcx-fortran-rules
-ffunction-sections -fdata-sections -g -O2 -mcpu=5206 -MT single.lo -MD -MP -MF
.deps/single.Tpo -c ../../../../gcc/libgfortran/caf/single.c -o single.o
In file included from ../../../../gcc/libgfortran/libgfortran.h:81:0,
 from ../../../../gcc/libgfortran/caf/libcaf.h:33,
 from ../../../../gcc/libgfortran/caf/single.c:26:
/home/joel/test-gcc/gcc/newlib/libc/include/ieeefp.h:152:2: error: #error
"double and long double are the same size but LDBL_EQ_DBL is not defined"
 #error "double and long double are the same size but LDBL_EQ_DBL is not
defined"
  ^
/home/joel/test-gcc/gcc/newlib/libc/include/ieeefp.h:195:3: error: unknown type
name '__ieee_ext_field_type'
   __ieee_ext_field_type  ext_fracl : EXT_FRACLBITS;
   ^
/home/joel/test-gcc/gcc/newlib/libc/include/ieeefp.h:195:38: error:
'EXT_FRACLBITS' undeclared here (not in a function); did you mean
'EXT_FRACBITS'?
   __ieee_ext_field_type  ext_fracl : EXT_FRACLBITS;
  ^
  EXT_FRACBITS
/home/joel/test-gcc/gcc/newlib/libc/include/ieeefp.h:195:26: error: bit-field
'ext_fracl' width not an integer constant
   __ieee_ext_field_type  ext_fracl : EXT_FRACLBITS;
  ^
/home/joel/test-gcc/gcc/newlib/libc/include/ieeefp.h:196:3: error: unknown type
name '__ieee_ext_field_type'
   __ieee_ext_field_type  ext_frach : EXT_FRACHBITS;
   ^
/home/joel/test-gcc/gcc/newlib/libc/include/ieeefp.h:196:38: error:
'EXT_FRACHBITS' undeclared here (not in a function); did you mean
'EXT_FRACLBITS'?
   __ieee_ext_field_type  ext_frach : EXT_FRACHBITS;
  ^
  EXT_FRACLBITS
/home/joel/test-gcc/gcc/newlib/libc/include/ieeefp.h:196:26: error: bit-field
'ext_frach' width not an integer constant
   __ieee_ext_field_type  ext_frach : EXT_FRACHBITS;
  ^
/home/joel/test-gcc/gcc/newlib/libc/include/ieeefp.h:197:3: error: unknown type
name '__ieee_ext_field_type'
   __ieee_ext_field_type  ext_exp   : EXT_EXPBITS;
   ^
/home/joel/test-gcc/gcc/newlib/libc/include/ieeefp.h:197:38: error:
'EXT_EXPBITS' undeclared here (not in a function); did you mean 'EXT_EXP_BIAS'?
   __ieee_ext_field_type  ext_exp   : EXT_EXPBITS;
  ^~~
  EXT_EXP_BIAS
/home/joel/test-gcc/gcc/newlib/libc/include/ieeefp.h:197:26: error: bit-field
'ext_exp' width not an integer constant
   __ieee_ext_field_type  ext_exp   : EXT_EXPBITS;
  ^~~
/home/joel/test-gcc/gcc/newlib/libc/include/ieeefp.h:198:3: error: unknown type
name '__ieee_ext_field_type'
   __ieee_ext_field_type  ext_sign  : 1;
   ^

[Bug target/78478] Compile Error for i386-rtems

[joel at gcc dot gnu.org]

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

Joel Sherrill  changed:

   What|Removed |Added

 Target||i386-rtems4.12
  Known to work||6.2.1
Version|unknown |7.0

--- Comment #1 from Joel Sherrill  ---
This error did not exist in "6.2.1 20161110"

$ ./gcc/xgcc --version
xgcc (GCC) 7.0.0 20161121 (experimental)
This patch allowed the build to continue:

diff --git a/libgcc/soft-fp/extended.h b/libgcc/soft-fp/extended.h
index 7b19e83..6c7396d 100644
--- a/libgcc/soft-fp/extended.h
+++ b/libgcc/soft-fp/extended.h
@@ -66,7 +66,11 @@
 #define _FP_HIGHBIT_DW_E   \
   ((_FP_W_TYPE) 1 << (_FP_WFRACBITS_DW_E - 1) % _FP_W_TYPE_SIZE)

+#ifdef _SOFT_FLOAT
+typedef float XFtype;
+#else
 typedef float XFtype __attribute__ ((mode (XF)));
+#endif

 #if _FP_W_TYPE_SIZE < 64

[Bug target/78478] New: Compile Error for i386-rtems

[joel at gcc dot gnu.org]

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

Bug ID: 78478
   Summary: Compile Error for i386-rtems
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: joel at gcc dot gnu.org
  Target Milestone: ---

This is on the git master (13d9a9837159ecd162d08fbbe2ef655aebb7a4c9) as of
yesterday.

This appears to be an issue with soft-float.

/home/joel/test-gcc/b-i386-rtems4.12-gcc/./gcc/xgcc
-B/home/joel/test-gcc/b-i386-rtems4.12-gcc/./gcc/ -nostdinc
-B/home/joel/test-gcc/b-i386-rtems4.12-gcc/i386-rtems4.12/newlib/ -isystem
/home/joel/test-gcc/b-i386-rtems4.12-gcc/i386-rtems4.12/newlib/targ-include
-isystem /home/joel/test-gcc/gcc/newlib/libc/include
-B/home/joel/test-gcc/install-master/i386-rtems4.12/bin/
-B/home/joel/test-gcc/install-master/i386-rtems4.12/lib/ -isystem
/home/joel/test-gcc/install-master/i386-rtems4.12/include -isystem
/home/joel/test-gcc/install-master/i386-rtems4.12/sys-include-g -O2
-msoft-float -O2 -I../../../../gcc/libgcc/../newlib/libc/sys/rtems/include -g
-O2 -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../../../../gcc/libgcc -I../../../../gcc/libgcc/.
-I../../../../gcc/libgcc/../gcc -I../../../../gcc/libgcc/../include 
-DHAVE_CC_TLS  -Wno-missing-prototypes -Wno-type-limits -o trunctfdf2.o -MT
trunctfdf2.o -MD -MP -MF trunctfdf2.dep  -c
../../../../gcc/libgcc/soft-fp/trunctfdf2.c -fvisibility=hidden -DHIDE_EXPORTS
/home/joel/test-gcc/b-i386-rtems4.12-gcc/./gcc/xgcc
-B/home/joel/test-gcc/b-i386-rtems4.12-gcc/./gcc/ -nostdinc
-B/home/joel/test-gcc/b-i386-rtems4.12-gcc/i386-rtems4.12/newlib/ -isystem
/home/joel/test-gcc/b-i386-rtems4.12-gcc/i386-rtems4.12/newlib/targ-include
-isystem /home/joel/test-gcc/gcc/newlib/libc/include
-B/home/joel/test-gcc/install-master/i386-rtems4.12/bin/
-B/home/joel/test-gcc/install-master/i386-rtems4.12/lib/ -isystem
/home/joel/test-gcc/install-master/i386-rtems4.12/include -isystem
/home/joel/test-gcc/install-master/i386-rtems4.12/sys-include-g -O2
-msoft-float -O2 -I../../../../gcc/libgcc/../newlib/libc/sys/rtems/include -g
-O2 -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../../../../gcc/libgcc -I../../../../gcc/libgcc/.
-I../../../../gcc/libgcc/../gcc -I../../../../gcc/libgcc/../include 
-DHAVE_CC_TLS  -Wno-missing-prototypes -Wno-type-limits -o trunctfxf2.o -MT
trunctfxf2.o -MD -MP -MF trunctfxf2.dep  -c
../../../../gcc/libgcc/soft-fp/trunctfxf2.c -fvisibility=hidden -DHIDE_EXPORTS
In file included from ../../../../gcc/libgcc/soft-fp/extendxftf2.c:31:0:
../../../../gcc/libgcc/soft-fp/extended.h:69:1: error: unable to emulate 'XF'
 typedef float XFtype __attribute__ ((mode (XF)));

[Bug libgcc/70720] moxie-rtems stanza does not include crti/crtn extra_parts

[joel at gcc dot gnu.org]

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

Joel Sherrill  changed:

   What|Removed |Added

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

--- Comment #6 from Joel Sherrill  ---
Fix should be on all branches.

[Bug libgcc/70720] moxie-rtems stanza does not include crti/crtn extra_parts

[joel at gcc dot gnu.org]

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

--- Comment #2 from Joel Sherrill  ---
Sebastian, should this be applied to other branches?

Should the PR be closed?

[Bug libgcc/70720] New: moxie-rtems stanza does not include crti/crtn extra_parts

[joel at gcc dot gnu.org]

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

Bug ID: 70720
   Summary: moxie-rtems stanza does not include crti/crtn
extra_parts
   Product: gcc
   Version: 4.9.4
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libgcc
  Assignee: unassigned at gcc dot gnu.org
  Reporter: joel at gcc dot gnu.org
  Target Milestone: ---

Created attachment 38305
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=38305&action=edit
Merge moxie-rtems stanza with other moxie stanzas.

moxie-rtems C++ applications fail to link because, the moxie-rtems stanza in
libgcc/config.host does not include extra_parts.

The solution is to add moxie-rtems to the list of other moxie targets above and
delete the special moxie-rtems stanza.

Filing this as a bug since it impacts at least from gcc 4.9 to the master.

[Bug c/70085] New: False positive -Wmisleading-indentation

[joel at gcc dot gnu.org]

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

Bug ID: 70085
   Summary: False positive -Wmisleading-indentation
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: joel at gcc dot gnu.org
  Target Milestone: ---

In code which indents cpp directives to match the code, the checker is
confused. The following example is sufficient to generate the warning.


===
#define ENABLE_FEATURE

int f(int x, int y)
{
  if (x > y)
return x - y;

  #ifdef ENABLE_FEATURE
if (x == y)
  return 0;
  #endif

  return -1;
}
===

sparc-rtems4.12-gcc (GCC) 6.0.0 20160228 (RTEMS 4.12, RSB
b537e5536459e207fc8e56a1df3774c1700606d5, Newlib 2.3.0.20160226)


indent.c: In function 'f':
indent.c:9:5: warning: statement is indented as if it were guarded by...
[-Wmisleading-indentation]
 if (x == y)
 ^~
indent.c:5:3: note: ...this 'if' clause, but it is not
   if (x > y)
   ^~

[Bug libgcc/62097] t-hardfp requires GNU sed

[joel at gcc dot gnu.org]

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

--- Comment #8 from Joel Sherrill  ---
(In reply to rsand...@gcc.gnu.org from comment #7)
> AIUI usual practice is not to assign stuff to people
> without asking them first, otherwise it gives the
> impression that someone is actively working on it
> when they're not.

Sorry Richard. I didn't mean to imply that you were 
working on it. Just that it looked very likely you
wrote the code causing the problem.

[Bug libgcc/62097] t-hardfp requires GNU sed

[joel at gcc dot gnu.org]

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

--- Comment #6 from Joel Sherrill  ---
git blame pins us down a bit on the change:

4b366ca9 (rsandifo 2014-02-07 07:46:34 + 74) hardfp_defines_for = \
4b366ca9 (rsandifo 2014-02-07 07:46:34 + 75)   $(shell echo $1 | \
4b366ca9 (rsandifo 2014-02-07 07:46:34 + 76) sed
's/\(.*\)\($(hardfp_mode_regexp)\)\($(hardfp_suffix_regexp)\|\)$$/-DFUNC=__&
-DOP_\1\3 -DTYPE=\2/')
4b366ca9 (rsandifo 2014-02-07 07:46:34 + 77) 

commit 4b366ca99e51b2e80ceb5f2b7ece5189f43bd661
Author: rsandifo 
Date:   Fri Feb 7 07:46:34 2014 +

libgcc/
* configure.ac (libgcc_cv_mips_hard_float): New.
* configure: Regenerate.
* config.host (mips*-*-*): Use t-hardfp-sfdf rather than
t-softfp-sfdf for hard-float targets.
* config/mips/t-mips (LIB2_SIDITI_CONV_FUNCS): Reinstate.
(softfp_float_modes, softfp_int_modes, softfp_extensions)
(softfp_truncations, softfp_exclude_libgcc2): New.
* config/t-hardfp: New file.
* config/t-hardfp-sfdf: Likewise.
* config/hardfp.c: Likewise.


git-svn-id: svn+ssh://gcc.gnu.org/svn/gcc/trunk@207593
138bc75d-0d04-0410-961f-82ee72b054a4

[Bug libgcc/62097] t-hardfp requires GNU sed

[joel at gcc dot gnu.org]

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

--- Comment #5 from Joel Sherrill  ---
MIPS tools for RTEMS are unbuildable on *BSD due to this GNU sed dependency.

[Bug target/65779] New: undefined local symbol on powerpc

[joel at gcc dot gnu.org]

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

Bug ID: 65779
   Summary: undefined local symbol on powerpc
   Product: gcc
   Version: 5.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: joel at gcc dot gnu.org

Created attachment 35323
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=35323&action=edit
Preprocessed source from zlib.c from RTEMS PowerPC bootloader

This file compiled without an undefined symbol with many gcc versions prior to
5.x.

powerpc-rtems4.11-gcc (GCC) 5.0.0 20150412 (experimental)

Fails:  powerpc-rtems4.11-gcc -mrelocatable -mcpu=603e -O2 -g zlib_pp.c 
Passes: powerpc-rtems4.11-gcc -mcpu=603e -O2 -g zlib_pp.c
Fails:  powerpc-rtems4.11-gcc -mrelocatable  -O2 -g zlib_pp.c

Also passes at -Os, -O0, and -O1.

The error is that the assembly language produced has a .4byte directive with a
reference to a symbol that is not generated.

$ grep LCL2 zlib_pp.s 
.LCL22:
lwz 0,.LCL22-.LCF22(30)
.LCL23:
lwz 0,.LCL23-.LCF23(30)
.LCL24:
lwz 0,.LCL24-.LCF24(30)
.LCL25:
lwz 0,.LCL25-.LCF25(30)
.4byte.LCL2
.4byte.LCL2

[Bug target/63683] m32c-rtems ICE unable to find spill register compiling libgcc

[joel at gcc dot gnu.org]

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

--- Comment #1 from Joel Sherrill  ---
Still fails on gcc head today.

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

[joel at gcc dot gnu.org]

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

Bug ID: 65501
   Summary: v850 ICE at c_register_pragma_1, at
c-family/c-pragma.c:1317
   Product: gcc
   Version: 5.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: joel at gcc dot gnu.org

This occurs during the exception model probe for libstdc++-v3. This should be
reproducible on v850-elf. I think this is the conftest.c based on the
aclocal.m4 file:

cat > conftest.$ac_ext << EOF
[#]line __oline__ "configure"
struct S { ~S(); };
void bar();
void foo()
{
  S s;
  bar();
}


configure:15092: checking for exception model to use
configure:15133:  /users/joel/test-gcc/b-v850-rtems4.11-gcc/./gcc/xgcc
-shared-libgcc -B/users/joel/test-gcc/b-v850-rtems4.11-gcc/./gcc -nostdinc++
-L/users/joel/test-gcc/b-v850-rtems4.11-gcc/v850-rtems4.11/libstdc++-v3/src
-L/users/joel/test-gcc/b-v850-rtems4.11-gcc/v850-rtems4.11/libstdc++-v3/src/.libs
-L/users/joel/test-gcc/b-v850-rtems4.11-gcc/v850-rtems4.11/libstdc++-v3/libsupc++/.libs
-nostdinc -B/users/joel/test-gcc/b-v850-rtems4.11-gcc/v850-rtems4.11/newlib/
-isystem
/users/joel/test-gcc/b-v850-rtems4.11-gcc/v850-rtems4.11/newlib/targ-include
-isystem /users/joel/test-gcc/gcc/newlib/libc/include
-B/users/joel/test-gcc/install-head/v850-rtems4.11/bin/
-B/users/joel/test-gcc/install-head/v850-rtems4.11/lib/ -isystem
/users/joel/test-gcc/install-head/v850-rtems4.11/include -isystem
/users/joel/test-gcc/install-head/v850-rtems4.11/sys-include-c -S 
conftest.cpp >&5
: internal compiler error: in c_register_pragma_1, at
c-family/c-pragma.c:1317
0x6a15f7 c_register_pragma_1
../../gcc/gcc/c-family/c-pragma.c:1317
0x6a2fa6 c_register_pragma(char const*, char const*, void (*)(cpp_reader*))
../../gcc/gcc/c-family/c-pragma.c:1335
0x534013 init_cp_pragma
../../gcc/gcc/cp/lex.c:225
0x534013 cxx_init()
../../gcc/gcc/cp/lex.c:276
0x435493 lang_dependent_init
../../gcc/gcc/toplev.c:1845
0x435493 do_compile
../../gcc/gcc/toplev.c:2062
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See <http://gcc.gnu.org/bugs.html> for instructions.
configure:15136: $? = 1
configure:15165: error: unable to detect exception model

[Bug target/64377] nios2 compile error in options-save.c

[joel at gcc dot gnu.org]

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

Joel Sherrill  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |FIXED

--- Comment #21 from Joel Sherrill  ---
(In reply to Martin Liška from comment #20)
> Can I please ask someone to confirm that the patch works and mark this issue
> as resolved?

As reported above, I built the toolset and RTEMS but have no target to test on.
I am going to close it.

Sandra was testing on hardware so it is safe to safe she got by this as well.

[Bug debug/63741] lm32 ICE in dwarf2out_frame_debug_expr, at dwarf2cfi.c:1677

[joel at gcc dot gnu.org]

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

--- Comment #7 from Joel Sherrill  ---
I added Jon Beniston who did the initial port and Sebastien Bourdeauducq who is
listed as the lm32 maintainer but hasn't committed since 2011. I hope one of
them can help out here.

[Bug target/64377] nios2 compile error in options-save.c

[joel at gcc dot gnu.org]

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

--- Comment #19 from Joel Sherrill  ---
Sorry.. wrong PR.

[Bug target/64377] nios2 compile error in options-save.c

[joel at gcc dot gnu.org]

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

--- Comment #18 from Joel Sherrill  ---
I added Jon Beniston who did the initial port and Sebastien Bourdeauducq who is
listed as the lm32 maintainer but hasn't committed since 2011. I hope one of
them can help out here.

[Bug debug/63741] lm32 ICE in dwarf2out_frame_debug_expr, at dwarf2cfi.c:1677

[joel at gcc dot gnu.org]

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

--- Comment #6 from Joel Sherrill  ---
I am not an expert on the machine descriptions or the lm32. If someone wants to
propose a patch, I am happy to test it.

[Bug target/50928] m32c ICE building RTEMS

[joel at gcc dot gnu.org]

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

--- Comment #9 from Joel Sherrill  ---
I updated binutils, newlib and gcc. The build fails very early for me:

/users/joel/test-gcc/b-m32c-rtems4.11-gcc/./gcc/xgcc
-B/users/joel/test-gcc/b-m32c-rtems4.11-gcc/./gcc/ -nostdinc
-B/users/joel/test-gcc/b-m32c-rtems4.11-gcc/m32c-rtems4.11/newlib/ -isystem
/users/joel/test-gcc/b-m32c-rtems4.11-gcc/m32c-rtems4.11/newlib/targ-include
-isystem /users/joel/test-gcc/gcc/newlib/libc/include
-B/users/joel/test-gcc/install-head/m32c-rtems4.11/bin/
-B/users/joel/test-gcc/install-head/m32c-rtems4.11/lib/ -isystem
/users/joel/test-gcc/install-head/m32c-rtems4.11/include -isystem
/users/joel/test-gcc/install-head/m32c-rtems4.11/sys-include-g -O2
-mcpu=m32cm -O2 -I../../../../gcc/libgcc/../newlib/libc/sys/rtems/include -g
-O2 -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../../../../gcc/libgcc -I../../../../gcc/libgcc/.
-I../../../../gcc/libgcc/../gcc -I../../../../gcc/libgcc/../include 
-DHAVE_CC_TLS -DUSE_EMUTLS -o _muldi3.o -MT _muldi3.o -MD -MP -MF _muldi3.dep
-DL_muldi3 -c ../../../../gcc/libgcc/libgcc2.c -fvisibility=hidden
-DHIDE_EXPORTS
/tmp/ccx0vJbF.s: Assembler messages:
/tmp/ccx0vJbF.s: Error: relocation out of range
make[4]: *** [_muldi3.o] Error 1

[Bug debug/63741] lm32 ICE in dwarf2out_frame_debug_expr, at dwarf2cfi.c:1677

[joel at gcc dot gnu.org]

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

--- Comment #3 from Joel Sherrill  ---
Added the dwarf maintainers hoping to get an answer. From an RTEMS perspective,
the lm32 is not usable. Both 4.9 and the head are broken. Hoping you two have
an idea. Happy to help since this is a cross target.

[Bug target/50928] m32c ICE building RTEMS

[joel at gcc dot gnu.org]

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

--- Comment #7 from Joel Sherrill  ---
DJ.. do you think the patch from Bernd can be applied to the 4.9 branch? and
maybe the head?

[Bug target/64600] [5.0 regression] arm-rtems ICE on valid code (-mcpu=xscale)

[joel at gcc dot gnu.org]

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

--- Comment #9 from Joel Sherrill  ---
I don't build with checking enabled. 

The normal recommended configuration for an RTEMS toolchain is long since we
build newlib at the same time and have iconv options. When I do git bisect, I
usually drop the newlib and disable-multilib. But here is how it failed for me
per the top level config.log:

/users/joel/test-gcc/gcc/configure --verbose --disable-werror
--disable-libstdcxx-pch --with-gnu-as --with-gnu-ld --with-newlib
--enable-multilib --enable-newlib-mb --enable-newlib-iconv --with-system-zlib
--disable-nls --without-included-gettext --disable-win32-registry
--enable-version-specific-runtime-libs --enable-newlib-iconv
--enable-newlib-iconv-encodings=big5,cp775,cp850,cp852,cp855,cp866,euc_jp,euc_kr,euc_tw,iso_8859_1,iso_8859_10,iso_8859_11,iso_8859_13,iso_8859_14,iso_8859_15,iso_8859_2,iso_8859_3,iso_8859_4,iso_8859_5,iso_8859_6,iso_8859_7,iso_8859_8,iso_8859_9,iso_ir_111,koi8_r,koi8_ru,koi8_u,koi8_uni,ucs_2,ucs_2_internal,ucs_2be,ucs_2le,ucs_4,ucs_4_internal,ucs_4be,ucs_4le,us_ascii,utf_16,utf_16be,utf_16le,utf_8,win_1250,win_1251,win_1252,win_1253,win_1254,win_1255,win_1256,win_1257,win_1258
--disable-lto --enable-newlib-io-c99-formats --enable-threads --disable-plugin
--enable-languages=c,c++ --target=arm-rtems4.11
--prefix=/users/joel/test-gcc/install-head

I am happy to try anything you need.

[Bug target/64606] New: multiple warnings in arm target code

[joel at gcc dot gnu.org]

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

Bug ID: 64606
   Summary: multiple warnings in arm target code
   Product: gcc
   Version: 5.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: joel at gcc dot gnu.org

/users/joel/test-gcc/b-arm-rtems4.11-gcc/./gcc/xgcc
-B/users/joel/test-gcc/b-arm-rtems4.11-gcc/./gcc/ -nostdinc
-B/users/joel/test-gcc/b-arm-rtems4.11-gcc/arm-rtems4.11/newlib/ -isystem
/users/joel/test-gcc/b-arm-rtems4.11-gcc/arm-rtems4.11/newlib/targ-include
-isystem /users/joel/test-gcc/gcc/newlib/libc/include
-B/users/joel/test-gcc/install-head/arm-rtems4.11/bin/
-B/users/joel/test-gcc/install-head/arm-rtems4.11/lib/ -isystem
/users/joel/test-gcc/install-head/arm-rtems4.11/include -isystem
/users/joel/test-gcc/install-head/arm-rtems4.11/sys-include-g -O2 -mthumb
-O2 -I../../../../gcc/libgcc/../newlib/libc/sys/rtems/include -g -O2 -DIN_GCC 
-DCROSS_DIRECTORY_STRUCTURE  -W -Wall -Wno-narrowing -Wwrite-strings
-Wcast-qual -Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition 
-isystem ./include   -fno-inline -g -DIN_LIBGCC2 -fbuilding-libgcc
-fno-stack-protector -Dinhibit_libc  -fno-inline -I. -I. -I../../.././gcc
-I../../../../gcc/libgcc -I../../../../gcc/libgcc/.
-I../../../../gcc/libgcc/../gcc -I../../../../gcc/libgcc/../include 
-DHAVE_CC_TLS  -o _fractunsUDAUDI.o -MT _fractunsUDAUDI.o -MD -MP -MF
_fractunsUDAUDI.dep -DL_fractuns -DFROM_UDA -DTO_UDI -c
../../../../gcc/libgcc/fixed-bit.c -fvisibility=hidden -DHIDE_EXPORTS
mv -f libunwind.visT libunwind.vis
../../../gcc/libgcc/config/arm/fp16.c:97:1: warning: no previous prototype for
'__gnu_h2f_internal' [-Wmissing-prototypes]
 __gnu_h2f_internal(unsigned short a, int ieee)
 ^
../../../gcc/libgcc/config/arm/fp16.c:122:1: warning: no previous prototype for
'__gnu_f2h_ieee' [-Wmissing-prototypes]
 __gnu_f2h_ieee(unsigned int a)
 ^
../../../gcc/libgcc/config/arm/fp16.c:128:1: warning: no previous prototype for
'__gnu_h2f_ieee' [-Wmissing-prototypes]
 __gnu_h2f_ieee(unsigned short a)
 ^
../../../gcc/libgcc/config/arm/fp16.c:134:1: warning: no previous prototype for
'__gnu_f2h_alternative' [-Wmissing-prototypes]
 __gnu_f2h_alternative(unsigned int x)
 ^
../../../gcc/libgcc/config/arm/fp16.c:140:1: warning: no previous prototype for
'__gnu_h2f_alternative' [-Wmissing-prototypes]
 __gnu_h2f_alternative(unsigned short a)
 ^
In file included from ../../../gcc/libgcc/config/arm/unwind-arm.c:143:0:
../../../gcc/libgcc/unwind-arm-common.inc: In function 'get_eit_entry':
../../../gcc/libgcc/unwind-arm-common.inc:245:29: warning: cast discards
'const' qualifier from pointer target type [-Wcast-qual]
   ucbp->pr_cache.ehtp = (_Unwind_EHT_Header *)&eitp->content;

[Bug debug/64602] h8300 ICE building libssp/ssp.c ICE, in maybe_record_trace_start, at dwarf2cfi.c:2308

[joel at gcc dot gnu.org]

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

--- Comment #1 from Joel Sherrill  ---
Created attachment 34451
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=34451&action=edit
Preprocessed source of libssp/ssp.c that trips error

[Bug debug/64602] New: h8300 ICE building libssp/ssp.c ICE, in maybe_record_trace_start, at dwarf2cfi.c:2308

[joel at gcc dot gnu.org]

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

Bug ID: 64602
   Summary: h8300 ICE building libssp/ssp.c ICE, in
maybe_record_trace_start, at dwarf2cfi.c:2308
   Product: gcc
   Version: 5.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: debug
  Assignee: unassigned at gcc dot gnu.org
  Reporter: joel at gcc dot gnu.org

git head d4cbe45aae70e38c12f3cd7430427c98289d7882


/users/joel/test-gcc/b-h8300-elf-gcc/./gcc/xgcc
-B/users/joel/test-gcc/b-h8300-elf-gcc/./gcc/ -nostdinc
-B/users/joel/test-gcc/b-h8300-elf-gcc/h8300-elf/h8sx/normal/newlib/ -isystem
/users/joel/test-gcc/b-h8300-elf-gcc/h8300-elf/h8sx/normal/newlib/targ-include
-isystem /users/joel/test-gcc/gcc/newlib/libc/include
-B/users/joel/test-gcc/install-head/h8300-elf/bin/
-B/users/joel/test-gcc/install-head/h8300-elf/lib/ -isystem
/users/joel/test-gcc/install-head/h8300-elf/include -isystem
/users/joel/test-gcc/install-head/h8300-elf/sys-include -msx -mn
-DHAVE_CONFIG_H -I. -I../../../../../gcc/libssp -Wall -g -O2 -msx -mn -MT
ssp.lo -MD -MP -MF .deps/ssp.Tpo -c ../../../../../gcc/libssp/ssp.c -o ssp.o
../../../../../gcc/libssp/ssp.c: In function 'fail.isra___0':
../../../../../gcc/libssp/ssp.c:163:1: internal compiler error: in
maybe_record_trace_start, at dwarf2cfi.c:2308
 }
 ^
0x5ddbb7 maybe_record_trace_start
../../gcc/gcc/dwarf2cfi.c:2308
0x5dde63 create_trace_edges
../../gcc/gcc/dwarf2cfi.c:2400
0x5de11f scan_trace
../../gcc/gcc/dwarf2cfi.c:2614
0x5dec6a create_cfi_notes
../../gcc/gcc/dwarf2cfi.c:2640
0x5dec6a execute_dwarf2_frame
../../gcc/gcc/dwarf2cfi.c:2996
0x5dec6a execute
../../gcc/gcc/dwarf2cfi.c:3476
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See <http://gcc.gnu.org/bugs.html> for instructions.

[Bug target/64600] arm-rtems ICE on valid code (-mcpu=xscale)

[joel at gcc dot gnu.org]

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

--- Comment #3 from Joel Sherrill  ---
(In reply to Joel Sherrill from comment #1)
> Created attachment 34450 [details]
> Preprocessed RTEMS source which produces the error

Attached test case compiles at -Os but not -O1 or -O2. 
-O2 without -mcpu=xscale also works.

Compiles find with end of 4.9 branch

arm-rtems4.11-gcc (GCC) 4.9.3 20150104 (prerelease)

[Bug target/64599] arm-rtems ICE on valid code (-mcpu=xscale)

[joel at gcc dot gnu.org]

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

Joel Sherrill  changed:

   What|Removed |Added

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

--- Comment #1 from Joel Sherrill  ---
Weird. Bugzilla hiccuped and two identical PRs ended up submitted. Closing this
one.

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

[Bug target/64600] arm-rtems ICE on valid code (-mcpu=xscale)

[joel at gcc dot gnu.org]

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

--- Comment #2 from Joel Sherrill  ---
*** Bug 64599 has been marked as a duplicate of this bug. ***

[Bug target/64600] arm-rtems ICE on valid code (-mcpu=xscale)

[joel at gcc dot gnu.org]

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

--- Comment #1 from Joel Sherrill  ---
Created attachment 34450
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=34450&action=edit
Preprocessed RTEMS source which produces the error

[Bug target/64600] New: arm-rtems ICE on valid code (-mcpu=xscale)

[joel at gcc dot gnu.org]

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

Bug ID: 64600
   Summary: arm-rtems ICE on valid code (-mcpu=xscale)
   Product: gcc
   Version: 5.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: joel at gcc dot gnu.org

$ arm-rtems4.11-gcc --version
arm-rtems4.11-gcc (GCC) 5.0.0 20150114 (experimental)

Last hash per git: commit d4cbe45aae70e38c12f3cd7430427c98289d7882

The fix for 64460 is in place.

Attached test case compiles at -Os but not -O1 or -O2. 
-O2 without -mcpu=xscale also works.

arm-rtems4.11-gcc --pipe -DHAVE_CONFIG_H   -I..
-I../../cpukit/../../../gumstix/lib/include   -mcpu=xscale -O2 -g -Wall
-Wmissing-prototypes -Wimplicit-function-declaration -Wstrict-prototypes
-Wnested-externs -MT src/libcsupport_a-cfgetospeed.o -MD -MP -MF
src/.deps/libcsupport_a-cfgetospeed.Tpo -c -o src/libcsupport_a-cfgetospeed.o
`test -f 'src/cfgetospeed.c' || echo
'../../../../../../rtems/c/src/../../cpukit/libcsupport/'`src/cfgetospeed.c
../../../../../../rtems/c/src/../../cpukit/libcsupport/src/cfgetospeed.c: In
function 'cfgetospeed':
../../../../../../rtems/c/src/../../cpukit/libcsupport/src/cfgetospeed.c:37:1:
internal compiler error: in decompose, at rtl.h:2005
 }
 ^
0x41c918 wi::int_traits >::decompose(long*,
unsigned int, std::pair const&)
../../gcc/gcc/rtl.h:2005
0x91eae0 wi::int_traits >::decompose(long*,
unsigned int, std::pair const&)
../../gcc/gcc/rtl.h:2005
0x91eae0 wide_int_ref_storage::wide_int_ref_storage >(std::pair const&, unsigned int)
../../gcc/gcc/wide-int.h:957
0x91eae0 generic_wide_int
>::generic_wide_int >(std::pair const&, unsigned int)
../../gcc/gcc/wide-int.h:733
0x91eae0 wi::binary_traits,
std::pair, wi::int_traits >::precision_type, wi::int_traits >::precision_type>::result_type wi::sub, std::pair >(std::pair const&, std::pair const&)
../../gcc/gcc/wide-int.h:2357
0x91eae0 simplify_const_binary_operation(rtx_code, machine_mode, rtx_def*,
rtx_def*)
../../gcc/gcc/simplify-rtx.c:3867
0x91bf3f simplify_binary_operation(rtx_code, machine_mode, rtx_def*, rtx_def*)
../../gcc/gcc/simplify-rtx.c:1972
0x91fc77 simplify_associative_operation
../../gcc/gcc/simplify-rtx.c:1929
0x9188cc simplify_binary_operation_1
../../gcc/gcc/simplify-rtx.c:2967
0xdd4f21 combine_simplify_rtx
../../gcc/gcc/combine.c:5541
0xdd743b subst
../../gcc/gcc/combine.c:5374
0xdd70c8 subst
../../gcc/gcc/combine.c:5319
0xdd97ce try_combine
../../gcc/gcc/combine.c:3266
0xddef81 combine_instructions
../../gcc/gcc/combine.c:1312
0xddef81 rest_of_handle_combine
../../gcc/gcc/combine.c:14094
0xddef81 execute
../../gcc/gcc/combine.c:14137
Please submit a full bug report,
with preprocessed source if appropriate.

[Bug target/64599] New: arm-rtems ICE on valid code (-mcpu=xscale)

[joel at gcc dot gnu.org]

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

Bug ID: 64599
   Summary: arm-rtems ICE on valid code (-mcpu=xscale)
   Product: gcc
   Version: 5.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: joel at gcc dot gnu.org

Created attachment 34449
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=34449&action=edit
Preprocessed RTEMS source which produces the error

$ arm-rtems4.11-gcc --version
arm-rtems4.11-gcc (GCC) 5.0.0 20150114 (experimental)

Last hash per git: commit d4cbe45aae70e38c12f3cd7430427c98289d7882

The fix for 64460 is in place.

Attached test case compiles at -Os but not -O1 or -O2. 
-O2 without -mcpu=xscale also works.

arm-rtems4.11-gcc --pipe -DHAVE_CONFIG_H   -I..
-I../../cpukit/../../../gumstix/lib/include   -mcpu=xscale -O2 -g -Wall
-Wmissing-prototypes -Wimplicit-function-declaration -Wstrict-prototypes
-Wnested-externs -MT src/libcsupport_a-cfgetospeed.o -MD -MP -MF
src/.deps/libcsupport_a-cfgetospeed.Tpo -c -o src/libcsupport_a-cfgetospeed.o
`test -f 'src/cfgetospeed.c' || echo
'../../../../../../rtems/c/src/../../cpukit/libcsupport/'`src/cfgetospeed.c
../../../../../../rtems/c/src/../../cpukit/libcsupport/src/cfgetospeed.c: In
function 'cfgetospeed':
../../../../../../rtems/c/src/../../cpukit/libcsupport/src/cfgetospeed.c:37:1:
internal compiler error: in decompose, at rtl.h:2005
 }
 ^
0x41c918 wi::int_traits >::decompose(long*,
unsigned int, std::pair const&)
../../gcc/gcc/rtl.h:2005
0x91eae0 wi::int_traits >::decompose(long*,
unsigned int, std::pair const&)
../../gcc/gcc/rtl.h:2005
0x91eae0 wide_int_ref_storage::wide_int_ref_storage >(std::pair const&, unsigned int)
../../gcc/gcc/wide-int.h:957
0x91eae0 generic_wide_int
>::generic_wide_int >(std::pair const&, unsigned int)
../../gcc/gcc/wide-int.h:733
0x91eae0 wi::binary_traits,
std::pair, wi::int_traits >::precision_type, wi::int_traits >::precision_type>::result_type wi::sub, std::pair >(std::pair const&, std::pair const&)
../../gcc/gcc/wide-int.h:2357
0x91eae0 simplify_const_binary_operation(rtx_code, machine_mode, rtx_def*,
rtx_def*)
../../gcc/gcc/simplify-rtx.c:3867
0x91bf3f simplify_binary_operation(rtx_code, machine_mode, rtx_def*, rtx_def*)
../../gcc/gcc/simplify-rtx.c:1972
0x91fc77 simplify_associative_operation
../../gcc/gcc/simplify-rtx.c:1929
0x9188cc simplify_binary_operation_1
../../gcc/gcc/simplify-rtx.c:2967
0xdd4f21 combine_simplify_rtx
../../gcc/gcc/combine.c:5541
0xdd743b subst
../../gcc/gcc/combine.c:5374
0xdd70c8 subst
../../gcc/gcc/combine.c:5319
0xdd97ce try_combine
../../gcc/gcc/combine.c:3266
0xddef81 combine_instructions
../../gcc/gcc/combine.c:1312
0xddef81 rest_of_handle_combine
../../gcc/gcc/combine.c:14094
0xddef81 execute
../../gcc/gcc/combine.c:14137
Please submit a full bug report,
with preprocessed source if appropriate.

[Bug target/64460] ARM ICE on valid code

[joel at gcc dot gnu.org]

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

Joel Sherrill  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution|--- |FIXED

--- Comment #12 from Joel Sherrill  ---
(In reply to ktkachov from comment #11)
> Joel, can you try trunk after this commit to confirm that it fixes the ICE
> on your end and close this off if ok?

Based on today's results, I am closing this one. The following shows my
compiler version and compiling the original test case.

Thanks.

$ arm-rtems4.11-gcc --version
arm-rtems4.11-gcc (GCC) 5.0.0 20150114 (experimental)
Copyright (C) 2015 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

$  ~/test-gcc/install-head/bin/arm-rtems4.11-gcc -mcpu=xscale -Os -c
/tmp/gumstix.c 
$  ~/test-gcc/install-head/bin/arm-rtems4.11-gcc -mcpu=xscale -O2 -c
/tmp/gumstix.c

[Bug preprocessor/64576] Preprocessor Error With 5.0 not with 4.9.2

[joel at gcc dot gnu.org]

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

--- Comment #3 from Joel Sherrill  ---
(In reply to Jakub Jelinek from comment #2)
> GCC 4.9 behaves the same way with -std=c11, GCC 5 behaves the old way with
> -std=c99.  -std=c11 turns on unicode literals, i.e. u"str", U"str" and
> u8"str".
> So for #u"str" you really need to put there whitespace, so that it isn't
> parsed as # followed by u"str" string literal.

Thanks for the explanation. I was posting that -std=c99 appeared to have an
impact and collided with your much better explanation.

Is this a change in the default language version for gcc?

[Bug preprocessor/64576] New: Preprocessor Error With 5.0 not with 4.9.2

[joel at gcc dot gnu.org]

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

Bug ID: 64576
   Summary: Preprocessor Error With 5.0 not with 4.9.2
   Product: gcc
   Version: 5.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: preprocessor
  Assignee: unassigned at gcc dot gnu.org
  Reporter: joel at gcc dot gnu.org

Created attachment 34431
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=34431&action=edit
Cut down example showing error

The attached example is based on code that has compiled fine for about 15
years. 

$ ~/test-gcc/install-head/bin/powerpc-rtems4.11-gcc  -meabi -mcpu=603e
-msdata=sysv -O2 -c b1.c
b1.c:1:36: error: '#' is not followed by a macro parameter
 #define SETBAT_ASM(batu, batl, u, l)\
^

The macro may have issues but it gcc has been happy with it for a LONG time. :)

[Bug target/64461] bad assembly generated for Coldfire targets

[joel at gcc dot gnu.org]

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

--- Comment #8 from Joel Sherrill  ---
Thanks. I didn't build all our Coldfire BSPs but I checked one and it is OK
now.

[Bug target/64460] ARM ICE on valid code

[joel at gcc dot gnu.org]

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

--- Comment #8 from Joel Sherrill  ---
(In reply to ktkachov from comment #7)
> I guess the testcase is flaky.
> I've posted the patch to fix the ICE and the reasoning behind it at
> https://gcc.gnu.org/ml/gcc-patches/2015-01/msg00686.html

Can you try again with the full test case? The head still fails for me at -O2
and -Os but not -O1. The location in toplev.c has moved down a few lines.

FWIW my original report had -mcpu=xscale but it fails with -mtune=xscale as
well. I 

$  ~/test-gcc/install-head/bin/arm-rtems4.11-gcc --version
arm-rtems4.11-gcc (GCC) 5.0.0 20150112 (experimental)

$  ~/test-gcc/install-head/bin/arm-rtems4.11-gcc -mtune=xscale -O2
/tmp/gumstix.c 
../../../../../../rtems/c/src/../../cpukit/score/src/objectextendinformation.c:
In function '_Objects_Extend_information':
../../../../../../rtems/c/src/../../cpukit/score/src/objectextendinformation.c:278:1:
internal compiler error: Segmentation fault
0x93b6ef crash_signal
../../gcc/gcc/toplev.c:372
0x8e4890 reg_overlap_mentioned_p(rtx_def const*, rtx_def const*)
../../gcc/gcc/rtlanal.c:1519
0xc0dd5c xscale_sched_adjust_cost
../../gcc/gcc/config/arm/arm.c:11534
0xc0d97b arm_adjust_cost
../../gcc/gcc/config/arm/arm.c:11984
0xe1979f dep_cost_1(_dep*, unsigned int)
../../gcc/gcc/haifa-sched.c:1513
0xe1af07 dep_cost(_dep*)
../../gcc/gcc/haifa-sched.c:1532
0xe1af07 priority
../../gcc/gcc/haifa-sched.c:1683
0xe1afff set_priorities(rtx_insn*, rtx_insn*)
../../gcc/gcc/haifa-sched.c:6796
0x8ecd2c compute_priorities()
../../gcc/gcc/sched-rgn.c:2940
0x8ef94d schedule_region
../../gcc/gcc/sched-rgn.c:3033
0x8ef94d schedule_insns()
../../gcc/gcc/sched-rgn.c:3431
0x8f0053 schedule_insns()
../../gcc/gcc/sched-rgn.c:3416
0x8f0053 rest_of_handle_sched
../../gcc/gcc/sched-rgn.c:3635
0x8f0053 execute
../../gcc/gcc/sched-rgn.c:3743
Please submit a full bug report,

[Bug target/64460] ARM ICE on valid code

[joel at gcc dot gnu.org]

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

--- Comment #6 from Joel Sherrill  ---
(In reply to ktkachov from comment #5)
> (In reply to Joel Sherrill from comment #4)
> > (In reply to ktkachov from comment #3)
> > > I have a fix in the works. The bug is down to the "shift" attribute value 
> > > in
> > > one of the patterns, although only xscale_sched_adjust_cost uses that
> > > attribute.
> > 
> > Awesome! I was about to start another attempt at a git bisect but it sounds
> > like you don't need it. Let me know if it is worth running.
> 
> Thanks, but no need. I think I've got the root cause and I got a fix that
> fixes the testcase, I just need to put it through testing.
> 
> A testsuite-appropriate reduced testcase would be nice I guess, although
> I'll kick off a reducer soon.

FWIW the head now builds for arm-rtems again but the bug is still present
with 15b6c83e88101ec7e2efedc114a7940cfbffa479.

FWIW there are a few warnings building the ARM:

../../../../../../gcc/libgcc/config/arm/fp16.c:97:1: warning: no previous
prototype for '__gnu_h2f_internal' [-Wmissing-prototypes]
../../../../../../gcc/libgcc/config/arm/fp16.c:122:1: warning: no previous
prototype for '__gnu_f2h_ieee' [-Wmissing-prototypes]
../../../../../../gcc/libgcc/config/arm/fp16.c:128:1: warning: no previous
prototype for '__gnu_h2f_ieee' [-Wmissing-prototypes]
../../../../../../gcc/libgcc/config/arm/fp16.c:134:1: warning: no previous
prototype for '__gnu_f2h_alternative' [-Wmissing-prototypes]
../../../../../../gcc/libgcc/config/arm/fp16.c:140:1: warning: no previous
prototype for '__gnu_h2f_alternative' [-Wmissing-prototypes]
../../../../../../gcc/libgcc/unwind-arm-common.inc:245:29: warning: cast
discards 'const' qualifier from pointer target type [-Wcast-qual]
../../../../../../gcc/libgcc/emutls.c:159:13: warning: implicit declaration of
function 'calloc' [-Wimplicit-function-declaration]
../../../../../../gcc/libgcc/emutls.c:159:13: warning: incompatible implicit
declaration of built-in function 'calloc'
../../../../../../gcc/libgcc/emutls.c:171:13: warning: implicit declaration of
function 'realloc' [-Wimplicit-function-declaration]
../../../../../../gcc/libgcc/emutls.c:171:13: warning: incompatible implicit
declaration of built-in function 'realloc'

[Bug target/64377] nios2 compile error in options-save.c

[joel at gcc dot gnu.org]

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

--- Comment #8 from Joel Sherrill  ---
(In reply to Martin Liška from comment #7)
> Hello.
> 
> There's suggested patch [1], may I ask someone from nios2 community for
> testing the patch?
> 
> [1] https://gcc.gnu.org/ml/gcc-patches/2015-01/msg00465.html

I can confirm that is enough to build nios2-rtems and build RTEMS itself with
no issues. I don't have a simulator or target to run the tests on.

Is there a free simulator now?

[Bug target/64460] ARM ICE on valid code

[joel at gcc dot gnu.org]

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

--- Comment #4 from Joel Sherrill  ---
(In reply to ktkachov from comment #3)
> I have a fix in the works. The bug is down to the "shift" attribute value in
> one of the patterns, although only xscale_sched_adjust_cost uses that
> attribute.

Awesome! I was about to start another attempt at a git bisect but it sounds
like you don't need it. Let me know if it is worth running.

[Bug target/64546] m32c ICE at calls.c:3638 compiling newlib

[joel at gcc dot gnu.org]

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

--- Comment #1 from Joel Sherrill  ---
Created attachment 34409
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=34409&action=edit
Preprocessed newlib source which produces the ICE

This code compiles with 4.8.3.

[Bug target/64546] New: m32c ICE at calls.c:3638 compiling newlib

[joel at gcc dot gnu.org]

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

Bug ID: 64546
   Summary: m32c ICE at calls.c:3638 compiling newlib
   Product: gcc
   Version: 5.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: joel at gcc dot gnu.org

xgcc (GCC) 5.0.0 20150107 (experimental)

This fails at -O[012S]. The flag -mcpu=m32cm appears to be the trigger.

/home2/joel/build/b-m32c-gcc/./gcc/xgcc -B/home2/joel/build/b-m32c-gcc/./gcc/ 
-c -g -O0 -mcpu=m32cm m32c-fopencookie.c 
/users/joel/test-gcc/gcc/newlib/libc/stdio/fopencookie.c: In function
'fopencookie':
/users/joel/test-gcc/gcc/newlib/libc/stdio/fopencookie.c:260:10: internal
compiler error: in expand_call, at calls.c:3638
   return _fopencookie_r (_REENT, cookie, mode, functions);
  ^
0x558b39 expand_call(tree_node*, rtx_def*, int)
/users/joel/test-gcc/gcc/gcc/calls.c:3638
0x64afa0 expand_expr_real_1(tree_node*, rtx_def*, machine_mode,
expand_modifier, rtx_def**, bool)
/users/joel/test-gcc/gcc/gcc/expr.c:10474
0x656fbc store_expr_with_bounds(tree_node*, rtx_def*, int, bool, tree_node*)
/users/joel/test-gcc/gcc/gcc/expr.c:5368
0x65e5ce expand_assignment(tree_node*, tree_node*, bool)
/users/joel/test-gcc/gcc/gcc/expr.c:5137
0x565886 expand_call_stmt
/users/joel/test-gcc/gcc/gcc/cfgexpand.c:2345
0x565886 expand_gimple_stmt_1
/users/joel/test-gcc/gcc/gcc/cfgexpand.c:3293
0x565886 expand_gimple_stmt
/users/joel/test-gcc/gcc/gcc/cfgexpand.c:3447
0x56b6e4 expand_gimple_basic_block
/users/joel/test-gcc/gcc/gcc/cfgexpand.c:5280
0x56d0ae execute
/users/joel/test-gcc/gcc/gcc/cfgexpand.c:5889
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See <http://gcc.gnu.org/bugs.html> for instructions.

[Bug target/64377] nios2 compile error in options-save.c

[joel at gcc dot gnu.org]

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

--- Comment #6 from Joel Sherrill  ---
(In reply to Sandra Loosemore from comment #5)
> I think complete failure to build GCC for nios2 target due to
> target-inspecific changes is a serious regression that needs to be addressed
> for GCC 5 release.  Can we up the priority?

+1

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

[joel at gcc dot gnu.org]

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

--- Comment #8 from Joel Sherrill  ---
(In reply to Richard Biener from comment #1)
> Did it work with 4.9.1?

No. Based on "git checkout gcc-4_9_1-release"

Ditto for 4.9.0.

Hopefully the recommended patch can be applied to the 4.9 branch.

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

[joel at gcc dot gnu.org]

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

--- Comment #7 from Joel Sherrill  ---
(In reply to Yaakov Selkowitz from comment #6)
> (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?

r210683 was by Bernd Schmidt. I added him to this PR.

Bernd... how about applying that fix to the 4.9 branch please so we can close
this PR?

Thanks.

[Bug target/64542] ARM use of ARM instruction on Thumb-only target

[joel at gcc dot gnu.org]

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

Joel Sherrill  changed:

   What|Removed |Added

 Target||arm-rtems
 CC||sebastian.huber@embedded-br
   ||ains.de

--- Comment #2 from Joel Sherrill  ---
The attachment produces the error with this command line:

arm-rtems4.11-gcc -mthumb -march=armv6-m -c -O0 /tmp/arm-thumb-pr64542.c

[Bug target/64542] ARM use of ARM instruction on Thumb-only target

[joel at gcc dot gnu.org]

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

--- Comment #1 from Joel Sherrill  ---
Created attachment 34405
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=34405&action=edit
Processed output from RTEMS cpu.c which produces the error

Looking at the error message, I am not sure if this is invalid code generated
by GCC or conditionally selected by RTEMS. Filing this as a GCC PR and adding
RTEMS folks to get a ruling.

[Bug target/64542] New: ARM use of ARM instruction on Thumb-only target

[joel at gcc dot gnu.org]

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

Bug ID: 64542
   Summary: ARM use of ARM instruction on Thumb-only target
   Product: gcc
   Version: 4.9.3
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: joel at gcc dot gnu.org

$ arm-rtems4.11-gcc --version
arm-rtems4.11-gcc (GCC) 4.9.3 20150104 (prerelease)

arm-rtems4.11-gcc --pipe  -mthumb -march=armv6-m --pipe -DHAVE_CONFIG_H  
-I../../.. -I../../../../../../lib/include   -g -O2 -Wall
-Wimplicit-function-declaration -Wstrict-prototypes -Wnested-externs -MT
libscorecpu_a-cpu.o -MD -MP -MF .deps/libscorecpu_a-cpu.Tpo -c -o
libscorecpu_a-cpu.o `test -f 'cpu.c' || echo
'/users/joel/test-gcc/rtems/cpukit/score/cpu/arm/'`cpu.c
{standard input}: Assembler messages:
{standard input}:187: Error: selected processor does not support ARM opcodes
{standard input}:188: Error: attempt to use an ARM instruction on a Thumb-only
processor -- `mrs r3,cpsr'
{standard input}:189: Error: attempt to use an ARM instruction on a Thumb-only
processor -- `bic r3,#(1<<7)'
{standard input}:190: Error: attempt to use an ARM instruction on a Thumb-only
processor -- `orr r3,r0'
{standard input}:191: Error: attempt to use an ARM instruction on a Thumb-only
processor -- `msr cpsr,r3'
{standard input}:192: Error: attempt to use an ARM instruction on a Thumb-only
processor -- `add r3,pc,#1'
{standard input}:193: Error: attempt to use an ARM instruction on a Thumb-only
processor -- `bx r3'
{standard input}:218: Error: selected processor does not support ARM opcodes
{standard input}:219: Error: attempt to use an ARM instruction on a Thumb-only
processor -- `mrs r0,cpsr'
{standard input}:220: Error: attempt to use an ARM instruction on a Thumb-only
processor -- `and r0,#(1<<7)'
{standard input}:221: Error: attempt to use an ARM instruction on a Thumb-only
processor -- `add r3,pc,#1'
{standard input}:222: Error: attempt to use an ARM instruction on a Thumb-only
processor -- `bx r3'

[Bug target/37440] [4.8/4.9/5 Regression] GNAT Bug Box a-ngcefu.adb:397

[joel at gcc dot gnu.org]

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

Joel Sherrill  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |FIXED

--- Comment #17 from Joel Sherrill  ---
This is fixed on at least the 4.9 branch. I successfully built arm-rtems on
that.

Closing.

[Bug target/55192] bfin generates invalid assembly

[joel at gcc dot gnu.org]

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

Joel Sherrill  changed:

   What|Removed |Added

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

--- Comment #2 from Joel Sherrill  ---
I have an installed bfin-rtems 4.8.3 so I am going to assume this has been
fixed and close it.

[Bug target/64460] ARM ICE on valid code

[joel at gcc dot gnu.org]

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

--- Comment #1 from Joel Sherrill  ---
I ran a git bisect and it didn't narrow it down much but I hope this helps.
After the list of candidates, I am posting the full git bisect log.

Bisecting: 27 revisions left to test after this (roughly 5 steps)
[9d0ddb1d2f78d8f75d1663c450bfb79a434316a4] -fuse-caller-save - Enable for MIPS
running /users/joel/test-gcc/test.sh
There are only 'skip'ped commits left to test.
The first bad commit could be any of:
c72a450a93b2267ed467dccba674ffbf5cf422aa
e5d9420b3864e1bee10962f9962086f6b4424bd9
b652abf9ece0468d3c4f7e28592f514f92555192
ec0d1d643fa3b5a0a4bb6cdc6e5bad494b84cb7e
0bf90b7bfb72acfedbbe7af3e57e8cca7711434f
754158d9189fd020e9cde6a16c55d0340035f503
9ac9a75871aa0616c341048f1d5fd9ff9567c5c6
f1714fa0234e7465d69869735ac90a5f6959948d
53037a4d5be734e4ccc99db221676fa7cec7a806
db2d29508c505d3fa5beda75afca51e1496d97df
9227ba81ede93aa32eeb27f3f44210e028356d2e
aec1009feb0d0f8568501195a39d47cd86b1b479
30b4a99c52814ac12e95bfbc46855ce3b716ccb0
e9bf1d7eb0815c5e0afb4ceb374ff4222b5647eb
3a2864197399bc0847ad020c536efbdf5a4c9233
753a9c15373e367581810622175047bcd8609231
7ea5b9d97b7ea13ca759b1f7ca4f81a54d9d2698
dbe2840abe44f5b7f166547a633abc8fb4ca
09fb1a0adb85c0ced9b1cbf3e354ef3562a04aa9
7ce85a1fe8e0fa9b1ad9913ea82107c8c9a245f3
0d4c8cda4ac52f9d1b8aee46e85205e8fbaf312d
b35f062ed12db8b2aaa9f8485be506baf41b871f
2f6bdc73b914b478dabb7bdd0ad996a9e3567bda
fdfe65e2642826951d8050c4071a9bd00bb8bd14
82a1c922605243e401ea56d1b6288e771dacf248
8b433e5e84822c0bc35942950eb0ccc22dd5c7e6
540af08f9b8503433d9c2aa8d6c93f91bb2e6979
5692b79caf9e04153427ab7c0663509242a447be
1d9ca4f001f34692e768942c8a1295ab96783917
dcfff6f9996e8c7b2d323c806f17325c3bbc4f4e
32ce9a5c4208411361402f60e672c4830da0bc8f
75b115f41512fbbab79191059ba6a21bbd98a7c9
205c3b0ab6423dca05db534c7b7099f39eaee409
49523e2f0b01f0d5e58b16279115be1ab1393147
ac37483380d835da1ddb54a2cc8a7e75d12a
c20614820dd7acd77899a9a1ca52071356f05a3e
7f9463ecb4e1285d80975224aff4d71e7a64bc2e
fa64988a95dc95e538fe8d1b44b0fa91e8349966
487fea840105dbb0ff516b797e7d86bea82ef74a
61b1440327acebe3aebb7bca187df4abafbf3179
3a05a70c9631864b0c87824cf983ec0665eea501
de8b47de2e5ffc6bdbba5bf14024a843af5d9012
6b204f796d985a7983f9dd4b37098435814583b9
6f0c730b2b89c556b8846f8859226ffafca93350
587e70a69bd133c66c4d62fb7881753fd0133996
8753931abe4a279eb4b2c945fb8b5c14fc6774c9
0a8b68fa1ad04e3b56733adaa1926448fd96046d
1a344a3feb0312e6bf51cc666449168f28317780
949d4c6f91bc04cd8dafc7b80bb177d4f222a077
e00f93485cc99b84d47c0ef273eb2cf57fd4d73c
41a5159cce6cf6a14d783db438b5cd9e285f5e29
723c5269bcf4c0d7d459b69480602179c24ad73a
9d0ddb1d2f78d8f75d1663c450bfb79a434316a4
d2b854bc935a18434b59f77d8a6e329e4146a2ba
0abea32ce53397ae5f3f9db852687aede815f6d4

Full git bisect log
===
# bad: [71a1e0b3c4bc5434ba2acc6dc317d98395888eb1] 2015-01-02  Tobias Burnus 

# good: [92b64c52c7ab48215e9bbd6b578a1b2324d10497] 2014-01-31  Vladimir Makarov
 
git bisect start 'HEAD' '92b64c52c7ab48215e9bbd6b578a1b2324d10497'
# bad: [73dc3c0d503205db874ed94eb894b2c059031717] 2014-07-31  Arnaud Charlet 

git bisect bad 73dc3c0d503205db874ed94eb894b2c059031717
# good: [9fa165ac10cbcbd65142077a0ce0e60cec60d6ae] 2014-05-08  Richard Biener 

git bisect good 9fa165ac10cbcbd65142077a0ce0e60cec60d6ae
# bad: [72dc204f1926c75112c52304925b93265e4bec82] rs6000: Make cr5 allocatable
git bisect bad 72dc204f1926c75112c52304925b93265e4bec82
# skip: [30b4a99c52814ac12e95bfbc46855ce3b716ccb0] PR target/61044 *
doc/extend.texi (Local Labels): Note that label differences are not
supported for AVR.
git bisect skip 30b4a99c52814ac12e95bfbc46855ce3b716ccb0
# good: [b3096d437157c3ff9b01315e48eeab7e736bbac0] 2014-05-11  Paolo Carlini 

git bisect good b3096d437157c3ff9b01315e48eeab7e736bbac0
# skip: [6b204f796d985a7983f9dd4b37098435814583b9] runtime: disable split
stacks for runtime_printf function under Clang
git bisect skip 6b204f796d985a7983f9dd4b37098435814583b9
# bad: [a1032d45752b8ff864201ca3ad0b7e289ec4e904] runtime: Initialize variable
to avoid compiler warning.
git bisect bad a1032d45752b8ff864201ca3ad0b7e289ec4e904
# good: [18f0a24b677b550b7271d18959ba994a681af6a4] rs6000: New type attribute
value "halfmul"
git bisect good 18f0a24b677b550b7271d18959ba994a681af6a4
# bad: [a99cebb7bcfba6f574f062bcff80f1f9f67fd179] * config/ia64/ia64.c
(ia64_first_cycle_multipass_dfa_lookahead_guard): Check pending_data_specs
first.
git bisect bad a99cebb7bcfba6f574f062bcff80f1f9f67fd179
# skip: [aec1009feb0d0f8568501195a39d47cd86b1b479] 2014-05-25  Paolo Carlini 

git bisect skip aec1009feb0d0f8568501195a39d47cd86b1b479
# bad: [c98fd781d8c0752f75b4ae03f1fa652b17265c27] *
sanitizer_common/sanitizer_stacktrace.cc: Cherry pick upstream r209879.
* sanitizer_common/sanitizer_common.h: Likewise. * asan/asan_mapping.h:
Likewise. * asan/asan_linux.cc: Likewise. * tsan/tsan_mman.cc: Cherry
pick upstream r209744. * sanitizer_common/sanitizer_allocator.h: Likewise.

[Bug middle-end/36828] 4.3.1 when optimising for size generates much larger code than 4.0.x

[joel at gcc dot gnu.org]

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

--- Comment #4 from Joel Sherrill  ---
Based on the last comment, should this PR be closed. It has been five years.

[Bug target/54747] config/bfin/bfin.c:2721: possible missing break ?

[joel at gcc dot gnu.org]

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

Joel Sherrill  changed:

   What|Removed |Added

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

--- Comment #3 from Joel Sherrill  ---
Closing. Bernd was OK with the code and I don't see anyway to check this again.

[Bug target/51192] h8300 ICE building libgcov.c in int_mode_for_mode

[joel at gcc dot gnu.org]

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

Joel Sherrill  changed:

   What|Removed |Added

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

--- Comment #3 from Joel Sherrill  ---
Given a patch claiming to fix this was committed and this doesn't seem to be
happening anymore, I am closing this.

[Bug target/64461] bad assembly generated for Coldfire targets

[joel at gcc dot gnu.org]

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

--- Comment #5 from Joel Sherrill  ---
(In reply to Andreas Schwab from comment #4)
> The easiest fix is to disable the three trunc patterns for the coldfire.

This isn't my area of expertise. That's why I focused in on doing the git
bisect. Hoped it would help someone else.

If you provide a patch, I am more than happy to test it.

[Bug libffi/14554] libffi: ASM error

[joel at gcc dot gnu.org]

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

Joel Sherrill  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 CC||joel at gcc dot gnu.org
 Resolution|--- |WORKSFORME

--- Comment #1 from Joel Sherrill  ---
Ancient PR. Can't reproduce now. Closing.

[Bug ada/14538] *-rtems broken for gnat

[joel at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=14538
Bug 14538 depends on bug 14436, which changed state.

Bug 14436 Summary: ICE building libgcc.a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=14436

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |WONTFIX

[Bug target/14436] ICE building libgcc.a

[joel at gcc dot gnu.org]

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

Joel Sherrill  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 CC||joel at gcc dot gnu.org
 Resolution|--- |WONTFIX
  Known to fail||

--- Comment #14 from Joel Sherrill  ---
CPU long dead. Target removed from GCC long ago. Closing as won't fix.

[Bug target/46586] Can't compile libiberty for bfin-elf target.

[joel at gcc dot gnu.org]

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

Joel Sherrill  changed:

   What|Removed |Added

 Status|WAITING |RESOLVED
 Resolution|--- |WORKSFORME

--- Comment #2 from Joel Sherrill  ---
bfin-rtems and bfin-elf have not had this issue in ages. Closing for lack of
feedback.

[Bug target/53314] m32r-rtems does not provide crtinit.o and crtfini.o

[joel at gcc dot gnu.org]

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

Joel Sherrill  changed:

   What|Removed |Added

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

--- Comment #2 from Joel Sherrill  ---
I committed a fix for this in 2012 but this PR didn't get closed.

[Bug target/64461] bad assembly generated for Coldfire targets

[joel at gcc dot gnu.org]

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

--- Comment #2 from Joel Sherrill  ---
Multiple BSPs trigger this on various files which is not a surprise seeing as
it is generating an illegal memory to memory move. But in case it helps, this
is the list of CPU CFLAGS of BSPs which trigger it. I really believe this is a
breakage for all Coldfire variants though.

-mcpu=5206
-mcpu=5235
-mcpu=5272
-mcpu=528x 
-mcpu=52235
-mcpu=5307
-mcfv4e -Wa,-memac

[Bug target/47540] ARM THUMB crash with complex numbers

[joel at gcc dot gnu.org]

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

Joel Sherrill  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |FIXED

--- Comment #10 from Joel Sherrill  ---
Based on Sebastian's last comment, I am marking this as resolved/fixed.

[Bug target/64461] bad assembly generated for Coldfire targets

[joel at gcc dot gnu.org]

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

--- Comment #1 from Joel Sherrill  ---
Doing a git bisect showed this to be the commit that broke things. Clearly not
m68k specific but triggered it. 

commit 91ae0791cbebaac673e42e53c8b7f000241a0ca1
Author: dj 
Date:   Fri Aug 29 23:19:42 2014 +

* expr.c (convert_move): If the target has an explicit converter,
use it.


git-svn-id: svn+ssh://gcc.gnu.org/svn/gcc/trunk@214747
138bc75d-0d04-0410-961f-82ee72b054a4



The full git bisect log is:

# bad: [6c13ec429c328b934e9f67d5cd6f5ab55e17ce73] 2015-01-02  Tobias Burnus 

# good: [8edc9ee53be8854228d20569eee719a01a4001de] 2014-07-18  Bernd Edlinger 

git bisect start 'HEAD' '8edc9ee53be8854228d20569eee719a01a4001de'
# bad: [2dd9fd37811882a2c5cdcd0880c20e507256e10f] 2014-10-10  Yannick Moy 

git bisect bad 2dd9fd37811882a2c5cdcd0880c20e507256e10f
# good: [1d8a14f043cccdaeee0a0782560a398a902e15cf] Daily bump.
git bisect good 1d8a14f043cccdaeee0a0782560a398a902e15cf
# bad: [e3b7afcb34c7c4d4cd2f876e83fc2c90c2eeaae6] 2014-09-11  Segher
Boessenkool  
git bisect bad e3b7afcb34c7c4d4cd2f876e83fc2c90c2eeaae6
# bad: [67e0a76ed4c526001119ad5d78f49f2cb2f780a0] Fix typo.
git bisect bad 67e0a76ed4c526001119ad5d78f49f2cb2f780a0
# good: [ae799283c5ecc25191575fb5ec2bc16d97674437] Use rtx_expr_list for
expr_status.x_forced_labels
git bisect good ae799283c5ecc25191575fb5ec2bc16d97674437
# good: [8c409b9147aa9f2c536bffe1db93e30ac740d99c] AVX-512. Support
512-bit/masked interleave.
git bisect good 8c409b9147aa9f2c536bffe1db93e30ac740d99c
# good: [c1920e9db30af5043bdc942cfdf374b832687ee4] 2014-08-29  Richard Biener 

git bisect good c1920e9db30af5043bdc942cfdf374b832687ee4
# good: [6843b812545c8f94708624f6332ea3873cc952fc] PR 62215 Reinstate unlinking
old module file before renaming.
git bisect good 6843b812545c8f94708624f6332ea3873cc952fc
# bad: [1c0165c81ccfbe4fbadd96ac8b85c59a0002cab6] * config/pa/pa.c
(pa_assemble_integer): Don't add PLABEL relocation prefix to function
labels when generating fast indirect calls.
git bisect bad 1c0165c81ccfbe4fbadd96ac8b85c59a0002cab6
# bad: [4765975cb2f85d61e801d12562b39da2d1e25f2c] * cppbuiltin.c
(define_builtin_macros_for_type_sizes): Round pointer size up to a power of
two. * defaults.h (DWARF2_ADDR_SIZE): Round up. (POINTER_SIZE_UNITS): New,
rounded up value. * dwarf2asm.c (size_of_encoded_value): Use it.
(dw2_output_indirect_constant_1): Likewise. * expmed.c (init_expmed_one_conv):
We now know the sizes of partial int modes. * loop-iv.c
(iv_number_of_iterations): Use precision, not size. * optabs.c (expand_float):
Use precision, not size. (expand_fix): Likewise. * simplify-rtx
(simplify_unary_operation_1): Likewise. * tree-dfa.c (get_ref_base_and_extent):
Likewise. * varasm.c (assemble_addr_to_section): Round up pointer sizes.
(default_assemble_integer) Likewise. (dump_tm_clone_pairs): Likewise. *
dwarf2out.c (mem_loc_descriptor): Allow partial-int modes also. *
var-tracking.c (adjust_mems): Allow partial-int modes also.
(prepare_call_arguments): Likewise. * stor-layout.c (finalize_type_size):
Preserve precision. (layout_type): Use precision, not size.
git bisect bad 4765975cb2f85d61e801d12562b39da2d1e25f2c
# good: [9f30a5e055e777cdb28fd391c34ec8f3cd80a4d6] * lib/target-supports.exp
(check_effective_target_size32plus): Increase size to avoid false positives on
24-bit address spaces. * gcc.c-torture/compile/limits-stringlit.c: Skip if
msp430. * gcc.dg/lto/pr54709_1.c: Fix memcpy prototype. *
gcc.dg/torture/pta-ptrarith-3.c: Use __SIZE_TYPE__ instead of "int". *
gcc.dg/torture/pr36373-10.c: Use __SIZE_TYPE__ if present. *
gcc.dg/torture/pr57864.c: Use __SIZE_TYPE__. * gcc.dg/torture/pr26763-2.c: Use
__SIZE_TYPE__ instead of "int". * gcc.dg/tree-ssa/isolate-3.c: Use
__SIZE_TYPE__ instead of "long unsigned int". * gcc.dg/pr52549.c: Use
__SIZE_TYPE__ if present.
git bisect good 9f30a5e055e777cdb28fd391c34ec8f3cd80a4d6
# bad: [91ae0791cbebaac673e42e53c8b7f000241a0ca1] * expr.c (convert_move): If
the target has an explicit converter, use it.
git bisect bad 91ae0791cbebaac673e42e53c8b7f000241a0ca1
# first bad commit: [91ae0791cbebaac673e42e53c8b7f000241a0ca1] * expr.c
(convert_move): If the target has an explicit converter, use it.

[Bug target/64461] New: bad assembly generated for Coldfire targets

[joel at gcc dot gnu.org]

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

Bug ID: 64461
   Summary: bad assembly generated for Coldfire targets
   Product: gcc
   Version: 5.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: joel at gcc dot gnu.org

Created attachment 34368
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=34368&action=edit
Preprocessed RTEMS source which produces the error

Fails at -O1, -O2, and -Os. All RTEMS Coldfire BSPs appear to be failing to
build. I have not looked through all build logs yet to give a complete list of
CPU models impacted but all are Coldfires. For sure, 5235 and 5282 do this.

$ m68k-rtems4.11-gcc --versionm68k-rtems4.11-gcc (GCC) 5.0.0 20141230
(experimental)


$ m68k-rtems4.11-gcc -mcpu=5235 -Os -c coldfire.c 
/tmp/ccrrBmOJ.s: Assembler messages:
/tmp/ccrrBmOJ.s:82: Error: operands mismatch -- statement `move.b
3(%a5),3(%a1,%d0.l)' ignored
/tmp/ccrrBmOJ.s:977: Error: operands mismatch -- statement `move.b
-1(%fp),3(%a0,%d2.l)' ignored
/tmp/ccrrBmOJ.s:1055: Error: operands mismatch -- statement `move.b
-5(%fp),3(%a0,%d3.l)' ignored

[Bug target/64460] New: ARM ICE on valid code

[joel at gcc dot gnu.org]

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

Bug ID: 64460
   Summary: ARM ICE on valid code
   Product: gcc
   Version: 5.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: joel at gcc dot gnu.org

Created attachment 34367
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=34367&action=edit
Preprocessed RTEMS source which produces the error

Looks like an xscale specific issue at -O2. Doesn't crash at -O1. Worked on the
4.9 branch.


$ arm-rtems4.11-gcc --version
arm-rtems4.11-gcc (GCC) 5.0.0 20141230 (experimental)


$ arm-rtems4.11-gcc -mcpu=xscale -O2 -c gumstix.c 
../../../../../../rtems/c/src/../../cpukit/score/src/objectextendinformation.c:
In function '_Objects_Extend_information':
../../../../../../rtems/c/src/../../cpukit/score/src/objectextendinformation.c:278:1:
internal compiler error: Segmentation fault
 }
 ^
0x93b7af crash_signal
../../gcc/gcc/toplev.c:359
0x8e4940 reg_overlap_mentioned_p(rtx_def const*, rtx_def const*)
../../gcc/gcc/rtlanal.c:1522
0xc0c44c xscale_sched_adjust_cost
../../gcc/gcc/config/arm/arm.c:11497
0xc0c06b arm_adjust_cost
../../gcc/gcc/config/arm/arm.c:11947
0xe17ddf dep_cost_1(_dep*, unsigned int)
../../gcc/gcc/haifa-sched.c:1513
0xe19547 dep_cost(_dep*)
../../gcc/gcc/haifa-sched.c:1532
0xe19547 priority
../../gcc/gcc/haifa-sched.c:1683
0xe1963f set_priorities(rtx_insn*, rtx_insn*)
../../gcc/gcc/haifa-sched.c:6796
0x8ecdcc compute_priorities()
../../gcc/gcc/sched-rgn.c:2940
0x8ef9ed schedule_region
../../gcc/gcc/sched-rgn.c:3033
0x8ef9ed schedule_insns()
../../gcc/gcc/sched-rgn.c:3431
0x8f00f3 schedule_insns()
../../gcc/gcc/sched-rgn.c:3416
0x8f00f3 rest_of_handle_sched
../../gcc/gcc/sched-rgn.c:3635
0x8f00f3 execute
../../gcc/gcc/sched-rgn.c:3743
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See <http://gcc.gnu.org/bugs.html> for instructions.

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

[joel at gcc dot gnu.org]

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

--- Comment #4 from Joel Sherrill  ---
Since this happens on two target architectures, could someone look at it enough
to put it in the right component. It could be the same type of defect on two
different targets but it could also be a more generic problem.

Thanks.

[Bug target/64377] New: nios2 compile error in options-save.c

[joel at gcc dot gnu.org]

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

Bug ID: 64377
   Summary: nios2 compile error in options-save.c
   Product: gcc
   Version: 5.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: joel at gcc dot gnu.org

g++ -c   -g  -DIN_GCC  -DCROSS_DIRECTORY_STRUCTURE  -fno-exceptions -fno-rtti
-fasynchronous-unwind-tables -W -Wall -Wno-narrowing -Wwrite-strings
-Wcast-qual -Wmissing-format-attribute -Woverloaded-virtual -pedantic
-Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -fno-common 
-DHAVE_CONFIG_H -I. -I. -I../../gcc/gcc -I../../gcc/gcc/.
-I../../gcc/gcc/../include -I../../gcc/gcc/../libcpp/include 
-I../../gcc/gcc/../libdecnumber -I../../gcc/gcc/../libdecnumber/dpd
-I../libdecnumber -I../../gcc/gcc/../libbacktrace   -o options-save.o -MT
options-save.o -MMD -MP -MF ./.deps/options-save.TPo options-save.c
options-save.c: In function ‘void cl_target_option_stream_in(data_in*,
bitpack_d*, cl_target_option*)’:
options-save.c:1910:41: error: expected primary-expression before ‘enum’
   ptr->saved_custom_code_status[256] = (enum nios2_ccs_code
saved_custom_code_status[256]) bp_unpack_value (bp, 64);
 ^
options-save.c:1910:41: error: expected ‘)’ before ‘enum’
options-save.c:1911:40: error: expected primary-expression before ‘int’
   ptr->saved_custom_code_index[256] = (int saved_custom_code_index[256])
bp_unpack_value (bp, 64);
^
options-save.c:1911:40: error: expected ‘)’ before ‘int’
options-save.c:1912:49: error: expected primary-expression before ‘int’
   ptr->saved_fpu_custom_code[n2fpu_code_num] = (int
saved_fpu_custom_code[n2fpu_code_num]) bp_unpack_value (bp, 64);
 ^
options-save.c:1912:49: error: expected ‘)’ before ‘int’
make: *** [options-save.o] Error 1

[Bug target/64377] nios2 compile error in options-save.c

[joel at gcc dot gnu.org]

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

--- Comment #1 from Joel Sherrill  ---
Looking at the generated options-save.c, the first line of this method is
clearly incorrect in the cast on the RHS. It looks like a full declaration and
not a type. If anyone familiar with the magic in these files looked at it, I am
sure it is easy to fix.

/* Stream in target options  */
void
cl_target_option_stream_in (struct data_in *data_in ATTRIBUTE_UNUSED,
struct bitpack_d *bp ATTRIBUTE_UNUSED,
struct cl_target_option *ptr ATTRIBUTE_UNUSED)
{
  ptr->saved_custom_code_status[256] = (enum nios2_ccs_code
saved_custom_code_status[256]) bp_unpack_value (bp, 64);
  ptr->saved_custom_code_index[256] = (int saved_custom_code_index[256])
bp_unpack_value (bp, 64);
  ptr->saved_fpu_custom_code[n2fpu_code_num] = (int
saved_fpu_custom_code[n2fpu_code_num]) bp_unpack_value (bp, 64);
  ptr->x_target_flags = (int) bp_unpack_value (bp, 64);
}

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

[joel at gcc dot gnu.org]

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

Bug ID: 64375
   Summary: m32c ICE building newlib in calls.cL3638
   Product: gcc
   Version: 5.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: joel at gcc dot gnu.org

Created attachment 34312
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=34312&action=edit
Preprocessed fopencookie.c from newlib

xgcc (GCC) 5.0.0 20141221 (experimental)

This appears to be completely independent of optimization. It fails at O[012s]
if -mcpum32cm is included.

/users/joel/test-gcc/b-m32c-rtems4.11-gcc/./gcc/xgcc
-B/users/joel/test-gcc/b-m32c-rtems4.11-gcc/./gcc/ -c -Os -mcpu=m32cm f.c

/users/joel/test-gcc/b-m32c-rtems4.11-gcc/./gcc/xgcc
-B/users/joel/test-gcc/b-m32c-rtems4.11-gcc/./gcc/ -nostdinc
-B/users/joel/test-gcc/b-m32c-rtems4.11-gcc/m32c-rtems4.11/m32cm/newlib/
-isystem
/users/joel/test-gcc/b-m32c-rtems4.11-gcc/m32c-rtems4.11/m32cm/newlib/targ-include
-isystem /users/joel/test-gcc/gcc/newlib/libc/include
-B/users/joel/test-gcc/install-head/m32c-rtems4.11/bin/
-B/users/joel/test-gcc/install-head/m32c-rtems4.11/lib/ -isystem
/users/joel/test-gcc/install-head/m32c-rtems4.11/include -isystem
/users/joel/test-gcc/install-head/m32c-rtems4.11/sys-include  -mcpu=m32cm
-DPACKAGE_NAME=\"newlib\" -DPACKAGE_TARNAME=\"newlib\"
-DPACKAGE_VERSION=\"2.2.0\" -DPACKAGE_STRING=\"newlib\ 2.2.0\"
-DPACKAGE_BUGREPORT=\"\" -DPACKAGE_URL=\"\" -I.
-I../../../../../../gcc/newlib/libc/stdio -Os -DPREFER_SIZE_OVER_SPEED
-DSMALL_MEMORY -D_COMPILING_NEWLIB -DMALLOC_PROVIDED -DEXIT_PROVIDED
-DSIGNAL_PROVIDED -DREENTRANT_SYSCALLS_PROVIDED -DHAVE_NANOSLEEP -DHAVE_BLKSIZE
-DHAVE_FCNTL -DHAVE_ASSERT_FUNC -D_NO_GETLOGIN -D_NO_GETPWENT -D_NO_GETUT
-D_NO_GETPASS -D_NO_SIGSET -D_NO_WORDEXP -D_NO_POPEN -D_NO_POSIX_SPAWN
-fno-builtin  -g -O2 -c -o lib_a-fopencookie.o `test -f 'fopencookie.c' ||
echo '../../../../../../gcc/newlib/libc/stdio/'`fopencookie.c
../../../../../../gcc/newlib/libc/stdio/fopencookie.c: In function
'fopencookie':
../../../../../../gcc/newlib/libc/stdio/fopencookie.c:260:10: internal compiler
error: in expand_call, at calls.c:3638
   return _fopencookie_r (_REENT, cookie, mode, functions);
  ^
0x558859 expand_call(tree_node*, rtx_def*, int)
../../gcc/gcc/calls.c:3638
0x64ac10 expand_expr_real_1(tree_node*, rtx_def*, machine_mode,
expand_modifier, rtx_def**, bool)
../../gcc/gcc/expr.c:10474
0x656c2c store_expr_with_bounds(tree_node*, rtx_def*, int, bool, tree_node*)
../../gcc/gcc/expr.c:5368
0x65e23e expand_assignment(tree_node*, tree_node*, bool)
../../gcc/gcc/expr.c:5137
0x5655a6 expand_call_stmt
../../gcc/gcc/cfgexpand.c:2345
0x5655a6 expand_gimple_stmt_1
../../gcc/gcc/cfgexpand.c:3293
0x5655a6 expand_gimple_stmt
../../gcc/gcc/cfgexpand.c:3447
0x56b651 expand_gimple_tailcall
../../gcc/gcc/cfgexpand.c:3494
0x56b651 expand_gimple_basic_block
../../gcc/gcc/cfgexpand.c:5257
0x56cdce execute
../../gcc/gcc/cfgexpand.c:5889
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See <http://gcc.gnu.org/bugs.html> for instructions.
make: *** [lib_a-fopencookie.o] Error 1

[Bug tree-optimization/63817] New: ICE in verify_gimple_in_cfg tree-cfg.c:5039 (arm)

[joel at gcc dot gnu.org]

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

Bug ID: 63817
   Summary: ICE in verify_gimple_in_cfg tree-cfg.c:5039 (arm)
   Product: gcc
   Version: 5.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: joel at gcc dot gnu.org

Created attachment 33934
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=33934&action=edit
Preprocessed newlib ecvtbuf.c which produces the ICE

gcc, binutils-gdb, newlib head. gcc git hash
662274eebc1318f5a70fdb362da74f7913fbf1ba

Fails on both arm-eabi and arm-rtems at -O1 and -O2. Compiles at -O0 w/-mthumb
and at -O2 w/o -mthumb

Configure (from top config.log) is based on RTEMS standard build configuration

../gcc/configure --prefix=/users/joel/test-gcc/install-head
--bindir=/users/joel/test-gcc/install-head/bin
--exec_prefix=/users/joel/test-gcc/install-head
--includedir=/users/joel/test-gcc/install-head/include
--libdir=/users/joel/test-gcc/install-head/lib
--libexecdir=/users/joel/test-gcc/install-head/libexec
--mandir=/users/joel/test-gcc/install-head/share/man
--infodir=/users/joel/test-gcc/install-head/share/info
--datadir=/users/joel/test-gcc/install-head/share --target=arm-eabi
--disable-libstdcxx-pch --with-gnu-as --with-gnu-ld --verbose --with-newlib
--with-system-zlib --disable-nls --without-included-gettext
--disable-win32-registry --enable-version-specific-runtime-libs
--enable-newlib-iconv
--enable-newlib-iconv-encodings=big5,cp775,cp850,cp852,cp855,cp866,euc_jp,euc_kr,euc_tw,iso_8859_1,iso_8859_10,iso_8859_11,iso_8859_13,iso_8859_14,iso_8859_15,iso_8859_2,iso_8859_3,iso_8859_4,iso_8859_5,iso_8859_6,iso_8859_7,iso_8859_8,iso_8859_9,iso_ir_111,koi8_r,koi8_ru,koi8_u,koi8_uni,ucs_2,ucs_2_internal,ucs_2be,ucs_2le,ucs_4,ucs_4_internal,ucs_4be,ucs_4le,us_ascii,utf_16,utf_16be,utf_16le,utf_8,win_1250,win_1251,win_1252,win_1253,win_1254,win_1255,win_1256,win_1257,win_1258
--disable-lto --enable-newlib-io-c99-formats --enable-threads --disable-plugin
target_alias=arm-eabi --enable-languages=c,c++ --no-create --no-recursion

Shortened command and failure with attached preprocessed evctbuf.c from newlib:

/users/joel/test-gcc/b-arm-eabi-gcc/./gcc/xgcc
-B/users/joel/test-gcc/b-arm-eabi-gcc/./gcc/ -g -O2  -mthumb -c ecvtbuf.c 
In file included from ../../../../../../gcc/newlib/libc/stdlib/ecvtbuf.c:71:0:
/users/joel/test-gcc/gcc/newlib/libc/include/stdlib.h: In function 'fcvtbuf':
/users/joel/test-gcc/gcc/newlib/libc/include/stdlib.h:175:8: error: non-trivial
conversion at assignment
 char * _EXFUN(fcvtbuf,(double, int, int*, int*, char *));
^
sizetype
int
_64 = _37;
/users/joel/test-gcc/gcc/newlib/libc/include/stdlib.h:175:8: internal compiler
error: verify_gimple failed
0x9602d1 verify_gimple_in_cfg(function*, bool)
../../gcc/gcc/tree-cfg.c:5039
0x86fd06 execute_function_todo
../../gcc/gcc/passes.c:1868
0x870733 execute_todo
../../gcc/gcc/passes.c:1925
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See <http://gcc.gnu.org/bugs.html> for instructions.