Bug 29413 - -EB / -EL don't properly affect endian for Linux on MIPS
Summary: -EB / -EL don't properly affect endian for Linux on MIPS
Status: RESOLVED FIXED
Alias: None
Product: gcc
Classification: Unclassified
Component: target (show other bugs)
Version: 4.1.0
: P3 normal
Target Milestone: ---
Assignee: Not yet assigned to anyone
URL:
Keywords: wrong-code
: 23824 (view as bug list)
Depends on:
Blocks:
 
Reported: 2006-10-10 14:13 UTC by Ralf Baechle
Modified: 2006-10-17 07:10 UTC (History)
4 users (show)

See Also:
Host:
Target: mips*-linux*
Build:
Known to work: 4.2.0
Known to fail:
Last reconfirmed: 2006-10-12 07:29:04


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Ralf Baechle 2006-10-10 14:13:05 UTC
$ mips-linux-gcc -EL -dM -E -C -x c /dev/null | grep MIPSE
#define MIPSEB 1
#define __MIPSEB__ 1
#define _MIPSEB 1
#define __MIPSEB 1
$ mipsel-linux-gcc -EB -dM -E -C -x c /dev/null | grep MIPSE
#define __MIPSEL__ 1
#define MIPSEL 1
#define _MIPSEL 1
#define __MIPSEL 1
$ mips64el-linux-gcc -EB -dM -E -C -x c /dev/null | grep MIPSE
#define __MIPSEL__ 1
#define MIPSEL 1
#define _MIPSEL 1
#define __MIPSEL 1
$ mips64-linux-gcc -EL -dM -E -C -x c /dev/null | grep MIPSE
#define MIPSEB 1
#define __MIPSEB__ 1
#define _MIPSEB 1
#define __MIPSEB 1
$

Tested with gcc 4.1.0 but given the (incomplete) hacks the Linux/MIPS kernel has for this I would assume it is broken since a very, very long time.
Comment 1 Andrew Pinski 2006-10-12 06:58:35 UTC
      if (TARGET_BIG_ENDIAN)                                    \
        {                                                       \
          builtin_define_std ("MIPSEB");                        \
          builtin_define ("_MIPSEB");                           \
        }                                                       \
      else                                                      \
        {                                                       \
          builtin_define_std ("MIPSEL");                        \
          builtin_define ("_MIPSEL");                           \
        }     



%{G*} %{EB:-meb} %{EL:-mel} %{EB:%{EL:%emay not use both -EB and -EL}} \


meb
Target Report RejectNegative Mask(BIG_ENDIAN)
Use big-endian byte order

mel
Target Report RejectNegative InverseMask(BIG_ENDIAN, LITTLE_ENDIAN)
Use little-endian byte order

It looks to me this should work.
Comment 2 Andrew Pinski 2006-10-12 07:05:31 UTC
[pinskia@celery gcc]$ ./xgcc -B. -EL -dM -E -C -x c /dev/null | grep MIPSE
#define __MIPSEL__ 1
#define MIPSEL 1
#define _MIPSEL 1
#define __MIPSEL 1
[pinskia@celery gcc]$ ./xgcc -B. -EB -dM -E -C -x c /dev/null | grep MIPSE
#define MIPSEB 1
#define __MIPSEB__ 1
#define _MIPSEB 1
#define __MIPSEB 1
[pinskia@celery gcc]$ ./xgcc -B. -EB -dM -E -C -x c /dev/null -v
Using built-in specs.
Target: mipsisa32-elf
Configured with: ../configure --target=mipsisa32-elf : (reconfigured)
Thread model: single
gcc version 4.0.4 20061010 (prerelease)

Hmm, If this does not work then the order of config/linux.h and config/mips/mips.h are wrong and config/linux.h is being included first which defines CC1_SPEC and then config/mips/mips.h checks to see if CC1_SPEC is defined.
Comment 3 Andrew Pinski 2006-10-12 07:08:01 UTC
Yep that is what is happening:
mips64*-*-linux*)
        tm_file="dbxelf.h elfos.h svr4.h linux.h ${tm_file} mips/linux.h mips/linux64.h"
        .....
        ;;
mips*-*-linux*)                         # Linux MIPS, either endian.
        tm_file="dbxelf.h elfos.h svr4.h linux.h ${tm_file} mips/linux.h"
        ....
        esac
        ;;
Comment 4 Andrew Pinski 2006-10-12 07:27:19 UTC
Actually it was only caused recently for mips-linux (non64bit):
2002-08-02  Eric Christopher  <echristo@redhat.com>

	* config.gcc (mips*-*-linux*): Fix ordering of tm_file.
	* config/mips/mips.h (READONLY_DATA_SECTION_ASM_OP): Change
	#ifndef to #undef.
	(TARGET_MEM_FUNCTIONS): Define instead of define to 1.

mips64-linux-gnu was always wrong.

The correct order was in
http://gcc.gnu.org/ml/gcc-patches/2002-07/msg01743.html
But was wrong before that patch
And then was broken again with
http://gcc.gnu.org/ml/gcc-patches/2002-08/msg00204.html

The not having the define means we are also creating wrong code.
Comment 5 Andrew Pinski 2006-10-12 07:33:07 UTC
*** Bug 23824 has been marked as a duplicate of this bug. ***
Comment 6 Ralf Baechle 2006-10-12 13:33:24 UTC
> %{G*} %{EB:-meb} %{EL:-mel} %{EB:%{EL:%emay not use both -EB and -EL}} \

Shouldn't the combination of both -EB and -EL be legal that is later options override preceeding ones just like with other -ffoo / -fno-foo options?
Comment 7 Andrew Pinski 2006-10-12 14:11:28 UTC
(In reply to comment #6)
> > %{G*} %{EB:-meb} %{EL:-mel} %{EB:%{EL:%emay not use both -EB and -EL}} \
> 
> Shouldn't the combination of both -EB and -EL be legal that is later options
> override preceeding ones just like with other -ffoo / -fno-foo options?
That is not the problem, the problem is that CC1_SPEC does not contain the above but instead the one that is in config/linux.h.
Comment 8 rsandifo@gcc.gnu.org 2006-10-17 07:10:46 UTC
Fixed in trunk.  Because the patch is simple and fairly obvious,
I used the leeway given target maintainers to fix the bug for 4.2,
even though it isn't a regression.  However, because it's not a
regression, I don't think it's appropriate for release branches.

Richard
Comment 9 rsandifo@gcc.gnu.org 2006-10-19 15:45:58 UTC
Subject: Bug 29413

Author: rsandifo
Date: Thu Oct 19 15:45:46 2006
New Revision: 117886

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=117886
Log:
gcc/
	Backport from mainline:

	2006-10-17  Andrew Pinsiki  <pinskia@gmail.com>
		    Richard Sandiford  <richard@codesourcery.com>

	PR target/29413
	* config/mips/linux.h (SUBTARGET_CC1_SPEC): Override.
	* config/mips/mips.h (CC1_SPEC): Override any earlier definition.

Added:
    branches/csl/sourcerygxx-4_1/gcc/ChangeLog.csl
Modified:
    branches/csl/sourcerygxx-4_1/gcc/config/mips/linux.h
    branches/csl/sourcerygxx-4_1/gcc/config/mips/mips.h