Miles Bader writes:
> Robert Dewar writes:
>> The worst thing for me about -O1 is arguments disappearing in the trace
>> back, that's really a deal breaker.
>
> Wasn't Alexandre Oliva's "VTA" work supposed to help this kind of
> thing...? Did that ever get merged?
It did get merged. My sense
Robert Dewar writes:
> The worst thing for me about -O1 is arguments disappearing in the trace
> back, that's really a deal breaker.
Wasn't Alexandre Oliva's "VTA" work supposed to help this kind of
thing...? Did that ever get merged?
-miles
--
Joy, n. An emotion variously excited, but in its
> "Robert" == Robert Dewar writes:
Robert> Now the debugging at -O1 is hopeless (even parameters routinely
Robert> disappear), and so I am forced to do everything at -O0.
There's been a lot of work on gcc in this area.
Please file bugs for cases you find.
Tom
On 12/7/2011 2:36 PM, David Brown wrote:
\
I guess experiences vary. As I said, I find debugging easier with -O1 -
but maybe that's because most of my work is on embedded targets, which
usually means RISC cpus with plenty of registers. The unoptimised code
for these is usually totally incompreh
On 07/12/11 19:05, Jeff Law wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 12/07/11 01:19, David Brown wrote:
Would it be possible then to have switches for different levels,
such as is done with the strict aliasing warnings?
Well, there's two obvious levels... Not sure if there's
On 12/7/2011 1:05 PM, Jeff Law wrote:
Do people often intentionally run gcc without any optimisations
these days?
Certainly. Compile speed and debugging being the primary reasons.
Actually speaking for myself, I run the compiler at -O0 much
*more* than I used to do. Why? Because gdb simply d
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 12/07/11 01:19, David Brown wrote:
>
> Would it be possible then to have switches for different levels,
> such as is done with the strict aliasing warnings?
Well, there's two obvious levels... Not sure if there's a good way to
get something in be
On 06/12/2011 20:33, Jeff Law wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 12/06/11 12:21, Ian Lance Taylor wrote:
While using the optimizers to improve the quality of uninitialized
warnings does have some benefits, those benefits are outweighed by
the drawbacks. We need to complete
On Tue, Dec 6, 2011 at 11:33 AM, Jeff Law wrote:
> In theory we could go ahead and translate into SSA when not optimizing
> which would remove the dependency on -O, at the expense of
> compile-time performance.
We actually already do this ... As there is only SSA expand now.
Thanks,
Andrew Pinsk
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 12/06/11 12:21, Ian Lance Taylor wrote:
> While using the optimizers to improve the quality of uninitialized
> warnings does have some benefits, those benefits are outweighed by
> the drawbacks. We need to completely reimplement this warning,
> ei
David Brown writes:
> The point of a warning like "unintialised variable" is static error
> checking - it is to help spot mistakes in your code. And if there is
> a path through the function that uses an uninitialised variable,
> that's almost certainly a bug in your code - one you would like th
On Tue, Dec 06, 2011 at 09:29:30AM -0500, Robert Dewar wrote:
> On 12/6/2011 9:16 AM, David Brown wrote:
>
> >I would say it's better to have false positives in cases like this, than
> >false negatives, because there are easy ways to remove the false
> >positives.
>
> My view is that for compiler
On 6 December 2011 15:18, David Brown wrote:
>
> But clearly the uninitialised warnings are useful, and users would like to
> see them improved - if it is possible to do so without adversely affecting
> code generation, of course.
Yes, we all like good things, and we all want more good things, as
On Tue, 2011-12-06 at 16:40 +0100, David Brown wrote:
> On 06/12/2011 16:27, Robert Dewar wrote:
> > On 12/6/2011 10:18 AM, David Brown wrote:
> >
> >> Unfortunately, there are no such tools available that compare with gcc
> >> and its warnings.
> >
...
> And there are large, expensive commercial
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 12/06/11 07:16, David Brown wrote:
>
> I would say it's better to have false positives in cases like this,
> than false negatives, because there are easy ways to remove the
> false positives. It is exactly in cases like this, with complex
> condi
On 06/12/2011 16:33, Robert Dewar wrote:
On 12/6/2011 10:32 AM, Richard Kenner wrote:
Well I am not sure what you mean by a linter or lint program,
See http://en.wikipedia.org/wiki/Lint_(software)
VERY early (and simple) static analysis program for C.
I know what lint is, but I never heard
On 06/12/2011 16:27, Robert Dewar wrote:
On 12/6/2011 10:18 AM, David Brown wrote:
Unfortunately, there are no such tools available that compare with gcc
and its warnings.
It's surprising this is true of C, it's certainly not true of Ada,
where CodePeer can do a much better job than GNAT+gcc
On 12/6/2011 10:32 AM, Richard Kenner wrote:
Well I am not sure what you mean by a linter or lint program,
See http://en.wikipedia.org/wiki/Lint_(software)
VERY early (and simple) static analysis program for C.
I know what lint is, but I never heard anyone referring
to static analysis progra
> Well I am not sure what you mean by a linter or lint program,
See http://en.wikipedia.org/wiki/Lint_(software)
VERY early (and simple) static analysis program for C.
On 12/6/2011 10:18 AM, David Brown wrote:
Unfortunately, there are no such tools available that compare with gcc
and its warnings.
It's surprising this is true of C, it's certainly not true of Ada,
where CodePeer can do a much better job than GNAT+gcc together on
this kind of issue.
Every ti
On 06/12/2011 15:29, Robert Dewar wrote:
On 12/6/2011 9:16 AM, David Brown wrote:
I would say it's better to have false positives in cases like this, than
false negatives, because there are easy ways to remove the false
positives.
My view is that for compiler warnings, you want to balance fal
On 12/6/2011 9:16 AM, David Brown wrote:
I would say it's better to have false positives in cases like this, than
false negatives, because there are easy ways to remove the false
positives.
My view is that for compiler warnings, you want to balance false
positives and false negatives. If you g
On 06/12/2011 14:26, Richard Guenther wrote:
On Tue, Dec 6, 2011 at 2:13 PM, Dave Korn wrote:
On 05/12/2011 21:43, Jeff Law wrote:
When the uninitialized& initialized to 10 paths meet, the compiler
(correctly) pretends the value for the uninitialized path is 10 as
well.
Wouldn't that be
On Tue, Dec 6, 2011 at 2:13 PM, Dave Korn wrote:
> On 05/12/2011 21:43, Jeff Law wrote:
>
>> When the uninitialized & initialized to 10 paths meet, the compiler
>> (correctly) pretends the value for the uninitialized path is 10 as
>> well.
>
> Wouldn't that be a good point at which to issue an un
On 05/12/2011 21:43, Jeff Law wrote:
> When the uninitialized & initialized to 10 paths meet, the compiler
> (correctly) pretends the value for the uninitialized path is 10 as
> well.
Wouldn't that be a good point at which to issue an uninitialised-use warning?
cheers,
DaveK
I agree with David, it would make our life easier if a warning is
triggered in such a case
Patrice
Le 6 décembre 2011 09:04, David Brown a écrit :
> On 05/12/2011 22:43, Jeff Law wrote:
>>
>> -BEGIN PGP SIGNED MESSAGE-
>> Hash: SHA1
>>
>> On 12/02/11 06:03, Patrice B wrote:
>>>
>>> Sor
On 05/12/2011 22:43, Jeff Law wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 12/02/11 06:03, Patrice B wrote:
Sorry for the noise, the problem is already tracked here:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18501
Le 2 décembre 2011 10:42, Patrice Bouchand a
écrit :
Hello,
I su
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 12/02/11 06:03, Patrice B wrote:
> Sorry for the noise, the problem is already tracked here:
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18501
>
> Le 2 décembre 2011 10:42, Patrice Bouchand a
> écrit :
>> Hello,
>>
>> I suspect a regression in
Sorry for the noise, the problem is already tracked here:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18501
Le 2 décembre 2011 10:42, Patrice Bouchand a écrit :
> Hello,
>
> I suspect a regression in uninitialized value detection, but before opening
> a bug I request your advices on the following
29 matches
Mail list logo
