Context Navigation

← Previous Ticket
Next Ticket →

#58442 closed defect (invalid)

clang-7.0,8.0,devel - seg. faults when used as assembler with assertions variant active when compiling with gcc and using `-g` to generate debug symbols

Reported by:	mouse07410 (Mouse)	Owned by:	kencu (Ken)
Priority:	Normal	Milestone:
Component:	ports	Version:
Keywords:		Cc:	cjones051073 (Chris Jones)
Port:	clang-7.0 clang-8.0 clang-devel

Description

MacOS 10.14.4, Xcode-10.2.1

$ sudo port install gcc9
Enter PIN for 'Certificate For PIV xxxxxxxxxx': 
--->  Computing dependencies for libgcc
--->  Fetching archive for libgcc
--->  Attempting to fetch libgcc-2.0_0.darwin_18.noarch.tbz2 from https://packages.macports.org/libgcc
--->  Attempting to fetch libgcc-2.0_0.darwin_18.noarch.tbz2 from http://aus.us.packages.macports.org/macports/packages/libgcc
--->  Attempting to fetch libgcc-2.0_0.darwin_18.noarch.tbz2 from http://fco.it.packages.macports.org/mirrors/macports-packages/libgcc
--->  Fetching distfiles for libgcc
--->  Verifying checksums for libgcc
--->  Extracting libgcc
--->  Configuring libgcc
--->  Building libgcc
--->  Staging libgcc into destroot
--->  Installing libgcc @2.0_0
--->  Cleaning libgcc
--->  Computing dependencies for libgcc
--->  Deactivating libgcc @1.0_0
--->  Deactivating libgcc8 @8.3.0_3
--->  Cleaning libgcc
--->  Activating libgcc @2.0_0
--->  Cleaning libgcc
--->  Computing dependencies for gcc9
--->  Fetching archive for gcc9
--->  Attempting to fetch gcc9-9.1.0_1.darwin_18.x86_64.tbz2 from https://packages.macports.org/gcc9
--->  Attempting to fetch gcc9-9.1.0_1.darwin_18.x86_64.tbz2 from http://aus.us.packages.macports.org/macports/packages/gcc9
--->  Attempting to fetch gcc9-9.1.0_1.darwin_18.x86_64.tbz2 from http://fco.it.packages.macports.org/mirrors/macports-packages/gcc9
--->  Fetching distfiles for gcc9
--->  Attempting to fetch gcc-9.1.0.tar.xz from ftp://ftp.funet.fi/pub/mirrors/sources.redhat.com/pub/gcc/releases/gcc-9.1.0/
--->  Verifying checksums for gcc9                                                   
--->  Extracting gcc9
--->  Configuring gcc9
--->  Building gcc9
Error: Failed to build gcc9: command execution failed
Error: See /opt/local/var/macports/logs/_opt_local_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_lang_gcc9/gcc9/main.log for details.
Error: Follow https://guide.macports.org/#project.tickets to report a bug.
Error: Processing of port gcc9 failed
$

Complete log attached.

Attachments (2)

gcc9.main.log.zip (1.8 MB) - added by mouse07410 (Mouse) 6 years ago.: main.log
gcc8.main.log.zip (1.8 MB) - added by mouse07410 (Mouse) 6 years ago.: main.log for gcc8

Change History (64)

Changed 6 years ago by mouse07410 (Mouse)

Attachment:	gcc9.main.log.zip added

main.log

comment:1 follow-up: 27 Changed 6 years ago by mouse07410 (Mouse)

Why does gcc9} port insist on building itself with Macports {{{clang-7.0?

. . . . .
:info:build Stack dump:
:info:build 0.	Program arguments: /opt/local/libexec/llvm-7.0/bin/clang -cc1as -triple x86_64-apple-macosx10.5.0 -filetype obj -main-file-name - -target-cpu core2 -I . -I . -I ../.././gcc -I /opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_lang_gcc9/gcc9/work/gcc-9.1.0/libgcc -I /opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_lang_gcc9/gcc9/work/gcc-9.1.0/libgcc/. -I /opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_lang_gcc9/gcc9/work/gcc-9.1.0/libgcc/../gcc -I /opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_lang_gcc9/gcc9/work/gcc-9.1.0/libgcc/../include -fdebug-compilation-dir /opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_lang_gcc9/gcc9/work/build/x86_64-apple-darwin18/libgcc -dwarf-debug-producer clang version 7.0.1 (tags/RELEASE_701/final) -I . -I . -I ../.././gcc -I /opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_lang_gcc9/gcc9/work/gcc-9.1.0/libgcc -I /opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_lang_gcc9/gcc9/work/gcc-9.1.0/libgcc/. -I /opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_lang_gcc9/gcc9/work/gcc-9.1.0/libgcc/../gcc -I /opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_lang_gcc9/gcc9/work/gcc-9.1.0/libgcc/../include -dwarf-version=2 -mrelocation-model pic -o cpuinfo_s.o - 
:info:build 0  libLLVM.dylib            0x000000010f618f60 llvm::sys::PrintStackTrace(llvm::raw_ostream&) + 37
:info:build 1  libLLVM.dylib            0x000000010f619351 SignalHandler(int) + 200
:info:build 2  libsystem_platform.dylib 0x00007fff60ca0b5d _sigtramp + 29
:info:build 3  libsystem_platform.dylib 0x0000000119c9d938 _sigtramp + 3103772152
:info:build 4  libsystem_c.dylib        0x00007fff60b606a6 abort + 127
:info:build 5  libsystem_c.dylib        0x00007fff60b2920d basename_r + 0
:info:build 6  libLLVM.dylib            0x00000001101f8b29 (anonymous namespace)::MCMachOStreamer::ChangeSection(llvm::MCSection*, llvm::MCExpr const*) + 793
:info:build 7  libLLVM.dylib            0x0000000110206239 llvm::MCStreamer::SwitchSection(llvm::MCSection*, llvm::MCExpr const*) + 97
:info:build 8  libLLVM.dylib            0x000000011023d45b (anonymous namespace)::DarwinAsmParser::parseSectionSwitch(llvm::StringRef, llvm::StringRef, unsigned int, unsigned int, unsigned int) + 201
:info:build 9  libLLVM.dylib            0x000000011023dc9e bool llvm::MCAsmParserExtension::HandleDirective<(anonymous namespace)::DarwinAsmParser, &((anonymous namespace)::DarwinAsmParser::parseSectionDirectiveModInitFunc(llvm::StringRef, llvm::SMLoc))>(llvm::MCAsmParserExtension*, llvm::StringRef, llvm::SMLoc) + 44
:info:build 10 libLLVM.dylib            0x0000000110226b85 (anonymous namespace)::AsmParser::parseStatement((anonymous namespace)::ParseStatementInfo&, llvm::MCAsmParserSemaCallback*) + 2127
:info:build 11 libLLVM.dylib            0x0000000110222a67 (anonymous namespace)::AsmParser::Run(bool, bool) + 395
:info:build 12 clang                    0x000000010db428d0 cc1as_main(llvm::ArrayRef<char const*>, char const*, void*) + 10156
:info:build 13 clang                    0x000000010db3db6b main + 7864
:info:build 14 libdyld.dylib            0x00007fff60abb3d5 start + 1
:info:build 15 libdyld.dylib            0x0000000000000030 start + 2673101916
:info:build clang: error: unable to execute command: Abort trap: 6
:info:build clang: error: clang integrated assembler command failed due to signal (use -v to see invocation)
:info:build clang version 7.0.1 (tags/RELEASE_701/final)
:info:build Target: x86_64-apple-darwin18.5.0
:info:build Thread model: posix
:info:build InstalledDir: /opt/local/libexec/llvm-7.0/bin
:info:build clang: note: diagnostic msg: PLEASE submit a bug report to https://bugs.llvm.org/ and include the crash backtrace, preprocessed source, and associated run script.
:info:build clang: note: diagnostic msg: Error generating preprocessed source(s) - no preprocessable inputs.
:info:build make[3]: *** [cpuinfo_s.o] Error 1

Here's my "normal" setup:

$ port select --list clang
Available versions for clang:
	apple-clang (active)
	mp-clang-6.0
	mp-clang-7.0
	mp-clang-8.0
	none
$ port select --list llvm
Available versions for llvm:
	mp-llvm-6.0
	mp-llvm-7.0
	mp-llvm-8.0
	none (active)
$

I tried installing gcc9 with setting mp-llvm-7.0 and mp-clang-7.0 as default - with the same bad result.

comment:2 Changed 6 years ago by kencu (Ken)

It looks like the clang assembler has crashed somewhere around line build 8 or build 9 in libLLVM.dylib asmParser.

building compilers is very challenging on the toolchain.

my first thought would be to try to disable the clang-7.0 dependency in the gcc Portfile and then deactivate clang-7.0 and try again. That should make as use the system clang, which should work.

And it has crossed my mind that maybe we're being a bit nutty to even have a cctools port and an ld64 port on these very new systems -- sometimes these ports seem to cause nothing but trouble for no visible benefit. Just having an empty port (like libcxx is on newer systems) would be a lot simpler than all our shenanigans.

comment:3 Changed 6 years ago by mouse07410 (Mouse)

First, I completely removed clang-7.0 and llvm-7.0. Build of gcc9 now fails because it requires those ports. I concur that gcc Portfile should not have those dependencies (and with other @kencu suggestions).

Also, I'm hitting a very similar (same?) problem trying to update (or otherwise rebuild) gcc8:

. . . . .
:info:build /opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_lang_gcc8/gcc8/work/build/./gcc/xgcc -B/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_lang_gcc8/gcc8/work/build/./gcc/ -B/opt/local/x86_64-apple-darwin18/bin/ -B/opt/local/x86_64-apple-darwin18/lib/ -isystem /opt/local/x86_64-apple-darwin18/include -isystem /opt/local/x86_64-apple-darwin18/sys-include    -g -O2 -pipe -Os -isysroot/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.14.sdk -O2  -g -O2 -pipe -Os -isysroot/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.14.sdk -DIN_GCC    -W -Wall -Wno-narrowing -Wwrite-strings -Wcast-qual -Wno-format -Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition  -isystem ./include   -mmacosx-version-min=10.5 -pipe -fno-common -g -DIN_LIBGCC2 -fbuilding-libgcc -fno-stack-protector   -mmacosx-version-min=10.5 -pipe -fno-common -I. -I. -I../.././gcc -I/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_lang_gcc8/gcc8/work/gcc-8.3.0/libgcc -I/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_lang_gcc8/gcc8/work/gcc-8.3.0/libgcc/. -I/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_lang_gcc8/gcc8/work/gcc-8.3.0/libgcc/../gcc -I/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_lang_gcc8/gcc8/work/gcc-8.3.0/libgcc/../include    -Wno-missing-prototypes -Wno-type-limits -o fixunstfti_s.o -MT fixunstfti_s.o -MD -MP -MF fixunstfti_s.dep -DSHARED  -c /opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_lang_gcc8/gcc8/work/gcc-8.3.0/libgcc/soft-fp/fixunstfti.c
:info:build Assertion failed: (!CreatedADWARFSection && "Creating regular section after DWARF"), function ChangeSection, file /opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_lang_llvm-8.0/llvm-8.0/work/llvm-8.0.0.src/lib/MC/MCMachOStreamer.cpp, line 159.
:info:build Stack dump:
:info:build 0.	Program arguments: /opt/local/libexec/llvm-8.0/bin/clang -cc1as -triple x86_64-apple-macosx10.5.0 -filetype obj -main-file-name - -target-cpu core2 -I . -I . -I ../.././gcc -I /opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_lang_gcc8/gcc8/work/gcc-8.3.0/libgcc -I /opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_lang_gcc8/gcc8/work/gcc-8.3.0/libgcc/. -I /opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_lang_gcc8/gcc8/work/gcc-8.3.0/libgcc/../gcc -I /opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_lang_gcc8/gcc8/work/gcc-8.3.0/libgcc/../include -fdebug-compilation-dir /opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_lang_gcc8/gcc8/work/build/x86_64-apple-darwin18/libgcc -dwarf-debug-producer clang version 8.0.0 (tags/RELEASE_800/final) -I . -I . -I ../.././gcc -I /opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_lang_gcc8/gcc8/work/gcc-8.3.0/libgcc -I /opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_lang_gcc8/gcc8/work/gcc-8.3.0/libgcc/. -I /opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_lang_gcc8/gcc8/work/gcc-8.3.0/libgcc/../gcc -I /opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_lang_gcc8/gcc8/work/gcc-8.3.0/libgcc/../include -dwarf-version=2 -mrelocation-model pic -o cpuinfo_s.o - 
:info:build 0  libLLVM.dylib            0x0000000104a94bfb llvm::sys::PrintStackTrace(llvm::raw_ostream&) + 40
:info:build 1  libLLVM.dylib            0x0000000104a94ff7 SignalHandler(int) + 188
:info:build 2  libsystem_platform.dylib 0x00007fff60ca0b5d _sigtramp + 29
:info:build 3  libsystem_platform.dylib 0x0000000000004318 _sigtramp + 2671130584
:info:build 4  libsystem_c.dylib        0x00007fff60b606a6 abort + 127
:info:build 5  libsystem_c.dylib        0x00007fff60b2920d basename_r + 0
:info:build 6  libLLVM.dylib            0x00000001057217b8 (anonymous namespace)::MCMachOStreamer::ChangeSection(llvm::MCSection*, llvm::MCExpr const*) + 762
:info:build 7  libLLVM.dylib            0x000000010572ef34 llvm::MCStreamer::SwitchSection(llvm::MCSection*, llvm::MCExpr const*) + 96
:info:build 8  libLLVM.dylib            0x00000001057684d3 (anonymous namespace)::DarwinAsmParser::parseSectionSwitch(llvm::StringRef, llvm::StringRef, unsigned int, unsigned int, unsigned int) + 195
:info:build 9  libLLVM.dylib            0x0000000105768d00 bool llvm::MCAsmParserExtension::HandleDirective<(anonymous namespace)::DarwinAsmParser, &((anonymous namespace)::DarwinAsmParser::parseSectionDirectiveModInitFunc(llvm::StringRef, llvm::SMLoc))>(llvm::MCAsmParserExtension*, llvm::StringRef, llvm::SMLoc) + 44
:info:build 10 libLLVM.dylib            0x000000010575290e (anonymous namespace)::AsmParser::parseStatement((anonymous namespace)::ParseStatementInfo&, llvm::MCAsmParserSemaCallback*) + 3740
:info:build 11 libLLVM.dylib            0x000000010574e285 (anonymous namespace)::AsmParser::Run(bool, bool) + 389
:info:build 12 clang                    0x0000000102e2a518 cc1as_main(llvm::ArrayRef<char const*>, char const*, void*) + 10800
:info:build 13 clang                    0x0000000102e2553d main + 7866
:info:build 14 libdyld.dylib            0x00007fff60abb3d5 start + 1
:info:build 15 libdyld.dylib            0x0000000000000030 start + 2673101916
:info:build clang: error: unable to execute command: Abort trap: 6
:info:build clang: error: clang integrated assembler command failed due to signal (use -v to see invocation)
:info:build clang version 8.0.0 (tags/RELEASE_800/final)
:info:build Target: x86_64-apple-darwin18.5.0
:info:build Thread model: posix
:info:build InstalledDir: /opt/local/libexec/llvm-8.0/bin
:info:build clang: note: diagnostic msg: PLEASE submit a bug report to https://bugs.llvm.org/ and include the crash backtrace, preprocessed source, and associated run script.
:info:build clang: note: diagnostic msg: Error generating preprocessed source(s) - no preprocessable inputs.
:info:build make[3]: *** [cpuinfo_s.o] Error 1

Again, complete log attached.

Changed 6 years ago by mouse07410 (Mouse)

Attachment:	gcc8.main.log.zip added

main.log for gcc8

comment:4 Changed 6 years ago by kencu (Ken)

disable the dep on clang7 in thr gcc9 portfile, deactivare clang7, then try again.

I haven't tried this build. does it fail on the buildbots? why aren't you getting a prebuilt binary anyway.?

Last edited 6 years ago by kencu (Ken) (previous) (diff)

comment:5 Changed 6 years ago by kencu (Ken)

btw, you have an actual assertion failure in that last crashlog, which is helpful.

most likely as you're now using clang8 as the assembler somehow, and assertions are apparently still on.

It's dying in the same source file, which is interesting and also helpful.

Last edited 6 years ago by kencu (Ken) (previous) (diff)

comment:6 follow-up: 9 Changed 6 years ago by mouse07410 (Mouse)

disable the dep on clang7 in the gcc9 portfile, deactivate clang7, then try again.

The "deactivate" part I get (I don't have clang-7.0 any more, would need to deactivate clang-8.0 ;) - but how do I disable something in a Portfile???

does it fail on the buildbots?

I've no idea.

why aren't you getting a prebuilt binary anyway?

Ah, this is the question I'd love to learn the answer. I seem to recall that most (all?) of the previous gcc8 (and gcc7?) updates were downliaded as prebuilt binaries. There are no variants to this port. So, WTF? Why doesn't it pull the prebuilt binaries?

comment:7 Changed 6 years ago by mouse07410 (Mouse)

And then a miracle happened (after the n-th time of sudo port clean gcc8 gcc9; sudo port selfupdate):

$ sudo port install gcc9
Enter PIN for 'Certificate For PIV Authentication (xxxxxxxx)': 
--->  Computing dependencies for libgcc9
--->  Fetching archive for libgcc9
--->  Attempting to fetch libgcc9-9.1.0_1.darwin_18.x86_64.tbz2 from https://packages.macports.org/libgcc9
--->  Attempting to fetch libgcc9-9.1.0_1.darwin_18.x86_64.tbz2.rmd160 from https://packages.macports.org/libgcc9
--->  Installing libgcc9 @9.1.0_1
--->  Cleaning libgcc9
--->  Computing dependencies for libgcc9
--->  Deactivating libgcc9 @9.1.0_0
--->  Cleaning libgcc9
--->  Activating libgcc9 @9.1.0_1
--->  Cleaning libgcc9
--->  Computing dependencies for gcc9
--->  Fetching archive for gcc9
--->  Attempting to fetch gcc9-9.1.0_1.darwin_18.x86_64.tbz2 from https://packages.macports.org/gcc9
--->  Attempting to fetch gcc9-9.1.0_1.darwin_18.x86_64.tbz2.rmd160 from https://packages.macports.org/gcc9
--->  Installing gcc9 @9.1.0_1
--->  Activating gcc9 @9.1.0_1
--->  Cleaning gcc9
--->  Scanning binaries for linking errors
--->  Found 6 broken files, matching files to ports      
--->  Found 1 broken port, determining rebuild order
You can always run 'port rev-upgrade' again to fix errors.
The following ports will be rebuilt: gcc8 @8.3.0
Continue? [Y/n]: 
--->  Computing dependencies for libgcc8
--->  Fetching archive for libgcc8
--->  Attempting to fetch libgcc8-8.3.0_4.darwin_18.x86_64.tbz2 from https://packages.macports.org/libgcc8
--->  Attempting to fetch libgcc8-8.3.0_4.darwin_18.x86_64.tbz2.rmd160 from https://packages.macports.org/libgcc8
--->  Installing libgcc8 @8.3.0_4
--->  Cleaning libgcc8
--->  Computing dependencies for libgcc8
--->  Deactivating libgcc8 @8.3.0_3
--->  Cleaning libgcc8
--->  Activating libgcc8 @8.3.0_4
--->  Cleaning libgcc8
--->  Computing dependencies for gcc8
--->  Fetching archive for gcc8
--->  Attempting to fetch gcc8-8.3.0_4.darwin_18.x86_64.tbz2 from https://packages.macports.org/gcc8
--->  Attempting to fetch gcc8-8.3.0_4.darwin_18.x86_64.tbz2.rmd160 from https://packages.macports.org/gcc8
--->  Installing gcc8 @8.3.0_4
--->  Cleaning gcc8
--->  Computing dependencies for gcc8
--->  Deactivating gcc8 @8.3.0_0
--->  Cleaning gcc8
--->  Activating gcc8 @8.3.0_4
--->  Cleaning gcc8
--->  Scanning binaries for linking errors
--->  No broken files found.                             
--->  No broken ports found.

So, the build is probably still screwed up - but since it does find/get the prebuilt binary now, the urgency is probably lower.

comment:8 follow-up: 28 Changed 6 years ago by mouse07410 (Mouse)

I take the success call back: it installed GCC9, but seems unable to use it correctly:

$ cd ntl-11.3.2
$ ./configure DEF_PREFIX=/opt/local
Compilation failed
See CompilerOutput.log for details
Goodbye! at DoConfig line 616.
$ cat CompilerOutput.log
*** CompilerOutput.log ***
*** building GenConfigInfo
g++ -I../include -I.  -g -O2   -o  GenConfigInfo GenConfigInfo.cpp -lm
Assertion failed: (!CreatedADWARFSection && "Creating regular section after DWARF"), function ChangeSection, file /opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_lang_llvm-8.0/llvm-8.0/work/llvm-8.0.0.src/lib/MC/MCMachOStreamer.cpp, line 159.
Stack dump:
0.	Program arguments: /opt/local/libexec/llvm-8.0/bin/clang -cc1as -triple x86_64-apple-macosx10.14.0 -filetype obj -main-file-name cceE8CeD.s -target-cpu penryn -I ../include -I . -fdebug-compilation-dir /Users/ur20980/src/ntl-11.3.2/src -dwarf-debug-producer clang version 8.0.0 (tags/RELEASE_800/final) -I ../include -I . -dwarf-version=4 -mrelocation-model pic -o /var/folders/c6/lnc_0m093ys8w16md_fm1mnxhtfnj8/T//ccVs4mYb.o /var/folders/c6/lnc_0m093ys8w16md_fm1mnxhtfnj8/T//cceE8CeD.s 
0  libLLVM.dylib            0x000000010fbadbfb llvm::sys::PrintStackTrace(llvm::raw_ostream&) + 40
1  libLLVM.dylib            0x000000010fbadff7 SignalHandler(int) + 188
2  libsystem_platform.dylib 0x00007fff60ca0b5d _sigtramp + 29
3  libLLVM.dylib            0x0000000112ac8a2c (anonymous namespace)::NoOpLoopAnalysis::Key + 448156
4  libsystem_c.dylib        0x00007fff60b606a6 abort + 127
5  libsystem_c.dylib        0x00007fff60b2920d basename_r + 0
6  libLLVM.dylib            0x000000011083a7b8 (anonymous namespace)::MCMachOStreamer::ChangeSection(llvm::MCSection*, llvm::MCExpr const*) + 762
7  libLLVM.dylib            0x0000000110847f34 llvm::MCStreamer::SwitchSection(llvm::MCSection*, llvm::MCExpr const*) + 96
8  libLLVM.dylib            0x00000001108814d3 (anonymous namespace)::DarwinAsmParser::parseSectionSwitch(llvm::StringRef, llvm::StringRef, unsigned int, unsigned int, unsigned int) + 195
9  libLLVM.dylib            0x0000000110881d00 bool llvm::MCAsmParserExtension::HandleDirective<(anonymous namespace)::DarwinAsmParser, &((anonymous namespace)::DarwinAsmParser::parseSectionDirectiveModInitFunc(llvm::StringRef, llvm::SMLoc))>(llvm::MCAsmParserExtension*, llvm::StringRef, llvm::SMLoc) + 44
10 libLLVM.dylib            0x000000011086b90e (anonymous namespace)::AsmParser::parseStatement((anonymous namespace)::ParseStatementInfo&, llvm::MCAsmParserSemaCallback*) + 3740
11 libLLVM.dylib            0x0000000110867285 (anonymous namespace)::AsmParser::Run(bool, bool) + 389
12 clang                    0x000000010df3f518 cc1as_main(llvm::ArrayRef<char const*>, char const*, void*) + 10800
13 clang                    0x000000010df3a53d main + 7866
14 libdyld.dylib            0x00007fff60abb3d5 start + 1
clang: error: unable to execute command: Abort trap: 6
clang: error: clang integrated assembler command failed due to signal (use -v to see invocation)
clang version 8.0.0 (tags/RELEASE_800/final)
Target: x86_64-apple-darwin18.5.0
Thread model: posix
InstalledDir: /opt/local/libexec/llvm-8.0/bin
clang: note: diagnostic msg: PLEASE submit a bug report to https://bugs.llvm.org/ and include the crash backtrace, preprocessed source, and associated run script.
clang: note: diagnostic msg: Error generating preprocessed source(s) - no preprocessable inputs.
make: *** [GenConfigInfo] Error 1
$

comment:9 in reply to: 6 Changed 6 years ago by kencu (Ken)

Replying to mouse07410:

how do I disable something in a Portfile???

I think your level of expertise, questions, and interest has evolved to the point where you can probably dig in helpfully now.

All the instructions for how things in MacPorts are built are kept in fairly simple-to-read recipes called Portfiles. Every port has one, inside a directory named after the port (usually...).

So to see the gcc9 Portfile, you could do something like this:

$ port file gcc9
/opt/local/var/macports/sources/rsync.macports.org/release/tarballs/ports/lang/gcc9/Portfile

and to edit it, just use your favourite capable editor -- I like bbedit, like this:

bbedit /opt/local/var/macports/sources/rsync.macports.org/release/tarballs/ports/lang/gcc8/Portfile

or -- in one step, using backticks:

bbedit `port file gcc9`

And in there you would see a bit of tcl code that looks for various system versions, and sets a dependency on various clang versions. So you would comment that out that dependency using a # character, and that's how you disable something in a Portfile.

Now -- don't make things worse for yourself. You have to know what you're doing here, and not do something silly and then blame us for it.

BUT -- as you've just demonstrated again, you are having an assembler issue building gcc9 with clang-7.0 (and clang-8.0) -- so disable that, and use the Xcode clang instead. like this:

In the current gcc9 Portfile, we see this:

# Make sure the MP clang version used by cctool's 'as' is available at build time and used.
if { ${os.major} > 10 } {
    if {![catch {set installed [lindex [registry_active cctools] 0]}]} {
        # cctools already installed, so figure out from registry what variant to use
        # list here must have all possible variants from cctools in it
        foreach {llvm_v llvm_v_nodot} {3.4 34 3.7 37 3.9 39 4.0 40 5.0 50 6.0 60 7.0 70 8.0 80 devel dev} {
            if {[active_variants cctools llvm${llvm_v_nodot} ""]} {
                depends_build-append port:clang-${llvm_v}
                configure.compiler macports-clang-${llvm_v}
                break
            }
        }
    } else {
        # cctools is not yet installed, so have to play 'guess the default variant' :(
        # Logic here needs to match that used in cctools port.
        if { ${os.major} <= 11 } {
            set llvm_v 3.4
        } elseif { ${os.major} <= 13 } {
            set llvm_v 3.7
        } else {
            set llvm_v 7.0
        }
        depends_build-append port:clang-${llvm_v}
        configure.compiler macports-clang-${llvm_v}
    }
}

So - for your purposes right now, just delete that whole block (it's going to be restored again next time you sudo port selfupdate anyway). Then deactivate clang-7.0, clang-8.0, and then try your build of gcc9 again.

It should not ask for any clang any longer (as you just deleted the part that made it ask for clang) and you will now get the Xcode clang called instead. We all hope that one works for you.

If it does, we can use that information to figure out what has gone wrong with the clang-7+ assembler.

Don't forget to be neat and tidy. Clean between attempts, or you just get sausage. REMEMBER any mods you make to other ports, or NOBODY will be able to help you.

But if you're ready for the next step, we can always use help!

Last edited 6 years ago by kencu (Ken) (previous) (diff)

comment:10 follow-up: 11 Changed 6 years ago by mouse07410 (Mouse)

I think your level of expertise, questions, and interest has evolved to the point where you can probably dig in helpfully now

You're flattering me. ;-)

Two questions. One - is it possible to somehow "virtualize" the environment, so that my experiments would be on a cloned/safe copy rather than on the main Macports setup? Two - it seems to me that Macports GCC should have "-Wa,-q" (or its analog) on by default, because otherwise there's no usable assembler anyway. Comments?

comment:11 in reply to: 10 Changed 6 years ago by kencu (Ken)

Replying to mouse07410:

Two questions. One - is it possible to somehow "virtualize" the environment, so that my experiments would be on a cloned/safe copy rather than on the main Macports setup?

You can set up a separate MacPorts installation for that (tedious as you have to build _everything_. Most of us (I think) just keep what we've done straight with notes, and undo it if we go down a bad path. Or you can use a Virtual Machine (I have many) and clone/hack/test/fix/destroy the VM.

Two - it seems to me that Macports GCC should have "-Wa,-q" (or its analog) on by default, because otherwise there's no usable assembler anyway. Comments?

That is what the MacPorts' devs have tried to duplicate automatically by tweaking the source code to the 'as' component of 'cctools' a few months ago. And, frankly, that is what is causing your troubles at the moment, it would appear, as you are running into some kind of issue with the tweaked-in clang assembler that (so far) nobody else has seen, for whatever reason.

comment:12 Changed 6 years ago by kencu (Ken)

Here's a thought. What variant of cctools do you have installed? I have the default, and most likely so does everyone else:

$ port -v installed cctools
The following ports are currently installed:
  cctools @921_1+xcode (active) platform='darwin 18' archs='noarch' date='2019-01-28T13:27:12-0800'

Last edited 6 years ago by kencu (Ken) (previous) (diff)

comment:13 Changed 6 years ago by kencu (Ken)

So I had no trouble building gcc9 on Mojave with Xcode 10.2.1 using the default cctools setting as above, without making any Portfile modifications.

Did you force the installation of a different cctools variant? If so, that is likely your trouble.

Not that there isn't a problem with clang-7.0 and clang-8.0 crashing while compiling gcc9 -- there certainly is, and that will need to be eventually fixed upstream in the llvm group somewhere, it would appear. But life is too short for taking on every issue every day. Follow the "road more travelled" and all that.

comment:14 Changed 6 years ago by mouse07410 (Mouse)

Here's a thought. What variant of cctools do you have installed?

Darn!! *&^&%! @#$%! @#*&! Great thought, and very correct. :-(

Did you force the installation of a different cctools variant? If so, that is likely your trouble.

Well, the default was/is [+]llvm70:

$ port info cctools
cctools @921_1 (devel)
Variants:             llvm39, llvm40, llvm50, llvm60, [+]llvm70, llvm80, llvmdev, universal, xcode

Description:          A set of essential tools to support development on Mac OS X and Darwin. Conceptually
                      similar similar to binutils on other platforms.
Homepage:             https://opensource.apple.com/source/cctools/

Build Dependencies:   libunwind-headers
Library Dependencies: llvm-7.0
Platforms:            darwin
License:              (APSL-2 or GPL-2+)
Maintainers:          Email: jeremyhu@macports.org, GitHub: jeremyhu
                      Policy: openmaintainer

After the above failure, I forced it to +llvm80 (still causing failures). And now, forcing it to +xcode (which is not the default, as far as I can see), seemed to improve a lot - at least I don't seem to need -Wa,-q, at least in general (would have to check with Crypto++).

Last edited 6 years ago by mouse07410 (Mouse) (previous) (diff)

comment:15 Changed 6 years ago by kencu (Ken)

cctools +xcode is as close as we can get to not having cctools installed at all. It defers all the toolchain to xcode. (same as ld64 +xcode).

There may be some way that is not ideal, but I can't think of what it is now.

comment:16 Changed 6 years ago by mouse07410 (Mouse)

Assuming I'm correct (I think I am), and xcode is not the default variant for cctools - would it make sense to make it default? If so, could somebody push that change please?

I'm still planning to run the experiments we talked above, but will set a MacOS VM for that first.

comment:17 Changed 6 years ago by kencu (Ken)

well it was the default at one point:

commit e0aea2323502365a86c06070c936f7dfd2b5dde0
Author: Chris Jones <jonesc@macports.org>
Date:   Tue Aug 7 21:00:23 2018 +0100

    cctools: Enforce xcode variant on Xcode 9+ systems

comment:18 Changed 6 years ago by kencu (Ken)

It was changed to +llvm70 by Jeremy on the last update he did. The tools are all the same as xcode 10's; the only real change is which clang will get called as the assembler. With the +xcode variant, you get the native Xcode toolchain. With the +llvm70 variant, you get our new as logic.

I guess I had the +xcode variant already, and it just kept on with the +xcode variant when I upgraded.

Last edited 6 years ago by kencu (Ken) (previous) (diff)

comment:19 Changed 6 years ago by mouse07410 (Mouse)

well it was the default at one point... With the +llvm70 variant, you get our new as logic... the only real change is which clang will get called as the assembler

It seems that the new ass logic fails, at least on the new systems. And the only reliably-working assembler apppears to be the one from native Xcode.

So there has to be a way to either restore +xcode as the default for the new systems, or let a user know (maybe in the output of port info cctools) - without him having to scour the trac.macports.org searching for solution - that the +llvm70 default is not going to work.

comment:20 Changed 6 years ago by kencu (Ken)

I will see if I can send the bug report about the assembler crash to someone who might fix it... if it's not already fixed in llvm-devel.

comment:21 Changed 6 years ago by mouse07410 (Mouse)

Yes, could you please do so.

P.S. You sure the Macports LLVM assembler is "good enough" to be used in place of the Xcode assembler, and this bug is the only thing that stands in its way?

comment:22 Changed 6 years ago by kencu (Ken)

Oh, sure it is. But there will always be wrinkles found, especially if you try to ride the fastest horse in the stable.

To be honest, that is part of the reason someone with Jeremy's skill set spends the time to get the newest tools out into the hands of people like us -- to find these exact sort of "out in the wild" issues before they enter the mainstream of Apple's distributed tools. Jeremy has found hundreds of bugs this way, often through our reports, just exactly like this one.

I see there was a commit to the llvm source tree that apparently came after the fork to Apple's Xcode 10 version but before llvm/clang-7.0 release that added this ASSERT. Probably gcc is generating some non-standard assembly instructions that previous clang compilers accepted but the newer, ever-more-strict compilers do not. Could even be in the optimizations of the code rather than the assembly itself. This stuff gets pretty mind-bending.

comment:23 Changed 6 years ago by mouse07410 (Mouse)

...there will always be wrinkles found...

That's fine, or at least tolerable. For example, the current Xcode 10.2+ lost the ability to authenticate to my Enterprise GitHub - how's that for a "wrinkle"? :-)

Speaking of which, Xcode-10 change wasn't as bad as Xcode-10.2. And 10.2.1 didn't seem to improve anything. :-(

...This stuff gets pretty mind-bending...

Which is why I don't think I looked at a compiler innards after circa 2005. ;-)

comment:24 Changed 6 years ago by cjones051073 (Chris Jones)

Just found my may to this ticket.... A few comments.

The cctools Xcode variant indeed was the default, for a while, as it was done to fix issues with the as from cctools being very very old and unable to handle the output from modern compilers.

Then, the maintainer updated the port, and made the llvm variants the default again, for reasons he did not care to share. Also note the maintainer works for Apple, and as such is not going to be any help with gcc as he cannot even look at code that is GPL3...

So then, later on, the logic currently in cctools was added to enhance the way it checks for the 'system' clang to work better in MacPorts case. So now it is better at finding the system compiler, and will also use the MP provided clang X.Y that the llvm X.Y corresponds to, to be used instead. However, this requires that clang X.Y to be available at build time, and as (for circular dependency reasons) cctools cannot directly depend on clang X.Y the logic in the gcc ports was added to make sure it is available, as there are in the gcc9+ builds things that cannot be built without a modern as.

Now... One thing that does confuse me here is I had no problems at all building gcc9 or 10 with Xcode 10.2.1 on macOS10.14, with cctools installed with the llvm70 (and in fact llvm80) variants active. So I am afraid I doubt this is the (only) cause of the issues seen here. There is more going on to cause the build failures reported here (also note, the binary tarballs would also not be available if the builds with the cctools llvm variants where not working)....

comment:25 follow-up: 29 Changed 6 years ago by kencu (Ken)

The llvm ports can be quite sensitive. I found some version of llvm crashing when built with one clang version, but not when built with another clang version.

comment:26 follow-up: 30 Changed 6 years ago by kencu (Ken)

Oh, and whatever is the root cause of the issue mouse saw, I just have not had the time to dig on building gcc with different clang versions to see where the break point is, or if the issue is even reproducible -- it takes so damn long to build gcc...

Last edited 6 years ago by kencu (Ken) (previous) (diff)

comment:27 in reply to: 1 Changed 6 years ago by cjones051073 (Chris Jones)

Replying to mouse07410:

Why does gcc9} port insist on building itself with Macports {{{clang-7.0?

. . . . .
:info:build Stack dump:
:info:build 0.	Program arguments: /opt/local/libexec/llvm-7.0/bin/clang -cc1as -triple x86_64-apple-macosx10.5.0 -filetype obj -main-file-name - -target-cpu core2 -I . -I . -I ../.././gcc -I /opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_lang_gcc9/gcc9/work/gcc-9.1.0/libgcc -I /opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_lang_gcc9/gcc9/work/gcc-9.1.0/libgcc/. -I /opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_lang_gcc9/gcc9/work/gcc-9.1.0/libgcc/../gcc -I /opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_lang_gcc9/gcc9/work/gcc-9.1.0/libgcc/../include -fdebug-compilation-dir /opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_lang_gcc9/gcc9/work/build/x86_64-apple-darwin18/libgcc -dwarf-debug-producer clang version 7.0.1 (tags/RELEASE_701/final) -I . -I . -I ../.././gcc -I /opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_lang_gcc9/gcc9/work/gcc-9.1.0/libgcc -I /opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_lang_gcc9/gcc9/work/gcc-9.1.0/libgcc/. -I /opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_lang_gcc9/gcc9/work/gcc-9.1.0/libgcc/../gcc -I /opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_lang_gcc9/gcc9/work/gcc-9.1.0/libgcc/../include -dwarf-version=2 -mrelocation-model pic -o cpuinfo_s.o - 
:info:build 0  libLLVM.dylib            0x000000010f618f60 llvm::sys::PrintStackTrace(llvm::raw_ostream&) + 37
:info:build 1  libLLVM.dylib            0x000000010f619351 SignalHandler(int) + 200
:info:build 2  libsystem_platform.dylib 0x00007fff60ca0b5d _sigtramp + 29
:info:build 3  libsystem_platform.dylib 0x0000000119c9d938 _sigtramp + 3103772152
:info:build 4  libsystem_c.dylib        0x00007fff60b606a6 abort + 127
:info:build 5  libsystem_c.dylib        0x00007fff60b2920d basename_r + 0
:info:build 6  libLLVM.dylib            0x00000001101f8b29 (anonymous namespace)::MCMachOStreamer::ChangeSection(llvm::MCSection*, llvm::MCExpr const*) + 793
:info:build 7  libLLVM.dylib            0x0000000110206239 llvm::MCStreamer::SwitchSection(llvm::MCSection*, llvm::MCExpr const*) + 97
:info:build 8  libLLVM.dylib            0x000000011023d45b (anonymous namespace)::DarwinAsmParser::parseSectionSwitch(llvm::StringRef, llvm::StringRef, unsigned int, unsigned int, unsigned int) + 201
:info:build 9  libLLVM.dylib            0x000000011023dc9e bool llvm::MCAsmParserExtension::HandleDirective<(anonymous namespace)::DarwinAsmParser, &((anonymous namespace)::DarwinAsmParser::parseSectionDirectiveModInitFunc(llvm::StringRef, llvm::SMLoc))>(llvm::MCAsmParserExtension*, llvm::StringRef, llvm::SMLoc) + 44
:info:build 10 libLLVM.dylib            0x0000000110226b85 (anonymous namespace)::AsmParser::parseStatement((anonymous namespace)::ParseStatementInfo&, llvm::MCAsmParserSemaCallback*) + 2127
:info:build 11 libLLVM.dylib            0x0000000110222a67 (anonymous namespace)::AsmParser::Run(bool, bool) + 395
:info:build 12 clang                    0x000000010db428d0 cc1as_main(llvm::ArrayRef<char const*>, char const*, void*) + 10156
:info:build 13 clang                    0x000000010db3db6b main + 7864
:info:build 14 libdyld.dylib            0x00007fff60abb3d5 start + 1
:info:build 15 libdyld.dylib            0x0000000000000030 start + 2673101916
:info:build clang: error: unable to execute command: Abort trap: 6
:info:build clang: error: clang integrated assembler command failed due to signal (use -v to see invocation)
:info:build clang version 7.0.1 (tags/RELEASE_701/final)
:info:build Target: x86_64-apple-darwin18.5.0
:info:build Thread model: posix
:info:build InstalledDir: /opt/local/libexec/llvm-7.0/bin
:info:build clang: note: diagnostic msg: PLEASE submit a bug report to https://bugs.llvm.org/ and include the crash backtrace, preprocessed source, and associated run script.
:info:build clang: note: diagnostic msg: Error generating preprocessed source(s) - no preprocessable inputs.
:info:build make[3]: *** [cpuinfo_s.o] Error 1

Here's my "normal" setup:

$ port select --list clang
Available versions for clang:
	apple-clang (active)
	mp-clang-6.0
	mp-clang-7.0
	mp-clang-8.0
	none
$ port select --list llvm
Available versions for llvm:
	mp-llvm-6.0
	mp-llvm-7.0
	mp-llvm-8.0
	none (active)
$

I tried installing gcc9 with setting mp-llvm-7.0 and mp-clang-7.0 as default - with the same bad result.

Having anything 'port selected' is not the default. Its not how the buildbots run, nor how I work. If I want macports clang (or gcc) I directly use the named command, like g++-mp-9, or clang++-mp-8.0

Please could you try removing any 'port select' you might have for gcc, llvm or clang (select none for them all) then try again ?

comment:28 in reply to: 8 Changed 6 years ago by cjones051073 (Chris Jones)

Replying to mouse07410:

I take the success call back: it installed GCC9, but seems unable to use it correctly:

$ cd ntl-11.3.2
$ ./configure DEF_PREFIX=/opt/local
Compilation failed
See CompilerOutput.log for details
Goodbye! at DoConfig line 616.
$ cat CompilerOutput.log
*** CompilerOutput.log ***
*** building GenConfigInfo
g++ -I../include -I.  -g -O2   -o  GenConfigInfo GenConfigInfo.cpp -lm
Assertion failed: (!CreatedADWARFSection && "Creating regular section after DWARF"), function ChangeSection, file /opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_lang_llvm-8.0/llvm-8.0/work/llvm-8.0.0.src/lib/MC/MCMachOStreamer.cpp, line 159.
Stack dump:
0.	Program arguments: /opt/local/libexec/llvm-8.0/bin/clang -cc1as -triple x86_64-apple-macosx10.14.0 -filetype obj -main-file-name cceE8CeD.s -target-cpu penryn -I ../include -I . -fdebug-compilation-dir /Users/ur20980/src/ntl-11.3.2/src -dwarf-debug-producer clang version 8.0.0 (tags/RELEASE_800/final) -I ../include -I . -dwarf-version=4 -mrelocation-model pic -o /var/folders/c6/lnc_0m093ys8w16md_fm1mnxhtfnj8/T//ccVs4mYb.o /var/folders/c6/lnc_0m093ys8w16md_fm1mnxhtfnj8/T//cceE8CeD.s 
0  libLLVM.dylib            0x000000010fbadbfb llvm::sys::PrintStackTrace(llvm::raw_ostream&) + 40
1  libLLVM.dylib            0x000000010fbadff7 SignalHandler(int) + 188
2  libsystem_platform.dylib 0x00007fff60ca0b5d _sigtramp + 29
3  libLLVM.dylib            0x0000000112ac8a2c (anonymous namespace)::NoOpLoopAnalysis::Key + 448156
4  libsystem_c.dylib        0x00007fff60b606a6 abort + 127
5  libsystem_c.dylib        0x00007fff60b2920d basename_r + 0
6  libLLVM.dylib            0x000000011083a7b8 (anonymous namespace)::MCMachOStreamer::ChangeSection(llvm::MCSection*, llvm::MCExpr const*) + 762
7  libLLVM.dylib            0x0000000110847f34 llvm::MCStreamer::SwitchSection(llvm::MCSection*, llvm::MCExpr const*) + 96
8  libLLVM.dylib            0x00000001108814d3 (anonymous namespace)::DarwinAsmParser::parseSectionSwitch(llvm::StringRef, llvm::StringRef, unsigned int, unsigned int, unsigned int) + 195
9  libLLVM.dylib            0x0000000110881d00 bool llvm::MCAsmParserExtension::HandleDirective<(anonymous namespace)::DarwinAsmParser, &((anonymous namespace)::DarwinAsmParser::parseSectionDirectiveModInitFunc(llvm::StringRef, llvm::SMLoc))>(llvm::MCAsmParserExtension*, llvm::StringRef, llvm::SMLoc) + 44
10 libLLVM.dylib            0x000000011086b90e (anonymous namespace)::AsmParser::parseStatement((anonymous namespace)::ParseStatementInfo&, llvm::MCAsmParserSemaCallback*) + 3740
11 libLLVM.dylib            0x0000000110867285 (anonymous namespace)::AsmParser::Run(bool, bool) + 389
12 clang                    0x000000010df3f518 cc1as_main(llvm::ArrayRef<char const*>, char const*, void*) + 10800
13 clang                    0x000000010df3a53d main + 7866
14 libdyld.dylib            0x00007fff60abb3d5 start + 1
clang: error: unable to execute command: Abort trap: 6
clang: error: clang integrated assembler command failed due to signal (use -v to see invocation)
clang version 8.0.0 (tags/RELEASE_800/final)
Target: x86_64-apple-darwin18.5.0
Thread model: posix
InstalledDir: /opt/local/libexec/llvm-8.0/bin
clang: note: diagnostic msg: PLEASE submit a bug report to https://bugs.llvm.org/ and include the crash backtrace, preprocessed source, and associated run script.
clang: note: diagnostic msg: Error generating preprocessed source(s) - no preprocessable inputs.
make: *** [GenConfigInfo] Error 1
$

This is particularly weird. I have built a number of things with gcc8/9 after the recent update and they all where just fine.

I have to start to suspect something 'different' in your environment or setup here that is causing this for you, but others don't see.

comment:29 in reply to: 25 Changed 6 years ago by cjones051073 (Chris Jones)

Replying to kencu:

The llvm ports can be quite sensitive. I found some version of llvm crashing when built with one clang version, but not when built with another clang version.

It looks like the issue is in fact with the llvm/clang ports, and not gcc. The recent gcc updates did not touch macports clang compilers, it simply uses them...

But why its affecting the OP here, and no one else is beyond me at this point.

comment:30 in reply to: 26 Changed 6 years ago by cjones051073 (Chris Jones)

Replying to kencu:

Oh, and whatever is the root cause of the issue mouse saw, I just have not had the time to dig on building gcc with different clang versions to see where the break point is, or if the issue is even reproducible -- it takes so damn long to build gcc...

The build bots have all built gcc9 and gcc10 fine on macOS10.7+, which are the only platforms supported by these compilers. So work fine with the cctools llvm variants these platforms use by default.

comment:31 Changed 6 years ago by kencu (Ken)

And yet mouse is clearly getting a crash in the llvm assembly routines, for some reason... it is the assembly gcc is producing (for clang to compile) that is triggering the crash.

But if I can't reproduce it, I'm not sending the ticket upstream either.

comment:32 Changed 6 years ago by cjones051073 (Chris Jones)

I am not disputing the crash is happening. Clearly it is. My point is really I suspect its something (unique) in Mouse's environment causing this, not a general issue. As such the focus should be on what Mouse has in their environment causing it.

comment:33 Changed 6 years ago by cjones051073 (Chris Jones)

Cc:	cjones051073 added

comment:34 Changed 6 years ago by kencu (Ken)

We can see the gcc output is going directly into macports-clang-7.0 or macports-clang-8.0 to assemble, so nothing is going astray in the environment there (ie there is no indication that it is a port select issue (port select is not involved here), an ld64 issue, or a cctools issue).

llvm is then crashing on the piped-in assembly.

But if nobody else can reproduce it, it is probably the specific way mouse has built llvm.

I have triaged many such random crashes in llvm -- you'd be surprised how touchy it can be.

comment:35 Changed 6 years ago by mouse07410 (Mouse)

I have no special way of building llvm. Except that I specified +assertions because I need analyzer support in clang that would use that llvm.

comment:36 Changed 6 years ago by cjones051073 (Chris Jones)

'Doctor, doctor, it hurts when I do this' 'Then don't do that!'

Seriously... You are using a non-standard variant which counts as a special build. Please just as a test try reinstalling with the standard default options and see if that fixes the errors. Even if you need the assertions, you will then know enabling them causes you the problems and you can go from there...

Last edited 6 years ago by cjones051073 (Chris Jones) (previous) (diff)

comment:37 Changed 6 years ago by cjones051073 (Chris Jones)

Port:	clang-7.0 clang-8.0 added; gcc9 removed
Summary:	gcc9 (and other gccN) fails to install on Mojave, Xcode-10.2.1 → clang-7,8.0 - seg. faults when used as assembler with assertions variant active.

comment:38 Changed 6 years ago by kencu (Ken)

I wrote this all down previously somewhere, but IIRC, if you build llvm-7 or llvm-8 with clang-3.7, it will crash. You will see no build errors, but it won't work. It's a bit touchy.

There may well be other combinations that also cause crashes that I don't know about.

It might be the assertions -- or it might be something else. Have to dig in to be sure.

Last edited 6 years ago by kencu (Ken) (previous) (diff)

comment:39 follow-up: 44 Changed 6 years ago by mouse07410 (Mouse)

'Doctor, doctor, it hurts when I do this' 'Then don't do that!'

- What are you looking for here under the lamppost?
- My keys.
- Did you lose them here?
- No, over there.
- Then why are you looking for them here?
- Because it's dark over there.

You are using a non-standard variant which counts as a special build

Since when did "non-default" become "non-standard"?

Are you testing your ports for all the variants you define/support? Or only the default one?

The build bots have all built gcc9 and gcc10 fine on macOS10.7+

MacOS 10.7? Are you validating under 10.14.x using Xcode-10.2.x? If not, I'd say that explains why you aren't catching this crash. Xcode-10.2 is quite different in what it allows and what it fails than the previous versions, at least in my experience.

Also, as I'm working with crypto code that tries to squeeze an extra bit of performance by utilizing inline assembly (I'm one of the maintainers of Crypto++ https://en.wikipedia.org/wiki/Crypto%2B%2B library), I'm trying to make sure it compiles with all the compilers available on MacOS. I noticed that the only way to get Macports GCC to compile code with inline assembly is to make it invoke Xcode assembler via -Wa,-q. We're also using export AS_INTEGRATED_ASSEMBLER=1. I'd just stick with Xcode, but it's GCC sucks even more, and it's very outdated besides. So, for a decent GCC have to use Macports port.

Here's my setup:

$ port installed llvm-8.0 clang-8.0 cctools ld64 gcc libgcc libgcc9 libgcc8
The following ports are currently installed:
  cctools @921_1+xcode (active)
  ld64 @3_1+ld64_xcode (active)
  clang-8.0 @8.0.0_0+analyzer+assertions+libstdcxx (active)
  libgcc @2.0_1 (active)
  libgcc8 @8.3.0_5 (active)
  libgcc9 @9.1.0_1 (active)
  llvm-8.0 @8.0.0_0+assertions+polly (active)
$ port select --list gcc
Available versions for gcc:
	mp-gcc8
	mp-gcc9 (active)
	none
$ port select --list clang
Available versions for clang:
	apple-clang (active)
	mp-clang-8.0
	none
$ port select --list llvm
Available versions for llvm:
	mp-llvm-6.0
	mp-llvm-8.0
	none (active)
$ $ cat /opt/local/etc/select/clang/apple-clang 
-
/usr/bin/clang++
/usr/bin/clang
-
. . . . . [30 more lines "-"] . . . . .

Last edited 6 years ago by mouse07410 (Mouse) (previous) (diff)

comment:40 Changed 6 years ago by kencu (Ken)

OK, so the crash is reproducible. Steps to reproduce:

install llvm-devel (comes with assertions on)
install cctools +llvmdev
select clang-devel using sudo port select clang clang-devel
try to build gcc9 sudo port -v destroot gcc9 configure.compiler=macports-clang

and you get mouse's exact error, more or less, in clang trunk:

Assertion failed: (!CreatedADWARFSection && "Creating regular section after DWARF"), function ChangeSection, file /opt/local/var/macports/build/_opt_bblocal_var_buildworker_ports_build_ports_lang_llvm-devel/llvm-devel/work/trunk/lib/MC/MCMachOStreamer.cpp, line 158.
Stack dump:
0.	Program arguments: /opt/local/libexec/llvm-devel/bin/clang -cc1as -triple x86_64-apple-macosx10.5.0 -filetype obj -main-file-name - -target-cpu core2 -I . -I . -I ../.././gcc -I /opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_tarballs_ports_lang_gcc9/gcc9/work/gcc-9.1.0/libgcc -I /opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_tarballs_ports_lang_gcc9/gcc9/work/gcc-9.1.0/libgcc/. -I /opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_tarballs_ports_lang_gcc9/gcc9/work/gcc-9.1.0/libgcc/../gcc -I /opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_tarballs_ports_lang_gcc9/gcc9/work/gcc-9.1.0/libgcc/../include -fdebug-compilation-dir /opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_tarballs_ports_lang_gcc9/gcc9/work/build/x86_64-apple-darwin18/libgcc -dwarf-debug-producer clang version 9.0.0 (trunk 357237) -I . -I . -I ../.././gcc -I /opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_tarballs_ports_lang_gcc9/gcc9/work/gcc-9.1.0/libgcc -I /opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_tarballs_ports_lang_gcc9/gcc9/work/gcc-9.1.0/libgcc/. -I /opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_tarballs_ports_lang_gcc9/gcc9/work/gcc-9.1.0/libgcc/../gcc -I /opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_tarballs_ports_lang_gcc9/gcc9/work/gcc-9.1.0/libgcc/../include -dwarf-version=2 -mrelocation-model pic -o cpuinfo_s.o - 
/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_tarballs_ports_lang_gcc9/gcc9/work/build/./gcc/xgcc -B/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_tarballs_ports_lang_gcc9/gcc9/work/build/./gcc/ -B/opt/local/x86_64-apple-darwin18/bin/ -B/opt/local/x86_64-apple-darwin18/lib/ -isystem /opt/local/x86_64-apple-darwin18/include -isystem /opt/local/x86_64-apple-darwin18/sys-include   -fno-checking -g -O2 -pipe -Os -isysroot/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.14.sdk -O2 -g -O2 -pipe -Os -isysroot/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.14.sdk -DIN_GCC    -W -Wall -Wno-narrowing -Wwrite-strings -Wcast-qual -Wno-format -Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition  -isystem ./include  -I. -I. -I../.././gcc -I/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_tarballs_ports_lang_gcc9/gcc9/work/gcc-9.1.0/libgcc -I/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_tarballs_ports_lang_gcc9/gcc9/work/gcc-9.1.0/libgcc/. -I/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_tarballs_ports_lang_gcc9/gcc9/work/gcc-9.1.0/libgcc/../gcc -I/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_tarballs_ports_lang_gcc9/gcc9/work/gcc-9.1.0/libgcc/../include   -g0  -finhibit-size-directive -fno-inline -fno-exceptions -fno-zero-initialized-in-bss -fno-toplevel-reorder -fno-tree-vectorize -fbuilding-libgcc -fno-stack-protector   -I. -I. -I../.././gcc -I/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_tarballs_ports_lang_gcc9/gcc9/work/gcc-9.1.0/libgcc -I/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_tarballs_ports_lang_gcc9/gcc9/work/gcc-9.1.0/libgcc/. -I/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_tarballs_ports_lang_gcc9/gcc9/work/gcc-9.1.0/libgcc/../gcc -I/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_tarballs_ports_lang_gcc9/gcc9/work/gcc-9.1.0/libgcc/../include  -o crttme.o -MT crttme.o -MD -MP -MF crttme.dep  -DEND -c /opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_tarballs_ports_lang_gcc9/gcc9/work/gcc-9.1.0/libgcc/config/darwin-crt-tm.c
0  libLLVM.dylib            0x0000000106126ed8 llvm::sys::PrintStackTrace(llvm::raw_ostream&) + 37
1  libLLVM.dylib            0x00000001061272c9 SignalHandler(int) + 200
2  libsystem_platform.dylib 0x00007fff79f5bb5d _sigtramp + 29
3  libsystem_platform.dylib 0x0000000105ff0938 _sigtramp + 2349420024
4  libsystem_c.dylib        0x00007fff79e1b6a6 abort + 127
5  libsystem_c.dylib        0x00007fff79de420d basename_r + 0
6  libLLVM.dylib            0x0000000106ddfa57 (anonymous namespace)::MCMachOStreamer::ChangeSection(llvm::MCSection*, llvm::MCExpr const*) + 793
7  libLLVM.dylib            0x0000000106ded7d9 llvm::MCStreamer::SwitchSection(llvm::MCSection*, llvm::MCExpr const*) + 97
8  libLLVM.dylib            0x0000000106e28b1d (anonymous namespace)::DarwinAsmParser::parseSectionSwitch(llvm::StringRef, llvm::StringRef, unsigned int, unsigned int, unsigned int) + 201
9  libLLVM.dylib            0x0000000106e292f4 bool llvm::MCAsmParserExtension::HandleDirective<(anonymous namespace)::DarwinAsmParser, &((anonymous namespace)::DarwinAsmParser::parseSectionDirectiveModInitFunc(llvm::StringRef, llvm::SMLoc))>(llvm::MCAsmParserExtension*, llvm::StringRef, llvm::SMLoc) + 44
10 libLLVM.dylib            0x0000000106e11fe1 (anonymous namespace)::AsmParser::parseStatement((anonymous namespace)::ParseStatementInfo&, llvm::MCAsmParserSemaCallback*) + 3833
11 libLLVM.dylib            0x0000000106e0d877 (anonymous namespace)::AsmParser::Run(bool, bool) + 389
12 clang                    0x0000000101b25bc6 cc1as_main(llvm::ArrayRef<char const*>, char const*, void*) + 10730
13 clang                    0x0000000101b20df0 main + 7865
14 libdyld.dylib            0x00007fff79d763d5 start + 1
15 libdyld.dylib            0x0000000000000030 start + 2250808412
clang: error: unable to execute command: Abort trap: 6
clang: error: clang integrated assembler command failed due to signal (use -v to see invocation)
clang version 9.0.0 (trunk 357237)
Target: x86_64-apple-darwin18.5.0
Thread model: posix
InstalledDir: /opt/local/libexec/llvm-devel/bin
clang: note: diagnostic msg: PLEASE submit a bug report to https://bugs.llvm.org/ and include the crash backtrace, preprocessed source, and associated run script.
clang: note: diagnostic msg: Error generating preprocessed source(s) - no preprocessable inputs.
make[3]: *** [cpuinfo_s.o] Error 1

so that's at least satisfying.

Last edited 6 years ago by kencu (Ken) (previous) (diff)

comment:41 follow-up: 45 Changed 6 years ago by mouse07410 (Mouse)

OK, so the crash is reproducible

Thanks!

so that's at least satisfying

Hopefully it can now be reported upstream, and maybe fixed.

comment:42 Changed 6 years ago by kencu (Ken)

doing the same thing, but using llvm&clang-8.0, which is built with assertions OFF, I get no crash:

/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_tarballs_ports_lang_gcc9/gcc9/work/build/./gcc/xgcc -B/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_tarballs_ports_lang_gcc9/gcc9/work/build/./gcc/ -B/opt/local/x86_64-apple-darwin18/bin/ -B/opt/local/x86_64-apple-darwin18/lib/ -isystem /opt/local/x86_64-apple-darwin18/include -isystem /opt/local/x86_64-apple-darwin18/sys-include   -fno-checking -g -O2 -pipe -Os -isysroot/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.14.sdk -O2  -g -O2 -pipe -Os -isysroot/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.14.sdk -DIN_GCC    -W -Wall -Wno-narrowing -Wwrite-strings -Wcast-qual -Wno-format -Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition  -isystem ./include   -mmacosx-version-min=10.5 -pipe -fno-common -g -DIN_LIBGCC2 -fbuilding-libgcc -fno-stack-protector   -mmacosx-version-min=10.5 -pipe -fno-common -I. -I. -I../.././gcc -I/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_tarballs_ports_lang_gcc9/gcc9/work/gcc-9.1.0/libgcc -I/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_tarballs_ports_lang_gcc9/gcc9/work/gcc-9.1.0/libgcc/. -I/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_tarballs_ports_lang_gcc9/gcc9/work/gcc-9.1.0/libgcc/../gcc -I/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_tarballs_ports_lang_gcc9/gcc9/work/gcc-9.1.0/libgcc/../include    -o cpuinfo_s.o -MT cpuinfo_s.o -MD -MP -MF cpuinfo_s.dep -DSHARED  -c /opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_tarballs_ports_lang_gcc9/gcc9/work/gcc-9.1.0/libgcc/config/i386/cpuinfo.c

and gcc9 is continuing to build away. So it looks like Chris pegged it to me -- it crashes with the assertions turned on, it seems.

comment:43 Changed 6 years ago by mouse07410 (Mouse)

it crashes with the assertions turned on, it seems

Yeah...

I'm getting confused now. I'm trying to recall why I enabled assertions, and I can't remember now! I think it was to support analyzer (which seems to be on by default). And in order to have assertions enabled in Clang, they have to be enabled in LLVM, right?

Regardless, this assertions-related crash should be fixed - but now I'm questioning why I got them enabled in the first place... Any suggestions? (and before you start - no, I'm not in the habit of turning on every available variant to see what might happen ;)

P.S. From https://blog.regehr.org/archives/1091:

Compilers such as GCC and LLVM ship with assertions enabled, making the compiler more 
likely to die and less likely to emit incorrect object code

Last edited 6 years ago by mouse07410 (Mouse) (previous) (diff)

comment:44 in reply to: 39 Changed 6 years ago by cjones051073 (Chris Jones)

You are using a non-standard variant which counts as a special build

Since when did "non-default" become "non-standard"?

To my thinking, they have always been the same thing.

Are you testing your ports for all the variants you define/support? Or only the default one?

The non-default variants are generally not as well tested as the default ones. In the case of the clang ports I cannot comment on if the maintainer tried any of them or not. Its really up to port maintainers to decide how well, or not, they test non-default variants. They aren't tested in any form as part of either the automatic builds in PRs, or by the buildbots.

The build bots have all built gcc9 and gcc10 fine on macOS10.7+

MacOS 10.7? Are you validating under 10.14.x using Xcode-10.2.x? If not, I'd say that explains why you aren't catching this crash. Xcode-10.2 is quite different in what it allows and what it fails than the previous versions, at least in my experience.

That is not what I said. I said the *buildbots* have successfully built gcc9 on *all* platforms from 10.7 upwards. That means all the way to 10.14. And just for the record, my primary machines here are 10.14 and 10.13 Xcode 10.2, and I have VMs going back to 10.6. When I submitted the recent gcc9 update I did test it across the board first.

Also, as I'm working with crypto code that tries to squeeze an extra bit of performance by utilizing inline assembly (I'm one of the maintainers of Crypto++ https://en.wikipedia.org/wiki/Crypto%2B%2B library), I'm trying to make sure it compiles with all the compilers available on MacOS. I noticed that the only way to get Macports GCC to compile code with inline assembly is to make it invoke Xcode assembler via -Wa,-q. We're also using export AS_INTEGRATED_ASSEMBLER=1. I'd just stick with Xcode, but it's GCC sucks even more, and it's very outdated besides. So, for a decent GCC have to use Macports port.

macOS does not have have gcc any more, in any form. Hasn't for years. Yes, it has a command that is called g++, but it aint GNU GCC. Its just a wrapper around clang.

Titan ~/Projects/MacPorts/ports > which g++
/usr/bin/g++
Titan ~/Projects/MacPorts/ports > g++ --version
Configured with: --prefix=/Applications/Xcode.app/Contents/Developer/usr --with-gxx-include-dir=/usr/include/c++/4.2.1
Apple LLVM version 10.0.0 (clang-1000.11.45.5)
Target: x86_64-apple-darwin17.7.0
Thread model: posix
InstalledDir: /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin

If you need GNU GCC, there is no option but to use an external source, like MacPorts.

Last edited 6 years ago by cjones051073 (Chris Jones) (previous) (diff)

comment:45 in reply to: 41 Changed 6 years ago by cjones051073 (Chris Jones)

Replying to mouse07410:

OK, so the crash is reproducible

Thanks!

so that's at least satisfying

Hopefully it can now be reported upstream, and maybe fixed.

Note though, its not just an issue with llvm trunk. Its clearly present going back to 7.0 as you see it there as well.

This suggests to me a number of possibilities.

Its uncommon, and no one has seen it before to report it. Seems unlikely, given as you get it building gcc.
Its already been seen and bug reports exist for it, but nothing has been done. Someone should check llvm's bug system.
Its specific to the way MacPorts builds clang.

Last edited 6 years ago by cjones051073 (Chris Jones) (previous) (diff)

comment:46 Changed 6 years ago by mouse07410 (Mouse)

Note though, its not just an issue with llvm trunk. Its clearly present going back to 7.0 as you see it there as well

Yes, I concur.

Its uncommon, and no one has seen it before to report it. Seems unlikely, given as you get it building gcc

Well, I personally doubt many people would build gcc with llvm, because all these compilers are somewhat alternative to each other. For example, I prefer to stay with Xcode clang, but for some cases need gcc - which I prefer to build with the Xcode clang.

Its already been seen and bug reports exist for it, but nothing has been done. Someone should check llvm's bug system

Possible... @kencu, would you be able to check with their bug system, and if this bug isn't there already - post a bug report there? I think you're the closest to them among us (I could be wrong here).

Its specific to the way MacPorts builds clang

To verify this, somebody would have to build LLVM from scratch (not via Macports), build Clang from scratch (pairing it to the above LLVM), and try to build GCC from scratch... Somewhat tough call...

My bet is on (1), possibly (2).

comment:47 Changed 6 years ago by kencu (Ken)

It's an assertion failure, introduced fairly recently into the llvm tree. The error is gcc's, more than likely, for trying to build assembly that is no longer considered valid by llvm. There is no bug about it in llvm at present that I can find, and if / when I do post it there, they will very likely say the bug is gcc's to fix anyway.

EVERYBODY on macOS builds gcc with clang/llvm, but almost NOBODY has assertions turned on, so nobody will see this without trying really hard to see it.

The issue really is to try to get a clean example of the exact assembly source file that causes the error, because it goes through a lot of gcc shenanigans -- it's not just a source file in their tree, I think. But I have it building away, and I'll see if I can get it clean enough to send up to somebody.

comment:48 Changed 6 years ago by cjones051073 (Chris Jones)

From earlier in this thread it looked like mouse had a potential reproducer from building ntl ? Maybe that would be simplier to use than gcc itself ?

Last edited 6 years ago by cjones051073 (Chris Jones) (previous) (diff)

comment:49 Changed 6 years ago by mouse07410 (Mouse)

...mouse had a potential reproducer from building ntl ?

Oh yes.

Make sure your Mac is set for using Macports GCC (say, gcc9 - but it happened with gcc8 as well): sudo port select --set gcc mp-gcc9 && sudo port select --set llvm mp-llvm-7.0 (or set llvm to mp-llvm-8.0, whatever)
Download and unpack the current (11.3.2) NTL distro ntl-11.3.2.tar.gz into the current dir.
cd ntl-11.3.2/src
./configure

This should be enough - it should abort with something like

$ ./configure
Compilation failed
See CompilerOutput.log for details
Goodbye! at DoConfig line 616.
$ cat CompilerOutput.log
*** CompilerOutput.log ***
*** building GenConfigInfo
g++ -I../include -I.  -g -O2   -o  GenConfigInfo GenConfigInfo.cpp -lm
Assertion failed: (!CreatedADWARFSection && "Creating regular section after DWARF"), function ChangeSection, file /opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_tarballs_ports_lang_llvm-7.0/llvm-7.0/work/llvm-7.0.1.src/lib/MC/MCMachOStreamer.cpp, line 159.
Stack dump:
0.	Program arguments: /opt/local/libexec/llvm-7.0/bin/clang -cc1as -triple x86_64-apple-macosx10.14.0 -filetype obj -main-file-name ccM0RN41.s -target-cpu penryn -I ../include -I . -fdebug-compilation-dir /Users/ur20980/src/ntl-11.3.2/src -dwarf-debug-producer clang version 7.0.1 (tags/RELEASE_701/final) -I ../include -I . -dwarf-version=4 -mrelocation-model pic -o /var/folders/c6/lnc_0m093ys8w16md_fm1mnxhtfnj8/T//ccqJ94NA.o /var/folders/c6/lnc_0m093ys8w16md_fm1mnxhtfnj8/T//ccM0RN41.s 
0  libLLVM.dylib            0x0000000105d038b0 llvm::sys::PrintStackTrace(llvm::raw_ostream&) + 37
1  libLLVM.dylib            0x0000000105d03ca1 SignalHandler(int) + 200
2  libsystem_platform.dylib 0x00007fff7fad1b5d _sigtramp + 29
3  libLLVM.dylib            0x00000001088ffa90 (anonymous namespace)::NoOpLoopAnalysis::Key + 405584
4  libsystem_c.dylib        0x00007fff7f9916a6 abort + 127
5  libsystem_c.dylib        0x00007fff7f95a20d basename_r + 0
6  libLLVM.dylib            0x00000001068e3479 (anonymous namespace)::MCMachOStreamer::ChangeSection(llvm::MCSection*, llvm::MCExpr const*) + 793
7  libLLVM.dylib            0x00000001068f0b89 llvm::MCStreamer::SwitchSection(llvm::MCSection*, llvm::MCExpr const*) + 97
8  libLLVM.dylib            0x0000000106927dab (anonymous namespace)::DarwinAsmParser::parseSectionSwitch(llvm::StringRef, llvm::StringRef, unsigned int, unsigned int, unsigned int) + 201
9  libLLVM.dylib            0x00000001069285ee bool llvm::MCAsmParserExtension::HandleDirective<(anonymous namespace)::DarwinAsmParser, &((anonymous namespace)::DarwinAsmParser::parseSectionDirectiveModInitFunc(llvm::StringRef, llvm::SMLoc))>(llvm::MCAsmParserExtension*, llvm::StringRef, llvm::SMLoc) + 44
10 libLLVM.dylib            0x00000001069114d5 (anonymous namespace)::AsmParser::parseStatement((anonymous namespace)::ParseStatementInfo&, llvm::MCAsmParserSemaCallback*) + 2127
11 libLLVM.dylib            0x000000010690d3b7 (anonymous namespace)::AsmParser::Run(bool, bool) + 395
12 clang                    0x000000010422efe0 cc1as_main(llvm::ArrayRef<char const*>, char const*, void*) + 10156
13 clang                    0x000000010422a27b main + 7864
14 libdyld.dylib            0x00007fff7f8ec3d5 start + 1
15 libdyld.dylib            0x000000000000001c start + 2154904648
clang: error: unable to execute command: Abort trap: 6
clang: error: clang integrated assembler command failed due to signal (use -v to see invocation)
clang version 7.0.1 (tags/RELEASE_701/final)
Target: x86_64-apple-darwin18.5.0
Thread model: posix
InstalledDir: /opt/local/libexec/llvm-7.0/bin
clang: note: diagnostic msg: PLEASE submit a bug report to https://bugs.llvm.org/ and include the crash backtrace, preprocessed source, and associated run script.
clang: note: diagnostic msg: Error generating preprocessed source(s) - no preprocessable inputs.
make: *** [GenConfigInfo] Error 1
$

comment:50 Changed 6 years ago by mouse07410 (Mouse)

Oh, I figure you want a simple reproducer?

How about this:

Set LLVM to one of the Macports LLVMs (e.g., sudo port select --set llvm mp-llvm-8.0)
Do g++ -g -o GenConfigInfo GenConfigInfo.cpp
Observe/enjoy the following output:

$ port select --list llvm
Available versions for llvm:
	mp-llvm-6.0
	mp-llvm-7.0
	mp-llvm-8.0 (active)
	none
$ port select --list gcc
Available versions for gcc:
	mp-gcc8
	mp-gcc9 (active)
	none
$ g++ -g -o GenConfigInfo GenConfigInfo.cpp
Assertion failed: (!CreatedADWARFSection && "Creating regular section after DWARF"), function ChangeSection, file /opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_tarballs_ports_lang_llvm-7.0/llvm-7.0/work/llvm-7.0.1.src/lib/MC/MCMachOStreamer.cpp, line 159.
Stack dump:
0.	Program arguments: /opt/local/libexec/llvm-7.0/bin/clang -cc1as -triple x86_64-apple-macosx10.14.0 -filetype obj -main-file-name cc8IygJS.s -target-cpu penryn -fdebug-compilation-dir /Users/ur20980/src/ntl-11.3.2/src -dwarf-debug-producer clang version 7.0.1 (tags/RELEASE_701/final) -dwarf-version=4 -mrelocation-model pic -o /var/folders/c6/lnc_0m093ys8w16md_fm1mnxhtfnj8/T//ccLrUU5b.o /var/folders/c6/lnc_0m093ys8w16md_fm1mnxhtfnj8/T//cc8IygJS.s 
0  libLLVM.dylib            0x000000010d3f78b0 llvm::sys::PrintStackTrace(llvm::raw_ostream&) + 37
1  libLLVM.dylib            0x000000010d3f7ca1 SignalHandler(int) + 200
2  libsystem_platform.dylib 0x00007fff7fad1b5d _sigtramp + 29
3  libsystem_platform.dylib 0x0000000119821938 _sigtramp + 2580872696
4  libsystem_c.dylib        0x00007fff7f9916a6 abort + 127
5  libsystem_c.dylib        0x00007fff7f95a20d basename_r + 0
6  libLLVM.dylib            0x000000010dfd7479 (anonymous namespace)::MCMachOStreamer::ChangeSection(llvm::MCSection*, llvm::MCExpr const*) + 793
7  libLLVM.dylib            0x000000010dfe4b89 llvm::MCStreamer::SwitchSection(llvm::MCSection*, llvm::MCExpr const*) + 97
8  libLLVM.dylib            0x000000010e01bdab (anonymous namespace)::DarwinAsmParser::parseSectionSwitch(llvm::StringRef, llvm::StringRef, unsigned int, unsigned int, unsigned int) + 201
9  libLLVM.dylib            0x000000010e01c5ee bool llvm::MCAsmParserExtension::HandleDirective<(anonymous namespace)::DarwinAsmParser, &((anonymous namespace)::DarwinAsmParser::parseSectionDirectiveModInitFunc(llvm::StringRef, llvm::SMLoc))>(llvm::MCAsmParserExtension*, llvm::StringRef, llvm::SMLoc) + 44
10 libLLVM.dylib            0x000000010e0054d5 (anonymous namespace)::AsmParser::parseStatement((anonymous namespace)::ParseStatementInfo&, llvm::MCAsmParserSemaCallback*) + 2127
11 libLLVM.dylib            0x000000010e0013b7 (anonymous namespace)::AsmParser::Run(bool, bool) + 395
12 clang                    0x000000010b925fe0 cc1as_main(llvm::ArrayRef<char const*>, char const*, void*) + 10156
13 clang                    0x000000010b92127b main + 7864
14 libdyld.dylib            0x00007fff7f8ec3d5 start + 1
clang: error: unable to execute command: Abort trap: 6
clang: error: clang integrated assembler command failed due to signal (use -v to see invocation)
clang version 7.0.1 (tags/RELEASE_701/final)
Target: x86_64-apple-darwin18.5.0
Thread model: posix
InstalledDir: /opt/local/libexec/llvm-7.0/bin
clang: note: diagnostic msg: PLEASE submit a bug report to https://bugs.llvm.org/ and include the crash backtrace, preprocessed source, and associated run script.
clang: note: diagnostic msg: Error generating preprocessed source(s) - no preprocessable inputs.
$

Here's the source of the reproducer:

#include <iostream>

/* output (compiler_name,language_standard,cpu_type)

   compiler_name:
   Right now, we just recognize "gcc", "clang", and "icc".
   Other compilers are named "unknown".

   language_standard:
   As of 2018, the available language standards are
   199711, 201103, 201402, 201703.

   cpu_type:
   Right now, we just recognize x86 and x86-64, and both are named "x86".
   Other CPUs are named "unknown".

*/

#ifndef __cplusplus
#define __cplusplus 1
#endif


int main()
{
   long language_standard = __cplusplus;
   // convert to one of 0, 1997, 2011, 2014, 2017
   if      (language_standard >= 201703) language_standard = 2017;
   else if (language_standard >= 201402) language_standard = 2014;
   else if (language_standard >= 201103) language_standard = 2011;
   else if (language_standard >= 199711) language_standard = 1997;
   else                                  language_standard = 0;

   const char *compiler_name = "unknown";

   const char *cpu_type = "unknown";

#if defined(__INTEL_COMPILER)
   compiler_name = "icc";
#elif defined(__clang__)
   compiler_name = "clang";
#elif defined (__GNUC__)
   compiler_name = "gcc";
#else
   compiler_name = "";
#endif

#if defined(__x86_64__) || defined(__x86_64) || defined(__i386__) || defined(__i386)
   cpu_type = "x86";
#endif

   std::cout << "(" << compiler_name << "," << language_standard 
             << "," << cpu_type << ")\n";

}

If you find this reproducer too complex - try the following (same setup as above):

$ cat t.cpp
int main() {
   return 0;
}
$ g++ -v
Using built-in specs.
COLLECT_GCC=g++
COLLECT_LTO_WRAPPER=/opt/local/libexec/gcc/x86_64-apple-darwin18/9.1.0/lto-wrapper
Target: x86_64-apple-darwin18
Configured with: /opt/local/var/macports/build/_opt_bblocal_var_buildworker_ports_build_ports_lang_gcc9/gcc9/work/gcc-9.1.0/configure --prefix=/opt/local --build=x86_64-apple-darwin18 --enable-languages=c,c++,objc,obj-c++,lto,fortran --libdir=/opt/local/lib/gcc9 --includedir=/opt/local/include/gcc9 --infodir=/opt/local/share/info --mandir=/opt/local/share/man --datarootdir=/opt/local/share/gcc-9 --with-local-prefix=/opt/local --with-system-zlib --disable-nls --program-suffix=-mp-9 --with-gxx-include-dir=/opt/local/include/gcc9/c++/ --with-gmp=/opt/local --with-mpfr=/opt/local --with-mpc=/opt/local --with-isl=/opt/local --enable-stage1-checking --disable-multilib --enable-lto --enable-libstdcxx-time --with-build-config=bootstrap-debug --with-as=/opt/local/bin/as --with-ld=/opt/local/bin/ld --with-ar=/opt/local/bin/ar --with-bugurl=https://trac.macports.org/newticket --disable-tls --with-pkgversion='MacPorts gcc9 9.1.0_1' --with-sysroot=/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.14.sdk
Thread model: posix
gcc version 9.1.0 (MacPorts gcc9 9.1.0_1) 
$ g++ -g -o t t.cpp
Assertion failed: (!CreatedADWARFSection && "Creating regular section after DWARF"), function ChangeSection, file /opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_tarballs_ports_lang_llvm-7.0/llvm-7.0/work/llvm-7.0.1.src/lib/MC/MCMachOStreamer.cpp, line 159.
Stack dump:
0.	Program arguments: /opt/local/libexec/llvm-7.0/bin/clang -cc1as -triple x86_64-apple-macosx10.14.0 -filetype obj -main-file-name ccPuEY3t.s -target-cpu penryn -fdebug-compilation-dir /Users/ur20980/src/ntl-11.3.2/src -dwarf-debug-producer clang version 7.0.1 (tags/RELEASE_701/final) -dwarf-version=4 -mrelocation-model pic -o /var/folders/c6/lnc_0m093ys8w16md_fm1mnxhtfnj8/T//ccOxbizy.o /var/folders/c6/lnc_0m093ys8w16md_fm1mnxhtfnj8/T//ccPuEY3t.s 
0  libLLVM.dylib            0x00000001151ae8b0 llvm::sys::PrintStackTrace(llvm::raw_ostream&) + 37
1  libLLVM.dylib            0x00000001151aeca1 SignalHandler(int) + 200
2  libsystem_platform.dylib 0x00007fff7fad1b5d _sigtramp + 29
3  libsystem_platform.dylib 0x0000000000003be0 _sigtramp + 2152931488
4  libsystem_c.dylib        0x00007fff7f9916a6 abort + 127
5  libsystem_c.dylib        0x00007fff7f95a20d basename_r + 0
6  libLLVM.dylib            0x0000000115d8e479 (anonymous namespace)::MCMachOStreamer::ChangeSection(llvm::MCSection*, llvm::MCExpr const*) + 793
7  libLLVM.dylib            0x0000000115d9bb89 llvm::MCStreamer::SwitchSection(llvm::MCSection*, llvm::MCExpr const*) + 97
8  libLLVM.dylib            0x0000000115dd2dab (anonymous namespace)::DarwinAsmParser::parseSectionSwitch(llvm::StringRef, llvm::StringRef, unsigned int, unsigned int, unsigned int) + 201
9  libLLVM.dylib            0x0000000115dd2ebe bool llvm::MCAsmParserExtension::HandleDirective<(anonymous namespace)::DarwinAsmParser, &((anonymous namespace)::DarwinAsmParser::parseSectionDirectiveConstructor(llvm::StringRef, llvm::SMLoc))>(llvm::MCAsmParserExtension*, llvm::StringRef, llvm::SMLoc) + 44
10 libLLVM.dylib            0x0000000115dbc4d5 (anonymous namespace)::AsmParser::parseStatement((anonymous namespace)::ParseStatementInfo&, llvm::MCAsmParserSemaCallback*) + 2127
11 libLLVM.dylib            0x0000000115db83b7 (anonymous namespace)::AsmParser::Run(bool, bool) + 395
12 clang                    0x000000010ffccfe0 cc1as_main(llvm::ArrayRef<char const*>, char const*, void*) + 10156
13 clang                    0x000000010ffc827b main + 7864
14 libdyld.dylib            0x00007fff7f8ec3d5 start + 1
clang: error: unable to execute command: Abort trap: 6
clang: error: clang integrated assembler command failed due to signal (use -v to see invocation)
clang version 7.0.1 (tags/RELEASE_701/final)
Target: x86_64-apple-darwin18.5.0
Thread model: posix
InstalledDir: /opt/local/libexec/llvm-7.0/bin
clang: note: diagnostic msg: PLEASE submit a bug report to https://bugs.llvm.org/ and include the crash backtrace, preprocessed source, and associated run script.
clang: note: diagnostic msg: Error generating preprocessed source(s) - no preprocessable inputs.
$ g++ -o t t.cpp
$ ./t
$

In short, -g seems to be the trigger. And no matter what you set LLVM to, it will use Macports LLVM-7.0 because Macports GCC9 depends on Macports Clang-7.0 that uses Macports LLVM-7.0.

Important detail: This only happens with cctools +llvm70 or cctools +llvm80:

$ g++ -g -o t t.cpp
Assertion failed: (!CreatedADWARFSection && "Creating regular section after DWARF"), function ChangeSection, file /opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_tarballs_ports_lang_llvm-8.0/llvm-8.0/work/llvm-8.0.0.src/lib/MC/MCMachOStreamer.cpp, line 159.
Stack dump:
0.	Program arguments: /opt/local/libexec/llvm-8.0/bin/clang -cc1as -triple x86_64-apple-macosx10.14.0 -filetype obj -main-file-name cc80Nniq.s -target-cpu penryn -fdebug-compilation-dir /Users/ur20980/src/ntl-11.3.2/src -dwarf-debug-producer clang version 8.0.0 (tags/RELEASE_800/final) -dwarf-version=4 -mrelocation-model pic -o /var/folders/c6/lnc_0m093ys8w16md_fm1mnxhtfnj8/T//ccvjQTJF.o /var/folders/c6/lnc_0m093ys8w16md_fm1mnxhtfnj8/T//cc80Nniq.s 
0  libLLVM.dylib            0x000000010b6608eb llvm::sys::PrintStackTrace(llvm::raw_ostream&) + 40
1  libLLVM.dylib            0x000000010b660ce7 SignalHandler(int) + 188
2  libsystem_platform.dylib 0x00007fff7fad1b5d _sigtramp + 29
3  libsystem_platform.dylib 000000000000000000 _sigtramp + 2152916160
4  libsystem_c.dylib        0x00007fff7f9916a6 abort + 127
5  libsystem_c.dylib        0x00007fff7f95a20d basename_r + 0
6  libLLVM.dylib            0x000000010c2ed4a8 (anonymous namespace)::MCMachOStreamer::ChangeSection(llvm::MCSection*, llvm::MCExpr const*) + 762
7  libLLVM.dylib            0x000000010c2fac24 llvm::MCStreamer::SwitchSection(llvm::MCSection*, llvm::MCExpr const*) + 96
8  libLLVM.dylib            0x000000010c3341c3 (anonymous namespace)::DarwinAsmParser::parseSectionSwitch(llvm::StringRef, llvm::StringRef, unsigned int, unsigned int, unsigned int) + 195
9  libLLVM.dylib            0x000000010c3342d6 bool llvm::MCAsmParserExtension::HandleDirective<(anonymous namespace)::DarwinAsmParser, &((anonymous namespace)::DarwinAsmParser::parseSectionDirectiveConstructor(llvm::StringRef, llvm::SMLoc))>(llvm::MCAsmParserExtension*, llvm::StringRef, llvm::SMLoc) + 44
10 libLLVM.dylib            0x000000010c31e5fe (anonymous namespace)::AsmParser::parseStatement((anonymous namespace)::ParseStatementInfo&, llvm::MCAsmParserSemaCallback*) + 3740
11 libLLVM.dylib            0x000000010c319f75 (anonymous namespace)::AsmParser::Run(bool, bool) + 389
12 clang                    0x00000001099f9cc8 cc1as_main(llvm::ArrayRef<char const*>, char const*, void*) + 10800
13 clang                    0x00000001099f4ced main + 7866
14 libdyld.dylib            0x00007fff7f8ec3d5 start + 1
15 libdyld.dylib            0x0000000000000014 start + 2154904640
clang: error: unable to execute command: Abort trap: 6
clang: error: clang integrated assembler command failed due to signal (use -v to see invocation)
clang version 8.0.0 (tags/RELEASE_800/final)
Target: x86_64-apple-darwin18.5.0
Thread model: posix
InstalledDir: /opt/local/libexec/llvm-8.0/bin
clang: note: diagnostic msg: PLEASE submit a bug report to https://bugs.llvm.org/ and include the crash backtrace, preprocessed source, and associated run script.
clang: note: diagnostic msg: Error generating preprocessed source(s) - no preprocessable inputs.
$ port installed cctools
The following ports are currently installed:
  cctools @921_1+llvm80 (active)
$

With cctools +xcode everything's kosher:

$ port installed cctools
The following ports are currently installed:
  cctools @921_1+llvm80
  cctools @921_1+xcode (active)
$ g++ -g -o t t.cpp
$ ./t
$

Last edited 6 years ago by mouse07410 (Mouse) (previous) (diff)

comment:51 Changed 6 years ago by kencu (Ken)

so any build with gcc that uses -g and pipes the assembly to clang to compile will crash if llvm has assertions on.

Even the simplest hello, world file will crash.

That's at least a simple reduced case.

comment:52 Changed 6 years ago by kencu (Ken)

<https://bugs.llvm.org/show_bug.cgi?id=41840>

comment:53 Changed 6 years ago by mouse07410 (Mouse)

Perfect, thanks!

As they teach in the Sniper School: "We aim to please!" :-)

comment:54 Changed 6 years ago by kencu (Ken)

Summary:	clang-7,8.0 - seg. faults when used as assembler with assertions variant active. → clang-7,8.0 - seg. faults when used as assembler with assertions variant active when compiling with gcc and using `-g` to generate debug symbols

comment:55 Changed 6 years ago by cjones051073 (Chris Jones)

Nice work Ken ! Lets now see what they say...

comment:56 Changed 6 years ago by kencu (Ken)

a lot of this was mouse doing the prospecting!

comment:57 Changed 6 years ago by cjones051073 (Chris Jones)

Port:	clang-devel added
Summary:	clang-7,8.0 - seg. faults when used as assembler with assertions variant active when compiling with gcc and using `-g` to generate debug symbols → clang-7.0,8.0,devel - seg. faults when used as assembler with assertions variant active when compiling with gcc and using `-g` to generate debug symbols

comment:58 Changed 6 years ago by mouse07410 (Mouse)

Do you know how long the LLVM developers usually take to react...?

Last edited 6 years ago by mouse07410 (Mouse) (previous) (diff)

comment:59 Changed 6 years ago by kencu (Ken)

years, for something like this :>

Well, it all depends on whose bug everyone feels it is -- there will be a big push to say it's gcc's bug to fix, I would imagine.

Last edited 6 years ago by kencu (Ken) (previous) (diff)

comment:60 Changed 5 years ago by kencu (Ken)

Cc:	kencu added

comment:61 Changed 4 years ago by kencu (Ken)

Cc:	kencu removed
Owner:	set to kencu
Status:	new → assigned

comment:62 Changed 3 years ago by kencu (Ken)

Resolution:	→ invalid
Status:	assigned → closed

this is an upstream issue and they are aware. It's been sitting several years. There is no need for a parallel macports ticket to track it.

Note: See TracTickets for help on using tickets.

Download in other formats: