[Bug target/27006] [4.1/4.2 Regression] Invalid altivec constant loading code
--- Comment #6 from uweigand at gcc dot gnu dot org 2006-04-13 11:47 --- I've now tested and submitted the patch, thanks. -- uweigand at gcc dot gnu dot org changed: What|Removed |Added URL||http://gcc.gnu.org/ml/gcc- ||patches/2006- ||04/msg00490.html Keywords||patch http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27006
[Bug target/27006] [4.1/4.2 Regression] Invalid altivec constant loading code
--- Comment #8 from uweigand at gcc dot gnu dot org 2006-04-13 20:27 --- Subject: Bug 27006 Author: uweigand Date: Thu Apr 13 20:26:59 2006 New Revision: 112923 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=112923 Log: 2006-04-13 Paolo Bonzini <[EMAIL PROTECTED]> Ulrich Weigand <[EMAIL PROTECTED]> PR target/27006 * config/rs6000/rs6000.h (EASY_VECTOR_15_ADD_SELF): Require n to be even. PR target/27006 * gcc.dg/vmx/pr27006.c: New testcase. Added: trunk/gcc/testsuite/gcc.dg/vmx/pr27006.c Modified: trunk/gcc/ChangeLog trunk/gcc/config/rs6000/rs6000.h trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27006
[Bug target/27006] [4.1/4.2 Regression] Invalid altivec constant loading code
--- Comment #9 from uweigand at gcc dot gnu dot org 2006-04-13 20:33 --- Subject: Bug 27006 Author: uweigand Date: Thu Apr 13 20:33:51 2006 New Revision: 112924 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=112924 Log: 2006-04-13 Paolo Bonzini <[EMAIL PROTECTED]> Ulrich Weigand <[EMAIL PROTECTED]> PR target/27006 * config/rs6000/rs6000.h (EASY_VECTOR_15_ADD_SELF): Require n to be even. PR target/27006 * gcc.dg/vmx/pr27006.c: New testcase. Added: branches/gcc-4_1-branch/gcc/testsuite/gcc.dg/vmx/pr27006.c Modified: branches/gcc-4_1-branch/gcc/ChangeLog branches/gcc-4_1-branch/gcc/config/rs6000/rs6000.h branches/gcc-4_1-branch/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27006
[Bug target/27006] [4.1/4.2 Regression] Invalid altivec constant loading code
--- Comment #10 from uweigand at gcc dot gnu dot org 2006-04-13 20:35 --- Fixed for 4.1 and mainline. -- uweigand at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27006
[Bug rtl-optimization/27661] ICE in subst_reloads
--- Comment #3 from uweigand at gcc dot gnu dot org 2006-05-22 13:27
---
Looking somewhat more into this problem, there are other places where
reload decides to reload an CONST_INT as address. Where this happens,
it usually uses Pmode as the mode to do the reload in (which makes
sense as Pmode should always be valid as the mode of an address).
Look e.g. at the various call sites of find_reloads_address_part.
However, at the place where the decision to reload a valid address
due to and EXTRA_MEMORY_CONSTRAINT or 'o' constraint is made, this
special treatment of VOIDmode constants is missing. However, it
looks to me that this was simply an oversight here.
Thus, I'd propose something like the following patch (as of right
now completely untested) to replace VOIDmode by Pmode at that place
too. This should fix the problem.
Index: gcc/reload.c
===
*** gcc/reload.c(revision 113828)
--- gcc/reload.c(working copy)
*** find_reloads (rtx insn, int replace, int
*** 3854,3864
&& goal_alternative_offmemok[i]
&& MEM_P (recog_data.operand[i]))
{
operand_reloadnum[i]
= push_reload (XEXP (recog_data.operand[i], 0), NULL_RTX,
&XEXP (recog_data.operand[i], 0), (rtx*) 0,
base_reg_class (VOIDmode, MEM, SCRATCH),
!GET_MODE (XEXP (recog_data.operand[i], 0)),
VOIDmode, 0, 0, i, RELOAD_FOR_INPUT);
rld[operand_reloadnum[i]].inc
= GET_MODE_SIZE (GET_MODE (recog_data.operand[i]));
--- 3854,3872
&& goal_alternative_offmemok[i]
&& MEM_P (recog_data.operand[i]))
{
+ /* If the address to be reloaded is a VOIDmode constant,
+ use Pmode as mode of the reload register, as would have
+ been done by find_reloads_address. */
+ enum machine_mode address_mode;
+ address_mode = GET_MODE (XEXP (recog_data.operand[i], 0));
+ if (address_mode == VOIDmode)
+ address_mode = Pmode;
+
operand_reloadnum[i]
= push_reload (XEXP (recog_data.operand[i], 0), NULL_RTX,
&XEXP (recog_data.operand[i], 0), (rtx*) 0,
base_reg_class (VOIDmode, MEM, SCRATCH),
!address_mode,
VOIDmode, 0, 0, i, RELOAD_FOR_INPUT);
rld[operand_reloadnum[i]].inc
= GET_MODE_SIZE (GET_MODE (recog_data.operand[i]));
I'll test the patch and propose it on gcc-patches if it works out.
Could you verify this patch helps with your original testcase?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27661
[Bug target/27772] mr instruction with odd-numbered register created
--- Comment #2 from uweigand at gcc dot gnu dot org 2006-05-26 12:58
---
This looks like a source-code problem. The assembler instruction
union {DItype __ll; struct {USItype __h, __l;} __i; } __x;
__asm__ ("lr %N0,%1\n\tmr %0,%2" : "=&r" (__x.__ll)
: "r" (__xm0), "r" (__xm1));
fundamentally assumes __ll is in fact of mode DImode, as the type name
DItype suggests -- that's (on 32-bit) what causes reload to allocate a
register *pair* for the %0 operand.
However, in your mul.i file, that type is defined as:
typedef long int DItype;
which happens to be in fact SImode ...
--
uweigand at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution||INVALID
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27772
[Bug rtl-optimization/27661] ICE in subst_reloads
--- Comment #5 from uweigand at gcc dot gnu dot org 2006-05-26 20:22 --- Subject: Bug 27661 Author: uweigand Date: Fri May 26 20:21:53 2006 New Revision: 114141 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=114141 Log: PR rtl-optimization/27661 * reload.c (find_reloads): When reloading a VOIDmode constant as address due to an EXTRA_MEMORY_CONSTRAINT or 'o' constraint, use Pmode as mode of the reload register. PR rtl-optimization/27661 * gcc.dg/pr27661.c: New test case. Added: trunk/gcc/testsuite/gcc.dg/pr27661.c Modified: trunk/gcc/ChangeLog trunk/gcc/reload.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27661
[Bug target/27842] New: Miscompile of Altivec vec_abs (float) inside loop
The following test case gets miscompiled and fails when built
with "-O -maltivec -mabi=altivec -include altivec.h" on GCC 4.1:
extern void abort (void);
void test (vector float *p, int n)
{
int i;
for (i = 0; i < n; i++)
p[i] = vec_abs (p[i]);
}
int
main (void)
{
vector float p = (vector float){ 0.5, 0.5, 0.5, 0.5 };
vector float q = p;
test (&p, 1);
if (memcmp (&p, &q, sizeof (p)))
abort ();
return 0;
}
The reason for this appears to be an abuse of RTL semantics by
the "altivec_vspltisw_v4sf" pattern:
(define_insn "altivec_vspltisw_v4sf"
[(set (match_operand:V4SF 0 "register_operand" "=v")
(vec_duplicate:V4SF
(float:SF (match_operand:QI 1 "s5bit_cint_operand" "i"]
"TARGET_ALTIVEC"
"vspltisw %0,%1"
[(set_attr "type" "vecperm")])
What this instruction does is to load an immediate *integer*
value into a vector register, which happens to be re-interpreted
as a floating point value (without changing the bit pattern).
What the RTL associated with the pattern *says*, however, is
to load the integer, *converted to floating point*, into the
register, which is a quite different semantics.
Now, since the pattern is only explicitly generated from within
other expanders inside altivec.md (apparently), all of which
expect the semantics of the actual Altivec instruction, not the
semantics as literally specified in the RTL, those misinterpretations
generally cancel each other and generated code behaves as expected.
However, as soon as the middle-end gets an opportunity to run the
RTL through the simplifier, everything breaks. This happens in
particular when the load is being hoisted out of a loop due to
being loop-invariant, as in the above test case: the vec_abs
pattern expands via this expander
;; Generate
;;vspltisw SCRATCH1,-1
;;vslw SCRATCH2,SCRATCH1,SCRATCH1
;;vandc %0,%1,SCRATCH2
(define_expand "absv4sf2"
[(set (match_dup 2)
(vec_duplicate:V4SF (float:SF (const_int -1
(set (match_dup 3)
(unspec:V4SF [(match_dup 2) (match_dup 2)] UNSPEC_VSLW))
(set (match_operand:V4SF 0 "register_operand" "=v")
(and:V4SF (not:V4SF (match_dup 3))
(match_operand:V4SF 1 "register_operand" "v")))]
"TARGET_ALTIVEC"
{
operands[2] = gen_reg_rtx (V4SFmode);
operands[3] = gen_reg_rtx (V4SFmode);
})
and the first two insns are in fact loop invariant.
The problem in this particular test case is a regression in GCC 4.1,
introduced by this patch:
[PATCH] Improve scheduling of Altivec absolute value patterns
http://gcc.gnu.org/ml/gcc-patches/2005-02/msg01195.html
-(define_insn "absv4sf2"
- [(set (match_operand:V4SF 0 "register_operand" "=v")
-(abs:V4SF (match_operand:V4SF 1 "register_operand" "v")))
- (clobber (match_scratch:V4SF 2 "=&v"))
- (clobber (match_scratch:V4SF 3 "=&v"))]
+;; Generate
+;;vspltisw SCRATCH1,-1
+;;vslw SCRATCH2,SCRATCH1,SCRATCH1
+;;vandc %0,%1,SCRATCH2
+(define_expand "absv4sf2"
+ [(set (match_dup 2)
+ (vec_duplicate:V4SF (float:SF (const_int -1
+ (set (match_dup 3)
+(unspec:V4SF [(match_dup 2) (match_dup 2)] UNSPEC_VSLW))
+ (set (match_operand:V4SF 0 "register_operand" "=v")
+(and:V4SF (not:V4SF (match_dup 3))
+ (match_operand:V4SF 1 "register_operand" "v")))]
"TARGET_ALTIVEC"
- "vspltisw %2,-1\;vslw %3,%2,%2\;vandc %0,%1,%3"
- [(set_attr "type" "vecsimple")
- (set_attr "length" "12")])
+{
+ operands[2] = gen_reg_rtx (V4SFmode);
+ operands[3] = gen_reg_rtx (V4SFmode);
+})
However, the underlying abuse of RTL semantics when describing the
vspltisw instruction in V4SFmode apparently pre-dates this patch.
The easiest way to fix this would appear to use an UNSPEC to
describe the insn semantics. Any better idea?
--
Summary: Miscompile of Altivec vec_abs (float) inside loop
Product: gcc
Version: 4.1.0
Status: UNCONFIRMED
Keywords: wrong-code
Severity: normal
Priority: P3
Component: target
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: uweigand at gcc dot gnu dot org
GCC target triplet: powerpc*-*-*
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27842
[Bug target/27842] Miscompile of Altivec vec_abs (float) inside loop
--- Comment #2 from uweigand at gcc dot gnu dot org 2006-05-31 16:59 --- I'm not sure (subreg:SF (const_int)) is canonical RTL, I haven't seen subregs of anything but REG or MEM. In any case, I don't really see what this would buy us over an UNSPEC -- will the generic simplifier be able to evaluate this by re-interpreting the bit pattern as float according to the target representation? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27842
[Bug target/27842] Miscompile of Altivec vec_abs (float) inside loop
--- Comment #4 from uweigand at gcc dot gnu dot org 2006-06-01 21:30 --- Yes, that makes sense -- in fact, it looks like altivec_vslw_v4sf can then be removed as well. I'm currenly testing a patch to that effect ... -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27842
[Bug target/27842] Miscompile of Altivec vec_abs (float) inside loop
--- Comment #7 from uweigand at gcc dot gnu dot org 2006-06-06 17:01
---
Subject: Bug 27842
Author: uweigand
Date: Tue Jun 6 17:01:27 2006
New Revision: 114438
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=114438
Log:
PR target/27842
* config/rs6000/altivec.md (UNSPEC_VSLW): Remove.
("altivec_vspltisw_v4sf", "altivec_vslw_v4sf"): Remove.
("mulv4sf3", "absv4sf3", "negv4sf3"): Adapt users to use
V4SImode temporaries and operations instead.
PR target/27842
* gcc.dg/vmx/pr27842.c: New test.
Added:
trunk/gcc/testsuite/gcc.dg/vmx/pr27842.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/rs6000/altivec.md
trunk/gcc/testsuite/ChangeLog
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27842
[Bug target/27842] Miscompile of Altivec vec_abs (float) inside loop
--- Comment #8 from uweigand at gcc dot gnu dot org 2006-06-06 17:05
---
Subject: Bug 27842
Author: uweigand
Date: Tue Jun 6 17:04:56 2006
New Revision: 114439
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=114439
Log:
PR target/27842
* config/rs6000/altivec.md (UNSPEC_VSLW): Remove.
("altivec_vspltisw_v4sf", "altivec_vslw_v4sf"): Remove.
("mulv4sf3", "absv4sf3", "negv4sf3"): Adapt users to use
V4SImode temporaries and operations instead.
PR target/27842
* gcc.dg/vmx/pr27842.c: New test.
Added:
branches/gcc-4_1-branch/gcc/testsuite/gcc.dg/vmx/pr27842.c
Modified:
branches/gcc-4_1-branch/gcc/ChangeLog
branches/gcc-4_1-branch/gcc/config/rs6000/altivec.md
branches/gcc-4_1-branch/gcc/testsuite/ChangeLog
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27842
[Bug target/27842] Miscompile of Altivec vec_abs (float) inside loop
--- Comment #9 from uweigand at gcc dot gnu dot org 2006-06-06 17:10 --- Fixed on 4.1 branch and mainline. -- uweigand at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27842
[Bug c++/18182] Incorrect processing of __attribute__ by the C++ parser
--- Comment #3 from uweigand at gcc dot gnu dot org 2006-07-14 19:27 --- Yes, looks like this is long fixed. Closing bug now. -- uweigand at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18182
[Bug middle-end/37053] [4.3/4.4/4.5 regression] ICE in reload_cse_simplify_operands, at postreload.c:395
--- Comment #18 from uweigand at gcc dot gnu dot org 2009-08-05 14:59 --- (In reply to comment #16) > Uli, can you please have a look at Richard's and Paolo's patches and does one > or the other seem like a "better" fix? I've yet another suggestion :-) See my message at: http://gcc.gnu.org/ml/gcc-patches/2009-08/msg00254.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37053
[Bug middle-end/37053] [4.3/4.4/4.5 regression] ICE in reload_cse_simplify_operands, at postreload.c:395
--- Comment #19 from uweigand at gcc dot gnu dot org 2009-08-10 15:34 --- Subject: Bug 37053 Author: uweigand Date: Mon Aug 10 15:34:09 2009 New Revision: 150626 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=150626 Log: PR target/37053 * reload1.c (reload_as_needed): Use cancel_changes to completely undo a failed replacement attempt. Modified: trunk/gcc/ChangeLog trunk/gcc/reload1.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37053
[Bug ada/22533] [4.1 regression] ICE in get_base_var
--- Comment #24 from uweigand at gcc dot gnu dot org 2005-11-05 00:23 --- Well, the workaround removes the ICE, but constructor handling appears still broken: ada/sem_prag.o(.text+0xa58): In function `sem_prag.analyze_pragma.check_no_identifier': ../../gcc-head/gcc/ada/sem_prag.adb:1168: undefined reference to `C.1290.13979' ada/sem_prag.o(.text+0x8758): In function `sem_prag.analyze_pragma': ../../gcc-head/gcc/ada/sem_prag.adb:382: undefined reference to `C.3692.17381' collect2: ld returned 1 exit status make[2]: *** [gnat1] Error 1 (at least on s390 and s390x). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22533
[Bug target/24621] [4.1 Regression] internal compiler error: in reload_cse_simplify_operands, at postreload.c:393
--- Comment #5 from uweigand at gcc dot gnu dot org 2005-11-07 18:03 --- Alternatively, the PR is also fixed by rth's patch here: http://gcc.gnu.org/ml/gcc-patches/2005-11/msg00424.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24621
[Bug ada/22533] [4.1 regression] Ada ICE during bootstrap on many platforms
--- Comment #28 from uweigand at gcc dot gnu dot org 2005-11-15 18:31 --- Just one additional comment: the patch from comment #10 was rejected, maybe because it required changes to the core gimplifier. However, I've tested just the Ada front-end pieces from that patch, and this *already* fixed the problem for me. The reason appears to be that -in general- occurrences of ADDR_EXPR (CONSTRUCTOR) do not constitute a problem. The problem only comes when such constructs occur in turn as part of another (outer) CONSTRUCTOR. The middle-end never generates that case, only the Ada front-end does -- thus it suffices to fix those cases in the Ada front-end itself. So I guess it would be possible right now to fix the bootstrap issue by a pure front-end patch. (This doesn't address the more general question of whether or not the gimplifier has a bug that can be exposed by other front-ends too, of course ...) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22533
[Bug ada/22533] [4.1 regression] Ada ICE during bootstrap on many platforms
--- Comment #30 from uweigand at gcc dot gnu dot org 2005-11-17 01:08 --- With that patch applied, Ada bootstraps on s390-ibm-linux and s390x-ibm-linux. Regression test results are at: http://gcc.gnu.org/ml/gcc-testresults/2005-11/msg00831.html http://gcc.gnu.org/ml/gcc-testresults/2005-11/msg00832.html There's still quite a number of regressions, but the good news is that all of them are already known from other platforms. Sorted by PR number, the regressions are: both s390 and s390x: PR 18659: c32001e c64105b c95086b PR 22333: c34007p c34007r c45282b PR 20548: c52103x c52104x c52104y PR 22561: ca11c01 s390x only: PR 18819: cdd2a01(*) cdd2a02 s390 only: PR 20753: ce3810b (*) The PR mentions only cdd2a02. But cdd2a01 fails with seemingly the same symptom for me ... -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22533
[Bug rtl-optimization/24883] [4.1 Regression] fatal error: internal consistency failure building xorg-x11
--- Comment #4 from uweigand at gcc dot gnu dot org 2005-11-17 12:45 --- It looks like the simplify-rtx patch is not really the cause of the problem, it simply exposes a pre-existing bug in combine and/or flow. Before combine, we have a situation that looks like (simplified): insn 82: reg46 = reg49 ^ reg50 (REG_DEAD reg49) insn 87: reg50 = reg46 ^ reg50 (REG_READ reg46) Note that reg 50 is live both at the start and the end of the current basic block. Now, due to the improved XOR optimization in simplify-rtx, combine recognized these insn can be combined into: insn 87: reg50 = reg49 (REG_READ reg49) And suddenly reg50 is no longer live at the start of this basic block. Unfortunately, there appears to be no code in combine that recognizes this fact and schedules the basic block for updating of global life info. (The only cases where that happens are related to moving REG_DEAD notes, but in this situation we don't *have* a REG_DEAD note for reg50 in the first place.) Thus, reg50 remains marked live-at-start in this basic block, and when a later pass does a local live info update on the block, the sanity check in verify_local_life_at_start triggers. Right now I don't know how and where to fix this. -- uweigand at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2005-11-17 12:45:27 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24883
[Bug target/25311] [4.1 Regression] ICE in reload_cse_simplify_operands, at postreload.c:393
--- Comment #3 from uweigand at gcc dot gnu dot org 2005-12-09 11:20 --- Subject: Bug 25311 Author: uweigand Date: Fri Dec 9 11:20:40 2005 New Revision: 108278 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=108278 Log: PR target/25311 * config/s390/s390.c (struct s390_address): New field literal_pool. (s390_decompose_address): Compute literal_pool field. Do not assume register %r13 is always (and solely) used as pool base. (s390_extra_constraint_str): Use literal_pool field. PR target/25311 * gcc.c-torture/compile/pr25311.c: New test. Added: trunk/gcc/testsuite/gcc.c-torture/compile/pr25311.c Modified: trunk/gcc/ChangeLog trunk/gcc/config/s390/s390.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25311
[Bug target/25311] [4.1 Regression] ICE in reload_cse_simplify_operands, at postreload.c:393
--- Comment #4 from uweigand at gcc dot gnu dot org 2005-12-09 11:26 --- Subject: Bug 25311 Author: uweigand Date: Fri Dec 9 11:26:47 2005 New Revision: 108279 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=108279 Log: PR target/25311 * config/s390/s390.c (struct s390_address): New field literal_pool. (s390_decompose_address): Compute literal_pool field. Do not assume register %r13 is always (and solely) used as pool base. (s390_extra_constraint_str): Use literal_pool field. PR target/25311 * gcc.c-torture/compile/pr25311.c: New test. Added: branches/gcc-4_1-branch/gcc/testsuite/gcc.c-torture/compile/pr25311.c Modified: branches/gcc-4_1-branch/gcc/ChangeLog branches/gcc-4_1-branch/gcc/config/s390/s390.c branches/gcc-4_1-branch/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25311
[Bug target/25311] [4.1 Regression] ICE in reload_cse_simplify_operands, at postreload.c:393
-- uweigand at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |uweigand at gcc dot gnu dot |dot org |org Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2005-12-09 11:28:38 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25311
[Bug target/25311] [4.1 Regression] ICE in reload_cse_simplify_operands, at postreload.c:393
--- Comment #5 from uweigand at gcc dot gnu dot org 2005-12-09 11:29 --- Fixed. -- uweigand at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25311
[Bug rtl-optimization/25310] [4.1 Regression] ICE in reload_cse_simplify_operands, at postreload.c:393
--- Comment #3 from uweigand at gcc dot gnu dot org 2005-12-09 11:30 --- Looks like a reload problem, I'll be posting a patch ... -- uweigand at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |uweigand at gcc dot gnu dot |dot org |org Status|UNCONFIRMED |ASSIGNED Component|target |rtl-optimization Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2005-12-09 11:30:15 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25310
[Bug fortran/25416] New: Segmentation fault in gfc_conv_function_call
The following test case
function bug(self,strvec) result(res)
character(*) :: self
character(*), dimension(:), intent(in) :: strvec
logical(kind=kind(.true.)) :: res
res = any(index(strvec,spread(self,1,size(strvec))) /= 0)
end function
triggers this ICE
#0 0x80070008 in gfc_conv_function_call (se=0x3ffdfc0,
sym=0x8059e770, arg=0x8059d850)
at ../../gcc-4_1/gcc/fortran/trans-expr.c:1542
#1 0x80074256 in gfc_conv_intrinsic_funcall (se=0x3ffdfc0,
expr=0x8059e040)
at ../../gcc-4_1/gcc/fortran/trans-intrinsic.c:1257
#2 0x80077220 in gfc_conv_intrinsic_function (se=0x3ffdfc0,
expr=0x8059e040)
at ../../gcc-4_1/gcc/fortran/trans-intrinsic.c:3256
#3 0x80070576 in gfc_conv_function_expr (se=0x3ffdfc0,
expr=0x8059d850) at ../../gcc-4_1/gcc/fortran/trans-expr.c:1951
#4 0x800709e0 in gfc_conv_expr (se=0x3ffdfc0, expr=0x8059e040) at
../../gcc-4_1/gcc/fortran/trans-expr.c:2314
#5 0x80066e5e in gfc_add_loop_ss_code (loop=0x3ffe1d0,
ss=0x8059e470, subscript=0 '\0')
at ../../gcc-4_1/gcc/fortran/trans-array.c:1480
#6 0x80067346 in gfc_conv_loop_setup (loop=0x3ffe1d0) at
../../gcc-4_1/gcc/fortran/trans-array.c:2732
#7 0x800743a2 in gfc_conv_intrinsic_anyall (se=0x3fff290,
expr=0x80572730, op=101)
at ../../gcc-4_1/gcc/fortran/trans-intrinsic.c:1323
#8 0x800779e4 in gfc_conv_intrinsic_function (se=0x3fff290,
expr=0x8059d3a0)
at ../../gcc-4_1/gcc/fortran/trans-intrinsic.c:2991
#9 0x80070576 in gfc_conv_function_expr (se=0x3fff290,
expr=0x8059d850) at ../../gcc-4_1/gcc/fortran/trans-expr.c:1951
#10 0x800709e0 in gfc_conv_expr (se=0x3fff290, expr=0x8059d3a0) at
../../gcc-4_1/gcc/fortran/trans-expr.c:2314
#11 0x80072c86 in gfc_trans_assignment (expr1=0x8059d220,
expr2=0x8059d3a0) at ../../gcc-4_1/gcc/fortran/trans-expr.c:2751
#12 0x800730c8 in gfc_trans_assign (code=0x0) at
../../gcc-4_1/gcc/fortran/trans-expr.c:2813
#13 0x80060a68 in gfc_trans_code (code=0x8059cb50) at
../../gcc-4_1/gcc/fortran/trans.c:493
#14 0x8006def8 in gfc_generate_function_code (ns=0x805654d0) at
../../gcc-4_1/gcc/fortran/trans-decl.c:2639
#15 0x80060b60 in gfc_generate_code (ns=0x0) at
../../gcc-4_1/gcc/fortran/trans.c:659
#16 0x80042bd0 in gfc_parse_file () at
../../gcc-4_1/gcc/fortran/parse.c:2680
#17 0x8005c0d0 in gfc_be_parse_file (set_yydebug=0) at
../../gcc-4_1/gcc/fortran/f95-lang.c:286
#18 0x802648d0 in toplev_main (argc=7, argv=0x8055e6a0) at
../../gcc-4_1/gcc/toplev.c:990
#19 0x80083fcc in main (argc=0, argv=0x0) at
../../gcc-4_1/gcc/main.c:35
in the line
1542 need_interface_mapping = ((sym->ts.type == BT_CHARACTER
1543 && sym->ts.cl->length->expr_type !=
EXPR_CONSTANT)
1544|| sym->attr.dimension);
because sym->ts.cl->length is NULL.
(gdb) print *sym
$1 = {name = 0x8059ba7c "_gfortran_spread_char_scalar", module = 0x0,
declared_at = {nextc = 0x80578268 "", lb = 0x80578240},
ts = {type = BT_CHARACTER, kind = 1, derived = 0x0, cl = 0x80572730}, attr =
{allocatable = 0, dimension = 1, external = 1,
intrinsic = 0, optional = 0, pointer = 0, save = 0, target = 0, dummy = 0,
result = 0, assign = 0, data = 0, use_assoc = 0,
in_namelist = 0, in_common = 0, in_equivalence = 0, function = 1,
subroutine = 0, generic = 0, implicit_type = 0, untyped = 0,
sequence = 0, elemental = 0, pure = 0, recursive = 0, unmaskable = 0,
masked = 0, contained = 0, noreturn = 0, entry = 0,
entry_master = 0, mixed_entry_master = 0, always_explicit = 1, referenced =
0, is_main_program = 0, access = ACCESS_UNKNOWN,
intent = INTENT_UNKNOWN, flavor = FL_PROCEDURE, if_source = IFSRC_UNKNOWN,
proc = PROC_INTRINSIC, cray_pointer = 0,
cray_pointee = 0}, generic = 0x0, component_access = ACCESS_UNKNOWN, formal
= 0x0, formal_ns = 0x0, value = 0x0,
as = 0x8059e8a0, result = 0x8059e770, components = 0x0, cp_pointer = 0x0,
common_next = 0x0, common_head = 0x0, dummy_order = 0,
namelist = 0x0, namelist_tail = 0x0, old_symbol = 0x0, tlink = 0x0, mark = 0,
new = 0, equiv_built = 0, refs = 0, ns = 0x0,
backend_decl = 0x0}
(gdb) print *sym->ts.cl
$2 = {length = 0x0, next = 0x0, backend_decl = 0x21f8460}
--
Summary: Segmentation fault in gfc_conv_function_call
Product: gcc
Version: 4.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: uweigand at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25416
[Bug rtl-optimization/25310] [4.1/4.2 Regression] ICE in reload_cse_simplify_operands, at postreload.c:393
--- Comment #4 from uweigand at gcc dot gnu dot org 2005-12-14 23:35 --- Subject: Bug 25310 Author: uweigand Date: Wed Dec 14 23:34:51 2005 New Revision: 108543 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=108543 Log: PR rtl-optimization/25310 * reload1.c (eliminate_regs_in_insn): Handle lowpart SUBREGs of the eliminable register when substituting into a PLUS. PR rtl-optimization/25310 * gcc.c-torture/compile/pr25310.c: New test. Added: trunk/gcc/testsuite/gcc.c-torture/compile/pr25310.c Modified: trunk/gcc/ChangeLog trunk/gcc/reload1.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25310
[Bug rtl-optimization/25310] [4.1/4.2 Regression] ICE in reload_cse_simplify_operands, at postreload.c:393
--- Comment #5 from uweigand at gcc dot gnu dot org 2005-12-14 23:40 --- Subject: Bug 25310 Author: uweigand Date: Wed Dec 14 23:40:22 2005 New Revision: 108544 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=108544 Log: PR rtl-optimization/25310 * reload1.c (eliminate_regs_in_insn): Handle lowpart SUBREGs of the eliminable register when substituting into a PLUS. PR rtl-optimization/25310 * gcc.c-torture/compile/pr25310.c: New test. Added: branches/gcc-4_1-branch/gcc/testsuite/gcc.c-torture/compile/pr25310.c Modified: branches/gcc-4_1-branch/gcc/ChangeLog branches/gcc-4_1-branch/gcc/reload1.c branches/gcc-4_1-branch/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25310
[Bug rtl-optimization/25310] [4.1/4.2 Regression] ICE in reload_cse_simplify_operands, at postreload.c:393
--- Comment #6 from uweigand at gcc dot gnu dot org 2005-12-14 23:40 --- Fixed. -- uweigand at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25310
[Bug rtl-optimization/21041] [4.0/4.1/4.2 Regression] ICE: output_operand: Cannot decompose address
--- Comment #11 from uweigand at gcc dot gnu dot org 2005-12-16 18:05 --- Patch posted. -- uweigand at gcc dot gnu dot org changed: What|Removed |Added URL||http://gcc.gnu.org/ml/gcc- ||patches/2005- ||12/msg01283.html Component|target |rtl-optimization Keywords||patch http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21041
[Bug rtl-optimization/21041] [4.0/4.1/4.2 Regression] ICE: output_operand: Cannot decompose address
--- Comment #12 from uweigand at gcc dot gnu dot org 2005-12-18 16:06 --- Subject: Bug 21041 Author: uweigand Date: Sun Dec 18 16:06:55 2005 New Revision: 108760 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=108760 Log: PR rtl-optimization/21041 * reload.c (find_reloads_subreg_address): Replace paradoxical subreg of MEM by widened access only if the resulting memory is properly aligned, even on !STRICT_ALIGNMENT targets. PR rtl-optimization/21041 * gcc.dg/pr21041.c: New test. Added: trunk/gcc/testsuite/gcc.dg/pr21041.c Modified: trunk/gcc/ChangeLog trunk/gcc/reload.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21041
[Bug rtl-optimization/21041] [4.0/4.1/4.2 Regression] ICE: output_operand: Cannot decompose address
--- Comment #13 from uweigand at gcc dot gnu dot org 2005-12-23 18:38 --- Subject: Bug 21041 Author: uweigand Date: Fri Dec 23 18:38:43 2005 New Revision: 109019 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=109019 Log: PR rtl-optimization/21041 * reload.c (find_reloads_subreg_address): Replace paradoxical subreg of MEM by widened access only if the resulting memory is properly aligned, even on !STRICT_ALIGNMENT targets. PR rtl-optimization/21041 * gcc.dg/pr21041.c: New test. Added: branches/gcc-4_1-branch/gcc/testsuite/gcc.dg/pr21041.c Modified: branches/gcc-4_1-branch/gcc/ChangeLog branches/gcc-4_1-branch/gcc/reload.c branches/gcc-4_1-branch/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21041
[Bug rtl-optimization/21041] [4.0/4.1/4.2 Regression] ICE: output_operand: Cannot decompose address
--- Comment #14 from uweigand at gcc dot gnu dot org 2005-12-23 18:44 --- Subject: Bug 21041 Author: uweigand Date: Fri Dec 23 18:44:07 2005 New Revision: 109020 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=109020 Log: PR rtl-optimization/21041 * reload.c (find_reloads_subreg_address): Replace paradoxical subreg of MEM by widened access only if the resulting memory is properly aligned, even on !STRICT_ALIGNMENT targets. PR rtl-optimization/21041 * gcc.dg/pr21041.c: New test. Added: branches/gcc-4_0-branch/gcc/testsuite/gcc.dg/pr21041.c Modified: branches/gcc-4_0-branch/gcc/ChangeLog branches/gcc-4_0-branch/gcc/reload.c branches/gcc-4_0-branch/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21041
[Bug rtl-optimization/21041] [4.0/4.1/4.2 Regression] ICE: output_operand: Cannot decompose address
--- Comment #15 from uweigand at gcc dot gnu dot org 2005-12-23 18:45 --- Fixed. -- uweigand at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21041
[Bug fortran/25716] FAIL: gfortran.dg/char_result_11.f90 -O (test for excess errors)
--- Comment #15 from uweigand at gcc dot gnu dot org 2006-01-19 23:10 --- This testcase also fails on s390x-ibm-linux (crash of f951). The patch in comment 13 fixes the crash. Any chance of getting the fix into 4.1? -- uweigand at gcc dot gnu dot org changed: What|Removed |Added CC||uweigand at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25716
[Bug target/25864] Enable IBM long double format in 32-bit PowerPC Linux
--- Comment #4 from uweigand at gcc dot gnu dot org 2006-01-19 23:19 --- FYI, the glibc folks have made a similar request w.r.t. adding 128-bit long double (IEEE quad) support for s390(x)-ibm-linux. We're currently preparing a patch -- if there's still a chance of getting this into 4.1 we'd like to join ... -- uweigand at gcc dot gnu dot org changed: What|Removed |Added CC| |uweigand at gcc dot gnu dot | |org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25864
[Bug ada/18819] [4.1/4.2 Regression] ACATS cdd2a01 cdd2a02 fail at runtime
--- Comment #14 from uweigand at gcc dot gnu dot org 2006-01-20 18:39 --- Some additional details about the s390x failure. This is caused by a miscompile of the fdd2a00__write__2 support routine: lg %r4,168(%r15) # 35*movdi_64/8 [length = 6] lg %r3,160(%r15) # 36*movdi_64/8 [length = 6] cgr %r4,%r3 # 37*cmpdi_ccs/1[length = 4] stg %r2,168(%r15) # 33*movdi_64/9 [length = 6] Note how insn 35 reads a stack slot that is uninitialized because insn 33 has been scheduled later. This is apparently caused by an alias set issue. The code at the .t97.final_cleanup level reads: A.63 = system__arith_64__add_with_ovflo_check (D.1421, D.1426); R38b = (ada__streams__Tstream_element_offsetB *) &A.63; where the data type of A.63 is system__arith_64__int64. This gets expanded into (insn 32 31 33 3 (set (reg:DI 60) (reg:DI 2 %r2)) -1 (nil) (nil)) (insn 33 32 34 3 (set (mem/c/i:DI (plus:DI (reg/f:DI 39 virtual-stack-vars) (const_int -8 [0xfff8])) [26 A.63+0 S8 A64]) (reg:DI 60)) -1 (nil) (nil)) (insn 34 33 35 3 (parallel [ (set (reg:DI 43 [ R38b ]) (plus:DI (reg/f:DI 39 virtual-stack-vars) (const_int -8 [0xfff8]))) (clobber (reg:CC 33 %cc)) ]) -1 (nil) (nil)) (insn 35 34 36 3 (set (reg:DI 48 [ D.1430 ]) (mem:DI (reg:DI 43 [ R38b ]) [27 S8 A64])) -1 (nil) (nil)) Note alias set 26 in insn 33 vs. alias set 27 in insn 35. Any ideas why this would be the case? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18819
[Bug c/28862] New: attribute ((aligned)) ignored on vector variables
The following test case
__attribute__ ((vector_size (16))) unsigned int foo[128/16]
__attribute__((aligned (128)));
[ and analagously
vector unsigned int foo[128/16] __attribute__((aligned (128)));
on ppc (where "vector" is defined to __attribute__((altivec(vector__)))
or spu (where "vector" is defined to __attribute__((spu_vector))) ]
compiles to
.comm foo,128,16
Note that the user-specified alignment is ignored, and the default
alignment of 16 for this vector type is used instead.
The reason appears to be a problem in decl_attributes (attribs.c).
For this declaration, first the "aligned" attribute is processed,
and sets DECL_ALIGN to 128 bytes, as well as the DECL_USER_ALIGN
flag. However, subsequently the "vector_size" attribute is
processed, and this this is marked as "type_required", the following
piece of code in decl_attributes:
/* Layout the decl in case anything changed. */
if (spec->type_required && DECL_P (*node)
&& (TREE_CODE (*node) == VAR_DECL
|| TREE_CODE (*node) == PARM_DECL
|| TREE_CODE (*node) == RESULT_DECL))
relayout_decl (*node);
thinks it needs to recompute the decl properties. In particular,
void
relayout_decl (tree decl)
{
DECL_SIZE (decl) = DECL_SIZE_UNIT (decl) = 0;
DECL_MODE (decl) = VOIDmode;
DECL_ALIGN (decl) = 0;
SET_DECL_RTL (decl, 0);
layout_decl (decl, 0);
}
relayout_decl resets DECL_ALIGN without consideration of the
DECL_USER_ALIGN flag, and layout_decl then fills back in the
default alignment for the vector type.
The problem does not occur in 3.4, since decl_attributes there
works like this:
/* Layout the decl in case anything changed. */
if (spec->type_required && DECL_P (*node)
&& (TREE_CODE (*node) == VAR_DECL
|| TREE_CODE (*node) == PARM_DECL
|| TREE_CODE (*node) == RESULT_DECL))
{
/* Force a recalculation of mode and size. */
DECL_MODE (*node) = VOIDmode;
DECL_SIZE (*node) = 0;
if (!DECL_USER_ALIGN (*node))
DECL_ALIGN (*node) = 0;
layout_decl (*node, 0);
}
and specifically keeps user-requested alignments.
Now, I'm not quite sure what the correct fix for 4.0 and mainline is.
Should be not call relayout_decl (as in 3.4)? Or should we add the
DECL_USER_ALIGN check to relayout_decl (what about other callers of
this function)?
Richard, it appears you added both the DECL_USER_ALIGN check in
3.4, and the relayout_decl call in 4.0, see PR 18282. Any opinion?
--
Summary: attribute ((aligned)) ignored on vector variables
Product: gcc
Version: 4.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: uweigand at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28862
[Bug middle-end/28862] [4.0/4.1/4.2 Regression] attribute ((aligned)) ignored on vector variables
--- Comment #6 from uweigand at gcc dot gnu dot org 2006-09-05 12:41 --- (In reply to comment #4) > Anyways I am going to test the obvious fix unless you (Ulrich) want to do it. Please go ahead, thanks! -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28862
[Bug middle-end/28862] [4.0/4.1/4.2 Regression] attribute ((aligned)) ignored on vector variables
--- Comment #7 from uweigand at gcc dot gnu dot org 2006-09-05 12:47 --- (In reply to comment #5) > Is this also supposed to fix the problem I posted in comment #2? I applied > that > patch to my gcc but it didn't fix the generated code for me. It's just weird > because the bug only appears if the code is complex enough. If it's just a > rather simple function, the generated code is correct. No, your problem is certainly something completely different. In fact I've never seen GCC (common code) do anything even remotely like: >GCC reserves an area big enough to hold the structure plus padding, >so it can align the structure dynamically at runtime. It stores a >pointer to the reserved area and a pointer to the structure within >the area. Normally, attribute ((aligned)) does not cause any code to be generated that attempts to dynamically adjust alignment at runtime, it simply allows a variable to be aligned up to whatever default stack frame alignment the platform ABI provides for. It appears that the i386 back-end has some special code related to the -mstackrealign option that may be involved here. In any case, this would be something for an i386 back-end person to look into. Since this is a completely unrelated problem, I recommend you open a separate bugzilla for it. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28862
[Bug tree-optimization/30590] New: tree-nrv optimization clobbers return variable
The following test case, when compiled with g++ -O, has a return
value of 1 (instead of the correct value of 0):
struct test
{
int type;
char buffer[4242]; /* should trigger pass-by-reference */
};
int flag = 0;
struct test
reset (void)
{
struct test retval;
retval.type = 1;
return retval;
}
struct test
test (void)
{
struct test result;
result.type = 0;
for (int i = 0; i < 2; ++i)
{
struct test candidate = reset ();
if (flag)
result = candidate;
}
return result;
}
int
main (void)
{
struct test result = test ();
return result.type;
}
The reason for this appears to be a bug in the tree-nrv (named
return value) optimization pass. Before tree-nrv, the function
test looks like:
struct test candidate;
int i;
int flag.0;
:
.type = 0;
flag.0 = flag;
i = 0;
:;
candidate = reset () [return slot optimization];
if (flag.0 != 0) goto ; else goto ;
:;
= candidate;
:;
i = i + 1;
if (i != 2) goto ; else goto ;
:;
return ;
After tree-nrv, we have:
struct test candidate;
int i;
int flag.0;
:
.type = 0;
flag.0 = flag;
i = 0;
:;
= reset () [return slot optimization];
if (flag.0 != 0) goto ; else goto ;
:;
:;
i = i + 1;
if (i != 2) goto ; else goto ;
:;
return ;
The return value of reset has been redirected directly
into the return value slot of test, instead of the local
variable candidate. tree-nrv.c has some code that is
apparently intended to prevent this type of thing; I'm
not sure why that didn't work here.
The bug occurs (at least) in GCC 4.1.1 and current mainline.
--
Summary: tree-nrv optimization clobbers return variable
Product: gcc
Version: 4.1.0
Status: UNCONFIRMED
Keywords: wrong-code
Severity: normal
Priority: P3
Component: tree-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: uweigand at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30590
[Bug middle-end/30761] [4.1/4.2/4.3 regression] Error: unsupported relocation against sfp
--- Comment #4 from uweigand at gcc dot gnu dot org 2007-02-21 15:05 --- Subject: Bug 30761 Author: uweigand Date: Wed Feb 21 15:05:01 2007 New Revision: 122199 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=122199 Log: PR middle-end/30761 * reload1.c (eliminate_regs_in_insn): In the single_set special case, attempt to re-recognize the insn before falling back to having reload fix it up. Modified: trunk/gcc/ChangeLog trunk/gcc/reload1.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30761
[Bug middle-end/30761] [4.1/4.2 regression] Error: unsupported relocation against sfp
--- Comment #6 from uweigand at gcc dot gnu dot org 2007-03-12 19:34 --- I haven't verified that this problem is fixed -- the patch was originally intended to fix another bug uncovered by Peter Bergner, and I just added this PR number to the check-in due to Andrew's comment #3 on this bug. Andrew, have you verified that the problem is fixed now? I could backport the reload1.c change to 4.1/4.2 -- I haven't done so as there's always some risk associated with such backports, and it appeared from this bugzilla record that the bug was exposed only with a 4.3 change anyway. Was this impression mistaken? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30761
[Bug tree-optimization/30590] [4.1/4.2/4.3 Regression] tree-nrv optimization clobbers return variable
--- Comment #12 from uweigand at gcc dot gnu dot org 2007-03-14 15:26 --- This does fix my testcase on mainline. Thanks! -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30590
[Bug target/31641] [4.1/4.2/4.3 Regression] ICE in s390_expand_setmem, at config/s390/s390.c:3618
--- Comment #3 from uweigand at gcc dot gnu dot org 2007-04-23 14:51 --- I don't think the patch is correct; according to the C standard, the third argument of memset is of type size_t, which must be an *unsigned* type, so it cannot in fact be negative. What apparently happens is that the argument (after conversion to size_t) is so big that it appears to be negative in its representation as CONST_INT, so the assert in s390.c triggers. A proper fix would probably be to remove the assert in s390_expand_setmem and at the same time make sure those big sizes are handled correctly. (In any case, the testcase certainly is broken anyway.) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31641
[Bug middle-end/30761] [4.1/4.2 regression] Error: unsupported relocation against sfp
--- Comment #9 from uweigand at gcc dot gnu dot org 2007-04-26 22:10 --- Subject: Bug 30761 Author: uweigand Date: Thu Apr 26 22:10:09 2007 New Revision: 124199 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=124199 Log: PR middle-end/30761 * reload1.c (eliminate_regs_in_insn): In the single_set special case, attempt to re-recognize the insn before falling back to having reload fix it up. Modified: branches/gcc-4_2-branch/gcc/ChangeLog branches/gcc-4_2-branch/gcc/reload1.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30761
[Bug middle-end/30761] [4.1/4.2 regression] Error: unsupported relocation against sfp
--- Comment #10 from uweigand at gcc dot gnu dot org 2007-04-27 14:59 --- Subject: Bug 30761 Author: uweigand Date: Fri Apr 27 14:59:21 2007 New Revision: 124219 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=124219 Log: PR middle-end/30761 * reload1.c (eliminate_regs_in_insn): In the single_set special case, attempt to re-recognize the insn before falling back to having reload fix it up. Modified: branches/gcc-4_1-branch/gcc/ChangeLog branches/gcc-4_1-branch/gcc/reload1.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30761
[Bug middle-end/30761] [4.1/4.2 regression] Error: unsupported relocation against sfp
--- Comment #11 from uweigand at gcc dot gnu dot org 2007-04-27 15:03 --- (In reply to comment #8) > Ulrich, in response to your question in Comment #6, yes, this bug appears in > 4.1 and 4.2, not just in 4.3. So, if you think it's safe to backport the > reload patch, it would be nice to have the fix there as well. I've back-ported the fix to 4.2 and 4.1 now. -- uweigand at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30761
[Bug middle-end/32970] [4.3 Regression] C++ frontend can not handle vector pointer constant parameter
--- Comment #6 from uweigand at gcc dot gnu dot org 2007-08-12 23:35 --- Changing component to middle-end as the problem is not actually in the C++ front-end. -- uweigand at gcc dot gnu dot org changed: What|Removed |Added Component|c++ |middle-end http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32970
[Bug middle-end/32970] [4.3 Regression] C++ frontend can not handle vector pointer constant parameter
--- Comment #7 from uweigand at gcc dot gnu dot org 2007-08-12 23:43 --- Sa's patch isn't quite correct as it ignores the result of the build_qualified_type call. The following patch should fix that: diff -urNp toolchain/gcc.orig/gcc/tree.c toolchain/gcc/gcc/tree.c --- toolchain/gcc.orig/gcc/tree.c 2007-08-12 15:57:05.442520932 +0200 +++ toolchain/gcc/gcc/tree.c2007-08-12 16:07:42.516093968 +0200 @@ -6554,10 +6554,7 @@ reconstruct_complex_type (tree type, tre else return bottom; - TYPE_READONLY (outer) = TYPE_READONLY (type); - TYPE_VOLATILE (outer) = TYPE_VOLATILE (type); - - return outer; + return build_qualified_type (outer, TYPE_QUALS (type)); } /* Returns a vector tree node given a mode (integer, vector, or BLKmode) and -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32970
[Bug target/20054] [4.0 Regression] ICE in change_address_1
--- Additional Comments From uweigand at gcc dot gnu dot org 2005-02-18 17:42 --- I think the middle-end *should* allow back-ends to use SUBREGs in that way. cleanup_subreg_operands should really act only on SUBREGs that are part of an operand, and not on SUBREGs that are part of the invariant insn pattern. In any case, I'll try to reimplement the pattern in a different way. The problem is that it needs to have a form that combine will match ... -- What|Removed |Added AssignedTo|unassigned at gcc dot gnu |uweigand at gcc dot gnu dot |dot org |org Status|UNCONFIRMED |ASSIGNED Ever Confirmed||1 Last reconfirmed|-00-00 00:00:00 |2005-02-18 17:42:25 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20054
[Bug target/20054] [4.0 Regression] ICE in change_address_1
--- Additional Comments From uweigand at gcc dot gnu dot org 2005-02-18 18:45 --- OK, now I see the problem: cleanup_subreg_operands *does* indeed touch only operands. However, the result of the splitter matches the *llgt_didi insn instead of *llgt_disi, because after reload nonimmediate_operands matches a SUBREG (MEM). Thus the SUBREG is indeed part of the operand, which is broken. The proper fix is to move the *llgt_disi pattern to *before* the *llgt_didi pattern to ensure it matches first. I'll commit this fix once testing completes. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20054
[Bug ada/19140] ACATS c37402a segfaults at runtime
--- Additional Comments From uweigand at gcc dot gnu dot org 2005-02-18 19:01 --- This test case fails on s390(x) as well; in fact it is quite annoying because it causes the whole test suite to hang ... The reason for this appears to be that the Ada runtime has installed a segfault handler which attempts to take some lock already held by the code that segfaulted. As the Ada test suite doesn't have timeout handlers, this blocks the whole test suite :-( -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19140
[Bug target/20054] [4.0 Regression] ICE in change_address_1
--- Additional Comments From uweigand at gcc dot gnu dot org 2005-02-18 21:15 --- Fixed. -- What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20054
[Bug target/20054] [4.0 Regression] ICE in change_address_1
-- What|Removed |Added Target Milestone|--- |4.0.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20054
[Bug middle-end/20917] ICE in schedule_insns at sched-rg.c:2549
--- Additional Comments From uweigand at gcc dot gnu dot org 2005-04-09 16:09 --- I cannot reproduce the problem on today's GCC 4.0.0 version ... What is different for you? Do you have any patches on top? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20917
[Bug middle-end/20917] ICE in schedule_insns at sched-rg.c:2549
--- Additional Comments From uweigand at gcc dot gnu dot org 2005-04-09 16:16 --- D'oh. Ignore my previous post; I forgot that the 4.0 branch now defaults to checking disabled. I can indeed reproduce the problem, an am looking into it now ... -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20917
[Bug middle-end/20917] ICE in schedule_insns at sched-rg.c:2549
--- Additional Comments From uweigand at gcc dot gnu dot org 2005-04-09
18:26 ---
Here's a reduced test case:
extern void abort (void);
extern void **alloc (void);
void *test (void)
{
void **p = alloc ();
if (!p) abort ();
__builtin_set_thread_pointer (p);
return *p;
}
It would appear the __builtin_set_thread_pointer changes
on s390 for GCC 4.0 have uncovered a latent bug in regmove;
this pass now generates an invalid REG_DEAD note.
I don't want to change regmove for 4.0, but I've found a
back-end workaround which I'm currently testing ...
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20917
[Bug target/20927] [4.0/4.1 Regression] ICE in smallest_mode_for_size, at stor-layout.c:221 (s390x)
--- Additional Comments From uweigand at gcc dot gnu dot org 2005-04-11
19:40 ---
Reduced testcase:
struct point { double x, y; };
extern void use (struct point);
void test (struct point *pc, struct point p1)
{
struct point p0 = *pc;
if (p0.x == p1.x && p0.y == p1.y)
use (p0);
asm ("" : : : "0", "1", "2", "3", "4", "5", "6", "7", "8", "9", "10");
p1.y -= p0.y;
use (p0);
use (p1);
}
The problem is when reload tries to find an inheritance register for
Reload 0: reload_in (DF) = (subreg:DF (reg/v:TI 48 [ p0 ]) 8)
FP_REGS, RELOAD_FOR_INPUT (opnum = 1)
reload_in_reg: (subreg:DF (reg/v:TI 48 [ p0 ]) 8)
reload_reg_rtx: (reg:DF 24 %f8 [orig:45 p0$y ] [45])
because the code in choose_reload_regs tries to reload the inner REG
in a MODE_FLOAT mode of the same size as TImode, and such a mode does
not exist on s390 (the largest floating point mode is DFmode).
However, this shouldn't cause an ICE here; at worst the search for an
inheritance register should be omitted. Thus I guess the bug is for
choose_reload_regs to call smallest_mode_for_size in the first place.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20927
[Bug target/21041] [4.0 Regression] ICE: output_operand: Cannot decompose address
--- Additional Comments From uweigand at gcc dot gnu dot org 2005-04-16
15:48 ---
The problem originates in find_reloads_subreg_address, which decides
to widen access to a memory reference. The instruction we have is:
(insn 129 127 130 10 (parallel [
(set (reg:SI 106)
(plus:SI (subreg:SI (reg:QI 104) 0)
(subreg:SI (reg:QI 105) 0)))
(clobber (reg:CC 33 %cc))
]) 143 {addsi3} (insn_list:REG_DEP_TRUE 128 (insn_list:REG_DEP_TRUE 127
(nil)))
(expr_list:REG_DEAD (reg:QI 104)
(expr_list:REG_DEAD (reg:QI 105)
(expr_list:REG_UNUSED (reg:CC 33 %cc)
(nil)
and register 104 is equivalent to a memory slot:
(insn 127 128 129 10 (set (reg:QI 104)
(mem:QI (reg/f:SI 47 [ pretmp.10 ]) [0 S1 A8])) 53 {*movqi}
(insn_list:REG_DEP_TRUE 81 (insn_list:REG_DEP_TRUE 88 (insn_list:REG_DEP_TR
UE 95 (insn_list:REG_DEP_TRUE 102 (insn_list:REG_DEP_TRUE 109
(insn_list:REG_DEP_TRUE 116 (insn_list:REG_DEP_TRUE 123 (nil
(expr_list:REG_EQUIV (mem:QI (reg/f:SI 47 [ pretmp.10 ]) [0 S1 A8])
(nil)))
Now, reg 104 does not get a hard reg assigned. However, register 47 gets
assigned hard reg 0, which is not valid in a memory address.
Because register 104 is now equivalent to an invalid memory reference,
find_reloads_toplev calls find_reloads_subreg_address on the paradoxical
(subreg:SI (reg:QI 104)).
That routine thinks it can replace the subreg with an adjusted equivalent
memory reference (mem:SI (plus (reg 0) (const_int -3))).
It then calls find_reloads_address on that address. Now, this address
is invalid for *two* reasons: register 0 cannot be used as base register,
and negative displacements are invalid. find_reloads_address is unable
to cope with this combination, and returns with an address that is still
invalid.
[ If LEGITIMIZE_RELOAD_ADDRESS is active, it fixes the negative displacement
but keeps register 0. If I disable LEGITIMIZE_RELOAD_ADDRESS, the default
find_reloads_address behaviour will reload register 0, but keep the invalid
displacement. ]
As a workaround, I can add code to LEGITIMIZE_RELOAD_ADDRESS that fixes
both issues and results in a valid address, fixing the ICE. However, this
has two problems:
1. According to my understanding, L_R_A should never be required for
correctness, but only bring extra performance. Thus find_reloads_address
alone should also be able to fix the problem.
2. The whole business of widening access to a memory slot is questionable
in this case: if register 47 were to point to the start of a page of memory
preceded by unmapped address space, the widened access would crash. I had
thought that for this reason, only accesses to *stack slots* can be widened;
scan_paradoxical_subregs would make sure such stack slots are aligned
properly. However, in this case just some random memory access is widened.
As a final comment: both test cases in this PR are strictly speaking
invalid C or C++, because uninitialized variables are accessed. I was
unable to modify the test cases to valid C/C++. Does the original
unreduced source code also have uninitialized variables? There have
been some issues in the past where reload would handle uninitialized
pseudos correctly ...
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21041
[Bug target/36613] [4.2/4.3 Regression] likely codegen bug
--- Comment #15 from uweigand at gcc dot gnu dot org 2008-08-11 15:12 --- (In reply to comment #14) > Ulrich asked for some time on the trunk (we have built all of our > packages against a patched 4.3 tree now with no appearant problems as > well). OK, in that case I have no further concern. I'll leave it up to you as release manager to decide when you want it to go into 4.3 ... -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36613
[Bug bootstrap/37097] [4.4 Regression]: Revision 139014 failed to bootstrap
--- Comment #1 from uweigand at gcc dot gnu dot org 2008-08-12 14:37 --- Subject: Bug 37097 Author: uweigand Date: Tue Aug 12 14:35:54 2008 New Revision: 139019 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=139019 Log: PR bootstrap/37097 * builtins.c (do_mpfr_bessel_n): Fix copy-and-paste bug introduced by last change. -This line, and those below, will be ignored-- Mgcc/builtins.c Mgcc/ChangeLog Modified: trunk/gcc/ChangeLog trunk/gcc/builtins.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37097
[Bug bootstrap/37097] [4.4 Regression]: Revision 139014 failed to bootstrap
--- Comment #2 from uweigand at gcc dot gnu dot org 2008-08-12 14:45 --- Should be fixed now ... -- uweigand at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37097
[Bug target/38025] gcc.target/spu/intrinsics-1.c test fails
--- Comment #1 from uweigand at gcc dot gnu dot org 2008-11-05 18:04 --- The test case tests for expected failures. It seems there is now an additional message being output: /home/meissner/fsf-src/trunk/gcc/testsuite/gcc.target/spu/intrinsics-1.c:13: warning: passing argument 2 of __builtin_spu_cmpgt_11 makes integer from pointer without a cast /home/meissner/fsf-src/trunk/gcc/testsuite/gcc.target/spu/intrinsics-1.c:13: note: expected int but argument is of type int * The testcase checks for the "makes integer from pointer" error, but does not expect the additional "note". -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38025
[Bug target/34529] [4.1/4.2/4.3 Regression] Wrong code with altivec stores and offsets
--- Comment #11 from uweigand at gcc dot gnu dot org 2008-01-21 18:54 --- The secondary reload hook does not need to make the decision whether or not indexed addresses are allowed; that decision has already been taken. The purpose of the secondary reload hook is simply to do whatever it takes to load an indexed address into a base register (after reload has already decided that this address needs to be loaded). Reload does not allocate scratch registers always since it assumes that targets provide a "load address" instruction that it able to perform this operation without scratch register. You need the secondary reload to let common code know that this doesn't work on your target. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34529
[Bug target/35311] ICE at postreload.c:392 while building webkit on s390
--- Comment #4 from uweigand at gcc dot gnu dot org 2008-02-25 22:15 --- (In reply to comment #3) > This problem has already been fixed for GCC 4.3 (#34641). The testcase from > that PR didn't fail for GCC 4.2 so I didn't apply the patch on 4.2 as well. > But > now the patch should be fine for 4.2. I've verified that it fixes your > testcase. I agree this patch should go into 4.2 as well. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35311
[Bug rtl-optimization/34999] Fallthru crossing edges in partition_hot_cold_basic_blocks are not been fixed when the section ends with call insn
--- Comment #16 from uweigand at gcc dot gnu dot org 2008-03-04 14:51 --- Hi Jakub, we need the same changes in both .eh_frame and .dwarf_frame; does the gas .cfi_ support both sections? I'm wondering how "save & restore" should work across two different FDEs -- in the new FDE, we'd have to emit the full set of CFA instructions to get to the "base-line" state ... -- uweigand at gcc dot gnu dot org changed: What|Removed |Added CC||uweigand at de dot ibm dot ||com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34999
[Bug middle-end/38028] [4.4 Regression] eh failures on spu-elf
--- Comment #1 from uweigand at gcc dot gnu dot org 2009-03-07 16:02 --- Subject: Bug 38028 Author: uweigand Date: Sat Mar 7 16:02:30 2009 New Revision: 144696 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=144696 Log: PR middle-end/38028 * function.c (assign_parm_setup_stack): Use STACK_SLOT_ALIGNMENT to determine alignment passed to assign_stack_local. (assign_parms_unsplit_complex): Likewise. * except.c (sjlj_build_landing_pads): Likewise. Modified: trunk/gcc/ChangeLog trunk/gcc/except.c trunk/gcc/function.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38028
[Bug testsuite/39422] New: [4.4 regression] Failing SPU vectorizer testcases
The following two SPU test cases now fail on mainline (they pass on 4.3): FAIL: gcc.dg/vect/costmodel/spu/costmodel-vect-76b.c scan-tree-dump-times vect "vectorized 1 loops" 1 FAIL: gcc.dg/vect/costmodel/spu/costmodel-vect-76c.c scan-tree-dump-times vect "vectorized 1 loops" 1 -- Summary: [4.4 regression] Failing SPU vectorizer testcases Product: gcc Version: 4.4.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: testsuite AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: uweigand at gcc dot gnu dot org GCC target triplet: spu-elf http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39422
[Bug target/39181] [4.4 Regression] complex int arguments cause ICE
--- Comment #2 from uweigand at gcc dot gnu dot org 2009-03-12 14:00 --- Subject: Bug 39181 Author: uweigand Date: Thu Mar 12 14:00:21 2009 New Revision: 144811 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=144811 Log: PR target/39181 * config/spu/spu.c (spu_expand_mov): Handle invalid subregs of non-integer mode as well. Modified: trunk/gcc/ChangeLog trunk/gcc/config/spu/spu.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39181
[Bug target/39181] [4.4 Regression] complex int arguments cause ICE
--- Comment #3 from uweigand at gcc dot gnu dot org 2009-03-12 14:01 --- Fixed. -- uweigand at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39181
[Bug middle-end/38028] [4.4 Regression] eh failures on spu-elf
--- Comment #2 from uweigand at gcc dot gnu dot org 2009-03-12 14:02 --- Fixed. -- uweigand at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38028
[Bug fortran/39795] New: Support round-to-zero in Fortran front-end
On the SPU, all single-precision floating-point arithmetic always takes place in round-to-zero rounding mode. The Fortran front-end always assumes round-to-nearest mode. This causes a number of issues: - Both real->string and string->real transformations (e.g. printf, scanf) operate in round-to-zero mode. This means that a round-trip transform will often not yield an identical result; this causes e.g. the default_format_1.f90 test case to fail. It seems this cannot be fixed as the behaviour of printf and scanf is specified to follow round-to-zero on the SPU ... - As a special case of the real->string->real round-trip transform problem, the value of GFC_REAL_4_HUGE from the (generated) kinds.h does not convert to the largest real when read back in, but its immediate predecessor. This causes the scalar_mask_2.f90 test case to fail. This can be fixed by using rounding away from zero when generating the string constant that is written to the kinds.h file. - Compile-time operations performed by the Fortran front-end are always done in round-to-nearest mode. This results in different results as compared to executing the corresponding operations at run-time. This causes e.g. the integer_exponentiation_3.F90 test case to fail. This can be fixed by having the Fortran front-end check the target floating format rounding mode, and using this mode to perform compile-time operations in. -- Summary: Support round-to-zero in Fortran front-end Product: gcc Version: 4.5.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: uweigand at gcc dot gnu dot org GCC target triplet: spu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39795
[Bug target/41176] [4.4/4.5 Regression] ICE in reload_cse_simplify_operands at postreload.c:396
--- Comment #9 from uweigand at gcc dot gnu dot org 2009-10-08 18:39 --- (In reply to comment #8) > This is on (set (reg:DF X) (mem:DF ((plus:DI (reg:DI Y) (const_int 3. > When X is still a pseudo, this is considered valid, as lfd accept any offset, > but when RA chooses to assign X to a GPR register, the address doesn't match > the Y constraint in movdf_hardfloat64. Is this a bug in reload that it > doesn't > attempt to force the address into a register, or in target description that it > should tell reload to do so somehow? Or does the backend need to be able to > handle these, perhaps by forcing splitting of it? If reload were fixing up this insn, it would indeed have to make sure that the Y -> r constraints are respected, e.g. by reloading the address. However, this whole insn is *generated* by reload, in order to load a value into a reload register. Unfortunately, for such reload insns (which are simple moves), reload will simply assume they must be supported by the target, unless there is a secondary reload for this case. To fix this, I guess the rs6000 backend either has to accept the insn and implement it via splitting, or else register a secondary reload for this case (which is also able to request scratch registers). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41176
[Bug tree-optimization/41857] New: Loop optimizer breaks __ea pointers with -mea64
The following test case
__ea char *strchr_ea (__ea const char *s, int c);
__ea char *foo (__ea char *s)
{
__ea char *ret = s;
int i;
for (i = 0; i < 3; i++)
ret = strchr_ea (ret, s[i]);
return ret;
}
results in an ICE when compiled with -O -mea64.
The reason is that the loop optimizers use an induction variable
of type "long long int" to represent s+i, instead of using the
appropriate pointer type.
This causes rewrite_use_address to call create_mem_ref with an
affine expression none of whose subexpressions is of pointer type.
Therefore, the induction variable is assigned as the "index" of
a TARGET_MEM_REF, which means it gets converted to sizetype.
As sizetype is smaller than the __ea pointer type in the -ea64 case,
this means that value would be truncated. This is later caught by
an assertion in convert_memory_address, which causes the ICE.
Note that use of an integral induction variable was introduced as
part of the fix to PR tree-optimization/27865:
http://gcc.gnu.org/ml/gcc-patches/2006-08/msg00198.html
It seems to me it would be preferable to keep using pointer variables
where possible, even on platforms where sizetype is the same size as
pointers, in order to properly identify address base registers where
this makes a performance difference.
--
Summary: Loop optimizer breaks __ea pointers with -mea64
Product: gcc
Version: 4.5.0
Status: UNCONFIRMED
Keywords: ice-on-valid-code
Severity: normal
Priority: P3
Component: tree-optimization
AssignedTo: uweigand at gcc dot gnu dot org
ReportedBy: uweigand at gcc dot gnu dot org
GCC target triplet: spu-unknown-elf
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41857
[Bug tree-optimization/41857] Loop optimizer breaks __ea pointers with -mea64
--- Comment #1 from uweigand at gcc dot gnu dot org 2009-10-29 18:49 --- Proposed fix: http://gcc.gnu.org/ml/gcc-patches/2009-10/msg01757.html -- uweigand at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2009-10-29 18:49:20 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41857
[Bug tree-optimization/41857] Loop optimizer breaks __ea pointers with -mea64
--- Comment #2 from uweigand at gcc dot gnu dot org 2009-11-02 14:30 --- Subject: Bug 41857 Author: uweigand Date: Mon Nov 2 14:30:39 2009 New Revision: 153810 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=153810 Log: gcc/ PR tree-optimization/41857 * tree-flow.h (rewrite_use_address): Add BASE_HINT argument. * tree-ssa-loop-ivopts.c (rewrite_use_address): Pass base hint to create_mem_ref. * tree-ssa-address.c (move_hint_to_base): New function. (most_expensive_mult_to_index): Add TYPE argument. Use mode and address space associated with TYPE. (addr_to_parts): Add TYPE and BASE_HINT arguments. Pass TYPE to most_expensive_mult_to_index. Call move_hint_to_base. (create_mem_ref): Add BASE_HINT argument. Pass BASE_HINT and TYPE to addr_to_parts. gcc/testsuite/ PR tree-optimization/41857 * gcc.target/spu/ea/pr41857.c: New file. Added: trunk/gcc/testsuite/gcc.target/spu/ea/pr41857.c Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/tree-flow.h trunk/gcc/tree-ssa-address.c trunk/gcc/tree-ssa-loop-ivopts.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41857
[Bug tree-optimization/41857] Loop optimizer breaks __ea pointers with -mea64
--- Comment #3 from uweigand at gcc dot gnu dot org 2009-11-02 14:35 --- Fixed. -- uweigand at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41857
[Bug tree-optimization/41857] Loop optimizer breaks __ea pointers with -mea64
--- Comment #4 from uweigand at gcc dot gnu dot org 2009-11-17 16:22 --- Subject: Bug 41857 Author: uweigand Date: Tue Nov 17 16:21:56 2009 New Revision: 154255 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=154255 Log: PR tree-optimization/41857 * tree-ssa-address.c (move_hint_to_base): Use void pointer to TYPE's address space instead of pointer to TYPE. Modified: trunk/gcc/ChangeLog trunk/gcc/tree-ssa-address.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41857
[Bug libgcj/24051] [4.1 Regression]: libjava failed to configure
--- Additional Comments From uweigand at gcc dot gnu dot org 2005-09-28 22:09 --- Same problem on s390(x)-ibm-linux. B.t.w. isn't the real problem that the CXX that comes out of the configure machinery is simply incorrect? I.e. it should be something like "xgcc -x c++" instead of just "xgcc" ... However, I don't follow the configure machinery enough to understand why this comes about, sorry. -- What|Removed |Added CC| |uweigand at gcc dot gnu dot | |org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24051
[Bug ada/19382] ACATS cxb4005 cxb5002 simple To_COBOL/To_Fortran test fails at runtime on s390-linux
--- Additional Comments From uweigand at gcc dot gnu dot org 2005-09-29 23:52 --- I've found some time to look a bit more into this. First of all, here's a much reduced test case: procedure CXB4005 is type Alphanumeric is array (Positive range <>) of Character; TC_Alphanumeric : Alphanumeric(1..1); begin TC_Alphanumeric := "A"; pragma Assert (TC_Alphanumeric = "A"); end CXB4005; The assertion fails when built with -O2 -gnata. The comparsion TC_Alphanumeric = "A" gets translated by the front end into this tree (02.original): if (VIEW_CONVERT_EXPR(tc_alphanumeric) != "A") which get gimplified into (03.generic): tc_alphanumeric.0 = (character[1:1] *) &tc_alphanumeric; tc_alphanumeric.1 = (const *) tc_alphanumeric.0; D.388 = *tc_alphanumeric.1; D.389 = (integer) D.388; D.390 = (const *) "A"; D.391 = *D.390; D.392 = (integer) D.391; D.393 = D.389 - D.392; if (D.393 != 0) This transformation happens because an NE_EXPR of array types is handled by gimplify_variable_sized_compare, which converts it into an implicit call to memcmp. This call (with length 1) is then transformed by fold_builtin_memcmp into the computation of the difference of the two bytes. This is done in fold_builtin_memcpy by casting the addresses to an 'const unsigned char *' and dereferencing that expression, where that type is constructed as a variant of the predefined unsigned_char_type_node. (This type shows up in the above listings as 'const *'.) Now, when the so-casted expression is dereferenced, we obviously get into aliasing issues. This works fine in C-based languages, because there 'unsigned char' is explicitly allowed to alias any other type -- the fold_builtin_memcpy code is correct really only when making that assumption. However, in Ada there is no such special case, and the Ada hook for get_alias_set does not handle unsigned_char_type_node at all. Thus the type gets assigned a fresh alias set (that aliases nothing at all since the type didn't otherwise occur). I guess this is really a bug in fold_builtin_memcpy, but I'm not sure what exactly the proper fix would be. As a workaround, I've added the "C-style" treatment of 'char' to the Ada get_alias_set, and this fixes the symptom as well. The patch for this is: Index: gcc/ada/misc.c === RCS file: /cvs/gcc/gcc/gcc/ada/misc.c,v retrieving revision 1.106 diff -c -p -r1.106 misc.c *** gcc/ada/misc.c 4 Jul 2005 13:27:09 - 1.106 --- gcc/ada/misc.c 29 Sep 2005 23:34:18 - *** gnat_get_alias_set (tree type) *** 713,718 --- 713,725 return get_alias_set (TREE_TYPE (TREE_TYPE (TYPE_FIELDS (TREE_TYPE (type); + /* ??? The middle end occasionally generates 'char' types by itself + and implicitly assumes they are allowed to alias everything. One + example is fold_builtin_memcmp, causing PR 19382. */ + if (type == char_type_node + || type == signed_char_type_node + || type == unsigned_char_type_node) + return 0; return -1; } -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19382
[Bug target/24600] [4.1 Regression] unrecognizable instruction
--- Comment #4 from uweigand at gcc dot gnu dot org 2005-11-01 21:53 --- This is a bug in the old loop optimizer introduced by: http://gcc.gnu.org/ml/gcc-patches/2005-03/msg00690.html The problem with this patch is that it assumes gen_move_insn where the source is a PLUS representing an address always returns a valid instruction. This is not the case at least on s390. -- uweigand at gcc dot gnu dot org changed: What|Removed |Added CC||uweigand at gcc dot gnu dot ||org Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2005-11-01 21:53:05 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24600
[Bug target/24600] [4.1 Regression] unrecognizable instruction
--- Comment #5 from uweigand at gcc dot gnu dot org 2005-11-01 21:54 --- Created an attachment (id=10106) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10106&action=view) Possible fix (not yet tested) This patch is a possible fix to the problem; it works by using force_operand to make sure the address can be loaded correctly. (Patch not yet tested.) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24600
[Bug target/24615] [4.1 Regression] internal compiler error: in print_shift_count_operand, at config/s390/s390.c:4025
--- Comment #3 from uweigand at gcc dot gnu dot org 2005-11-01 21:56 --- What command line options? I cannot reproduce an ICE with the usual sets of options ... -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24615
[Bug target/24600] [4.1 Regression] unrecognizable instruction
--- Comment #6 from uweigand at gcc dot gnu dot org 2005-11-02 16:22 --- Tested patch in: http://gcc.gnu.org/ml/gcc-patches/2005-11/msg00113.html -- uweigand at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |uweigand at gcc dot gnu dot |dot org |org URL||http://gcc.gnu.org/ml/gcc- ||patches/2005- ||11/msg00113.html Status|NEW |ASSIGNED Keywords||patch Last reconfirmed|2005-11-01 21:53:05 |2005-11-02 16:22:35 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24600
[Bug target/24615] [4.1 Regression] internal compiler error: in print_shift_count_operand, at config/s390/s390.c:4025
--- Comment #5 from uweigand at gcc dot gnu dot org 2005-11-02 16:32 --- Confirmed. Looks like a backend problem, I'm working on it. -- uweigand at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |uweigand at gcc dot gnu dot |dot org |org Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2005-11-02 16:32:31 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24615
[Bug target/24620] [4.1 Regression] internal compiler error: in find_reloads, at reload.c:3730
--- Comment #2 from uweigand at gcc dot gnu dot org 2005-11-02 20:27 --- Clearly a backend bug. Working on it ... -- uweigand at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |uweigand at gcc dot gnu dot |dot org |org Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2005-11-02 20:27:44 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24620
[Bug target/24600] [4.1 Regression] unrecognizable instruction
--- Comment #7 from uweigand at gcc dot gnu dot org 2005-11-02 23:06 --- Subject: Bug 24600 Author: uweigand Date: Wed Nov 2 23:06:26 2005 New Revision: 106404 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=106404 Log: ChangeLog: PR target/24600 * loop.c (loop_givs_rescan): Use force_operand to expand complex GIVs. testsuite/ChangeLog: PR target/24600 * gcc.dg/pr24600.c: New test. Added: trunk/gcc/testsuite/gcc.dg/pr24600.c Modified: trunk/gcc/ChangeLog trunk/gcc/loop.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24600
[Bug target/24600] [4.1 Regression] unrecognizable instruction
--- Comment #8 from uweigand at gcc dot gnu dot org 2005-11-02 23:09 --- Fixed. -- uweigand at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24600
[Bug target/24615] [4.1 Regression] internal compiler error: in print_shift_count_operand, at config/s390/s390.c:4025
--- Comment #7 from uweigand at gcc dot gnu dot org 2005-11-02 23:16
---
Subject: Bug 24615
Author: uweigand
Date: Wed Nov 2 23:16:31 2005
New Revision: 106405
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=106405
Log:
ChangeLog:
PR target/24615
* config/s390/s390-protos.h (s390_decompose_shift_count): Declare.
* config/s390/s390.c (s390_decompose_shift_count): New function.
(s390_extra_constraint_str) ['Y']: Use s390_decompose_shift_count.
(print_shift_count_operand): Use s390_decompose_shift_count.
* config/s390/predicates.md ("setmem_operand", "shift_count_operand"):
Use s390_decompose_shift_count. Do not accept any non-base hard regs.
testsuite/ChangeLog:
PR target/24615
* gcc.dg/pr24615.c: New test.
Added:
trunk/gcc/testsuite/gcc.dg/pr24615.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/s390/predicates.md
trunk/gcc/config/s390/s390-protos.h
trunk/gcc/config/s390/s390.c
trunk/gcc/testsuite/ChangeLog
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24615
[Bug target/24615] [4.1 Regression] internal compiler error: in print_shift_count_operand, at config/s390/s390.c:4025
--- Comment #8 from uweigand at gcc dot gnu dot org 2005-11-02 23:18 --- Fixed. -- uweigand at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24615
[Bug target/24623] [4.1 Regression] internal compiler error: in propagate_one_insn, at flow.c:1702
--- Comment #3 from uweigand at gcc dot gnu dot org 2005-11-03 02:04 --- Likely backend problem, investigating ... -- uweigand at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |uweigand at gcc dot gnu dot |dot org |org Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2005-11-03 02:04:13 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24623
[Bug target/24624] [4.1 Regression] internal compiler error: in reload, at reload1.c:1071
--- Comment #3 from uweigand at gcc dot gnu dot org 2005-11-03 02:04 --- Likely backend problem, investigating ... -- uweigand at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |uweigand at gcc dot gnu dot |dot org |org Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2005-11-03 02:04:45 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24624
[Bug target/24620] [4.1 Regression] internal compiler error: in find_reloads, at reload.c:3730
--- Comment #4 from uweigand at gcc dot gnu dot org 2005-11-03 04:16
---
Subject: Bug 24620
Author: uweigand
Date: Thu Nov 3 04:16:52 2005
New Revision: 106422
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=106422
Log:
ChangeLog:
PR target/24620
* config/s390/s390.md ("*insv_reg_imm"): Accept any CONST_INT
as operand 2.
("*insv_reg_extimm"): Likewise.
testsuite/ChangeLog:
PR target/24620
* gcc.dg/pr24620.c: New test.
Added:
trunk/gcc/testsuite/gcc.dg/pr24620.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/s390/s390.md
trunk/gcc/testsuite/ChangeLog
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24620
[Bug target/24620] [4.1 Regression] internal compiler error: in find_reloads, at reload.c:3730
--- Comment #5 from uweigand at gcc dot gnu dot org 2005-11-03 04:19 --- Fixed. -- uweigand at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24620
[Bug target/24621] [4.1 Regression] internal compiler error: in reload_cse_simplify_operands, at postreload.c:393
--- Comment #4 from uweigand at gcc dot gnu dot org 2005-11-03 18:40 --- This looks like a reload problem related to the one I fixed here: http://gcc.gnu.org/ml/gcc-patches/2004-10/msg01133.html I'm currently testing a fix ... -- uweigand at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |uweigand at gcc dot gnu dot |dot org |org Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2005-11-03 18:40:37 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24621
[Bug target/41176] [4.4/4.5 Regression] ICE in reload_cse_simplify_operands at postreload.c:396
--- Comment #11 from uweigand at gcc dot gnu dot org 2010-03-02 19:56 --- (In reply to comment #10) > I don't see where reload is creating the whole instruction; maybe I am > misunderstanding that statement. Well, after reload you have insn 624, which presumably didn't exist before. This was inserted by reload before the (original) insn 218 -- you didn't show the fixed-up version of insn 218 after reload, but I'm assuming it's probably a register-to-register (or -to-memory) move from the reload register (reg:DF 21) into whatever the register allocator has chosen to hold (reg/v:DF 203). The new insn 624 is not in any way a "fixed up" version of insn 218. Instead, it is a reload insn that was generated by reload to load some value (in this case the (mem:DF ...)) into some reload register. (That this happens to look similar to insn 218 before reload is just a coincidence.) As I mentioned, reload by default assumes that any move of any legitimate operand into any register is always valid and can by performed by a simple set. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41176
[Bug middle-end/43292] Bogus TYPE_ADDR_SPACE access
--- Comment #1 from uweigand at gcc dot gnu dot org 2010-03-08 16:11 --- Why doesn't this make sense? The address space is a property of the pointed-to type, not the pointer type itself (just like const/volatile-ness) ... -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43292
[Bug ada/19381] ACATS c954a03 raises storage error at runtime on s390-linux
--- Additional Comments From uweigand at gcc dot gnu dot org 2005-07-04 12:45 --- I don't see it failing on the 4.0 branch. I haven't been able to build mainline Ada for several months now ... -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19381
