On Fri, Nov 03, 2017 at 12:41:30PM -0600, Jeff Law wrote:
> On 11/03/2017 12:34 PM, Steve Kargl wrote:
> > One of the tests for gfortran has been XPASSing
> > on newer versions of FreeBSD. The testcase has
> > the line
> >
> > ! { dg-xfail-if "" { "*-*-freebsd*" } { "*" } { "" } }
> >
> > I kno
On 11/03/2017 12:34 PM, Steve Kargl wrote:
One of the tests for gfortran has been XPASSing
on newer versions of FreeBSD. The testcase has
the line
! { dg-xfail-if "" { "*-*-freebsd*" } { "*" } { "" } }
I know the tests passes on *-*-freebsd12.0. I should
pass on *-*-freebsd11.* and perhaps *
One of the tests for gfortran has been XPASSing
on newer versions of FreeBSD. The testcase has
the line
! { dg-xfail-if "" { "*-*-freebsd*" } { "*" } { "" } }
I know the tests passes on *-*-freebsd12.0. I should
pass on *-*-freebsd11.* and perhaps *-*-freebsd10.*.
I don't know if it passes on
On Mon, Feb 21, 2011 at 10:26 PM, Christian Grössler
wrote:
> On 19.02.11 23:01, Richard Guenther wrote:
>>
>> On Sat, Feb 19, 2011 at 10:53 PM, Christian Grössler
>> wrote:
>>>
>>> The failures come from the assembler which complains about the out of
>>> range
>>> shift counts.
>>>
>>> Should I
On 19.02.11 23:01, Richard Guenther wrote:
On Sat, Feb 19, 2011 at 10:53 PM, Christian Grössler
wrote:
The failures come from the assembler which complains about the out of range
shift counts.
Should I disable them or is there any reason unknown to me that these tests
make sense?
You need
On Sat, Feb 19, 2011 at 10:53 PM, Christian Grössler
wrote:
> Hi,
>
> I'm running the testsuite with a compiler for a private target.
>
> I get many failures because of shift counts out of range (too big or
> negative).
>
> Examples of failed tests:
>
> gcc.c-torture/compile/20020710-1.c
> gcc.c-t
Hi,
I'm running the testsuite with a compiler for a private target.
I get many failures because of shift counts out of range (too big or negative).
Examples of failed tests:
gcc.c-torture/compile/20020710-1.c
gcc.c-torture/compile/20021119-1.c
gcc.c-torture/compile/20021124-1.c
The failures c
> Yes. I tried it in the order your used, and the compile to check
> for inttypes.h tried to also compile c_kinds.c, which wasn't
> available from where the compile was done. In general it's best
> to check effective targets before adding files or options, unless
> the options are required for th
On Mon, 2007-08-06 at 13:16 -0700, Steve Ellcey wrote:
> > and the test runs on powerpc64-linux for both -m32 and -m64. Did
> > you have it in a different position? If so I'll try that and see
> > if I can figure out why it would be skipped. Also, which target
> > were you testing?
>
> I was te
> and the test runs on powerpc64-linux for both -m32 and -m64. Did
> you have it in a different position? If so I'll try that and see
> if I can figure out why it would be skipped. Also, which target
> were you testing?
I was testing on an IA64 Linux platform (Debian). I had this:
! { dg-do r
On Mon, 2007-08-06 at 10:28 -0700, Steve Ellcey wrote:
> I am running into a problem running the gfortran.dg/c_kind_params.f90
> and am wondering how to address it. This test has a C language
> component in gfortran.dg/c_kinds.c. This C file includes stdint.h and
> uses types like int32_t and int
I am running into a problem running the gfortran.dg/c_kind_params.f90
and am wondering how to address it. This test has a C language
component in gfortran.dg/c_kinds.c. This C file includes stdint.h and
uses types like int32_t and int64_t. On HPPA HP-UX platforms we don't
have a stdint.h header
12 matches
Mail list logo
