[Bug 214902] head -r309179 buildworld on powerpc64 via clang 3.9.0: llvm::sys::CompareAndSwap and llvm::sys::MemoryFence undefined so build stops

[bugzilla-noreply]

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=214902

Dimitry Andric  changed:

   What|Removed |Added

   Assignee|freebsd-toolchain@FreeBSD.o |d...@freebsd.org
   |rg  |
 CC||d...@freebsd.org
 Status|New |In Progress
   Severity|Affects Only Me |Affects Some People

--- Comment #7 from Dimitry Andric  ---
Mark, can you please verify that r309656 fixes this particular build issue,
when building on PowerPC?  I don't have access to any PowerPC hardware.

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
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"

[Bug 215333] head -r310046 for powerpc family: sys/powerpc/powerpc/intr_machdep.c's i->trig == -1 if-tests reported as always false by compiler

[bugzilla-noreply]

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=215333

Mark Linimon  changed:

   What|Removed |Added

   Assignee|freebsd-b...@freebsd.org|freebsd-toolchain@FreeBSD.o
   ||rg

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
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"

[Bug 215333] head -r310046 for powerpc family: sys/powerpc/powerpc/intr_machdep.c's i->trig == -1 if-tests reported as always false by compiler

[bugzilla-noreply]

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=215333

Mark Linimon  changed:

   What|Removed |Added

   Assignee|freebsd-toolchain@FreeBSD.o |freebsd-b...@freebsd.org
   |rg  |

--- Comment #2 from Mark Linimon  ---
Submitter notes that this is more likely an issue of the src code itself.

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
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"

[Bug 215333] head -r310046 for powerpc family: sys/powerpc/powerpc/intr_machdep.c's i->trig == -1 if-tests reported as always false by compiler

[bugzilla-noreply]

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=215333

--- Comment #1 from Mark Millard  ---
(In reply to Mark Millard from comment #0)

This is more likely a kernel source code issue than a toolchain issue as far as
I know: It is  not a claim that the compiler's report is wrong.

More likely the source code violates a C rule in a way that the compiler is
allowed any handling. That handling can change with optimization level and
at some optimization levels it might appears to be working even though the
language standard makes no such guarantees.

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
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"

[Bug 215136] graphics/colmap: clang -O2 runs out of memory on i386 then aborts (i.e. not killed)

[bugzilla-noreply]

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=215136

Bug ID: 215136
   Summary: graphics/colmap: clang -O2 runs out of memory on i386
then aborts (i.e. not killed)
   Product: Ports & Packages
   Version: Latest
  Hardware: i386
OS: Any
Status: New
  Severity: Affects Only Me
  Priority: ---
 Component: Individual Port(s)
  Assignee: freebsd-ports-b...@freebsd.org
  Reporter: jbe...@freebsd.org
CC: freebsd-toolchain@FreeBSD.org

Created attachment 17
  --> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=17=edit
src/util/camera_specs.cc (preprocessed, compressed)

$ cd /usr/ports/graphics/colmap
$ rm files/patch-src_util_CMakeLists.txt
$ make
[...]
1.   parser at end of file
2.  Per-module optimization passes
3.  Running pass 'CallGraph Pass Manager' on module
'src/util/camera_specs.cc'.
4.  Running pass 'Value Propagation' on function
'@_ZN6colmap21InitializeCameraSpecsEv'
c++: error: unable to execute command: Abort trap
c++: error: clang frontend command failed due to signal (use -v to see
invocation)
FreeBSD clang version 3.4.1 (tags/RELEASE_34/dot1-final 208032) 20140512
Target: i386-unknown-freebsd10.1
Thread model: posix

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
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"

[Bug 215136] graphics/colmap: clang -O2 runs out of memory on i386 then aborts (i.e. not killed)

[bugzilla-noreply]

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=215136

--- Comment #1 from Jan Beich (mail not working)  ---
Created attachment 18
  --> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=18=edit
command line args (for clang 3.8+)

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
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"

[Bug 214904] head -r309179 clang 3.9.0 TARGET_ARCH=powerpc64 cross-built buildkernel stops for: rejected assembler notation

[bugzilla-noreply]

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=214904

--- Comment #2 from Mark Millard  ---
Created attachment 177812
  --> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=177812=edit
patch for contrib/llvm/lib/Target/PowerPC/PPCInstrInfo.td

Roman Divacky provided the patch and had me test it
on am old PowerMac G5 so-called "Quad Core". It
allowed hwpmc_e500.o to be built and the build to
then continue on to other things instead of
stopping.

(The svnlite diff output is mine in order to be a
comparison against a more modern version than roman
originally used --and so mine has a closer file line
number match.)

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
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"

[Bug 214904] head -r309179 clang 3.9.0 TARGET_ARCH=powerpc64 buildkernel stops for: rejected assembler notation in hwpmc_e500.c

[bugzilla-noreply]

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=214904

Mark Millard  changed:

   What|Removed |Added

Summary|head -r309179 clang 3.9.0   |head -r309179 clang 3.9.0
   |TARGET_ARCH=powerpc64   |TARGET_ARCH=powerpc64
   |cross-built buildkernel |buildkernel stops for:
   |stops for: rejected |rejected assembler notation
   |assembler notation  |in hwpmc_e500.c

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
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"

[Bug 215039] head -r309179 TARGET_ARCH=powerpc64 clang 3.9.0 based buildworld on powerpc64 using WITH_LLVM_LIBUNWIND= fails to build: asserts and rejects .S file contents

[bugzilla-noreply]

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=215039

--- Comment #2 from Mark Millard  ---
(In reply to Justin Hibbits from comment #1)

I have submitted llvm 31590 for the UnwindRegisters*.S related
syntax error reports. (Not covering libunwind.cpp's static assert
failure.)

While I placed it against llvm's/clang's powerpc support
initially my guess is they may reclassify it as against
libunwind's source.

(I did not find where to classify something as a libunwind
issue and I also took the point of view that their compiler
infrastructure was supposed to be able to parse their
project's source code.)

Of course they might end up declaring that
llvm/projects/libunwind/ is intentionally darwin-specific for
powerpc64 and powerpc and so only is expected to compile
for a darwin target relative to what they support. (I've
no clue of their policy/intent for such.)

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
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"

[Bug 215975] ThreadSanitizer lacks runtime in base

[bugzilla-noreply]

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=215975

Bug ID: 215975
   Summary: ThreadSanitizer lacks runtime in base
   Product: Base System
   Version: CURRENT
  Hardware: Any
OS: Any
Status: New
  Severity: Affects Only Me
  Priority: ---
 Component: bin
  Assignee: freebsd-toolchain@FreeBSD.org
  Reporter: jbe...@freebsd.org
 Flags: mfc-stable11?

$ pkg install -qy llvm39
$ echo 'int main() {}' >a.c

$ clang39 -fsanitize=thread a.c
$ cc -fsanitize=thread a.c
/usr/bin/ld: /usr/bin/../lib/clang/3.9.0/lib/freebsd/libclang_rt.tsan-x86_64.a:
No such file: No such file or directory
cc: error: linker command failed with exit code 1 (use -v to see invocation)

$ pkg info -xl llvm39 | fgrep tsan
/usr/local/llvm39/include/sanitizer/tsan_interface_atomic.h
/usr/local/llvm39/lib/clang/3.9.1/lib/freebsd/libclang_rt.tsan-x86_64.a
   
/usr/local/llvm39/lib/clang/3.9.1/lib/freebsd/libclang_rt.tsan-x86_64.a.syms
   
/usr/local/llvm39/lib/clang/3.9.1/lib/freebsd/libclang_rt.tsan_cxx-x86_64.a
   
/usr/local/llvm39/lib/clang/3.9.1/lib/freebsd/libclang_rt.tsan_cxx-x86_64.a.syms

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
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"

[Bug 215798] clang: please Include thread sanitizer (and all other available sanitizers)

[bugzilla-noreply]

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=215798

Dimitry Andric  changed:

   What|Removed |Added

 CC||jbe...@freebsd.org

--- Comment #2 from Dimitry Andric  ---
*** Bug 215975 has been marked as a duplicate of this bug. ***

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
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"

[Bug 215975] ThreadSanitizer lacks runtime in base

[bugzilla-noreply]

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=215975

Dimitry Andric  changed:

   What|Removed |Added

 Status|New |Closed
 CC||d...@freebsd.org
 Resolution|--- |DUPLICATE

--- Comment #1 from Dimitry Andric  ---
Same as bug 215798: ThreadSanitizer does not work on FreeBSD, unfortunately.
Somebody needs to do the work to get it functional.

*** This bug has been marked as a duplicate of bug 215798 ***

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
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"

[Bug 216012] /usr/lib/libgcc_s.so underlinks libc after r308308

[bugzilla-noreply]

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=216012

Bug ID: 216012
   Summary: /usr/lib/libgcc_s.so underlinks libc after r308308
   Product: Base System
   Version: CURRENT
  Hardware: Any
OS: Any
Status: New
  Keywords: regression
  Severity: Affects Only Me
  Priority: ---
 Component: bin
  Assignee: freebsd-toolchain@FreeBSD.org
  Reporter: jbe...@freebsd.org

Below example is a snippet from configure check in www/firefox. Rebuilding
world WITHOUT_LLVM_LIBUNWIND=1 makes the issue disappear.

$ pkg install -qy binutils fontconfig
$ mkdir gold
$ ln -s /usr/local/bin/ld.gold gold/ld
$ echo 'int main() {}' >a.c
$ cc -Bgold -L/usr/local/lib -lfontconfig a.c
/usr/lib/libgcc_s.so: error: undefined reference to 'free'
/usr/lib/libgcc_s.so: error: undefined reference to 'malloc'
/usr/lib/libgcc_s.so: error: undefined reference to '__stderrp'
/usr/lib/libgcc_s.so: error: undefined reference to 'memcpy'
/usr/lib/libgcc_s.so: error: undefined reference to 'getenv'
/usr/lib/libgcc_s.so: error: undefined reference to 'abort'
/usr/lib/libgcc_s.so: error: undefined reference to 'fflush'
/usr/lib/libgcc_s.so: error: undefined reference to 'memset'
/usr/lib/libgcc_s.so: error: undefined reference to '__assert'
/usr/lib/libgcc_s.so: error: undefined reference to 'snprintf'
/usr/lib/libgcc_s.so: error: undefined reference to 'fprintf'
/usr/lib/libgcc_s.so: error: undefined reference to 'fwrite'
cc: error: linker command failed with exit code 1 (use -v to see invocation)

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
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"

[Bug 216012] /usr/lib/libgcc_s.so underlinks libc breaking linking with ld.gold

[bugzilla-noreply]

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=216012

Jan Beich (mail not working)  changed:

   What|Removed |Added

Summary|/usr/lib/libgcc_s.so|/usr/lib/libgcc_s.so
   |underlinks libc after   |underlinks libc breaking
   |r308308 |linking with ld.gold
 Blocks||213480


Referenced Bugs:

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=213480
[Bug 213480] [exp-run] switch to compiler-rt & LLVM libunwind for libgcc_eh.a
and libgcc_s.so
-- 
You are receiving this mail because:
You are the assignee for the bug.
___
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"

[Bug 215969] c++ compiler regression

[bugzilla-noreply]

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=215969

Mark Linimon  changed:

   What|Removed |Added

   Assignee|freebsd-b...@freebsd.org|freebsd-toolchain@FreeBSD.o
   ||rg

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
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"

[Bug 215969] c++ compiler regression

[bugzilla-noreply]

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=215969

Dimitry Andric  changed:

   What|Removed |Added

 Status|New |In Progress
 CC||d...@freebsd.org

--- Comment #1 from Dimitry Andric  ---
This problem is caused by commit https://reviews.llvm.org/rL274049, as has been
reported in the upstream PR.

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
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"

[Bug 214863] lang/gcc + libc++ may fail due to spurious __cxa_throw_bad_array_new_length reference

[bugzilla-noreply]

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=214863

Dimitry Andric  changed:

   What|Removed |Added

 CC||b...@freebsd.org

--- Comment #8 from Dimitry Andric  ---
One question though: why are ports on 10.x using devel/libc++, while libc++ is
in base?  I would really like to understand the reasoning behind this.  IIRC
Baptiste added it, so I'm putting him on the CC list.

Another way to fix this would be to make the ports that use devel/libc++, also
use devel/libcxxrt, in which this problem has already been fixed.  E.g, change
the devel/libc++ port so the /usr/local/lib/c++/libstdc++.so linker scripts it
installs contains:

GROUP ( /usr/local/lib/libc++.so.1 /usr/local/lib/libcxxrt.so )

and add devel/libcxxrt as a dependency of devel/libc++.

This is far easier than an EN, and this workaround can be removed as soon as
9.x and 10.[12] reach end of life.  In fact, we should actively try to remove
the whole devel/libc++ and devel/libcxxrt ports in the future.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
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"

[Bug 214863] lang/gcc + libc++ may fail due to spurious __cxa_throw_bad_array_new_length reference

[bugzilla-noreply]

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=214863

--- Comment #9 from Baptiste Daroussin  ---
well this is a bug :)

They should not

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
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"

[Bug 214904] head -r309179 clang 3.9.0 TARGET_ARCH=powerpc64 cross-built buildkernel stops for: rejected assembler notation

[bugzilla-noreply]

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=214904

--- Comment #1 from Mark Millard  ---
(In reply to Mark Millard from comment #0)

I've now also tried this on a powerpc64 running a minor variant
of head -r309179 and it gets the same result that the amd64
cross build for TARGET_ARCH=powerpc64 does --unlike the
buildworld WITH_LIB32= issue now listed in bugzilla 215037.

Here it seems that the "BOOK E" specific instructions are
missing from the assembler notation that clang 3.9.0 supports
for TARGET_ARCH=powerpc64. There might be other non-classic
PowerPc instructions also missing for all I know.

I've sent a note asking Justin Hibbits what he thinks the
proper classification of this is. Does llvm need to support
the BOOK E specific instructions on the assembler notation
in order for FreeBSD to use clang as the system compiler?

Even if GENERIC64 could avoid including such things there
would still be the issue of how to allow more specialized
builds to target BOOK E (or other variants with special
instructions for the variant).

This may need a related llvm bugzilla submittal to be
listed in the:

[META] Using Clang as the FreeBSD/ppc system compiler

(25780 for llvm).

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
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"

[Bug 215684] ports-mgmt/poudriere-devel: fails to build native-xtools because of libllvmminimal

[bugzilla-noreply]

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=215684

Sylvain Garrigues  changed:

   What|Removed |Added

 Status|In Progress |Closed
 Resolution|--- |FIXED

--- Comment #6 from Sylvain Garrigues  ---
Problem solved for me with above commit.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
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"

[Bug 214855] head -r309179 TARGET_ARCH=powerpc64 clang 3.9.0 based cross build: powerpc.powerpc64/usr/src/tmp/usr/bin/ld: BFD 2.17.50 [FreeBSD] 2007-07-03 internal error

[bugzilla-noreply]

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=214855

--- Comment #2 from Mark Millard  ---
I retried with -r311147 and the failure repeated. clang 3.9.1 and the like
have not changed the behavior of the

/usr/obj/powerpc64vtsc_clang_world/powerpc.powerpc64/usr/src/tmp/usr/bin/ld

when it processes as.full .

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
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"

[Bug 215798] clang: please Include thread sanitizer (and all other available sanitizers)

[bugzilla-noreply]

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=215798

Mark Linimon  changed:

   What|Removed |Added

   Assignee|freebsd-b...@freebsd.org|freebsd-toolchain@FreeBSD.o
   ||rg
Summary|clang: Include thread   |clang: please Include
   |sanitizer (and all other|thread sanitizer (and all
   |available sanitizers)   |other available sanitizers)

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
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"

[Bug 215684] ports-mgmt/poudriere-devel: fails to build native-xtools because of libllvmminimal

[bugzilla-noreply]

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=215684

--- Comment #7 from commit-h...@freebsd.org ---
A commit references this bug:

Author: dim
Date: Fri Jan  6 22:09:00 UTC 2017
New revision: 311558
URL: https://svnweb.freebsd.org/changeset/base/311558

Log:
  MFC r311131:

  Make native-xtools build correctly after clang/llvm 3.9.0 import

  During the clang/llvm 3.9.0 import, the build structure for it was
  completely revamped.  This broke the native-xtools target.

  It first attempts to build libllvmminimal, then the llvm-tblgen and
  clang-tblgen executables, but these fail to link because they are linked
  to the 'full' libllvm by default, as they normally are during the
  'world' stage.

  To make these link against libllvmminimal instead, define TOOLS_PREFIX,
  similarly as during the bootstrap-tools phase.  The value itself is
  empty, as we don't really want to use a prefix.

  Reviewed by:  imp
  PR:   215684
  Differential Revision:https://reviews.freebsd.org/D9026

Changes:
_U  stable/11/
  stable/11/Makefile.inc1

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
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"

[Bug 215821] head -r311147's bootstrapped ld for TARGET_ARCH=powerpc64 produces kernel.full as a "shared object" for -pie instead of as a "executable": booting the produced kernel crashes

[bugzilla-noreply]

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=215821

Mark Linimon  changed:

   What|Removed |Added

 CC||ema...@freebsd.org
   Assignee|freebsd-b...@freebsd.org|freebsd-toolchain@FreeBSD.o
   ||rg

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
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"

[Bug 215819] head r311147's clang 3.9.1 for powerpc64: locore.o generation messed up: generates R_PPC64_ADDR16_DS instead of R_PPC64_TOC16_DS with .toc

[bugzilla-noreply]

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=215819

Mark Linimon  changed:

   What|Removed |Added

   Assignee|freebsd-b...@freebsd.org|freebsd-toolchain@FreeBSD.o
   ||rg

--- Comment #1 from Mark Linimon  ---
Reassign.

It doesn't look to me like r311147 has anything to do with clang, though?

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
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"

[Bug 215819] head r311147's clang 3.9.1 for powerpc64: locore.o generation messed up: generates R_PPC64_ADDR16_DS instead of R_PPC64_TOC16_DS with .toc

[bugzilla-noreply]

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=215819

--- Comment #2 from Mark Millard  ---
(In reply to Mark Linimon from comment #1)

-r311147 is just the version I tested. It does not
show how long the problem has existed.

Usually folks want to know if the current (or a recent)
build still has a problem before going further. Plus
it is more time and effort to back trace to the first
example.

In this case it is likely clang 3.9.0 and 3.9.1's whole
powerpc64 history in FreeBSD: effectively I've just
learned more about "already known to be broken" details
and reported them. There was prior list activity about
the bad register offsets such as 0(r2) but without the
R_PPC64_ADDR16_DS vs. R_PPC64_TOC16_DS information.

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
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"

[Bug 215798] clang: please Include thread sanitizer (and all other available sanitizers)

[bugzilla-noreply]

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=215798

Dimitry Andric  changed:

   What|Removed |Added

 CC||d...@freebsd.org

--- Comment #1 from Dimitry Andric  ---
The problem is that the thread sanitizer currently does not work on FreeBSD.

This has to do with the way thread sanitizer attempts to initialize very early
during program startup, and it conflicts with jemalloc's early initialization. 
This leads to an endless recursion, and a stack overflow.

For thread sanitizer to work properly, it looks like we will need some sort of
hook in libc, which can be used to initialize thread sanitizer before jemalloc
is initialized.  I have limited time, so I have not yet worked on this. 
Patches are welcome. :-)

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
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"

[Bug 215681] head -r310854: TARGET_ARCH=powerpc buildkernel via clang 3.9.1: sys/powerpc/aim/trap_subr32.S:409:2: error: too few operands for instruction

[bugzilla-noreply]

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=215681

Mark Linimon  changed:

   What|Removed |Added

   Keywords||patch
   Assignee|freebsd-toolchain@FreeBSD.o |freebsd-...@freebsd.org
   |rg  |

--- Comment #3 from Mark Linimon  ---
Apparently only one instruction is rejected by clang.  Submitter has included a
patch to the kernel source file /usr/src/sys/powerpc/aim/trap_subr32.S to fix
this.

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
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"

[Bug 214863] lang/gcc + libc++ may fail due to spurious __cxa_throw_bad_array_new_length reference

[bugzilla-noreply]

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=214863

--- Comment #14 from commit-h...@freebsd.org ---
A commit references this bug:

Author: jbeich
Date: Tue Jan  3 08:55:57 UTC 2017
New revision: 430446
URL: https://svnweb.freebsd.org/changeset/ports/430446

Log:
  cad/openvsp: drop 10.1 workaround (revert r428665) per EOL

  PR:   214863 215307
  Approved by:  portmgr blanket

Changes:
  head/cad/openvsp/Makefile

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
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"

[Bug 215649] clang version 3.9.1 Segmentation fault

[bugzilla-noreply]

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=215649

Mark Linimon  changed:

   What|Removed |Added

   Assignee|freebsd-b...@freebsd.org|freebsd-toolchain@FreeBSD.o
   ||rg

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
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"

[Bug 215649] clang version 3.9.1 Segmentation fault

[bugzilla-noreply]

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=215649

Dimitry Andric  changed:

   What|Removed |Added

 Status|New |In Progress
   Assignee|freebsd-toolchain@FreeBSD.o |d...@freebsd.org
   |rg  |
 CC||d...@freebsd.org,
   ||ema...@freebsd.org
URL||https://llvm.org/bugs/show_
   ||bug.cgi?id=30775

--- Comment #2 from Dimitry Andric  ---
This is most likely upstream LLVM PR 30775:
https://llvm.org/bugs/show_bug.cgi?id=30775

Unfortunately the preprocessed code doesn't compile with llvm trunk, so I'm
reducing the test case locally, to see whether it still reproduces.

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
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"

[Bug 215819] head r311147's clang 3.9.1 for powerpc64: locore.o generation messed up: generates R_PPC64_ADDR16_DS instead of R_PPC64_TOC16_DS with .toc

[bugzilla-noreply]

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=215819

--- Comment #3 from Mark Millard  ---
(In reply to Mark Millard from comment #0)

I found how to control the behavior based on
the assembler notation @toc being missing vs.
being present.

If llvm should change is strongly tied to llvm's criteria for
gcc compatibility relative to filling-in/defaulting omitted
@toc's in the assembler notation.

FreeBSD has the option of always being explicit with @toc in order
to avoid differences in handling of omitted notation.

So I've no clue if FreebSD wants to claim that a llvm change
is a requirement for using clang as the powerpc64 system compiler.

[The issue of the distinction is submittable to llvm either way.]

Details. . .

For:

   .section ".toc","aw"
tmpstk.L: .tc tmpstk[TC],tmpstk
. . .
   /* Set up the stack pointer */
   ld  %r1,tmpstk.L(%r2)

using devel/powerpc64-gcc gets:

# /usr/local/bin/powerpc64-unknown-freebsd12.0-gcc \   
  -c \ 
   
-x assembler-with-cpp \
  -pipe  \  
   
  locore64_simplified.S
locore64_simplified.S: Assembler messages:
locore64_simplified.S:80: Warning: assuming @toc on symbol

and produces (with R_PPC64_TOC16_DS for .toc):

# /usr/local/powerpc64-freebsd/bin/objdump -r locore64_simplified.o

locore64_simplified.o: file format elf64-powerpc-freebsd

RELOCATION RECORDS FOR [.text]:
OFFSET   TYPE  VALUE 
0028 R_PPC64_REL64 __tocbase+0x8000
0046 R_PPC64_TOC16_DS  .toc


RELOCATION RECORDS FOR [.toc]:
OFFSET   TYPE  VALUE 
 R_PPC64_ADDR64tmpstk


RELOCATION RECORDS FOR [.opd]:
OFFSET   TYPE  VALUE 
 R_PPC64_ADDR64.__start
0008 R_PPC64_TOC   *ABS*


By contrast clang is silent (cross compiler used):

# /usr/obj/powerpc64vtsc_clang_kernel/powerpc.powerpc64/usr/src/tmp/usr/bin/cc
\  -target
powerpc64-unknown-freebsd12.0 \
 
--sysroot=/usr/obj/powerpc64vtsc_clang_kernel/powerpc.powerpc64/usr/src/tmp \  
 
-B/usr/obj/powerpc64vtsc_clang_kernel/powerpc.powerpc64/usr/src/tmp/usr/bin \   
   
  -c \-x assembler-with-cpp \  
   
-pipe  \   
  locore64_simplified.S

and produces code with R_PPC64_ADDR16_DS for the .toc instead:

# /usr/local/powerpc64-freebsd/bin/objdump -r locore64_simplified.o | more  
locore64_simplified.o: file format elf64-powerpc-freebsd

RELOCATION RECORDS FOR [.text]:
OFFSET   TYPE  VALUE 
0028 R_PPC64_REL64 __tocbase+0x8000
0046 R_PPC64_ADDR16_DS  .toc


RELOCATION RECORDS FOR [.toc]:
OFFSET   TYPE  VALUE 
 R_PPC64_ADDR64tmpstk


RELOCATION RECORDS FOR [.opd]:
OFFSET   TYPE  VALUE 
 R_PPC64_ADDR64.__start
0008 R_PPC64_TOC   *ABS*



But for:

   .section ".toc","aw"
tmpstk.L: .tc tmpstk[TC],tmpstk
. . .
   /* Set up the stack pointer */
   ld  %r1,tmpstk.L@toc(%r2)

(note the @toc notation) both compilers agree and use
R_PPC64_TOC16_DS for the .toc:

# /usr/local/bin/powerpc64-unknown-freebsd12.0-gcc \   
  -c \ 
   
-x assembler-with-cpp \
  -pipe  \  
   
  locore64_simplified.S

# /usr/local/powerpc64-freebsd/bin/objdump -r locore64_simplified.o | more  
locore64_simplified.o: file format elf64-powerpc-freebsd

RELOCATION RECORDS FOR [.text]:
OFFSET   TYPE  VALUE 
0028 R_PPC64_REL64 __tocbase+0x8000
0046 R_PPC64_TOC16_DS  .toc


RELOCATION RECORDS FOR [.toc]:
OFFSET   TYPE  VALUE 
 R_PPC64_ADDR64tmpstk


RELOCATION RECORDS FOR [.opd]:

[Bug 215039] head -r309179 TARGET_ARCH=powerpc64 clang 3.9.0 based buildworld on powerpc64 using WITH_LLVM_LIBUNWIND= fails to build: asserts and rejects .S file contents

[bugzilla-noreply]

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=215039

Justin Hibbits  changed:

   What|Removed |Added

 CC||jhibb...@freebsd.org

--- Comment #1 from Justin Hibbits  ---
The naked 'r*' and 'f*' register designations are a Darwinism.  SysV notation
requires '%r*' and '%f*', or naked numbers.

This should probably be filed upstream as well.

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
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"

[Bug 215681] head -r310854: TARGET_ARCH=powerpc buildkernel via clang 3.9.1: sys/powerpc/aim/trap_subr32.S:409:2: error: too few operands for instruction

[bugzilla-noreply]

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=215681

--- Comment #1 from Mark Millard  ---
(In reply to Mark Millard from comment #0)

Noting the SRC_ENV_CONF in use for the amd64 -> powerpc cross buildkernel:

Script started on Sat Dec 31 00:15:10 2016
Command: env __MAKE_CONF=/root/src.configs/make.conf SRCCONF=/dev/null
SRC_ENV_CONF=/root/src.configs/src.conf.powerpc64-clang-bootstrap.amd64-host
WITH_META_MODE=yes MAKEOBJDIRPREFIX=/usr/obj/powerpc64vtsc_clang_kernel make -j
4 buildkernel


# more ~/src.configs/src.conf.powerpc-clang-bootstrap.amd64-host 
TO_TYPE=powerpc
#
KERNCONF=GENERICvtsc-NODBG
TARGET=${TO_TYPE}
.if ${.MAKE.LEVEL} == 0
TARGET_ARCH=${TO_TYPE}
.export TARGET_ARCH
.endif
#
WITH_CROSS_COMPILER=
WITHOUT_SYSTEM_COMPILER=
#
WITH_LIBCPLUSPLUS=
WITH_BINUTILS_BOOTSTRAP=
WITH_CLANG_BOOTSTRAP=
WITH_CLANG=
WITH_CLANG_IS_CC=
WITH_CLANG_FULL=
WITH_CLANG_EXTRAS=
# lldb requires missing atomic 8-byte operations for powerpc (non-64)
WITHOUT_LLDB=
#
WITH_BOOT=
WITHOUT_LIB32=
#
WITHOUT_ELFTOOLCHAIN_BOOTSTRAP=
WITHOUT_GCC_BOOTSTRAP=
WITHOUT_GCC=
WITHOUT_GCC_IS_CC=
WITHOUT_GNUCXX=
#
NO_WERROR=
#WERROR=
MALLOC_PRODUCTION=
#
WITH_DEBUG_FILES=

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
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"

[Bug 215684] ports-mgmt/poudriere-devel: fails to build native-xtools because of libllvmminimal

[bugzilla-noreply]

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=215684

--- Comment #3 from Sylvain Garrigues  ---
Also reproduced with ports-mgmt/poudriere in addition to ports-mgmt/poudriere 

So as of today, it seems it is no longer possible to create an armv6 poudriere
jail with "-x" (native-xtools)!

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
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"

[Bug 215684] ports-mgmt/poudriere-devel: fails to build native-xtools because of libllvmminimal

[bugzilla-noreply]

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=215684

Dimitry Andric  changed:

   What|Removed |Added

 Status|New |In Progress

--- Comment #4 from Dimitry Andric  ---
Submitted https://reviews.freebsd.org/D9026 for review.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
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"

[Bug 215684] ports-mgmt/poudriere-devel: fails to build native-xtools because of libllvmminimal

[bugzilla-noreply]

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=215684

--- Comment #5 from commit-h...@freebsd.org ---
A commit references this bug:

Author: dim
Date: Mon Jan  2 19:33:23 UTC 2017
New revision: 311131
URL: https://svnweb.freebsd.org/changeset/base/311131

Log:
  Make native-xtools build correctly after clang/llvm 3.9.0 import

  During the clang/llvm 3.9.0 import, the build structure for it was
  completely revamped.  This broke the native-xtools target.

  It first attempts to build libllvmminimal, then the llvm-tblgen and
  clang-tblgen executables, but these fail to link because they are linked
  to the 'full' libllvm by default, as they normally are during the
  'world' stage.

  To make these link against libllvmminimal instead, define TOOLS_PREFIX,
  similarly as during the bootstrap-tools phase.  The value itself is
  empty, as we don't really want to use a prefix.

  Reviewed by:  imp
  PR:   215684
  MFC after:3 days
  Differential Revision:https://reviews.freebsd.org/D9026

Changes:
  head/Makefile.inc1

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
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"

[Bug 214904] head -r309179 clang 3.9.0 TARGET_ARCH=powerpc64 buildkernel stops for: rejected assembler notation in hwpmc_e500.c

[bugzilla-noreply]

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=214904

--- Comment #3 from Mark Millard  ---
Comment on attachment 177812
  --> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=177812
patch for contrib/llvm/lib/Target/PowerPC/PPCInstrInfo.td

Roman Divacky reports that this patch is incomplete, quoting:

. . . the patch is not finished and I don't
have the time nor the resources (I would need to implement the scheduling
for that instruction) to finish it.

I just did it to let you continue your exploring. . . .

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
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"

[Bug 214971] clang + lld 3.9.1: Unhandled relocation 1031

[bugzilla-noreply]

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=214971

--- Comment #2 from Shawn Webb  ---
Ping.

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
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"

[Bug 215821] head -r311147's bootstrapped ld for TARGET_ARCH=powerpc64 produces kernel.full as a "shared object" for -pie instead of as a "executable": booting the produced kernel crashes

[bugzilla-noreply]

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=215821

Mark Millard  changed:

   What|Removed |Added

 Status|New |Closed
 Resolution|--- |DUPLICATE

--- Comment #2 from Mark Millard  ---
I mis-atttributed the cause of the address that the PowerMac G5 so-called
"Quad Core" showed for the bootstrapped binutils context this report was
about. That lead to other bad inferences.

It turns out that bugzilla 215819's issue controls the behavior of this
as well.

So I'm closing this one as a poorly attributed report that is actually
a duplicate of 215819 technically.

*** This bug has been marked as a duplicate of bug 215819 ***

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
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"

[Bug 215819] head r311147's clang 3.9.1 for powerpc64: locore.o generation messed up: generates R_PPC64_ADDR16_DS instead of R_PPC64_TOC16_DS with .toc

[bugzilla-noreply]

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=215819

--- Comment #6 from Mark Millard  ---
Created attachment 178691
  --> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=178691=edit
Have TOC_REF(...) in instructions use @toc notation for clang

Have TOC_REF(...) in instructions use @toc notation for clang 3.9.1 so
that clang does the right thing.

The one old use of TOC_REF in TOC_ENTRY does not get the @toc notation
use also have a TOC_NAME_FOR_REF(...) that does not get the @toc
notation. TOC_REF(...) in turn uses TOC_NAME_FOR_REF(...) .

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
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"

[Bug 215107] head -r309656 clang 3.9.0 for TARGET_ARCH=powerpc: -mminimal-toc rejected (missing llvm 19098 fix?)

[bugzilla-noreply]

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=215107

--- Comment #6 from Mark Millard  ---
Created attachment 178693
  --> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=178693=edit
Corrected patch to track compiler type

Since at least gcc 4.2.1 requires the -mminimal-toc usage
have the patch track the COMPILER_TYPE (gcc vs. not) for
if -mminimal-toc is used vs. not.

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
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"

[Bug 215455] AddressSanitizer unlike libc provides memalign() confusing consumers

[bugzilla-noreply]

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=215455

Jan Beich (mail not working)  changed:

   What|Removed |Added

Summary|AdressSanitizer provides|AddressSanitizer unlike
   |memalign() confusing|libc provides memalign()
   |consumers   |confusing consumers

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
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"

[Bug 215455] AddressSanitizer unlike libc provides memalign() confusing consumers

[bugzilla-noreply]

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=215455

Dimitry Andric  changed:

   What|Removed |Added

   Assignee|freebsd-toolchain@FreeBSD.o |d...@freebsd.org
   |rg  |
 Status|New |In Progress
 CC||d...@freebsd.org,
   ||ema...@freebsd.org

--- Comment #1 from Dimitry Andric  ---
This is similar to bug 215125, which is for mallinfo() and mallopt().  I
submitted an upstream review at https://reviews.llvm.org/D27654, still awaiting
approval.  I will submit something similar for this one.

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
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"

[Bug 215455] AdressSanitizer provides memalign() confusing consumers

[bugzilla-noreply]

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=215455

Bug ID: 215455
   Summary: AdressSanitizer provides memalign() confusing
consumers
   Product: Base System
   Version: CURRENT
  Hardware: Any
OS: Any
Status: New
  Severity: Affects Only Me
  Priority: ---
 Component: bin
  Assignee: freebsd-toolchain@FreeBSD.org
  Reporter: jbe...@freebsd.org

Some build systems test symbol availability without prototypes in case of
broken/incomplete headers or due to simplicity. For one, Firefox has
AC_CHECK_FUNCS(memalign) which fails on FreeBSD but defines HAVE_MEMALIGN with
ASan. The code can be unwrapped into the following:

  $ cat a.c
  char memalign();

  int main()
  {
  memalign();
  return 0;
  }

  $ cc a.c -fsanitize=address
  $ echo $?
  0

  $ cc a.c
  /tmp/a-294bd8.o: In function `main':
  a.c:(.text+0x12): undefined reference to `memalign'
  $ echo $?
  1

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
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"

[Bug 214971] clang + lld 3.9.1: Unhandled relocation 1031

[bugzilla-noreply]

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=214971

--- Comment #1 from Shawn Webb  ---
Created attachment 178114
  --> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=178114=edit
Fix RTLD

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
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"

[Bug 214863] lang/gcc + libc++ may fail due to spurious __cxa_throw_bad_array_new_length reference

[bugzilla-noreply]

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=214863

--- Comment #11 from Jan Beich (mail not working)  ---
What's portmgr's plan for quarterly? Will 2017Q1 still support 9.x, 10.1, 10.2
and tag RELEASE_9_EOL at the end?

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
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"

[Bug 214863] lang/gcc + libc++ may fail due to spurious __cxa_throw_bad_array_new_length reference

[bugzilla-noreply]

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=214863

--- Comment #12 from Antoine Brodin  ---
(In reply to Jan Beich (mail not working) from comment #11)
Unless the FreeBSD Security Officer changes his mind,  at 23:59 UTC December
31, 2016, FreeBSD 9.3, 10.1 and 10.2 will reach end-of-life and will no longer
be supported.

So 2017Q1 will not support those releases (unless so@ changes his mind).

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
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"

[Bug 216080] science/bddsolve: fails to build with libc++ 4.0

[bugzilla-noreply]

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=216080

--- Comment #4 from Ed Schouten  ---
Because the good() member function isn't the exact opposite of the fail()
member function. See the table at the bottom of this page:

http://en.cppreference.com/w/cpp/io/basic_ios/fail

Changing it to use good() alters the code's behaviour.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
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"

[Bug 216707] exp-run: Update lang/gcc from GCC 4.9 to GCC 5

[bugzilla-noreply]

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=216707

--- Comment #42 from Antoine Brodin  ---
Review at https://reviews.freebsd.org/D10081 should fix all devel/hs-c2hs and
devel/hs-gtk2hs-buildtools users.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
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"

[Bug 213732] lang/beignet: crashes with some OpenCL apps

[bugzilla-noreply]

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=213732

Dimitry Andric  changed:

   What|Removed |Added

 Resolution|--- |FIXED
 Status|In Progress |Closed

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
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"

[Bug 213732] lang/beignet: crashes with some OpenCL apps

[bugzilla-noreply]

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=213732

--- Comment #9 from commit-h...@freebsd.org ---
A commit references this bug:

Author: dim
Date: Sat Mar 25 12:29:15 UTC 2017
New revision: 315943
URL: https://svnweb.freebsd.org/changeset/base/315943

Log:
  MFC r315745:

  Cherry-pick libcxxrt commit 8a853717e61d5d55cbdf74d9d0a7545da5d5ff92:

  Author: David Chisnall 
  Date:   Wed Mar 22 12:27:08 2017 +

  Simplify some code.

  realloc() with a null pointer is equivalent to malloc, so we don't need
  to handle the two cases independently.

  Fixes #46

  This should help with lang/beignet and other programs, which expect
  __cxa_demangle(name, NULL, NULL, ) to return zero in status.

  PR:   213732

Changes:
_U  stable/10/
  stable/10/contrib/libcxxrt/typeinfo.cc
_U  stable/11/
  stable/11/contrib/libcxxrt/typeinfo.cc
_U  stable/9/
_U  stable/9/contrib/
_U  stable/9/contrib/libcxxrt/
  stable/9/contrib/libcxxrt/typeinfo.cc

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
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"

[Bug 213732] lang/beignet: crashes with some OpenCL apps

[bugzilla-noreply]

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=213732

--- Comment #7 from commit-h...@freebsd.org ---
A commit references this bug:

Author: dim
Date: Wed Mar 22 21:45:42 UTC 2017
New revision: 315745
URL: https://svnweb.freebsd.org/changeset/base/315745

Log:
  Cherry-pick libcxxrt commit 8a853717e61d5d55cbdf74d9d0a7545da5d5ff92:

  Author: David Chisnall 
  Date:   Wed Mar 22 12:27:08 2017 +

  Simplify some code.

  realloc() with a null pointer is equivalent to malloc, so we don't need
  to handle the two cases independently.

  Fixes #46

  This should help with lang/beignet and other programs, which expect
  __cxa_demangle(name, NULL, NULL, ) to return zero in status.

  PR:   213732
  MFC after:3 days

Changes:
  head/contrib/libcxxrt/typeinfo.cc

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
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"

[Bug 213732] lang/beignet: crashes with some OpenCL apps

[bugzilla-noreply]

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=213732

Dimitry Andric  changed:

   What|Removed |Added

 CC||d...@freebsd.org
 Status|Open|In Progress

--- Comment #8 from Dimitry Andric  ---
I will close this after r315745 has been MFCd.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
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"

[Bug 214855] head -r309179 TARGET_ARCH=powerpc64 clang 3.9.0 based cross build: powerpc.powerpc64/usr/src/tmp/usr/bin/ld: BFD 2.17.50 [FreeBSD] 2007-07-03 internal error

[bugzilla-noreply]

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=214855

Justin Hibbits  changed:

   What|Removed |Added

 CC||jhibb...@freebsd.org

--- Comment #4 from Justin Hibbits  ---
I saw this back in 2014 when I was making my first set of changes for the new
thread local storage relocations that clang uses.  I was never able to track
down the bug yet, and haven't tested to see if it manifests as well with newer
binutils.

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
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"

[Bug 214258] devel/openmp: spurious libm dependency

[bugzilla-noreply]

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=214258

--- Comment #13 from commit-h...@freebsd.org ---
A commit references this bug:

Author: jbeich
Date: Wed Mar 29 14:43:30 UTC 2017
New revision: 437204
URL: https://svnweb.freebsd.org/changeset/ports/437204

Log:
  devel/openmp: link libomp.so against -lm for clang 3.6+

  PR:   214258
  Submitted by: Yuta Satoh 
  Approved by:  portmgr blanket

Changes:
  head/devel/llvm-devel/Makefile
  head/devel/llvm-devel/files/openmp-patch-bug32279
  head/devel/llvm37/Makefile
  head/devel/llvm37/files/openmp-patch-bug32279
  head/devel/llvm38/Makefile
  head/devel/llvm38/files/openmp-patch-bug32279
  head/devel/llvm39/Makefile
  head/devel/llvm39/files/openmp-patch-bug32279
  head/devel/llvm40/Makefile
  head/devel/llvm40/files/openmp-patch-bug32279
  head/devel/openmp/Makefile
  head/devel/openmp/files/patch-bug32279

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
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"

[Bug 214971] clang + lld 3.9.1: Unhandled relocation 1031

[bugzilla-noreply]

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=214971

Ed Maste  changed:

   What|Removed |Added

 Status|New |In Progress
  Flags||mfc-stable9-,
   ||mfc-stable10-,
   ||mfc-stable11?

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
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"

[Bug 214258] devel/openmp: spurious libm dependency

[bugzilla-noreply]

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=214258

Konstantin Belousov  changed:

   What|Removed |Added

 CC||k...@freebsd.org

--- Comment #5 from Konstantin Belousov  ---
(In reply to Jan Beich (mail not working) from comment #4)
A library cannot 'pick up symbols without referencing them'.  The presence of
the the undefined references means that there are real references in the code.

Note that existence of libm.so as a separate shared object from libc is a minor
optimization.  The libm services are mandated by the C standard, so the
separate library is only a way to slighly reduce working set of the programs
that do not need them.  Linking it in is fine.

If you are so intolerate to the presence of -lm in the dependency list even
when symbols are not referenced, you can use '-Wl,--as-needed -lm
-Wl,--no-as-needed' construct to only record DT_NEEDED fro libm.so when
references actually exist.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
You are the assignee for the bug.
___
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"

[Bug 214258] devel/openmp: spurious libm dependency

[bugzilla-noreply]

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=214258

--- Comment #4 from Jan Beich (mail not working)  ---
Comment on attachment 179304
  --> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=179304
ports/devel/openmp/files/patch-link-libm.patch

The workaround isn't really correct. FreeBSD versions before 11.0 don't really
need -lm.

$ clang40 -fopenmp omp_hello.c
$ ldd a.out
a.out:
libomp.so => /usr/local/llvm40/lib/libomp.so (0x80081f000)
libc.so.7 => /lib/libc.so.7 (0x800aa3000)
libthr.so.3 => /lib/libthr.so.3 (0x800e5)

-- 
You are receiving this mail because:
You are the assignee for the bug.
You are on the CC list for the bug.
___
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"

[Bug 214258] devel/openmp: spurious libm dependency

[bugzilla-noreply]

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=214258

--- Comment #3 from Jan Beich (mail not working)  ---
To avoid maintenance burden it'd be nice if we fix base system regression
before FreeBSD 11.1-RELEASE. devel/openmp isn't the only -lomp provider.

$ fetch https://computing.llnl.gov/tutorials/openMP/samples/C/omp_hello.c

$ pkg install llvm37 llvm38 llvm39 llvm40 llvm-devel

$ find -s /usr/local -name libomp.so
/usr/local/lib/libomp.so
/usr/local/llvm-devel/lib/libomp.so
/usr/local/llvm37/lib/libomp.so
/usr/local/llvm38/lib/libomp.so
/usr/local/llvm39/lib/libomp.so
/usr/local/llvm40/lib/libomp.so

$ clang37 -fopenmp omp_hello.c
/usr/bin/ld: cannot find -lomp
clang-3.7: error: linker command failed with exit code 1 (use -v to see
invocation)

$ clang37 -fopenmp omp_hello.c $(llvm-config37 --ldflags)
/usr/local/llvm37/lib/libomp.so: undefined reference to `scalbnl'
/usr/local/llvm37/lib/libomp.so: undefined reference to `fmaxl'
/usr/local/llvm37/lib/libomp.so: undefined reference to `logbl'
/usr/local/llvm37/lib/libomp.so: undefined reference to `scalbnf'
/usr/local/llvm37/lib/libomp.so: undefined reference to `logb'
/usr/local/llvm37/lib/libomp.so: undefined reference to `logbf'
/usr/local/llvm37/lib/libomp.so: undefined reference to `scalbn'
clang-3.7: error: linker command failed with exit code 1 (use -v to see
invocation)

$ clang38 -fopenmp omp_hello.c
/usr/local/llvm38/lib/libomp.so: undefined reference to `scalbnl'
/usr/local/llvm38/lib/libomp.so: undefined reference to `fmaxl'
/usr/local/llvm38/lib/libomp.so: undefined reference to `logbl'
/usr/local/llvm38/lib/libomp.so: undefined reference to `scalbnf'
/usr/local/llvm38/lib/libomp.so: undefined reference to `logb'
/usr/local/llvm38/lib/libomp.so: undefined reference to `logbf'
/usr/local/llvm38/lib/libomp.so: undefined reference to `scalbn'
clang-3.8: error: linker command failed with exit code 1 (use -v to see
invocation)

$ clang39 -fopenmp omp_hello.c
/usr/local/llvm39/lib/libomp.so: undefined reference to `scalbnl'
/usr/local/llvm39/lib/libomp.so: undefined reference to `fmaxl'
/usr/local/llvm39/lib/libomp.so: undefined reference to `logbl'
/usr/local/llvm39/lib/libomp.so: undefined reference to `scalbnf'
/usr/local/llvm39/lib/libomp.so: undefined reference to `logb'
/usr/local/llvm39/lib/libomp.so: undefined reference to `logbf'
/usr/local/llvm39/lib/libomp.so: undefined reference to `scalbn'
clang-3.9: error: linker command failed with exit code 1 (use -v to see
invocation)

$ clang40 -fopenmp omp_hello.c
/usr/local/llvm40/lib/libomp.so: undefined reference to `scalbnl'
/usr/local/llvm40/lib/libomp.so: undefined reference to `fmaxl'
/usr/local/llvm40/lib/libomp.so: undefined reference to `logbl'
/usr/local/llvm40/lib/libomp.so: undefined reference to `scalbnf'
/usr/local/llvm40/lib/libomp.so: undefined reference to `logb'
/usr/local/llvm40/lib/libomp.so: undefined reference to `logbf'
/usr/local/llvm40/lib/libomp.so: undefined reference to `scalbn'
clang-4.0: error: linker command failed with exit code 1 (use -v to see
invocation)

$ clang-devel -fopenmp omp_hello.c
/usr/bin/ld: cannot find -lomp
clang-5.0: error: linker command failed with exit code 1 (use -v to see
invocation)

$ clang-devel -fopenmp omp_hello.c $(llvm-config-devel --ldflags)
/usr/local/llvm-devel/lib/libomp.so: undefined reference to `scalbnl'
/usr/local/llvm-devel/lib/libomp.so: undefined reference to `fmaxl'
/usr/local/llvm-devel/lib/libomp.so: undefined reference to `logbl'
/usr/local/llvm-devel/lib/libomp.so: undefined reference to `scalbnf'
/usr/local/llvm-devel/lib/libomp.so: undefined reference to `logb'
/usr/local/llvm-devel/lib/libomp.so: undefined reference to `logbf'
/usr/local/llvm-devel/lib/libomp.so: undefined reference to `scalbn'
clang-5.0: error: linker command failed with exit code 1 (use -v to see
invocation)

-- 
You are receiving this mail because:
You are on the CC list for the bug.
You are the assignee for the bug.
___
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"

[Bug 214258] devel/openmp: spurious libm dependency

[bugzilla-noreply]

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=214258

--- Comment #9 from Jan Beich (mail not working)  ---
Maybe but cc -E doesn't show any calls to __divdc3 et al.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
You are the assignee for the bug.
___
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"

[Bug 214258] devel/openmp: spurious libm dependency

[bugzilla-noreply]

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=214258

--- Comment #10 from Konstantin Belousov  ---
(In reply to Jan Beich (mail not working) from comment #9)
Why it should ?  The symbols like __divdc3 are referenced by a
compiler-generated code,  for instance the __divdc3 definition is
   complex double __divdc3 (double a, double b, double c, double d)
with the semantic of return ((a + i * b) / (c + i * d)), where i is imaginary
one.  The source code should contain complex division operation, not __divdc3
call, to get the reference.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
You are the assignee for the bug.
___
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"

[Bug 214258] devel/openmp: spurious libm dependency

[bugzilla-noreply]

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=214258

--- Comment #11 from Jan Beich (mail not working)  ---
Because if compiler emits undefined references the linker cannot be expected to
know when -lm is required. Looking at
contrib/llvm/tools/clang/lib/Driver/Tools.cpp there are already cases when -lm
is passed together with --no-as-needed. Maybe something like 
https://reviews.llvm.org/D5698 added one more case.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
You are the assignee for the bug.
___
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"

[Bug 217736] addr2line incorrectly resolves filename/lineno/function

[bugzilla-noreply]

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=217736

--- Comment #3 from Marat Radchenko  ---
Also, gimli (Rust addr2line implementation) was fixed and is now consistent
with binutils and llvm-symbolizer. So it seems like my testcase is valid, it's
addr2line implementations misbehaving.

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
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"

[Bug 217736] addr2line incorrectly resolves filename/lineno/function

[bugzilla-noreply]

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=217736

--- Comment #2 from Marat Radchenko  ---
I've sent a patch to elftoolchain that fixes filename/lineno resolving:
https://sourceforge.net/p/elftoolchain/tickets/545/#6d97 although elftoolchain
devs seem to be reacting kinda slowly.

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
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"

[Bug 217736] addr2line incorrectly resolves filename/lineno/function

[bugzilla-noreply]

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=217736

Ed Maste  changed:

   What|Removed |Added

   Assignee|freebsd-toolchain@FreeBSD.o |ema...@freebsd.org
   |rg  |

--- Comment #4 from Ed Maste  ---
(In reply to Marat Radchenko from comment #2)
Thank you for the patch - I've replied with a few comments over there. We
should be able to get this into FreeBSD in the next few days.

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
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"

[Bug 216707] exp-run: Update lang/gcc from GCC 4.9 to GCC 5

[bugzilla-noreply]

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=216707
Bug 216707 depends on bug 216843, which changed state.

Bug 216843 Summary: devel/hs-ncurses: fails to build with gcc5 or later
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=216843

   What|Removed |Added

 Status|In Progress |Closed
 Resolution|--- |FIXED

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
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"

[Bug 214904] head -r309179 clang 3.9.0 TARGET_ARCH=powerpc64 buildkernel stops for: rejected assembler notation in hwpmc_e500.c

[bugzilla-noreply]

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=214904

Justin Hibbits  changed:

   What|Removed |Added

 Resolution|--- |Overcome By Events
 Status|New |Closed
 CC||jhibb...@freebsd.org

--- Comment #4 from Justin Hibbits  ---
Fixed by the import of clang 4.0.0 (changes committed upstream to llvm)

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
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"

[Bug 216707] exp-run: Update lang/gcc from GCC 4.9 to GCC 5

[bugzilla-noreply]

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=216707

--- Comment #40 from Antoine Brodin  ---
Do not forget to copy files/patch-libc++ from gcc5 to fix the build with libc++
4.0,  and maybe the patch for aarch64 support too.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
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"

[Bug 214258] devel/openmp: spurious libm dependency

[bugzilla-noreply]

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=214258

Jan Beich (mail not working)  changed:

   What|Removed |Added

   See Also||https://bugs.llvm.org//show
   ||_bug.cgi?id=32279

-- 
You are receiving this mail because:
You are on the CC list for the bug.
You are the assignee for the bug.
___
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"

[Bug 214258] devel/openmp: spurious libm dependency

[bugzilla-noreply]

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=214258

--- Comment #8 from Konstantin Belousov  ---
(In reply to Jan Beich (mail not working) from comment #7)
Which means that libm is really needed.

-- 
You are receiving this mail because:
You are the assignee for the bug.
You are on the CC list for the bug.
___
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"

[Bug 217753] lld [llvm 4.0.0] Linker won't link on aarch64 (Error: Failed to open a.out)

[bugzilla-noreply]

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=217753

Jan Beich (mail not working)  changed:

   What|Removed |Added

 Status|New |Closed
 Resolution|--- |DUPLICATE

--- Comment #1 from Jan Beich (mail not working)  ---
Marking dup unless you can reproduce without qemu-user-static. lld works fine
on aarch64 reference machines[1].

[1] https://www.freebsd.org/internal/machines.html

*** This bug has been marked as a duplicate of bug 217189 ***

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
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"

[Bug 213732] lang/beignet: crashes with some OpenCL apps

[bugzilla-noreply]

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=213732

Jan Beich (mail not working)  changed:

   What|Removed |Added

 Status|New |Open
 CC||freebsd-toolchain@FreeBSD.o
   ||rg

--- Comment #6 from Jan Beich (mail not working)  ---
libcxxrt behavior doesn't even match libcxxabi (from LLVM). I've filed a bug:
https://github.com/pathscale/libcxxrt/issues/46

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
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"

[Bug 216707] exp-run: Update lang/gcc from GCC 4.9 to GCC 5

[bugzilla-noreply]

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=216707

--- Comment #52 from Gerald Pfeifer  ---
(In reply to Jan Beich from comment #51)
> Gerald, can you file a bug for lang/gcc 5.4.0 -> 6.3.0 update? If there's
> no there's nothing to fix which postpones the update indefinitely.

I absolutely will, Jan.

It's just that there is another change to the lang/gcc* port(s) I am
planning that'll need an -exp run first, or I would have already started
the GCC 5 -> 6 upgrade.  


Based on your request and the utter lack of _any_ negative feedback on
the update to GCC 5 (yeah!) I expedited this intermediary step and created
PR 218330 for an -exp run.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
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"

[Bug 216707] exp-run: Update lang/gcc from GCC 4.9 to GCC 5

[bugzilla-noreply]

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=216707

--- Comment #51 from Jan Beich  ---
Gerald, can you file a bug for lang/gcc 5.4.0 -> 6.3.0 update? If there's no
exp-run there's nothing to fix which postpones the update indefinitely.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
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"

[Bug 216707] exp-run: Update lang/gcc from GCC 4.9 to GCC 5

[bugzilla-noreply]

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=216707

--- Comment #46 from commit-h...@freebsd.org ---
A commit references this bug:

Author: gerald
Date: Sat Apr  1 15:03:22 UTC 2017
New revision: 437437
URL: https://svnweb.freebsd.org/changeset/ports/437437

Log:
  Update lang/gcc and hence the default version of GCC in the Ports
  Collection (requested by USE_GCC=yes and various USES=compiler
  invocations) from GCC 4.9.4 to GCC 5.4.

  files/patch-arm-support and files/patch-gcc_system.h have become
  obsolete.  New patches files/patch-arm-unwind-cxx-support and
  files/patch-libc++ help support arm targets and new libc++ in base.

  ONLY_FOR_ARCHS now also includes arm.

  A new option GRAPHITE_DESC, off by default for now, adds support for
  Graphite loop optimizations.

  Finally, conflicts with other lang/gcc* ports are adjusted suitably.

  In terms of changes for users, this upgrade brings the following:

  The default mode for C is now -std=gnu11 instead of -std=gnu89.
  New warning options -Wc90-c99-compat and -Wc99-c11-compat may
  prove useful on that front.

  The C++ front end now has full C++14 language support including
  C++14 variable templates, C++14 aggregates with non-static data
  member initializers, C++14 extended constexpr, and more.
  The Standard C++ Library (libstdc++) has full C++11 support and
  experimental full C++14 support.  It uses a new ABI by default.

  There have been significant improvements to inter-procedural optimizations
  and link-time optimization such as One Definition Rule based merging of C++
  types as well as register allocation.

  OpenMP 4.0 specification offloading features are now supported by the C,
  C++, and Fortran compilers.  Cilk Plus, an extension to the C and C++
  languages to support data and task parallelism, has been added as well.

  New warning options -Wswitch-bool, -Wlogical-not-parentheses,
  -Wbool-compare and -Wsizeof-array-argument may prove useful as
  may new preprocessor directives __has_include, __has_include_next,
  and __has_attribute.

  GCC can now be built as a shared library for embedding in other processes
  (such as interpreters), suitable for Just-In-Time compilation to machine
  code.  This provides a C API and a C++ wrapper API.

  Many code generation improvements for AArch64, ARM, support for
  AVX-512{BW,DQ,VL,IFMA,VBMI} and Intel MPX on x86-64, and generally
  improvements on many targets.

  The Local Register Allocator (LRA) now contains a rematerialization
  subpass and is able to reuse the PIC hard register on x86/x86-64 to
  improve performance of position independent code.

  https://gcc.gnu.org/gcc-5/changes.html has a more extensive set of
  changes and https://gcc.gnu.org/gcc-5/porting_to.html has a solid
  overview of issue you may encountering porting to this new version.

  PR: 216707, 218125
  Tested by:  antoine (-exp runs)
  Supported by:   jbeich, tcberner, and others

Changes:
  head/Mk/bsd.default-versions.mk
  head/lang/gcc/Makefile
  head/lang/gcc/distinfo
  head/lang/gcc/files/patch-arm-support
  head/lang/gcc/files/patch-arm-unwind-cxx-support
  head/lang/gcc/files/patch-gcc_system.h
  head/lang/gcc/files/patch-libc++
  head/lang/gcc/pkg-descr
  head/lang/gcc/pkg-plist
  head/lang/gcc49/Makefile
  head/lang/gcc5/Makefile
  head/lang/gcc5-devel/Makefile

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
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"

[Bug 216707] exp-run: Update lang/gcc from GCC 4.9 to GCC 5

[bugzilla-noreply]

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=216707

Gerald Pfeifer  changed:

   What|Removed |Added

  Flags|exp-run?, merge-quarterly?  |merge-quarterly+

--- Comment #47 from Gerald Pfeifer  ---
No objections including this in the quarterly branch, though given the
large number of dependent ports (cf. the next commit) may this be a little
intrusive/risky?  

I am not planning to do this myself, though; if for no other reason, then
shortage of time.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
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"

[Bug 216707] exp-run: Update lang/gcc from GCC 4.9 to GCC 5

[bugzilla-noreply]

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=216707

--- Comment #48 from commit-h...@freebsd.org ---
A commit references this bug:

Author: gerald
Date: Sat Apr  1 15:23:43 UTC 2017
New revision: 437439
URL: https://svnweb.freebsd.org/changeset/ports/437439

Log:
  Bump PORTREVISIONs for ports depending on the canonical version of GCC and
  lang/gcc which have moved from GCC 4.9.4 to GCC 5.4 (at least under some
  circumstances such as versions of FreeBSD or platforms).

  This includes ports
   - with USE_GCC=yes or USE_GCC=any,
   - with USES=fortran,
   - using using Mk/bsd.octave.mk which in turn has USES=fortran, and
   - with USES=compiler specifying openmp, nestedfct, c++11-lib, c++14-lang,
 c++11-lang, c++0x, c11, or gcc-c++11-lib.

  PR:   216707

Changes:
  head/archivers/kf5-karchive/Makefile
  head/archivers/paq/Makefile
  head/archivers/pxz/Makefile
  head/archivers/py-brotli/Makefile
  head/archivers/rvm/Makefile
  head/astro/geographiclib/Makefile
  head/astro/gpstk/Makefile
  head/astro/kstars/Makefile
  head/astro/libosmium/Makefile
  head/astro/nightfall/Makefile
  head/astro/opencpn/Makefile
  head/astro/qmapshack/Makefile
  head/astro/viking/Makefile
  head/astro/wcslib/Makefile
  head/astro/xtide/Makefile
  head/audio/audacity/Makefile
  head/audio/calf/Makefile
  head/audio/ccaudio2/Makefile
  head/audio/chromaprint/Makefile
  head/audio/codec2/Makefile
  head/audio/csound/Makefile
  head/audio/csound6/Makefile
  head/audio/deadbeef/Makefile
  head/audio/espeak/Makefile
  head/audio/firefly/Makefile
  head/audio/funktrackergold/Makefile
  head/audio/gbsplay/Makefile
  head/audio/gnuspeechsa/Makefile
  head/audio/gogglesmm/Makefile
  head/audio/idjc/Makefile
  head/audio/libsoxr/Makefile
  head/audio/murmur/Makefile
  head/audio/musescore/Makefile
  head/audio/musicpd/Makefile
  head/audio/ncmpcpp/Makefile
  head/audio/openal-soft/Makefile
  head/audio/openspc/Makefile
  head/audio/pragha/Makefile
  head/audio/pulseaudio/Makefile
  head/audio/py-karaoke/Makefile
  head/audio/py-tagpy/Makefile
  head/audio/qjackctl/Makefile
  head/audio/rosegarden/Makefile
  head/audio/sayonara/Makefile
  head/audio/schism/Makefile
  head/audio/smasher/Makefile
  head/audio/soundkonverter/Makefile
  head/audio/soundtouch/Makefile
  head/audio/spek/Makefile
  head/audio/tomahawk/Makefile
  head/audio/wxguitar/Makefile
  head/audio/xmms-gbsplay/Makefile
  head/benchmarks/himenobench/Makefile
  head/benchmarks/hpl/Makefile
  head/benchmarks/octave-forge-benchmark/Makefile
  head/benchmarks/phoronix-test-suite/Makefile
  head/benchmarks/polygraph/Makefile
  head/biology/bowtie/Makefile
  head/biology/cd-hit/Makefile
  head/biology/crux/Makefile
  head/biology/diamond/Makefile
  head/biology/fasttree/Makefile
  head/biology/jellyfish/Makefile
  head/biology/molden/Makefile
  head/biology/mopac/Makefile
  head/biology/ncbi-blast+/Makefile
  head/biology/plink/Makefile
  head/biology/psi88/Makefile
  head/biology/seqan-apps/Makefile
  head/biology/seqtools/Makefile
  head/biology/ssaha/Makefile
  head/biology/t_coffee/Makefile
  head/biology/tinker/Makefile
  head/cad/NASTRAN-95/Makefile
  head/cad/alliance/Makefile
  head/cad/calculix/Makefile
  head/cad/cura-engine/Makefile
  head/cad/elmerfem/Makefile
  head/cad/feappv/Makefile
  head/cad/freecad/Makefile
  head/cad/freehdl/Makefile
  head/cad/gmsh/Makefile
  head/cad/gspiceui/Makefile
  head/cad/kicad/Makefile
  head/cad/kicad-devel/Makefile
  head/cad/klayout/Makefile
  head/cad/libopencad/Makefile
  head/cad/librecad/Makefile
  head/cad/meshlab/Makefile
  head/cad/opencascade/Makefile
  head/cad/openscad/Makefile
  head/cad/openvsp/Makefile
  head/cad/pdnmesh/Makefile
  head/cad/qelectrotech/Makefile
  head/cad/sceptre/Makefile
  head/cad/scotch/Makefile
  head/cad/stepcode/Makefile
  head/cad/tochnog/Makefile
  head/chinese/ibus-libpinyin/Makefile
  head/chinese/ibus-pinyin/Makefile
  head/chinese/librime/Makefile
  head/chinese/opencc/Makefile
  head/chinese/pyzy/Makefile
  head/comms/aldo/Makefile
  head/comms/dabstick-radio/Makefile
  head/comms/efax-gtk/Makefile
  head/comms/ems-flasher/Makefile
  head/comms/fldigi/Makefile
  head/comms/freedv/Makefile
  head/comms/gnuradio/Makefile
  head/comms/gr-osmosdr/Makefile
  head/comms/qt5-serialbus/Makefile
  head/comms/sdr-wspr/Makefile
  head/comms/telldus-core/Makefile
  head/comms/trustedqsl/Makefile
  head/comms/uhd/Makefile
  head/comms/usrp/Makefile
  head/comms/wsjt/Makefile
  head/comms/wsjtx/Makefile
  head/comms/wspr/Makefile
  head/converters/pdf2djvu/Makefile
  head/databases/clickhouse/Makefile
  head/databases/evolution-data-server/Makefile
  head/databases/fastdb/Makefile
  head/databases/galera/Makefile
  head/databases/gigabase/Makefile
  head/databases/gnats4/Makefile
  head/databases/gomdb/Makefile
  head/databases/grass/Makefile
  head/databases/leveldb/Makefile
  head/databases/levigo/Makefile
  head/databases/mariadb-connector-c/Makefile
  

[Bug 216707] exp-run: Update lang/gcc from GCC 4.9 to GCC 5

[bugzilla-noreply]

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=216707

--- Comment #45 from Gerald Pfeifer  ---
(In reply to Antoine Brodin from comment #40)
> Do not forget to copy files/patch-libc++ from gcc5 to fix the build
> with libc++ 4.0,  and maybe the patch for aarch64 support too.

Yep, files/patch-libc++ has been in my local tree for two months
(exactly two months). :-)

As for aarch64, I plan on taking care of that very quickly after
the original commit.  (It's not a regression, but will be a nice
addition.)

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
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"

[Bug 218164] lang/gcc5: Bootstrap comparison failure

[bugzilla-noreply]

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=218164

Gerald Pfeifer  changed:

   What|Removed |Added

   Assignee|ger...@freebsd.org  |freebsd-toolchain@FreeBSD.o
   ||rg
  Flags|maintainer-feedback?(gerald |
   |@FreeBSD.org)   |

--- Comment #3 from Gerald Pfeifer  ---
(In reply to Michał "phoe" Herda from comment #2)
> I can build both gcc5 and gcc48 as long as I do not select bootstrapping 
> in config.

If anything, it's actually supposed to be the other way around,
boostrapping should be the safer option.

The error you see is GCC compiling itself repeatedly does not lead
to a consistent result as it should.

Clearly this does not happen for other SPARC targets of GCC, and I'm
afraid I won't be able to help with this.

(Luckily there is at least a workaround of disabling bootstrap, which
is the default for lang/gcc.)

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
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"

[Bug 217376] make buildworld exits with segfault

[bugzilla-noreply]

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=217376

Jan Beich  changed:

   What|Removed |Added

   Assignee|freebsd-b...@freebsd.org|freebsd-toolchain@FreeBSD.o
   ||rg

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
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"

[Bug 209413] c++ symbolic functions broken on arm

[bugzilla-noreply]

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=209413

Jan Beich  changed:

   What|Removed |Added

 Attachment #170167|text/x-csrc |text/plain
  mime type||

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
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"

[Bug 217376] make buildworld exits with segfault

[bugzilla-noreply]

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=217376

Dimitry Andric  changed:

   What|Removed |Added

   Assignee|freebsd-toolchain@FreeBSD.o |d...@freebsd.org
   |rg  |
 Status|New |In Progress
 CC||d...@freebsd.org

--- Comment #3 from Dimitry Andric  ---
I've tried reproducing your error with clang 5.0.0, 4.0.0, 3.9.0, 3.8.0 and
3.7.1, but for me your sample compiles just fine.  All these compiles don't
take a lot of memory either, so I think we can rule out crashes due to limited
RAM.

Maybe the /usr/obj/usr/src/tmp/usr/bin/cc executable was built with CPU options
which aren't valid for your hardware?  Are you able to get a backtrace and/or
some more detailed debugging information?

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
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"

[Bug 218808] www/firefox: usr/bin/ld: error: unknown argument: --warn-unresolved-symbols

[bugzilla-noreply]

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=218808

Jan Beich  changed:

   What|Removed |Added

 CC||freebsd-toolchain@FreeBSD.o
   ||rg
  Flags|maintainer-feedback?(gecko@ |maintainer-feedback+
   |FreeBSD.org)|

--- Comment #1 from Jan Beich  ---
(In reply to O. Hartmann from comment #0)
> I'm wondering about the error as it indicates a missing flag?

Probably. Firefox uses --ignore-unresolved-symbol (ld.bfd 2.26+ or ld.gold
2.28+) or --warn-unresolved-symbol to allow environ(7) in shared libraries
together with --no-undefined. This is a workaround for BSD libc, GNU libc is
unaffected.

$ cat a.c
#include 

void foo() {
  extern char **environ;
  for(int i = 0; environ[i] != NULL; i++)
printf("%s\n", environ[i]);
}

$ cc -fPIC -shared -Wl,-z,defs -o a.so a.c -B/usr/local/bin
-Wl,--ignore-unresolved-symbol,environ
$ cc -fPIC -shared -Wl,-z,defs -o a.so a.c -Wl,--warn-unresolved-symbols
/tmp/a-52cbc1.o: In function `foo':
a.c:(.text+0x12): warning: undefined reference to `environ'
a.c:(.text+0x32): warning: undefined reference to `environ'

http://searchfox.org/mozilla-central/rev/6e1c138a06a8/old-configure.in#662

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
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"

[Bug 218808] www/firefox: usr/bin/ld: error: unknown argument: --warn-unresolved-symbols

[bugzilla-noreply]

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=218808

--- Comment #2 from Jan Beich  ---
(In reply to Jan Beich from comment #1)
> --ignore-unresolved-symbol (ld.bfd 2.26+

Oops, since ld.bfd 2.24 but the flag came from NetBSD.

https://mail-index.netbsd.org/source-changes/2008/04/03/msg004439.html

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
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"

[Bug 217648] [lld 4.0.0] WITH_LLD_IS_LD Results

[bugzilla-noreply]

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=217648

--- Comment #3 from Shawn Webb  ---
Also, reproduce this by NOT installing the aarch64-binutils package and by
specifying CROSS_BINUTILS_PREFIX=/usr in the make arguments.

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
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"

[Bug 215969] c++ compiler regression

[bugzilla-noreply]

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=215969

Dimitry Andric  changed:

   What|Removed |Added

 Resolution|--- |FIXED
 Status|In Progress |Closed

--- Comment #3 from Dimitry Andric  ---
Clang 4.0.0 has been imported in r314564, and this contains upstream commit
r291955.

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
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"

[Bug 217753] lld [llvm 4.0.0] Linker won't link on aarch64 (Error: Failed to open a.out)

[bugzilla-noreply]

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=217753

Bug ID: 217753
   Summary: lld [llvm 4.0.0] Linker won't link on aarch64 (Error:
Failed to open a.out)
   Product: Base System
   Version: CURRENT
  Hardware: arm64
OS: Any
Status: New
  Severity: Affects Only Me
  Priority: ---
 Component: arm
  Assignee: freebsd-...@freebsd.org
  Reporter: wolfgang.me...@hob.de
CC: freebsd-toolchain@FreeBSD.org

Created attachment 180774
  --> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=180774=edit
Output for verbose compilation/linking (cc -v -Wl,--verbose conftest.c)

When trying to compile C sources on 12-CURRENT (aarch64) with the newly
integrated LLVM 4.0 toolchain the compilation fails with ld giving an error on
failing to open the executable file to be produced by the compilation. An empty
file with the executable name and a .tmpXXX suffix is produced by the
linking process.

This has been observed using poudriere jails with a FreeBSD 12-CURRENT for
aarch64 after integration of the llvm 4.0 toolchain (tested with base r314564
and base r315016) running on an amd64 host using qemu-user-static for arm64
execution.

How to reproduce:
Build poudriere jail for HEAD and aarch64 architecture.
Enter jail and try to compile typical configure test source (referred to as
conftest.c):

  int main()
  {
;
return 0;
  }

Compilation:
>cc conftest.c
Output:
/usr/bin/ld: error: failed to open a.out: Unknown error -1
cc: error: linker command failed with exit code 1 (use -v to see invocation)

An empty a.out.tmpXXX is produced.

This happens with qemu-aarch64-static 2.6.90.g20160728_1 ( ports r424575 ).
With qemu-aarch64-static 2.8.50.g20170307 ( ports r435636 ) I get a qemu error:
/usr/ports/emulators/qemu-user-static/work/qemu-bsd-user-c0989c8/tcg/tcg.c:2017:
tcg fatal error
cc: error: unable to execute command: Abort trap (core dumped)
cc: error: linker command failed due to signal (use -v to see invocation)

Using lld 3.9.0 on aarch64 poudriere jails works fine with either qemu-emulated
execution.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
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"

[Bug 217736] addr2line incorrectly resolves filename/lineno/function

[bugzilla-noreply]

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=217736

--- Comment #1 from Marat Radchenko  ---
Additional info on various addr2line implementations misbehaving on this
testcase: https://github.com/gimli-rs/addr2line/issues/35#issue-213881844

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
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"

[Bug 215969] c++ compiler regression

[bugzilla-noreply]

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=215969

Dominic Fandrey  changed:

   What|Removed |Added

 Resolution|FIXED   |---
 Status|Closed  |Open

--- Comment #4 from Dominic Fandrey  ---
stable/11 is still affected.

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
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"

[Bug 218861] libelf elf_update fails when adding sections

[bugzilla-noreply]

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=218861

--- Comment #1 from Eric McCorkle  ---
Review for fix: https://reviews.freebsd.org/D10487

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
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"

[Bug 219484] cad/openvsp: Fails to build with lang/gcc6 or later on 10.3 (< 11.0)

[bugzilla-noreply]

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=219484

Raphael Kubo da Costa  changed:

   What|Removed |Added

 CC||rak...@freebsd.org

--- Comment #17 from Raphael Kubo da Costa  ---
(In reply to fernando.apesteguia from comment #16)
>> Is this patch acceptable?
>
> .if ${OSVERSION} < 110

Note that you generally want to choose a more specific version that corresponds
more closely to the commit that imported the libc++ version with the new
overloads.

In any case, I think you can simplify the patch by just setting
USE_CXXSTD=gnu++11 -- GCC 6 builds with -std=gnu++14 by default, and the new
overloads were added in C++14. Since you only need C++11 to build the code you
can use an older standard. I've done that here and the port built fine on
10.3-i386 with GCC 6.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
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"

[Bug 219484] cad/openvsp: Fails to build with lang/gcc6 or later on 10.3 (< 11.0)

[bugzilla-noreply]

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=219484

Gerald Pfeifer  changed:

   What|Removed |Added

  Flags|merge-quarterly?|merge-quarterly-
 Resolution|--- |FIXED
 Status|In Progress |Closed

--- Comment #23 from Gerald Pfeifer  ---
Since the update to GGC 6 is never going to hit the quarterly branch
(and hardly going to land on trunk if dependent bugs keep being 
re-opened ), I do not see a need to backport this kind of change.

Nothing is broken in quarterly here.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
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"

[Bug 220590] math/fftw3: fails to build on armv6 (729 ports skipped)

[bugzilla-noreply]

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=220590

Jason E. Hale  changed:

   What|Removed |Added

 Status|In Progress |Closed
 Resolution|--- |FIXED

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
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"

[Bug 220590] math/fftw3: fails to build on armv6 (729 ports skipped)

[bugzilla-noreply]

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=220590

--- Comment #10 from commit-h...@freebsd.org ---
A commit references this bug:

Author: jhale
Date: Mon Jul 31 11:58:28 UTC 2017
New revision: 446955
URL: https://svnweb.freebsd.org/changeset/ports/446955

Log:
  Fix build on armv6. The -funsafe-math-optimizations flag in Clang (pulled in
by
  -ffast-math) is emitting references to the sincos() function which is not
  implemented on versions of FreeBSD < 1200032. Workaround by adding
  -fno-unsafe-math-optimizations to armv6 CFLAGS.

  /bin/sh ../libtool  --tag=CC   --mode=link /nxb-bin/usr/bin/cc -D_THREAD_SAFE
-pthread -O2 -pipe  -O3 -ffast-math -fstrict-aliasing -fomit-frame-pointer   -o
bench bench-bench.o bench-hook.o bench-fftw-bench.o
../threads/libfftw3_threads.la ../libfftw3.la ../libbench2/libbench2.a  -lm
  libtool: link: /nxb-bin/usr/bin/cc -D_THREAD_SAFE -pthread -O2 -pipe -O3
-ffast-math -fstrict-aliasing -fomit-frame-pointer -o .libs/bench bench-bench.o
bench-hook.o bench-fftw-bench.o  ../threads/.libs/libfftw3_threads.so
../.libs/libfftw3.so ../libbench2/libbench2.a -lm -pthread -Wl,-rpath
-Wl,/usr/local/lib
  ./libbench2/libbench2.a(verify-lib.o): In function `aphase_shift':
  verify-lib.c:(.text+0x578): undefined reference to `sincos'
  ./libbench2/libbench2.a(verify-lib.o): In function `tf_shift':
  verify-lib.c:(.text+0x13a0): undefined reference to `sincos'
  verify-lib.c:(.text+0x16e4): undefined reference to `sincos'
  cc: error: linker command failed with exit code 1 (use -v to see invocation)
  gmake[3]: *** [Makefile:400: bench] Error 1
  gmake[3]: Leaving directory
'/wrkdirs/usr/ports/math/fftw3/work/fftw-3.3.6-pl2/tests'
  gmake[2]: *** [Makefile:684: all-recursive] Error 1
  gmake[2]: Leaving directory
'/wrkdirs/usr/ports/math/fftw3/work/fftw-3.3.6-pl2'
  gmake[1]: *** [Makefile:549: all] Error 2
  gmake[1]: Leaving directory
'/wrkdirs/usr/ports/math/fftw3/work/fftw-3.3.6-pl2'
  *** Error code 1

  PR:   220590
  Submitted by: jbeich

Changes:
  head/math/fftw3/Makefile

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
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"

[Bug 220590] math/fftw3: fails to build on armv6 (729 ports skipped)

[bugzilla-noreply]

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=220590

--- Comment #11 from commit-h...@freebsd.org ---
A commit references this bug:

Author: jhale
Date: Mon Jul 31 12:16:28 UTC 2017
New revision: 446956
URL: https://svnweb.freebsd.org/changeset/ports/446956

Log:
  MFH: r446955

  Fix build on armv6. The -funsafe-math-optimizations flag in Clang (pulled in
by
  -ffast-math) is emitting references to the sincos() function which is not
  implemented on versions of FreeBSD < 1200032. Workaround by adding
  -fno-unsafe-math-optimizations to armv6 CFLAGS.

  /bin/sh ../libtool  --tag=CC   --mode=link /nxb-bin/usr/bin/cc -D_THREAD_SAFE
-pthread -O2 -pipe  -O3 -ffast-math -fstrict-aliasing -fomit-frame-pointer   -o
bench bench-bench.o bench-hook.o bench-fftw-bench.o
../threads/libfftw3_threads.la ../libfftw3.la ../libbench2/libbench2.a  -lm
  libtool: link: /nxb-bin/usr/bin/cc -D_THREAD_SAFE -pthread -O2 -pipe -O3
-ffast-math -fstrict-aliasing -fomit-frame-pointer -o .libs/bench bench-bench.o
bench-hook.o bench-fftw-bench.o  ../threads/.libs/libfftw3_threads.so
../.libs/libfftw3.so ../libbench2/libbench2.a -lm -pthread -Wl,-rpath
-Wl,/usr/local/lib
  ./libbench2/libbench2.a(verify-lib.o): In function `aphase_shift':
  verify-lib.c:(.text+0x578): undefined reference to `sincos'
  ./libbench2/libbench2.a(verify-lib.o): In function `tf_shift':
  verify-lib.c:(.text+0x13a0): undefined reference to `sincos'
  verify-lib.c:(.text+0x16e4): undefined reference to `sincos'
  cc: error: linker command failed with exit code 1 (use -v to see invocation)
  gmake[3]: *** [Makefile:400: bench] Error 1
  gmake[3]: Leaving directory
'/wrkdirs/usr/ports/math/fftw3/work/fftw-3.3.6-pl2/tests'
  gmake[2]: *** [Makefile:684: all-recursive] Error 1
  gmake[2]: Leaving directory
'/wrkdirs/usr/ports/math/fftw3/work/fftw-3.3.6-pl2'
  gmake[1]: *** [Makefile:549: all] Error 2
  gmake[1]: Leaving directory
'/wrkdirs/usr/ports/math/fftw3/work/fftw-3.3.6-pl2'
  *** Error code 1

  PR:   220590
  Submitted by: jbeich

  Approved by:  ports-secteam (blanket)

Changes:
_U  branches/2017Q3/
  branches/2017Q3/math/fftw3/Makefile

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
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"

[Bug 220590] math/fftw3: fails to build on armv6 (729 ports skipped)

[bugzilla-noreply]

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=220590

Kubilay Kocak  changed:

   What|Removed |Added

  Flags||merge-quarterly+

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
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"

[Bug 219484] cad/openvsp: Fails to build with lang/gcc6 or later on 10.3 (< 11.0)

[bugzilla-noreply]

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=219484

--- Comment #24 from commit-h...@freebsd.org ---
A commit references this bug:

Author: feld
Date: Thu Aug  3 15:13:32 UTC 2017
New revision: 447224
URL: https://svnweb.freebsd.org/changeset/ports/447224

Log:
  MFH: r446855

  Explicitly build with -std=gnu++11.

  This fixes the build with GCC 6, which switched its default from -std=gnu++98
  to -std=gnu++14. With this switch, it added a `operator delete(void*,
size_t)'
  overload and uses it for all delete calls. This does not play well with
  dependencies built with other compilers (such as base clang), which use the
old
  operator delete overload and cause linking errors.

  PR:   219484
  Submitted by: fernando.apesteg...@gmail.com (maintainer)

  Approved by:  ports-secteam (with hat)

Changes:
_U  branches/2017Q3/
  branches/2017Q3/cad/openvsp/Makefile

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
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"

[Bug 221423] gcc std::locale(LocaleName) crashes instead of throwing an exception

[bugzilla-noreply]

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=221423

Jan Beich  changed:

   What|Removed |Added

 CC||jbe...@freebsd.org

--- Comment #5 from Jan Beich  ---
Can you confirm the issue doesn't affect lang/gcc6 and lang/gcc7? The default
is going to change soon per bug 219275.

I can reproduce in a pristine jail with nothing but gcc5 installed. gcc49,
gcc48, gcc47, gcc46 are also affected.

(In reply to Mark Millard from comment #3)
> The compile/link command did not specify: -Wl,-rpath=...

Maybe -Wl,-rpath should be added to the specfile instead of relying on ldconfig
hints roulette. Not having sane defaults is a bug.

(In reply to Mark Millard from comment #3)
> mix of system and gcc libraries than gcc5

Tier1 and some Tier2 archs don't have system GCC anymore. It's enough to
install more than one lang/gcc* to get ambiguity about libstdc++ et al.

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
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"

[Bug 221423] gcc std::locale(LocaleName) crashes instead of throwing an exception

[bugzilla-noreply]

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=221423

--- Comment #8 from Mark Millard  ---
(In reply to Jan Beich from comment #5)

> Can you confirm the issue doesn't affect lang/gcc6 and lang/gcc7?
> The default is going to change soon per bug 219275.

I'm not sure which issue(s)/aspect(s) you are after,
so I pick the following to try to answer.

I strongly expect that an ldd on the original
context that was using std::locale(LocaleName)
would show something implying a mix of system
and gcc original definitions, where at run-time
a specific binding ends up being made. (But no
one has posted such ldd output for the failing
context(s).)

I expect that what is required is producing the
program and libraries it is bound to such that
that they avoid the mix and bind at run time to
the same implementation related materials as
they all were built with.

I expect that such applies to all lang/gcc*
examples, including gcc6 and gcc7 and the
older gcc5 (and before).

This hole area of bindings is a mess. Progressing
from gccN to gcc  is an example were if

-Wl,-rpath=/usr/local/lib/gccN

was used then it looks explicitly for files from:

/usr/local/lib/gccN/

and if lang/gccN is uninstalled they will not be
there to be found. It takes a rebuild or other
form of forced redirection to have it try looking
in:

/usr/local/lib/gcc/

instead. Even if it looks and finds a binding in
the new place it can try to use, the behavior need
not be compatible once bound.

Some types of system have a means of leaving the
libraries around for binding even when the compiler
and such is no long around for the version in
question.

Without -Wl,-rpath=/usr/local/lib/gccN involved
there are other issues. But sometimes the binding
that results happens to work better than does with
-rpath in use (since other libraries involved
were not set up for the -rpath libraries but,
say, system ones).

I'm not sure there is a universal, fixed answer to
which binding is better for the likes of (gcc6
example):

   libgcc_s.so.1 => /lib/libgcc_s.so.1 (0x800fbd000)
vs.
   libgcc_s.so.1 => /usr/local/lib/gcc6/libgcc_s.so.1 (0x800e06000)

but as things are the run-time binding is
controlled via use or not of the:

-Wl,-rpath=/usr/local/lib/gccN

Any set of libraries that is put to use in a program
but that ends up being originally based overall on a
mix of the two bindings (build time) is likely to end
up being a problem combination when one implementation
is actually bound.

However, as I understand it, that option does not
determine the use or not of the likes of:

   libcxxrt.so.1 => /lib/libcxxrt.so.1 (0x800b72000)

because a bunch of those bindings can instead be
found from the likes of:

   libstdc++.so.6 => /usr/local/lib/gcc6/libstdc++.so.6 (0x800844000)

if it is involved, even without a -rpath in the link.

Again a set of libraries used in a program but
that mix the original contexts is likely to
end up being a problem combination. (The
program needs to match as well.)

It appears that avoiding mixes is generally
(but not universally?) required (both for
libgcc_s alternative and for libcxxrt vs.
implicit in libstdc++ ).

In case an example makes it clearer:

For my libthr example: It appears to me that a program
using libstdc++ itself or in libraries would need a
libthr equivalent that had also been built based on
libstdc++ as libstdc++ is now constructed. Similarly
for any libgcc_s use by the libthr equivalent.

An alternate would be a libstdc++ that was built based
on the system libgcc_s and libcxxrt and so that libstdc++
did not provide various bindings to gcc specifics that
libstdc++ now does --and there would be no gcc based
libgcc_s in use. As I understand g++ and libstdc++ is
not designed for this sort of structure.

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
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"