> 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 mistaken to use numbers. > > > >> Read proposal again. There is one thing in proposal that allows to > >> handle similar > >> situation for diary messages in nicer way. > > > > What look funny instead of looking right? > > Optimization diary has its own version number. When new messages > are included version number is updated. This allows its consumer to > take appropriate action and not choke. Appropriate action may be, ignore > entire diary or ignore unknown messages or something else... Version numbers are sometimes counter productive. So you don't want stuff for free fine, then go implement what ever you want with out thinking about adding new optimziations. > > > >> Do you ever wonder why errno is number and not error string ? > > > > And how many times new error numbers get added? Almost never, > > compared to adding > > a new optimization which can happen any time now. > > > > Look at the problem this way, if it does not change that much often > > then yes it should > > be a number, otherwise a message string is better. > > > > > > Can we have standard numbers for file names now, then? > > OK, I opened the wrong window and this has no relation to this > discussion. Lets close and stay focused :) How is it not related, you asked about error numbers staying the same and I just mention they are not changing that often, even dwarf2 does not change that often. > Since you chose to not continue discuss regarding your three questions > (overlapping > numbers, no space in extension range and tools mismatch), I guess I've > answered all your questions. Overlapping numbers and tool mismatch are instaintly solved with messages and there is no problems with space in the extension range because you don't need a range. The other issue that numbers come with is are the corresponding messages sharable between compilers and compiler versions? Like say, call location was not inlined because number of times this function can be inlined was hit. Shouldn't we provide this information to the user instead of saying it was not inlined (with no reason). Yes this is extension range but what happens when two compilers says the same thing but a third cannot say that but instead says "because 10 inlines is too much for the function". Or with the vectorizer in mind, we have to version this loop for alignment because we can only prove the alignment is 4 bytes. Isn't that better than just saying the loop was version because alignment cannot be proved to be 16bytes? -- Pinski
