Hi,
On Wed, 7 Jun 2006, Daniel Jacobowitz wrote:
> On Wed, Jun 07, 2006 at 11:29:44AM -0700, Devang Patel wrote:
> > And string does not answer localization issue, however for numbers at least
> > there is one precedent to follow.
>
> I think this discussion has gotten totally sidetracked. When
> > I still don't see how gcc maintainers would know to make this
> > distinction. Perhaps I'm misunderstanding the distinction between
> > command and display.
>
> for (i=0; i<4; i++)
> {
> C[i] = A[i] + C[i+3];
> }
>
> Auto vectorizer emits three messages.
> 1) This loop is not vectorized beca
Tom Tromey wrote:
"Devang" == Devang Patel <[EMAIL PROTECTED]> writes:
Devang> Since messages are represented using a number, how about using
Devang> one category bit to identify command message vs display message ?
Devang> Command message is a message where tools, reading opt diar
> "Devang" == Devang Patel <[EMAIL PROTECTED]> writes:
Devang> Since messages are represented using a number, how about using
Devang> one category bit to identify command message vs display message ?
Devang> Command message is a message where tools, reading opt diary,
Devang> take perform some
On 07/06/2006, at 11:33 AM, Daniel Jacobowitz wrote:
On Wed, Jun 07, 2006 at 11:29:44AM -0700, Devang Patel wrote:
And string does not answer localization issue, however for numbers
at least
there is one precedent to follow.
I think this discussion has gotten totally sidetracked. When I s
Daniel Jacobowitz wrote:
On Wed, Jun 07, 2006 at 11:29:44AM -0700, Devang Patel wrote:
And string does not answer localization issue, however for numbers at least
there is one precedent to follow.
I think this discussion has gotten totally sidetracked.
I agree.
When I said
I was i
>
> And string does not answer localization issue, however for numbers at least
> there is one precedent to follow.
And strings have precedent for localization also, just look into how
GCC's error messages are done. Or even any of the Mac OS X programs
which does all localization based on string
On Wed, Jun 07, 2006 at 11:29:44AM -0700, Devang Patel wrote:
> And string does not answer localization issue, however for numbers at least
> there is one precedent to follow.
I think this discussion has gotten totally sidetracked. When I said
I was in favor of strings, I didn't mean messages tha
Andrew Pinski wrote:
No, you said it has limitations and it is mistake to allow vendor
extensions in DWARF.
My exact words were:
Not my fault and not really related because we are creating a new standard and
don't want to repeat this mistake, messages don't have this issue.
I was not tryin
> No, you said it has limitations and it is mistake to allow vendor
> extensions in DWARF.
My exact words were:
Not my fault and not really related because we are creating a new standard and
don't want to repeat this mistake, messages don't have this issue.
I was not trying to imply dwarf2 was mi
Andrew Pinski wrote:
On Jun 7, 2006, at 10:10 AM, Devang Patel wrote:
Is it constructive (and appropriate? but hey I'm DWARF newbie myself)
to declare
DWARF standard limited and full of mistakes ?
No, I am saying that dwarf2 is supposed to be stable and adding stuff
is not likely
going to
Tom Tromey wrote:
Devang> In the case of "dead code" we could use _msg. However, _cmd is
Devang> available to trigger some actions in tools that use this
Devang> information. If we let our imaginations run wild then for
Devang> example, lead developer towards __restrict documentation
Devang> (i.
Tom Tromey wrote:
Dan> It also has almost zero hope of working over multiple compiler versions,
Dan> being future proof in general, and not having other compiler vendors
Dan> fight over message number namespace.
The maintenance issue is a major one. This document definitely needs
to address thi
On Jun 7, 2006, at 10:10 AM, Devang Patel wrote:
Is it constructive (and appropriate? but hey I'm DWARF newbie
myself) to declare
DWARF standard limited and full of mistakes ?
No, I am saying that dwarf2 is supposed to be stable and adding stuff
is not likely
going to happen that often u
Andrew Pinski wrote:
On Jun 6, 2006, at 10:34 PM, Devang Patel wrote:
Andrew Pinski wrote:
On Jun 6, 2006, at 9:49 PM, Devang Patel wrote:
We can allocate space in numbering for vendor extensions.
What happens when you compile two sources with two different
compilers and they
use the sa
> "Dan" == Daniel Berlin <[EMAIL PROTECTED]> writes:
Dan> You still need to be able to display the message for each number in all
Dan> the languages you want, so it's going to be stored somewhere, you
Dan> haven't solved the problem, just moved it completely to the consumer.
Usually I'm not a
On Wed, 2006-06-07 at 01:36, Geoffrey Keating wrote:
> On 06/06/2006, at 5:25 PM, Andrew Pinski wrote:
>
> >> On 06/06/2006, at 5:20 PM, Andrew Pinski wrote:
> >>
> Right above, you said "We control the debug output machinery
> generating this, and can simply tell it to only deal in one
On Jun 6, 2006, at 10:34 PM, Devang Patel wrote:
Andrew Pinski wrote:
On Jun 6, 2006, at 9:49 PM, Devang Patel wrote:
We can allocate space in numbering for vendor extensions.
What happens when you compile two sources with two different
compilers and they
use the same number for vendor
Andrew Pinski wrote:
On Jun 6, 2006, at 9:49 PM, Devang Patel wrote:
We can allocate space in numbering for vendor extensions.
What happens when you compile two sources with two different compilers
and they
use the same number for vendor extension?
What happens when another compiler uses
Tom Tromey wrote:
"Devang" == Devang Patel <[EMAIL PROTECTED]> writes:
* DW_AT_GNU_OD_cmd - it seems strange for this to be defined in terms
of text highlighting. Why have a separate code here for "dead
code" instead of just marking a text region and having a new _msg
value me
On Jun 6, 2006, at 9:49 PM, Devang Patel wrote:
We can allocate space in numbering for vendor extensions.
What happens when you compile two sources with two different
compilers and they
use the same number for vendor extension? You just end up with weird
results
in the IDE or performance
Tom Tromey wrote:
"Devang" == Devang Patel <[EMAIL PROTECTED]> writes:
Tom> * Why put the optimization diary into the object file?
[...]
Devang> 2) This info is consumed by other tools (e.g. IDE, performance
Devang> analyzer). It makes sense for a tool like Shark to use dwarf
De
Daniel Jacobowitz wrote:
On Tue, Jun 06, 2006 at 05:36:33PM -0700, Geoffrey Keating wrote:
I don't see how making it a string makes this different. Either your
new string will be a standard string or it won't. Either your new
number will be a standard number or it won't. If you want it
On Tue, Jun 06, 2006 at 05:36:33PM -0700, Geoffrey Keating wrote:
> I don't see how making it a string makes this different. Either your
> new string will be a standard string or it won't. Either your new
> number will be a standard number or it won't. If you want it to be
> standard, you
> I don't see how making it a string makes this different. Either your
> new string will be a standard string or it won't. Either your new
> number will be a standard number or it won't. If you want it to be
> standard, you have to go through the committee.
I don't understand why it has t
On 06/06/2006, at 5:25 PM, Andrew Pinski wrote:
On 06/06/2006, at 5:20 PM, Andrew Pinski wrote:
Right above, you said "We control the debug output machinery
generating this, and can simply tell it to only deal in one
language." Here, you seem to be implying that the messages
should be
loc
>
>
> --Apple-Mail-9--465959030
> Content-Transfer-Encoding: 7bit
> Content-Type: text/plain;
> charset=US-ASCII;
> delsp=yes;
> format=flowed
>
>
> On 06/06/2006, at 5:20 PM, Andrew Pinski wrote:
>
> >> Right above, you said "We control the debug output machinery
> >> genera
On 06/06/2006, at 5:20 PM, Andrew Pinski wrote:
Right above, you said "We control the debug output machinery
generating this, and can simply tell it to only deal in one
language." Here, you seem to be implying that the messages should be
localised in the language the compiler is going to outpu
> Right above, you said "We control the debug output machinery
> generating this, and can simply tell it to only deal in one
> language." Here, you seem to be implying that the messages should be
> localised in the language the compiler is going to output messages
> in. I suppose you coul
On 06/06/2006, at 5:11 PM, Daniel Berlin wrote:
Geoffrey Keating wrote:
On 06/06/2006, at 4:58 PM, Daniel Berlin wrote:
Geoffrey Keating wrote:
Daniel Berlin <[EMAIL PROTECTED]> writes:
Tom Tromey wrote:
"Devang" == Devang Patel <[EMAIL PROTECTED]> writes:
Devang> This version removes in
Geoffrey Keating wrote:
> On 06/06/2006, at 4:58 PM, Daniel Berlin wrote:
>
>> Geoffrey Keating wrote:
>>> Daniel Berlin <[EMAIL PROTECTED]> writes:
>>>
Tom Tromey wrote:
>> "Devang" == Devang Patel <[EMAIL PROTECTED]> writes:
> Devang> This version removes internal radar numbers
On 06/06/2006, at 4:58 PM, Daniel Berlin wrote:
Geoffrey Keating wrote:
Daniel Berlin <[EMAIL PROTECTED]> writes:
Tom Tromey wrote:
"Devang" == Devang Patel <[EMAIL PROTECTED]> writes:
Devang> This version removes internal radar numbers and replaces s/
Devang> DW_AT_APPLE.../DW_AT_GNU...
>
> Trying to catalogue and assign a permanent place and number to every
> single optimization message a compiler can generate is a much much much
> worse idea, IMHO.
In the same way numbering warning messages is a bad idea (yes ICC and a couple
other compilers do but we should not).
-- Pinski
Geoffrey Keating wrote:
> Daniel Berlin <[EMAIL PROTECTED]> writes:
>
>> Tom Tromey wrote:
"Devang" == Devang Patel <[EMAIL PROTECTED]> writes:
>>> Devang> This version removes internal radar numbers and replaces s/
>>> Devang> DW_AT_APPLE.../DW_AT_GNU...
>>>
>>> I read this. I'm not any
Daniel Berlin <[EMAIL PROTECTED]> writes:
> Tom Tromey wrote:
> >> "Devang" == Devang Patel <[EMAIL PROTECTED]> writes:
> >
> > Devang> This version removes internal radar numbers and replaces s/
> > Devang> DW_AT_APPLE.../DW_AT_GNU...
> >
> > I read this. I'm not anywhere near an expert in
> "Dan" == Daniel Berlin <[EMAIL PROTECTED]> writes:
Dan> In addition to Tom's concerns, it seems to me to be a *really bad idea*
Dan> to try to come up with integer values for every single message, instead
Dan> of just placing a string there.
One reason to prefer the numerical approach is th
> "Devang" == Devang Patel <[EMAIL PROTECTED]> writes:
>> * DW_AT_GNU_OD_cmd - it seems strange for this to be defined in terms
>> of text highlighting. Why have a separate code here for "dead
>> code" instead of just marking a text region and having a new _msg
>> value meaning "dead code"?
> "Devang" == Devang Patel <[EMAIL PROTECTED]> writes:
Tom> * Why put the optimization diary into the object file?
[...]
Devang> 2) This info is consumed by other tools (e.g. IDE, performance
Devang> analyzer). It makes sense for a tool like Shark to use dwarf
Devang> reader to get this inf
On Tue, 6 Jun 2006, Daniel Jacobowitz wrote:
| On Tue, Jun 06, 2006 at 03:47:59PM -0500, Gabriel Dos Reis wrote:
| > Devang Patel <[EMAIL PROTECTED]> writes:
| >
| > | [ Interestingly, there is a long standing request, here at Apple, to list
| > | command line options in object file (even when o
Tom Tromey wrote:
>> "Devang" == Devang Patel <[EMAIL PROTECTED]> writes:
>
> Devang> This version removes internal radar numbers and replaces s/
> Devang> DW_AT_APPLE.../DW_AT_GNU...
>
> I read this. I'm not anywhere near an expert in dwarf or anything
> related to this proposal, so please
Is this what you want ?
yes :)
Thanks,
-
Devang
On Tue, Jun 06, 2006 at 03:47:59PM -0500, Gabriel Dos Reis wrote:
> Devang Patel <[EMAIL PROTECTED]> writes:
>
> | [ Interestingly, there is a long standing request, here at Apple, to list
> | command line options in object file (even when optimization is not used).
> | One of our intern tried
Hi Devang,
> -
> Devang
>
> [ Interestingly, there is a long standing request, here at Apple, to list
> command line options in object file (even when optimization is not used).
> One of our intern tried to put them in STABS string. It may be a good
> idea to use DWARF in that case also. H
Devang Patel <[EMAIL PROTECTED]> writes:
| [ Interestingly, there is a long standing request, here at Apple, to list
| command line options in object file (even when optimization is not used).
| One of our intern tried to put them in STABS string. It may be a good
| idea to use DWARF in that
Devang Patel <[EMAIL PROTECTED]> writes:
| Tom Tromey wrote:
| > * Why put the optimization diary into the object file?
| > Why not just have -Wdiary and print it along with all the warnings?
| > (I'm sure there's an answer to this, it would just be nice if it
| > were in the document...)
|
Andrew Pinski wrote:
Andrew Pinski wrote:
These are not warnings and they should not cause build failures
when -Werror is used, hence warnings are not suitable medium to
communicate this info.
There is a third type of diagnostic in GCC which gets not much
use at all. It is c
>
> Andrew Pinski wrote:
> >> These are not warnings and they should not cause build failures
> >> when -Werror is used, hence warnings are not suitable medium to
> >> communicate this info.
> >>
> >
> > There is a third type of diagnostic in GCC which gets not much
> > use at all. It is cal
Andrew Pinski wrote:
These are not warnings and they should not cause build failures
when -Werror is used, hence warnings are not suitable medium to
communicate this info.
There is a third type of diagnostic in GCC which gets not much
use at all. It is called note. It might be interestin
> These are not warnings and they should not cause build failures
> when -Werror is used, hence warnings are not suitable medium to
> communicate this info.
There is a third type of diagnostic in GCC which gets not much
use at all. It is called note. It might be interesting to use that instead
o
Tom Tromey wrote:
* Why put the optimization diary into the object file?
Why not just have -Wdiary and print it along with all the warnings?
(I'm sure there's an answer to this, it would just be nice if it
were in the document...)
These are not warnings and they should not cause build f
Tom Tromey wrote:
"Devang" == Devang Patel <[EMAIL PROTECTED]> writes:
Devang> This version removes internal radar numbers and replaces s/
Devang> DW_AT_APPLE.../DW_AT_GNU...
I read this. I'm not anywhere near an expert in dwarf or anything
related to this proposal, so please bea
> "Devang" == Devang Patel <[EMAIL PROTECTED]> writes:
Devang> This version removes internal radar numbers and replaces s/
Devang> DW_AT_APPLE.../DW_AT_GNU...
I read this. I'm not anywhere near an expert in dwarf or anything
related to this proposal, so please bear with me if I say something
52 matches
Mail list logo