[Bug middle-end/27536] [4.2 Regression] -fsection-anchors breaks Ada
--- Comment #5 from richard at codesourcery dot com 2006-05-11 15:56 --- Subject: Re: [4.2 Regression] -fsection-anchors breaks Ada "dje at gcc dot gnu dot org" <[EMAIL PROTECTED]> writes: > It looks like something in exception handling is creating a new object > very late, after reload, and the new address is not validized before > being handed to replace_equiv_address(). > > Should explow.c:use_anchored_address() add > > if (reload_in_progress || reload_completed) > return x; > > Either the block should not be created so late or it should be validized. > Although, I am curious how this works in expand_expr_real_1 when section > anchors is not enabled. I find this a little surprising too. Could someone do: call debug_tree (...) on the type that output_ttype is trying to expand? Richard -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27536
[Bug middle-end/27536] [4.2 Regression] -fsection-anchors breaks Ada
--- Comment #7 from richard at codesourcery dot com 2006-05-11 16:18 --- Subject: Re: [4.2 Regression] -fsection-anchors breaks Ada Thanks Andreas. I might be barking up the wrong tree here, but it seems odd to me is that output_ttype is using expand_normal () to expand this tree. That in general allows arbitrary code to be generated. output_ttype does seem to want an assembly constant. Shouldn't it be using EXPAND_INITIALIZER instead? Richard -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27536
[Bug target/27770] [4.2 Regression] wrong code in spec tests for -ftree-vectorize -maltivec
--- Comment #9 from richard at codesourcery dot com 2006-06-06 15:02
---
Subject: Re: [4.2 Regression] wrong code in spec tests for -ftree-vectorize
-maltivec
"pinskia at gcc dot gnu dot org" <[EMAIL PROTECTED]> writes:
> What about instead of absolute numbers doing label subtraction for
> section anchors and then we can defer the decision for the layout of
> the section until after all functions are done compiling?
I don't think symbolic offsets would work, if that's what you mean.
We need to know the constant offset so that (a) we can enforce
TARGET_{MIN,MAX}_ANCHOR_OFFSET (which is more important for other
targets than it is for PowerPC) and (b) we know for PowerPC-like
setups whether the offset needs an addis.
Richard
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27770
[Bug target/27770] [4.2 Regression] wrong code in spec tests for -ftree-vectorize -maltivec
--- Comment #11 from richard at codesourcery dot com 2006-06-06 15:16 --- Subject: Re: [4.2 Regression] wrong code in spec tests for -ftree-vectorize -maltivec "dje at gcc dot gnu dot org" <[EMAIL PROTECTED]> writes: > The auto-vectorizer is a Tree-SSA pass. The section anchors are an > RTL pass. I do not understand why the alignment of the vectorized > variables is not known at section anchor creation time. The rtl optimisations for bar() precede the tree optimisations for foo(). Richard -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27770
[Bug target/27770] [4.2 Regression] wrong code in spec tests for -ftree-vectorize -maltivec
--- Comment #14 from richard at codesourcery dot com 2006-06-06 15:53 --- Subject: Re: [4.2 Regression] wrong code in spec tests for -ftree-vectorize -maltivec "dje at gcc dot gnu dot org" <[EMAIL PROTECTED]> writes: > We're performing the auto-vectorization in unit-at-a-time-mode, so > maybe we need to recompile the other functions. It seems that we're > going to encounter more problems along these lines with LTO. Well, I'm not convinced recompilation is the way to go. I can't imagine it scaling well in pathological cases. If we're talking about long-term fixes, I think we should just make sure that we vectorise all functions before applying rtl optimisations to any of them. But that's all moot anyway: either approach will take a long time to implement. (Note that, as things stand, we've already written out the asm code for bar() by the time we vectorise foo().) As far as 4.2 fixes go, does anyone disagree with my earlier comment? Richard -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27770
[Bug middle-end/27770] [4.2 Regression] wrong code in spec tests for -ftree-vectorize -maltivec
--- Comment #18 from richard at codesourcery dot com 2006-07-02 13:39 --- Subject: Re: [4.2 Regression] wrong code in spec tests for -ftree-vectorize -maltivec "hubicka at gcc dot gnu dot org" <[EMAIL PROTECTED]> writes: > Increasing alignment of static variable during tree optimization should be as > easy as increasing the DECL_ALIGN. All variables are output after all > functions. This is what already happens. The problem is _when_ it happens. In the testcase, we first compile a simple function that has no vectorisable parts. The function accesses a variable and we decide to use section anchors to address it. We therefore place the variable in the section based on its current DECL_ALIGN. We then compile a different function that has vectorisable accesses to the same variable. We increase the variable's DECL_ALIGN accordingly. This new DECL_ALIGN throws off the assumptions made for the first function. The fix we've agreed is best in principle is to speculatively increase the DECL_ALIGN of vectorisable variables before compiling functions. Dorit says that there is a patch related to this on the autovect branch, which I'll look at when I get back from Ottawa. Richard -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27770
[Bug libstdc++/27878] GCC 4.1.1 build fails on mips-sgi-irix6.5 (libstdc++)/GCC 4.1.0 worked.
--- Comment #25 from richard at codesourcery dot com 2006-07-12 06:32
---
Subject: Re: GCC 4.1.1 build fails on mips-sgi-irix6.5 (libstdc++)/GCC 4.1.0
worked.
"pcarlini at suse dot de" <[EMAIL PROTECTED]> writes:
> Thanks Rainer and Eric. Then, since we have a workaround in place for
> the issue (--disable-wchar_t) and apparently it affects only very old
> ("broken" as far as such features are concerned) releases of the OS,
> I'm inclined to close this PR as WONTFIX. Any objections? I will go
> ahead in a few days...
Sounds good to me.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27878
[Bug target/27681] [4.1 regression] Missing DImode float conversion functions with -msoft-float
--- Comment #5 from richard at codesourcery dot com 2006-07-24 06:03 --- Subject: Re: [4.1 regression] Missing DImode float conversion functions with -msoft-float "echristo at apple dot com" <[EMAIL PROTECTED]> writes: > I doubt we're going to backport that patch to 4.1 at all, should we > just close this bug? I hope we're going to backport it ;) It's on my to-do list. Richard -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27681
[Bug rtl-optimization/32557] [4.3 Regression] internal compiler error: RTL check: expected code 'reg', have 'subreg' in rhs_regno, at rtl.h:956
--- Comment #6 from richard at codesourcery dot com 2007-08-20 09:40 --- Subject: Re: [4.3 Regression] internal compiler error: RTL check: expected code 'reg', have 'subreg' in rhs_regno, at rtl.h:956 "bonzini at gnu dot org" <[EMAIL PROTECTED]> writes: > --- Comment #5 from bonzini at gnu dot org 2007-08-20 07:11 --- > Richard, is this the issue you had a patch for? Well, the patch I had has already been committed: 2007-07-27 Richard Sandiford <[EMAIL PROTECTED]> * df.h (df_mw_hardreg): Remove "loc" field. * df-scan.c (df_ref_record): Don't set it. Remove redundant local variable. * df-problems.c (df_whole_mw_reg_unused_p): New function, split out from df_set_unused_notes_for_mw. Return false for partial references. Assert that mw_reg is a REG when returning true. (df_set_unused_notes_for_mw): Use it. Use mw_reg instead of *loc. (df_whole_mw_reg_dead_p): New function, split out from df_set_dead_notes_for_mw. Return false for partial references. Assert that mw_reg is a REG when returning true. (df_set_dead_notes_for_mw): Use it. Use mw_reg instead of *loc. Remove redundant bitmap check. Is this a regression from then? Richard -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32557
[Bug target/33256] internal compiler error: in print_operand_reloc, at config/mips/mips.c:5579
--- Comment #14 from richard at codesourcery dot com 2007-09-05 21:08
---
Subject: Re: internal compiler error: in print_operand_reloc, at
config/mips/mips.c:5579
"ddaney at avtrex dot com" <[EMAIL PROTECTED]> writes:
>> I've not forced -EB because that fails for -EL
>> multilibs, and we want this test to work for both anyway.)
>>
> Are you sure? On the trunk I tested on mipsel-linux with -EB and it
> seems to work. For a compile only test it should work on little-endian
> system.
I mean that it fails if you explicitly test -EL multilibs. E.g. on
mipsisa64-elf, I normally test "mips-sim{,-msoft-float}{-EB,-EL}", and
the compiler will complain at having both -EL and -EB on the command line.
We could make mips.exp skip the test when -EL is forced, but it seems
more useful to run it regardless. Or we could use target selectors to
select between two dg-mips-options lines depending on whether -EL has
been added to the multilib flags. However, it seems odd to test
big-endian (only) on little-endian systems when -EL is not explicitly
given, but test little-endian when -EL _is_ explicitly (and redundantly)
given.
Richard
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33256
[Bug target/33256] internal compiler error: in print_operand_reloc, at config/mips/mips.c:5579
--- Comment #16 from richard at codesourcery dot com 2007-09-05 21:22 --- Subject: Re: internal compiler error: in print_operand_reloc, at config/mips/mips.c:5579 "ddaney at avtrex dot com" <[EMAIL PROTECTED]> writes: > My concern was that the bug only occurs for me with -EB, so running the > test case with -EL would be pointless. I understand that you do most of > your testing on the simulator, but for someone doing testing on little > endian hardware there is no coverage without the -EB. OK. As I said before, I didn't think it would be pointless, because we do want to make sure this continues to work for -EL too. (There's generally very little coverage of -mabi=64 -msym32; the only user I know of is linux.) However, I'll yield and make mips.exp skip the test when running explicitly-EL multilibs. Richard -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33256
[Bug target/33256] internal compiler error: in print_operand_reloc, at config/mips/mips.c:5579
--- Comment #18 from richard at codesourcery dot com 2007-09-05 21:44
---
Subject: Re: internal compiler error: in print_operand_reloc, at
config/mips/mips.c:5579
"ddaney at avtrex dot com" <[EMAIL PROTECTED]> writes:
> richard at codesourcery dot com wrote:
>> --- Comment #16 from richard at codesourcery dot com 2007-09-05 21:22
>> ---
>> Subject: Re: internal compiler error: in print_operand_reloc, at
>> config/mips/mips.c:5579
>>
>> "ddaney at avtrex dot com" <[EMAIL PROTECTED]> writes:
>>> My concern was that the bug only occurs for me with -EB, so running the
>>> test case with -EL would be pointless. I understand that you do most of
>>> your testing on the simulator, but for someone doing testing on little
>>> endian hardware there is no coverage without the -EB.
>>
>> OK. As I said before, I didn't think it would be pointless, because
>> we do want to make sure this continues to work for -EL too.
>
> The only time loading the low order bits of a word is done at an offset
> from the base of the word is in big endian. So I don't think it will
> ever fail on a little endian system, but I may be missing something.
Yes, I realise that, but I meant that you can't really assume very much
about -mabi=64 -msym32 -EL at all from a mips{64,}{,-el}-linux-gnu run.
At least allowing the test to be run in little-endian would have provided
some coverage, and people were still going to notice if the -EB case
regressed.
Richard
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33256
[Bug target/31975] [4.3 Regression] segfault in try_split on mips during bootstrap
--- Comment #15 from richard at codesourcery dot com 2007-05-25 14:13 --- Subject: Re: [4.3 Regression] segfault in try_split on mips during bootstrap David, msny thanks for looking at this. "pinskia at gcc dot gnu dot org" <[EMAIL PROTECTED]> writes: > RS6000, ia64, and sh does this: > /* Mark the end of the (empty) prologue. */ > emit_note (NOTE_INSN_PROLOGUE_END); > > You might want to use that note also for MIPS. Agreed. I suppose it's slightly more self-documenting than NOTE_INSN_DELETED, and it's good to be consistent with other ports. David, FWIW, a patch to add those two lines is pre-approved. If you've already tested the NOTE_INSN_DELETED version, don't feel you need to test the whole thing again with the other note; as long as cc1 compiles, that's fine. Richard -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31975
[Bug target/32406] [4.3 Regression] MIPS: FAIL in nestfunc-6.c at -O3
--- Comment #3 from richard at codesourcery dot com 2007-06-20 12:56 --- Subject: Re: [4.3 Regression] MIPS: FAIL in nestfunc-6.c at -O3 "daney at gcc dot gnu dot org" <[EMAIL PROTECTED]> writes: > I don't really like the patch that much though. It forces $gp to be > loaded in a nonlocal_goto_receiver, which fixes the bug in cases where > $gp is needed. If $gp is not needed, it would be nice not to force it > to be restored. > > In vain I tried to mark $gp as clobbered in hope that it would be > magically restored if needed. I guess I need a bit more RTL foo. If > there are two function calls in the nonlocal goto target (two uses of > $gp with a clobber between), the second call has $gp restored. I > think there should be a way to make the first use of $gp to cause $gp > to be restored, but I don't know what it is. The post-reload splitter converts the unspec_volatile into an ordinary move. In theory (TM), if the restore isn't needed, it should get deleted as dead after that point. Stepping back, the model here is that anything up to and including the post-reload splitters can introduce new uses of pic_offset_table_rtx. (This includes reload, which might need new uses of pic_offset_table_rtx in order to access the constant pool. It also includes high/lo_sum accesses that we previously modelled as being purely symbolic; this higher-level, register-free form is easier to optimise.) So we basically consider $gp to be live throughout the function before the post-reload splitters. At that point, when using explicit relocs, every use of $gp becomes explicit, and normal liveness rules apply. Do you have an example of a function that does need $gp at some point, but which restores $gp unnecessarily at other points? I suppose there will be cases where a function with a nonlocal goto doesn't need $gp at all, but sets $gp up anyway because of the set in the receiver pattern. I can think of a way of dealing with that, but it will mean adding special cases. I wonder how often it would trigger. Richard -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32406
[Bug target/32437] [4.3 Regression] MIPS: FAIL in gcc.dg/cleanup-[8|9|10|11].c
--- Comment #19 from richard at codesourcery dot com 2007-06-27 14:37
---
Subject: Re: [4.3 Regression] MIPS: FAIL in gcc.dg/cleanup-[8|9|10|11].c
Kenneth Zadeck <[EMAIL PROTECTED]> writes:
> 2007-06-23 Kenneth Zadeck <[EMAIL PROTECTED]>
>
> PR middle-end/32437
> *dce.c (deletable_insn_p): Add extra parameter and recurse if insn
> is a PARALLEL.
> (prescan_insns_for_dce): Add extra parameter.
Kenny found that this patch introduced problems on x86 (I think it was)
because it applied the special handling for bare CLOBBERs to those
inside PARALLELs as well. We don't want that; bare USEs and CLOBBERs
are special DF markers, but USEs and CLOBBERs inside PARALLELs are parts
of asms or define_insns.
Kenny pre-approved the patch below. Bootstrapped & regression-tested
on x86_64-linux-gnu. Applied to mainline.
Richard
gcc/
* dce.c (deletable_insn_p_1): New function, split out from...
(deletable_insn_p): ...here. Only treat bare USEs and CLOBBERs
specially, not those inside PARALLELs. Remove BODY argument
and adjust recursive call accordingly.
(prescan_insns_for_dce): Update call to delete_insn_p.
Index: gcc/dce.c
===
--- gcc/dce.c (revision 126053)
+++ gcc/dce.c (working copy)
@@ -58,16 +58,15 @@ static VEC(rtx,heap) *worklist;
static sbitmap marked = NULL;
-/* Return true if INSN with BODY is a normal instruction that can be
- deleted by the DCE pass. */
+/* A subroutine for which BODY is part of the instruction being tested;
+ either the top-level pattern, or an element of a PARALLEL. The
+ instruction is known not to be a bare USE or CLOBBER. */
static bool
-deletable_insn_p (rtx insn, rtx body, bool fast)
+deletable_insn_p_1 (rtx body)
{
- rtx x;
switch (GET_CODE (body))
{
-case USE:
case PREFETCH:
case TRAP_IF:
/* The UNSPEC case was added here because the ia-64 claims that
@@ -79,6 +78,35 @@ deletable_insn_p (rtx insn, rtx body, bo
case UNSPEC:
return false;
+default:
+ if (volatile_insn_p (body))
+ return false;
+
+ if (flag_non_call_exceptions && may_trap_p (body))
+ return false;
+
+ return true;
+}
+}
+
+/* Return true if INSN is a normal instruction that can be deleted by
+ the DCE pass. */
+
+static bool
+deletable_insn_p (rtx insn, bool fast)
+{
+ rtx body, x;
+ int i;
+
+ if (!NONJUMP_INSN_P (insn))
+return false;
+
+ body = PATTERN (insn);
+ switch (GET_CODE (body))
+{
+case USE:
+ return false;
+
case CLOBBER:
if (fast)
{
@@ -88,32 +116,20 @@ deletable_insn_p (rtx insn, rtx body, bo
x = XEXP (body, 0);
return REG_P (x) && (!HARD_REGISTER_P (x) || reload_completed);
}
- else
+ else
/* Because of the way that use-def chains are built, it is not
possible to tell if the clobber is dead because it can
never be the target of a use-def chain. */
return false;
case PARALLEL:
- {
- int i;
- for (i = XVECLEN (body, 0) - 1; i >= 0; i--)
- if (!deletable_insn_p (insn, XVECEXP (body, 0, i), fast))
- return false;
- return true;
- }
+ for (i = XVECLEN (body, 0) - 1; i >= 0; i--)
+ if (!deletable_insn_p_1 (XVECEXP (body, 0, i)))
+ return false;
+ return true;
default:
- if (!NONJUMP_INSN_P (insn))
- return false;
-
- if (volatile_insn_p (body))
- return false;
-
- if (flag_non_call_exceptions && may_trap_p (body))
- return false;
-
- return true;
+ return deletable_insn_p_1 (body);
}
}
@@ -369,7 +385,7 @@ prescan_insns_for_dce (bool fast)
rtx note = find_reg_note (insn, REG_LIBCALL_ID, NULL_RTX);
if (note)
mark_libcall (insn, fast);
-else if (deletable_insn_p (insn, PATTERN (insn), fast))
+else if (deletable_insn_p (insn, fast))
mark_nonreg_stores (PATTERN (insn), insn, fast);
else
mark_insn (insn, fast);
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32437
[Bug rtl-optimization/32475] [4.3 Regression] function with asm() does not setup stack frame
--- Comment #11 from richard at codesourcery dot com 2007-06-30 12:19 --- Subject: Re: [4.3 Regression] function with asm() does not setup stack frame "zadeck at naturalbridge dot com" <[EMAIL PROTECTED]> writes: > Could you check to see if this bug is collateral damage from your > latest fix to deletable_insn_p. It's appearance has been tied to that > function in the past. _My_ latest fix to deletable_insn_p? ;) All I did was rephrase your patch in terms of deletable_insn_p_1. I won't have time to work on this in the near future, so I'll just revert the patch for now. Richard -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32475
[Bug target/32437] [4.3 Regression] MIPS: FAIL in gcc.dg/cleanup-[8|9|10|11].c
--- Comment #21 from richard at codesourcery dot com 2007-06-30 12:26 --- Subject: Re: [4.3 Regression] MIPS: FAIL in gcc.dg/cleanup-[8|9|10|11].c Richard Sandiford <[EMAIL PROTECTED]> writes: > Kenneth Zadeck <[EMAIL PROTECTED]> writes: >> 2007-06-23 Kenneth Zadeck <[EMAIL PROTECTED]> >> >> PR middle-end/32437 >> *dce.c (deletable_insn_p): Add extra parameter and recurse if insn >> is a PARALLEL. >> (prescan_insns_for_dce): Add extra parameter. > > Kenny found that this patch introduced problems on x86 (I think it was) > because it applied the special handling for bare CLOBBERs to those > inside PARALLELs as well. We don't want that; bare USEs and CLOBBERs > are special DF markers, but USEs and CLOBBERs inside PARALLELs are parts > of asms or define_insns. > > Kenny pre-approved the patch below. Bootstrapped & regression-tested > on x86_64-linux-gnu. Applied to mainline. This patch apparently caused 32475 to resurface, so I reverted it. Richard -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32437
[Bug rtl-optimization/32475] [4.3 Regression] function with asm() does not setup stack frame
--- Comment #12 from richard at codesourcery dot com 2007-06-30 12:58 --- Subject: Re: [4.3 Regression] function with asm() does not setup stack frame "richard at codesourcery dot com" <[EMAIL PROTECTED]> writes: > "zadeck at naturalbridge dot com" <[EMAIL PROTECTED]> writes: >> Could you check to see if this bug is collateral damage from your >> latest fix to deletable_insn_p. It's appearance has been tied to that >> function in the past. > > _My_ latest fix to deletable_insn_p? ;) All I did was rephrase > your patch in terms of deletable_insn_p_1. Sorry, I shouldn't have said that. Kenny's original patch was basically an implementation of something I'd suggested on IRC, so the ultimate blame does lie with me. I think the upshot is still the same: I don't really have time to work on this, and given that what I suggested was either wrong, or exposed some other latent problem, I think reverting the patch is the correct thing to do under the circumstances. I suggest that someone else looks at the problem that the patch was trying to solve (which AIUI was a pessimisation rather than a wrong-code bug). Richard -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32475
[Bug fortran/23373] Functions returning pointers with pointer argument
--- Additional Comments From richard at codesourcery dot com 2005-09-07 17:07 --- Subject: Re: Functions returning pointers with pointer argument "tobi at gcc dot gnu dot org" <[EMAIL PROTECTED]> writes: > I don't have the standard at hand, but both the Intel and the Portland Group > compiler accept this. OK, thanks for checking! I'll work on the basis that it's valid. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23373
[Bug middle-end/29519] [4.2 Regression] Bad code on MIPS with -fnon-call-exceptions
--- Comment #7 from richard at codesourcery dot com 2006-10-22 08:51 --- Subject: Re: [4.2 Regression] Bad code on MIPS with -fnon-call-exceptions "daney at gcc dot gnu dot org" <[EMAIL PROTECTED]> writes: > Richard, does this look right? Looks good to me. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29519
[Bug target/29943] [4.2/4.3 Regression] gcc generate incorrect alias symbols for PPC
--- Comment #6 from richard at codesourcery dot com 2006-11-23 05:04 --- Subject: Re: [4.2/4.3 Regression] gcc generate incorrect alias symbols for PPC "amodra at bigpond dot net dot au" <[EMAIL PROTECTED]> writes: > AssignedTo|unassigned at gcc dot gnu |amodra at bigpond dot net >|dot org |dot au Thanks for taking this Alan. I'm happy to look at it if you like though. If it's section-anchor related, then it's my bug. Richard -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29943
