[Bug 225330] clang bug can incorrectly enable or disable interrupts on amd64

[bugzilla-noreply]

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

Dimitry Andric  changed:

   What|Removed |Added

 CC||d...@freebsd.org

--- Comment #1 from Dimitry Andric  ---
It would be much better to take this issue upstream.  We would not want to
carry patches like this without them having been checked over first.

-- 
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 225352] clang 6.0.0 crashes building emulators/wine: Assertion failed: ((size_t)StackDisp < Context.ArgStoreVector.size() && "Function call has more parameters than the stack is adjusted for.")

[bugzilla-noreply]

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

Dimitry Andric  changed:

   What|Removed |Added

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

--- Comment #1 from Dimitry Andric  ---


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

-- 
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 216316] objcopy (elfcopy) in 11 appears to have a regression compared to the version in 10

[bugzilla-noreply]

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

--- Comment #6 from Oleksandr Tymoshenko  ---
The content of attachment 189987 has been deleted for the following reason:

spam

-- 
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 216316] objcopy (elfcopy) in 11 appears to have a regression compared to the version in 10

[bugzilla-noreply]

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

Oleksandr Tymoshenko  changed:

   What|Removed |Added

 CC||go...@freebsd.org
 Attachment #189987|0   |1
is obsolete||

-- 
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 202665] clang++ core dump during compile with invalid syntax

[bugzilla-noreply]

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

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

Author: dim
Date: Tue Feb 27 19:02:50 UTC 2018
New revision: 330080
URL: https://svnweb.freebsd.org/changeset/base/330080

Log:
  Avoid using the C++11 auto keyword, which was introduced in r328555, as
  part of an upstream change.  This is not supported by gcc 4.2.1, which
  is still the default system compiler for some architectures.

  Direct commit to stable/9 and stable/10, since this does not apply to
  stable/11 and head.

  Reported by:  j...@iki.fi
  PR:   202665,226068

Changes:
  stable/10/contrib/llvm/tools/clang/lib/Sema/SemaInit.cpp
  stable/9/contrib/llvm/tools/clang/lib/Sema/SemaInit.cpp

-- 
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 227340] clang crashes with error in backend: Access past stack top

[bugzilla-noreply]

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

Rodney W. Grimes  changed:

   What|Removed |Added

 CC||toolch...@freebsd.org

-- 
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 227339] clang crashes with error in backend: SSE2 register return with SSE2 disabled

[bugzilla-noreply]

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

Dimitry Andric  changed:

   What|Removed |Added

   Assignee|toolch...@freebsd.org   |d...@freebsd.org

-- 
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 227340] clang crashes with error in backend: Access past stack top

[bugzilla-noreply]

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

Dimitry Andric  changed:

   What|Removed |Added

   Assignee|toolch...@freebsd.org   |d...@freebsd.org

-- 
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 227339] clang crashes with error in backend: SSE2 register return with SSE2 disabled

[bugzilla-noreply]

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

Rodney W. Grimes  changed:

   What|Removed |Added

 CC||toolch...@freebsd.org

-- 
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 227438] -fopenmp=libgomp doesn't work

[bugzilla-noreply]

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

Bug ID: 227438
   Summary: -fopenmp=libgomp doesn't work
   Product: Base System
   Version: CURRENT
  Hardware: Any
OS: Any
Status: New
  Severity: Affects Only Me
  Priority: ---
 Component: bin
  Assignee: toolch...@freebsd.org
  Reporter: jbe...@freebsd.org

libomp has limited platform availability (currently, only i386 and amd64), so
ports/ may prefer to use another library to avoid ugly conditionals. Using GCC
isn't always an option due to conflicts in libgcc_s, libstdc++, broken ASAN and
hard to use with LLD.

Steps to reproduce:

  $ pkg install ca_root_nss gcc7
  $ fetch https://computing.llnl.gov/tutorials/openMP/samples/C/omp_hello.c
  $ cc -fopenmp=libgomp -isystem$(find /usr/local/lib/gcc7 -name omp.h | xargs
dirname) -L/usr/local/lib/gcc7 omp_hello.c

Actual result

  $ ./a.out
  Hello World from thread = 0
  Number of threads = 1

Expected result:

  $ ./a.out
  Hello World from thread = 4
  Hello World from thread = 0
  Number of threads = 8
  Hello World from thread = 2
  Hello World from thread = 1
  Hello World from thread = 6
  Hello World from thread = 5
  Hello World from thread = 7
  Hello World from thread = 3

-- 
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 227438] clang -fopenmp=libgomp doesn't work

[bugzilla-noreply]

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

Jan Beich  changed:

   What|Removed |Added

Summary|-fopenmp=libgomp doesn't|clang -fopenmp=libgomp
   |work|doesn't work

-- 
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 225330] clang bug can incorrectly enable or disable interrupts on amd64

[bugzilla-noreply]

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

--- Comment #3 from Jonathan T. Looney  ---
The upstream bug is fixed in r329657 and r329673. Also, dim@ fixed a related
bug that allows us to use -msahf as a workaround (committed in upstream
r325446). Once those revisions appear in our tree, this bug should be fixed.

-- 
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 227438] clang -fopenmp=libgomp doesn't work

[bugzilla-noreply]

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

Dimitry Andric  changed:

   What|Removed |Added

 CC||d...@freebsd.org

--- Comment #1 from Dimitry Andric  ---
Hmm, I don't think -fopenmp=libgomp is functional at all.  It's probably better
to report this upstream, as I have no clue whatsoever if it is supposed to
work.

-- 
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 227438] clang -fopenmp=libgomp doesn't work

[bugzilla-noreply]

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

--- Comment #2 from Dimitry Andric  ---
22:19.11  dim: -fopenmp=libgomp is just like you compile without
-fopenmp
22:19.24  ABataev: aha.
22:21.13  dim: It works. Clang uses only libomp interface and does not
rely on libgomp. -fopenmp=libgomp is used as a stub-like option
22:23.09  dim: Yes, if they want to use libgomp, they must use 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 225330] clang bug can incorrectly enable or disable interrupts on amd64

[bugzilla-noreply]

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

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

Author: dim
Date: Sat Apr 14 12:07:07 UTC 2018
New revision: 332501
URL: https://svnweb.freebsd.org/changeset/base/332501

Log:
  Pull in r325446 from upstream clang trunk (by me):

[X86] Add 'sahf' CPU feature to frontend

Summary:
Make clang accept `-msahf` (and `-mno-sahf`) flags to activate the
`+sahf` feature for the backend, for bug 36028 (Incorrect use of
pushf/popf enables/disables interrupts on amd64 kernels).  This was
originally submitted in bug 36037 by Jonathan Looney
.

As described there, GCC also uses `-msahf` for this feature, and the
backend already recognizes the `+sahf` feature. All that is needed is
to teach clang to pass this on to the backend.

The mapping of feature support onto CPUs may not be complete; rather,
it was chosen to match LLVM's idea of which CPUs support this feature
(see lib/Target/X86/X86.td).

I also updated the affected test case (CodeGen/attr-target-x86.c) to
match the emitted output.

Reviewers: craig.topper, coby, efriedma, rsmith

Reviewed By: craig.topper

Subscribers: emaste, cfe-commits

Differential Revision: https://reviews.llvm.org/D43394

  Pull in r328944 from upstream llvm trunk (by Chandler Carruth):

[x86] Expose more of the condition conversion routines in the public
API for X86's instruction information. I've now got a second patch
under review that needs these same APIs. This bit is nicely
orthogonal and obvious, so landing it. NFC.

  Pull in r329414 from upstream llvm trunk (by Craig Topper):

[X86] Merge itineraries for CLC, CMC, and STC.

These are very simple flag setting instructions that appear to only
be a single uop. They're unlikely to need this separation.

  Pull in r329657 from upstream llvm trunk (by Chandler Carruth):

[x86] Introduce a pass to begin more systematically fixing PR36028
and similar issues.

The key idea is to lower COPY nodes populating EFLAGS by scanning the
uses of EFLAGS and introducing dedicated code to preserve the
necessary state in a GPR. In the vast majority of cases, these uses
are cmovCC and jCC instructions. For such cases, we can very easily
save and restore the necessary information by simply inserting a
setCC into a GPR where the original flags are live, and then testing
that GPR directly to feed the cmov or conditional branch.

However, things are a bit more tricky if arithmetic is using the
flags.  This patch handles the vast majority of cases that seem to
come up in practice: adc, adcx, adox, rcl, and rcr; all without
taking advantage of partially preserved EFLAGS as LLVM doesn't
currently model that at all.

There are a large number of operations that techinaclly observe
EFLAGS currently but shouldn't in this case -- they typically are
using DF.  Currently, they will not be handled by this approach.
However, I have never seen this issue come up in practice. It is
already pretty rare to have these patterns come up in practical code
with LLVM. I had to resort to writing MIR tests to cover most of the
logic in this pass already.  I suspect even with its current amount
of coverage of arithmetic users of EFLAGS it will be a significant
improvement over the current use of pushf/popf. It will also produce
substantially faster code in most of the common patterns.

This patch also removes all of the old lowering for EFLAGS copies,
and the hack that forced us to use a frame pointer when EFLAGS copies
were found anywhere in a function so that the dynamic stack
adjustment wasn't a problem. None of this is needed as we now lower
all of these copies directly in MI and without require stack
adjustments.

Lots of thanks to Reid who came up with several aspects of this
approach, and Craig who helped me work out a couple of things
tripping me up while working on this.

Differential Revision: https://reviews.llvm.org/D45146

  Pull in r329673 from upstream llvm trunk (by Chandler Carruth):

[x86] Model the direction flag (DF) separately from the rest of
EFLAGS.

This cleans up a number of operations that only claimed te use EFLAGS
due to using DF. But no instructions which we think of us setting
EFLAGS actually modify DF (other than things like popf) and so this
needlessly creates uses of EFLAGS that aren't really there.

In fact, DF is so restrictive it is pretty easy to model. Only STD,
CLD, and the whole-flags writes (WRFLAGS and POPF) need to model
this.

I've also somewhat cleaned up some of the flag management instruction
definitions to be in the correct .td file.

Adding this extra register also uncovered a failure to use the
correct datatype to hold X86 registers, and 

[Bug 225330] clang bug can incorrectly enable or disable interrupts on amd64

[bugzilla-noreply]

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

Dimitry Andric  changed:

   What|Removed |Added

 Status|New |In Progress
  Flags||mfc-stable11+
   Assignee|toolch...@freebsd.org   |d...@freebsd.org

-- 
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 225330] clang bug can incorrectly enable or disable interrupts on amd64

[bugzilla-noreply]

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

Rodney W. Grimes  changed:

   What|Removed |Added

 CC||toolch...@freebsd.org

-- 
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 225330] clang bug can incorrectly enable or disable interrupts on amd64

[bugzilla-noreply]

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

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

Author: dim
Date: Sat Apr 14 14:57:34 UTC 2018
New revision: 332503
URL: https://svnweb.freebsd.org/changeset/base/332503

Log:
  Revert r332501 for now, as it can cause build failures on i386.
  Reported upstream as .

  Reported by:  emaste, ci.freebsd.org
  PR:   225330

Changes:
  head/contrib/llvm/include/llvm/CodeGen/MachineBasicBlock.h
  head/contrib/llvm/lib/CodeGen/MachineBasicBlock.cpp
  head/contrib/llvm/lib/Target/X86/Disassembler/X86Disassembler.cpp
  head/contrib/llvm/lib/Target/X86/X86.h
  head/contrib/llvm/lib/Target/X86/X86FlagsCopyLowering.cpp
  head/contrib/llvm/lib/Target/X86/X86ISelLowering.cpp
  head/contrib/llvm/lib/Target/X86/X86ISelLowering.h
  head/contrib/llvm/lib/Target/X86/X86InstrCompiler.td
  head/contrib/llvm/lib/Target/X86/X86InstrInfo.cpp
  head/contrib/llvm/lib/Target/X86/X86InstrInfo.h
  head/contrib/llvm/lib/Target/X86/X86InstrInfo.td
  head/contrib/llvm/lib/Target/X86/X86InstrSystem.td
  head/contrib/llvm/lib/Target/X86/X86RegisterInfo.td
  head/contrib/llvm/lib/Target/X86/X86Schedule.td
  head/contrib/llvm/lib/Target/X86/X86ScheduleAtom.td
  head/contrib/llvm/lib/Target/X86/X86TargetMachine.cpp
  head/contrib/llvm/tools/clang/include/clang/Driver/Options.td
  head/contrib/llvm/tools/clang/lib/Basic/Targets/X86.cpp
  head/contrib/llvm/tools/clang/lib/Basic/Targets/X86.h
  head/lib/clang/freebsd_cc_version.h
  head/lib/clang/libllvm/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 227340] clang crashes with error in backend: Access past stack top

[bugzilla-noreply]

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

Mark Linimon  changed:

   What|Removed |Added

   Assignee|b...@freebsd.org|toolch...@freebsd.org

-- 
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 225330] clang bug can incorrectly enable or disable interrupts on amd64

[bugzilla-noreply]

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

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

Author: dim
Date: Fri Apr 20 18:20:56 UTC 2018
New revision: 332833
URL: https://svnweb.freebsd.org/changeset/base/332833

Log:
  Recommit r332501, with an additional upstream fix for "Cannot lower
  EFLAGS copy that lives out of a basic block!" errors on i386.

  Pull in r325446 from upstream clang trunk (by me):

[X86] Add 'sahf' CPU feature to frontend

Summary:
Make clang accept `-msahf` (and `-mno-sahf`) flags to activate the
`+sahf` feature for the backend, for bug 36028 (Incorrect use of
pushf/popf enables/disables interrupts on amd64 kernels).  This was
originally submitted in bug 36037 by Jonathan Looney
.

As described there, GCC also uses `-msahf` for this feature, and the
backend already recognizes the `+sahf` feature. All that is needed is
to teach clang to pass this on to the backend.

The mapping of feature support onto CPUs may not be complete; rather,
it was chosen to match LLVM's idea of which CPUs support this feature
(see lib/Target/X86/X86.td).

I also updated the affected test case (CodeGen/attr-target-x86.c) to
match the emitted output.

Reviewers: craig.topper, coby, efriedma, rsmith

Reviewed By: craig.topper

Subscribers: emaste, cfe-commits

Differential Revision: https://reviews.llvm.org/D43394

  Pull in r328944 from upstream llvm trunk (by Chandler Carruth):

[x86] Expose more of the condition conversion routines in the public
API for X86's instruction information. I've now got a second patch
under review that needs these same APIs. This bit is nicely
orthogonal and obvious, so landing it. NFC.

  Pull in r329414 from upstream llvm trunk (by Craig Topper):

[X86] Merge itineraries for CLC, CMC, and STC.

These are very simple flag setting instructions that appear to only
be a single uop. They're unlikely to need this separation.

  Pull in r329657 from upstream llvm trunk (by Chandler Carruth):

[x86] Introduce a pass to begin more systematically fixing PR36028
and similar issues.

The key idea is to lower COPY nodes populating EFLAGS by scanning the
uses of EFLAGS and introducing dedicated code to preserve the
necessary state in a GPR. In the vast majority of cases, these uses
are cmovCC and jCC instructions. For such cases, we can very easily
save and restore the necessary information by simply inserting a
setCC into a GPR where the original flags are live, and then testing
that GPR directly to feed the cmov or conditional branch.

However, things are a bit more tricky if arithmetic is using the
flags.  This patch handles the vast majority of cases that seem to
come up in practice: adc, adcx, adox, rcl, and rcr; all without
taking advantage of partially preserved EFLAGS as LLVM doesn't
currently model that at all.

There are a large number of operations that techinaclly observe
EFLAGS currently but shouldn't in this case -- they typically are
using DF.  Currently, they will not be handled by this approach.
However, I have never seen this issue come up in practice. It is
already pretty rare to have these patterns come up in practical code
with LLVM. I had to resort to writing MIR tests to cover most of the
logic in this pass already.  I suspect even with its current amount
of coverage of arithmetic users of EFLAGS it will be a significant
improvement over the current use of pushf/popf. It will also produce
substantially faster code in most of the common patterns.

This patch also removes all of the old lowering for EFLAGS copies,
and the hack that forced us to use a frame pointer when EFLAGS copies
were found anywhere in a function so that the dynamic stack
adjustment wasn't a problem. None of this is needed as we now lower
all of these copies directly in MI and without require stack
adjustments.

Lots of thanks to Reid who came up with several aspects of this
approach, and Craig who helped me work out a couple of things
tripping me up while working on this.

Differential Revision: https://reviews.llvm.org/D45146

  Pull in r329673 from upstream llvm trunk (by Chandler Carruth):

[x86] Model the direction flag (DF) separately from the rest of
EFLAGS.

This cleans up a number of operations that only claimed te use EFLAGS
due to using DF. But no instructions which we think of us setting
EFLAGS actually modify DF (other than things like popf) and so this
needlessly creates uses of EFLAGS that aren't really there.

In fact, DF is so restrictive it is pretty easy to model. Only STD,
CLD, and the whole-flags writes (WRFLAGS and POPF) need to model
this.

I've also somewhat cleaned up some of the flag management instruction
definitions to be in the 

[Bug 225330] clang bug can incorrectly enable or disable interrupts on amd64

[bugzilla-noreply]

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

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

Author: brooks
Date: Fri Apr 20 22:46:23 UTC 2018
New revision: 467849
URL: https://svnweb.freebsd.org/changeset/ports/467849

Log:
  Merge r332833 from FreeBSD HEAD.

  This should ensure clang does not use pushf/popf sequences to
  save and restore flags, avoiding problems with unrelated flags (such as
  the interrupt flag) being restored unexpectedly.

  PR:   225330

Changes:
  head/devel/llvm60/Makefile
  head/devel/llvm60/files/clang/patch-fsvn-r332833-clang
  head/devel/llvm60/files/patch-fsvn-r332833

-- 
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 227686] www/firefox: clang 6.0 crashes during build

[bugzilla-noreply]

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

Bug ID: 227686
   Summary: www/firefox: clang 6.0 crashes during build
   Product: Ports & Packages
   Version: Latest
  Hardware: Any
OS: Any
Status: New
  Keywords: regression
  Severity: Affects Only Me
  Priority: ---
 Component: Individual Port(s)
  Assignee: ge...@freebsd.org
  Reporter: jbe...@freebsd.org
  Assignee: ge...@freebsd.org
 Flags: maintainer-feedback?(ge...@freebsd.org)

Regression range: base r332632 (good) and base r332849 (bad).

/usr/bin/c++ -o Unified_cpp_dom_system0.o -c
-I/wrkdirs/usr/ports/www/firefox/work/.build/dist/stl_wrappers
-I/wrkdirs/usr/ports/www/firefox/work/.build/dist/system_wrappers -include
/wrkdirs/usr/ports/www/firefox/work/mozilla-release-239e434d6d2b8e1e2b697c3416d1e96d48fe98e5/config/gcc_hidden.h
-DNDEBUG=1 -DTRIMMED=1 -DOS_POSIX=1 -DOS_FREEBSD=1 -DOS_BSD=1
'-DDLL_PREFIX="lib"' '-DDLL_SUFFIX=".so"' -DSTATIC_EXPORTABLE_JS_API
-DMOZ_HAS_MOZGLUE -DMOZILLA_INTERNAL_API -DIMPL_LIBXUL
-I/wrkdirs/usr/ports/www/firefox/work/mozilla-release-239e434d6d2b8e1e2b697c3416d1e96d48fe98e5/dom/system
-I/wrkdirs/usr/ports/www/firefox/work/.build/dom/system
-I/wrkdirs/usr/ports/www/firefox/work/.build/ipc/ipdl/_ipdlheaders
-I/wrkdirs/usr/ports/www/firefox/work/mozilla-release-239e434d6d2b8e1e2b697c3416d1e96d48fe98e5/ipc/chromium/src
-I/wrkdirs/usr/ports/www/firefox/work/mozilla-release-239e434d6d2b8e1e2b697c3416d1e96d48fe98e5/ipc/glue
-I/wrkdirs/usr/ports/www/firefox/work/mozilla-release-239e434d6d2b8e1e2b697c3416d1e96d48fe98e5/dom/base
-I/wrkdirs/usr/ports/www/firefox/work/mozilla-release-239e434d6d2b8e1e2b697c3416d1e96d48fe98e5/dom/bindings
-I/wrkdirs/usr/ports/www/firefox/work/mozilla-release-239e434d6d2b8e1e2b697c3416d1e96d48fe98e5/js/xpconnect/loader
-I/wrkdirs/usr/ports/www/firefox/work/mozilla-release-239e434d6d2b8e1e2b697c3416d1e96d48fe98e5/xpcom/base
-I/wrkdirs/usr/ports/www/firefox/work/.build/dist/include
-I/usr/local/include/nspr -I/usr/local/include/nss -I/usr/local/include/nss/nss
-I/usr/local/include -I/usr/local/include -I/usr/local/include/pixman-1 -fPIC
-DMOZILLA_CLIENT -include
/wrkdirs/usr/ports/www/firefox/work/.build/mozilla-config.h -Qunused-arguments
-D_GLIBCXX_USE_C99 -D_GLIBCXX_USE_C99_MATH_TR1 -D_DECLARE_C99_LDBL_MATH
-DLIBICONV_PLUG -isystem /usr/local/include -U_FORTIFY_SOURCE
-D_FORTIFY_SOURCE=2 -Qunused-arguments -Wall -Wempty-body -Wignored-qualifiers
-Woverloaded-virtual -Wpointer-arith -Wsign-compare -Wtype-limits
-Wunreachable-code -Wunreachable-code-return -Wwrite-strings
-Wno-invalid-offsetof -Wclass-varargs -Wloop-analysis -Wc++1z-compat -Wcomma
-Wimplicit-fallthrough -Wstring-conversion -Wno-inline-new-delete
-Wno-error=deprecated-declarations -Wno-error=array-bounds -Wformat
-Wformat-security -Wno-gnu-zero-variadic-macro-arguments
-Wno-unknown-warning-option -Wno-return-type-c-linkage -fno-sized-deallocation
-O2 -pipe -O3 -DLIBICONV_PLUG -fstack-protector -isystem /usr/local/include
-fno-strict-aliasing -DLIBICONV_PLUG -isystem /usr/local/include
-U_FORTIFY_SOURCE -D_FORTIFY_SOURCE=2 -fno-exceptions -fno-strict-aliasing
-fno-rtti -ffunction-sections -fdata-sections -fno-exceptions -fno-math-errno
-pipe -I/usr/local/include -O2 -O3 -fno-omit-frame-pointer  -MD -MP -MF
.deps/Unified_cpp_dom_system0.o.pp  
/wrkdirs/usr/ports/www/firefox/work/.build/dom/system/Unified_cpp_dom_system0.cpp
Assertion failed: (isReg() && "This is not a register operand!"), function
getReg, file
/usr/local/poudriere/jails/head-i386/usr/src/contrib/llvm/include/llvm/CodeGen/MachineOperand.h,
line 333.
c++: error: unable to execute command: Abort trap (core dumped)
c++: error: clang frontend command failed due to signal (use -v to see
invocation)
FreeBSD clang version 6.0.0 (tags/RELEASE_600/final 326565) (based on LLVM
6.0.0)
Target: i386-unknown-freebsd12.0
Thread model: posix
InstalledDir: /usr/bin

http://beefy11.nyi.freebsd.org/data/head-i386-default/p467853_s332849/logs/errors/firefox-59.0.2_6,1.log
http://beefy11.nyi.freebsd.org/data/head-i386-default/p467853_s332849/logs/errors/libxul-45.9.0_11.log

vs. green logs

http://beefy11.nyi.freebsd.org/data/head-i386-default/p467743_s332632/logs/firefox-59.0.2_6,1.log
http://beefy11.nyi.freebsd.org/data/head-i386-default/p467743_s332632/logs/libxul-45.9.0_11.log

-- 
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 227686] www/firefox: clang 6.0 crashes during build

[bugzilla-noreply]

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

Jan Beich  changed:

   What|Removed |Added

   Assignee|ge...@freebsd.org   |toolch...@freebsd.org

--- Comment #1 from Jan Beich  ---
Can someone bisect?

dom/system/nsDeviceSensors.cpp preprocessed: https://ptpb.pw/sdnj (11 Mb)
Clang 6.0 command line arguments: https://ptpb.pw/-Urk

-- 
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 227686] www/firefox: clang 6.0 crashes during build

[bugzilla-noreply]

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

Jan Beich  changed:

   What|Removed |Added

   Hardware|Any |i386

-- 
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 227723] clang 6.0 breaks php56/opcache

[bugzilla-noreply]

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

Rodney W. Grimes  changed:

   What|Removed |Added

 CC||toolch...@freebsd.org

-- 
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 227723] clang 6.0 breaks php56/opcache

[bugzilla-noreply]

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

--- Comment #6 from Dimitry Andric  ---
After some bisecting, it turns out this behavior changed due to the following
upstream commit: https://reviews.llvm.org/rL313784 ("Remove offset size check
in nullptr arithmetic handling") and https://reviews.llvm.org/rL313666 ("Teach
clang to tolerate the 'p = nullptr + n' idiom used by glibc").

See also https://reviews.llvm.org/D37042.

What PHP5 is doing is, strictly speaking, undefined behavior, as adding numbers
to null pointers is normally not allowed.  In the upstream commit, Andrew
Kaylor has apparently tried to make this work, at least partially, for a few
specific cases used in glibc.

PHP7 and later use a completely different way of storing these variable/number
hybrids, which is not affected by this, as it apparently avoids any null
pointer arithmetic.

I'll see if I can get some feedback from Andrew on this.

-- 
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 227723] clang 6.0 breaks php56/opcache

[bugzilla-noreply]

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

Florian Smeets  changed:

   What|Removed |Added

   Assignee|toolch...@freebsd.org   |a...@freebsd.org

--- Comment #5 from Florian Smeets  ---
Over to maintainer. The patch works for the OP, I think in that case it should
be committed to the port. I'll have to figure our why it didn't work for me, I
probably applied it to the wrong poudriere ports tree.

-- 
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 227723] clang 6.0 breaks php56/opcache

[bugzilla-noreply]

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

--- Comment #7 from la...@fit.vutbr.cz ---
That's true, if base nullptr is changed to any temp_variable* in VAR_NUM(),
then generated code is identical and index is correctly sign extended. So this
probably will be not fixed in clang and patch for php56 is more appropriate.

-- 
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 227698] www/iridium, www/qt5-webengine: clang 6.0 crashes during build

[bugzilla-noreply]

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

Jan Beich  changed:

   What|Removed |Added

 Blocks||227683


Referenced Bugs:

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=227683
[Bug 227683] www/chromium, www/iridium, www/qt5-webengine: switch to llvm60
-- 
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 227686] www/firefox: clang 6.0 crashes during build

[bugzilla-noreply]

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

--- Comment #4 from Dimitry Andric  ---
I can reproduce, it's caused by r332833 (the upstream fixes for EFLAGS).  I'm
going to make a minimized test case, and figure out which of the upstream
revisions caused it.

-- 
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 227698] www/iridium, www/qt5-webengine: clang 6.0 crashes during build

[bugzilla-noreply]

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

Dimitry Andric  changed:

   What|Removed |Added

 CC||d...@freebsd.org,
   ||ema...@freebsd.org,
   ||j...@freebsd.org
   Assignee|toolch...@freebsd.org   |d...@freebsd.org
 Status|New |Open

--- Comment #8 from Dimitry Andric  ---
I can reproduce, it's caused by r332833 (the upstream fixes for EFLAGS),
similar to bug 227686, but I'm not sure if it has exactly the same cause.  I'm
going to make a minimized test case, and figure out which of the upstream
revisions caused it.

-- 
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 227686] www/firefox: clang 6.0 crashes during build

[bugzilla-noreply]

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

Jan Beich  changed:

   What|Removed |Added

 Blocks||227679


Referenced Bugs:

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=227679
[Bug 227679] USES=compiler:c++14-lang update Clang to 6.0
-- 
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 227699] devel/powerpc64-gcc: clang 6.0 crashes during build

[bugzilla-noreply]

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

Dimitry Andric  changed:

   What|Removed |Added

 Status|New |Open
 CC||d...@freebsd.org
   Assignee|toolch...@freebsd.org   |d...@freebsd.org

--- Comment #3 from Dimitry Andric  ---
I cannot reproduce.  I just get a long string of errors, and no crash:

$ clang "-cc1" "-triple" "i386-unknown-freebsd12.0" "-emit-obj" "-disable-free"
"-main-file-name" "insn-opinit.c" "-mrelocation-model" "static"
"-mthread-model" "posix" "-mdisable-fp-elim" "-relaxed-aliasing"
"-masm-verbose" "-mconstructor-aliases" "-munwind-tables" "-target-cpu" "i486"
"-dwarf-column-info" "-debugger-tuning=gdb" "-coverage-notes-file"
"/wrkdirs/usr/ports/devel/powerpc64-gcc/work/.build/gcc/insn-opinit.gcno" "-D"
"CROSS_DIRECTORY_STRUCTURE" "-D" "LIBICONV_PLUG" "-D" "LIBICONV_PLUG" "-D"
"IN_GCC" "-D" "CROSS_DIRECTORY_STRUCTURE" "-D" "HAVE_CONFIG_H" "-D"
"LIBICONV_PLUG" "-O2" "-W" "-Wall" "-Wno-narrowing" "-Wwrite-strings"
"-Wcast-qual" "-Wmissing-format-attribute" "-Woverloaded-virtual"
"-Wno-long-long" "-Wno-variadic-macros" "-Wno-overlength-strings" "-pedantic"
"-fdeprecated-macro" "-ferror-limit" "19" "-fmessage-length" "114"
"-stack-protector" "1" "-fno-rtti" "-fobjc-runtime=gnustep"
"-fdiagnostics-show-option" "-fcolor-diagnostics" "-vectorize-loops"
"-vectorize-slp" "-x" "c++" "insn-opinit-e12175.c"
In file included from insn-opinit.c:5:
In file included from
/wrkdirs/usr/ports/devel/powerpc64-gcc/work/gcc-6.3.0/gcc/system.h:681:
/usr/local/include/gmp.h:469:7: error: use of undeclared identifier 'std'
using std::FILE;
  ^
/usr/local/include/gmp.h:2278:19: error: use of undeclared identifier 'std'
__GMP_DECLSPEC_XX std::ostream& operator<< (std::ostream &, mpz_srcptr);
  ^
/usr/local/include/gmp.h:2278:45: error: use of undeclared identifier 'std'
__GMP_DECLSPEC_XX std::ostream& operator<< (std::ostream &, mpz_srcptr);
^
/usr/local/include/gmp.h:2279:19: error: use of undeclared identifier 'std'
__GMP_DECLSPEC_XX std::ostream& operator<< (std::ostream &, mpq_srcptr);
  ^
/usr/local/include/gmp.h:2279:45: error: use of undeclared identifier 'std'
__GMP_DECLSPEC_XX std::ostream& operator<< (std::ostream &, mpq_srcptr);
^
/usr/local/include/gmp.h:2280:19: error: use of undeclared identifier 'std'
__GMP_DECLSPEC_XX std::ostream& operator<< (std::ostream &, mpf_srcptr);
  ^
/usr/local/include/gmp.h:2280:45: error: use of undeclared identifier 'std'
__GMP_DECLSPEC_XX std::ostream& operator<< (std::ostream &, mpf_srcptr);
^
/usr/local/include/gmp.h:2281:19: error: use of undeclared identifier 'std'
__GMP_DECLSPEC_XX std::istream& operator>> (std::istream &, mpz_ptr);
  ^
/usr/local/include/gmp.h:2281:45: error: use of undeclared identifier 'std'
__GMP_DECLSPEC_XX std::istream& operator>> (std::istream &, mpz_ptr);
^
/usr/local/include/gmp.h:2282:19: error: use of undeclared identifier 'std'
__GMP_DECLSPEC_XX std::istream& operator>> (std::istream &, mpq_ptr);
  ^
/usr/local/include/gmp.h:2282:45: error: use of undeclared identifier 'std'
__GMP_DECLSPEC_XX std::istream& operator>> (std::istream &, mpq_ptr);
^
/usr/local/include/gmp.h:2283:19: error: use of undeclared identifier 'std'
__GMP_DECLSPEC_XX std::istream& operator>> (std::istream &, mpf_ptr);
  ^
/usr/local/include/gmp.h:2283:45: error: use of undeclared identifier 'std'
__GMP_DECLSPEC_XX std::istream& operator>> (std::istream &, mpf_ptr);
^
In file included from insn-opinit.c:6:
/wrkdirs/usr/ports/devel/powerpc64-gcc/work/gcc-6.3.0/gcc/coretypes.h:62:1:
warning: class 'rtx_def' was
  previously declared as a struct [-Wmismatched-tags]
class rtx_def;
^
/wrkdirs/usr/ports/devel/powerpc64-gcc/work/gcc-6.3.0/gcc/coretypes.h:55:8:
note: previous use is here
struct rtx_def;
   ^
/wrkdirs/usr/ports/devel/powerpc64-gcc/work/gcc-6.3.0/gcc/coretypes.h:266:9:
error: use of undeclared identifier
  'std'
typedef std::pair  tree_pair;
^
In file included from insn-opinit.c:6:
In file included from
/wrkdirs/usr/ports/devel/powerpc64-gcc/work/gcc-6.3.0/gcc/coretypes.h:344:
/wrkdirs/usr/ports/devel/powerpc64-gcc/work/gcc-6.3.0/gcc/wide-int.h:1112:1:
warning: 'fixed_wide_int_storage'
  defined as a class template here but previously declared as a struct
template [-Wmismatched-tags]
class GTY(()) fixed_wide_int_storage
^
/wrkdirs/usr/ports/devel/powerpc64-gcc/work/gcc-6.3.0/gcc/wide-int.h:279:18:
note: did you mean 

[Bug 227698] www/iridium, www/qt5-webengine: clang 6.0 crashes during build

[bugzilla-noreply]

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

--- Comment #7 from Jan Beich  ---
Nevermind comment 4. I forgot to update jail/package on amd64.

-- 
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 227698] www/iridium, www/qt5-webengine: clang 6.0 crashes during build

[bugzilla-noreply]

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

Jan Beich  changed:

   What|Removed |Added

   Assignee|ports-b...@freebsd.org  |toolch...@freebsd.org

--- Comment #3 from Jan Beich  ---
Can you bisect?

-- 
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 227698] www/iridium, www/qt5-webengine: clang 6.0 crashes during build

[bugzilla-noreply]

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

--- Comment #4 from Jan Beich  ---
Note, -m32 or -target i386-unknown-freebsd12.0 won't trigger the crash. Make
sure to run 32bit Clang binary.

-- 
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 225330] clang bug can incorrectly enable or disable interrupts on amd64

[bugzilla-noreply]

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

Jan Beich  changed:

   What|Removed |Added

 Depends on||227686


Referenced Bugs:

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=227686
[Bug 227686] www/firefox: clang 6.0 crashes during build
-- 
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 227686] www/firefox: clang 6.0 crashes during build

[bugzilla-noreply]

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

Jan Beich  changed:

   What|Removed |Added

 Blocks||225330


Referenced Bugs:

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=225330
[Bug 225330] clang bug can incorrectly enable or disable interrupts on amd64
-- 
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 227686] www/firefox: clang 6.0 crashes during build

[bugzilla-noreply]

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

--- Comment #2 from Jan Beich  ---
Note, every Gecko port is affected:
- mail/thunderbird
- www/firefox-esr
- www/firefox
- www/libxul
- www/palemoon
- www/seamonkey
- www/waterfox

-- 
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 225330] clang bug can incorrectly enable or disable interrupts on amd64

[bugzilla-noreply]

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

Jan Beich  changed:

   What|Removed |Added

 Depends on||227699


Referenced Bugs:

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=227699
[Bug 227699] devel/powerpc64-gcc: clang 6.0 crashes during build
-- 
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 227698] www/iridium, www/qt5-webengine: clang 6.0 crashes during build

[bugzilla-noreply]

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

--- Comment #5 from Jan Beich  ---
Regression range: base r332632 (good) and base r332849 (bad). Probably a dupe
of bug 227686. My guess, base r332833 and ports r467849 are culprits.

http://beefy11.nyi.freebsd.org/data/head-i386-default/p467853_s332849/logs/iridium-browser-58.0_13.log
http://beefy11.nyi.freebsd.org/data/head-i386-default/p467853_s332849/logs/qt5-webengine-5.9.4_1.log

vs. green logs

http://beefy11.nyi.freebsd.org/data/head-i386-default/p467743_s332632/logs/iridium-browser-58.0_13.log
http://beefy11.nyi.freebsd.org/data/head-i386-default/p467743_s332632/logs/qt5-webengine-5.9.4_1.log

-- 
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 227698] www/iridium, www/qt5-webengine: clang 6.0 crashes during build

[bugzilla-noreply]

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

Jan Beich  changed:

   What|Removed |Added

   Keywords|needs-qa|regression
 Blocks|224669  |225330


Referenced Bugs:

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=224669
[Bug 224669] [exp-run] Against projects/clang600-import branch
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=225330
[Bug 225330] clang bug can incorrectly enable or disable interrupts on amd64
-- 
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 225330] clang bug can incorrectly enable or disable interrupts on amd64

[bugzilla-noreply]

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

Jan Beich  changed:

   What|Removed |Added

 Depends on||227698


Referenced Bugs:

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=227698
[Bug 227698] www/iridium, www/qt5-webengine: clang 6.0 crashes during build
-- 
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 227686] www/firefox: clang 6.0 crashes during build

[bugzilla-noreply]

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

--- Comment #3 from Jan Beich  ---
Nevermind comment 2, my guess was bogus. www/palemoon and www/waterfox are
affected but mail/thunderbird, www/firefox-esr, www/seamonkey are not. Maybe
the stars haven't aligned on ESR52. ;)

-- 
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 227686] www/firefox: clang 6.0 crashes during build

[bugzilla-noreply]

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

Jan Beich  changed:

   What|Removed |Added

  Flags|maintainer-feedback?(gecko@ |
   |FreeBSD.org)|

-- 
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 227699] devel/powerpc64-gcc: clang 6.0 crashes during build

[bugzilla-noreply]

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

Jan Beich  changed:

   What|Removed |Added

  Flags|maintainer-feedback?(kan@Fr |
   |eeBSD.org)  |
   Assignee|k...@freebsd.org |toolch...@freebsd.org

-- 
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 227723] clang 6.0 breaks php56/opcache

[bugzilla-noreply]

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

--- Comment #2 from Florian Smeets  ---
I reported this to dim@ when clang 6 was merged to head. He created the patch I
attached. It didn't work in my case, I'm still using USE_GCC in my lang/php56
port. I haven't had the time to dig further. Maybe you can try the patch.

-- 
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 227723] clang 6.0 breaks php56/opcache

[bugzilla-noreply]

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

Mark Linimon  changed:

   What|Removed |Added

   Assignee|b...@freebsd.org|toolch...@freebsd.org

-- 
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 227723] clang 6.0 breaks php56/opcache

[bugzilla-noreply]

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

--- Comment #4 from la...@fit.vutbr.cz ---
test case was for constant, which was optimized to immediate, here is another
with variable:

#include 
#include 

#define EX_TMP_VAR(ex, n) ((temp_variable*)(((char*)(ex)) +
((int)(n
#define EX_TMP_VAR_NUM(ex, n)  (EX_TMP_VAR(ex, 0) - (1 + (n)))
#define VAR_NUM(v) ((unsigned int)(EX_TMP_VAR_NUM(0, 0) - EX_TMP_VAR(0, v)))

typedef struct TV {
long tmp;
char tmp3[30];
} temp_variable;

int num = -1000;

int main()
{
printf("%x\n", VAR_NUM(num));
return 0;
}

clang50 result is 18
clang60 result is 6018

The only difference in generated code (clang50 first, clang60 second):

<   movslq  num(%rip), %rax
---
>   movlnum(%rip), %eax
movq$-40, %rcx
subq%rax, %rcx
shrq$3, %rcx


It looks like num is not sign extended before pointer arithmetic.

-- 
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 227723] clang 6.0 breaks php56/opcache

[bugzilla-noreply]

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

--- Comment #3 from la...@fit.vutbr.cz ---
Patch seems to be ok. I've only changed installed header files in
/usr/local/include/php/Zend, recompiled/reinstalled opcache, restarted apache
and it runs.
I've reduced problem to:

#include 
#include 

#define EX_TMP_VAR(ex, n) ((temp_variable*)(((char*)(ex)) +
((int)(n
#define EX_TMP_VAR_NUM(ex, n)  (EX_TMP_VAR(ex, 0) - (1 + (n)))
#define VAR_NUM(v) ((unsigned int)(EX_TMP_VAR_NUM(0, 0) - EX_TMP_VAR(0, v)))

typedef struct TV {
long tmp;
char tmp3[30];
} temp_variable;

int num;

int main()
{
printf("%x\n", VAR_NUM(-100));
return 0;
}

cc -O2 t.c
f99c
clang50 -O2 t.c
1
gcc -O2 t.c
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 225330] clang bug can incorrectly enable or disable interrupts on amd64

[bugzilla-noreply]

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

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

Author: dim
Date: Mon Apr 23 23:07:58 UTC 2018
New revision: 332898
URL: https://svnweb.freebsd.org/changeset/base/332898

Log:
  Pull in r329771 from upstream llvm trunk (by Craig Topper):

[X86] In X86FlagsCopyLowering, when rewriting a memory setcc we need
to emit an explicit MOV8mr instruction.

Previously the code only knew how to handle setcc to a register.

This should fix a crash in the chromium build.

  This fixes various assertion failures while building ports targeting
  i386:
  * www/firefox: isReg() && "This is not a register operand!"
  * www/iridium, www/qt5-webengine: (I.atEnd() || std::next(I) ==
def_instr_end()) && "getVRegDef assumes a single definition or no
definition"
  * devel/powerpc64-gcc: FromReg != ToReg && "Cannot replace a reg with
itself"

  Reported by:  jbeich
  PR:   225330, 227686, 227698, 227699
  MFC after:1 week
  X-MFC-With:   r332833

Changes:
  head/contrib/llvm/lib/Target/X86/X86FlagsCopyLowering.cpp

-- 
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 227698] www/iridium, www/qt5-webengine: clang 6.0 crashes during build

[bugzilla-noreply]

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

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

Author: dim
Date: Mon Apr 23 23:07:58 UTC 2018
New revision: 332898
URL: https://svnweb.freebsd.org/changeset/base/332898

Log:
  Pull in r329771 from upstream llvm trunk (by Craig Topper):

[X86] In X86FlagsCopyLowering, when rewriting a memory setcc we need
to emit an explicit MOV8mr instruction.

Previously the code only knew how to handle setcc to a register.

This should fix a crash in the chromium build.

  This fixes various assertion failures while building ports targeting
  i386:
  * www/firefox: isReg() && "This is not a register operand!"
  * www/iridium, www/qt5-webengine: (I.atEnd() || std::next(I) ==
def_instr_end()) && "getVRegDef assumes a single definition or no
definition"
  * devel/powerpc64-gcc: FromReg != ToReg && "Cannot replace a reg with
itself"

  Reported by:  jbeich
  PR:   225330, 227686, 227698, 227699
  MFC after:1 week
  X-MFC-With:   r332833

Changes:
  head/contrib/llvm/lib/Target/X86/X86FlagsCopyLowering.cpp

-- 
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 227686] www/firefox: clang 6.0 crashes during build

[bugzilla-noreply]

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

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

Author: dim
Date: Mon Apr 23 23:07:58 UTC 2018
New revision: 332898
URL: https://svnweb.freebsd.org/changeset/base/332898

Log:
  Pull in r329771 from upstream llvm trunk (by Craig Topper):

[X86] In X86FlagsCopyLowering, when rewriting a memory setcc we need
to emit an explicit MOV8mr instruction.

Previously the code only knew how to handle setcc to a register.

This should fix a crash in the chromium build.

  This fixes various assertion failures while building ports targeting
  i386:
  * www/firefox: isReg() && "This is not a register operand!"
  * www/iridium, www/qt5-webengine: (I.atEnd() || std::next(I) ==
def_instr_end()) && "getVRegDef assumes a single definition or no
definition"
  * devel/powerpc64-gcc: FromReg != ToReg && "Cannot replace a reg with
itself"

  Reported by:  jbeich
  PR:   225330, 227686, 227698, 227699
  MFC after:1 week
  X-MFC-With:   r332833

Changes:
  head/contrib/llvm/lib/Target/X86/X86FlagsCopyLowering.cpp

-- 
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 227438] clang -fopenmp=libgomp doesn't work

[bugzilla-noreply]

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

Jan Beich  changed:

   What|Removed |Added

 Status|New |Closed
 Resolution|--- |Not A Bug

--- Comment #3 from Jan Beich  ---
Thanks for explanation.

-- 
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 230857] loading carp module panic i386 kernel (VIMAGE related)

[bugzilla-noreply]

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

Bjoern A. Zeeb  changed:

   What|Removed |Added

 Status|Open|In Progress

--- Comment #4 from Bjoern A. Zeeb  ---
Ok, so the short explanation is that having a non-simple-type at the end of the
dpcpu or vnet linker sets and an intelligent compiler/linker combination can
result in the last symbol not being relocated.  In the case of i386/carp this
was the PCPU stats glebius introduced which is an array of 16 pointers.

I've spent a day to think of possible work around and the only one was to add
padding to the end of the section;  with the help of arichardson managed to
work my way around linker scripts and with an extra 8 hours I have a dual-stage
linker-script solution which will only adjust the kernel modules which actually
do have a vnet_set or pcpu_set section and not create one in every module with
the size of 1 byte.

I'll write the entire details up including sample code and the hacked up
prototype solution and post it all here and in phab sometime the next days
(possibly after the weekend).

TODO: investigate which other architectures but i386 are possibly affected by
this as well.

-- 
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 230412] graphics/GraphicsMagick: fails to build with libc++ 7

[bugzilla-noreply]

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

Sunpoet Po-Chuan Hsieh  changed:

   What|Removed |Added

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

--- Comment #8 from Sunpoet Po-Chuan Hsieh  ---
Committed. Thanks!

-- 
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 230412] graphics/GraphicsMagick: fails to build with libc++ 7

[bugzilla-noreply]

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

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

Author: sunpoet
Date: Sun Oct 14 16:29:18 UTC 2018
New revision: 482063
URL: https://svnweb.freebsd.org/changeset/ports/482063

Log:
  Fix build with libc++ 7

  PR:   230412
  Reported by:  jbeich
  Submitted by: dim

Changes:
  head/graphics/GraphicsMagick/Makefile

-- 
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 -r339076 TARGET_ARCH=powerpc64 clang 6.0.1 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

Mark Millard  changed:

   What|Removed |Added

Summary|head -r309179   |head -r339076
   |TARGET_ARCH=powerpc64 clang |TARGET_ARCH=powerpc64 clang
   |3.9.0 based buildworld on   |6.0.1 based buildworld on
   |powerpc64 using |powerpc64 using
   |WITH_LLVM_LIBUNWIND= fails  |WITH_LLVM_LIBUNWIND= fails
   |to build: asserts and   |to build: asserts and
   |rejects .S file contents|rejects .S file contents

-- 
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 #3 from Mark Millard  ---
Note: I recently posted to a list that the problems
still exist as of head -r339076 . This was in reply
to a suggestion to try it.

But the particular experiment was adding WITH_LLVM_LIBUNWIND=
to a src.conf type of file for using devel/powerpc64-gcc to
do the build (on a powerpc64). [clang is still not up to
it.]

For example, UnwindRegistersRestore.S did not get the C-preprocessor
handling that it is designed for and the __ppc__ assembler notation
still has "register designations are a Darwinism" status. The ";"
comment notation also might be a Darwinism as far as I know.

WITH_LLVM_LIBUNWIND= is not yet an option for powerpc64 and the like.

-- 
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 220822] Missing libatomic.a for clang?

[bugzilla-noreply]

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

Jan Beich  changed:

   What|Removed |Added

 Blocks||232546


Referenced Bugs:

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=232546
[Bug 232546] www/firefox-esr: 60.3.0,1 fails with linker_error with TEST=on
-- 
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 230857] loading carp module panic i386 kernel (VIMAGE related)

[bugzilla-noreply]

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

Bjoern A. Zeeb  changed:

   What|Removed |Added

 Depends on||232291, 232289

--- Comment #8 from Bjoern A. Zeeb  ---
Track the dependency problems;  need to solve at least the link_elf one before
we can do the BYTE(1) linker script and follow-up link_elf checks.


Referenced Bugs:

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=232289
[Bug 232289] kern/link_elf.c fails for small sections sizes (https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=232291
[Bug 232291] ld.bfd (newer) and ld.lld (6 and imho 7) create empty sections
when 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 231355] Compiler assert error when compiling lang/qt5-qml

[bugzilla-noreply]

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

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

Author: dim
Date: Wed Oct 31 18:49:08 UTC 2018
New revision: 483602
URL: https://svnweb.freebsd.org/changeset/ports/483602

Log:
  MFH: r481120

  Update to a new snapshot.

  Update LICENSE data per mailing list feedback and move to a seperate
  Makefile.LICENSE for use by other llvm ports.

  MFH: r483054

  Add all patches from base llvm/clang/lld/lldb 6.0 to devel/llvm60

  This adds all the patches that were applied in the past to head, under
  contrib/llvm.  After these, there only minimal diffs left between the
  port sources and the base sources.

  Most of these remaining diffs are due to #ifdef shortcuts in the base
  sources, because we don't compile certain features in.  Other diffs are
  because the port has applied a few changes that we don't have in base.

  While here, use Makefile.LICENSE from the devel/llvm-devel port.

  Approved by:  portmgr (miwi)
  Reviewed by:  brooks
  PR:   212343, 225128, 225471, 226388, 226658, 226872, 229050, 230444,
230604, 231355
  Differential Revision: https://reviews.freebsd.org/D17702

Changes:
_U  branches/2018Q4/
  branches/2018Q4/devel/llvm-devel/Makefile
  branches/2018Q4/devel/llvm-devel/Makefile.LICENSE
  branches/2018Q4/devel/llvm-devel/Makefile.snapshot
  branches/2018Q4/devel/llvm-devel/distinfo
 
branches/2018Q4/devel/llvm-devel/files/lldb-patch-tools_lldb_source_Plugins_Process_FreeBSD_ProcessFreeBSD.cpp
  branches/2018Q4/devel/llvm-devel/pkg-plist
  branches/2018Q4/devel/llvm60/Makefile
  branches/2018Q4/devel/llvm60/files/clang/patch-head-r331066.diff
  branches/2018Q4/devel/llvm60/files/clang/patch-head-r336227.diff
  branches/2018Q4/devel/llvm60/files/clang/patch-head-r338697.diff
  branches/2018Q4/devel/llvm60/files/clang/patch-head-r339019.diff
  branches/2018Q4/devel/llvm60/files/lld/
  branches/2018Q4/devel/llvm60/files/lldb/
  branches/2018Q4/devel/llvm60/files/patch-head-r308867.diff
  branches/2018Q4/devel/llvm60/files/patch-head-r330686.diff
  branches/2018Q4/devel/llvm60/files/patch-head-r331065.diff
  branches/2018Q4/devel/llvm60/files/patch-head-r331366.diff
  branches/2018Q4/devel/llvm60/files/patch-head-r336969.diff
  branches/2018Q4/devel/llvm60/files/patch-head-r336970.diff
  branches/2018Q4/devel/llvm60/files/patch-head-r337615.diff
  branches/2018Q4/devel/llvm60/files/patch-head-r338689.diff

-- 
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 231355] Compiler assert error when compiling lang/qt5-qml

[bugzilla-noreply]

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

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

Author: dim
Date: Fri Oct 26 21:20:07 UTC 2018
New revision: 483054
URL: https://svnweb.freebsd.org/changeset/ports/483054

Log:
  Add all patches from base llvm/clang/lld/lldb 6.0 to devel/llvm60

  This adds all the patches that were applied in the past to head, under
  contrib/llvm.  After these, there only minimal diffs left between the
  port sources and the base sources.

  Most of these remaining diffs are due to #ifdef shortcuts in the base
  sources, because we don't compile certain features in.  Other diffs are
  because the port has applied a few changes that we don't have in base.

  While here, use Makefile.LICENSE from the devel/llvm-devel port.

  Approved by:  brooks (maintainer)
  Reviewed by:  brooks
  PR:   212343, 225128, 225471, 226388, 226658, 226872, 229050, 230444,
230604, 231355
  MFH:  2018Q4
  Differential Revision: https://reviews.freebsd.org/D17702

Changes:
  head/devel/llvm60/Makefile
  head/devel/llvm60/files/clang/patch-head-r331066.diff
  head/devel/llvm60/files/clang/patch-head-r336227.diff
  head/devel/llvm60/files/clang/patch-head-r338697.diff
  head/devel/llvm60/files/clang/patch-head-r339019.diff
  head/devel/llvm60/files/lld/
  head/devel/llvm60/files/lld/patch-head-r331731.diff
  head/devel/llvm60/files/lld/patch-head-r333401.diff
  head/devel/llvm60/files/lld/patch-head-r336664.diff
  head/devel/llvm60/files/lld/patch-head-r336972.diff
  head/devel/llvm60/files/lld/patch-head-r337282.diff
  head/devel/llvm60/files/lld/patch-head-r338251.diff
  head/devel/llvm60/files/lld/patch-head-r338682.diff
  head/devel/llvm60/files/lld/patch-head-r339013.diff
  head/devel/llvm60/files/lld/patch-head-r339304.diff
  head/devel/llvm60/files/lldb/
  head/devel/llvm60/files/lldb/patch-head-r332849.diff
  head/devel/llvm60/files/lldb/patch-head-r332965.diff
  head/devel/llvm60/files/patch-head-r308867.diff
  head/devel/llvm60/files/patch-head-r330686.diff
  head/devel/llvm60/files/patch-head-r331065.diff
  head/devel/llvm60/files/patch-head-r331366.diff
  head/devel/llvm60/files/patch-head-r336969.diff
  head/devel/llvm60/files/patch-head-r336970.diff
  head/devel/llvm60/files/patch-head-r337615.diff
  head/devel/llvm60/files/patch-head-r338689.diff

-- 
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 232911] Assembly code crashes clang

[bugzilla-noreply]

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

Gerald Pfeifer  changed:

   What|Removed |Added

 CC||ger...@freebsd.org
   Assignee|standa...@freebsd.org   |toolch...@freebsd.org

--- Comment #1 from Gerald Pfeifer  ---
Reassigning to toolchain@ ; not that the upstream bug reported by Yuri
(thanks!) now has a much smaller reproducer.

-- 
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 230857] loading carp module panic i386 kernel (VIMAGE related)

[bugzilla-noreply]

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

Bug 232289 Summary: kern/link_elf.c fails for small sections sizes 
(https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=232289

   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 230857] loading carp module panic i386 kernel (VIMAGE related)

[bugzilla-noreply]

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

--- Comment #10 from Bjoern A. Zeeb  ---
As Alex R points out if we run into symbol reordering problems with the extra
variable fix committed, we could add an extra .o file to the end of the list
which (unless there is a linker-script doing magic) should always stay at the
end of the list.
We could add that to just problematic modules or to all modules (and then could
still ignore the extra bytes).
We'd use a static __used variable to not conflict with duplicate symbols or if
that does not work, asm.

I am just adding this to the PR as to write own more possible ways to fix this.

He also mentions -fPIC would probably solve the initial problem (but that's a
totally different can of worms on our i386).

-- 
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 230857] loading carp module panic i386 kernel (VIMAGE related)

[bugzilla-noreply]

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

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

Author: bz
Date: Thu Nov  1 17:26:18 UTC 2018
New revision: 340009
URL: https://svnweb.freebsd.org/changeset/base/340009

Log:
  carpstats are the last virtualised variable in the file and end up at the
  end of the vnet_set.  The generated code uses an absolute relocation at
  one byte beyond the end of the carpstats array.  This means the relocation
  for the vnet does not happen for carpstats initialisation and as a result
  the kernel panics on module load.

  This problem has only been observed with carp and only on i386.
  We considered various possible solutions including using linker scripts
  to add padding to all kernel modules for pcpu and vnet sections.

  While the symbols (by chance) stay in the order of appearance in the file
  adding an unused non-file-local variable at the end of the file will extend
  the size of set_vnet and hence make the absolute relocation for carpstats
  work (think of this as a single-module set_vnet padding).

  This is a (tmporary) hack.  It is the least intrusive one as we need a
  timely solution for the upcoming release.  We will revisit the problem in
  HEAD.  For a lot more information and the possible alternate solutions
  please see the PR and the references therein.

  PR:   230857
  MFC after:3 days

Changes:
  head/sys/netinet/ip_carp.c

-- 
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 231952] emulators/rpcs3: clang crashes during build

[bugzilla-noreply]

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

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

Author: jbeich
Date: Sat Nov 10 10:28:33 UTC 2018
New revision: 484601
URL: https://svnweb.freebsd.org/changeset/ports/484601

Log:
  MFH: r484600

  emulators/rpcs3: unbreak build with clang > 6.0.0

  Assertion failed: (D->getCachedLinkage() == LV.getLinkage()), function
getLVForDecl, file /usr/src/contrib/llvm/tools/clang/lib/AST/Decl.cpp, line
1394.

  PR:   231952
  Reported by:  pkg-fallout
  Submitted by: Roman CAT
  Approved by:  ports-secteam blanket

Changes:
_U  branches/2018Q4/
  branches/2018Q4/emulators/rpcs3/files/patch-Utilities_typemap.h

-- 
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 231952] emulators/rpcs3: clang crashes during build

[bugzilla-noreply]

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

--- Comment #7 from Jan Beich  ---
(In reply to Roman CAT from comment #6)
Thanks. It built fine on
12.0 (clang 6.0.1): https://ptpb.pw/s4K6
13.0 (clang 7.0.1): https://ptpb.pw/p5hn

-- 
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 231952] emulators/rpcs3: clang crashes during build

[bugzilla-noreply]

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

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

Author: jbeich
Date: Sat Nov 10 10:27:35 UTC 2018
New revision: 484600
URL: https://svnweb.freebsd.org/changeset/ports/484600

Log:
  emulators/rpcs3: unbreak build with clang > 6.0.0

  Assertion failed: (D->getCachedLinkage() == LV.getLinkage()), function
getLVForDecl, file /usr/src/contrib/llvm/tools/clang/lib/AST/Decl.cpp, line
1394.

  PR:   231952
  Reported by:  pkg-fallout
  Submitted by: Roman CAT

Changes:
  head/emulators/rpcs3/files/patch-Utilities_typemap.h

-- 
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 231952] emulators/rpcs3: clang crashes during build

[bugzilla-noreply]

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

Roman CAT  changed:

   What|Removed |Added

 CC||roman-...@yandex.ru

--- Comment #6 from Roman CAT  ---
Can be fixed.

Utilites/typemap.h 197

// Type information for each used type
template 
inline const typeinfo g_typeinfo{};

template 
struct typepoly
{
uint type = 0;

typepoly();
};

Change to "const typeinfo g_typeinfo{};"

-- 
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 233143] cc -mcmodel=large croaks on

[bugzilla-noreply]

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

Mark Linimon  changed:

   What|Removed |Added

   Assignee|b...@freebsd.org|toolch...@freebsd.org

-- 
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 233143] cc -mcmodel=large croaks on

[bugzilla-noreply]

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

Dimitry Andric  changed:

   What|Removed |Added

 Status|New |Open
 CC||d...@freebsd.org

--- Comment #1 from Dimitry Andric  ---
Unfortunately, at this time, LLVM does not support large model in combination
with TLS and position-dependent code.  Upstream bug (which has quite a number
of duplicates):

https://bugs.llvm.org/show_bug.cgi?id=26906

Possible workarounds:
* Don't use TLS
* Don't use -mcmodel=large
* Use -fPIE or -fPIC

-- 
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

Ed Maste  changed:

   What|Removed |Added

 Blocks|228911  |

--- Comment #2 from Ed Maste  ---
Drop from 12.0 tracking; there is an open question in the review and this is
unlikely to be resolved before release.


Referenced Bugs:

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=228911
[Bug 228911] FreeBSD 12.0 Release action items
-- 
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 231952] emulators/rpcs3: clang crashes during build

[bugzilla-noreply]

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

Jan Beich  changed:

   What|Removed |Added

   Assignee|ports-b...@freebsd.org  |toolch...@freebsd.org
URL||http://beefy12.nyi.freebsd.
   ||org/data/head-amd64-default
   ||/p481194_s339174/logs/error
   ||s/rpcs3-0.0.5.968.log

--- Comment #3 from Jan Beich  ---
Clang crashes since https://github.com/RPCS3/rpcs3/commit/1b740995a4b6 Affects
at least Clang 8.0.0 (20181001), 7.0.0, 6.0.1 while GCC 8.2.0, 7.3.0 are fine.
Earlier versions don't support C++17 required by RPCS3.

Can you help analyze what's wrong with Clang on FreeBSD?

-- 
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 231952] emulators/rpcs3: clang crashes during build

[bugzilla-noreply]

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

Jan Beich  changed:

   What|Removed |Added

   Keywords||regression

--- Comment #4 from Jan Beich  ---
Clang 6.0.0 on FreeBSD 11.2 is not affected, see https://ptpb.pw/wO-Z
OTOH, devel/llvm60 does crash on FreeBSD 11.2.

-- 
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 230857] loading carp module panic i386 kernel (VIMAGE related)

[bugzilla-noreply]

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

Bjoern A. Zeeb  changed:

   What|Removed |Added

 CC||d...@freebsd.org
   Keywords||toolchain

--- Comment #5 from Bjoern A. Zeeb  ---
I'll start describing the problem from a reduced piece of code, which is not as
big as carp, replicating carpstats, assuming VIMAGE is on:


#include 
#include 
#include 
#include 
#include 
#include 
#include 

struct xstats {
uint64_tfoo1;
uint64_tbar1;
uint64_tbaz1;
uint64_tmad1;

uint64_tfoo2;
uint64_tbar2;
uint64_tbaz2;
uint64_tmad2;

uint64_tfoo3;
uint64_tbar3;
uint64_tbaz3;
uint64_tmad3;

uint64_tfoo4;
uint64_tbar4;
uint64_tbaz4;
uint64_tmad4;
};

VNET_PCPUSTAT_DEFINE(struct xstats, xstats);
VNET_PCPUSTAT_SYSINIT(xstats);


This unrolls into:

 1 struct _hack;
 2 counter_u64_t   vnet_entry_xstats[sizeof(struct xstats) / sizeof(uint64_t)]
__attribute__((__section__("set_vnet"))) __attribute__((__used__));
 3
 4
 5 static void
 6 vnet_xstats_init(const void *unused)
 7 {
 8 do {
 9 for (int i = 0; i < (sizeof((*(__typeof(vnet_entry_xstats)
*) (__curthread())->td_vnet))->vnet_data_base) + (uintptr_t) &
vnet_entry_xstats))) / sizeof(counter_u64_t)); i++)
10 ((*(__typeof(vnet_entry_xstats) *)
(__curthread())->td_vnet))->vnet_data_base) + (uintptr_t) &
vnet_entry_xstats)))[i] = counter_u64_alloc((0x0002));
11 } while (0);
12 }


In essance what looks so complicated is (on a per vnet base):
void *array[16];
for (i=0 ; i<16; i++)
array[i] = alloc();


The above (with the vnet bits), on i386, is translated into:

0340 :
 340:   55  push   %ebp
 341:   89 e5   mov%esp,%ebp
 343:   56  push   %esi
 344:   50  push   %eax
 345:   be c0 ff ff ff  mov$0xffc0,%esi
 34a:   90  nop
 34b:   90  nop
 34c:   90  nop
 34d:   90  nop
 34e:   90  nop
 34f:   90  nop
 350:   c7 04 24 02 00 00 00movl   $0x2,(%esp)
 357:   e8 fc ff ff ff  call   358 
358: R_386_PC32 counter_u64_alloc
 35c:   64 8b 0d 00 00 00 00mov%fs:0x0,%ecx
 363:   8b 89 1c 03 00 00   mov0x31c(%ecx),%ecx
 369:   8b 49 1cmov0x1c(%ecx),%ecx
 36c:   89 84 31 88 14 00 00mov%eax,0x1488(%ecx,%esi,1)
36f: R_386_RELATIVE *ABS*
 373:   83 c6 04add$0x4,%esi
 376:   75 d8   jne350 
 378:   83 c4 04add$0x4,%esp
 37b:   5e  pop%esi
 37c:   5d  pop%ebp
 37d:   c3  ret


Now here's the problem:

__start_set_vnet is 0x1448
__stop_set_vnet is 0x1488


The problem is that the code generated goes like this:

%esi = -64
repeat:
%eax = alloc()
We do all the curthread->td_vnet->vnet_data_base in %ecx and then do
mov%eax,0x1488(%ecx,%esi,1)   
Which is:
move the alloc() result into curthread->td_vnet->vnet_data_base + 0x1488 +
(1 * -64)
Now 0x1488 - 64 gets us to the beginning of the array[] or array[0].

%esi += 4
So next iteration it'll be 0x1488 - 60 or array[1] ... and so on.
while %esi != 0 goto repeat;


It's an easy way to to the for(i=0; i<16; i++) loop.

The problem is that 0x1488 was not relocated.

When we are going over the relocations and calling into elf_relocaddr() the
check for VIMAGE is:

  if (x >= ef->vnet_start && x < ef->vnet_stop) {

In our case we have an *ABS* R_386_RELATIVE of 0x1488, which is ==
ef->vnet_stop but not < ef->vnet_stop.


The real problem is that with non-simple-types the code generated with an
absolute relocation might be just outside the range.  We cannot adjust the
check as there might be a simple-type following in the next section which would
then be relocated.



For CARP this showed up because the VNET_PCPUSTAT_DEFINE() went into the VNET
section the last and hence the problem showed up.  If there was any other, say
int V_Foo after it, we'd never have noticed.   We cannot fully control the
order in which symbols go into the section, or at least not to the extend we'd
like to, so we cannot make sure there's always a char at the end.

The only solution arichardson and I agreed to would be to add 1 byte of padding
to the end of the section.


Using BYTE(1) in a linker script however would always create a set_vnet section
in 

[Bug 230857] loading carp module panic i386 kernel (VIMAGE related)

[bugzilla-noreply]

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

--- Comment #6 from Bjoern A. Zeeb  ---
Created attachment 198004
  --> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=198004=edit
kmod.mk adjustments along with two new linker scripts

-- 
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 #12 from commit-h...@freebsd.org ---
A commit references this bug:

Author: jbeich
Date: Wed Oct 10 21:44:42 UTC 2018
New revision: 481771
URL: https://svnweb.freebsd.org/changeset/ports/481771

Log:
  math/fftw3: drop FreeBSD 11.1 support per EOL

  PR:   220590 (for tracking)

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 231952] emulators/rpcs3: clang crashes during build

[bugzilla-noreply]

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

Dimitry Andric  changed:

   What|Removed |Added

 CC||d...@freebsd.org

--- Comment #5 from Dimitry Andric  ---
Reduced and submitted as https://bugs.llvm.org/show_bug.cgi?id=39246

-- 
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 230857] loading carp module panic i386 kernel (VIMAGE related)

[bugzilla-noreply]

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

--- Comment #7 from Bjoern A. Zeeb  ---
https://reviews.freebsd.org/D17512

-- 
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 230412] graphics/GraphicsMagick: fails to build with libc++ 7

[bugzilla-noreply]

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

--- Comment #6 from Antoine Brodin  ---
@sunpoet : can you verify that the c++03 is no longer needed and remove it?

-- 
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 218860] libelf doesn't reload section headers after update with ELF_C_WRITE

[bugzilla-noreply]

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

Rodney W. Grimes  changed:

   What|Removed |Added

 CC||rgri...@freebsd.org,
   ||toolch...@freebsd.org

-- 
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 218860] libelf doesn't reload section headers after update with ELF_C_WRITE

[bugzilla-noreply]

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

Ed Maste  changed:

   What|Removed |Added

   Assignee|toolch...@freebsd.org   |ema...@freebsd.org
 Status|New |In Progress

-- 
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 225946] /usr/bin/make dumps core with simple Makefile

[bugzilla-noreply]

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

Kubilay Kocak  changed:

   What|Removed |Added

   See Also||https://bugs.freebsd.org/bu
   ||gzilla/show_bug.cgi?id=2266
   ||78
   Keywords||toolchain
  Flags||mfc-stable11+
 Resolution|--- |FIXED
   Assignee|b...@freebsd.org|s...@freebsd.org
 Status|New |Closed
 CC||toolch...@freebsd.org

--- Comment #3 from Kubilay Kocak  ---
MFC'd to stable/11 by sjg in base r331246 as part of bug 226678

Assign to committer that resolved

-- 
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 223752] clang __attribute__((constructor)) gets wrong input parameters

[bugzilla-noreply]

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

Alex S  changed:

   What|Removed |Added

 CC||iwt...@gmail.com

--- Comment #22 from Alex S  ---
(In reply to Dimitry Andric from comment #20)

https://sourceware.org/git/?p=glibc.git;a=blob;f=elf/dl-init.c;h=3e72fa3013a6aaeda05fe61a0ae7af5d46640826;hb=HEAD#l58

-- 
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 234070] problem with lld and wildcard characters in version scripts

[bugzilla-noreply]

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

--- Comment #1 from Tijl Coosemans  ---
Created attachment 200601
  --> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=200601=edit
qt5-version.patch

Quoting https://bugs.llvm.org/show_bug.cgi?id=40176: "If more than one clause
in a version script match the same symbol, the last one takes precedence. Thus,
if you have the catch-all clause at end (i.e. "*"), it overwrites everything."

This patch for Qt5 changes the version scripts to put the catch-all first. 
Note that if this is committed all ports that depend on Qt5 need to be rebuilt
because many library symbols will get a different (corrected) version label.

-- 
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 234070] problem with lld and wildcard characters in version scripts

[bugzilla-noreply]

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

Mark Linimon  changed:

   What|Removed |Added

   Keywords||patch

-- 
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 234070] devel/qt5: problem with lld and wildcard characters in version scripts

[bugzilla-noreply]

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

Tijl Coosemans  changed:

   What|Removed |Added

 CC||toolch...@freebsd.org
   Assignee|toolch...@freebsd.org   |k...@freebsd.org
Summary|problem with lld and|devel/qt5: problem with lld
   |wildcard characters in  |and wildcard characters in
   |version scripts |version scripts

--- Comment #2 from Tijl Coosemans  ---
Assign to kde@ for patch review.

-- 
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 234144] base clang 6.0.0 Assertion failed: (Result.isUninit() && "temporary created multiple times"), function createTemporary

[bugzilla-noreply]

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

--- Comment #4 from Dimitry Andric  ---
Added https://reviews.freebsd.org/D18699 for including the patch in the llvm60
port.

-- 
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 234480] multimedia/aom: clang 7 crashes with aom >= 1.0.0.1109

[bugzilla-noreply]

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

Jan Beich  changed:

   What|Removed |Added

  Flags||maintainer-feedback?(brooks
   ||@FreeBSD.org)

--- Comment #9 from Jan Beich  ---
(In reply to Dimitry Andric from comment #5)
> Please re-check after base r342592, and close if it is now fixed.

I confirm, builds fine on -CURRENT with base Clang 7:
- 13.0 i386:  https://ptpb.pw/-noq (CPUTYPE=native)
- 13.0 amd64: https://ptpb.pw/qPa_

Leaving open per comment 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 234480] multimedia/aom: clang 7 crashes with aom >= 1.0.0.1109

[bugzilla-noreply]

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

Rodney W. Grimes  changed:

   What|Removed |Added

 CC||toolch...@freebsd.org

-- 
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 220103] devel/glib20: ld-elf.so.1: /usr/local/lib/libglib-2.0.so.0: Undefined symbol "environ" (WITH_LLD_IS_LD)

[bugzilla-noreply]

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

Michal Meloun  changed:

   What|Removed |Added

 CC||m...@freebsd.org

--- Comment #12 from Michal Meloun  ---
(In reply to Dimitry Andric from comment #7)
Yes, linker scripts are culprits (at least for mplayer and chromium). And I
think that this issue is related to glib-20 at all, it is only first visible
victim.

'environ' (and several other symbols) is exported from crt1.o as global symbol.
crt1.o (and other startup object files) should be linked to every single
dynamically linked program (but not to shared libraries). So, every program
should export 'environ' as global symbol. But linker scrips used for 
linking mplayer or chromium lowers visibility of all not enumerated symbols to
local, including 'environ' symbol. Thus because 'environ' is referenced at
least from libc (or glib-20), runtime linker complains about undefined symbol.

Simply, linker version scrips used for linking target binary are not compatible
with FreeBSD (just because startup objects linked with target binary emits
global symbols). 

Linker scrips like this

foo {
...
local: *;  
   
   };

cannot be applied to symbols originated from startup object (ctr*.o)

-- 
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 234070] devel/qt5: problem with lld and wildcard characters in version scripts

[bugzilla-noreply]

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

Adriaan de Groot  changed:

   What|Removed |Added

   Assignee|k...@freebsd.org |t...@freebsd.org

--- Comment #4 from Adriaan de Groot  ---
Assigning back to reporter for a next step.

-- 
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 234070] devel/qt5: problem with lld and wildcard characters in version scripts

[bugzilla-noreply]

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

Adriaan de Groot  changed:

   What|Removed |Added

 CC||adr...@freebsd.org

--- Comment #3 from Adriaan de Groot  ---
The patch looks ok. I rebuilt qt5-core with it and noticed that the number of
"private" symbols goes up:

```
[adridg@beastie .../devel/qt5-core]$ for l in
/usr/local/lib/qt5/libQt5*.so; do readelf -a $l | grep @Qt_5_PRIVATE; done | wc
-l
4926
# Rebuild here
[adridg@beastie .../devel/qt5-core]$ for l in
/usr/local/lib/qt5/libQt5*.so; do readelf -a $l | grep @Qt_5_PRIVATE; done | wc
-l
5780
```

But this will need an exp-run (I'm going to leave that to you) and probably a
runtime-test (e.g. start some big-ass Qt5 application like www/falkon) as well.
And bumps to all the Qt5 ports.

-- 
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 220103] devel/glib20: ld-elf.so.1: /usr/local/lib/libglib-2.0.so.0: Undefined symbol "environ" (WITH_LLD_IS_LD)

[bugzilla-noreply]

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

--- Comment #24 from Michal Meloun  ---
(In reply to Dimitry Andric from comment #23)
I was too brief, sorry. 

'environ' symbol is exported from /lib/crt1.o with *global* binding:
# readelf -s /usr/lib/crt1.o | grep environ
46: 0008 8 OBJECT  GLOBAL DEFAULT  COM environ

And it's referenced (not only) from /lib/libc:
# readelf -s /lib/libc.so.7  | grep environ
 3:  0 NOTYPE  GLOBAL DEFAULT  UND environ

For final mplayer link, following command is issued:
'ld … --version-script binary.ver /usr/lib/crt1.o –lc …'
where linker script binary.ver is:
MPLAYER_1 {
  # to support glibcs abhorrent backwards-compatibility hack
  global: _IO_stdin_used;
  local: *;
};

This script changes binding of all (but  _IO_stdin_used) symbols exported by
mplayer from *global* to *local*, including ‘environ’ symbol from linked in
crt1.o. Due to this, 'environ' becomes invisible to other DSO (libc..). So
resulting binary is invalid, it cannot be run-time loaded and linker should
report this issue.
Everything above is also valid for '__progname' symbol.

Actual ld.bfd (2.30, from binutils) correctly report this problem and reject to
build invalid binary:
/usr/bin/ld: mplayer: local symbol '__progname' in /usr/lib/crt1.o is
referenced by DSO

But ld.lld(7.0.1) doesn't and silently produces invalid binary.

The lack of error report and unloadable binary is, imho, evident ld.lld bug.

I can prepare trivial testcase for this, if you want it.

-- 
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 220103] devel/glib20: ld-elf.so.1: /usr/local/lib/libglib-2.0.so.0: Undefined symbol "environ" (WITH_LLD_IS_LD)

[bugzilla-noreply]

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

--- Comment #25 from Michal Meloun  ---
(In reply to Konstantin Belousov from comment #22)
> To be fair, typical cause of occurrence of the second unversioned symbol in
> the readelf -a output is due to the presence of the static (debugging)
> symbol table.
Aha, I did not know this. Thanks for info.

> That said, it is wrong for environ to be exported with any
> version, as well, it must be unversioned in the dynamic symbol table. Our
> rtld is forgiving but in principle we could check.
True. Using version script for final binary (not DSO) looks like stupid idea,
mainly if it contains 'local: *' clause. Moreover, there are more (other then 
'__progname' and 'environ') global symbols exported by /lib/crt*.o stuff.
All above is only quick fix for actual damage.

At this point, and if these programs are really needs version scripts, I know
about only one real solution. Final link should be splitted to two phases.
First phase should link all local objects to one big while applying version
script. Second phase should do final link by using resulting object from first
step without issuing version script.

But that's a big change, it's hard to tell if it's right and if is acceptable
by upstream.

-- 
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 231010] emulators/wine: (amd64) Segmentation fault when built on 12.0-CURRENT/ALPHA

[bugzilla-noreply]

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

Alex S  changed:

   What|Removed |Added

 CC||iwt...@gmail.com

--- Comment #4 from Alex S  ---
> Using USE_GCC=yes works around the problem, but using LLD_UNSAFE=yes with the 
> default toolchain produces broken binaries with the same symptom.

Remove /usr/bin/ld -> /usr/bin/ld.lld symlink and try USE_BINUTILS=yes.

-- 
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 220103] devel/glib20: ld-elf.so.1: /usr/local/lib/libglib-2.0.so.0: Undefined symbol "environ" (WITH_LLD_IS_LD)

[bugzilla-noreply]

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

--- Comment #26 from Dimitry Andric  ---
In any case, I just tried www/chromium, and it does exactly the same dumb thing
as mplayer:

$ cat
/wrkdirs/usr/ports/www/chromium/work/chromium-68.0.3440.106/build/linux/chrome.map
{
global:
  __bss_start;
  __data_start;
  data_start;
  _edata;
  _end;
  _IO_stdin_used;
[...]
local:
  *;
};

I think that the idea is to explicitly "whitelist" any variables that are safe
to export from the main executable, and hide everything else under local.  What
the use of such a scheme is, is not really clear.

If we don't want to mess with this system too much, we might want to simply add
"environ" and any other necessary symbols to the global list

Alternatively, we could just get rid of the linker script completely, and use a
similar approach for mplayer.  We certainly don't need the glibc specific
_IO_stdin_used hack.

-- 
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 220103] devel/glib20: ld-elf.so.1: /usr/local/lib/libglib-2.0.so.0: Undefined symbol "environ" (WITH_LLD_IS_LD)

[bugzilla-noreply]

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

--- Comment #27 from Dimitry Andric  ---
It looks like the chromium version script was introduced here:

https://chromium.googlesource.com/chromium/src.git/+/83365024efd81b5f3439d95c5560465ad2110388%5E%21/

"[Linux build] Add a linker version script to prevent symbol leaks

Bug 770264 was caused by accidentally leaking FreeType symbols from
Chrome.  This CL adds a linker version script to ensure new leaks do
not happen.  Any newly exported symbols must be explicitly added to
the version script."

Unfortunately the chromium issue itself,
https://bugs.chromium.org/p/chromium/issues/detail?id=770264 apparently, is not
viewable by mere mortals.  So much for open source. :)

In any case, it seems that chromium has assumed the responsibility of keeping
up-to-date with all the required exported symbols to make an executable work. 
So probably an upstream bug report is needed, together with a list of FreeBSD
specific symbols that must always be exported.

-- 
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"