search for: bitcodeversion

...nt possibilities for updating the bitcode wrapper specification. The first is to simply add a single 32bit wide field at the end of the existing bitcode wrapper format field. This would result in the new structure looking like this: [Magic_{32}, Version_{32}, Offset_{32}, Size_{32}, CPUType_{32}, BitcodeVersion_{32}] All of the existing fields would keep their current meanings, and the new field BitcodeVersion is simply appended with the format described in the first paragraph. A second idea was to use the existing Version field in the bitcode wrapper format to store the bitcode version information. Acc...

...nt possibilities for updating the bitcode wrapper specification. The first is to simply add a single 32bit wide field at the end of the existing bitcode wrapper format field. This would result in the new structure looking like this: [Magic_{32}, Version_{32}, Offset_{32}, Size_{32}, CPUType_{32}, BitcodeVersion_{32}] All of the existing fields would keep their current meanings, and the new field BitcodeVersion is simply appended with the format described in the first paragraph. A second idea was to use the existing Version field in the bitcode wrapper format to store the bitcode version information. Acc...

...gt; >> >> The first is to simply add a single 32bit wide field at the end of the >> existing bitcode wrapper format field. This would result in the new >> structure looking like this: >> >> [Magic_{32}, Version_{32}, Offset_{32}, Size_{32}, CPUType_{32}, >> BitcodeVersion_{32}] >> >> All of the existing fields would keep their current meanings, and the new >> field BitcodeVersion is simply appended with the format described in the >> first paragraph. >> >> A second idea was to use the existing Version field in the bitcode >>...

...; The first is to simply add a single 32bit wide field at the end of the >>> existing bitcode wrapper format field. This would result in the new >>> structure looking like this: >>> >>> [Magic_{32}, Version_{32}, Offset_{32}, Size_{32}, CPUType_{32}, >>> BitcodeVersion_{32}] >>> >>> All of the existing fields would keep their current meanings, and the >>> new field BitcodeVersion is simply appended with the format described in >>> the first paragraph. >>> >>> A second idea was to use the existing Version field...

...r > specification. > > > > The first is to simply add a single 32bit wide field at the end of the > existing bitcode wrapper format field. This would result in the new > structure looking like this: > > [Magic_{32}, Version_{32}, Offset_{32}, Size_{32}, CPUType_{32}, > BitcodeVersion_{32}] > > All of the existing fields would keep their current meanings, and the new > field BitcodeVersion is simply appended with the format described in the > first paragraph. > > A second idea was to use the existing Version field in the bitcode wrapper > format to store the...