| Message ID | e4aa84b83e00e1c571493217b4f1924f522c8ecf.1526938969.git.segher@kernel.crashing.org |
|---|---|
| State | New |
| Headers | show |
| Series | testsuite: Introduce be/le selectors | expand |
Hi Segher, > This patch creates "be" and "le" selectors, which can be used by all > architectures, similar to ilp32 and lp64. > > Is this okay for trunk? two issues: I don't find be and le particularly expressive. Maybe big-endian and little-endian? Besides, whatever we do, the new keywords need documenting in sourcebuild.texi. Rainer
On Mon, May 21, 2018 at 11:59:43PM +0200, Rainer Orth wrote: > Hi Segher, > > > This patch creates "be" and "le" selectors, which can be used by all > > architectures, similar to ilp32 and lp64. > > > > Is this okay for trunk? > > two issues: I don't find be and le particularly expressive. Maybe > big-endian and little-endian? But they will be used a _lot_, at least for rs6000, in places where space is it a premium. Like in scan-assembler-times and the like. > Besides, whatever we do, the new keywords need documenting in > sourcebuild.texi. Ah yes, I forgot. Thanks. Segher
On 05/21/2018 03:46 PM, Segher Boessenkool wrote: > This patch creates "be" and "le" selectors, which can be used by all > architectures, similar to ilp32 and lp64. > > Is this okay for trunk? > > > Segher > > > 2017-05-21 Segher Boessenkool <segher@kernel.crashing.org> > > gcc/testsuite/ > * lib/target-supports.exp (check_effective_target_be): New. > (check_effective_target_le): New. I think this is fine. "be" "le" are used all over the place in gcc and the kernel to denote big/little endian. jeff
On 22/05/18 22:21, Jeff Law wrote: > On 05/21/2018 03:46 PM, Segher Boessenkool wrote: >> This patch creates "be" and "le" selectors, which can be used by all >> architectures, similar to ilp32 and lp64. >> >> Is this okay for trunk? >> >> >> Segher >> >> >> 2017-05-21 Segher Boessenkool <segher@kernel.crashing.org> >> >> gcc/testsuite/ >> * lib/target-supports.exp (check_effective_target_be): New. >> (check_effective_target_le): New. > I think this is fine. "be" "le" are used all over the place in gcc and > the kernel to denote big/little endian. except when el and eb are used for perversity... :-) R. > > jeff >
On Tue, May 22, 2018 at 03:21:30PM -0600, Jeff Law wrote: > On 05/21/2018 03:46 PM, Segher Boessenkool wrote: > > This patch creates "be" and "le" selectors, which can be used by all > > architectures, similar to ilp32 and lp64. > > I think this is fine. "be" "le" are used all over the place in gcc and > the kernel to denote big/little endian. Thanks. This is what I checked in (to trunk): 2017-05-23 Segher Boessenkool <segher@kernel.crashing.org> * doc/sourcebuild.texi (Endianness): New subsubsection. gcc/testsuite/ * lib/target-supports.exp (check_effective_target_be): New. (check_effective_target_le): New. diff --git a/gcc/doc/sourcebuild.texi b/gcc/doc/sourcebuild.texi index dfb0578..596007d 100644 --- a/gcc/doc/sourcebuild.texi +++ b/gcc/doc/sourcebuild.texi @@ -1313,6 +1313,16 @@ By convention, keywords ending in @code{_nocache} can also include options specified for the particular test in an earlier @code{dg-options} or @code{dg-add-options} directive. +@subsubsection Endianness + +@table @code +@item be +Target uses big-endian memory order for multi-byte and multi-word data. + +@item le +Target uses little-endian memory order for multi-byte and multi-word data. +@end table + @subsubsection Data type sizes @table @code diff --git a/gcc/testsuite/lib/target-supports.exp b/gcc/testsuite/lib/target-supports.exp index aa1296e6..0a53d7b 100644 --- a/gcc/testsuite/lib/target-supports.exp +++ b/gcc/testsuite/lib/target-supports.exp @@ -2523,6 +2523,22 @@ proc check_effective_target_next_runtime { } { }] } +# Return 1 if we're generating code for big-endian memory order. + +proc check_effective_target_be { } { + return [check_no_compiler_messages be object { + int dummy[__BYTE_ORDER__ == __ORDER_BIG_ENDIAN__ ? 1 : -1]; + }] +} + +# Return 1 if we're generating code for little-endian memory order. + +proc check_effective_target_le { } { + return [check_no_compiler_messages le object { + int dummy[__BYTE_ORDER__ == __ORDER_LITTLE_ENDIAN__ ? 1 : -1]; + }] +} + # Return 1 if we're generating 32-bit code using default options, 0 # otherwise.
On Wed, May 23, 2018 at 10:07:18AM +0100, Richard Earnshaw (lists) wrote: > On 22/05/18 22:21, Jeff Law wrote: > > On 05/21/2018 03:46 PM, Segher Boessenkool wrote: > >> This patch creates "be" and "le" selectors, which can be used by all > >> architectures, similar to ilp32 and lp64. > >> 2017-05-21 Segher Boessenkool <segher@kernel.crashing.org> > >> > >> gcc/testsuite/ > >> * lib/target-supports.exp (check_effective_target_be): New. > >> (check_effective_target_le): New. > > I think this is fine. "be" "le" are used all over the place in gcc and > > the kernel to denote big/little endian. > > except when el and eb are used for perversity... :-) It should have been -BE and -EL, because that is what it means. That also avoids the -l/-L problem -le and -LE would have ;-) (Confusing? Yes, little-endian is confusing). Segher
On 24/05/18 18:28, Segher Boessenkool wrote: > On Wed, May 23, 2018 at 10:07:18AM +0100, Richard Earnshaw (lists) wrote: >> On 22/05/18 22:21, Jeff Law wrote: >>> On 05/21/2018 03:46 PM, Segher Boessenkool wrote: >>>> This patch creates "be" and "le" selectors, which can be used by all >>>> architectures, similar to ilp32 and lp64. > >>>> 2017-05-21 Segher Boessenkool <segher@kernel.crashing.org> >>>> >>>> gcc/testsuite/ >>>> * lib/target-supports.exp (check_effective_target_be): New. >>>> (check_effective_target_le): New. >>> I think this is fine. "be" "le" are used all over the place in gcc and >>> the kernel to denote big/little endian. >> >> except when el and eb are used for perversity... :-) > > It should have been -BE and -EL, because that is what it means. That > also avoids the -l/-L problem -le and -LE would have ;-) > > (Confusing? Yes, little-endian is confusing). I beg to differ. Big endian is the confusing one... :-) R. > > > Segher >
On Fri, May 25, 2018 at 10:30:58AM +0100, Richard Earnshaw (lists) wrote: > On 24/05/18 18:28, Segher Boessenkool wrote: > > On Wed, May 23, 2018 at 10:07:18AM +0100, Richard Earnshaw (lists) wrote: > >> On 22/05/18 22:21, Jeff Law wrote: > >>> On 05/21/2018 03:46 PM, Segher Boessenkool wrote: > >>>> This patch creates "be" and "le" selectors, which can be used by all > >>>> architectures, similar to ilp32 and lp64. > > > >>>> 2017-05-21 Segher Boessenkool <segher@kernel.crashing.org> > >>>> > >>>> gcc/testsuite/ > >>>> * lib/target-supports.exp (check_effective_target_be): New. > >>>> (check_effective_target_le): New. > >>> I think this is fine. "be" "le" are used all over the place in gcc and > >>> the kernel to denote big/little endian. > >> > >> except when el and eb are used for perversity... :-) > > > > It should have been -BE and -EL, because that is what it means. That > > also avoids the -l/-L problem -le and -LE would have ;-) > > > > (Confusing? Yes, little-endian is confusing). > > I beg to differ. Big endian is the confusing one... :-) I thought you said -EL is perverse. Maybe I misunderstood! (Sorry sorry). Segher
Hi Jeff, Is it ok to backport this patch to gcc 8? There are other backports of test programs that would like to use the new selector options. Thanks. On 5/23/18 12:31 PM, Segher Boessenkool wrote: > On Tue, May 22, 2018 at 03:21:30PM -0600, Jeff Law wrote: >> On 05/21/2018 03:46 PM, Segher Boessenkool wrote: >>> This patch creates "be" and "le" selectors, which can be used by all >>> architectures, similar to ilp32 and lp64. >> >> I think this is fine. "be" "le" are used all over the place in gcc and >> the kernel to denote big/little endian. > > Thanks. This is what I checked in (to trunk): > > > 2017-05-23 Segher Boessenkool <segher@kernel.crashing.org> > > * doc/sourcebuild.texi (Endianness): New subsubsection. > > gcc/testsuite/ > * lib/target-supports.exp (check_effective_target_be): New. > (check_effective_target_le): New. > > > diff --git a/gcc/doc/sourcebuild.texi b/gcc/doc/sourcebuild.texi > index dfb0578..596007d 100644 > --- a/gcc/doc/sourcebuild.texi > +++ b/gcc/doc/sourcebuild.texi > @@ -1313,6 +1313,16 @@ By convention, keywords ending in @code{_nocache} can also include options > specified for the particular test in an earlier @code{dg-options} or > @code{dg-add-options} directive. > > +@subsubsection Endianness > + > +@table @code > +@item be > +Target uses big-endian memory order for multi-byte and multi-word data. > + > +@item le > +Target uses little-endian memory order for multi-byte and multi-word data. > +@end table > + > @subsubsection Data type sizes > > @table @code > diff --git a/gcc/testsuite/lib/target-supports.exp b/gcc/testsuite/lib/target-supports.exp > index aa1296e6..0a53d7b 100644 > --- a/gcc/testsuite/lib/target-supports.exp > +++ b/gcc/testsuite/lib/target-supports.exp > @@ -2523,6 +2523,22 @@ proc check_effective_target_next_runtime { } { > }] > } > > +# Return 1 if we're generating code for big-endian memory order. > + > +proc check_effective_target_be { } { > + return [check_no_compiler_messages be object { > + int dummy[__BYTE_ORDER__ == __ORDER_BIG_ENDIAN__ ? 1 : -1]; > + }] > +} > + > +# Return 1 if we're generating code for little-endian memory order. > + > +proc check_effective_target_le { } { > + return [check_no_compiler_messages le object { > + int dummy[__BYTE_ORDER__ == __ORDER_LITTLE_ENDIAN__ ? 1 : -1]; > + }] > +} > + > # Return 1 if we're generating 32-bit code using default options, 0 > # otherwise. >
On 06/27/2018 10:01 AM, Kelvin Nilsen wrote: > Hi Jeff, > > Is it ok to backport this patch to gcc 8? There are other backports of test programs that would like to use the new selector options. Sure. jeff
diff --git a/gcc/testsuite/lib/target-supports.exp b/gcc/testsuite/lib/target-supports.exp index cfc22a2..3b9460d 100644 --- a/gcc/testsuite/lib/target-supports.exp +++ b/gcc/testsuite/lib/target-supports.exp @@ -2641,6 +2641,22 @@ proc check_effective_target_long_neq_int { } { }] } +# Return 1 if we're generating big-endian code. + +proc check_effective_target_be { } { + return [check_no_compiler_messages be object { + int dummy[__BYTE_ORDER__ == __ORDER_BIG_ENDIAN__ ? 1 : -1]; + }] +} + +# Return 1 if we're generating little-endian code. + +proc check_effective_target_le { } { + return [check_no_compiler_messages le object { + int dummy[__BYTE_ORDER__ == __ORDER_LITTLE_ENDIAN__ ? 1 : -1]; + }] +} + # Return 1 if the target supports long double larger than double, # 0 otherwise.