diff mbox

config/ sync with binutils vs. removing gcc targets.

Message ID 20161206224041.GW4829@bubble.grove.modra.org
State New
Headers show

Commit Message

Alan Modra Dec. 6, 2016, 10:40 p.m. UTC
I understand that config/ in the gcc repository is the master source
for binutils-gdb config/.  If that's the case then people removing
gcc support for particular targets need to be careful about their
config/ edits.  If a target is still supported in binutils, then
please don't rip out config/ support for the target.

I also didn't apply one of my binutils changes to gcc's config/,
so to sync with binutils I'd like to apply the following to gcc.
gcc doesn't use AC_PROG_LEX.

OK to apply?

	* elf.m4: Revert 2016-06-21 change.
	* picflag.m4: Likewise.  Revert 2016-04-30 change too.
	* override.m4 (AC_PROG_LEX): Import 2016-01-18 binutils fix
	for PR binutils/19481.

Comments

Oleg Endo Dec. 7, 2016, 11:46 a.m. UTC | #1
Hi,

Yeah, my SH5/SH64 removal procedures might have been a little too
radical, sorry about that.  However ...

On Wed, 2016-12-07 at 09:10 +1030, Alan Modra wrote:
> I understand that config/ in the gcc repository is the master source
> for binutils-gdb config/.  If that's the case then people removing
> gcc support for particular targets need to be careful about their
> config/ edits.  If a target is still supported in binutils, then
> please don't rip out config/ support for the target.

How exactly is this going to work when support for a configuration has
been removed from the compiler, but not from the configuration itself?
 That's just confusing for the user and doesn't make sense, I believe.

Cheers,
Oleg
Alan Modra Dec. 7, 2016, 12:44 p.m. UTC | #2
On Wed, Dec 07, 2016 at 08:46:32PM +0900, Oleg Endo wrote:
> Hi,
> 
> Yeah, my SH5/SH64 removal procedures might have been a little too
> radical, sorry about that.  However ...
> 
> On Wed, 2016-12-07 at 09:10 +1030, Alan Modra wrote:
> > I understand that config/ in the gcc repository is the master source
> > for binutils-gdb config/.  If that's the case then people removing
> > gcc support for particular targets need to be careful about their
> > config/ edits.  If a target is still supported in binutils, then
> > please don't rip out config/ support for the target.
> 
> How exactly is this going to work when support for a configuration has
> been removed from the compiler, but not from the configuration itself?
>  That's just confusing for the user and doesn't make sense, I believe.

The files in the config/ directory don't select which targets are
supported by gcc.  That selection is done in other files, like
config.gcc.  I don't see anything that would be confusing to users by
leaving sh5 patterns in say config/picflag.m4.

The config/* files are similar to config.guess and config.sub.  Just
as you do not touch config.guess and config.sub when removing a target
from gcc support, so you should not need to modify config/*.
Bernd Schmidt Dec. 7, 2016, 1:14 p.m. UTC | #3
On 12/06/2016 11:40 PM, Alan Modra wrote:
> I understand that config/ in the gcc repository is the master source
> for binutils-gdb config/.  If that's the case then people removing
> gcc support for particular targets need to be careful about their
> config/ edits.  If a target is still supported in binutils, then
> please don't rip out config/ support for the target.
>
> I also didn't apply one of my binutils changes to gcc's config/,
> so to sync with binutils I'd like to apply the following to gcc.
> gcc doesn't use AC_PROG_LEX.
>
> OK to apply?
>
> 	* elf.m4: Revert 2016-06-21 change.
> 	* picflag.m4: Likewise.  Revert 2016-04-30 change too.
> 	* override.m4 (AC_PROG_LEX): Import 2016-01-18 binutils fix
> 	for PR binutils/19481.

I think this is OK for now. Have you considered removing support for 
those dead targets from binutils?


Bernd
diff mbox

Patch

diff -urp ../gcc.git/config/elf.m4 config/elf.m4
--- ../gcc.git/config/elf.m4	2016-09-27 09:13:37.515759318 +0930
+++ config/elf.m4	2016-10-22 23:18:19.884410154 +1030
@@ -17,7 +17,7 @@  target_elf=no
 case $target in
   *-darwin* | *-aix* | *-cygwin* | *-mingw* | *-aout* | *-*coff* | \
   *-msdosdjgpp* | *-vms* | *-wince* | *-*-pe* | \
-  alpha*-dec-osf* | hppa[[12]]*-*-hpux* | \
+  alpha*-dec-osf* | *-interix* | hppa[[12]]*-*-hpux* | \
   nvptx-*-none)
     target_elf=no
     ;;
diff -urp ../gcc.git/config/picflag.m4 config/picflag.m4
--- ../gcc.git/config/picflag.m4	2016-09-27 09:13:37.515759318 +0930
+++ config/picflag.m4	2016-10-22 23:18:19.884410154 +1030
@@ -27,6 +27,10 @@  case "${$2}" in
 	;;
     i[[34567]]86-*-mingw* | x86_64-*-mingw*)
 	;;
+    i[[34567]]86-*-interix[[3-9]]*)
+	# Interix 3.x gcc -fpic/-fPIC options generate broken code.
+	# Instead, we relocate shared libraries at runtime.
+	;;
     i[[34567]]86-*-nto-qnx*)
 	# QNX uses GNU C++, but need to define -shared option too, otherwise
 	# it will coredump.
@@ -57,7 +61,8 @@  case "${$2}" in
 	$1=-fpic
 	;;
     # FIXME: Simplify to sh*-*-netbsd*?
-    sh-*-netbsdelf* | shl*-*-netbsdelf*)
+    sh-*-netbsdelf* | shl*-*-netbsdelf* | sh5-*-netbsd* | sh5l*-*-netbsd* | \
+      sh64-*-netbsd* | sh64l*-*-netbsd*)
 	$1=-fpic
 	;;
     # Default to -fPIC unless specified otherwise.
diff -urp ../gcc.git/config/override.m4 config/override.m4
--- ../gcc.git/config/override.m4	2014-11-24 14:48:32.327333882 +1030
+++ config/override.m4	2016-10-22 23:18:19.884410154 +1030
@@ -101,4 +101,16 @@  m4_define([_AC_CHECK_DECLS],
 
 ])
 
+dnl If flex/lex are not found, the top level configure sets LEX to
+dnl "/path_to/missing flex".  When AC_PROG_LEX tries to find the flex
+dnl output file, it calls $LEX to do so, but the current lightweight
+dnl "missing" won't create a file.  This results in an error.
+dnl Avoid calling the bulk of AC_PROG_LEX when $LEX is "missing".
+AC_DEFUN_ONCE([AC_PROG_LEX],
+[AC_CHECK_PROGS(LEX, flex lex, :)
+case "$LEX" in
+  :|*"missing "*) ;;
+  *) _AC_PROG_LEX_YYTEXT_DECL ;;
+esac])
+
 ])