FAST_DEPEND is now default

[Bryan Drewery]

WITH_FAST_DEPEND is now enabled by default for in-tree and out-of-tree
builds.  It no longer runs mkdep(1) during 'make depend', and the
'make depend' stage can safely be skipped now as it is auto ran
when building 'make all' and will generate all SRCS and DPSRCS before
building anything else.  Dependencies are gathered at compile time with
-MF flags kept in separate .depend files per object file.  Users should
run 'make cleandepend' once if using -DNO_CLEAN to clean out older
stale .depend files.

The option and mkdep(1) support will be removed in a few weeks.

-- 
Regards,
Bryan Drewery



signature.asc
Description: OpenPGP digital signature

Re: How to insist on only clang, for world/kernel?

[Chris H]

On Thu, 10 Mar 2016 21:49:01 -0700 Warner Losh  wrote

> make buildworld WITH_CLANG=t WITH_CLANG_BOOTSTRAP=t WITHOUT_GCC=y
> WITHOUT_GCC_BOOTSTRAP=t WITH_CLANG_IS_CC=t
> make buildkernel
> 
> But that's mostly default these days, so really most people get what you
> want by doing
> 
> make buildworld buildkernel
> 
> Warner
Thanks for the quick reply, Warner!
This is on RELENG_9, so I *don't* get that by default. ;)
But true. Everything else I run in on -CURRENT, and indeed gets
the options you indicate above out-of-the-box.

Thanks again, Warner.
> 
> On Thu, Mar 10, 2016 at 9:23 PM, Chris H  wrote:
> 
> > Greetings,
> >  A recent build/install world/kernel on a fresh 9-STABLE.
> > I was surprised to see that, while clang was also built,
> > gcc was used to perform the build for at least world.
> > I performed some research to definitively determine the
> > magic incantation for at least src.conf(5). However, I
> > found too many possibilities to be sure. So I'm here
> > to beg for the answer.
> >
> > The most likely candidates I have so far
> >
> > FAVORITE_COMPILER=clang
> > MAKE_COMPILER_TYPE=clang
> > WITH_CLANG=true
> > CC=clang
> > CXX=clang++
> > CPP=clang-cpp
> >
> > Thanks you.
> >

--Chris

--


___
freebsd-toolchain@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-toolchain
To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org"

Re: Running Clang 3.7 on Current....

[Dimitry Andric]

On 11 Mar 2016, at 10:27, Willem Jan Withagen  wrote:
> 
> CURRENT has recently received the upgrade to Clang 3.8.
> 
> Now I run into the problem that some of the tests with Ceph are all of a
> sudden failing
> Mainly manifesting itself because of access errors thru pointers in
> very complex records structs. (Which is almost always in C++ :) )
> Either pointers are 0x0, or to invalid memory.
> 
> This can be attributed to a few things, some of them:
>  - changes in the Ceph code
>   Which is possible since I rebased since I started using 3.8.
>  - Subtle difference in corner cases, and overlaping structs get written
>   wrongly.
>  - A compiler bug
>  - other issues 
> 
> Ceph is run thru extensive tests while building, after which there is another
> large QA testset run by the Ceph-team in their openstack with even more and
> complexer tests. So real programming "errors" would be caught in this process.
> 
> To exclude the compiler I'd like to run a compile/build/test run with 3.7
> Can I just install the ports 3.7 version without endangering my 3.8 current
> installation. Then it'll just be set 'CC=clang37 C++=clang37++ make' and
> see what comes of it.

Yes, that should work without any problems.

-Dimitry



signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: Ulrich Weigand has confirmed 3 of my 4 llvm bug submittals for clang 3.8.0 targeting powerpc/powerpc64. . .

[Mark Millard]

[Some more details confirmed.]

On 2016-Mar-9, at 12:24 PM, Mark Millard  wrote:
> 
> On 2016-Mar-9, at 11:16 AM, Mark Millard  wrote:
>> 
>> [He also includes a note about ELFV2 ABI for powerpc64le.]
>> 
>> Quoting llvm 26856 Comment 6 (he put the text in the 26856 submittal but the 
>> content also covers 26519 and most of 26844):
>> 
>>> Ulrich Weigand 2016-03-09 11:53:17 CST
>>> 
>>> Yes, there's indeed a couple of problems here, which affect different areas.
>>> 
>>> 1) On 32-bit ppc, LLVM violates the ABI by storing below the stack pointer 
>>> even though the ABI does not provide a "red zone".  This affects every 
>>> function with a stack frame, and could in theory lead to spurious crashes 
>>> when an asynchronous signal overwrites this area.  This seems to be a known 
>>> issue; the source code contains FIXME lines:
>>>   // FIXME: On PPC32 SVR4, we must not spill before claiming the stackframe.
>>> 
>>> 2) In some scenarios, registers may be spilled/restored twice to the stack. 
>>>  This happens because while most of the spilling happens in 
>>> PPCFrameLowering::spillCalleeSavedRegisters, a few selected registers are 
>>> also spilled in PPCFrameLowering::emitPrologue.  Those registers are the 
>>> frame pointer, base pointer, PIC base pointer, link register, and condition 
>>> code register.  For the latter two, code ensures that they can never be 
>>> spilled in both places (for CR, there is extra code in 
>>> spillCalleeSavedRegisters; for LR, the register is removed from SavedRegs 
>>> in determineCalleeSaves).
>>> 
>>> However, for FP, BP, and PBP, nothing ensures the registers are not spilled 
>>> twice.  It is probably *rare* for this to happen, because the register 
>>> allocator will not use those registers within the function if they're 
>>> needed for their special purpose, but it can happen in rare cases.  This 
>>> includes the case of a system unwinder routine that uses 
>>> __builtin_unwind_init, but could also include other routines that clobber 
>>> one of those registers, e.g. the following case:
>>> 
>>> void func (void);
>>> 
>>> void test (void)
>>> {
>>> func ();
>>> asm ("nop" : : : "31");
>>> }
>>> 
>>> When it happens that a register is spilled twice, the code as such still 
>>> works correctly, but the DWARF CFI unwind info associated with the routine 
>>> will be broken, which can mess up both C++ exception handling and debugging.
>>> 
>>> 3) For the specific case of system unwinder routines that use 
>>> __builtin_unwind_init and/or __builtin_eh_return, special things need to 
>>> happen in the prolog and epilog that are not required for any other 
>>> routine.  This in particular includes setting up save areas and CFI records 
>>> for the EH data registers (r3 ... r6).  [See bug #26844. ]  For the ELFv2 
>>> ABI (powerpc64le), it also include using three separate save areas for the 
>>> three caller-saved condition register fields, so that the EH logic can 
>>> overwrite their values independently.
>>> 
>>> None of this is currently implemented in LLVM, since on Linux generally GCC 
>>> is used to build the system unwind libraries, and no other code in the 
>>> system ever needs those special constructs.
>> 
>> 
>> ===
>> Mark Millard
>> markmi at dsl-only.net
> 
> One point of his note is wrong: when the 2nd "spill" of a register is after 
> it had been changed it makes a bigger difference. I commented back:
> 
> 
>> However, for FP, BP, and PBP, nothing ensures the registers are not spilled
>> twice.. . .
>> 
>> When it happens that a register is spilled twice, the code as such still
>> works correctly, but the DWARF CFI unwind info associated with the routine
>> will be broken, which can mess up both C++ exception handling and debugging.
> 
> 
> I will note that the Frame Pointer Register (r31) being saved again to the 
> same location but after it was adjusted to match the adjusted stack pointer 
> in the callee does not work correctly in that the restore of the Frame 
> Pointer for the return to the caller will restore the wrong pointer value.
> 
> If the caller then uses r31 without separately also restoring r31 first then 
> it will be addressing the wrong memory on the stack.
> 
> The observed/reported code sequence had the 2nd r31 store in the callee after 
> r31 had been adjusted to match the adjusted stack pointer in the callee.
> 
> So more than C++ exception handling and debugging is broken for the reported 
> code sequence.

The new comments are. . .

> Comment # 9 on bug 26856 from Ulrich Weigand
> (In reply to comment #8)
> 
> > (In reply to comment #6
> )
> > 
> > > However, for FP, BP, and PBP, nothing ensures the registers are not 
> > > spilled
> > > twice.. . .
> > > 
> > > When it happens that a register is spilled twice, the code as such still
> > > works correctly, but the DWARF CFI unwind info associated with the routine
> > > will be broken, which can mess up both C++ exception handling and 
> > > debugging.
> > 
> > 

Running Clang 3.7 on Current....

[Willem Jan Withagen]

Hi,

CURRENT has recently received the upgrade to Clang 3.8.

Now I run into the problem that some of the tests with Ceph are all of a
sudden failing
Mainly manifesting itself because of access errors thru pointers in
very complex records structs. (Which is almost always in C++ :) )
Either pointers are 0x0, or to invalid memory.

This can be attributed to a few things, some of them:
  - changes in the Ceph code
Which is possible since I rebased since I started using 3.8.
  - Subtle difference in corner cases, and overlaping structs get written
wrongly.
  - A compiler bug
  - other issues 

Ceph is run thru extensive tests while building, after which there is 
another

large QA testset run by the Ceph-team in their openstack with even more and
complexer tests. So real programming "errors" would be caught in this 
process.


To exclude the compiler I'd like to run a compile/build/test run with 3.7
Can I just install the ports 3.7 version without endangering my 3.8 current
installation. Then it'll just be set 'CC=clang37 C++=clang37++ make' and
see what comes of it.

Thanx,
--WjW


___
freebsd-toolchain@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-toolchain
To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org"