[Bug 223752] clang __attribute__((constructor)) gets wrong input parameters

[bugzilla-noreply]

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

--- Comment #9 from Mark Millard  ---
(In reply to dstaesse from comment #7)

I did not manage to find anything that mentioned
the parameters/arguments: You found materials that
I did not. What context(s) were they from?

"portable way": what range of portability? Even having
shared libraries is likely not universal to all C/C++
contexts. Windows .DLL's have a different mechanism
if I remember right. And so on.

But even for a narrower Unix/BSD/Linux context: as far
as I know the conventions are just local/ABI conventions
and the compiler does not drive which conventions are
used: the environment does something to impose the
environment's desired rules.

[I'm no expert on POSIX rules so there might be material
from that direction that I'm not aware of.]

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

[bugzilla-noreply]

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

--- Comment #11 from Mark Millard  ---
(In reply to dstaesse from comment #8)

(In reply to dstaesse from comment #8)

I took a quick grep for -r325700 (head):

# grep -r __init_array_start /usr/src/* | more
/usr/src/contrib/llvm/tools/lld/ELF/Writer.cpp:  Define("__init_array_start",
"__init_array_end", Out::InitArray);
/usr/src/contrib/binutils/ld/scripttempl/elf.sc:
${RELOCATING+${CREATE_SHLIB-PROVIDE_HIDDEN
(${USER_LABEL_PREFIX}__init_array_start = .);}}
/usr/src/contrib/binutils/ld/ChangeLog-2006:(__preinit_array_start,
__preinit_array_end, __init_array_start,
/usr/src/lib/csu/common/ignore_init.c:extern void (*__init_array_start[])(int,
char **, char **) __hidden;
/usr/src/lib/csu/common/ignore_init.c:  array_size = __init_array_end -
__init_array_start;
/usr/src/lib/csu/common/ignore_init.c:  fn = __init_array_start[n];
/usr/src/sys/conf/ldscript.amd64: PROVIDE_HIDDEN (__init_array_start = .);
/usr/src/sys/conf/ldscript.i386: PROVIDE_HIDDEN (__init_array_start = .);
/usr/src/sys/contrib/octeon-sdk/cvmx-shared-linux-o32.ld:  PROVIDE
(__init_array_start = .);
/usr/src/sys/contrib/octeon-sdk/cvmx-shared-linux.ld: PROVIDE_HIDDEN
(__init_array_start = .);
/usr/src/sys/contrib/octeon-sdk/cvmx-shared-linux-n32.ld: PROVIDE_HIDDEN
(__init_array_start = .);

Note the ldscript.* are limited to amd64 and i386 mentioning
__init_array_start explicitly.  The whole block of text:

  .preinit_array :
  {
PROVIDE_HIDDEN (__preinit_array_start = .);
KEEP (*(.preinit_array))
PROVIDE_HIDDEN (__preinit_array_end = .);
  }
  .init_array :
  {
 PROVIDE_HIDDEN (__init_array_start = .);
 KEEP (*(SORT(.init_array.*)))
 KEEP (*(.init_array))
 PROVIDE_HIDDEN (__init_array_end = .);
  }
  .fini_array :
  {
PROVIDE_HIDDEN (__fini_array_start = .);
KEEP (*(.fini_array))
KEEP (*(SORT(.fini_array.*)))
PROVIDE_HIDDEN (__fini_array_end = .);
  }

seems to only to be for those two ldscript.*'s.

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

[bugzilla-noreply]

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

--- Comment #13 from Mark Millard  ---
(In reply to dstaesse from comment #10)

The materials that you have referenced
indicate that __attribute__ ((constructor))
gets no arguments. Details follow.

>From the materials you referenced:

QUOTE
The .preinit_array and .init_array sections must contain function pointers (NOT
code!) The prototype of these functions must be
void func(int argc,char** argv,char** envp)
__libc_csu_init execute them in the following order:
Function pointers in .preinit_array section
Functions marked as __attribute__ ((constructor)), via _init
Function pointers in .init_array section
END QUOTE

Note that __attribute__ ((constructor)) is not for the
*init_array usage, just for usage inside _init .

And from the elf-init.c that you listed:

#ifndef NO_INITFINI
  _init ();
#endif

has no arguments.

So, __attribute__ ((constructor)) routines are called
form a context not explicitly having the erguments
available.

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

[bugzilla-noreply]

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

--- Comment #19 from Mark Millard  ---
(In reply to dstaesse from comment #18)

You are welcome.

My guess is that this is outside POSIX completely and
is just ABI material for what you are doing.

In fact, looking around I found an ARM document
indicating an empty parameter list for its
.init_array context:

 Each translation unit provides a fragment of the constructor vector in an ELF
section called .init_array of type SHT_INIT_ARRAY (=0xE) and section flags
SHF_ALLOC + SHF_WRITE.

 Each element of the vector contains the address of a function of type extern
“C” void (* const)(void) that, when called, performs part or all of the global
object construction for the translation unit. Producers must treat .init_array
sections as if they were read-only.

( http://infocenter.arm.com/help/topic/com.arm.doc.ihi0041e/IHI0041E_cppabi.pdf
page 19 of 24.)

So, not portable across all ABIs that have .init_array .

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

[bugzilla-noreply]

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

Dimitry Andric  changed:

   What|Removed |Added

 Status|New |Closed
 Resolution|--- |Works As Intended

--- Comment #20 from Dimitry Andric  ---
Unfortunately, as you both point out, the exact signature of C constructors and
destructors is not explicitly documented.  However, glibc calls them without
any arguments, and ignores the return value:

https://sourceware.org/git/?p=glibc.git;a=blob;f=elf/soinit.c;h=fe9935732b2dcc3d71b5c0f2e52c32efc642d160;hb=HEAD#l20

and all its test cases and examples use void func(void).

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

[bugzilla-noreply]

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

--- Comment #8 from dstaesse  ---
I agree that the documentation could be more specific about the nature of the
functions that can have this attribute.

It's true that most examples use functions without arguments but that could
just be because they are examples and keep things as simple as possible. Most
of the examples have a main() without arguments as well...

Of course it's glibc specific, but the elf-init.c seems to define the functions
that go into the pre_init array as having (int, char **, char **) arguments:

https://sourceware.org/git/?p=glibc.git;a=blob_plain;f=csu/elf-init.c

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
freebsd-toolchain@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-toolchain
To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org"

[Bug 223752] clang __attribute__((constructor)) gets wrong input parameters

[bugzilla-noreply]

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

--- Comment #15 from dstaesse  ---
Created attachment 188130
  --> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=188130=edit
updated library code

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

[bugzilla-noreply]

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

--- Comment #16 from dstaesse  ---
Your comments make a lot of sense. I updated the library code to call the
functions in the .init_array and .fini_array, and it looks like this works for
our testcases.

This is probably the answer I was looking for.

Thanks a million!

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

[bugzilla-noreply]

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

--- Comment #10 from dstaesse  ---
(In reply to Mark Millard from comment #9)

Thanks a lot for taking time to help me out. I'm definitely no expert on this
matter. Our target is restricted to POSIX.

I've found mostly posts on stackoverflow, definitely nothing that's official
documentation. 
But this gave me some insights:
https://www.cs.stevens.edu/~jschauma/810/elf.html

Here is says that:

The .preinit_array and .init_array sections must contain function pointers (NOT
code!) The prototype of these functions must be

void func(int argc,char** argv,char** envp)

But this may be specific for x86_64.

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

[bugzilla-noreply]

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

--- Comment #7 from dstaesse  ---
(In reply to Mark Millard from comment #5)

Good point, we only tried amd64 and i386. 

This feature seems to be very sparsely documented, with some sources saying
everything but void func(void) is undefined behaviour and others stating that
it can have the same signature as the main() function. The GNU compiler
documentation doesn't give details and clang doesn't document it at all. I've
seen other projects use this, though.

The compiler doesn't seem to check the function signature at all, I've tried to
set the constructor attribute to functions with all sorts of parameters and
complaints.

If this is undefined behaviour, do you know of a portable way to access argv
from a shared library without passing it as a function parameter to some init
call?

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

[bugzilla-noreply]

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

--- Comment #12 from dstaesse  ---
(In reply to Mark Millard from comment #11)

Interesting.

Doesn't the list of func_ptrs have the arguments here as well?

/usr/src/lib/csu/common/ignore_init.c:extern void (*__init_array_start[])(int,
char **, char **) __hidden;

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

[bugzilla-noreply]

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

--- Comment #14 from Mark Millard  ---
(In reply to Mark Millard from comment #13)

Beyond my "form" vs "from" typo and "erguments"
vs. "arguments" typo, I probably also should
have put the word "called" in quotes: the
__attribute__ ((constructor)) routines might end
up inlined in the proper sequence for all
I know.

-- 
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 220233] Clang: Assertion failed: (NextLocalOffset + FileSize + 1 > NextLocalOffset && NextLocalOffset + FileSize + 1 <= CurrentLoadedOffset && "Ran out of source locations!")

[bugzilla-noreply]

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

Ed Maste  changed:

   What|Removed |Added

  Component|gnu |bin
 CC||ema...@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 223680] www/firefox: DTRACE=on fails with /usr/bin/ld: error: ../../js/src/jsarray.o: string table non-null terminated

[bugzilla-noreply]

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

Mark Johnston  changed:

   What|Removed |Added

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

--- Comment #4 from Mark Johnston  ---
This is a problem with r313504. It occurs when linking with ld.bfd as well,
it's just that lld is more strict.

-- 
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 223680] www/firefox: DTRACE=on fails with /usr/bin/ld: error: ../../js/src/jsarray.o: string table non-null terminated

[bugzilla-noreply]

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

--- Comment #2 from Jan Beich  ---
Another way to reproduce:

$ ln -fs ld.lld /usr/bin/ld
$ pkg install autoconf213 gmake python27 mercurial
$ hg clone https://hg.mozilla.org/mozilla-central
$ cd mozilla-central/js/src
$ autoconf-2.13
$ ./configure --disable-jemalloc --enable-dtrace
$ gmake
[...]
/usr/bin/ld: error: ../jsarray.o: string table non-null terminated
clang++: error: linker command failed with exit code 1 (use -v to see
invocation)

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
freebsd-toolchain@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-toolchain
To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org"

[Bug 223551] for external toolchain support, X prefix is not setting build utils for make buildworld

[bugzilla-noreply]

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

--- Comment #10 from Mark Millard  ---
(In reply to sid from comment #9)

What happens if you comment out as below:

 CC= /usr/local/llvm40/bin/clang
 #XCC=/usr/local/llvm40/bin/clang
 CXX=/usr/local/llvm40/bin/clang++
 #XCXX=   /usr/local/llvm40/bin/clang++
 CPP=/usr/local/llvm40/bin/clang-cpp
 #XCPP=   /usr/local/llvm40/bin/clang-cpp

I expect that it would have the same behavior:
absent explicit X?? assignments the ?? assignments
are copied into the internal X??'s before those
X??'s are used.

The same sort of point should apply to AR vs. XAR
and the like if they are similarly duplicates
by content.

You should only needed X?? when you assign
a distinct value from the matching ?? .

That can cut down on the amount of text required
if you care (presuming the test goes as I expect).


I do not see any information for me to analyze for
the rebuild-kernel-twice issue.

But that goes outside this Bugzilla report. I
think we are nearing your being able to close
this report as "not a bug", other than possibly
the original wording in:

https://wiki.freebsd.org/ExternalToolchain

being made clearer.

-- 
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 223551] for external toolchain support, X prefix is not setting build utils for make buildworld

[bugzilla-noreply]

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

--- Comment #11 from s...@bsdmail.com ---
(In reply to Mark Millard from comment #10)
It compiles with the X prefix left out of the compiler and utils. I believe it
will complete successfully.

This bug report can be closed. As for the X compiler/utils prefix, it seems
like it is made specifically for if one compiler is used on the host computer,
while another compiler is used for another purpose, cross compiling, and not
needed if there is a sole (ports/pkg) compiler. Thank you.

-- 
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 223551] for external toolchain support, X prefix is not setting build utils for make buildworld

[bugzilla-noreply]

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

s...@bsdmail.com changed:

   What|Removed |Added

 Status|New |Closed
 Resolution|--- |Works As Intended

-- 
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 223415] lang/rust: don't require SSE2 on i386 (at least for binary packages)

[bugzilla-noreply]

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

Jan Beich  changed:

   What|Removed |Added

 CC||freebsd-toolchain@FreeBSD.o
   ||rg

--- Comment #4 from Jan Beich  ---
Can toolchain@ clarify plans regarding i386 support in future? Is FreeBSD going
to be stuck targeting i486 until the architecture is dead? How much effort port
maintainers are supposed to exert for i486 if upstream projects couldn't care
less? It's not like FreeBSD to care about ancient hardware (unlike NetBSD).

-- 
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 223551] for external toolchain support, X prefix is not setting build utils for make buildworld

[bugzilla-noreply]

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

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

I'll also mention that there is a
port devel/xtoolchain-llvm50 that
installs files to help configure
for using llvm50 as a
cross-compiler.

For example:

# more /usr/local/share/toolchains/llvm50.mk
XCC=/usr/local/bin/clang50
XCXX=/usr/local/bin/clang++50
XCPP=/usr/local/bin/clang-cpp50
XLD=/usr/local/llvm50/bin/ld.lld
CROSS_BINUTILS_PREFIX=/var/empty
X_COMPILER_TYPE=clang

An example for a gcc compiler is:

# more /usr/local/share/toolchains/aarch64-gcc.mk
XCC=/usr/local/bin/aarch64-unknown-freebsd12.0-gcc
XCXX=/usr/local/bin/aarch64-unknown-freebsd12.0-g++
XCPP=/usr/local/bin/aarch64-unknown-freebsd12.0-cpp
CROSS_BINUTILS_PREFIX=/usr/local/aarch64-freebsd/bin/
X_COMPILER_TYPE=gcc

It would take also assigning CC/CXX/CPP/. . . in
order to also use llvm50 materials as the host
compiler/toolchain as well during cross-builds.

(Note that the limiting condition of a cross-build is
a form of native build, where the target happens to
match the host type. But technically the CC/CXX/CPP/. . .
could be assigned but the XCC/XCXX/XCPP/. . . left
unassigned for "self hosted" that avoids the
system compiler.)

One does have to consider what to do with
(showing WITHOUT_ use):

WITHOUT_CROSS_COMPILER=
WITHOUT_SYSTEM_COMPILER=

WITH_SYSTEM_COMPILER= would be directly indicating
to use the system compiler when a cross compiler
does not seem to need to be built.

WITH_CROSS_COMPILE= vs. WITHOUT_CROSS_COMPILER=
is less obvious and I analyzed source code to see
which way had the properties that I was after in
each case.

In my earlier example it was using WITHOUT_ for
both and I explicitly set lots of things. This
makes the case structurally more similar to the
case of avoiding the system compiler (and potential
cross compiler variant): in part it is just replacing
some paths.

It is not obvious what your host-native vs.
cross-build-target intents are for use of:

/usr/local/bin/llvm-as50
/usr/local/bin/llvm-ar50
/usr/local/bin/lld-link50
/usr/local/bin/llvm-nm50
/usr/local/bin/llvm-objdump50
/usr/local/bin/llvm-ranlib50
/usr/local/bin/llvm-strings50

(I've had examples of the host-native
vs. cross-build-toolchain using different
tools.)

You may have to specify more of your intent
for such things in order to find out what is
needed to configure things.

-- 
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 223551] for external toolchain support, X prefix is not setting build utils for make buildworld

[bugzilla-noreply]

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

Mark Millard  changed:

   What|Removed |Added

 CC||mar...@dsl-only.net

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

I expect that there is a misinterpretation of the
https://wiki.freebsd.org/ExternalToolchain wording.
(Easily done.)

I think that https://wiki.freebsd.org/ExternalToolchain
does not well indicate what context it material applies
in vs. what context is does not: XCC, XCXX, XCPP, XAS, etc.
do not replace all uses of CC, CPP, AS, etc. in all
contexts.

The description:

The XCC approach works with top level build targets (buildworld, buildkernel,
etc) and overrides common make variables such as CC, CXX, and AS during the
cross building portions of the build with values specified by the XCC, XCPP,
XAS, etc variables.

(end description)

sounds like all uses of CC, CXX, AS, and the like
are replaced --but that is wrong and would not
work for cross-builds.

For example, for amd64 -> aarch64 (cortex-A53)
cross builds I've used one compiler as the "for
host" CC/CXX/CPP and another compiler and its tool
chain as the "cross compiler to target" XCC/XCPP/. . .
for a cross build context. The cross-compiler tools
can not be used for everything because some
host software is also built for later use in
the overall buildworld that is happening on the
host.

Some recursive makes replace uses of CC/CXX/CPP
and the like with uses of XCC/XCXX/XCPP (for
example). But other make activity uses the
original definitions above (or the defaults for
what is not specified).

I've even done examples of a gcc host compiler
(and its toolchain) and a separate gcc cross
compiler (and its tool chain), avoiding the
system compiler for both aspects. That is
a type of example where things have to
start with CC/CXX/CPP/. . . vs. XCC/XCXX/XCPP/. . .
being distinct and the initial CC/CXX/CPP/. . .
do have to be used but are not the default
(system compiler tied). [devel/*-xtolchain-gcc's
are not setup for this fully automatically:
they are only the cross-compiler/toolchain
part of it.]

I'll supply one example for a cross-build that
has both CC/CXX/CPP and XCC/XCXX/XCPP/XAS/. . .
assignments and needs the distinctions:
(The example is for 12.0 but I've done such
11.x and for 10.x in the past. This does
use the system compiler/toolchain as the
host-targetting compiler/toolchain.)

# more ~/src.configs/src.conf.cortexA53-xtoolchain-gcc.amd64-host
TO_TYPE=aarch64
TOOLS_TO_TYPE=${TO_TYPE}
VERSION_CONTEXT=12.0
#
KERNCONF=GENERIC-NODBG
TARGET=arm64
.if ${.MAKE.LEVEL} == 0
TARGET_ARCH=${TO_TYPE}
.export TARGET_ARCH
.endif
#
WITHOUT_CROSS_COMPILER=
WITHOUT_SYSTEM_COMPILER=
#
WITH_LIBCPLUSPLUS=
WITHOUT_BINUTILS_BOOTSTRAP=
WITHOUT_ELFTOOLCHAIN_BOOTSTRAP=
WITHOUT_CLANG_BOOTSTRAP=
WITH_CLANG=
WITH_CLANG_IS_CC=
WITH_CLANG_FULL=
WITH_CLANG_EXTRAS=
WITHOUT_LLD_BOOTSTRAP=
WITH_LLD=
WITH_LLD_IS_LD=
WITH_LLDB=
#
WITH_BOOT=
WITHOUT_LIB32=
#
WITHOUT_GCC_BOOTSTRAP=
WITHOUT_GCC=
WITHOUT_GCC_IS_CC=
WITHOUT_GNUCXX=
#
NO_WERROR=
#WERROR=
MALLOC_PRODUCTION=
#
WITH_REPRODUCIBLE_BUILD=
WITH_DEBUG_FILES=
#
XCFLAGS+= -mcpu=cortex-a53
XCXXFLAGS+= -mcpu=cortex-a53
# There is no XCPPFLAGS but XCPP gets XCFLAGS content.
#
#
# For TO (so-called "cross") stages . . .
# So-called-cross via ${TO_TYPE}-xtoolchain-gcc/${TO_TYPE}-gcc. . .
# TOOLS_TO_TYPE based on ${TO_TYPE}-xtoolchain-gcc related binutils. . .
#
CROSS_TOOLCHAIN=${TO_TYPE}-gcc
X_COMPILER_TYPE=gcc
CROSS_BINUTILS_PREFIX=/usr/local/${TOOLS_TO_TYPE}-freebsd/bin/
.if ${.MAKE.LEVEL} == 0
XCC=/usr/local/bin/${TOOLS_TO_TYPE}-unknown-freebsd${VERSION_CONTEXT}-gcc
XCXX=/usr/local/bin/${TOOLS_TO_TYPE}-unknown-freebsd${VERSION_CONTEXT}-g++
XCPP=/usr/local/bin/${TOOLS_TO_TYPE}-unknown-freebsd${VERSION_CONTEXT}-cpp
.export XCC
.export XCXX
.export XCPP
XAS=/usr/local/${TOOLS_TO_TYPE}-freebsd/bin/as
XAR=/usr/local/${TOOLS_TO_TYPE}-freebsd/bin/ar
XLD=/usr/local/${TOOLS_TO_TYPE}-freebsd/bin/ld
XNM=/usr/local/${TOOLS_TO_TYPE}-freebsd/bin/nm
XOBJCOPY=/usr/local/${TOOLS_TO_TYPE}-freebsd/bin/objcopy
XOBJDUMP=/usr/local/${TOOLS_TO_TYPE}-freebsd/bin/objdump
XRANLIB=/usr/local/${TOOLS_TO_TYPE}-freebsd/bin/ranlib
XSIZE=/usr/local/${TOOLS_TO_TYPE}-freebsd/bin/size
#NO-SUCH: XSTRINGS=/usr/local/${TOOLS_TO_TYPE}-freebsd/bin/strings
XSTRINGS=/usr/local/bin/${TOOLS_TO_TYPE}-freebsd-strings
.export XAS
.export XAR
.export XLD
.export XNM
.export XOBJCOPY
.export XOBJDUMP
.export XRANLIB
.export XSIZE
.export XSTRINGS
.endif
#
#
# From based on clang (via system). . .
#
.if ${.MAKE.LEVEL} == 0
CC=/usr/bin/clang
CXX=/usr/bin/clang++
CPP=/usr/bin/clang-cpp
.export CC
.export CXX
.export CPP
.endif

(In some respects the above is explicit about
some things that each devel/*-xtoolchain-gcc
sets up to do automatically.)


So ultimately I think the specifics of any

[Bug 223551] for external toolchain support, X prefix is not setting build utils for make buildworld

[bugzilla-noreply]

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

--- Comment #3 from s...@bsdmail.com ---
(In reply to Mark Millard from comment #2)
You're saying the X prefix doesn't replace buildworld compilers and utils in
make.conf settings, it supplements them. If this is the case, perhaps this is
an  incorrect bug report.

My intent was to replace binutils with either elfutils or llvm's utils. It was
in part for purposes of not having to build/install utils and compilers twice
(from the base system, then again from ports), and for modularity and
efficiency of utils and compilers. As far as I'm aware, all of binutil's
replacements are not completed. Down the road it will be better for testing, if
there is a false sense that the package/ports compiler and utils are used, when
base components are used.

llvm40 and llvm50 work much the same. I used llvm50, because I thought perhaps
it's binutils' replacements were more developed.


Here's a sample of my src.conf to use clang/llvm from packages.
#WITHOUT_TOOLCHAIN=yes #binutils is needed
WITH_BINUTILS=yes
WITH_BINUTILS_BOOTSTRAP=yes
WITHOUT_CLANG=yes
WITHOUT_CLANG_BOOTSTRAP=yes
WITHOUT_CPP=yes # uncertain about
WITHOUT_CXX=yes # needed for devd, gperf and c++ libraries # will use llvm40/50
WITH_LLVM_LIBUNWIND=yes

WITH_LLD_BOOTSTRAP=yes
WITH_LLD_IS_LD=yes
WITH_LLVM_LIBUNWIND=yes

WITHOUT_CROSS_COMPILER=yes
WITHOUT_GCC=yes
WITHOUT_GCC_BOOTSTRAP=yes
WITHOUT_GDB=yes
WITHOUT_GPL_DTC=yes
WITHOUT_GNU=yes
WITHOUT_GNUCXX=yes
WITHOUT_GNU_SUPPORT=yes
WITH_LLVM_LIBUNWIND=yes

With your information, I will adjust my src.conf and make.conf and see if that
works for the linker and utils. Thank you.

-- 
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 223551] for external toolchain support, X prefix is not setting build utils for make buildworld

[bugzilla-noreply]

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

--- Comment #6 from Mark Millard  ---
(In reply to sid from comment #5)

So, for whatever reason, you want to:

buildworld buildkernel

in a way that does not build a system
compiler or toolchain in the process,
neither for internal use of the stages
of the build, nor for what would be in
the system after installworld. Also you
do not want to use any pre-existing
system compilers or system tool chain
to do this activity but instead use
a devel/llvm* .

Sound right? (The ports conventions
do not really apply to buildworld,
although there likely is some overlap.)

I used to do this sort of thing for
powerpc64 (self hosted), although before
devel/llvm*'s time. As I remember
I had it build system-clang but not use
system-clang. (At the time clang was
broken in big ways for powerpc64 so the
compiler was basically unusable.) I
had it build various things just to prove
that the builds could complete, even if
they were otherwise unused.

As I remember I had to do things to force
the system include files and libraries to
be used for what I used as the substitute
for the "host system compiler/toolchain".
The files from the compiler's own environment
were not appropriate/sufficient.

In more modern terms this would have been
using lang/gcc7 and its tool chain as the
"host system compiler/toolchain" and
devel/powerpc64-gcc and its tool chain
as the "cross compiler/toolchain", both
targeting powerpc64 (on a powerpc64
context). (Originally it was gcc49 instead
of gcc7.)

May be the below will help, even though it
is not exactly what you are after.

Not adjusting the material for devel/llvm40
or devel/llvm50 but modernizing the content
some and making it reference amd64 and be
appropriate for adm64 (and its set up for
12.0):

(preumes lang/gcc7 and devel/adm64-xtoolchain-gcc
are installed, dependencies included; still shows
building clang materials; I've not tested the
below)

# more /root/src.configs/src.conf.powerpc64-xtoolchain-gcc.powerpc64-host
TO_TYPE=amd64
TOOLS_TO_TYPE=${TO_TYPE}
FROM_TYPE=${TO_TYPE}
TOOLS_FROM_TYPE=${FROM_TYPE}
VERSION_CONTEXT=12.0
#
KERNCONF=GENERIC
TARGET=amd64
.if ${.MAKE.LEVEL} == 0
TARGET_ARCH=${TO_TYPE}
.export TARGET_ARCH
.endif
#
WITHOUT_CROSS_COMPILER=
WITHOUT_SYSTEM_COMPILER=
#
WITH_LIBCPLUSPLUS=
WITHOUT_BINUTILS_BOOTSTRAP=
WITHOUT_ELFTOOLCHAIN_BOOTSTRAP=
WITHOUT_CLANG_BOOTSTRAP=
WITH_CLANG=
WITH_CLANG_IS_CC=
WITH_CLANG_FULL=
WITH_CLANG_EXTRAS=
WITH_LLD=
WITH_LLDB=
#
WITH_BOOT=
WITH_LIB32=
#
WITHOUT_GCC_BOOTSTRAP=
WITHOUT_GCC=
WITHOUT_GCC_IS_CC=
WITHOUT_GNUCXX=
#
NO_WERROR=
#
WERROR=
MALLOC_PRODUCTION=
#
WITH_REPRODUCIBLE_BUILD=
WITH_DEBUG_FILES=
#
#
# For TO (so-called "cross") stages . . .
# So-called-cross via ${TO_TYPE}-xtoolchain-gcc/${TO_TYPE}-gcc. . .
# TOOLS_TO_TYPE based on ${TO_TYPE}-xtoolchain-gcc related binutils. . .
#
CROSS_TOOLCHAIN=${TO_TYPE}-gcc
X_COMPILER_TYPE=gcc
CROSS_BINUTILS_PREFIX=/usr/local/${TOOLS_TO_TYPE}-freebsd/bin/
.if ${.MAKE.LEVEL} == 0
XCC=/usr/local/bin/${TOOLS_TO_TYPE}-unknown-freebsd${VERSION_CONTEXT}-gcc
XCXX=/usr/local/bin/${TOOLS_TO_TYPE}-unknown-freebsd${VERSION_CONTEXT}-g++
XCPP=/usr/local/bin/${TOOLS_TO_TYPE}-unknown-freebsd${VERSION_CONTEXT}-cpp
.export XCC
.export XCXX
.export XCPP
XAS=/usr/local/${TOOLS_TO_TYPE}-freebsd/bin/as
XAR=/usr/local/${TOOLS_TO_TYPE}-freebsd/bin/ar
XLD=/usr/local/${TOOLS_TO_TYPE}-freebsd/bin/ld
XNM=/usr/local/${TOOLS_TO_TYPE}-freebsd/bin/nm
XOBJCOPY=/usr/local/${TOOLS_TO_TYPE}-freebsd/bin/objcopy
XOBJDUMP=/usr/local/${TOOLS_TO_TYPE}-freebsd/bin/objdump
XRANLIB=/usr/local/${TOOLS_TO_TYPE}-freebsd/bin/ranlib
XSIZE=/usr/local/${TOOLS_TO_TYPE}-freebsd/bin/size
#NO-SUCH: XSTRINGS=/usr/local/${TOOLS_TO_TYPE}-freebsd/bin/strings
XSTRINGS=/usr/local/bin/${TOOLS_TO_TYPE}-freebsd-strings
.export XAS
.export XAR
.export XLD
.export XNM
.export XOBJCOPY
.export XOBJDUMP
.export XRANLIB
.export XSIZE
.export XSTRINGS
.endif
#
#
# For FROM (host) stages . . .
# From gccXY (such as gcc7 but not xtoolchain)
# TOOLS_FROM_TYPE's appropriate binutils. . .
#
.if ${.MAKE.LEVEL} == 0
CC=env C_INCLUDE_PATH=/usr/include /usr/local/bin/gcc7 -L/usr/lib
CXX=env C_INCLUDE_PATH=/usr/include CPLUS_INCLUDE_PATH=/usr/include/c++/v1
/usr/local/bin/g++7 -std=c++11 -nostdinc++ -L/usr/lib
CPP=/usr/local/bin/cpp7
.export CC
.export CXX
.export CPP
AS=/usr/local/${TOOLS_FROM_TYPE}-portbld-freebsd${VERSION_CONTEXT}/bin/as
AR=/usr/local/${TOOLS_FROM_TYPE}-portbld-freebsd${VERSION_CONTEXT}/bin/ar
LD=/usr/local/${TOOLS_FROM_TYPE}-portbld-freebsd${VERSION_CONTEXT}/bin/ld
NM=/usr/local/${TOOLS_FROM_TYPE}-portbld-freebsd${VERSION_CONTEXT}/bin/nm
OBJCOPY=/usr/local/${TOOLS_FROM_TYPE}-portbld-freebsd${VERSION_CONTEXT}/bin/objcopy
OBJDUMP=/usr/local/${TOOLS_FROM_TYPE}-portbld-freebsd${VERSION_CONTEXT}/bin/objdump
RANLIB=/usr/local/${TOOLS_FROM_TYPE}-portbld-freebsd${VERSION_CONTEXT}/bin/ranlib
SIZE=/usr/local/${TOOLS_FROM_TYPE}-portbld-freebsd${VERSION_CONTEXT}/bin/size
#NO-SUCH:

[Bug 223551] for external toolchain support, X prefix is not setting build utils for make buildworld

[bugzilla-noreply]

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

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

I used -v to check include paths searched for
devel/llvm50 :

#include <...> search starts here:
 /usr/include/c++/v1
 /usr/local/llvm50/lib/clang/5.0.0/include
 /usr/include

As I would expect for devel/* it looks like
teh devel/llvm* 's were adjusted to use the
system include files by default.

(If there was a lang/llvm50 then it likely would
not have such an adjustment, just like lang/gcc7
does not look there by default.)

So it appears that the following paragraph does
not apply to your context:

As I remember I had to do things to force
the system include files and libraries to
be used for what I used as the substitute
for the "host system compiler/toolchain".
The files from the compiler's own environment
were not appropriate/sufficient.


I will note that currently lld from devel/llvm* 's
are broken on zfs from the fallocate change (ZFS
does not actually support it but lld tries to
use it without detecting the problem). The
devel/llvm* 's need to be updated so that they
build usable lld 's even for use in a zfs
context.

What lld does on zfs after a given version is:

 "/usr/local/llvm50/bin/ld" --eh-frame-hdr -dynamic-linker /libexec/ld-elf.so.1
--hash-style=both --enable-new-dtags -o a.out /usr/lib/crt1.o /usr/lib/crti.o
/usr/lib/crtbegin.o -L/usr/lib /tmp/exception_test-baadc9.o -lc++ -lm -lgcc
--as-needed -lgcc_s --no-as-needed -lc -lgcc --as-needed -lgcc_s --no-as-needed
/usr/lib/crtend.o /usr/lib/crtn.o
/usr/local/llvm50/bin/ld: error: cannot open output file a.out: Invalid
argument
clang-5.0: error: linker command failed with exit code 1 (use -v to see
invocation)

At soem point this will apply to 11.x instead of
just 12.0. (I've not been tracking 11.x and so
do not know the status of zfs and fallocate there.)

-- 
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 223415] lang/rust: don't require SSE2 on i386 (at least for binary packages)

[bugzilla-noreply]

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

Dimitry Andric  changed:

   What|Removed |Added

 CC||d...@freebsd.org

--- Comment #5 from Dimitry Andric  ---
(In reply to Jan Beich from comment #4)
> Can toolchain@ clarify plans regarding i386 support in future? Is FreeBSD
> going to be stuck targeting i486 until the architecture is dead?

I think the architecture itself will live on for quite some time, whether we
like it or not.  In my opinion we should start requiring at least i686 or
higher (or maybe even pentium4).

IIRC there have been plans to start an arch separate from i386, specifically
for updating to 64-bit time_t, that could maybe also be used for such an
update. :)

On the other hand, in Linux land there are already distros dropping i386
completely, e.g: https://www.archlinux.org/news/the-end-of-i686-support/


> How much
> effort port maintainers are supposed to exert for i486 if upstream projects
> couldn't care less? It's not like FreeBSD to care about ancient hardware
> (unlike NetBSD).

At some point, I guess we must simply stop supporting some ports for such
targets.  I can't be too long until firefox and chromium are simply too large
to run in a 32-bit address space...

-- 
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 223551] for external toolchain support, X prefix is not setting build utils for make buildworld

[bugzilla-noreply]

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

Mark Linimon  changed:

   What|Removed |Added

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

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
freebsd-toolchain@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-toolchain
To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org"

[Bug 223420] [patch] rtld(1): fix formatting glitch

[bugzilla-noreply]

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

Bryan Drewery  changed:

   What|Removed |Added

   Assignee|freebsd-toolchain@FreeBSD.o |freebsd-d...@freebsd.org
   |rg  |
 CC||bdrew...@freebsd.org

--- Comment #1 from Bryan Drewery  ---
Not sure what is being fixed here.  All of the other environment variables are
'.It Ev', and they should be prefixed with 'Ev' as well.

Seeing '11-STABLE' here, I think you wanted r318432 MFCd, which I'll do:

commit f74c0ee574162808ddd3f0f7a9a4d4ec412fa421
Author: jonathan 
Date:   Thu May 18 00:32:05 2017 +

Fix some nroff syntax in rtld.1.

When I originally documented the LD_LIBRARY_PATH_FDS environment variable,
I used `.Ev` rather than `.It Ev` to introduce it; this led to the
documentation being embedded in the previous paragraph (LD_LIBRARY_PATH).

Notes:
svn path=/head/; revision=318432

diff --git libexec/rtld-elf/rtld.1 libexec/rtld-elf/rtld.1
index 79f1478bb90d..4347eb018171 100644
--- libexec/rtld-elf/rtld.1
+++ libexec/rtld-elf/rtld.1
@@ -192,7 +192,7 @@ the directories specified by
 will be searched first
 followed by the set of built-in standard directories.
 This variable is unset for set-user-ID and set-group-ID programs.
-.Ev LD_LIBRARY_PATH_FDS
+.It Ev LD_LIBRARY_PATH_FDS
 A colon separated list of file descriptor numbers for library directories.
 This is intended for use within
 .Xr capsicum 4

-- 
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 223776] ports-mgmt/pkg: lld confuses shared library tracking

[bugzilla-noreply]

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

--- Comment #3 from Ed Maste  ---
This should be fixed in pkg 1.10.3

-- 
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 224174] cc: error: unable to execute command: segmentation fault

[bugzilla-noreply]

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

Conrad Meyer  changed:

   What|Removed |Added

 CC||c...@freebsd.org,
   ||d...@freebsd.org
   Assignee|freebsd-b...@freebsd.org|freebsd-toolchain@FreeBSD.o
   ||rg

--- Comment #1 from Conrad Meyer  ---
Clang 4.0.0 crash.  Does the toolchain list own the compiler, or just as/ld
etc?

-- 
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 224174] cc: error: unable to execute command: segmentation fault

[bugzilla-noreply]

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

Dimitry Andric  changed:

   What|Removed |Added

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

--- Comment #2 from Dimitry Andric  ---
All your test cases compile just fine for me, with both clang 4.0.0, 5.0.0 and
5.0.1.  Are these segfaults repeatable?  If not, please test your hardware
carefully, especially the RAM.

-- 
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 223415] lang/rust: don't require SSE2 on i386 (at least for binary packages)

[bugzilla-noreply]

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

Jan Beich  changed:

   What|Removed |Added

 CC||bs...@phoe.frmug.org,
   ||truck...@freebsd.org

--- Comment #10 from Jan Beich  ---
Don or Bertrand, can you check ripgrep binary package from /latest set works
fine on a machine without SSE2? Building locally isn't recommended:
textproc/ripgrep as -j1 has MaxRSS ~539 MiB.

-- 
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 223415] lang/rust: don't require SSE2 on i386 (at least for binary packages)

[bugzilla-noreply]

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

--- Comment #11 from Jan Beich  ---
If you're short on time here're the QA steps:

$ mkdir -p /usr/local/etc/pkg/repos/
$ sed -En '/url/s/quarterly/latest/; /{|}/p' /etc/pkg/FreeBSD.conf \
  >/usr/local/etc/pkg/repos/FreeBSD.conf

$ pkg install ripgrep

$ rg --version
ripgrep 0.7.1
-AVX -SIMD

$ command time -l rg shenanigan /usr/src
/usr/src/share/dict/web2
180127:shenanigan

/usr/src/sys/dev/ciss/ciss.c
3046:* The reason for all these shenanigans is to create a maxio value that

/usr/src/contrib/llvm/lib/Target/X86/X86FastISel.cpp
1089:// Handle extension to 64-bits via sub-register shenanigans.

/usr/src/crypto/heimdal/appl/telnet/telnetd/sys_term.c
485: * Here are some shenanigans to make sure that there
0.62 real 2.80 user 1.91 sys
 13200  maximum resident set size
  2572  average shared memory size
44  average unshared data size
   128  average unshared stack size
  2251  page reclaims
 0  page faults
 0  swaps
  8292  block input operations
 0  block output operations
 0  messages sent
 0  messages received
 0  signals received
  2631  voluntary context switches
  2156  involuntary context switches

$ pkg delete ripgrep

-- 
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 223415] lang/rust: don't require SSE2 on i386 (at least for binary packages)

[bugzilla-noreply]

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

--- Comment #13 from Jan Beich  ---
(In reply to Bertrand Petit from comment #12)
> $ objdump -d usr/local/bin/rg | grep xmm
[...]

WITH_DEBUG=1 port build contains symbol names. It seems xmm registers are used
by __floatdidf and __floatundidf from compiler-rt. Rust compiler always
includes optimized routines on i386 but not always uses them. If my
understanding is correct then the code is dead.

# Rust 1.22.1
https://github.com/rust-lang-nursery/compiler-builtins/blob/0b9844764ea1/build.rs#L3977
https://github.com/rust-lang-nursery/compiler-builtins/blob/0b9844764ea1/src/float/conv.rs#L91
https://github.com/rust-lang-nursery/compiler-builtins/blob/0b9844764ea1/src/float/conv.rs#L120
https://github.com/rust-lang/compiler-rt/blob/c8a8767c56ad/lib/builtins/i386/floatdidf.S
https://github.com/rust-lang/compiler-rt/blob/c8a8767c56ad/lib/builtins/i386/floatundidf.S

-- 
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 223415] lang/rust: don't require SSE2 on i386 (at least for binary packages)

[bugzilla-noreply]

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

--- Comment #12 from Bertrand Petit  ---
(In reply to Jan Beich from comment #11)
Jan, I took another route:

$ fetch http://pkg.freebsd.org/FreeBSD:11:i386/latest/All/ripgrep-0.7.1_3.txz
[...]
$ sha256 ripgrep-0.7.1_3.txz 
SHA256 (ripgrep-0.7.1_3.txz) =
501e31aef29bf5cd7c73bdea4eca376126ee2bf1b06da044071e0d8c3179af51
$ tar xf ripgrep-0.7.1_3.txz
$ objdump -d usr/local/bin/rg | grep xmm
  1d922c:   f2 0f 2a 4c 24 08   cvtsi2sd 0x8(%esp),%xmm1
  1d9232:   f3 0f 10 44 24 04   movss  0x4(%esp),%xmm0
  1d923e:   f2 0f 59 88 13 62 05mulsd  0x56213(%eax),%xmm1
  1d9246:   f2 0f 10 90 03 62 05movsd  0x56203(%eax),%xmm2
  1d924e:   f2 0f 5c ca subsd  %xmm2,%xmm1
  1d9252:   66 0f 56 c2 orpd   %xmm2,%xmm0
  1d9256:   f2 0f 58 c1 addsd  %xmm1,%xmm0
  1d925a:   f2 0f 11 44 24 04   movsd  %xmm0,0x4(%esp)
  1d9268:   f3 0f 10 4c 24 08   movss  0x8(%esp),%xmm1
  1d926e:   f3 0f 10 44 24 04   movss  0x4(%esp),%xmm0
  1d927a:   66 0f 56 88 07 62 05orpd   0x56207(%eax),%xmm1
  1d9282:   f2 0f 5c 88 f7 61 05subsd  0x561f7(%eax),%xmm1
  1d928a:   66 0f 56 80 e7 61 05orpd   0x561e7(%eax),%xmm0
  1d9292:   f2 0f 58 c1 addsd  %xmm1,%xmm0
  1d9296:   f2 0f 11 44 24 04   movsd  %xmm0,0x4(%esp)

Unfortunately cvtsi2sd is an SSE2 instruction, this package wont run on non
SSE2 hosts unless that operation is located in dead code.

-- 
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 223415] lang/rust: don't require SSE2 on i386 (at least for binary packages)

[bugzilla-noreply]

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

--- Comment #14 from Bertrand Petit  ---
(In reply to Jan Beich from comment #13)

You are likely correct. However you have just uncovered a different bug, a
replication on one already fixed in src:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=221733
You may want to adress it to rid the rust bootstrap of SIMD instructions.

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

Dimitry Andric  changed:

   What|Removed |Added

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

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
freebsd-toolchain@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-toolchain
To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org"

[Bug 227723] clang 6.0 breaks php56/opcache

[bugzilla-noreply]

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

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

Author: flo
Date: Mon May 14 14:24:14 UTC 2018
New revision: 469895
URL: https://svnweb.freebsd.org/changeset/ports/469895

Log:
  Prevent php 5.6 (opcache) from segfaulting when compiled with clang 6.0

  PR: 227723
  Submitted by:   dim
  Reported by:flo, la...@fit.vutbr.cz
  Approved by:maintainer timeout
  MFH:2018Q2

Changes:
  head/lang/php56/Makefile
  head/lang/php56/files/patch-Zend_zend__compile.h
  head/lang/php56/files/patch-Zend_zend__execute.h

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

 Resolution|--- |FIXED
 Status|New |Closed

--- Comment #10 from Florian Smeets  ---
Patch was committed to the tree.

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

Author: dim
Date: Fri Apr 27 19:21:41 UTC 2018
New revision: 333070
URL: https://svnweb.freebsd.org/changeset/base/333070

Log:
  MFC r332833:

  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

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

Author: dim
Date: Fri Apr 27 19:21:42 UTC 2018
New revision: 333070
URL: https://svnweb.freebsd.org/changeset/base/333070

Log:
  MFC r332833:

  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

[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

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

 Status|New |Closed
 Resolution|--- |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 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 #11 from commit-h...@freebsd.org ---
A commit references this bug:

Author: jbeich
Date: Fri Apr 27 17:41:18 UTC 2018
New revision: 468476
URL: https://svnweb.freebsd.org/changeset/ports/468476

Log:
  devel/llvm60: apply i386 crashfix after r467849

  PR:   227686, 227698
  Approved by:  portmgr blanket

Changes:
  head/devel/llvm60/Makefile
  head/devel/llvm60/files/patch-fsvn-r332898

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

Author: dim
Date: Fri Apr 27 19:21:41 UTC 2018
New revision: 333070
URL: https://svnweb.freebsd.org/changeset/base/333070

Log:
  MFC r332833:

  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

[Bug 227686] www/firefox: clang 6.0 crashes during build

[bugzilla-noreply]

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

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

Author: dim
Date: Fri Apr 27 19:21:41 UTC 2018
New revision: 333070
URL: https://svnweb.freebsd.org/changeset/base/333070

Log:
  MFC r332833:

  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

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

[bugzilla-noreply]

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

Bug 227686 Summary: www/firefox: clang 6.0 crashes during build
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=227686

   What|Removed |Added

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

[bugzilla-noreply]

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

Bug 227698 Summary: www/iridium, www/qt5-webengine: clang 6.0 crashes during 
build
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=227698

   What|Removed |Added

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

[bugzilla-noreply]

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

Bug 227699 Summary: devel/powerpc64-gcc: clang 6.0 crashes during build
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=227699

   What|Removed |Added

 Status|Open|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 215193] libc++ and libcxxrt: convert to a private library

[bugzilla-noreply]

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

Henry Hu  changed:

   What|Removed |Added

 CC||henry.hu...@gmail.com

--- Comment #3 from Henry Hu  ---
Can we create/revive the libc++ port? We can still have the base version, but
we can also allow people to install the port version, and let other ports
depend on it. When compiling dependent ports, compiler flags can be set to use
the header file from the port, and link with the libc++ library from the port.
During runtime, the port version can use libmap.conf to redirect every program
to use the library from the port.

-- 
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 215193] libc++ and libcxxrt: convert to a private library

[bugzilla-noreply]

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

--- Comment #4 from David Chisnall  ---
(In reply to Henry Hu from comment #3)

That should be fine, as long as there aren't any ABI compatibility problems
between the different versions.  The problem comes when two libraries used by
the same program both use libc++ and end up with different versions.  As long
as it's fine for both to use the newer one (which it should be with libc++)
then that's fine.

We will likely to a libc++ ABI break in 12.0, but that's probably not a good
idea for the port running on 11.

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

Danilo G. Baio  changed:

   What|Removed |Added

 CC||db...@freebsd.org

--- Comment #7 from Danilo G. Baio  ---

I am getting this error when building dns/knot2 only in FreeBSD 12 i386, clang
6.0.0, pr #227620.

./.libs/libknotd.a(libknotd_la-query_module.o): In function
`knotd_mod_stats_incr':
query_module.c:(.text+0x9d0): undefined reference to `__atomic_fetch_add_8'
./.libs/libknotd.a(libknotd_la-query_module.o): In function
`knotd_mod_stats_decr':
query_module.c:(.text+0xa80): undefined reference to `__atomic_fetch_sub_8'
./.libs/libknotd.a(libknotd_la-query_module.o): In function
`knotd_mod_stats_store':
query_module.c:(.text+0xb30): undefined reference to `__atomic_store_8'
cc: error: linker command failed with exit code 1 (use -v to see invocation)


root@12-i386-head:~ # gcc6 -dM -E -x c /dev/null | grep LLONG_LOCK
#define __GCC_ATOMIC_LLONG_LOCK_FREE 1

root@12-i386-head:~ # clang -dM -E -x c /dev/null | grep LLONG_LOCK
#define __CLANG_ATOMIC_LLONG_LOCK_FREE 1
#define __GCC_ATOMIC_LLONG_LOCK_FREE 1

root@12-i386-head:~ # clang --version
FreeBSD clang version 6.0.0 (tags/RELEASE_600/final 326565) (based on LLVM
6.0.0)


root@11-i386-head:~ # gcc6 -dM -E -x c /dev/null | grep LLONG_LOCK
#define __GCC_ATOMIC_LLONG_LOCK_FREE 1

root@11-i386-head:~ # clang -dM -E -x c /dev/null | grep LLONG_LOCK
#define __GCC_ATOMIC_LLONG_LOCK_FREE 1

root@11-i386-head:~ # clang --version
FreeBSD clang version 4.0.0 (tags/RELEASE_400/final 297347) (based on LLVM
4.0.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 227723] clang 6.0 breaks php56/opcache: Broken after clang 6.0 import (on CURRENT)

[bugzilla-noreply]

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

Kubilay Kocak  changed:

   What|Removed |Added

  Flags||merge-quarterly+

--- Comment #12 from Kubilay Kocak  ---
Assign to committer that resolved. Track merge to quarterly.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
freebsd-toolchain@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-toolchain
To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org"

[Bug 193594] stddef.h should define max_align_t

[bugzilla-noreply]

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

Konstantin Belousov  changed:

   What|Removed |Added

 CC||k...@freebsd.org
 Status|New |Closed
 Resolution|--- |FIXED

--- Comment #3 from Konstantin Belousov  ---
Dup of PR210890, already closed.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
freebsd-toolchain@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-toolchain
To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org"

[Bug 193594] stddef.h should define max_align_t

[bugzilla-noreply]

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

Kubilay Kocak  changed:

   What|Removed |Added

 Resolution|FIXED   |DUPLICATE

--- Comment #4 from Kubilay Kocak  ---
Correctly mark as duplicate

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

-- 
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 227941] llvm crash when compiling specific code

[bugzilla-noreply]

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

Jan Beich  changed:

   What|Removed |Added

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

--- Comment #2 from Jan Beich  ---
(In reply to neal from comment #0)
> Preprocessed source(s) and associated run script(s) are located at:
> c++: note: diagnostic msg: /tmp/main-8ed6cc.cpp
> c++: note: diagnostic msg: /tmp/main-8ed6cc.sh

Maybe attach main.cpp or compiler preprocessed source.

-- 
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 #6 from Jan Beich  ---
www/firefox builds fine on 12.0-CURRENT but devel/llvm60 still crashes. Brooks,
can you either back out ports r467849 or import base r332898 as well?

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
freebsd-toolchain@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-toolchain
To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org"

[Bug 227941] clang assertion when compiling C++ code with -fblocks

[bugzilla-noreply]

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

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 227941] clang assertion when compiling C++ code with -fblocks

[bugzilla-noreply]

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

Dimitry Andric  changed:

   What|Removed |Added

 Status|New |Open
Summary|llvm crash when compiling   |clang assertion when
   |specific code   |compiling C++ code with
   ||-fblocks
   See Also||https://bugs.llvm.org/show_
   ||bug.cgi?id=37328
 CC||d...@freebsd.org
   Assignee|toolch...@freebsd.org   |d...@freebsd.org

--- Comment #5 from Dimitry Andric  ---
I can reproduce, also with newer versions of clang.  If assertions are enabled,
it gives:

Assertion failed: (isa(Val) && "cast() argument of incompatible type!"),
function cast, file /usr/src/contrib/llvm/include/llvm/Support/Casting.h, line
255.

Minimized test case:

// clang -cc1 -triple x86_64-- -S -fblocks bug227941-min.cpp
class a {
public:
  template  a(b);
};
class {
public:
  int c(a);
} d;
void f() {
  __attribute__((__blocks__(byref))) int e = d.c([] {});
}

Submitted upstream as: https://bugs.llvm.org/show_bug.cgi?id=37328

-- 
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 227941] llvm crash when compiling specific code

[bugzilla-noreply]

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

--- Comment #4 from n...@wanlink.com ---
Sorry about that.
I missed that the attachment with the .core file didn't make it because of
size.

-- 
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 227941] llvm crash when compiling specific code

[bugzilla-noreply]

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

--- Comment #3 from n...@wanlink.com ---
Created attachment 193022
  --> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=193022=edit
llvm crash output

minus the llvm .core file, it's bigger than allowed.

-- 
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 222641] www/firefox: OPTIMIZED_CFLAGS=off build fails: libgkrust.a: could not read symbols

[bugzilla-noreply]

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

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

Author: jbeich
Date: Sun Dec 31 00:58:13 UTC 2017
New revision: 457658
URL: https://svnweb.freebsd.org/changeset/ports/457658

Log:
  MFH: r457657

  www/firefox: unbreak OPTIMIZED_CFLAGS=off build after r450707

  x86_64-unknown-freebsd/release/libgkrust.a: could not read symbols: File
format not recognized

  PR:   222641
  Reported by:  many
  Approved by:  ports-secteam blanket

Changes:
_U  branches/2017Q4/
  branches/2017Q4/Mk/bsd.gecko.mk

-- 
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 222641] www/firefox: OPTIMIZED_CFLAGS=off build fails: libgkrust.a: could not read symbols

[bugzilla-noreply]

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

Jan Beich  changed:

   What|Removed |Added

 Status|New |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 222641] www/firefox: OPTIMIZED_CFLAGS=off build fails: libgkrust.a: could not read symbols

[bugzilla-noreply]

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

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

Author: jbeich
Date: Sun Dec 31 00:57:07 UTC 2017
New revision: 457657
URL: https://svnweb.freebsd.org/changeset/ports/457657

Log:
  www/firefox: unbreak OPTIMIZED_CFLAGS=off build after r450707

  x86_64-unknown-freebsd/release/libgkrust.a: could not read symbols: File
format not recognized

  PR:   222641
  Reported by:  many

Changes:
  head/Mk/bsd.gecko.mk

-- 
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 223333] science/simlib: crashes nm(1) during build

[bugzilla-noreply]

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

k...@openldap.org changed:

   What|Removed |Added

 CC||k...@openldap.org

--- Comment #4 from k...@openldap.org ---
I ran into this bug using a different port (lcov)... so it's not just "affects
only me".

-- 
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 225025] Base c++ seems to find errors in the /usr/include/c++/v1/type_traits header in base

[bugzilla-noreply]

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

Mark Linimon  changed:

   What|Removed |Added

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

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
freebsd-toolchain@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-toolchain
To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org"

[Bug 225025] Base c++ seems to find errors in the /usr/include/c++/v1/type_traits header in base

[bugzilla-noreply]

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

Dimitry Andric  changed:

   What|Removed |Added

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

--- Comment #1 from Dimitry Andric  ---
Looks like something is defining `__invoke`, and then including the C++
headers.  That should be avoided, any identifiers starting with `_` are
reserved.

Try to find the part of the program that is defining __invoke, and fix that.

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

Mitchell horne  changed:

   What|Removed |Added

 CC||mhorne...@gmail.com

--- Comment #3 from Mitchell horne  ---
(In reply to pete from comment #2)

Here's the readelf section information on the file you provided:

$ readelf --sections ipxe.pxe.tmp

File: ipxe.pxe.tmp
There are 20 section headers, starting at offset 0x702650:

Section Headers:
  [Nr] Name  TypeAddr OffSize   ES Flg Lk Inf
Al
  [ 0]   NULL 00 00 00  0   0 
0
  [ 1] .prefix   PROGBITS 000134 000cb1 00 WAX  0   0 
1
  [ 2] .text16.early PROGBITS 000df0 ee 00 WAX  0   0 
2
  [ 3] .text16.late  PROGBITS00f0 000ee0 0007f2 00 WAX  0   0
16
  [ 4] .data16   PROGBITS 0016e0 000150 00  WA  0   0
16
  [ 5] .bss.data16   NOBITS  0150 0cb780 003040 00  WA  0   0
16
  [ 6] .textdata PROGBITS 001830 0c9ec8 00 WAX  0   0 
4
  [ 7] .bss.textdata NOBITS  000c9f00 0cb780 0a5580 00  WA  0   0
128
  [ 8] .zinfoPROGBITS 0cb6f8 80 00   A  0   0 
1
  [ 9] .debug_info   PROGBITS 0cb778 398f31 00  0   0 
1
  [10] .debug_abbrev PROGBITS 4646a9 054828 00  0   0 
1
  [11] .debug_arangesPROGBITS 4b8ed1 008e50 00  0   0 
1
  [12] .debug_line   PROGBITS 4c1d21 059425 00  0   0 
1
  [13] .debug_strPROGBITS 51b146 05a0b9 01  MS  0   0 
1
  [14] .debug_frame  PROGBITS 575200 02ec7c 00  0   0 
4
  [15] .debug_locPROGBITS 5a3e7c 15183d 00  0   0 
1
  [16] .debug_ranges PROGBITS 6f56b9 00ced0 00  0   0 
1
  [17] .shstrtab STRTAB   702589 c5 00  0   0 
1
  [18] .symtab   SYMTAB   702970 01af40 10 19 4079 
4
  [19] .strtab   STRTAB   71d8b0 01ebe8 00  0   0 
1

It appears that .bss.data16 and .bss.textdata overlap with .debug_info and this
is causing
them to be moved. According to the ELF specification, "Sections in a file may
not overlap.  
No byte in a file resides in more than one section" [1]. So whatever program is
generating
your ELF file is doing so incorrectly. Although GNU objcopy is able to ignore
this when
generating a binary file, it will adjust the section offsets similar to
elftoolchain objcopy
when performing other operations (e.g. objcopy -R .zinfo ipxe.pxe.tmp).

However, I'm not sure why this would be causing you problems either way. When
converting an
ELF file to binary, sections with NOBITS type are ignored since they take up no
actual space
in the file itself. This is the case regardless of which implementation of
objcopy you use. 
Perhaps elftoolchain has a different bug in the binary creation procedure, but
to find that 
you would need to provide additional info on how the binary output file is
unusable.

The simplest workaround (if you still need it at this point) is to use the GNU
version of
objcopy provided in the binutils package.

[1] http://www.skyfree.org/linux/references/ELF_Format.pdf

-- 
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 216080] science/bddsolve: fails to build with lang/gcc6 or later

[bugzilla-noreply]

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

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

Author: ed
Date: Wed Jan 17 14:28:32 UTC 2018
New revision: 459258
URL: https://svnweb.freebsd.org/changeset/ports/459258

Log:
  Upgrade bddsolve to version 1.04.

  This release includes a fix that should make it build with C++14.

  PR:   216080
  Reviewed by:  jbeich
  Differential Revision:https://reviews.freebsd.org/D13951

Changes:
  head/science/bddsolve/Makefile
  head/science/bddsolve/distinfo

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
freebsd-toolchain@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-toolchain
To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org"

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

[bugzilla-noreply]

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

Ed Schouten  changed:

   What|Removed |Added

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

[bugzilla-noreply]

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

Jonathan T. Looney  changed:

   What|Removed |Added

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

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
freebsd-toolchain@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-toolchain
To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org"

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

Bug ID: 225352
   Summary: 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.")
   Product: Base System
   Version: CURRENT
  Hardware: amd64
OS: Any
Status: New
  Severity: Affects Some People
  Priority: ---
 Component: bin
  Assignee: freebsd-toolchain@FreeBSD.org
  Reporter: ger...@freebsd.org

The import of clang 6.0.0 into -CURRENT broke both the emulators/wine
and emulators/wine-devel ports, with clang crashing:

http://beefy12.nyi.freebsd.org/data/head-amd64-default/p459147_s328035/logs/
wine-2.0.4,1.log
http://beefy12.nyi.freebsd.org/data/head-amd64-default/p459147_s328035/logs/
wine-devel-3.0.r6,1.log
http://beefy12.nyi.freebsd.org/data/head-amd64-default/p459306_s328104/logs/
wine-2.0.4,1.log
http://beefy12.nyi.freebsd.org/data/head-amd64-default/p459306_s328104/logs/
wine-devel-3.0.r6,1.log
http://beefy12.nyi.freebsd.org/data/head-amd64-default/p459491_s328183/logs/
wine-2.0.4,1.log
http://beefy12.nyi.freebsd.org/data/head-amd64-default/p459491_s328183/logs/
wine-devel-3.0.r6,1.log

Assertion failed: ((size_t)StackDisp < Context.ArgStoreVector.size() &&
"Function call has more parameters than the stack is adjusted for."),
function collectCallInfo, file
/usr/local/poudriere/jails/head-amd64/usr/src/contrib/llvm/lib/Target/X86/X8
6CallFrameOptimization.cpp, line 449.
cc: error: unable to execute command: Abort trap (core dumped)
cc: error: clang frontend command failed due to signal (use -v to see
invocation)
FreeBSD clang version 6.0.0 (branches/release_60 321788) (based on LLVM
6.0.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 225278] mail/deforaos-mailer: clang 5 crashes during build

[bugzilla-noreply]

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

--- Comment #5 from Dimitry Andric  ---
Submitted https://bugs.llvm.org/show_bug.cgi?id=36031.

Note that tuning down the -fstack-protector setting from 3 (which means 'all')
to 2 (e.g. 'strong') makes the crash go away.  So maybe this can be used as a
workaround.

-- 
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 225278] mail/deforaos-mailer: clang 5 crashes during build

[bugzilla-noreply]

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

Dimitry Andric  changed:

   What|Removed |Added

 CC||d...@freebsd.org

--- Comment #4 from Dimitry Andric  ---
Bisecting shows this to have been introduced with
https://reviews.llvm.org/rL203575 ("ARM: enable tail call optimisation on Thumb
2").  Since that is a very old commit, we seem to be hitting an edge case.

I'll submit a PR upstream, but I would not get my hopes up :)

-- 
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 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 #5 from jack  ---
CC:proposed path, testcase, etc.

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

jack  changed:

   What|Removed |Added

 CC||two...@yahoo.com
 Attachment #189987||maintainer-approval+
  Flags||

--- Comment #4 from jack  ---
Created attachment 189987
  --> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=189987=edit
File:user/password

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

[bugzilla-noreply]

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

Jan Beich  changed:

   What|Removed |Added

 Blocks||219139

--- Comment #2 from Jan Beich  ---
Clang 4 builds fine but Clang 5 crashes with a bit different error:

1.   parser at end of file
2.  Per-module optimization passes
3.  Running pass 'Function Pass Manager' on module 'fxemu-e9d1b4.cpp'.
4.  Running pass 'Loop Pass Manager' on function
'@_Z24fx_computeScreenPointersv'
5.  Running pass 'Unroll loops' on basic block '%vector.body425'


Referenced Bugs:

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=219139
[Bug 219139] [exp-run] Against projects/clang500-import branch
-- 
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 225278] mail/deforaos-mailer: clang 6 crashes during build

[bugzilla-noreply]

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

Jan Beich  changed:

   What|Removed |Added

 CC||freebsd-toolchain@FreeBSD.o
   ||rg
 Blocks|224669  |

--- Comment #2 from Jan Beich  ---
Doh, I didn't notice Clang 5.0 was also crashing:
http://beefy8.nyi.freebsd.org/data/head-armv6-default/p458501_s327711/logs/errors/deforaos-mailer-0.1.7.log


Referenced Bugs:

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=224669
[Bug 224669] [exp-run] Against projects/clang600-import branch
-- 
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 225280] www/palemoon: clang crashes during build

[bugzilla-noreply]

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

Jan Beich  changed:

   What|Removed |Added

 Blocks|224669  |


Referenced Bugs:

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=224669
[Bug 224669] [exp-run] Against projects/clang600-import branch
-- 
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 225278] mail/deforaos-mailer: clang 5 crashes during build

[bugzilla-noreply]

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

Jan Beich  changed:

   What|Removed |Added

Summary|mail/deforaos-mailer: clang |mail/deforaos-mailer: clang
   |6 crashes during build  |5 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 225280] www/palemoon: clang crashes during build

[bugzilla-noreply]

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

Jan Beich  changed:

   What|Removed |Added

   Hardware|Any |arm
 CC||freebsd-...@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 225278] mail/deforaos-mailer: clang 6 crashes during build

[bugzilla-noreply]

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

Jan Beich  changed:

   What|Removed |Added

 Blocks||219139

--- Comment #3 from Jan Beich  ---
Earlier Clang versions didn't crash on this port.

http://beefy15.nyi.freebsd.org/data/latest-per-pkg/deforaos-mailer/0.1.7/110armv6-quarterly.log
(Clang 3.8)
http://beefy15.nyi.freebsd.org/data/latest-per-pkg/deforaos-mailer/0.1.7/111armv6-quarterly.log
(Clang 4)


Referenced Bugs:

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=219139
[Bug 219139] [exp-run] Against projects/clang500-import branch
-- 
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 225280] www/palemoon: clang crashes during build

[bugzilla-noreply]

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

Dimitry Andric  changed:

   What|Removed |Added

 CC||d...@freebsd.org

--- Comment #3 from Dimitry Andric  ---
(In reply to Jan Beich from comment #2)
> Can probably be fixed by applying www/libxul/files/patch-bug1278861

Yes, this looks very much like a duplicate of bug 199450, bug 202229,
https://bugs.llvm.org/show_bug.cgi?id=23229, and
https://bugs.llvm.org/show_bug.cgi?id=23244, which are unfortunately still not
solved upstream, and no movement was detected. :-/

-- 
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 225280] www/palemoon: clang crashes during build

[bugzilla-noreply]

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

--- Comment #4 from lich...@gmail.com ---
Created attachment 189865
  --> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=189865=edit
proposed patch

-- 
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 225280] www/palemoon: clang crashes during build

[bugzilla-noreply]

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

Jan Beich  changed:

   What|Removed |Added

   See Also||https://bugzilla.mozilla.or
   ||g/show_bug.cgi?id=1278861

--- Comment #2 from Jan Beich  ---
Can probably be fixed by applying www/libxul/files/patch-bug1278861

-- 
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 225280] www/palemoon: clang crashes during build

[bugzilla-noreply]

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

Bug ID: 225280
   Summary: www/palemoon: clang crashes during build
   Product: Ports & Packages
   Version: Latest
  Hardware: Any
OS: Any
Status: New
  Keywords: toolchain
  Severity: Affects Only Me
  Priority: ---
 Component: Individual Port(s)
  Assignee: freebsd-ports-b...@freebsd.org
  Reporter: jbe...@freebsd.org
CC: freebsd-toolchain@FreeBSD.org, lich...@gmail.com
Blocks: 224669
CC: lich...@gmail.com
 Flags: maintainer-feedback?(lich...@gmail.com)

Created attachment 189861
  --> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=189861=edit
js/src/asmjs/AsmJSModule.cpp (compressed, preprocessed)

/usr/bin/c++ -o Unified_cpp_js_src0.o -c  -I../../dist/system_wrappers -include
/wrkdirs/usr/ports/www/palemoon/work/Pale-Moon-27.6.2_Release/config/gcc_hidden.h
-DEXPORT_JS_API -DJS_HAS_CTYPES -DDLL_PREFIX='"lib"' -DDLL_SUFFIX='".so"'
-DMOZ_GLUE_IN_PROGRAM -DAB_CD= -DNO_NSPR_10_SUPPORT
-I/wrkdirs/usr/ports/www/palemoon/work/Pale-Moon-27.6.2_Release/js/src -I.
-I/usr/local/lib/libffi-3.2.1/include -I/usr/local/include -I../../dist/include
  -I/usr/local/include/nspr -fPIC  -Qunused-arguments -DLIBICONV_PLUG
-isystem /usr/local/include  -DMOZILLA_CLIENT -include
../../js/src/js-confdefs.h -MD -MP -MF .deps/Unified_cpp_js_src0.o.pp
-Qunused-arguments -DLIBICONV_PLUG -isystem /usr/local/include 
-Qunused-arguments -Wall -Wsign-compare -Wtype-limits -Wno-invalid-offsetof
-Wno-c++0x-extensions -Wno-unknown-warning-option -Wno-return-type-c-linkage
-O2 -pipe -O3 -DLIBICONV_PLUG -isystem /usr/local/include -fno-strict-aliasing
-DLIBICONV_PLUG -isystem /usr/local/include -fno-rtti -ffunction-sections
-fdata-sections -fno-exceptions -fno-math-errno -std=gnu++0x -pipe  -DNDEBUG
-DTRIMMED -O2 -O3  
/wrkdirs/usr/ports/www/palemoon/work/Pale-Moon-/obj-armv6-unknown-freebsd12.0/js/src/Unified_cpp_js_src0.cpp
[...]
Assertion failed: ((PartVT.isInteger() || PartVT == MVT::x86mmx) &&
ValueVT.isInteger() && "Unknown mismatch!"), function getCopyToParts, file
/usr/local/poudriere/jails/head-armv6/usr/src/contrib/llvm/lib/CodeGen/SelectionDAG/SelectionDAGBuilder.cpp,
line 533.
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 (branches/release_60 321788) (based on LLVM 6.0.0)
Target: armv6-unknown-freebsd12.0-gnueabihf
Thread model: posix
InstalledDir: /nxb-bin/usr/bin

http://beefy8.nyi.freebsd.org/data/head-armv6-default/p459021_s327977/logs/errors/palemoon-27.6.2_1.log
(clang 6)
http://beefy8.nyi.freebsd.org/data/head-armv6-default/p458501_s327711/logs/palemoon-27.6.2_1.log
(clang 5)


Referenced Bugs:

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=224669
[Bug 224669] [exp-run] Against projects/clang600-import branch
-- 
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 225280] www/palemoon: clang crashes during build

[bugzilla-noreply]

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

--- Comment #1 from Jan Beich  ---
Created attachment 189862
  --> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=189862=edit
command line args (for clang 6.0)

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

[bugzilla-noreply]

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

Dimitry Andric  changed:

   What|Removed |Added

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

--- Comment #3 from Dimitry Andric  ---
Reproduced, minimized, and reported upstream here:
https://bugs.llvm.org/show_bug.cgi?id=36116

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

Dimitry Andric  changed:

   What|Removed |Added

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

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

Author: dim
Date: Mon Jan 29 18:11:27 UTC 2018
New revision: 328555
URL: https://svnweb.freebsd.org/changeset/base/328555

Log:
  Pull in r217197 from upstream clang trunk (by Richard Smith):

PR20844: If we fail to list-initialize a reference, map to the
referenced type before retrying the initialization to produce
diagnostics. Otherwise, we may fail to produce any diagnostics, and
silently produce invalid AST in a -Asserts build. Also add a note to
this codepath to make it more clear why we were trying to create a
temporary.

  This should fix assertions when parsing some forms of incomplete list
  intializers.

  Direct commit to stable/9 and stable/10, since stable/11 and head
  already have this upstream fix.

  Reported by:  ajcbowh...@gmail.com
  PR:   202665

Changes:
  stable/10/contrib/llvm/tools/clang/include/clang/Basic/DiagnosticSemaKinds.td
  stable/10/contrib/llvm/tools/clang/lib/Sema/SemaInit.cpp
  stable/9/contrib/llvm/tools/clang/include/clang/Basic/DiagnosticSemaKinds.td
  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 187266] clang(1): clang 3.4 aborts when building math/py-numeric with -march=athlon64 on i386

[bugzilla-noreply]

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

Dimitry Andric  changed:

   What|Removed |Added

 Resolution|--- |Unable to Reproduce
 Status|Open|Closed
 CC||d...@freebsd.org

--- Comment #2 from Dimitry Andric  ---
Works for me, on 10.4-STABLE #0 r327717.  Tested both with CPUTYPE=athlon64 and
without any CPUTYPE setting.  Please reopen if it is still reproducible
somehow.

-- 
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 225280] www/palemoon: clang crashes during build

[bugzilla-noreply]

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

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

Author: tobik
Date: Sat Feb  3 12:42:15 UTC 2018
New revision: 460808
URL: https://svnweb.freebsd.org/changeset/ports/460808

Log:
  MFH: r460803

  www/palemoon: Update to 27.7.2

  - Attempt to fix build with Clang 6 [1]

  Changes:  http://www.palemoon.org/releasenotes.shtml
  PR:   225644, 225280 [1]
  Approved by:  lich...@gmail.com (maintainer)
  Security: 5044bd23-08cb-11e8-b08f-00012e582166

  Approved by:  ports-secteam blanket

Changes:
_U  branches/2018Q1/
  branches/2018Q1/www/palemoon/Makefile
  branches/2018Q1/www/palemoon/distinfo
  branches/2018Q1/www/palemoon/files/patch-bug1278861

-- 
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 187266] clang(1): clang 3.4 aborts when building math/py-numeric with -march=athlon64 on i386

[bugzilla-noreply]

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

Jan Beich  changed:

   What|Removed |Added

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

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
freebsd-toolchain@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-toolchain
To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org"

[Bug 225488] clang-6.0.0 crashes building multimedia/libvpx

[bugzilla-noreply]

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

Jan Beich  changed:

   What|Removed |Added

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

--- Comment #2 from Jan Beich  ---
(In reply to Pawel Pekala from comment #0)
> vpx_dsp/x86/variance_sse2.c

A few lines below it says vpx_dsp/x86/sad4d_avx512.c. After playing a bit with
attachment 190105 the issue seems to be -march=native injecting -mno-sse4.1
which isn't reverted by -mavx* e.g.,

$ cd /usr/ports/multimedia/libvpx
$ make clean configure
$ cd `make -V WRKSRC`
$ gmake vpx_dsp_rtcd.h
$ cc -mno-sse4.1 -mavx512bw -I. -c -o vpx_dsp/x86/sad4d_avx512.c.o
vpx_dsp/x86/sad4d_avx512.c

(In reply to Pawel Pekala from comment #1)
> sad4d_avx512-2e4c36.c is 2.4MB and cannot be attached.

Compressing with xz(1) should've worked as well e.g., bug 225086 has one 8.5MB
large if uncompressed.

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

Jan Beich  changed:

   What|Removed |Added

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

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
freebsd-toolchain@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-toolchain
To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org"

[Bug 225488] clang-6.0.0 crashes building multimedia/libvpx

[bugzilla-noreply]

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

--- Comment #3 from Pawel Pekala  ---
Created attachment 190111
  --> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=190111=edit
c file

-- 
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 205934] clang crashes in configure test with #pragma weak

[bugzilla-noreply]

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

Jan Beich  changed:

   What|Removed |Added

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

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
freebsd-toolchain@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-toolchain
To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org"

[Bug 203832] clang crash: frontend command failed due to signal

[bugzilla-noreply]

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

Jan Beich  changed:

   What|Removed |Added

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

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
freebsd-toolchain@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-toolchain
To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org"

[Bug 220822] Missing libatomic.a for clang?

[bugzilla-noreply]

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

Jan Beich  changed:

   What|Removed |Added

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

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
freebsd-toolchain@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-toolchain
To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org"

[Bug 178792] -march=native fails with clang on certain CPU's

[bugzilla-noreply]

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

Jan Beich  changed:

   What|Removed |Added

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

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
freebsd-toolchain@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-toolchain
To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org"

[Bug 210886] clang/llvm-tblgen fails to buid

[bugzilla-noreply]

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

Jan Beich  changed:

   What|Removed |Added

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

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
freebsd-toolchain@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-toolchain
To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org"