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 GCC
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 standard rules
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 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. I
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 i_15(3), 0(0);
Looks like VRP does not understand PHI functions or it just gives up too
often.
i_15 and 0 have a non-empty
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 threader.
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
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 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 clean bootstrap and test run using
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 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,
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
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:
Why isn't the tree level loop IV-OPTs doing this?
Because variable i is static.
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:
$ 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
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'll take a
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
