public inbox for gcc-prs@sourceware.org
help / color / mirror / Atom feed
* Re: optimization/10315: [3.2/3.3 regression] [powerpc] ICE: in extract_insn, at recog.c:2175
@ 2003-04-25 14:06 David Edelsohn
0 siblings, 0 replies; 8+ messages in thread
From: David Edelsohn @ 2003-04-25 14:06 UTC (permalink / raw)
To: nobody; +Cc: gcc-prs
The following reply was made to PR optimization/10315; it has been noted by GNATS.
From: David Edelsohn <dje@watson.ibm.com>
To: Richard Henderson <rth@redhat.com>, Geoff Keating <geoffk@geoffk.org>,
s.bosscher@student.tudelft.nl, gcc-gnats@gcc.gnu.org, gcc-bugs@gcc.gnu.org,
adconrad@0c3.net, 186299@bugs.debian.org, gcc-patches@gcc.gnu.org
Cc:
Subject: Re: optimization/10315: [3.2/3.3 regression] [powerpc] ICE: in extract_insn, at recog.c:2175
Date: Fri, 25 Apr 2003 09:57:14 -0400
>>>>> Richard Henderson writes:
> The attached patch (which has only been cross-tested vs the
> pr test case) would appear to do the right thing. Would someone
> please give this proper bootstrap testing?
This patch bootstraps and does not introduce any new regressions
on AIX. Looks good to me.
Thanks, David
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: optimization/10315: [3.2/3.3 regression] [powerpc] ICE: in extract_insn, at recog.c:2175
@ 2003-04-24 4:56 Richard Henderson
0 siblings, 0 replies; 8+ messages in thread
From: Richard Henderson @ 2003-04-24 4:56 UTC (permalink / raw)
To: nobody; +Cc: gcc-prs
The following reply was made to PR optimization/10315; it has been noted by GNATS.
From: Richard Henderson <rth@redhat.com>
To: David Edelsohn <dje@watson.ibm.com>, Geoff Keating <geoffk@geoffk.org>,
s.bosscher@student.tudelft.nl, gcc-gnats@gcc.gnu.org, gcc-bugs@gcc.gnu.org,
adconrad@0c3.net, 186299@bugs.debian.org, gcc-patches@gcc.gnu.org
Cc:
Subject: Re: optimization/10315: [3.2/3.3 regression] [powerpc] ICE: in extract_insn, at recog.c:2175
Date: Wed, 23 Apr 2003 21:51:18 -0700
On Wed, Apr 23, 2003 at 03:50:43PM -0700, Richard Henderson wrote:
> This is the same as PR8300, which I am looking at today.
Well, not quite the same. There are a couple of bugs here, any one
of which will fix the crash.
First, rs6000_emit_move decided that any time it was called with a
non-general_operand input, that it must be reload doing something
weird. The attached patch (which has only been cross-tested vs the
pr test case) would appear to do the right thing. Would someone
please give this proper bootstrap testing?
Second, gen_move_insn doesn't have nearly the sort of checks
performed by emit_move_insn. This is certainly a bug. IMO
gen_move_insn should be implemented as
rtx gen_move_insn (dst, src)
{
start_sequence ();
emit_move_insn (dst, src);
ret = get_insns ();
end_sequence ();
return ret;
}
However, I'm sure this will break something, though I don't
know what. Certainly we should explore something like this
for mainline, but ...
r~
* config/rs6000/rs6000.c (rs6000_emit_move): Only elide proper
checks during reload; use validize_mem instead of adjust_address.
Index: config/rs6000/rs6000.c
===================================================================
RCS file: /cvs/gcc/gcc/gcc/config/rs6000/rs6000.c,v
retrieving revision 1.403.2.6
diff -c -p -d -r1.403.2.6 rs6000.c
*** config/rs6000/rs6000.c 1 Apr 2003 10:14:13 -0000 1.403.2.6
--- config/rs6000/rs6000.c 24 Apr 2003 04:42:11 -0000
*************** rs6000_emit_move (dest, source, mode)
*** 2640,2655 ****
}
}
! /* Handle the case where reload calls us with an invalid address;
! and the case of CONSTANT_P_RTX. */
! if (!ALTIVEC_VECTOR_MODE (mode)
&& (! general_operand (operands[1], mode)
! || ! nonimmediate_operand (operands[0], mode)
! || GET_CODE (operands[1]) == CONSTANT_P_RTX))
! {
! emit_insn (gen_rtx_SET (VOIDmode, operands[0], operands[1]));
! return;
! }
/* FIXME: In the long term, this switch statement should go away
and be replaced by a sequence of tests based on things like
--- 2640,2654 ----
}
}
! /* Handle the case where reload calls us with an invalid address. */
! if (reload_in_progress && mode == Pmode
&& (! general_operand (operands[1], mode)
! || ! nonimmediate_operand (operands[0], mode)))
! goto emit_set;
!
! /* Handle the case of CONSTANT_P_RTX. */
! if (GET_CODE (operands[1]) == CONSTANT_P_RTX)
! goto emit_set;
/* FIXME: In the long term, this switch statement should go away
and be replaced by a sequence of tests based on things like
*************** rs6000_emit_move (dest, source, mode)
*** 2864,2876 ****
/* Above, we may have called force_const_mem which may have returned
an invalid address. If we can, fix this up; otherwise, reload will
have to deal with it. */
! if (GET_CODE (operands[1]) == MEM
! && ! memory_address_p (mode, XEXP (operands[1], 0))
! && ! reload_in_progress)
! operands[1] = adjust_address (operands[1], mode, 0);
emit_insn (gen_rtx_SET (VOIDmode, operands[0], operands[1]));
- return;
}
\f
/* Initialize a variable CUM of type CUMULATIVE_ARGS
--- 2863,2873 ----
/* Above, we may have called force_const_mem which may have returned
an invalid address. If we can, fix this up; otherwise, reload will
have to deal with it. */
! if (GET_CODE (operands[1]) == MEM && ! reload_in_progress)
! operands[1] = validize_mem (operands[1]);
+ emit_set:
emit_insn (gen_rtx_SET (VOIDmode, operands[0], operands[1]));
}
\f
/* Initialize a variable CUM of type CUMULATIVE_ARGS
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: optimization/10315: [3.2/3.3 regression] [powerpc] ICE: in extract_insn, at recog.c:2175
@ 2003-04-23 22:56 Richard Henderson
0 siblings, 0 replies; 8+ messages in thread
From: Richard Henderson @ 2003-04-23 22:56 UTC (permalink / raw)
To: nobody; +Cc: gcc-prs
The following reply was made to PR optimization/10315; it has been noted by GNATS.
From: Richard Henderson <rth@redhat.com>
To: David Edelsohn <dje@watson.ibm.com>
Cc: Geoff Keating <geoffk@geoffk.org>, s.bosscher@student.tudelft.nl,
gcc-gnats@gcc.gnu.org, gcc-bugs@gcc.gnu.org, adconrad@0c3.net,
186299@bugs.debian.org, gcc-patches@gcc.gnu.org
Subject: Re: optimization/10315: [3.2/3.3 regression] [powerpc] ICE: in extract_insn, at recog.c:2175
Date: Wed, 23 Apr 2003 15:50:43 -0700
On Wed, Apr 23, 2003 at 04:09:59PM -0400, David Edelsohn wrote:
> GCC probably should not fall on its face when presented with this
> type of error, but I am not sure who sure ensure a valid insn.
> gen_move_insn() should not be called that late?
This is the same as PR8300, which I am looking at today.
r~
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: optimization/10315: [3.2/3.3 regression] [powerpc] ICE: in extract_insn, at recog.c:2175
@ 2003-04-23 20:16 David Edelsohn
0 siblings, 0 replies; 8+ messages in thread
From: David Edelsohn @ 2003-04-23 20:16 UTC (permalink / raw)
To: nobody; +Cc: gcc-prs
The following reply was made to PR optimization/10315; it has been noted by GNATS.
From: David Edelsohn <dje@watson.ibm.com>
To: Geoff Keating <geoffk@geoffk.org>
Cc: s.bosscher@student.tudelft.nl, gcc-gnats@gcc.gnu.org, gcc-bugs@gcc.gnu.org,
adconrad@0c3.net, 186299@bugs.debian.org, gcc-patches@gcc.gnu.org
Subject: Re: optimization/10315: [3.2/3.3 regression] [powerpc] ICE: in extract_insn, at recog.c:2175
Date: Wed, 23 Apr 2003 16:09:59 -0400
>>>>> Geoff Keating writes:
> In that case, the RTL should never have been generated...
The original C code appears to be buggy and GCC is not handling
the error very gracefully. The C code is:
case 'f': {
float v;
memcpy(&v, &input[inputpos], sizeof(float));
add_assoc_double(return_value, n, (double)v);
break;
}
case 'd': {
double v;
memcpy(&v, &input[inputpos], sizeof(float));
add_assoc_double(return_value, n, v);
break;
}
Notice case 'd' memcpy uses sizeof(float), not sizeof(double). GCC
inlines the memcpy(), but only half of "v" is set.
flow.c:initialize_uninitialized_subregs() simply jams in a zero in the
entry block for the function:
insn = gen_move_insn (param.retval,
CONST0_RTX (GET_MODE (param.retval)));
If I change sizeof(float) to sizeof(double) for case 'd', the
function compiles without error. The sizeof(float) seems to be a typo, so
my first suggestion is fix the source code.
GCC probably should not fall on its face when presented with this
type of error, but I am not sure who sure ensure a valid insn.
gen_move_insn() should not be called that late?
David
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: optimization/10315: [3.2/3.3 regression] [powerpc] ICE: in extract_insn, at recog.c:2175
@ 2003-04-23 18:26 Geoff Keating
0 siblings, 0 replies; 8+ messages in thread
From: Geoff Keating @ 2003-04-23 18:26 UTC (permalink / raw)
To: nobody; +Cc: gcc-prs
The following reply was made to PR optimization/10315; it has been noted by GNATS.
From: Geoff Keating <geoffk@geoffk.org>
To: dje@watson.ibm.com
Cc: s.bosscher@student.tudelft.nl, gcc-gnats@gcc.gnu.org, gcc-bugs@gcc.gnu.org,
adconrad@0c3.net, 186299@bugs.debian.org
Subject: Re: optimization/10315: [3.2/3.3 regression] [powerpc] ICE: in extract_insn, at recog.c:2175
Date: Wed, 23 Apr 2003 11:14:26 -0700
> Cc: Steven Bosscher <s.bosscher@student.tudelft.nl>, gcc-gnats@gcc.gnu.org,
> gcc-bugs@gcc.gnu.org, adconrad@0c3.net, 186299@bugs.debian.org
> Date: Tue, 22 Apr 2003 23:14:37 -0400
> From: David Edelsohn <dje@watson.ibm.com>
> X-OriginalArrivalTime: 23 Apr 2003 03:14:43.0793 (UTC) FILETIME=[7C849410:01C30946]
>
> The problem is easy_fp_constant():
>
> /* If we are using V.4 style PIC, consider all constants to be hard. */
> if (flag_pic && DEFAULT_ABI == ABI_V4)
> return 0;
>
> This means that "input_operand" predicate fails for movdf_hardfloat32 when
> presented with const_double:DF. I'm not sure what's suppose to save us at
> that point.
In that case, the RTL should never have been generated...
--
- Geoffrey Keating <geoffk@geoffk.org>
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: optimization/10315: [3.2/3.3 regression] [powerpc] ICE: in extract_insn, at recog.c:2175
@ 2003-04-23 3:16 David Edelsohn
0 siblings, 0 replies; 8+ messages in thread
From: David Edelsohn @ 2003-04-23 3:16 UTC (permalink / raw)
To: nobody; +Cc: gcc-prs
The following reply was made to PR optimization/10315; it has been noted by GNATS.
From: David Edelsohn <dje@watson.ibm.com>
To: Geoff Keating <geoffk@geoffk.org>
Cc: Steven Bosscher <s.bosscher@student.tudelft.nl>, gcc-gnats@gcc.gnu.org,
gcc-bugs@gcc.gnu.org, adconrad@0c3.net, 186299@bugs.debian.org
Subject: Re: optimization/10315: [3.2/3.3 regression] [powerpc] ICE: in extract_insn, at recog.c:2175
Date: Tue, 22 Apr 2003 23:14:37 -0400
The problem is easy_fp_constant():
/* If we are using V.4 style PIC, consider all constants to be hard. */
if (flag_pic && DEFAULT_ABI == ABI_V4)
return 0;
This means that "input_operand" predicate fails for movdf_hardfloat32 when
presented with const_double:DF. I'm not sure what's suppose to save us at
that point.
David
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: optimization/10315: [3.2/3.3 regression] [powerpc] ICE: in extract_insn, at recog.c:2175
@ 2003-04-07 7:16 Steven Bosscher
0 siblings, 0 replies; 8+ messages in thread
From: Steven Bosscher @ 2003-04-07 7:16 UTC (permalink / raw)
To: nobody; +Cc: gcc-prs
The following reply was made to PR optimization/10315; it has been noted by GNATS.
From: Steven Bosscher <s.bosscher@student.tudelft.nl>
To: gcc-gnats@gcc.gnu.org, gcc-bugs@gcc.gnu.org, adconrad@0c3.net,
nobody@gcc.gnu.org, gcc-prs@gcc.gnu.org, 186299@bugs.debian.org
Cc:
Subject: Re: optimization/10315: [3.2/3.3 regression] [powerpc] ICE: in extract_insn,
at recog.c:2175
Date: Mon, 07 Apr 2003 09:12:21 +0200
http://gcc.gnu.org/cgi-bin/gnatsweb.pl?cmd=view%20audit-trail&database=gcc&pr=10315
Is this problem present on mainline as well?
^ permalink raw reply [flat|nested] 8+ messages in thread
* optimization/10315: [3.2/3.3 regression] [powerpc] ICE: in extract_insn, at recog.c:2175
@ 2003-04-05 13:56 Matthias Klose
0 siblings, 0 replies; 8+ messages in thread
From: Matthias Klose @ 2003-04-05 13:56 UTC (permalink / raw)
To: gcc-gnats, debian-gcc
>Number: 10315
>Category: optimization
>Synopsis: [3.2/3.3 regression] [powerpc] ICE: in extract_insn, at recog.c:2175
>Confidential: no
>Severity: serious
>Priority: medium
>Responsible: unassigned
>State: open
>Class: ice-on-legal-code
>Submitter-Id: net
>Arrival-Date: Sat Apr 05 13:56:00 UTC 2003
>Closed-Date:
>Last-Modified:
>Originator: Adam Conrad <adconrad@0c3.net>
>Release: 3.2.1 (Debian) (Debian unstable)
>Organization:
The Debian Project
>Environment:
System: Debian GNU/Linux (unstable)
Architecture: powerpc
>Description:
[ Reported to the Debian BTS as report #186299.
Please CC 186299@bugs.debian.org on replies.
Log of report can be found at http://bugs.debian.org/186299 ]
Rechecked with 3.2 20030314 and 3.3 20030404.
While building php3 on unstable/powerpc, gcc-3.2 ICEs on a file that gcc-2.95
handles fine. Attemps were made with gcc-2.95 (success), gcc-3.2 (fail), and
gcc-snapshot (fail).
Using -O0 or omitting -fPIC doesn't show the ICE.
$ gcc -c -fPIC -O1 pack.i
../functions/pack.c: In function `php3_unpack':
../functions/pack.c:807: error: unrecognizable insn:
(insn 1275 1022 3 0 (nil) (set (reg/v:DF 311)
(const_double:DF 0.0 [0x0.0p+0])) -1 (nil)
(nil))
../functions/pack.c:807: internal compiler error: in extract_insn, at recog.c:2175
Please submit a full bug report,
with preprocessed source if appropriate.
See <URL:http://gcc.gnu.org/bugs.html> for instructions.
[appending the source in a followup]
>How-To-Repeat:
>Fix:
>Release-Note:
>Audit-Trail:
>Unformatted:
^ permalink raw reply [flat|nested] 8+ messages in thread
end of thread, other threads:[~2003-04-25 14:06 UTC | newest]
Thread overview: 8+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2003-04-25 14:06 optimization/10315: [3.2/3.3 regression] [powerpc] ICE: in extract_insn, at recog.c:2175 David Edelsohn
-- strict thread matches above, loose matches on Subject: below --
2003-04-24 4:56 Richard Henderson
2003-04-23 22:56 Richard Henderson
2003-04-23 20:16 David Edelsohn
2003-04-23 18:26 Geoff Keating
2003-04-23 3:16 David Edelsohn
2003-04-07 7:16 Steven Bosscher
2003-04-05 13:56 Matthias Klose
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).