H.J. Lu | 1 Nov 01:24 2008
Picon

PING: PATCH: PR middle-end/37843:[4.4 Regression] unaligned stack in maindue to tail call optimizatiP

On Fri, Oct 24, 2008 at 3:38 PM, H.J. Lu <hjl.tools <at> gmail.com> wrote:
> On Fri, Oct 17, 2008 at 10:06 AM, Uros Bizjak <ubizjak <at> gmail.com> wrote:
>> H.J. Lu wrote:
>>
>>>
>>> The problem is sibcall optimization will use the incoming stack
>>> boundary as the outgoing stack boundary. It is OK as long as
>>> the incoming stack boundary >= the outgoing stack boundary.
>>> ix86_function_ok_for_sibcall needs to know the precise incoming
>>> stack boundary, which is set in expand_stack_alignment, to
>>> check if the incoming stack boundary >= the outgoing stack
>>> boundary.
>>>
>>> This patch moves updating stack boundary before
>>> TARGET_FUNCTION_OK_FOR_SIBCALL is called. It
>>> changes cfgexpand.c and i386.c. OK for trunk?
>>>
>>> Thanks.
>>>
>>>  2008-10-15  H.J. Lu  <hongjiu.lu <at> intel.com>
>>>            Joey Ye  <joey.ye <at> intel.com>
>>>
>>>        PR target/37843
>>>        * cfgexpand.c (expand_stack_alignment): Move updating stack
>>>        boundary to ...
>>>        (gimple_expand_cfg): Here.
>>>
>>>        * config/i386/i386.c (ix86_function_ok_for_sibcall): Return
>>>        false if we need to align the outgoing stack.
>>>        (ix86_update_stack_boundary): Check parm_stack_boundary.
(Continue reading)

Kaz Kojima | 1 Nov 05:43 2008
Picon

[patch RFA] backport the fix for PR rtl-optimization/37769 to 4.3

This patch fixes PR rtl-optimization/37769 for the 4.3 branch.
It's backported from the patch for the trunk:

http://gcc.gnu.org/ml/gcc-patches/2008-10/msg00662.html

which is already applied and it looks there are no problems.  It's
tested with bootstrap and the top level "make -k check" with no new
failures both on i686-pc-linux-gnu and powerpc-apple-darwin9.5.0.
Ok for the 4.3 branch?

Regards,
	kaz
--
2008-11-01  Kaz Kojima  <kkojima <at> gcc.gnu.org>

	Backport from mainline:
	2008-10-24  Kaz Kojima  <kkojima <at> gcc.gnu.org>

	PR rtl-optimization/37769
	* regmove.c (optimize_reg_copy_2): Update REG_INC note if needed.

--- ORIG/gcc-4_3-branch/gcc/regmove.c	2008-02-20 06:48:51.000000000 +0900
+++ LOCAL/gcc-4_3-branch/gcc/regmove.c	2008-10-25 08:12:25.000000000 +0900
 <at>  <at>  -686,7 +686,16  <at>  <at>  optimize_reg_copy_2 (rtx insn, rtx dest,
 	      {
 		if (reg_mentioned_p (dest, PATTERN (q)))
 		  {
+		    rtx note;
+
 		    PATTERN (q) = replace_rtx (PATTERN (q), dest, src);
(Continue reading)

Kumba | 1 Nov 08:30 2008
Picon

Re: [PATCH]: R10000 Needs LL/SC Workaround in Gcc

Kumba wrote:
> The attached patch adds a workaround to have gcc emit branch likely 
> instructions (beqzl) in atomic operations for R10000 CPUs.  This is 
> because revisions of this CPU before 3.0 misbehave, while revisions 2.6 
> and earlier will deadlock.  This issue has been noted on SGI IP28 
> (Indigo2 Impact R10000) systems and SGI IP27 Origin systems.
> 
> After creating a patch to glibc based off of Debian Bug #462112 
> (http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=462112), it was 
> suggested by David Daney that a similar patch be created for GCC.
> 
> Feedback would be welcome on any suggestions for improving this patch 
> (please CC, as I'm not subscribed to the ML).
> 
> Thanks!

Oops, typo in my first patch.  Stray parenthesis around the macro check.  Fixed 
patch is included.

I'm wondering whether this should be limited to _MIPS_ARCH_R10000, though. 
Maybe _MIPS_ARCH_MIPS4 instead, because the R10000 is at minimum, a MIPS-IV CPU, 
  and there might be cases where a userland compiled with -march=mips4 could get 
used instead of one optimized for -march=r10000?

Or would MIPS-II be better, which is when the branch likely instruction was added?

--

-- 
Joshua Kinard
Gentoo/MIPS
kumba <at> gentoo.org
(Continue reading)

Paolo Bonzini | 1 Nov 09:53 2008
Picon

Re: [RFB] IRA and regclass both ignore '!' attribute

Andrew_Pinski <at> PlayStation.Sony.Com wrote:
> Vladimir Makarov <vmakarov <at> redhat.com> wrote on 10/31/2008 07:54:06 AM:
>> The problem you mentioned (selecting GPR instead of FPR) could be solved 
> 
>> by putting one or more ? in the alternative to get the same effect you 
>> are trying to achieve with this patch.  Imho, the patch you are 
>> proposing probably decrease some gcc functionality. Probably ! was 
>> supposed to be used only for reload.
> 
> 
> The documentation says this about '!':
> Disparage severely the alternative that the `!' appears in. This 
> alternative can still be used if it fits without reloading, but if 
> reloading is needed, some other alternative will be used.

But that's almost what the compiler does.

Until reload, i.e. in regclass, the alternative can still be used, but
if reloading is needed, some other alternative will be used.

In other words the only important thing to say is: "During reload,
disparage severely the alternative that the `!' appears in".

Now, I'm not expert enough to understand why this makes sense, but
indeed I saw lots of ?! constraints and that's probably why.

Paolo

Thomas Koenig | 1 Nov 11:33 2008
Picon

Re: [Patch, fortran] PR37159

On Thu, 2008-10-30 at 11:54 +0100, Dennis Wassel wrote:
> Hi list,
> 
> the FSF guys have just sent me the countersigned copyright assignment,
> so: *ping*
> The patch has been accepted by Thomas Koenig on 2008-09-18. Good to go?

Hello Dennis,

I have committed your patch as rev. 141511.  Thanks a lot!

I didn't close the PR yet, because of the check for GET
that Tobias mentioned in
http://gcc.gnu.org/ml/fortran/2008-10/msg00281.html

For your question about Bugzilla and commit privileges:  See
http://gcc.gnu.org/svnwrite.html .  Once you have a gcc.gnu.org
account, you can also manipulate Bugzilla.  It may be a good
idea to wait with that until you have gained a bit more of experience.

Again, congratulations, welcome aboard and happy hacking!

	Thomas

Richard Guenther | 1 Nov 11:53 2008
Picon

Re: [patch RFA] backport the fix for PR rtl-optimization/37769 to 4.3

On Sat, Nov 1, 2008 at 5:43 AM, Kaz Kojima <kkojima <at> rr.iij4u.or.jp> wrote:
> This patch fixes PR rtl-optimization/37769 for the 4.3 branch.
> It's backported from the patch for the trunk:
>
> http://gcc.gnu.org/ml/gcc-patches/2008-10/msg00662.html
>
> which is already applied and it looks there are no problems.  It's
> tested with bootstrap and the top level "make -k check" with no new
> failures both on i686-pc-linux-gnu and powerpc-apple-darwin9.5.0.
> Ok for the 4.3 branch?

It looks like this is a regression on the 4.3 branch (though it isn't
marked as such - please
make sure to mark regressions appropriately in bugzilla).  So the
patch is ok (and in
general you needn't ask for approval for backporting regression fixes).

Thanks,
Richard.

> Regards,
>        kaz
> --
> 2008-11-01  Kaz Kojima  <kkojima <at> gcc.gnu.org>
>
>        Backport from mainline:
>        2008-10-24  Kaz Kojima  <kkojima <at> gcc.gnu.org>
>
>        PR rtl-optimization/37769
>        * regmove.c (optimize_reg_copy_2): Update REG_INC note if needed.
(Continue reading)

Kaz Kojima | 1 Nov 13:27 2008
Picon

Re: [patch RFA] backport the fix for PR rtl-optimization/37769 to 4.3

"Richard Guenther" <richard.guenther <at> gmail.com> wrote:
> It looks like this is a regression on the 4.3 branch (though it isn't
> marked as such - please
> make sure to mark regressions appropriately in bugzilla).

Sorry for missing it.

> So the patch is ok (and in general you needn't ask for approval for
> backporting regression fixes).

I was ambiguous about this rule.  Thanks for the clarification.

Regards,
	kaz

Richard Guenther | 1 Nov 13:43 2008
Picon

[PATCH] Fix PR37976, wrong types from folding strspn


PRE these days nicely detects wrong types in the IL ... both
folding strspn and strcspn wrongly return integer typed zero while
they should return size typed zeros.  Fixed thusly.

Bootstrapped and tested on x86_64-unknown-linux-gnu, applied to trunk.

Richard.

2008-11-01  Richard Guenther  <rguenther <at> suse.de>

	PR middle-end/37976
	* builtins.c (fold_builtin_strspn): Return a size_t.
	(fold_builtin_strcspn): Likewise.

	* gcc.c-torture/compile/pr37976.c: New testcase.

Index: gcc/builtins.c
===================================================================
*** gcc/builtins.c	(revision 141511)
--- gcc/builtins.c	(working copy)
*************** fold_builtin_strspn (tree s1, tree s2)
*** 11398,11404 ****
        if ((p1 && *p1 == '\0') || (p2 && *p2 == '\0'))
  	/* Evaluate and ignore both arguments in case either one has
  	   side-effects.  */
! 	return omit_two_operands (integer_type_node, integer_zero_node,
  				  s1, s2);
        return NULL_TREE;
      }
(Continue reading)

Paul Thomas | 1 Nov 13:48 2008
Picon

Re: [Patch, Fortran] PR fortran/35681: First part, fix ELEMENTAL dependency handling for MVBITS

Daniel,

Regtests fine on FC9/x86_i64.  This is OK for trunk.

Have you had any thoughts on parentheses expressions yet?

Thanks for the patch

Paul
> Hi,
>
> I've updated the patch described below to trunk of now (including the 
> trivial conflicts merge with Mikael's recent check-in) and run a new 
> regtest, no regressions on GNU/Linux-x86-32.
>
> Cheers,
> Daniel
>
> Daniel Kraft wrote:
>> working on PR fortran/35681, I've got some rather big patch now 
>> handling part of the problem.  What it exactly does:
>>
>> 1) Some tab-indentation formatting fixes as I came along, sorry for 
>> those.  I hope it is ok so.
>>
>> 2) When resolving a MVBITS intrinsic call, the code->resolved_sym 
>> gets a dummy formal argument list with the correct INTENTs specified; 
>> this is needed later for gfc_conv_elemental_dependencies.
>>
>> 3) gfc_code got a new member "resolved_isym" that tracks calls to 
(Continue reading)

Janus Weil | 1 Nov 14:27 2008

Re: [Patch, Fortran] PR 36322/36463

> This looks OK for trunk, subject a remark being resolved according
> unto conscience:

Committed as r141515, including a mention of James van Buskirk as the
original author in proc_decl_17.f90.

Cheers,
Janus


Gmane