Re: [gofrontend-dev] Re: [PATCH 7/9] Gccgo port to s390[x] -- part I
On Thu, Oct 30, 2014 at 08:20:20AM -0700, Ian Taylor wrote:
/* { dg-skip-if not supported for target { ! s390*-*-* x86_64-*-* } } */
+/* { dg-skip-if not supported for target { ! lp64 } } */
Hm, but then the test will be skipped on s390 (31 bit) too where
it should work. The current solution is hopefully good enough for
now, but maybe boolean operators in the selector can help to
improve it; I'll check that, but give me some time for more
important issues first.
Ciao
Dominik ^_^ ^_^
--
Dominik Vogt
IBM Germany
Re: [gofrontend-dev] Re: [PATCH 7/9] Gccgo port to s390[x] -- part I
On Thu, Oct 30, 2014 at 07:51:45AM -0700, Ian Taylor wrote: On Thu, Oct 30, 2014 at 12:25 AM, Dominik Vogt v...@linux.vnet.ibm.com wrote: See attached patch. I don't mind skipping the test on other platforms, but xfail is not correct. When an xfail test passes, we get an XPASS error from the testsuite. We need dg-skip-if. I committed this patch. That is exactly the reason why I chose dg-xfail-if: To identify the targets where the test works out of the box, because I think there won't be many of them. But anyway, we can leave it as it is for the moment and eventually I'll get around cleaning that up. Ciao Dominik ^_^ ^_^ -- Dominik Vogt IBM Germany
Re: [gofrontend-dev] Re: [PATCH 7/9] Gccgo port to s390[x] -- part I
On Fri, Oct 31, 2014 at 2:11 AM, Dominik Vogt v...@linux.vnet.ibm.com wrote: On Thu, Oct 30, 2014 at 07:51:45AM -0700, Ian Taylor wrote: On Thu, Oct 30, 2014 at 12:25 AM, Dominik Vogt v...@linux.vnet.ibm.com wrote: See attached patch. I don't mind skipping the test on other platforms, but xfail is not correct. When an xfail test passes, we get an XPASS error from the testsuite. We need dg-skip-if. I committed this patch. That is exactly the reason why I chose dg-xfail-if: To identify the targets where the test works out of the box, because I think there won't be many of them. That would be fine if coupled with an immediate plan to test on all systems. What we don't want is an XPASS on some random system six months from now that forces some poor GCC developer who knows nothing at all about this code to figure out what is going on. But anyway, we can leave it as it is for the moment and eventually I'll get around cleaning that up. OK. Ian
Re: [gofrontend-dev] Re: [PATCH 7/9] Gccgo port to s390[x] -- part I
On Wed, Oct 29, 2014 at 10:16:40AM -0700, Ian Taylor wrote:
Thanks. Part of the problem is that the m68k max alignment is 16
bits, but the godump test expects it to be at least 64 bits. This is
BIGGEST_ALIGNMENT in config/m68k/m68k.h. Another part of the problem
seems to be that structs are sometimes aligned to 16 bits although
there is no obvious reason for that. I'm not sure where that is
coming from.
Hm, the test cases make assumptions about the Abi (structure
padding and alignment) that are true on x86, x64_64 and s390[x].
That may not be the case on other platforms and hence the tests
fail. Another candidate for test failures is the effect of
bitfields (named or anonymous) on structure layout.
We could disable the test on m68k or make it more accepting.
Since the point of some of the tests is to make sure that the Go
structure layout matches the C layout, making the tests accept
deviations seems to be rather pointless. It's possible to add
target selectors to all the scan-file lines, but that is a lot
of work and will likely become unmaintainable very soon when more
platforms need to be added. Personally I cannot provide fixed
tests for all the Abis either, so my suggestion is to xfail the
test on all targets except s390[x] and x86_64 and leave it to the
people who know the other platforms to decide whether the test
should work there or how the test could be modified to work.
See attached patch.
Ciao
Dominik ^_^ ^_^
--
Dominik Vogt
IBM Germany
From fc92faa8532e3ea0ac3b4c8b18eb6b0a3ee862dc Mon Sep 17 00:00:00 2001
From: Dominik Vogt v...@linux.vnet.ibm.com
Date: Thu, 30 Oct 2014 07:50:18 +0100
Subject: [PATCH] Xfail -fdump-go-spec tests for all platforms except s390[x]
and x86_64.
---
gcc/testsuite/gcc.misc-tests/godump-1.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/gcc/testsuite/gcc.misc-tests/godump-1.c b/gcc/testsuite/gcc.misc-tests/godump-1.c
index f339cc9..91b8637 100644
--- a/gcc/testsuite/gcc.misc-tests/godump-1.c
+++ b/gcc/testsuite/gcc.misc-tests/godump-1.c
@@ -2,6 +2,7 @@
/* { dg-options -c -fdump-go-spec=godump-1.out } */
/* { dg-do compile } */
+/* { dg-xfail-if not supported for target { ! s390*-*-* x86_64-*-* } } */
#include stdint.h
--
1.8.4.2
Re: [gofrontend-dev] Re: [PATCH 7/9] Gccgo port to s390[x] -- part I
On Thu, Oct 30, 2014 at 12:25 AM, Dominik Vogt v...@linux.vnet.ibm.com wrote:
On Wed, Oct 29, 2014 at 10:16:40AM -0700, Ian Taylor wrote:
Thanks. Part of the problem is that the m68k max alignment is 16
bits, but the godump test expects it to be at least 64 bits. This is
BIGGEST_ALIGNMENT in config/m68k/m68k.h. Another part of the problem
seems to be that structs are sometimes aligned to 16 bits although
there is no obvious reason for that. I'm not sure where that is
coming from.
Hm, the test cases make assumptions about the Abi (structure
padding and alignment) that are true on x86, x64_64 and s390[x].
That may not be the case on other platforms and hence the tests
fail. Another candidate for test failures is the effect of
bitfields (named or anonymous) on structure layout.
We could disable the test on m68k or make it more accepting.
Since the point of some of the tests is to make sure that the Go
structure layout matches the C layout, making the tests accept
deviations seems to be rather pointless. It's possible to add
target selectors to all the scan-file lines, but that is a lot
of work and will likely become unmaintainable very soon when more
platforms need to be added. Personally I cannot provide fixed
tests for all the Abis either, so my suggestion is to xfail the
test on all targets except s390[x] and x86_64 and leave it to the
people who know the other platforms to decide whether the test
should work there or how the test could be modified to work.
See attached patch.
I don't mind skipping the test on other platforms, but xfail is not
correct. When an xfail test passes, we get an XPASS error from the
testsuite. We need dg-skip-if. I committed this patch.
Ian
2014-10-30 Dominik Vogt v...@linux.vnet.ibm.com
* gcc.misc-tests/godump-1.c: Skip -fdump-go-spec tests for all
platforms except s390[x] and x86_64.
Index: gcc.misc-tests/godump-1.c
===
--- gcc.misc-tests/godump-1.c (revision 216840)
+++ gcc.misc-tests/godump-1.c (working copy)
@@ -2,6 +2,7 @@
/* { dg-options -c -fdump-go-spec=godump-1.out } */
/* { dg-do compile } */
+/* { dg-skip-if not supported for target { ! s390*-*-* x86_64-*-* } } */
#include stdint.h
Re: [gofrontend-dev] Re: [PATCH 7/9] Gccgo port to s390[x] -- part I
Hello!
I don't mind skipping the test on other platforms, but xfail is not
correct. When an xfail test passes, we get an XPASS error from the
testsuite. We need dg-skip-if. I committed this patch.
2014-10-30 Dominik Vogt v...@linux.vnet.ibm.com
* gcc.misc-tests/godump-1.c: Skip -fdump-go-spec tests for all
platforms except s390[x] and x86_64.
/* { dg-options -c -fdump-go-spec=godump-1.out } */
/* { dg-do compile } */
+/* { dg-skip-if not supported for target { ! s390*-*-* x86_64-*-* } } */
x86_64 also needs lp64, otherwise -m32 will defeat this condition.
Uros.
Re: [gofrontend-dev] Re: [PATCH 7/9] Gccgo port to s390[x] -- part I
On Thu, Oct 30, 2014 at 8:05 AM, Uros Bizjak ubiz...@gmail.com wrote:
/* { dg-options -c -fdump-go-spec=godump-1.out } */
/* { dg-do compile } */
+/* { dg-skip-if not supported for target { ! s390*-*-* x86_64-*-* } } */
x86_64 also needs lp64, otherwise -m32 will defeat this condition.
Thanks. I committed this patch.
Ian
2014-10-30 Ian Lance Taylor i...@google.com
* gcc.misc-tests/godump-1.c: Skip if ! lp64.
Index: gcc.misc-tests/godump-1.c
===
--- gcc.misc-tests/godump-1.c (revision 216936)
+++ gcc.misc-tests/godump-1.c (working copy)
@@ -3,6 +3,7 @@
/* { dg-options -c -fdump-go-spec=godump-1.out } */
/* { dg-do compile } */
/* { dg-skip-if not supported for target { ! s390*-*-* x86_64-*-* } } */
+/* { dg-skip-if not supported for target { ! lp64 } } */
#include stdint.h
Re: [gofrontend-dev] Re: [PATCH 7/9] Gccgo port to s390[x] -- part I
On Thu, 30 Oct 2014, Dominik Vogt wrote:
platforms need to be added. Personally I cannot provide fixed
tests for all the Abis either, so my suggestion is to xfail the
test on all targets except s390[x] and x86_64 and leave it to the
You should never do something in a test for x86_64 and not i?86, because
they cover exactly the same set of targets (if only LP64 x86 / x86_64 is
relevant, use { { i?86-*-* x86_64-*-* } lp64 }).
--
Joseph S. Myers
jos...@codesourcery.com
Re: [PATCH 7/9] Gccgo port to s390[x] -- part I
I'm getting these test failures on m68k-linux:
FAIL: gcc.misc-tests/godump-1.c scan-file (?n)^type _tsbf_anon_pad1 struct { c
uint[0-9]*; }$
FAIL: gcc.misc-tests/godump-1.c scan-file (?n)^type _tsbf_anon_pad5 struct { c
uint[0-9]*; }$
FAIL: gcc.misc-tests/godump-1.c scan-file (?n)^type _tsbf_pad16_1 struct {
Godump_0_pad \\[1\\]byte; c uint[0-9]*; Godump_1_align \\[0\\]int[0-9]*; }$
FAIL: gcc.misc-tests/godump-1.c scan-file (?n)^type _tsbf_pad16_2 struct {
Godump_0_pad \\[2\\]byte; c uint[0-9]*; Godump_1_align \\[0\\]int[0-9]*; }$
FAIL: gcc.misc-tests/godump-1.c scan-file (?n)^type _tsbf_pad32_1 struct {
Godump_0_pad \\[1\\]byte; c uint[0-9]*; Godump_1_align \\[0\\]int[0-9]*; }$
FAIL: gcc.misc-tests/godump-1.c scan-file (?n)^type _tsbf_pad32_2 struct {
Godump_0_pad \\[4\\]byte; c uint[0-9]*; Godump_1_align \\[0\\]int[0-9]*; }$
FAIL: gcc.misc-tests/godump-1.c scan-file (?n)^type _tsbf_pad64_1 struct {
Godump_0_pad \\[1\\]byte; c uint[0-9]*; Godump_1_align \\[0\\]int[0-9]*; }$
FAIL: gcc.misc-tests/godump-1.c scan-file (?n)^type _tsbf_pad64_2 struct {
Godump_0_pad \\[8\\]byte; c uint[0-9]*; Godump_1_align \\[0\\]int[0-9]*; }$
FAIL: gcc.misc-tests/godump-1.c scan-file (?n)^type _tsbf_18b struct {
Godump_0_pad \\[3\\]byte; }$
FAIL: gcc.misc-tests/godump-1.c scan-file (?n)^type _tsbf_gaps struct { bf1
uint[0-9]*; c uint[0-9]*; bf2 uint[0-9]*; Godump_0_pad \\[2\\]byte; s
uint[0-9]*; Godump_1_align \\[0\\]int[0-9]*; }$
FAIL: gcc.misc-tests/godump-1.c scan-file (?n)^type _tu1 struct { c
\\[8\\]byte; Godump_0_align \\[0\\]uint64; }$
FAIL: gcc.misc-tests/godump-1.c scan-file (?n)^type _tu2 struct { l
\\[8\\]byte; Godump_0_align \\[0\\]uint64; }$
FAIL: gcc.misc-tests/godump-1.c scan-file (?n)^type _tu3 struct { l
\\[24\\]byte; Godump_0_align \\[0\\]uint64; }$
FAIL: gcc.misc-tests/godump-1.c scan-file (?n)^type _tsu_anon struct { Godump_0
struct { c \\[8\\]byte; Godump_1_align \\[0\\]uint64; }; }$
FAIL: gcc.misc-tests/godump-1.c scan-file (?n)^type _tu_size struct { bf
\\[8\\]byte; Godump_0_align \\[0\\]uint64; }$
FAIL: gcc.misc-tests/godump-1.c scan-file (?n)^type _tu3_size struct { b
\\[8\\]byte; Godump_0_align \\[0\\]uint64; }$
FAIL: gcc.misc-tests/godump-1.c scan-file (?n)^var _sbf_anon_pad1 struct { c
uint[0-9]*; }$
FAIL: gcc.misc-tests/godump-1.c scan-file (?n)^var _sbf_anon_pad5 struct { c
uint[0-9]*; }$
FAIL: gcc.misc-tests/godump-1.c scan-file (?n)^var _sbf_pad16_1 struct {
Godump_0_pad \\[1\\]byte; c uint[0-9]*; Godump_1_align \\[0\\]int[0-9]*; }$
FAIL: gcc.misc-tests/godump-1.c scan-file (?n)^var _sbf_pad16_2 struct {
Godump_0_pad \\[2\\]byte; c uint[0-9]*; Godump_1_align \\[0\\]int[0-9]*; }$
FAIL: gcc.misc-tests/godump-1.c scan-file (?n)^var _sbf_pad32_1 struct {
Godump_0_pad \\[1\\]byte; c uint[0-9]*; Godump_1_align \\[0\\]int[0-9]*; }$
FAIL: gcc.misc-tests/godump-1.c scan-file (?n)^var _sbf_pad32_2 struct {
Godump_0_pad \\[4\\]byte; c uint[0-9]*; Godump_1_align \\[0\\]int[0-9]*; }$
FAIL: gcc.misc-tests/godump-1.c scan-file (?n)^var _sbf_pad64_1 struct {
Godump_0_pad \\[1\\]byte; c uint[0-9]*; Godump_1_align \\[0\\]int[0-9]*; }$
FAIL: gcc.misc-tests/godump-1.c scan-file (?n)^var _sbf_pad64_2 struct {
Godump_0_pad \\[8\\]byte; c uint[0-9]*; Godump_1_align \\[0\\]int[0-9]*; }$
FAIL: gcc.misc-tests/godump-1.c scan-file (?n)^var _sbf_18b struct {
Godump_0_pad \\[3\\]byte; }$
FAIL: gcc.misc-tests/godump-1.c scan-file (?n)^var _sbf_gaps struct { bf1
uint[0-9]*; c uint[0-9]*; bf2 uint[0-9]*; Godump_0_pad \\[2\\]byte; s
uint[0-9]*; Godump_1_align \\[0\\]int[0-9]*; }$
FAIL: gcc.misc-tests/godump-1.c scan-file (?n)^var _u1 struct { c \\[8\\]byte;
Godump_0_align \\[0\\]uint64; }$
FAIL: gcc.misc-tests/godump-1.c scan-file (?n)^var _u2 struct { l \\[8\\]byte;
Godump_0_align \\[0\\]uint64; }$
FAIL: gcc.misc-tests/godump-1.c scan-file (?n)^var _u3 struct { l \\[24\\]byte;
Godump_0_align \\[0\\]uint64; }$
FAIL: gcc.misc-tests/godump-1.c scan-file (?n)^var _su_anon struct { Godump_0
struct { c \\[8\\]byte; Godump_1_align \\[0\\]uint64; }; }$
FAIL: gcc.misc-tests/godump-1.c scan-file (?n)^var _u_size struct { bf
\\[8\\]byte; Godump_0_align \\[0\\]uint64; }$
FAIL: gcc.misc-tests/godump-1.c scan-file (?n)^var _u3_size struct { b
\\[8\\]byte; Godump_0_align \\[0\\]uint64; }$
Andreas.
--
Andreas Schwab, SUSE Labs, sch...@suse.de
GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE 1748 E4D4 88E3 0EEA B9D7
And now for something completely different.
Re: [gofrontend-dev] Re: [PATCH 7/9] Gccgo port to s390[x] -- part I
On Wed, Oct 29, 2014 at 9:38 AM, Andreas Schwab sch...@suse.de wrote: I'm getting these test failures on m68k-linux: Can you send the file BUILDDIR/gcc/testsuite/gcc/godump-1.out? Ian
Re: [gofrontend-dev] Re: [PATCH 7/9] Gccgo port to s390[x] -- part I
// unknowndefine __SIZE_TYPE__ unsigned int // unknowndefine __PTRDIFF_TYPE__ int // unknowndefine __WCHAR_TYPE__ long int // unknowndefine __WINT_TYPE__ unsigned int // unknowndefine __INTMAX_TYPE__ long long int // unknowndefine __UINTMAX_TYPE__ long long unsigned int // unknowndefine __CHAR16_TYPE__ short unsigned int // unknowndefine __CHAR32_TYPE__ unsigned int // unknowndefine __SIG_ATOMIC_TYPE__ int // unknowndefine __INT8_TYPE__ signed char // unknowndefine __INT16_TYPE__ short int // unknowndefine __INT32_TYPE__ int // unknowndefine __INT64_TYPE__ long long int // unknowndefine __UINT8_TYPE__ unsigned char // unknowndefine __UINT16_TYPE__ short unsigned int // unknowndefine __UINT32_TYPE__ unsigned int // unknowndefine __UINT64_TYPE__ long long unsigned int // unknowndefine __INT_LEAST8_TYPE__ signed char // unknowndefine __INT_LEAST16_TYPE__ short int // unknowndefine __INT_LEAST32_TYPE__ int // unknowndefine __INT_LEAST64_TYPE__ long long int // unknowndefine __UINT_LEAST8_TYPE__ unsigned char // unknowndefine __UINT_LEAST16_TYPE__ short unsigned int // unknowndefine __UINT_LEAST32_TYPE__ unsigned int // unknowndefine __UINT_LEAST64_TYPE__ long long unsigned int // unknowndefine __INT_FAST8_TYPE__ signed char // unknowndefine __INT_FAST16_TYPE__ int // unknowndefine __INT_FAST32_TYPE__ int // unknowndefine __INT_FAST64_TYPE__ long long int // unknowndefine __UINT_FAST8_TYPE__ unsigned char // unknowndefine __UINT_FAST16_TYPE__ unsigned int // unknowndefine __UINT_FAST32_TYPE__ unsigned int // unknowndefine __UINT_FAST64_TYPE__ long long unsigned int // unknowndefine __INTPTR_TYPE__ int // unknowndefine __UINTPTR_TYPE__ unsigned int // unknowndefine __DBL_MAX__ ((double)1.1) // unknowndefine __DBL_MIN__ ((double)1.1) // unknowndefine __DBL_EPSILON__ ((double)1.1) // unknowndefine __DBL_DENORM_MIN__ ((double)1.1) // unknowndefine __REGISTER_PREFIX__ % // unknowndefine __LEAF , __leaf__ // unknowndefine __LEAF_ATTR __attribute__ ((__leaf__)) // unknowndefine __THROW __attribute__ ((__nothrow__ __LEAF)) // unknowndefine __THROWNL __attribute__ ((__nothrow__)) // unknowndefine __ptr_t void * // unknowndefine __long_double_t long double // unknowndefine __fortify_function __extern_always_inline __attribute_artificial__ // unknowndefine __flexarr [] // unknowndefine __attribute_malloc__ __attribute__ ((__malloc__)) // unknowndefine __attribute_pure__ __attribute__ ((__pure__)) // unknowndefine __attribute_const__ __attribute__ ((__const__)) // unknowndefine __attribute_used__ __attribute__ ((__used__)) // unknowndefine __attribute_noinline__ __attribute__ ((__noinline__)) // unknowndefine __attribute_deprecated__ __attribute__ ((__deprecated__)) // unknowndefine __attribute_warn_unused_result__ __attribute__ ((__warn_unused_result__)) // unknowndefine __always_inline __inline __attribute__ ((__always_inline__)) // unknowndefine __attribute_artificial__ __attribute__ ((__artificial__)) // unknowndefine __extern_inline extern __inline __attribute__ ((__gnu_inline__)) // unknowndefine __extern_always_inline extern __always_inline __attribute__ ((__gnu_inline__)) // unknowndefine __restrict_arr __restrict // unknowndefine INT64_MIN (-__INT64_C(9223372036854775807)-1) // unknowndefine INT64_MAX (__INT64_C(9223372036854775807)) // unknowndefine UINT64_MAX (__UINT64_C(18446744073709551615)) // unknowndefine INT_LEAST64_MIN (-__INT64_C(9223372036854775807)-1) // unknowndefine INT_LEAST64_MAX (__INT64_C(9223372036854775807)) // unknowndefine UINT_LEAST64_MAX (__UINT64_C(18446744073709551615)) // unknowndefine INT_FAST64_MIN (-__INT64_C(9223372036854775807)-1) // unknowndefine INT_FAST64_MAX (__INT64_C(9223372036854775807)) // unknowndefine UINT_FAST64_MAX (__UINT64_C(18446744073709551615)) // unknowndefine INTMAX_MIN (-__INT64_C(9223372036854775807)-1) // unknowndefine INTMAX_MAX (__INT64_C(9223372036854775807)) // unknowndefine UINTMAX_MAX (__UINT64_C(18446744073709551615)) type _int8_t int8 type _int16_t int16 type _int32_t int32 type _int64_t int64 type _uint8_t uint8 type _uint16_t uint16 type _uint32_t uint32 type _uint64_t uint64 type _int_least8_t int8 type _int_least16_t int16 type _int_least32_t int32 type _int_least64_t int64 type _uint_least8_t uint8 type _uint_least16_t uint16 type _uint_least32_t uint32 type _uint_least64_t uint64 type _int_fast8_t int8 type _int_fast16_t int32 type _int_fast32_t int32 type _int_fast64_t int64 type _uint_fast8_t uint8 type _uint_fast16_t uint32 type _uint_fast32_t uint32 type _uint_fast64_t uint64 type _intptr_t int32 type _uintptr_t uint32 type _intmax_t int64 type _uintmax_t uint64 type _c_t int8 type _s_t int16 type _i_t int32 type _l_t int32 type _ll_t int64 type _uc_t uint8 type _us_t uint16 type _ui_t uint32 type _ul_t uint32 type _ull_t uint64 type _sc_t int8 type _ss_t int16 type _si_t int32 type _sl_t int32 type _sll_t int64 type _i8_t int8 type _i16_t int16 type _i32_t int32 type _i64_t int64 type _ui8_t uint8 type _iu16_t uint16 type _iu32_t uint32
Re: [gofrontend-dev] Re: [PATCH 7/9] Gccgo port to s390[x] -- part I
Thanks. Part of the problem is that the m68k max alignment is 16 bits, but the godump test expects it to be at least 64 bits. This is BIGGEST_ALIGNMENT in config/m68k/m68k.h. Another part of the problem seems to be that structs are sometimes aligned to 16 bits although there is no obvious reason for that. I'm not sure where that is coming from. I'll let Dominik decide how he wants to handle this. We could disable the test on m68k or make it more accepting. There may be problems on other architectures as well. Ian
