Roberto Bagnara <[EMAIL PROTECTED]> writes:
> (The platform I'm thinking of is Tandem NSK/OSS.)
>
> Is this correct? Doesn't C99's 6.2.5#6 mandate that...
This is straying from the subject of GCC and into the
problems of writing portable C code, but since you asked
The Tandem NSK/OSS enviro
Paul Eggert wrote:
> Also, such an approach assumes that unsigned long long int
> has at least as many bits as long long int. But this is an
> unportable assumption; C99 does not require this. We have
> run into hosts where the widest signed integer type has much
> greater range than the widest
On Thu, 2006-12-21 at 10:54 -0800, Robert Kennedy wrote:
> > In this case this isn't true, because we have code that orphans ssa
> > names without releasing them.
> > I'm sure Robert will explain further details in a few moments :)
>
> Actually you explained all the relevant details. The question
On Thu, 2006-12-21 at 10:58 -0800, Robert Kennedy wrote:
> > Right now we can have SSA_NAMEs in the
> > list which are no longer used, and we have no way to tell whether they
> > are used or not. Thus the only way to see all valid SSA_NAMEs is to
> > walk the code.
>
> To wit: are there iteration
On Thu, 2006-12-21 at 20:18 +0100, Zdenek Dvorak wrote:
> I think this might be a good idea. I think that this requires
> a lot of changes (basically going through all uses of bsi_remove
> and remove_phi_node and checking them), but it would be cleaner
> than the current situation.
Agreed. Tedio
On Thu, 2006-12-21 at 14:05 -0500, Diego Novillo wrote:
> In any case, that is not important. I agree that every SSA name in the
> SSA table needs to have a DEF_STMT that is either (a) an empty
> statement, or, (b) a valid statement still present in the IL.
Just to be 100% clear. This is not tr
Hi,
Thanks very much. I still have doubts on your suggestion:
AFAIK, the back-end pass consists of (in order) : reg move -> insn sched
-> reg class -> local alloc -> global alloc -> reload -> post-reload.
There are edges from reg move to reg class and reload back to global
alloc.
In case I wan
Paul Brook wrote:
Who says the optimisation is valid? The language standard?
The example was given as something that's 100% safe to optimize. I'm
disagreeing with that assertion. The use I describe isn't that unlikely if
the code was written by someone with poor knowledge of C.
My point is
On Friday 22 December 2006 02:06, Robert Dewar wrote:
> Paul Brook wrote:
> > On Friday 22 December 2006 00:58, Denis Vlasenko wrote:
> >> On Tuesday 19 December 2006 23:39, Denis Vlasenko wrote:
> >>> There are a lot of 100.00% safe optimizations which gcc
> >>> can do. Value range propagation for
Paul Eggert <[EMAIL PROTECTED]> writes:
| Ian Lance Taylor <[EMAIL PROTECTED]> writes:
|
| > We could disable VRP's assumptions about signed overflow. I don't
| > know what else we could do to fix this case. I don't even know how we
| > could issue a useful warning. Perhaps there is a way.
|
Paul Brook wrote:
On Friday 22 December 2006 00:58, Denis Vlasenko wrote:
On Tuesday 19 December 2006 23:39, Denis Vlasenko wrote:
There are a lot of 100.00% safe optimizations which gcc
can do. Value range propagation for bitwise operations, for one
Or this, absolutely typical C code. i386 ar
On Friday 22 December 2006 00:58, Denis Vlasenko wrote:
> On Tuesday 19 December 2006 23:39, Denis Vlasenko wrote:
> > There are a lot of 100.00% safe optimizations which gcc
> > can do. Value range propagation for bitwise operations, for one
>
> Or this, absolutely typical C code. i386 arch can co
On Thu, Dec 21, 2006 at 10:00:47AM +1100, Ben Elliston wrote:
> On Thu, 2006-12-21 at 09:56 +1100, Ben Elliston wrote:
>
> > After some digging, I managed to work out why: the gcov runtime code
> > wants to create the .gcda file in the same directory that the object
> > file was created on the bui
On Tuesday 19 December 2006 23:39, Denis Vlasenko wrote:
> There are a lot of 100.00% safe optimizations which gcc
> can do. Value range propagation for bitwise operations, for one
Or this, absolutely typical C code. i386 arch can compare
16 bits at a time here (luckily, no alighment worries on th
On Thu, Dec 21, 2006 at 09:43:26PM +, Manuel López-Ibáñez wrote:
> On 21/12/06, Janis Johnson <[EMAIL PROTECTED]> wrote:
> >On Wed, Dec 20, 2006 at 03:06:34PM +0100, Jan Eissfeld wrote:
> >> Hi,
> >>
> >> PR19978 reports that some overflow warnings are emitted multiple times.
> >Like for examp
Ian Lance Taylor <[EMAIL PROTECTED]> writes:
> We could disable VRP's assumptions about signed overflow. I don't
> know what else we could do to fix this case. I don't even know how we
> could issue a useful warning. Perhaps there is a way.
It is a knotty problem. Thanks for thinking about it
On Thu, 21 Dec 2006, Ian Lance Taylor wrote:
> > Another question for the GCC experts: would it fix the bug
> > if we replaced "j *= 2" with "j <<= 1" in this sample code?
>
> Well, mainline VRP isn't clever enough to understand that case. But
> it doesn't make the code any more defined. A left
On 2006-12-21, at 23:42, Robert Dewar wrote:
Marcin Dalecki wrote:
Of course I didn't think about a substitute for ==. Not! However I
think
that checks for |x-y| < epsilion, could be really given a
significant speed edge
if done in a single go in hardware.
One thing to ponder here is t
Paul Eggert <[EMAIL PROTECTED]> writes:
> That probably sounds vague, so here's the code that beta
> gcc -O2 actually broke (which started this whole thread):
>
> int j;
> for (j = 1; 0 < j; j *= 2)
> if (! bigtime_test (j))
> return 1;
It's interesting to note that in
Marcin Dalecki wrote:
Of course I didn't think about a substitute for ==. Not! However I think
that checks for |x-y| < epsilion, could be really given a significant
speed edge
if done in a single go in hardware.
One thing to ponder here is that "thinks" like this are what lead
to CISC instr
Snapshot gcc-4.0-20061221 is now available on
ftp://gcc.gnu.org/pub/gcc/snapshots/4.0-20061221/
and on various mirrors, see http://gcc.gnu.org/mirrors.html for details.
This snapshot has been generated from the GCC 4.0 SVN branch
with the following options: svn://gcc.gnu.org/svn/gcc/branches
Marcin Dalecki wrote:
On 2006-12-21, at 23:17, Robert Dewar wrote:
Marcin Dalecki:
Well actually it wouldn't "save the world". However adding an
op-code implementing: x eqeps y <=> |x - y| < epsilion, would be
indeed helpful.
Maybe some m-f has already patented it, and that's the reason we
On 2006-12-21, at 23:17, Robert Dewar wrote:
> Marcin Dalecki:
Well actually it wouldn't "save the world". However adding an
op-code implementing: x eqeps y <=> |x - y| < epsilion, would be
indeed helpful.
Maybe some m-f has already patented it, and that's the reason we
don't see it
al
On 2006-12-21, at 22:19, David Nicol wrote:
It has always seemed to me that floating point comparison could
be standardized to regularize the exponent and ignore the least
significant
few bits and doing so would save a lot of headaches.
This would be a real nuisance. This myth that you sho
>Something along these lines may be useful to do in the vectorizer when we
>get code like this:
> > ((char)x) = ((char)( ((int)((char)x)) << ((int)c) ) )
>and don't feel like doing all the unpacking of chars to ints and then
>packing the ints to chars after the shift. An alternative could be
"Joseph S. Myers" <[EMAIL PROTECTED]> writes:
> Conversion of out-of-range integers to signed types is
> implementation-defined not undefined,
Thanks for the correction; I keep forgetting that. However,
a conforming implementation is allowed to raise a signal for
those conversions, which could
On 2006-12-21, at 22:19, David Nicol wrote:
It has always seemed to me that floating point comparison could
be standardized to regularize the exponent and ignore the least
significant
few bits and doing so would save a lot of headaches.
Well actually it wouldn't "save the world". However
On 21/12/06, Janis Johnson <[EMAIL PROTECTED]> wrote:
On Wed, Dec 20, 2006 at 03:06:34PM +0100, Jan Eissfeld wrote:
> Hi,
>
> PR19978 reports that some overflow warnings are emitted multiple times. Like
for example,
>
> test.c:6: warning: integer overflow in expression
> test.c:6: warning: integ
> You can't change the last parameter to true in the if's true branch.
Ouch. Duh. Thanks!
The worst of it is, Zdenek sent me a patch, and not only did I
misunderstand it, I then transcribed it wrong based on my
misunderstanding. Oh well. Thanks for guessing my mistake.
-- Robert
On 12/20/06, Marcin Dalecki <[EMAIL PROTECTED]> wrote:
You better don't. Really! Please just realize for example the impact
of the (in)famous 80 bit internal (over)precision of a
very common IEEE 754 implementation...
volatile float b = 1.;
if (1. / 3. == b / 3.) {
printf("HALLO!\n")
} else
Marcin Dalecki wrote:
But the same applies to floating point numbers. There, the situation
is even better, because nowadays I can rely on a float or double
being the representation defined in IEEE 754 because there is such
overwhelming hardware support.
You better don't. Really! Please just
On Thu, 21 Dec 2006, Paul Eggert wrote:
> But because bigtime_test wants an int, this causes the test
> program to compute the equivalent of (int) ((unsigned int)
> INT_MAX + 1), and C99 says that if you cannot assume
> wrapping semantics this expression has undefined behavior in
> the common case
Robert Kennedy wrote on 12/21/06 15:01:
Something I forgot to add in my previous message. Notice that it is not
altogether rare to find cases where we have more SSA names than
statements. Are you walking the SSA names because you assume it's
always shorter than walking the statements?
No. I
> Something I forgot to add in my previous message. Notice that it is not
> altogether rare to find cases where we have more SSA names than
> statements. Are you walking the SSA names because you assume it's
> always shorter than walking the statements?
No. I'm walking the SSA names because l
On 12/21/06, Robert Kennedy <[EMAIL PROTECTED]> wrote:
> Robert, can you attach the testcase you've been working with?
One testcase is libstdc++-v3/libsupc++/vec.cc from mainline.
But it compiles without trouble unless you add verification or a walk
over the SSA_NAMEs at the right time.
> 1. W
Jeffrey Law <[EMAIL PROTECTED]> writes:
> On Thu, 2006-12-21 at 10:08 -0800, Ian Lance Taylor wrote:
>
> First, let's go ahead and define an orphan. An orphan is an SSA_NAME
> which has SSA_NAME_DEF_STMT pointing to a statement which does not
> appear in the IL.
That's fine, that simply changes
> Robert, can you attach the testcase you've been working with?
One testcase is libstdc++-v3/libsupc++/vec.cc from mainline.
But it compiles without trouble unless you add verification or a walk
over the SSA_NAMEs at the right time.
> 1. We replace all uses of a phi node with something else
> 2.
On 12/21/06, Diego Novillo <[EMAIL PROTECTED]> wrote:
Daniel Berlin wrote on 12/21/06 12:21:
> for (i = 0; i < num_ssa_names; i++)
> {
> tree name = ssa_name (i);
> if (name && !SSA_NAME_IN_FREELIST (name)
>DFS (name)
>
I see that you are not checking for IS_EMPTY_STMT. Does DFS need t
Paolo Bonzini <[EMAIL PROTECTED]> writes:
> On the autoconf mailing list, Paul Eggert mentioned as a good
> compromise that GCC could treat signed overflow as undefined only for
> loops and not in general.
What I meant to propose (and perhaps did not propose clearly
enough) is that if the C appli
Ian Lance Taylor wrote on 12/21/06 13:08:
If that is acceptable, then there is no issue here. If that is not
acceptable, then we need to fix the code to correctly mark SSA_NAMEs
which are no longer used. Whether we recycle the memory in the unused
SSA_NAMEs is a separate (and less interesting)
Hello,
> > > > The situation is that some SSA_NAMEs are disused (removed from the
> > > > code) without being released onto the free list by
> > > > release_ssa_name().
> > > >
> > > Yes, it happens if a name is put into the set of names to be updated by
> > > update_ssa.
> > >
> > > After update_
Jeffrey Law wrote on 12/21/06 12:48:
True. But remember, the stated purpose of the SSA_NAME recycling
code was _not_ to track every SSA_NAME that went "dead" and recycle
it, but instead to get the majority of them (and to ultimately save
memory by recycling them). Orphan SSA_NAME were always ex
Robert Kennedy wrote on 12/21/06 13:58:
Right now we can have SSA_NAMEs in the
list which are no longer used, and we have no way to tell whether they
are used or not. Thus the only way to see all valid SSA_NAMEs is to
walk the code.
To wit: are there iteration macros somewhere that will help m
Daniel Berlin wrote on 12/21/06 12:21:
for (i = 0; i < num_ssa_names; i++)
{
tree name = ssa_name (i);
if (name && !SSA_NAME_IN_FREELIST (name)
DFS (name)
>
I see that you are not checking for IS_EMPTY_STMT. Does DFS need to
access things like bb_for_stmt?
In any case, that is not im
> Right now we can have SSA_NAMEs in the
> list which are no longer used, and we have no way to tell whether they
> are used or not. Thus the only way to see all valid SSA_NAMEs is to
> walk the code.
To wit: are there iteration macros somewhere that will help me walk
the code while abstracting a
> In this case this isn't true, because we have code that orphans ssa
> names without releasing them.
> I'm sure Robert will explain further details in a few moments :)
Actually you explained all the relevant details. The question is
whether it should be allowed or not. So far almost everyone seem
On Thu, 2006-12-21 at 10:08 -0800, Ian Lance Taylor wrote:
First, let's go ahead and define an orphan. An orphan is an SSA_NAME
which has SSA_NAME_DEF_STMT pointing to a statement which does not
appear in the IL.
> I may be missing something, but I don't think that is the interesting
> issue her
I wrote:
> I don't much care about the details of *how* the facility is provided...
I should rephrase this. I do care about the interface to it. I don't
care so much about the implementation. I would like the interface to
be straightforward.
I don't want to do a separate project to reevaluate the
> I think the discussion should begin with reevaluating whether or not
> the memory savings from recycling SSA_NAMEs is still worth the headache.
That's a separate project that I'd rather not bundle with strength
reduction, because the two are unrelated conceptually.
My opinion is that instead, t
Afternoon all,
I was trying to recover my password for the gcc wiki, and it doesn't work:
when I enter my email and click the button, I see an error message at the top
of the page saying:
{u'[EMAIL PROTECTED]': (550, 'relaying denied')}
I believe this is reporting an error at the sourc
I may be missing something, but I don't think that is the interesting
issue here.
I agree.
I think the issue is whether we want to have a way to see all
currently valid SSA_NAMEs. Right now we can have SSA_NAMEs in the
list which are no longer used, and we have no way to tell whether they
a
Jeffrey Law <[EMAIL PROTECTED]> writes:
> On Thu, 2006-12-21 at 11:55 -0500, Diego Novillo wrote:
> > Robert Kennedy wrote on 12/21/06 11:37:
> >
> > > The situation is that some SSA_NAMEs are disused (removed from the
> > > code) without being released onto the free list by
> > > release_ssa_n
On Wed, Dec 20, 2006 at 03:06:34PM +0100, Jan Eissfeld wrote:
> Hi,
>
> PR19978 reports that some overflow warnings are emitted multiple times. Like
> for example,
>
> test.c:6: warning: integer overflow in expression
> test.c:6: warning: integer overflow in expression
> test.c:6: warning: integ
On Thu, 2006-12-21 at 11:55 -0500, Diego Novillo wrote:
> Robert Kennedy wrote on 12/21/06 11:37:
>
> > The situation is that some SSA_NAMEs are disused (removed from the
> > code) without being released onto the free list by
> > release_ssa_name().
> >
> Yes, it happens if a name is put into t
On Thu, 2006-12-21 at 12:21 -0500, Daniel Berlin wrote:
> On 12/21/06, Diego Novillo <[EMAIL PROTECTED]> wrote:
> > Robert Kennedy wrote on 12/21/06 11:37:
> >
> > > The situation is that some SSA_NAMEs are disused (removed from the
> > > code) without being released onto the free list by
> > > rel
On 12/21/06, Diego Novillo <[EMAIL PROTECTED]> wrote:
Robert Kennedy wrote on 12/21/06 11:37:
> The situation is that some SSA_NAMEs are disused (removed from the
> code) without being released onto the free list by
> release_ssa_name().
>
Yes, it happens if a name is put into the set of names t
Robert Kennedy wrote on 12/21/06 11:37:
The situation is that some SSA_NAMEs are disused (removed from the
code) without being released onto the free list by
release_ssa_name().
Yes, it happens if a name is put into the set of names to be updated by
update_ssa.
After update_ssa, it should
In my ongoing plumbing work on Dan Berlin's Operator Strength
Reduction implementation, I've encountered what seems to me like a
bug. On IRC yesterday everyone seemed to agree that it was a bug.
Zdenek, OTOH, says it is not a bug.
I would like it to be a bug (so it will get fixed everywhere), so
Rajkishore Barik <[EMAIL PROTECTED]> writes:
> Does anyone know of any document describing (in details) the reload phase
> of GCC?
There isn't one. The closest such document is
http://gcc.gnu.org/wiki/reload
which is accurate despite, or perhaps because of, starting out by
equating reload w
Paolo Bonzini wrote:
Some time ago (a year?) I was told on this mailing-list that code
breakage due to undefinedness of signed overflow is not too common (I
at least claimed with no evidence that it was more than one bug per
1,000 lines). My claim was counterclaimed by something like "most of
Maybe he forgot the delicate details? The issue may happen if this
example was incomplete (my "completion" may need some tweaking to make
it more realistic):
#define make_a_bar(ppInstance)
*(unsigned**)(&ppInstance)=make_a_uint(sizeof(struct bar))
make_a_bar(foo->bar);
foo->bar
Paolo Bonzini wrote:
foo->bar = make_a_bar();
foo->bar->none = value;
being rendered as:
call make_a_bar
foo->bar->none = value
foo->bar =
You are not describing a C compiler.
Um, I'm describing what gcc did?
I think he meant
x = make_a_bar ();
x->none = value;
foo->bar = x;
I don't
foo->bar = make_a_bar();
foo->bar->none = value;
being rendered as:
call make_a_bar
foo->bar->none = value
foo->bar =
You are not describing a C compiler.
Um, I'm describing what gcc did?
I think he meant
x = make_a_bar ();
x->none = value;
foo->bar = x;
I don't know if this is a vali
Some time ago (a year?) I was told on this mailing-list that code
breakage due to undefinedness of signed overflow is not too common (I at
least claimed with no evidence that it was more than one bug per 1,000
lines). My claim was counterclaimed by something like "most of the time
people work
Dear Collegues,
I am pleased to announce 3 new GCC mirrors located in London (UK), Hong Kong
and Toronto (CANADA), daily resync.
1) Hong Kong: http://gcc-hk.internet.bs thanks to http://www.internet.bs
(info at internet dot bs)
2) London (UK): http://gcc-uk.internet.bs thanks to http://www.interne
This overflow attitude has some resemblance to the attitude that
resulted in the Y2K issues. I don't try to troll, I have a detailed
explanation below.
Some time ago (a year?) I was told on this mailing-list that code
breakage due to undefinedness of signed overflow is not too common (I at
leas
66 matches
Mail list logo
