> Anyway, the problem here isn't that I particularly care about coming up
> with some workaround to make LTO work, but rather that tests from the
> gcc testsuite are failing on this target because of what looks like
> buggy LTO behavior instead of bugs in the target support, and I wanted
> to b
> I'd say open a missed optimization bug with the testcase and go ahead
> with both patches. Let's see if Eric has some comments first though.
None, but the m32c maintainer may have some.
DJ, do you happen to know the rationale for the use of the MEM_SCALAR_P and
MEM_IN_STRUCT_P flags in m32c_i
On 01/02/2012 12:22 AM, Andi Kleen wrote:
Sandra Loosemore writes:
I'm still finding my way around LTO; can anyone who's more familiar
with this help narrow down where to look for the cause of this? I
don't even know if this is a compiler or ld bug at this point. I'm
I would look into the
On Mon, Jan 2, 2012 at 3:42 PM, Richard Sandiford
wrote:
> Thanks for both replies.
>
> Richard Guenther writes:
>> On Thu, Dec 29, 2011 at 8:48 PM, Eric Botcazou wrote:
fixed_scalar_and_varying_struct_p passes an _address_ rather than a MEM.
So in these cases fixed_scalar_and_varying_
On Mon, Jan 2, 2012 at 3:09 PM, Amker.Cheng wrote:
> On Mon, Jan 2, 2012 at 9:37 PM, Richard Guenther
> wrote:
>
>> Well, with
>>
>> Index: gcc/tree-ssa-pre.c
>> ===
>> --- gcc/tree-ssa-pre.c (revision 182784)
>> +++ gcc/tree-ssa-pr
Thanks for both replies.
Richard Guenther writes:
> On Thu, Dec 29, 2011 at 8:48 PM, Eric Botcazou wrote:
>>> fixed_scalar_and_varying_struct_p passes an _address_ rather than a MEM.
>>> So in these cases fixed_scalar_and_varying_struct_p effectively becomes
>>> a no-op on targets that don't all
On Mon, Jan 2, 2012 at 9:37 PM, Richard Guenther
wrote:
> Well, with
>
> Index: gcc/tree-ssa-pre.c
> ===
> --- gcc/tree-ssa-pre.c (revision 182784)
> +++ gcc/tree-ssa-pre.c (working copy)
> @@ -4335,16 +4335,23 @@ eliminate (void)
On Mon, Jan 2, 2012 at 2:11 PM, Amker.Cheng wrote:
> Thanks Richard,
>
> On Mon, Jan 2, 2012 at 8:33 PM, Richard Guenther
> wrote:
>>
>> I've previously worked on changing GIMPLE_COND to no longer embed
>> the comparison but carry a predicate SSA_NAME only (this is effectively
>> what you do as p
Hi,
I ran into an issue with -fstack-protector on FreeBSD/i386. GCC
generates calls to __stack_chk_fail_local that the linker complains are
undefined. The following test case shows it:
% cat test.c
int
main( void ) {
return( 0 );
}
% gcc46 -o test test.c -fstack-protector-all -fPIE
/var/tmp//
Thanks Richard,
On Mon, Jan 2, 2012 at 8:33 PM, Richard Guenther
wrote:
>
> I've previously worked on changing GIMPLE_COND to no longer embed
> the comparison but carry a predicate SSA_NAME only (this is effectively
> what you do as pre-processing before SCCVN). It had some non-trivial
> fallout
On Thu, Dec 29, 2011 at 9:50 AM, Jiangning Liu wrote:
>
>
>> -Original Message-
>> From: Jiangning Liu
>> Sent: Wednesday, December 28, 2011 5:38 PM
>> To: Jiangning Liu; 'Richard Guenther'
>> Cc: Michael Matz; gcc@gcc.gnu.org
>> Subject: RE: A case exposing code sink issue
>>
>>
>>
>> > -
On Mon, Jan 2, 2012 at 12:37 PM, Amker.Cheng wrote:
> Hi,
> Since SCCVN operates on SSA graph instead of the control flow graph
> for the sake of efficiency,
> it does not handle or value number the conditional expression of
> GIMPLE_COND statement.
> As a result, FRE/PRE does not simplify conditi
Hi,
Since SCCVN operates on SSA graph instead of the control flow graph
for the sake of efficiency,
it does not handle or value number the conditional expression of
GIMPLE_COND statement.
As a result, FRE/PRE does not simplify conditional expression, as
reported in bug 30997.
Since it would be com
On Fri, Dec 30, 2011 at 6:53 PM, Jakub Jelinek wrote:
> On Thu, Dec 29, 2011 at 04:24:31PM +, Richard Sandiford wrote:
>> AIUI, the outcome of PR38964 was that we can't use TBAA for testing an
>> anti_dependence between a load X and store Y because Y might be defining
>> a new object in the sa
On Sat, 31 Dec 2011, Mark Kettenis wrote:
> Execution of the test randomly fails for me on OpenBSD/amd64. Looking
> at the code, it seems it is doing an out-of-bounds array access. For
> refernce I've copied the code of the testcase below. As you can see
> there's a foo(0) call in main(). Ther
15 matches
Mail list logo
