- User Since
- Oct 9 2018, 12:17 PM (40 w, 3 h)
May 16 2019
I like that you combined it for ease of use. We have OpenVMS-specific changes for our out-of-tree cross-compilers (based on 3.4.2) and it was even worse back then. Having it in one place makes it easier for us. We're currently rebasing for native compilers based on 8.0.0 but will probably rebase again quickly.
May 8 2019
Apr 12 2019
Yes, D60597 feels better if that helps in this case as well.
Apr 8 2019
Other than better Feng Shui, is there a problem you are trying to solve? Is it a building issue?
Feb 19 2019
I asked my local expert for an opinion.
Feb 6 2019
Awesome. I have a out-of-tree change similar to this but I won't be rebasing for another 6 months or so. You've saved me the work. :)
Dec 13 2018
Dec 12 2018
Dec 10 2018
I'll ask the larger question of why did you pick ".LLVM.command.line" as the section name? While distasteful, there might be existing scripts that do things like:
Dec 5 2018
One of my coworkers did an informal test last year and saw that newer Intel CPUs optimization of REP-string-op-instruction was faster than using SSE2 (he used large data sizes, not anything in the shorter ranges this patch deals with). Is that something that should be looked at? (or has somebody done that examination already)
Nov 14 2018
Nov 13 2018
I know you are just trying to match gcc behavior, but do you know why they use SHT_PROGBITS instead of something like SHT_NOTE for the information? On OpenVMS, we use .note entries to record compilation date/time, compiler version, command line, etc. information that is later used by our linker to print out detail link maps. Or is the intention that the information get propagated all the way to the final executable or shared library?
Nov 12 2018
Ah, thanks for finding this. We were just noticing this on our OpenVMS port since we also use platform-registers way up in the 16352-16383 range.
Nov 9 2018
I don't understand the need for the "common alpha" global variable. For VMS Fortran on Itanium (not LLVM), we generate the following DWARF for
Nov 8 2018
[Sorry for the delay, my Dad broke a hip and I had to travel to Tennessee.]
Nov 5 2018
As I commented in the dev email list, these "Fortran" features are actually useful for other languages. We use similar DWARF for Pascal "schema types", BASIC string types, etc. on OpenVMS Itanium and we'll want to leverage all of these for our x86 target. I suggested that the names be make more neutral or folded into the matching metadata tag. I'll give inline comments next.
While I normally would recommend NOT encoding the language name in the constants (I'll be making that suggestion in "part 2" in just a bit), these symbols are clearly Fortran-only (you OR in bit DIFlagFortran 30). The text in the DWARF4 standard also makes the same case but doesn't come out and say Fortran-only but just "These attributes are not relevant for languages that do not support similar keywords or syntax." So should they be named DIFlagFortranPure, DIFlagFortranElemental, DIFlagFortranRecursive or is that too heavy handed?
Yes I see. Thanks for double checking.
Nov 2 2018
While that seems like a place to change, I would have thought that the code just a little farther down would have caught this....