[Bug 192320] Use of thread_local produces linking errors on system version of clang++

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=192320 Tijl Coosemans t...@freebsd.org changed: What|Removed |Added CC||t...@freebsd.org

[Bug 192320] Use of thread_local produces linking errors on system version of clang++

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=192320 Dimitry Andric d...@freebsd.org changed: What|Removed |Added CC||d...@freebsd.org,

[Bug 192320] Use of thread_local produces linking errors on system version of clang++

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=192320 --- Comment #2 from David Chisnall thera...@freebsd.org --- I did write a __cxa_thread_atexit a while ago, but I haven't yet committed it (I'll try to find it). I didn't commit it because the semantics of _Thread_local are very poorly

[Bug 192303] C++11 std::list::remove_if() visits elements multiple times

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=192303 Tijl Coosemans t...@freebsd.org changed: What|Removed |Added CC||t...@freebsd.org

[Bug 192490] [build] race condition with multiple instances of cleandir in subdirectories; results in failure like rm: fts_read: No such file or directory

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=192490 yaneurab...@gmail.com changed: What|Removed |Added CC||freebsd-toolchain@FreeBSD.o

[Bug 192490] [build] race condition with multiple instances of cleandir in subdirectories; results in failure like rm: fts_read: No such file or directory

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=192490 Garrett Cooper n...@freebsd.org changed: What|Removed |Added CC||i...@freebsd.org,

[Bug 192490] [build] race condition with multiple instances of cleandir in subdirectories; results in failure like rm: fts_read: No such file or directory

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=192490 Warner Losh i...@freebsd.org changed: What|Removed |Added Status|Needs Triage|Issue Resolved

[Bug 192490] [build] race condition with multiple instances of cleandir in subdirectories; results in failure like rm: fts_read: No such file or directory

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=192490 Warner Losh i...@freebsd.org changed: What|Removed |Added Status|Issue Resolved |Needs MFC

[Bug 192490] [build] race condition with multiple instances of cleandir in subdirectories; results in failure like rm: fts_read: No such file or directory

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=192490 Garrett Cooper n...@freebsd.org changed: What|Removed |Added CC||h...@sendmail.cz

[Bug 192490] [build] race condition with multiple instances of cleandir in subdirectories; results in failure like rm: fts_read: No such file or directory

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=192490 Glen Barber g...@freebsd.org changed: What|Removed |Added Status|Needs MFC |Issue Resolved

[Bug 192490] [build] race condition with multiple instances of cleandir in subdirectories; results in failure like rm: fts_read: No such file or directory

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=192490 Garrett Cooper n...@freebsd.org changed: What|Removed |Added Status|Issue Resolved |In Discussion

[Bug 192490] [build] race condition with multiple instances of cleandir in subdirectories; results in failure like rm: fts_read: No such file or directory

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=192490 Garrett Cooper n...@freebsd.org changed: What|Removed |Added Assignee|i...@freebsd.org |i...@freebsd.org

[Bug 192490] [build] race condition with multiple instances of cleandir in subdirectories; results in failure like rm: fts_read: No such file or directory

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=192490 --- Comment #11 from Warner Losh i...@freebsd.org --- P.S. If you want to paper over it in a different way, you could add a '-' after the @ in the rm -rf ${CANONICALOBJDIR} line. That would cause errors to just be ignored. -- You are

[Bug 192320] Use of thread_local produces linking errors on system version of clang++

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=192320 --- Comment #3 from Steve Wills swi...@freebsd.org --- (In reply to David Chisnall from comment #2) Any status update on this? I've run into this issue too. -- You are receiving this mail because: You are the assignee for the bug.

[Bug 192320] Use of thread_local produces linking errors on system version of clang++

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=192320 --- Comment #5 from Tijl Coosemans t...@freebsd.org --- (In reply to David Chisnall from comment #4) That's what glibc seems to do. When a thread calls dlclose its thread_local variables are destroyed, but if there are other threads with

[Bug 192490] [build] race condition with multiple instances of cleandir in subdirectories; results in failure like "rm: fts_read: No such file or directory"

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=192490 Garrett Cooper,425-314-3911 changed: What|Removed |Added Resolution|---

[Bug 192320] Use of thread_local produces linking errors on system version of clang++

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=192320 Rudolf-Walter Kiss-Szakacs changed: What|Removed |Added CC|

[Bug 202914] make buildworld clang failure

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=202914 --- Comment #2 from duckbre...@yahoo.com --- (In reply to Dimitry Andric from comment #1) I resolved this issue by running make delete-old -- You are receiving this mail because: You are the assignee for the bug.

[Bug 202914] make buildworld clang failure

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=202914 Mark Linimon changed: What|Removed |Added Component|standards |kern -- You

[Bug 202914] make buildworld clang failure

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=202914 Raphael Kubo da Costa changed: What|Removed |Added Assignee|freebsd-standards@FreeBSD.o

[Bug 202914] make buildworld clang failure

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=202914 --- Comment #1 from Dimitry Andric --- This message: "fatal error: file '/usr/src/lib/clang/libllvmmipscodegen/../../../contrib/llvm/include/llvm/Support/Compiler.h' modified since it was first processed" seems to

[Bug 202914] make buildworld clang failure

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=202914 Dimitry Andric changed: What|Removed |Added Resolution|--- |Not A Bug

[Bug 203064] buildworld via external toolchain (clang) throws assertion

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=203064 Mark Linimon changed: What|Removed |Added Assignee|freebsd-b...@freebsd.org

[Bug 192320] Use of thread_local produces linking errors on system version of clang++

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=192320 Hannes Hauswedell changed: What|Removed |Added CC|

[Bug 205453] 11.0-CURRENT libcxxrt/guard.cc uses C11's _Static_assert in conditionally-compiled C++ code and when it is used buildworld fails for syntax errors in g++ compilers

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=205453 Mark Linimon changed: What|Removed |Added Assignee|freebsd-b...@freebsd.org

[Bug 205453] 11.0-CURRENT libcxxrt/guard.cc uses C11's _Static_assert in conditionally-compiled C++ code and when it is used buildworld fails for syntax errors in g++ compilers

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=205453 Dimitry Andric changed: What|Removed |Added CC|

[Bug 205453] 11.0-CURRENT libcxxrt/guard.cc uses C11's _Static_assert in conditionally-compiled C++ code and when it is used buildworld fails for syntax errors in g++ compilers

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=205453 --- Comment #3 from Mark Millard --- As for where _Static_assert and static_assert are gotten from: _Static_assert in C11 and static_assert in C++11 exist even for free-standing implementations. As I understand it is

[Bug 192320] Use of thread_local produces linking errors on system version of clang++

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=192320 Mikhail Teterin changed: What|Removed |Added CC|

[Bug 207253] cad/openvsp: Fix in 11-CURRENT

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=207253 Raphael Kubo da Costa changed: What|Removed |Added CC|

[Bug 207253] cad/openvsp: Fix in 11-CURRENT

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=207253 --- Comment #9 from Raphael Kubo da Costa --- I agree, but this is legacy software (version 3 doesn't even have its own array implementation anymore as far as I can see) that won't be changed upstream. My question is

[Bug 207253] cad/openvsp: Fix in 11-CURRENT

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=207253 --- Comment #8 from Dimitry Andric --- I think the program should not try to use both "using namespace std", and then use a reserved C++11 name. It should either drop the "using namespace std", or rename its own array to

[Bug 207253] cad/openvsp: Fix in 11-CURRENT

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=207253 --- Comment #10 from fernando.apesteg...@gmail.com --- (In reply to Raphael Kubo da Costa from comment #9) I think it is not doing the right thing. Have a look at this[1]. std::array is a feature introduced in C++11 and the software is not

[Bug 207253] cad/openvsp: Fix in 11-CURRENT

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=207253 --- Comment #16 from fernando.apesteg...@gmail.com --- Comment on attachment 167391 --> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=167391 Enclose array in a namespace I added two new poudriere logs for {9.3,10.2}amd64. I can

[Bug 207253] cad/openvsp: Fix in 11-CURRENT

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=207253 --- Comment #18 from fernando.apesteg...@gmail.com --- (In reply to Raphael Kubo da Costa from comment #17) Yes, please. And thanks to come up with the patch. -- You are receiving this mail because: You are on the CC list for the bug.

[Bug 207253] cad/openvsp: Fix in 11-CURRENT

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=207253 fernando.apesteg...@gmail.com changed: What|Removed |Added Attachment #167090|0 |1 is

[Bug 207253] cad/openvsp: Fix in 11-CURRENT

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=207253 Raphael Kubo da Costa changed: What|Removed |Added Attachment #167391|maintainer-approval?(fernan

[Bug 207253] cad/openvsp: Fix in 11-CURRENT

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=207253 --- Comment #19 from commit-h...@freebsd.org --- A commit references this bug: Author: rakuco Date: Thu Feb 25 22:21:38 UTC 2016 New revision: 409563 URL: https://svnweb.freebsd.org/changeset/ports/409563 Log: Add patches to fix the

[Bug 207253] cad/openvsp: Fix in 11-CURRENT

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=207253 Raphael Kubo da Costa changed: What|Removed |Added Assignee|freebsd-ports-bugs@FreeBSD.

[Bug 207253] cad/openvsp: Fix in 11-CURRENT

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=207253 Raphael Kubo da Costa changed: What|Removed |Added CC|

[Bug 207253] cad/openvsp: Fix in 11-CURRENT

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=207253 --- Comment #25 from David Chisnall --- Works for me: $ clang++ -c foo.cc $ clang++ -v FreeBSD clang version 3.4.1 (tags/RELEASE_34/dot1-final 208032) 20140512 Target: x86_64-unknown-freebsd10.2 Thread model: posix

[Bug 207253] cad/openvsp: Fix in 11-CURRENT

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=207253 --- Comment #28 from David Chisnall --- Ah, I see. It would have helped if your reduced test case had used #include instead of #include . -- You are receiving this mail because: You are on the CC list for the bug.

[Bug 207253] cad/openvsp: Fix in 11-CURRENT

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=207253 --- Comment #27 from fernando.apesteg...@gmail.com --- (In reply to David Chisnall from comment #25) In 10.2 and below OpenVSP compiles without these modifications. It is in 11-CURRENT where it started to fail when we landed the new

[Bug 207253] cad/openvsp: Fix in 11-CURRENT

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=207253 --- Comment #26 from Raphael Kubo da Costa --- Well, that's FreeBSD 10.2, where the port was already working. The problem only happens in HEAD after a newer libc++ was imported. -- You are receiving this mail because:

[Bug 207253] cad/openvsp: Fix in 11-CURRENT

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=207253 David Chisnall changed: What|Removed |Added CC|

[Bug 207253] cad/openvsp: Fix in 11-CURRENT

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=207253 --- Comment #22 from Raphael Kubo da Costa --- (In reply to David Chisnall from comment #21) > This patch looks more complicated than it needs to be. Wouldn't inserting: > > using ::array; > > Immediately after the

[Bug 207837] www/firefox: clang34 and clang35 crash on i386 with -O2 -fstack-protector

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=207837 --- Comment #4 from Jan Beich --- (In reply to Vikash Badal from comment #0) > c++: note: diagnostic msg: Error generating preprocessed source(s). This probably means we have to shave

[Bug 207837] www/firefox: clang34 and clang35 crash on i386 with -O2 -fstack-protector (OPTIMIZED_CFLAGS=off)

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=207837 Jan Beich changed: What|Removed |Added Summary|www/firefox: clang34 and|www/firefox:

[Bug 207837] www/firefox: clang34 and clang35 crash on i386 with -O2 -fstack-protector (OPTIMIZED_CFLAGS=off)

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=207837 --- Comment #10 from commit-h...@freebsd.org --- A commit references this bug: Author: jbeich Date: Sun Mar 13 15:17:03 UTC 2016 New revision: 410995 URL: https://svnweb.freebsd.org/changeset/ports/410995 Log: MFH: r410973

[Bug 207837] www/firefox: clang34 and clang35 crash on i386 with -O2 -fstack-protector (OPTIMIZED_CFLAGS=off)

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=207837 --- Comment #14 from Jan Beich --- (In reply to Dimitry Andric from comment #13) OPTIMIZED_CFLAGS is enabled by default. It doesn't pass just -O3 but also --enable-optimize which lets vendor decide whether to pass

[Bug 207837] www/firefox: clang34 and clang35 crash on i386 with -O2 -fstack-protector (OPTIMIZED_CFLAGS=off)

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=207837 --- Comment #16 from commit-h...@freebsd.org --- A commit references this bug: Author: dim Date: Sun Mar 13 18:32:18 UTC 2016 New revision: 296801 URL: https://svnweb.freebsd.org/changeset/base/296801 Log: Pull in r219512 from upstream

[Bug 207837] www/firefox: clang34 and clang35 crash on i386 with -O2 -fstack-protector (OPTIMIZED_CFLAGS=off)

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=207837 --- Comment #12 from Dimitry Andric --- Strangely, I tried building www/firefox on stable/10, from before r410973 was applied, and it builds just fine for me, even the problematic Unified_cpp_protocol_websocket0.cpp file.

[Bug 207837] www/firefox: clang34 and clang35 crash on i386 with -O2 -fstack-protector (OPTIMIZED_CFLAGS=off)

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=207837 --- Comment #9 from commit-h...@freebsd.org --- A commit references this bug: Author: jbeich Date: Sun Mar 13 14:42:59 UTC 2016 New revision: 410973 URL: https://svnweb.freebsd.org/changeset/ports/410973 Log: www/firefox: work around

[Bug 207837] www/firefox build fails on i386

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=207837 Jan Beich changed: What|Removed |Added CC|

[Bug 207837] www/firefox build fails on i386

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=207837 --- Comment #2 from Vikash Badal --- no sure how to obtain this info lldb37 c++.core (lldb) bt error: invalid process please advise -- You are receiving this mail because: You are on the CC list for the

[Bug 207837] www/firefox: clang34 and clang35 crash on i386 with -O2 -fstack-protector (OPTIMIZED_CFLAGS=off)

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=207837 Jan Beich changed: What|Removed |Added CC||jbe...@freebsd.org

[Bug 207837] www/firefox: clang34 and clang35 crash on i386 with -O2 -fstack-protector (OPTIMIZED_CFLAGS=off)

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=207837 --- Comment #7 from Vikash Badal --- (In reply to Jan Beich from comment #3) I tried adding OPTIMIZED_CFLAGS=on to the make.conf for the poudriere jail ---Begin make.conf--- MACHINE=i386 MACHINE_ARCH=i386

[Bug 205453] 11.0-CURRENT libcxxrt/guard.cc uses C11's _Static_assert in conditionally-compiled C++ code and when it is used buildworld fails for syntax errors in g++ compilers

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=205453 Dimitry Andric changed: What|Removed |Added Status|New |Closed

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

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=209413 Sylvain Garrigues changed: What|Removed |Added CC|

[Bug 211864] [Regression] Compiler is using AVX instructions for CPUTYPE=btver1

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=211864 Baptiste Daroussin changed: What|Removed |Added CC|

[Bug 193594] stddef.h should define max_align_t

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=193594 Vladimir Krstulja changed: What|Removed |Added Depends on|

[Bug 193594] stddef.h should define max_align_t

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=193594 Ed Schouten changed: What|Removed |Added CC||e...@freebsd.org

[Bug 211864] Compiler is using AVX instructions for CPUTYPE=btver1

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=211864 Kubilay Kocak changed: What|Removed |Added Keywords||needs-qa

[Bug 211864] LLVM is using AVX instructions for CPUTYPE=btver1 (AMD Bobcat)

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=211864 --- Comment #3 from Michel Depeige --- Quick follow : I'm trying to rebuild the world with the patch applied, but the box is overheating. I'm trying to sort that out before winter :) -- You are receiving this

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

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=216707 Bug ID: 216707 Summary: exp-run: Update lang/gcc from GCC 4.9 to GCC 5 Product: Ports & Packages Version: Latest Hardware: Any OS: Any Status: New

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

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=216707 --- Comment #22 from Gerald Pfeifer --- (In reply to commit-hook from comment #21) > New revision: 433484 > URL: https://svnweb.freebsd.org/changeset/ports/433484 > > Log: > lang/gprolog: pass -O3 to unbreak with gcc5

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

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=216707 --- Comment #21 from commit-h...@freebsd.org --- A commit references this bug: Author: jbeich Date: Mon Feb 6 10:55:32 UTC 2017 New revision: 433484 URL: https://svnweb.freebsd.org/changeset/ports/433484 Log: lang/gprolog: pass -O3 to

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

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=216707 --- Comment #24 from Jan Beich (mail not working) --- (In reply to Gerald Pfeifer from comment #22) > Usually I would have expected this to be fixed with a _lower_ optimization > level (so -O1), Both -O1 and -O3 fix

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

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=216707 --- Comment #14 from commit-h...@freebsd.org --- A commit references this bug: Author: jbeich Date: Sun Feb 5 07:52:23 UTC 2017 New revision: 433381 URL: https://svnweb.freebsd.org/changeset/ports/433381 Log: graphics/bugle: unbreak

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

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=216707 Jan Beich (mail not working) changed: What|Removed |Added Depends on|

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

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=216707 --- Comment #13 from commit-h...@freebsd.org --- A commit references this bug: Author: jbeich Date: Sun Feb 5 07:18:56 UTC 2017 New revision: 433376 URL: https://svnweb.freebsd.org/changeset/ports/433376 Log:

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

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=216707 Bug 216707 depends on bug 216810, which changed state. Bug 216810 Summary: devel/tigcc: fails to build with gcc5 or later https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=216810 What|Removed |Added

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

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=216707 --- Comment #12 from commit-h...@freebsd.org --- A commit references this bug: Author: jbeich Date: Sun Feb 5 04:36:23 UTC 2017 New revision: 433350 URL: https://svnweb.freebsd.org/changeset/ports/433350 Log: sysutils/shim: unbreak

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

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=216707 Jan Beich (mail not working) changed: What|Removed |Added Depends on|

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

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=216707 --- Comment #7 from commit-h...@freebsd.org --- A commit references this bug: Author: jbeich Date: Sun Feb 5 03:30:08 UTC 2017 New revision: 433342 URL: https://svnweb.freebsd.org/changeset/ports/433342 Log: lang/gcl: use clang and

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

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=216707 Jan Beich (mail not working) changed: What|Removed |Added Depends on|

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

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=216707 --- Comment #10 from commit-h...@freebsd.org --- A commit references this bug: Author: jbeich Date: Sun Feb 5 03:30:33 UTC 2017 New revision: 433345 URL: https://svnweb.freebsd.org/changeset/ports/433345 Log: emulators/raine: partially

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

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=216707 --- Comment #9 from commit-h...@freebsd.org --- A commit references this bug: Author: jbeich Date: Sun Feb 5 03:30:25 UTC 2017 New revision: 433344 URL: https://svnweb.freebsd.org/changeset/ports/433344 Log: games/wizznic: use clang

[Bug 216878] BSD readelf -d output is slightly incompatible with GNU readelf

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=216878 Bug ID: 216878 Summary: BSD readelf -d output is slightly incompatible with GNU readelf Product: Ports & Packages Version: Latest Hardware: Any OS:

[Bug 216878] BSD readelf -d output is slightly incompatible with GNU readelf

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=216878 Jan Beich (mail not working) changed: What|Removed |Added Assignee|freebsd-b...@freebsd.org

[Bug 216878] BSD readelf -d output is slightly incompatible with GNU readelf

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=216878 Jan Beich (mail not working) changed: What|Removed |Added CC|freebsd-toolchain@FreeBSD.o

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

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=216707 --- Comment #26 from Antoine Brodin --- New failures on 11.0 amd64: + {"origin"=>"devel/hs-ncurses", "pkgname"=>"hs-ncurses-0.2.15", "phase"=>"build", "errortype"=>"???"} + {"origin"=>"lang/yap",

[Bug 216878] BSD readelf -d output is slightly incompatible with GNU readelf

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=216878 --- Comment #1 from Ed Maste --- Added ELF Tool Chain ticket: https://sourceforge.net/p/elftoolchain/tickets/544/ Note that elfutils eu-readelf does not include parentheses: % eu-readelf -d /bin/ls Dynamic segment

[Bug 216878] BSD readelf -d output is slightly incompatible with GNU readelf

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=216878 --- Comment #2 from Baptiste Daroussin --- Note that this was already raised in the past and the result of the discussion was this won't change iirc and we adapted the readelf consumers in base and the ports framework for

[Bug 216878] BSD readelf -d output is slightly incompatible with GNU readelf

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=216878 --- Comment #3 from Ed Maste --- (In reply to Baptiste Daroussin from comment #2) Do you have a link to that discussion? I recall that we had it, but can't find it now. -- You are receiving this mail because: You are

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

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=216707 6year...@gmail.com changed: What|Removed |Added CC||6year...@gmail.com ---

[Bug 216908] security/gnutls: does not build on 12-CURRENT aarch64 after llvm 3.9 toolchain integration

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=216908 --- Comment #3 from commit-h...@freebsd.org --- A commit references this bug: Author: emaste Date: Wed Feb 8 20:31:54 UTC 2017 New revision: 313458 URL: https://svnweb.freebsd.org/changeset/base/313458 Log: lld: Allow arbitrary code

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

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=216707 John Marino changed: What|Removed |Added CC|

[Bug 216903] clang frontend command failed due to signal

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=216903 Mark Linimon changed: What|Removed |Added Assignee|freebsd-b...@freebsd.org

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

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=216707 --- Comment #15 from commit-h...@freebsd.org --- A commit references this bug: Author: jbeich Date: Sun Feb 5 12:34:06 UTC 2017 New revision: 433397 URL: https://svnweb.freebsd.org/changeset/ports/433397 Log: lang/hugs: unbreak with

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

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=216707 --- Comment #18 from Pedro F. Giffuni --- (In reply to Jan Beich (mail not working) from comment #17) > Hmm, not much bustage thanks to DragonFly dogfooding GCC 5 before us. :). > (In reply to Pedro F. Giffuni from

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

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=216707 --- Comment #23 from Gerald Pfeifer --- (In reply to Jan Beich (mail not working) from comment #17) > Why not GCC 7? GCC 7 is still in development and its first release (GCC 7.1) is still a few months out. > exp-runs

[Bug 216908] security/gnutls: does not build on 12-CURRENT aarch64 after llvm 3.9 toolchain integration

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=216908 Tijl Coosemans changed: What|Removed |Added Assignee|t...@freebsd.org

[Bug 216080] science/bddsolve: fails to build with lang/gcc6 or later

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=216080 --- Comment #5 from Ed Schouten --- So to get this straight: this no longer breaks, right? It was caused by a change to libc++, but that change has been reverted. If so, shall I mark this bug as WONTFIX? -- You are

[Bug 216080] science/bddsolve: fails to build with lang/gcc6 or later

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=216080 --- Comment #6 from Jan Beich (mail not working) --- DragonFly, architectures on external toolchain and users that prefer GCC may be affected after upgrading GCC to 6.x or later. For some reason Clang (even 4.0) is

[Bug 216908] security/gnutls: does not build on 12-CURRENT aarch64 after llvm 3.9 toolchain integration

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=216908 --- Comment #2 from Ed Maste --- (In reply to Dimitry Andric from comment #1) > I wasn't aware that lld was used by default for aarch64, I thought this used > an external binutils port based ld instead? buildworld and

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

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=216707 --- Comment #5 from commit-h...@freebsd.org --- A commit references this bug: Author: jbeich Date: Sat Feb 4 04:16:59 UTC 2017 New revision: 433278 URL: https://svnweb.freebsd.org/changeset/ports/433278 Log: net-mgmt/flow-tools:

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

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=216707 --- Comment #1 from Antoine Brodin --- Update of LANG_GCC_IS is missing? -- You are receiving this mail because: You are on the CC list for the bug. ___

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

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=216707 Gerald Pfeifer changed: What|Removed |Added Attachment #179503|0 |1 is

[Bug 216451] Assertion failed: (NodeToMatch->getOpcode() != ISD::DELETED_NODE && "NodeToMatch was removed partway through selection"), function SelectCodeCommon, file /usr/src/contrib/llvm/lib/CodeGen

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=216451 --- Comment #4 from otacilio.n...@bsd.com.br --- (In reply to otacilio.neto from comment #3) Sorry, this patch do not reproduce the error. I'm creating a new one. -- You are receiving this mail because: You are the assignee for the bug.

[Bug 216451] Assertion failed: (NodeToMatch->getOpcode() != ISD::DELETED_NODE && "NodeToMatch was removed partway through selection"), function SelectCodeCommon, file /usr/src/contrib/llvm/lib/CodeGen

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=216451 otacilio.n...@bsd.com.br changed: What|Removed |Added Attachment #179298|0 |1 is obsolete|

  1   2   3   4   5   6   7   8   9   10   >