Relative to (Bryan Drewery Mon May 23 16:40:23 UTC 2016):

> A critical note to toolchain developers, or anyone who touches the Clang
> or GCC source files.  If you modify these files or add a new target
> architecture into Clang, please bump the revision in the appropriate file:
> Clang: lib/clang/include/clang/Basic/ FREEBSD_CC_VERSION
> GCC: gnu/usr.bin/cc/cc_tools/freebsd-native.h FBSD_CC_VER

quoting from :

> This relies on the macros being incremented whenever any change occurs
> to these compilers that warrant rebuilding files.  It also should never
> repeat earlier values.

It appears that someone that tries to make or test clang patches without using 
a committer bit to be the one updating the official source will have trouble 
meeting this criteria. I've been in that situation in the past. Reverting back 
to, say, CURRENT after a patch is adopted is another example of version number 
progression problems.

It may be that official value updates to FREEBSD_CC_VERSION should be spaced 
apart leaving versions available between official version numbers for such 
local activities without version identification conflicts.

There are also projects such as the /project/clang*-import ones that might have 
version number transition issues between it and CURRENT at various stages for 
those working on the project and anyone that is just following the project 
while it is active. I followed clang380-import and reported on some 
powerpc64/powerpc/armv6 issues during the project so I've been in this 
situation in the past.

It is not clear to me what the right things would have been to do and when to 
do it if this FREEBSD_CC_VERSION criteria had been in place at the time.

Similar comments probably apply to FBSD_CC_VER and gcc/g++.

Is it as simple as "never use WITH_SYSTEM_COMPILER" for patch/update 
explorations that are not yet official commits on CURRENT or STABLE? Does the 
version number involved then matter?

Mark Millard

_______________________________________________ mailing list
To unsubscribe, send any mail to ""

Reply via email to