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
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
language. Here,
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 fan of
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
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
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 this,
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.e.
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
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
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
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 that
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 strings.
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
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
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 diary,
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; i4; i++)
{
C[i] = A[i] + C[i+3];
}
Auto vectorizer emits three messages.
1) This loop is not vectorized because of data
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
dumb :-).
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 bear
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
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
of
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
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
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
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 to
Is this what you want ?
yes :)
Thanks,
-
Devang
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
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 info then parse
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 In the case
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 that it makes
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 dwarf or anything
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 anywhere near an expert in dwarf
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
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...
I read
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 and replaces s/
Devang
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 internal
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 could
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 output
--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
generating this, and can
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
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 to
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
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
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
43 matches
Mail list logo
