Re: regression due to r187199 explow.c? in target ia64-hp-hpux11.23.
Hi, so it looks like there are other ia64 specific calls to plus_constant that need to be adjusted. Tristan. On Jun 6, 2012, at 1:29 PM, Mailaripillai, Kannan Jeganathan wrote: What is the backtrace ? >> #0 0x6db96a0:0 in plus_constant (mode=RFmode, x=0x18, c=1) >> #13 0x6f68260:0 in expand_expr_real_1 (exp=0x651ab420, target=0x0, > > Full backtrace: > > #0 0x6db96a0:0 in plus_constant (mode=RFmode, x=0x18, c=1) > #1 0xd7503f0:0 in ia64_expand_tls_address (tls_kind=TLS_MODEL_INITIAL_EXEC, >op0=0x651ac120, op1=0x651ac0f0, orig_op1=0x651ac0f0, addend=0) > #2 0xd750dd0:0 in ia64_expand_move (op0=0x651ac120, op1=0x651ac0f0) > #3 0xd8c6e90:0 in gen_movsi (operand0=0x651ac120, operand1=0x651ac0f0) > #4 0x6ef9900:0 in emit_move_insn_1 (x=0x651ac120, y=0x651ac0f0) > #5 0x6efa6f0:0 in emit_move_insn (x=0x651ac120, y=0x651ac0f0) > #6 0x6dbdd30:0 in copy_to_mode_reg (mode=SImode, x=0x651ac0f0) > #7 0x8ba3c30:0 in maybe_legitimize_operand (icode=CODE_FOR_addsi3, opno=1, >op=0x7fffcf88) > #8 0x8ba46c0:0 in maybe_legitimize_operands (icode=CODE_FOR_addsi3, opno=0, >nops=3, ops=0x7fffcf80) > #9 0x8ba48c0:0 in maybe_gen_insn (icode=CODE_FOR_addsi3, nops=3, >ops=0x7fffcf80) > #10 0x8b6b620:0 in expand_binop_directly (mode=SImode, binoptab=0x40257fdc, >op0=0x651ac0f0, op1=0x653ba4f0, target=0x0, unsignedp=1, >methods=OPTAB_LIB_WIDEN, last=0x0) > #11 0x8b6bcb0:0 in expand_binop (mode=SImode, binoptab=0x40257fdc, >op0=0x651ac0f0, op1=0x653ba4f0, target=0x0, unsignedp=1, >methods=OPTAB_LIB_WIDEN) > #12 0x6f4fa30:0 in expand_expr_real_2 (ops=0x7fffdcd4, target=0x0, >tmode=SImode, modifier=EXPAND_NORMAL) > #13 0x6f68260:0 in expand_expr_real_1 (exp=0x651ab420, target=0x0, >tmode=SImode, modifier=EXPAND_NORMAL, alt_rtl=0x0) > #14 0x6f3c830:0 in expand_expr_real (exp=0x651ab420, target=0x0, tmode=SImode, >modifier=EXPAND_NORMAL, alt_rtl=0x0) > #15 0x6e7c5e0:0 in expand_expr (exp=0x651ab420, target=0x0, mode=SImode, >modifier=EXPAND_NORMAL) > #16 0x6f37cc0:0 in expand_expr_addr_expr_1 (exp=0x651a2900, target=0x0, >tmode=SImode, modifier=EXPAND_NORMAL, as=0 '\000') > #17 0x6f3adb0:0 in expand_expr_addr_expr (exp=0x651a8558, target=0x0, >tmode=SImode, modifier=EXPAND_NORMAL) > #18 0x6f67ff0:0 in expand_expr_real_1 (exp=0x651a8558, target=0x0, >tmode=SImode, modifier=EXPAND_NORMAL, alt_rtl=0x0) > #19 0x6f3c830:0 in expand_expr_real (exp=0x651a8558, target=0x0, tmode=SImode, >modifier=EXPAND_NORMAL, alt_rtl=0x0) > #20 0xaa49f90:0 in expand_expr (exp=0x651a8558, target=0x0, mode=SImode, >modifier=EXPAND_NORMAL) > #21 0xaa4ee60:0 in insert_value_copy_on_edge (e=0x655a4e40, dest=8, >src=0x651a8558, locus=1363692) > #22 0xaa53730:0 in eliminate_phi (e=0x655a4e40, g=0x404d6de0) > #23 0xaa54d70:0 in expand_phi_nodes (sa=0x4012623c) > #24 0x5f909d0:0 in gimple_expand_cfg () > #25 0x8d130d0:0 in execute_one_pass (pass=0x400451b8) > #26 0x8d137f0:0 in execute_pass_list (pass=0x400451b8) > #27 0x656d740:0 in expand_function (node=0x65550450) > #28 0x656eb60:0 in expand_all_functions () > #29 0x6571400:0 in compile () > #30 0x6571940:0 in finalize_compilation_unit () > #31 0x51bc8e0:0 in c_write_global_declarations () > #32 0x9c63b30:0 in compile_file () > #33 0x9c6b470:0 in do_compile () > #34 0x9c6b9c0:0 in toplev_main (argc=49, argv=0x7fffeee8) > #35 0xf564740:0 in main (argc=49, argv=0x7fffeee8) > > Regards, > Kannan > > -Original Message- > From: Mailaripillai, Kannan Jeganathan > Sent: Wednesday, June 06, 2012 4:42 PM > To: 'Tristan Gingold' > Cc: gcc@gcc.gnu.org > Subject: RE: regression due to r187199 explow.c? in target ia64-hp-hpux11.23. > > >> What is the backtrace ? > > #0 0x6db96a0:0 in plus_constant (mode=RFmode, x=0x18, c=1) > #1 0xd7503f0:0 in ia64_expand_tls_address (tls_kind=TLS_MODEL_INITIAL_EXEC, >op0=0x651ac120, op1=0x651ac0f0, orig_op1=0x651ac0f0, addend=0) > #2 0xd750dd0:0 in ia64_expand_move (op0=0x651ac120, op1=0x651ac0f0) > #3 0xd8c6e90:0 in gen_movsi (operand0=0x651ac120, operand1=0x651ac0f0) > #4 0x6ef9900:0 in emit_move_insn_1 (x=0x651ac120, y=0x651ac0f0) > #5 0x6efa6f0:0 in emit_move_insn (x=0x651ac120, y=0x651ac0f0) > #6 0x6dbdd30:0 in copy_to_mode_reg (mode=SImode, x=0x651ac0f0) > #7 0x8ba3c30:0 in maybe_legitimize_operand (icode=CODE_FOR_addsi3, opno=1, >op=0x7fffcf88) > #8 0x8ba46c0:0 in maybe_legitimize_operands (icode=CODE_FOR_addsi3, opno=0, >nops=3, ops=0x7fffcf80) > #9 0x8ba48c0:0 in maybe_gen_insn (icode=CODE_FOR_addsi3, nops=3, >ops=0x7fffcf80) > #10 0x8b6b620:0 in expand_binop_directly (mode=SImode, binoptab=0x40257fdc, >op0=0x651ac0f0, op1=0x653ba4f0, target=0x0, unsignedp=1, >methods=OPTAB_LIB_WIDEN, last=0x0) > #11 0x8b6bcb0:0 in expand_binop (mode=SImode, binoptab=0x40257fdc, >op0=0x651ac0f0, op1=0x653ba4f0, target=0x0, unsignedp=1, >methods=OPTAB_LIB_WIDEN) > #12 0x6f4fa30:0 in expand_expr_real_2 (ops=0x7fffdcd4, target=0x0, >tmode=SImode, modifier
Question about ifcvt.c:noce_mem_write_may_trap_or_fault_p() vs. decl_readonly_section
Hello,
I am confused by the following code in
ifcvt.c:noce_mem_write_may_trap_or_fault_p():
static bool
noce_mem_write_may_trap_or_fault_p (const_rtx mem)
{
rtx addr;
if (MEM_READONLY_P (mem))
return true;
(...)
addr = XEXP (mem, 0);
/* Call target hook to avoid the effects of -fpic etc */
addr = targetm.delegitimize_address (addr);
while (addr)
switch (GET_CODE (addr))
{
(...) case SYMBOL_REF:
if (SYMBOL_REF_DECL (addr)
&& decl_readonly_section (SYMBOL_REF_DECL (addr), 0))
return true;
If decl_readonly_section (SYMBOL_REF_DECL (addr), 0) is true, I would
expect that MEM_READONLY_P is set, and the decl_readonly_section check
is never true.
Is there a difference between "could be read-only"
(decl_readonly_section) and "is read-only" (MEM_READONLY_P)?
Thanks for any help you can give,
Ciao!
Steven
Re: Question about ifcvt.c:noce_mem_write_may_trap_or_fault_p() vs. decl_readonly_section
Steven Bosscher writes:
> I am confused by the following code in
> ifcvt.c:noce_mem_write_may_trap_or_fault_p():
>
> static bool
> noce_mem_write_may_trap_or_fault_p (const_rtx mem)
> {
> rtx addr;
>
> if (MEM_READONLY_P (mem))
> return true;
> (...)
>
> addr = XEXP (mem, 0);
>
> /* Call target hook to avoid the effects of -fpic etc */
> addr = targetm.delegitimize_address (addr);
>
> while (addr)
> switch (GET_CODE (addr))
> {
> (...) case SYMBOL_REF:
> if (SYMBOL_REF_DECL (addr)
> && decl_readonly_section (SYMBOL_REF_DECL (addr), 0))
> return true;
>
> If decl_readonly_section (SYMBOL_REF_DECL (addr), 0) is true, I would
> expect that MEM_READONLY_P is set, and the decl_readonly_section check
> is never true.
>
> Is there a difference between "could be read-only"
> (decl_readonly_section) and "is read-only" (MEM_READONLY_P)?
In principle, I agree that MEM_READONLY_P should be set if the address
is based on a SYMBOL_REF and decl_readonly_section is true for the
SYMBOL_REF. In practice I would not be in the least surprised if the
two tests were not identical. There is a lot of code in the compiler
that creates a MEM, and the functions to create a MEM do not check for a
SYMBOL_REF for which decl_readonly_section is true. There are other
triggers for MEM_READONLY_P, so it could turn out to be identical, but I
would not be surprised if it isn't.
If you are really curious it's probably worth adding a test there to see
if it ever triggers--if the call to decl_readonly_section ever returns
true.
Ian
Re: backporting PR52558 to 4.7?
On 05/31/12 15:44, Aldy Hernandez wrote: Hello gentlemen. Would it be ok to backport the fix for PR52558 into the 4.7 branch? This PR is the store data race patch I have been iterating with Richi. Doing so will avoid critical data races for both TM and the C++ memory model. The code is all predicated by flag_tm or !PARAM_VALUE (PARAM_ALLOW_STORE_DATA_RACES)), so it shouldn't affect code paths outside of TM or the C++1x memory model. Thanks. Aldy Ping.
Re: backporting PR52558 to 4.7?
On Thu, Jun 07, 2012 at 12:48:38PM -0500, Aldy Hernandez wrote: > On 05/31/12 15:44, Aldy Hernandez wrote: > >Hello gentlemen. > > > >Would it be ok to backport the fix for PR52558 into the 4.7 branch? This > >PR is the store data race patch I have been iterating with Richi. Doing > >so will avoid critical data races for both TM and the C++ memory model. > > > >The code is all predicated by flag_tm or !PARAM_VALUE > >(PARAM_ALLOW_STORE_DATA_RACES)), so it shouldn't affect code paths > >outside of TM or the C++1x memory model. > > > >Thanks. > Ping. I think it is ok for 4.7.2, 4.7.1 is frozen now and it isn't as severe as various other PRs we've also deferred for 4.7.2. Jakub
gcc-4.5-20120607 is now available
Snapshot gcc-4.5-20120607 is now available on ftp://gcc.gnu.org/pub/gcc/snapshots/4.5-20120607/ and on various mirrors, see http://gcc.gnu.org/mirrors.html for details. This snapshot has been generated from the GCC 4.5 SVN branch with the following options: svn://gcc.gnu.org/svn/gcc/branches/gcc-4_5-branch revision 188318 You'll find: gcc-4.5-20120607.tar.bz2 Complete GCC MD5=9d5ce24452a999c822d70b75c8917a28 SHA1=5609eff19c39b9985f5d2d2516fb05b28046d645 Diffs from 4.5-20120531 are available in the diffs/ subdirectory. When a particular snapshot is ready for public consumption the LATEST-4.5 link is updated and a message is sent to the gcc list. Please do not use a snapshot before it has been announced that way.
Re: GCC 4.7.1 Release Candidate available from gcc.gnu.org
On 6 June 2012 22:14, Richard Guenther wrote: > > The first release candidate for GCC 4.7.1 is available from > > ftp://gcc.gnu.org/pub/gcc/snapshots/4.7.1-RC-20120606 > > and shortly its mirrors. It has been generated from SVN revision 188257. > > I have so far bootstrapped and tested the release candidate on > x86_64-linux. Please test it and report any issues to bugzilla. > > If all goes well, I'd like to release 4.7.1 at the end of next week. This bootstraps and tests OK in ARMv5T+ARM+soft, Cortex-A9+Thumb-2+softfp+NEON, and Cortex-A9+Thumb-2+hard+NEON configurations for C, C++, Fortran, and objc[1]. The regressions compared to 4.7.0 are testisms or the vectoriser not applying. I haven't logged them in bugzilla, sorry. -- Michael [1] http://builds.linaro.org/toolchain/gcc-4.7.1-RC-20120606/logs/
