On Saturday 22 October 2005 13:32, Diego Novillo wrote:
> The bug in your code is exposed when GCC creates the intermediate
> representation for your program. In that intermediate representation,
> GCC is explicitly exposing the sequence points in expression evaluation
> using the st
On Saturday 22 October 2005 13:20, manus at eiffel dot com wrote:
> Would it make sense to have a new option in `gcc' to say that target is
> always evaluated after source is?
>
Not really possible. You are correct that it occurs at any optimization
level.
The bug in your code is exposed when G
On Thursday 20 October 2005 12:50, reichelt at igpm dot rwth-aachen dot de
> Doesn't translation unit cover the include file?
>
> But anyway. How should I mark it threadprivate in file2.c?
> Adding "#pragma omp threadprivate (i)" before or after "int i;"
> doesn't work.
>
Indeed, sorry about that.
On Thursday 20 October 2005 12:34, reichelt at gcc dot gnu dot org wrote:
> I'd expect that i is threadprivate in file1.c and file2.c.
>
But you have to mark it so in both places.
> Am I misreading the OpenMP spec or is this a bug in the frontends?
>
I think you're misreading the spec, in 2.8.2.
On Wed, Jul 06, 2005 at 12:16:20AM -, dberlin at gcc dot gnu dot org wrote:
>
> --- Additional Comments From dberlin at gcc dot gnu dot org 2005-07-06
> 00:16 ---
> It's in the ml archives, i'll try to find it.
>
Thanks. I remember the discussion, but I need some URL so that
we can
On Sun, Apr 24, 2005 at 05:56:50PM -, pinskia at gcc dot gnu dot org wrote:
>
> i_15: [1, 2147483647]
> i_16: [0, 2147483647]
> i_20: VARYING
>
> # i_20 = PHI ;
>
>
> Looks like VRP does not understand PHI functions or it just gives up too
> often.
>
i_15 and 0 have a non-empty interse
On Tue, Apr 12, 2005 at 04:55:20PM -, law at redhat dot com wrote:
> That mental model doesn't work right now with the way DOM & the
> jump threader because they are too tightly intertwined.
>
The link that you have still not shown me is why doesn't this
mental model work for the jump threade
On Tue, Apr 12, 2005 at 07:30:56AM +0200, Gabriel Dos Reis wrote:
> This might be due to the bootstrapping compiler -- I was using a
> compiler built from yesterday tree to bootstrap
>
Oh, PR 20933. Yes, the fix you see there should allow you to use
4.1 as a stage0 compiler again. We were misco
On Tue, Apr 12, 2005 at 03:48:10AM -, kazu at cs dot umass dot edu wrote:
> test.c.t21.copyprop1
> test.c.t26.copyprop2
> test.c.t40.copyprop3
> test.c.t55.copyprop5
> test.c.t66.copyprop4
>
> Note that the last two lines are sort of swapped.
> t55 and t66 should have copyprop4 and copyprop6,
#x27;s your top-of-ChangeLog? Works for me up to
2005-04-11 Diego Novillo <[EMAIL PROTECTED]>
PR tree-optimization/20933
* tree-ssa-alias.c (compute_flow_insensitive_aliasing): Move
[ ... ]
Diego.
On Sun, Apr 10, 2005 at 09:47:25PM -0400, Diego Novillo wrote:
> On Sun, Apr 10, 2005 at 05:38:31PM -0400, Andrew Pinski wrote:
>
> > This fixes the bootstrap problem for me on powerpc-darwin.
> >
> Thanks. I will commit as soon as I get a clean bootstrap.
>
Got a clea
On Sun, Apr 10, 2005 at 09:53:00PM -0400, Andrew Pinski wrote:
> Could you try the patch in PR 20934 and see if it fixed the
> bootstrap problem on i686-linux?
>
It does. What's the status of that patch? It almost looks
obvious to me.
Diego.
On Sun, Apr 10, 2005 at 05:38:31PM -0400, Andrew Pinski wrote:
> This fixes the bootstrap problem for me on powerpc-darwin.
>
Thanks. I will commit as soon as I get a clean bootstrap.
Diego.
Sigh. Another SSA_NAME flowing through EH edges getting in the
way.
I'm starting to think that it would be much better to make these
SSA_NAME_OCCURS_IN_ABNORMAL_PHI into virtuals. We would avoid
all the monkeying around that optimizers have to do. It would
involve a bit of trickery because we o
Andrew Pinski wrote:
I think you commenting on the wrong bug.
Indeed. I misread 20376 as 20367. Sorry about that.
pinskia at gcc dot gnu dot org wrote:
Why isn't the tree level loop IV-OPTs doing this?
Because variable i is static.
pinskia at gcc dot gnu dot org wrote:
void g();
int
f(int s, int *a)
{
static int i;
for (i = 0; i < 800; i++)
{
g();
s += a[i];
}
return s;
}
But all of this needs to be on the tree level to be really effective.
This particular case is trivial to fix inside the tree optimizers.
pinskia at gcc dot gnu dot org wrote:
$ gcc/xgcc -Bgcc -O2 -c pr19299.C --version
xgcc (GCC) 4.0.0 20050117 (experimental)
--version makes the compiler to do nothing except for printing out the version.
I know. I collapsed both outputs for brevity.
Never mind. I was using a --disabled-check
pinskia at gcc dot gnu dot org wrote:
The following function:
int f(int a)
{
int i = a & -129;
return i == 144;
}
Should be compiled to:
int f1(int a)
{
return (a & -129) == 144; // aka return 0;
}
Yes this shows up in real code (gcc), found while testing out my tree combiner.
Hmm? What does
On Wed, 2004-12-01 at 00:51 +, kazu at cs dot umass dot edu wrote:
> I get "internal compiler error: Segmentation fault".
>
> The testcase was reduced from i386.c.
>
Hmm, does this happen after fold-all-builtins?
Diego.
On Fri, 2004-11-26 at 22:50 +, dnovillo at gcc dot gnu dot org
wrote:
> --- Additional Comments From dnovillo at gcc dot gnu dot org 2004-11-26
> 22:50 ---
> (In reply to comment #6)
>
> > Diego, if you are too busy, just let me know which you prefer and i'll
> implement it.
> >
> I'
On Fri, 2004-10-08 at 09:03, sebastian dot pop at cri dot ensmp dot fr
wrote:
> Then the following patch solves the problem by avoiding the analysis
> of these cycles.
>
You could also try splitting blocks, but if there's a cheaper work
around for 4.0, that'd be safer.
Diego.
22 matches
Mail list logo
