llvm Trunk fails to build on DragonFly + patches

[Quuxplusone]

Bugzilla Link	PR17735
Status	RESOLVED INVALID
Importance	P normal
Reported by	Robin Hahling (robin.hahling@gw-computing.net)
Reported on	2013-10-30 06:21:03 -0700
Last modified on	2013-11-19 06:32:14 -0800
Version	trunk
Hardware	PC DragonFly BSD
CC	david.majnemer@gmail.com, llvm-bugs@lists.llvm.org
Fixed by commit(s)
Attachments	llvm-dragonfly.patch (2314 bytes, text/plain) crash-r191854.log (84248 bytes, text/x-log) crash-trunk-r193677.log (32242 bytes, text/x-log)
Blocks
Blocked by
See also

Created attachment 11445
patches required to build llvm on DragonFly

DragonFly is not able to build llvm anymore. It used to build fine up to at
least llvm 3.3. However, it required patches which I attached here.

We would be grateful if you incorporate theses patches. They are trivial and do
not affect others systems than DragonFly therefore they should not cause any
problems.

However, since at least revision 191854, llvm fails to build on DragonFly.
The getFrequency() method in include/llvm/Support/BlockFrequency.h from the
BlockFrequency class does not seem to return the correct type which leads
std::max to fail when called in include/llvm/Analysis/BlockFrequencyImpl.h with
errors such as:
error: no matching function for call to 'max(uint64_t&, long long unsigned int)'

Full stack trace attached with build attempts on r191854 and r193677.
To reproduce, simply try building llvm from a DragonFly host. Build attempts
where made with the current development version of DragonFly:  3.5-DEVELOPMENT
DragonFly v3.5.0.1265.gc05746-DEVELOPMENT

[Quuxplusone]

Attached llvm-dragonfly.patch (2314 bytes, text/plain): patches required to build llvm on DragonFly

[Quuxplusone]

Attached crash-r191854.log (84248 bytes, text/x-log): r191854 build attempt trace

[Quuxplusone]

Attached crash-trunk-r193677.log (32242 bytes, text/x-log): r193677 (trunk) build attempt trace

[Quuxplusone]

Please send llvm related patches to llvm-commits. As an aside, I do not see any changes to the CMake side of things. Does that Just Work (tm)?

[Quuxplusone]

Ok, I will do this.

There are no cmake changes necessary that we know of at this time.

[Quuxplusone]

Just an update: the patches have been merged into Trunk as of r193750. Therefore, there is no need to apply them anymore before attempting a build against Trunk and reproduce the bug described here.

[Quuxplusone]

It seems broken since r185236: http://lists.cs.uiuc.edu/pipermail/llvm-
commits/Week-of-Mon-20130624/179547.html

Unfortunately, r185237 (http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-
Mon-20130624/179552.html) does not fix the problem and it is this line in
include/llvm/Analysis/BlockFrequencyImpl.h that cause the build to break:

uint64_t N = std::max(BackFreq.getFrequency(), UINT64_C(1));

So it seems to me that BackFreq.getFrequency() does not return the correct type.
I'm pretty sure the fix should be simple but it does not stand out to me.

[Quuxplusone]

It actually was DragonFly BSD itself that required a fix. See http://gitweb.dragonflybsd.org/dragonfly.git/commitdiff/2a61a4766f203ace8a0d0ed677e146bd3959dd58

This issue can now be considered solved.