On Thu, 2006-01-12 at 11:24 -0800, Joe Buck wrote:
> On Thu, Jan 12, 2006 at 12:13:06PM -0500, Daniel Berlin wrote:
> > I hate to bring this up, because it's a "half-troll", but the halting
> > problem is *not* undecidable on the machines we use everyday, because they
> > have finite memory.
>
>
On Thu, Jan 12, 2006 at 11:13:59AM -0500, Diego Novillo wrote:
> On Thursday 12 January 2006 11:01, [EMAIL PROTECTED] wrote:
>
> > Yes, there is one more instruction to set the variable to 0...
> >
> Oh, please... Fine. You win. I don't care enough.
Use "unsigned".
On Thu, Jan 12, 2006 at 12:13:06PM -0500, Daniel Berlin wrote:
> I hate to bring this up, because it's a "half-troll", but the halting
> problem is *not* undecidable on the machines we use everyday, because they
> have finite memory.
Fine. Now you just have to come up with a solution before the
Robert Dewar wrote:
> Daniel Berlin wrote:
>
>>> The chain of inferences that the compiler would need to do to properly
>>> diagnose this case is beyond the scope of the mechanical
>>> transformations. The reasoning you need to implement to catch these
>>> cases could even be reduced to the haltin
Daniel Berlin wrote:
The chain of inferences that the compiler would need to do to properly
diagnose this case is beyond the scope of the mechanical transformations.
The reasoning you need to implement to catch these cases could even be
reduced to the halting problem.
I hate to bring this
On Thursday 12 January 2006 12:13, Daniel Berlin wrote:
> > The chain of inferences that the compiler would need to do to properly
> > diagnose this case is beyond the scope of the mechanical
> > transformations. The reasoning you need to implement to catch these
> > cases could even be reduced to
The chain of inferences that the compiler would need to do to properly
diagnose this case is beyond the scope of the mechanical transformations.
The reasoning you need to implement to catch these cases could even be
reduced to the halting problem.
I hate to bring this up, because it's a "half-tr
On Thursday 12 January 2006 11:03, Michael Veksler wrote:
> You are most likely right about the "realistically" part.
>
Yes. The heavy analysis would probably be worth doing in a lint-like
checker. Or be part of the compiler with special static optimization
switches. It's probably too heavy-d
On Thursday 12 January 2006 11:01, [EMAIL PROTECTED] wrote:
> Yes, there is one more instruction to set the variable to 0...
>
Oh, please... Fine. You win. I don't care enough.
Quoting Diego Novillo <[EMAIL PROTECTED]>:
[...]
>
> The compiler cannot statically short-circuit that predicate because it
> doesn't know whether best.score will be positive or not.
>
> The chain of inferences that the compiler would need to do to properly
> diagnose this case is beyond the sc
[EMAIL PROTECTED] said:
> Sub-optimal?
Yes, there is one more instruction to set the variable to 0...
--- testit_1.s 2006-01-12 16:38:06.13376 +0100
+++ testit.s2006-01-12 16:57:04.844986000 +0100
@@ -16,6 +16,7 @@
testl %ebx, %ebx
je .L9
movl$0, %edx
On Thursday 12 January 2006 10:47, [EMAIL PROTECTED] wrote:
> But... it used to be the case that the compiler didn't try to warn about
> uninitialized variables embedded in structs (or so I seem to
> remember...) So I was wondering if this was some kind of regression...
>
Progression, of sorts. Y
[EMAIL PROTECTED] wrote:
> But... it used to be the case that the compiler didn't try to warn about
> uninitialized variables embedded in structs (or so I seem to remember...)
> So I was wondering if this was some kind of regression...
I would consider that to be a bug, not a feature. Just be
Ok, a slightly simpler testcase still shows the warning:
--- testit.c ---
#include
static void
testit(unsigned int *a, unsigned int cnt)
{
struct {unsigned int score; unsigned int d;} best;
unsigned int i;
best.score = 0;
for (i = 0; i < cnt; i++)
if (a[i] > best.score) {
best.
On Thursday 12 January 2006 10:14, Perry Smith wrote:
> But... getting a compiler to figure that out is expecting too much.
> Did you try up'ing the optimization level (just out of curiosity)?
>
Right. He will have the same problem at any level.
The compiler cannot statically short-circuit that
Because best.score is set to 0 up front, he is expecting the || (or)
to short circuit and never test best.d.
But... getting a compiler to figure that out is expecting too much.
Did you try up'ing the optimization level (just out of curiosity)?
On Jan 12, 2006, at 9:01 AM, Diego Novillo wr
On Thursday 12 January 2006 09:53, [EMAIL PROTECTED] wrote:
> On my FC4 box with gcc version 4.0.2 20051125 (Red Hat 4.0.2-8) it says:
> testit.c: In function 'testit':
> testit.c:6: warning: 'best.d' may be used uninitialized in this function
>
The warning is valid. You are not guaranteeing that
>I am somewhat confused about the status of the
>"may be used uninitialized" warning...
This list is more for discussing the internals of the GCC compiler,
not how to use it.
As for your question, if cnt is less than or equal to zero, or if a[i]
is always less than zero, then the assignment to
Hi all,
I am somewhat confused about the status of the
"may be used uninitialized" warning...
Consider:
--- testit.c ---
#include
static void
testit(int *a, int cnt)
{
struct {int score; int d;} best;
int i;
best.score = 0;
for (i = 0; i < cnt; i++)
if (a[i] > best.score) {
b
19 matches
Mail list logo