Bug 10540 - [3.3 regression] mips-sgi-irix6.5 testsuite failure in gcc.c-torture/execute/20020227-1.c with checking enabled
Summary: [3.3 regression] mips-sgi-irix6.5 testsuite failure in gcc.c-torture/execute/...
Status: RESOLVED DUPLICATE of bug 6221
Alias: None
Product: gcc
Classification: Unclassified
Component: middle-end (show other bugs)
Version: 3.3
: P3 normal
Target Milestone: 3.3.2
Assignee: Not yet assigned to anyone
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2003-04-29 14:36 UTC by Kaveh Ghazi
Modified: 2003-07-28 21:08 UTC (History)
1 user (show)

See Also:
Host:
Target:
Build:
Known to work:
Known to fail:
Last reconfirmed: 2003-06-09 05:49:57


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Kaveh Ghazi 2003-04-29 14:36:02 UTC
With the 3.3 branch, I'm getting new testsuite failures with checking enabled on mips-sgi-irix6.5 in gcc.c-torture/execute/20020227-1.c.  The errors did NOT happen in a 4/23 version:
http://gcc.gnu.org/ml/gcc-testresults/2003-04/msg01502.html
But they DO happen in a 4/26 version:
http://gcc.gnu.org/ml/gcc-testresults/2003-04/msg01636.html

I'll try and narrow it down a bit more.

Release:
gcc version 3.3 20030429 (prerelease)

Environment:
mips-sgi-irix6.5

How-To-Repeat:
Configure with --enable-checking and target mips-sgi-irix6.5 and compile 20020227-1.i with:

cc1 -fpreprocessed 20020227-1.i -quiet -dumpbase 20020227-1.c -auxbase 20020227-1 -version -o 20020227-1.s


# 1 "20020227-1.c"
# 1 "<built-in>"
# 1 "<command line>"
# 1 "20020227-1.c"




typedef __complex__ float cf;
struct x { char c; cf f; } __attribute__ ((__packed__));
extern void f2 (struct x*);
extern void f1 (void);
int
main (void)
{
  f1 ();
  exit (0);
}

void
f1 (void)
{
  struct x s;
  s.f = 1;
  s.c = 42;
  f2 (&s);
}

void
f2 (struct x *y)
{
  if (y->f != 1 || y->c != 42)
    abort ();
}
Comment 1 Dara Hazeghi 2003-05-26 23:57:42 UTC
Hello,

with gcc 3.2.3, 3.3 branch and mainline, the testcase builds fine for me with a mips-sgi-irix6.5 
cross-compiler, though I don't have checking enabled. Does this problem still occur for you? Does 
it only occur when checking is enabled? Thanks,

Dara
Comment 2 Andrew Pinski 2003-05-27 13:25:38 UTC
See Dara's question (comment 1).
Comment 3 Kaveh Ghazi 2003-06-09 05:47:19 UTC
Yes checking is required to trigger the bug and it still occurs, see:
http://gcc.gnu.org/ml/gcc-testresults/2003-06/msg00483.html
Comment 4 Mark Mitchell 2003-07-17 20:36:24 UTC
The crash occurs on this code in subreg_hard_regno:

#ifdef ENABLE_CHECKING
  if (!subreg_offset_representable_p (REGNO (reg), GET_MODE (reg),
			  	      SUBREG_BYTE (x), mode))
    abort ();
#endif

The expression in question is:

  (subreg:SF (reg:DI 3 v1) 0)

Is that supposed to be valid?
Comment 5 Mark Mitchell 2003-07-23 23:05:03 UTC
This crash only occurs with --enable-checking, so I've postponed the bug until
GCC 3.3.2.
Comment 6 Mark Mitchell 2003-07-28 21:08:40 UTC
According to PR 6221, this is a generic failure on 64-bit targets.

It used to build, but do the wrong thing at runtime, so the fact that it now
aborts at compile time is in some ways an improvement.

*** This bug has been marked as a duplicate of 6221 ***