Re: SRA generates uninitialized var use

[Xinliang David Li]

Bootstrap and tested on linux/x86_64.

Ok for trunk?

David


On Sat, Jun 18, 2011 at 1:56 AM, Xinliang David Li  wrote:
> Compiling the test case in the patch with -O2 -m32 without the fix,
> the program will abort. The problem is a var decl whose address is
> taken is not marked as addressable leading to bad SSA update (missing
> VUSE).  (the triaging used the the .after and .after_cleanup dump diff
> and found the problem).
>
> the test is on going. Ok after testing?
>
> Thanks,
>
> David
>

Re: Cgraph alias reorg 15/14 (New infrastructure for same body aliases)

[Hans-Peter Nilsson]

On Sat, 11 Jun 2011, Jan Hubicka wrote:

> Hi,
> this patch complettes the same body alias rework by removing the old same body
> alias code and adding new representation.  Same body aliases are now separate
> function nodes that have IPA_REF_ALIAS reference to the node they are alias 
> of.
>
> I am still getting one failure:
> FAIL: g++.dg/torture/pr43879-1_1.C
>
> It tests IPA PTA in presence of same body aliases.  I honestly have no idea
> what is wrong there.  I decided to go ahead with the patch anyway, given the
> current state of affair of aliases and IPA-PTA. Hope Richard will help me
> fixing this on Monday.

Still there, see again PR49373.  Anything better than a xfail in the works?

brgds, H-P

Re: Cgraph alias reorg 15/14 (New infrastructure for same body aliases)

[Jan Hubicka]

> On Sat, 11 Jun 2011, Jan Hubicka wrote:
> 
> > Hi,
> > this patch complettes the same body alias rework by removing the old same 
> > body
> > alias code and adding new representation.  Same body aliases are now 
> > separate
> > function nodes that have IPA_REF_ALIAS reference to the node they are alias 
> > of.
> >
> > I am still getting one failure:
> > FAIL: g++.dg/torture/pr43879-1_1.C
> >
> > It tests IPA PTA in presence of same body aliases.  I honestly have no idea
> > what is wrong there.  I decided to go ahead with the patch anyway, given the
> > current state of affair of aliases and IPA-PTA. Hope Richard will help me
> > fixing this on Monday.
> 
> Still there, see again PR49373.  Anything better than a xfail in the works?

Yes, we discussed the problem with Richi and the issue is that ipa-pta gets
confused by inliner redirecting edge from alias to the real inline clone.
The proper fix is to teach passmanager to do small ipa passes before final
compilation.  I am currently at the GCC gathering, so I plan to implement
this day after tomorrow after returning.

Honza
> 
> brgds, H-P

Re: Cgraph alias reorg 15/14 (New infrastructure for same body aliases)

[Jan Hubicka]

> > On Sat, 11 Jun 2011, Jan Hubicka wrote:
> > 
> > > Hi,
> > > this patch complettes the same body alias rework by removing the old same 
> > > body
> > > alias code and adding new representation.  Same body aliases are now 
> > > separate
> > > function nodes that have IPA_REF_ALIAS reference to the node they are 
> > > alias of.
> > >
> > > I am still getting one failure:
> > > FAIL: g++.dg/torture/pr43879-1_1.C
> > >
> > > It tests IPA PTA in presence of same body aliases.  I honestly have no 
> > > idea
> > > what is wrong there.  I decided to go ahead with the patch anyway, given 
> > > the
> > > current state of affair of aliases and IPA-PTA. Hope Richard will help me
> > > fixing this on Monday.
> > 
> > Still there, see again PR49373.  Anything better than a xfail in the works?
> 
> Yes, we discussed the problem with Richi and the issue is that ipa-pta gets
> confused by inliner redirecting edge from alias to the real inline clone.
> The proper fix is to teach passmanager to do small ipa passes before final
> compilation.  I am currently at the GCC gathering, so I plan to implement
> this day after tomorrow after returning.
But for sure we can xfail it.
(It was prevoiusly latent problem and richi did quicker fix but that just
uncovered another problems. Sorry for the delays here).

Honza

Re: [Ada] Fix bugs with volatile and components of aggregate types

[Duncan Sands]

Hi Eric,


This is the usual problem of volatile accesses not preserved under (heavy)
optimization.  In Ada, we can put pragma Volatile on components of composite
types without putting it on the enclosing type itself,


if T is a non-volatile composite type with volatile components, and O is an
object of type T, are the optimizers allowed to remove the assignment "O := O"?

Ciao, Duncan.

powerpc64 large-toc vs. reload

[Alan Modra]

I was alerted to a problem with large toc (-mcmodel=medium/large) code
a few days ago by warnings emitted during a binutils build.

dwarf.c: In function 'display_debug_lines_raw':
dwarf.c:2409:1: note: non-delegitimized UNSPEC UNSPEC_TOCREL (44) found in 
variable location
dwarf.c:2409:1: note: non-delegitimized UNSPEC UNSPEC_TOCREL (44) found in 
variable location

On investigating why this was happening, I found that these UNSPECs
were from the high part calculation of a toc-relative address that
didn't get a register.  reload allocated the pseudo to a stack slot..
The stack slot didn't match the tight pattern in delegitimize_address
which is why we have an UNSPEC left in the debug info.  The real
problem of course is that reload should never allocate a stack slot
for a simple address calculation that can be rematerialised anywhere
in the function with just one instruction.  So after quite a bit of
digging around in reload, I finally figured out that the problem has a
really easy solution.  Simply tell reload that those high part address
calculations are constants.  Which is true.

That's what the create_TOC_reference change, and the rs6000.md changes
below do.  (I also fix large-toc tls patterns.)  The rest of the patch
just adjusts for the changed RTL.

Bootstrap and regression tests powerpc64-linux in progress.  OK to
apply mainline and 4.6 assuming no regressions?

* config/rs6000/rs6000.c (create_TOC_reference): Wrap high part
of toc-relative address in CONST.
(rs6000_delegitimize_address): Recognize changed address.
(rs6000_legitimize_reload_address): Likewise.
(rs6000_emit_move): Don't force these constants to memory.
* config/rs6000/rs6000.md (tls_gd, tls_gd_high): Wrap high part of
toc-relative address in CONST.
(tls_ld, tls_ld_high, tls_got_dtprel, tls_got_dtprel_high): Likewise.
(tls_got_tprel, tls_got_tprel_high, largetoc_high): Likewise.

Index: gcc/config/rs6000/rs6000.c
===
--- gcc/config/rs6000/rs6000.c  (revision 175175)
+++ gcc/config/rs6000/rs6000.c  (working copy)
@@ -5803,12 +5803,13 @@ rs6000_delegitimize_address (rtx orig_x)
   || TARGET_MINIMAL_TOC
   || TARGET_CMODEL != CMODEL_SMALL))
  || (TARGET_CMODEL != CMODEL_SMALL
- && GET_CODE (XEXP (x, 0)) == PLUS
- && GET_CODE (XEXP (XEXP (x, 0), 0)) == REG
- && REGNO (XEXP (XEXP (x, 0), 0)) == TOC_REGISTER
- && GET_CODE (XEXP (XEXP (x, 0), 1)) == HIGH
+ && GET_CODE (XEXP (x, 0)) == CONST
+ && GET_CODE (XEXP (XEXP (x, 0), 0)) == PLUS
+ && GET_CODE (XEXP (XEXP (XEXP (x, 0), 0), 0)) == REG
+ && REGNO (XEXP (XEXP (XEXP (x, 0), 0), 0)) == TOC_REGISTER
+ && GET_CODE (XEXP (XEXP (XEXP (x, 0), 0), 1)) == HIGH
  && rtx_equal_p (XEXP (x, 1),
- XEXP (XEXP (XEXP (x, 0), 1), 0)
+ XEXP (XEXP (XEXP (XEXP (x, 0), 0), 1), 0)
{
  y = XVECEXP (y, 0, 0);
  if (offset != NULL_RTX)
@@ -6147,11 +6148,12 @@ rs6000_legitimize_reload_address (rtx x,
   && GET_CODE (XEXP (x, 0)) == PLUS
   && GET_CODE (XEXP (XEXP (x, 0), 0)) == REG
   && REGNO (XEXP (XEXP (x, 0), 0)) == TOC_REGISTER
-  && GET_CODE (XEXP (XEXP (x, 0), 1)) == HIGH
+  && GET_CODE (XEXP (XEXP (x, 0), 1)) == CONST
+  && GET_CODE (XEXP (XEXP (XEXP (x, 0), 1), 0)) == HIGH
   && GET_CODE (XEXP (x, 1)) == CONST
   && GET_CODE (XEXP (XEXP (x, 1), 0)) == UNSPEC
   && XINT (XEXP (XEXP (x, 1), 0), 1) == UNSPEC_TOCREL
-  && rtx_equal_p (XEXP (XEXP (XEXP (x, 0), 1), 0), XEXP (x, 1)))
+  && rtx_equal_p (XEXP (XEXP (XEXP (XEXP (x, 0), 1), 0), 0), XEXP (x, 1)))
 {
   push_reload (XEXP (x, 0), NULL_RTX, &XEXP (x, 0), NULL,
   BASE_REG_CLASS, Pmode, VOIDmode, 0, 0,
@@ -7197,6 +7196,11 @@ rs6000_emit_move (rtx dest, rtx source, 
}
   else if (mode == Pmode
   && CONSTANT_P (operands[1])
+  && GET_CODE (operands[1]) != HIGH
+  && !(TARGET_CMODEL != CMODEL_SMALL
+   && GET_CODE (operands[1]) == CONST
+   && GET_CODE (XEXP (operands[1], 0)) == PLUS
+   && GET_CODE (XEXP (XEXP (operands[1], 0), 1)) == HIGH)
   && ((GET_CODE (operands[1]) != CONST_INT
&& ! easy_fp_constant (operands[1], mode))
   || (GET_CODE (operands[1]) == CONST_INT
@@ -7204,7 +7208,6 @@ rs6000_emit_move (rtx dest, rtx source, 
   > (TARGET_CMODEL != CMODEL_SMALL ? 3 : 2)))
   || (GET_CODE (operands[0]) == REG
   && FP_REGNO_P (REGNO (operands[0]
-  && GET_CODE (operands[1]) != HIGH
   && ! legitimate_constant_pool_address_p (oper

Re: [PATCH] backport r175089/r175108 to gcc-4_5-branch

[Mike Stump]

On Jun 18, 2011, at 6:10 PM, Jack Howarth wrote:
>   Since the common config/mh-darwin file doesn't exist on gcc-4_5-branch, the 
> following patch
> creates a config/mh-x86-darwin to allow r175089 and r175108 to be effectively 
> backported. This
> change is worthwhile to provide darwin11 users access to dragonegg (since 
> dragonegg doesn't
> build on gcc 4.6.x yet). Bootstrap and regression tested on 
> x86_64-apple-darwin11. Okay
> for gcc-4_5-branch?

Ok and applied.

Re: [PATCH][Revised] Pass -no_pie on SYSTEMSPEC for darwin11

[Mike Stump]

On Jun 18, 2011, at 8:11 AM, Mike Stump wrote:
> On Jun 17, 2011, at 7:49 PM, Jack Howarth wrote:
>> The gcj compiler needs to pass -no_pie for linkage on darwin11 due to the 
>> new -pie
>> default of the linker. The attached patch accomplishes this by passing 
>> -no_pie on SYSTEMSPEC
>> for *-*-darwin[12]*. Since Darwin10 supports -no_pie in its linker, I 
>> included it in the
>> triplet match to simplify the syntax. Bootstrap and tested on 
>> x86_64-apple-darwin11.
>> Okay for gcc trunk with PR added to comment as requested?
>>  Jack
>> ps This change also works for gcc-4_6-branch in concert with a backport of
>> r175089 and r175108.
>> 
>> 2011-06-17  Jack Howarth 
>> 
>>  PR target/49461
>>  * libjava/configure.ac (SYSTEMSPEC): Pass -no_pie for darwin11.
>>  * libjava/configure: Regenerate.
> 
> Checked in r175182, with one additional comment.  We still welcome tracking 
> down what exactly doesn't work and a bug report and fix for that, until then, 
> I think life is too short to have java be broken for too long.

Also backported for 4.6.1.

Re: Turn on -pie on darwin11 and later

[Mike Stump]

On Jun 15, 2011, at 6:33 PM, Mike Stump wrote:
>   * mh-darwin: Turn off -pie on darwin11 and later.

Also backported for gcc 4.5.4 and 4.6.1.

Re: Turn on -pie on darwin11 and later

[Mike Stump]

On Jun 16, 2011, at 12:22 PM, Mike Stump wrote:
> On Jun 16, 2011, at 5:01 AM, Pedro Alves wrote:
>> On Thursday 16 June 2011 02:33:50, Mike Stump wrote:
>>> BOOT_CFLAGS += -mdynamic-no-pic
>>> +
>>> +# Ensure we don't try and use -pie, as it is incompatible with pch.
>>> +BOOT_LDFLAGS=`case ${host} in *-*-darwin[1][1-9]*) echo -Wl,-no_pie ;; 
>>> esac;`
>> 
>> Shouldn't this use += like BOOT_CFLAGS?
> 
> Yes, fixed.  Thanks for the review.

Also backported for gcc 4.5.4 and 4.6.1.

> Index: config/mh-darwin
> ===
> --- config/mh-darwin  (revision 175089)
> +++ config/mh-darwin  (working copy)
> @@ -4,4 +4,4 @@
> BOOT_CFLAGS += -mdynamic-no-pic
> 
> # Ensure we don't try and use -pie, as it is incompatible with pch.
> -BOOT_LDFLAGS=`case ${host} in *-*-darwin[1][1-9]*) echo -Wl,-no_pie ;; esac;`
> +BOOT_LDFLAGS += `case ${host} in *-*-darwin[1][1-9]*) echo -Wl,-no_pie ;; 
> esac;`

PING: PATCH: PR target/46770: Use .init_array/.fini_array sections

[H.J. Lu]

On Fri, Jun 3, 2011 at 5:51 AM, H.J. Lu  wrote:
> On Fri, Jun 3, 2011 at 5:31 AM, Richard Guenther
>  wrote:
>> On Fri, Jun 3, 2011 at 6:31 AM, H.J. Lu  wrote:
>>> On Wed, May 18, 2011 at 8:57 AM, H.J. Lu  wrote:
 On Tue, Apr 26, 2011 at 6:05 AM, H.J. Lu  wrote:
> On Thu, Mar 31, 2011 at 7:57 AM, H.J. Lu  wrote:
>> On Mon, Mar 21, 2011 at 11:40 AM, H.J. Lu  wrote:
>>> On Mon, Mar 14, 2011 at 12:28 PM, H.J. Lu  wrote:
 On Thu, Jan 27, 2011 at 2:40 AM, Richard Guenther
  wrote:
> On Thu, Jan 27, 2011 at 12:12 AM, H.J. Lu  
> wrote:
>> On Tue, Dec 14, 2010 at 05:20:48PM -0800, H.J. Lu wrote:
>>> This patch uses .init_array/.fini_array sections instead of
>>> .ctors/.dtors sections if mixing .init_array/.fini_array and
>>> .ctors/.dtors sections with init_priority works.
>>>
>>> It removes .ctors/.ctors sections from executables and DSOes, which 
>>> will
>>> remove one function call at startup time from each executable and 
>>> DSO.
>>> It should reduce image size and improve system startup time.
>>>
>>> If a platform with a working .init_array/.fini_array support needs a
>>> different .init_array/.fini_array implementation, it can set
>>> use_initfini_array to no.
>>>
>>> Since .init_array/.fini_array is a target feature. 
>>> --enable-initfini-array
>>> is default to no unless the native run-time test is passed.
>>>
>>> To pass the native run-time test, a linker with 
>>> SORT_BY_INIT_PRIORITY
>>> support is required.  The binutils patch is available at
>>>
>>> http://sourceware.org/ml/binutils/2010-12/msg00466.html
>>
>> Linker patch has been checked in.
>>
>>>
>>> This patch passed 32bit/64bit regression test on Linux/x86-64.  Any
>>> comments?
>>>
>>
>> This updated patch fixes build on Linux/ia64 and should work on 
>> others.
>> Any comments?
>
> Yes.  This is stage1 material.
>

 Here is the updated patch.  OK for trunk?

 Thanks.


 --
 H.J.
 
 2011-03-14  H.J. Lu  

        PR target/46770
        * acinclude.m4 (gcc_AC_INITFINI_ARRAY): Removed.

        * config.gcc (use_initfini_array): New variable.
        Use initfini-array.o if supported.

        * crtstuff.c: Don't generate .ctors nor .dtors sections if
        NO_CTORS_DTORS_SECTIONS is defined.

        * configure.ac: Remove gcc_AC_INITFINI_ARRAY.  Add
        --enable-initfini-array and check if .init_array can be used 
 with
        .ctors.

        * configure: Regenerated.

        * config/initfini-array.c: New.
        * config/initfini-array.h: Likewise.
        * config/t-initfini-array: Likewise.

        * config/arm/arm.c (arm_asm_init_sections): Call
        elf_initfini_array_init_sections if NO_CTORS_DTORS_SECTIONS
        is defined.
        * config/avr/avr.c (avr_asm_init_sections): Likewise.
        * config/ia64/ia64.c (ia64_asm_init_sections): Likewise.
        * config/mep/mep.c (mep_asm_init_sections): Likewise.
        * config/microblaze/microblaze.c 
 (microblaze_elf_asm_init_sections):
        Likewise.
        * config/rs6000/rs6000.c (rs6000_elf_asm_init_sections): 
 Likewise.
        * config/stormy16/stormy16.c (xstormy16_asm_init_sections):
        Likewise.
        * config/v850/v850.c (v850_asm_init_sections): Likewise.

>>>
>>> PING:
>>>
>>> http://gcc.gnu.org/ml/gcc-patches/2011-03/msg00760.html
>>>
>>
>> Any comments?  Any objections?
>>
>
> Here is the patch updated for the current trunk.  OK for trunk?
>

 PING,.
>>>
>>> Hi Richard,
>>>
>>> You commented my patch was stage 1 material:
>>>
>>> http://gcc.gnu.org/ml/gcc-patches/2011-01/msg01989.html
>>>
>>> Is my patch:
>>>
>>> http://gcc.gnu.org/ml/gcc-patches/2011-03/msg00760.html
>>>
>>> OK for trunk?
>>
>> I can't approve the configury changes and would like to defer
>> to target maintainers for the target specific changes.  That said,
>> I'm not familiar enough with the area of the patch.  But yes,
>> it's stage1 now - so if anyone else wants to approve this patch...
>
> My first attempt:
>
> http://gcc.gnu.org/ml/gcc-patches/2010-12/msg00589.html
>
> only affects x86.  I changed it to generic based on the
> feedbacks.  But other target maintainers show no interests.
> Should I make it x86 only first?  Each target can enable it
> if needed.
>

I am enclosing 2 patches here.  One only aff

Re: [PATCH][Revised] Pass -no_pie on SYSTEMSPEC for darwin11

[Jack Howarth]

On Sun, Jun 19, 2011 at 11:15:11AM -0700, Mike Stump wrote:
> On Jun 18, 2011, at 8:11 AM, Mike Stump wrote:
> > On Jun 17, 2011, at 7:49 PM, Jack Howarth wrote:
> >> The gcj compiler needs to pass -no_pie for linkage on darwin11 due to the 
> >> new -pie
> >> default of the linker. The attached patch accomplishes this by passing 
> >> -no_pie on SYSTEMSPEC
> >> for *-*-darwin[12]*. Since Darwin10 supports -no_pie in its linker, I 
> >> included it in the
> >> triplet match to simplify the syntax. Bootstrap and tested on 
> >> x86_64-apple-darwin11.
> >> Okay for gcc trunk with PR added to comment as requested?
> >>  Jack
> >> ps This change also works for gcc-4_6-branch in concert with a backport of
> >> r175089 and r175108.
> >> 
> >> 2011-06-17  Jack Howarth 
> >> 
> >>PR target/49461
> >>* libjava/configure.ac (SYSTEMSPEC): Pass -no_pie for darwin11.
> >>* libjava/configure: Regenerate.
> > 
> > Checked in r175182, with one additional comment.  We still welcome tracking 
> > down what exactly doesn't work and a bug report and fix for that, until 
> > then, I think life is too short to have java be broken for too long.
> 
> Also backported for 4.6.1.

Thanks. Can we get this on gcc 4.5.4 as well?
  Jack

Re: PING: PATCH: PR target/46770: Use .init_array/.fini_array sections

[Uros Bizjak]

On Sun, Jun 19, 2011 at 8:39 PM, H.J. Lu  wrote:

>>> I can't approve the configury changes and would like to defer
>>> to target maintainers for the target specific changes.  That said,
>>> I'm not familiar enough with the area of the patch.  But yes,
>>> it's stage1 now - so if anyone else wants to approve this patch...
>>
>> My first attempt:
>>
>> http://gcc.gnu.org/ml/gcc-patches/2010-12/msg00589.html
>>
>> only affects x86.  I changed it to generic based on the
>> feedbacks.  But other target maintainers show no interests.
>> Should I make it x86 only first?  Each target can enable it
>> if needed.
>>
>
> I am enclosing 2 patches here.  One only affects Linux/x86
> and the other covers all targets.  I tested both versions on
> Linux/x86 without any regressions.  Since I only got OK from
> one target maintainer and I have been pinging on this patch
> for more than 6 months, I'd like to get it enabled for Linux/x86
> soon.
>
> Uros, can I check in Linux/x86 version if there are no full feedbacks
> from the rest of target maintainers for more than 48hours.  We can
> enable other targets on a target by target basis later.

Sorry, but I don't feel confident enough to review the patch in this
part of the compiler. I would prefer if somebody else approves it.

Uros.

Re: [RFC, ARM] Convert thumb1 prologue completely to rtl

[Michael Hope]

On Sun, Jun 19, 2011 at 7:02 AM, Richard Henderson  wrote:
> I couldn't find anything terribly tricky about the conversion.
>
> The existing push_mult pattern would service thumb1 with just
> a tweak or two to the memory predicate and the length.
>
> The existing emit_multi_reg_push wasn't set up to handle a
> complete switch of registers for unwind info.  I thought about
> trying to merge them, but thought chickened out.
>
> I havn't cleaned out the code that is now dead in thumb_pushpop.
> I'd been thinking about maybe converting epilogues completely
> to rtl as well, which would allow the function to be deleted
> completely, rather than incrementally.
>
> I'm unsure what testing should be applied.  I'm currently doing
> arm-elf, which does at least have a thumb1 multilib, and uses
> newlib so I don't have to fiddle with setting up a full native
> cross environment.  What else should be done?  arm-eabi?

Hi Richard.  arm-linux-gnueabi bootstraps in Thumb1 mode.  I haven't
done many builds in that way, but here's the latest:
 
http://builds.linaro.org/toolchain/gcc-4.6.0-RC-20110321/logs/armv7l-maverick-cbuild93-ursa1-armv5thumbr1/

-- Michael

Re: [testsuite] scan-dump variants to use 'unresolved' for missing dump file

[Mike Stump]

On Jun 16, 2011, at 6:11 PM, Janis Johnson wrote:
> Currently, scan-dump variants treat a missing dump file as a failure and
> append ": dump file does not exist" to the test message that would be
> used with pass or fail.  This patch treats it as unresolved instead,
> using the same test message as for pass/fail and reporting the reason
> in the log file.
> 
> Tested with dummy tests that use all of these procs for either pass,
> fail, or unresolved.  OK for trunk, and later for 4.6?

Ok.

Re: [PATCH][Revised] Pass -no_pie on SYSTEMSPEC for darwin11

[Mike Stump]

On Jun 19, 2011, at 12:43 PM, Jack Howarth wrote:
> Thanks. Can we get this on gcc 4.5.4 as well?

As commented in the PR, I'd have to see a confirmation that the bug exists in 
gcc-4.5.x _and_ that the patch fixes it (with no regressions).  That had been 
previously stated for gcc-4.6.x, which is why the backport to 4.6.x.  Sorry in 
advance if it has already been stated, I might have missed it.

Re: [PATCH][Revised] Pass -no_pie on SYSTEMSPEC for darwin11

[Jack Howarth]

On Sun, Jun 19, 2011 at 02:40:59PM -0700, Mike Stump wrote:
> On Jun 19, 2011, at 12:43 PM, Jack Howarth wrote:
> > Thanks. Can we get this on gcc 4.5.4 as well?
> 
> As commented in the PR, I'd have to see a confirmation that the bug exists in 
> gcc-4.5.x _and_ that the patch fixes it (with no regressions).  That had been 
> previously stated for gcc-4.6.x, which is why the backport to 4.6.x.  Sorry 
> in advance if it has already been stated, I might have missed it.

This is definitely a problem in current gcc-4_5-branch without the backport of 
the SYSTEMSPEC fix...

[MacPro:~] howarth% gcj-fsf-4.5 --main=testme -O testme.java
gcj-fsf-4.5: Internal error: Abort trap: 6 (program ecj1)
Please submit a full bug report.
See  for instructions.

   Jack

Converting Sparc to REG_CFA_* notes

[Richard Henderson]

Sparc is one of three users of a dwarf2out hook that I'd like to eliminate.

The other two users (arm and ia64) should be able to transition directly to
existing REG_CFA_* notes, and I will take care of those shortly.  Sparc is
the only user of DW_CFA_GNU_window_save, which means we need a corresponding
note to match.

I've tested this via cross-compile and the unwind info is unchanged before
and after.  However, I'll hold off checking it in for the moment until it
has had a chance to go through a true bootstrap cycle.  Dave, might you
have a moment to do that?


r~
* reg-notes.def (REG_CFA_WINDOW_SAVE): New.
* dwarf2out.c (dwarf2out_frame_debug): Handle it.
(dwarf2out_frame_debug_cfa_window_save): Rename from
dwarf2out_window_save; make static.
* tree.h (dwarf2out_window_save): Don't declare.

* config/sparc/sparc.c (sparc_dwarf_handle_frame_unspec): Remove.
(TARGET_DWARF_HANDLE_FRAME_UNSPEC): Remove.
(emit_save_register_window): Rename from gen_save_register_window;
emit the insn and add REG_CFA_* notes.
(sparc_expand_prologue): Update to match.
* config/sparc/sparc.md (save_register_window_1): Simplify from
save_register_window.


diff --git a/gcc/config/sparc/sparc.c b/gcc/config/sparc/sparc.c
index fe28d55..084d111 100644
--- a/gcc/config/sparc/sparc.c
+++ b/gcc/config/sparc/sparc.c
@@ -460,7 +460,6 @@ static unsigned int sparc_function_arg_boundary (enum 
machine_mode,
 const_tree);
 static int sparc_arg_partial_bytes (cumulative_args_t,
enum machine_mode, tree, bool);
-static void sparc_dwarf_handle_frame_unspec (const char *, rtx, int);
 static void sparc_output_dwarf_dtprel (FILE *, int, rtx) ATTRIBUTE_UNUSED;
 static void sparc_file_end (void);
 static bool sparc_frame_pointer_required (void);
@@ -611,9 +610,6 @@ char sparc_hard_reg_printed[8];
 #undef TARGET_VECTORIZE_PREFERRED_SIMD_MODE
 #define TARGET_VECTORIZE_PREFERRED_SIMD_MODE sparc_preferred_simd_mode
 
-#undef TARGET_DWARF_HANDLE_FRAME_UNSPEC
-#define TARGET_DWARF_HANDLE_FRAME_UNSPEC sparc_dwarf_handle_frame_unspec
-
 #ifdef SUBTARGET_INSERT_ATTRIBUTES
 #undef TARGET_INSERT_ATTRIBUTES
 #define TARGET_INSERT_ATTRIBUTES SUBTARGET_INSERT_ATTRIBUTES
@@ -4597,12 +4593,26 @@ emit_save_or_restore_local_in_regs (rtx base, int 
offset, sorr_act_t action)
 /* Generate a save_register_window insn.  */
 
 static rtx
-gen_save_register_window (rtx increment)
+emit_save_register_window (rtx increment)
 {
-  if (TARGET_ARCH64)
-return gen_save_register_windowdi (increment);
-  else
-return gen_save_register_windowsi (increment);
+  rtx insn;
+
+  insn = emit_insn (gen_save_register_window_1 (increment));
+  RTX_FRAME_RELATED_P (insn) = 1;
+
+  /* The return address (%i7) is saved in %o7.  */
+  add_reg_note (insn, REG_CFA_REGISTER,
+   gen_rtx_SET (VOIDmode,
+gen_rtx_REG (Pmode, 31),
+gen_rtx_REG (Pmode, 15)));
+
+  /* The window save event.  */
+  add_reg_note (insn, REG_CFA_WINDOW_SAVE, const0_rtx);
+
+  /* The CFA is %o6, the hard frame pointer.  */
+  add_reg_note (insn, REG_CFA_DEF_CFA, hard_frame_pointer_rtx);
+
+  return insn;
 }
 
 /* Generate a create_flat_frame_1 insn.  */
@@ -4671,7 +4681,6 @@ sparc_expand_prologue (void)
 {
   HOST_WIDE_INT size;
   rtx insn;
-  int i;
 
   /* Compute a snapshot of current_function_uses_only_leaf_regs.  Relying
  on the final value of the flag means deferring the prologue/epilogue
@@ -4733,10 +4742,10 @@ sparc_expand_prologue (void)
   else
 {
   if (size <= 4096)
-   insn = emit_insn (gen_save_register_window (GEN_INT (-size)));
+   emit_save_register_window (GEN_INT (-size));
   else if (size <= 8192)
{
- insn = emit_insn (gen_save_register_window (GEN_INT (-4096)));
+ emit_save_register_window (GEN_INT (-4096));
  /* %sp is not the CFA register anymore.  */
  emit_insn (gen_stack_pointer_inc (GEN_INT (4096 - size)));
}
@@ -4744,12 +4753,8 @@ sparc_expand_prologue (void)
{
  rtx reg = gen_rtx_REG (Pmode, 1);
  emit_move_insn (reg, GEN_INT (-size));
- insn = emit_insn (gen_save_register_window (reg));
+ emit_save_register_window (reg);
}
-
-  RTX_FRAME_RELATED_P (insn) = 1;
-  for (i=0; i < XVECLEN (PATTERN (insn), 0); i++)
-RTX_FRAME_RELATED_P (XVECEXP (PATTERN (insn), 0, i)) = 1;
 }
 
   if (sparc_leaf_function_p)
@@ -1,20 +10005,6 @@ get_some_local_dynamic_name_1 (rtx *px, void *data 
ATTRIBUTE_UNUSED)
   return 0;
 }
 
-/* Handle the TARGET_DWARF_HANDLE_FRAME_UNSPEC hook.
-
-   This is called from dwarf2out.c to emit call frame instructions
-   for frame-related insns containing UNSPECs and UNSPEC_VOLATILEs.  */
-
-static void
-sparc_dwarf_handle_frame_unspec (const char *label,
-  

Re: [Ada] Fix bugs with volatile and components of aggregate types

[Eric Botcazou]

> if T is a non-volatile composite type with volatile components, and O is an
> object of type T, are the optimizers allowed to remove the assignment "O :=
> O"?

Good question, that I'm not really qualified to answer.  Any language lawyer?

-- 
Eric Botcazou

Re: [PATCH][RFC][1/2] Bitfield lowering, add BIT_FIELD_EXPR

[William J. Schmidt]

On Thu, 2011-06-16 at 13:35 +0200, Richard Guenther wrote:
> This is a (possible) pre-requesite for the bitfield lowering patch,
> taken from the old mem-ref branch.  It introduces BIT_FIELD_EXPR
> which can be used to do bitfield composition.
> BIT_FIELD_EXPR  is equivalent to computing
> a & ~((1 << C1 - 1) << C2) | ((b << C2) & (1 << C1 = 1)), thus
> inserting b of width C1 at the bitfield position C2 in a, returning
> the new value.  This allows translating
>  BIT_FIELD_REF  = b;
> to
>  a = BIT_FIELD_EXPR ;
> which avoids partial definitions of a (thus, BIT_FIELD_EXPR is
> similar to COMPLEX_EXPR).  BIT_FIELD_EXPR is supposed to work
> on registers only.
> 
> Comments welcome, esp. on how to avoid introducing quaternary
> RHS on gimple stmts (or using a GIMPLE_SINGLE_RHS as the patch does).
> 

At the risk of being obvious...it seems you could easily combine C1 and
C2 into a single "bitfield descriptor" TREE_INT_CST operand by using
both the high and low portions of the constant.  Accessor macros could
be used to hide the slight hackishness of the solution.  I didn't see
anything in either patch where this would look particularly ugly.

Storing operands differently than in BIT_FIELD_REF isn't ideal, but
perhaps it's better than a quaternary RHS.  /shrug

Bill

Re: [Ada] Fix bugs with volatile and components of aggregate types

[Mike Stump]

On Jun 19, 2011, at 4:24 PM, Eric Botcazou wrote:
>> if T is a non-volatile composite type with volatile components, and O is an
>> object of type T, are the optimizers allowed to remove the assignment "O :=
>> O"?
> 
> Good question, that I'm not really qualified to answer.  Any language lawyer?

I'd like to think that the optimizers are not allowed to remove the assignment 
(unless they synthesize of up the assignment of all volatile fields).  For 
unions, head explodes.  I think for unions, it can.  I could check the standard 
to ensure I have it right, but, well, that's annoying.  :-)  This answer is for 
the answer for C and C++, but, the middle end, _could_ decide to differ, if it 
had a compelling reason to.  I don't know of any reason.  Now, before someone 
tries to optimize structures, please be very careful.  Unions, transparent 
unions, frontend synthed structures with multiple offsets at the same location 
and the like come to mind.

Re: Converting Sparc to REG_CFA_* notes

[Eric Botcazou]

> I've tested this via cross-compile and the unwind info is unchanged before
> and after.  However, I'll hold off checking it in for the moment until it
> has had a chance to go through a true bootstrap cycle.  Dave, might you
> have a moment to do that?

Note that you have SPARC/Linux machines in the Compile Farm.

Minor nits:

+  /* The return address (%i7) is saved in %o7.  */
+  add_reg_note (insn, REG_CFA_REGISTER,
+   gen_rtx_SET (VOIDmode,
+gen_rtx_REG (Pmode, 31),
+gen_rtx_REG (Pmode, 15)));

We have RETURN_ADDR_REGNUM and INCOMING_RETURN_ADDR_REGNUM nowadays.

+  /* The CFA is %o6, the hard frame pointer.  */
+  add_reg_note (insn, REG_CFA_DEF_CFA, hard_frame_pointer_rtx);

%o6 is %sp, the stack pointer.  You want %fp (better than %i6 IMO).

-- 
Eric Botcazou

Re: Converting Sparc to REG_CFA_* notes

[David Miller]

From: Richard Henderson 
Date: Sun, 19 Jun 2011 16:19:41 -0700

>   * reg-notes.def (REG_CFA_WINDOW_SAVE): New.
>   * dwarf2out.c (dwarf2out_frame_debug): Handle it.
>   (dwarf2out_frame_debug_cfa_window_save): Rename from
>   dwarf2out_window_save; make static.
>   * tree.h (dwarf2out_window_save): Don't declare.
> 
>   * config/sparc/sparc.c (sparc_dwarf_handle_frame_unspec): Remove.
>   (TARGET_DWARF_HANDLE_FRAME_UNSPEC): Remove.
>   (emit_save_register_window): Rename from gen_save_register_window;
>   emit the insn and add REG_CFA_* notes.
>   (sparc_expand_prologue): Update to match.
>   * config/sparc/sparc.md (save_register_window_1): Simplify from
>   save_register_window.

I'll give this a test later this evening.

[PATCH][PING] Backport PR42333 fix to gcc 4.5

[Jack Howarth]

Mike,
   I requested a backport to gcc-4_5-branch of the fix for PR42333 awhile
back...

http://gcc.gnu.org/ml/gcc-patches/2011-02/msg01098.html

Can we get that committed?
  Jack
ps You already pre-approved such a backport in...

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42333#c57

Re: powerpc64 large-toc vs. reload

[David Edelsohn]

On Sun, Jun 19, 2011 at 10:03 AM, Alan Modra  wrote:
> I was alerted to a problem with large toc (-mcmodel=medium/large) code
> a few days ago by warnings emitted during a binutils build.
>
> dwarf.c: In function 'display_debug_lines_raw':
> dwarf.c:2409:1: note: non-delegitimized UNSPEC UNSPEC_TOCREL (44) found in 
> variable location
> dwarf.c:2409:1: note: non-delegitimized UNSPEC UNSPEC_TOCREL (44) found in 
> variable location
>
> On investigating why this was happening, I found that these UNSPECs
> were from the high part calculation of a toc-relative address that
> didn't get a register.  reload allocated the pseudo to a stack slot..
> The stack slot didn't match the tight pattern in delegitimize_address
> which is why we have an UNSPEC left in the debug info.  The real
> problem of course is that reload should never allocate a stack slot
> for a simple address calculation that can be rematerialised anywhere
> in the function with just one instruction.  So after quite a bit of
> digging around in reload, I finally figured out that the problem has a
> really easy solution.  Simply tell reload that those high part address
> calculations are constants.  Which is true.
>
> That's what the create_TOC_reference change, and the rs6000.md changes
> below do.  (I also fix large-toc tls patterns.)  The rest of the patch
> just adjusts for the changed RTL.
>
> Bootstrap and regression tests powerpc64-linux in progress.  OK to
> apply mainline and 4.6 assuming no regressions?
>
>        * config/rs6000/rs6000.c (create_TOC_reference): Wrap high part
>        of toc-relative address in CONST.
>        (rs6000_delegitimize_address): Recognize changed address.
>        (rs6000_legitimize_reload_address): Likewise.
>        (rs6000_emit_move): Don't force these constants to memory.
>        * config/rs6000/rs6000.md (tls_gd, tls_gd_high): Wrap high part of
>        toc-relative address in CONST.
>        (tls_ld, tls_ld_high, tls_got_dtprel, tls_got_dtprel_high): Likewise.
>        (tls_got_tprel, tls_got_tprel_high, largetoc_high): Likewise.

Okay.

Thanks, David

Patch ping

[Jakub Jelinek]

[testsuite]
  http://gcc.gnu.org/ml/gcc-patches/2011-06/msg01069.html
  PR tree-optimization/48377, PR middle-end/49191
  trunk/4.6
  non_strict_align testsuite support

[debug]
  http://gcc.gnu.org/ml/gcc-patches/2011-06/msg00649.html
  trunk only
  DW_OP_GNU_parameter_ref support

[debug]
  http://gcc.gnu.org/ml/gcc-patches/2011-06/msg00751.html
  trunk only
  DW_OP_GNU_convert <0> support

Jakub