Блог пользователя Xiaohuba

Homebrew GCC may not work properly on Apple M1 devices
Автор Xiaohuba, история, 11 месяцев назад, По-английски

These days I'm trying to compile the following c++ code:

#include<vector>

const int MAXN=1e5+5;
std::vector<int> factor[MAXN];

signed main() {return 0;}

This code works while I'm using g++ 11.3.0. However, if I use g++ 13.1.0 or 12.1.0, I'll receive a compile error:

/var/folders/v7/yk8tz4j54cl2lhp1f80nyz700000gn/T//cc2HpyzP.s:371:29: error: unexpected token in '.section' directive
        .section .data.rel.ro.local

Reinstalling the compiler doesn't works. What should I do?

Note I use Apple M1 with MacOS 13.2.1 (22D68).

  • Проголосовать: нравится
  • +7
  • Проголосовать: не нравится

»
11 месяцев назад, # |
  Проголосовать: нравится 0 Проголосовать: не нравится

Have you tried updating your Xcode command line tools? It worked for me. This might help: updating command line tools

→ Ответить
»
11 месяцев назад, # |
  Проголосовать: нравится +8 Проголосовать: не нравится

Try compiling with -O2.

→ Ответить
  • »
    »
    11 месяцев назад, # ^ |
      Проголосовать: нравится +18 Проголосовать: не нравится

    Even if this worked, it'd still be a bug, or it could be sneaking in hidden bugs. You don't always want to compile with -O2.

    → Ответить
    • »
      »
      »
      11 месяцев назад, # ^ |
        Проголосовать: нравится +8 Проголосовать: не нравится

      Yeah, it's certainly not a great fix, but it's the only one I've found so far. Before, I used to just decrease MAXN, but I've lost track of how many bugs I've gotten by forgetting to revert MAXN before submitting :/

      → Ответить
  • »
    »
    11 месяцев назад, # ^ |
      Проголосовать: нравится 0 Проголосовать: не нравится

    For me, it doesn't work. :(

    → Ответить
»
11 месяцев назад, # |
  Проголосовать: нравится 0 Проголосовать: не нравится

I've also came across this issue, I don't necessarily have a fix but I do remember it had to do with MAXN being too large. Try setting it to 1e2, it compiled fine for me afterwards.

→ Ответить
»
11 месяцев назад, # |
← Rev. 3   Проголосовать: нравится 0 Проголосовать: не нравится

Same Error Here. It has to do with MAXN. If you set it small enough, it will work. Also, if you use the default Clang Apple provides, it works normally. See here for some discussion.

I have also tried increasing the stack size, but it too doesn't work.

Is anybody here on Apple Silicon who uses gcc who fixed this problem? Thanks

→ Ответить
»
11 месяцев назад, # |
  Проголосовать: нравится 0 Проголосовать: не нравится

Since decreasing MAXN has been suggested, try comparing the assembly for sufficiently small and too large MAXN. How do they differ?

→ Ответить
»
11 месяцев назад, # |
  Проголосовать: нравится 0 Проголосовать: не нравится

I am using g++ 12.2.0 and it's working for me as for your concern you should run it on custom test if it's working then it may be an internal problem of your system.

→ Ответить
»
11 месяцев назад, # |
  Проголосовать: нравится 0 Проголосовать: не нравится

Can i know how ur able to use g++ compiler with mac? Whenever i type g++ [filename] it always compiles with clang. How do I make it compile with g++?

→ Ответить
  • »
    »
    11 месяцев назад, # ^ |
    ← Rev. 2   Проголосовать: нравится 0 Проголосовать: не нравится

    In Mac, g++ is an alias for Clang. Use the g++ inside Homebrew folder, for me it is /opt/homebrew/bin/g++-13

    See here

    → Ответить
    • »
      »
      »
      11 месяцев назад, # ^ |
        Проголосовать: нравится 0 Проголосовать: не нравится

      Ohh tysm. Ive been struggling with this for a while and just decided to deal with it and use clang lol. Appreciate it.

      → Ответить
»
11 месяцев назад, # |
  Проголосовать: нравится 0 Проголосовать: не нравится

GCC has never officially supported macos, so you either revert to past versions or wait for proper fixes. One possible workaround is to use clang/llvm with libstdc++ instead of libc++.

For instance, if your gcc installation lies in /opt/homebrew/Cellar/gcc/12.1.0 (which is the default path for aarch64 homebrew gcc), the compilation command would be

clang++ \
    -stdlib=libstdc++ \
    -stdlib++-isystem \
    /opt/homebrew/Cellar/gcc/12.1.0/include/c++/12 \
    -cxx-isystem \
    /opt/homebrew/Cellar/gcc/12.1.0/include/c++/12/aarch64-apple-darwin22 \
    -L/opt/homebrew/Cellar/gcc/12.1.0/lib/gcc/12 \
    -std=c++17 \
    -o main main.cpp
→ Ответить
  • »
    »
    11 месяцев назад, # ^ |
      Проголосовать: нравится 0 Проголосовать: не нравится

    Does this provide access to gnu pbds? I have been trying to find a way to use pbds without gcc, because gcc does not support sanitizers on my computer

    → Ответить
  • »
    »
    11 месяцев назад, # ^ |
      Проголосовать: нравится 0 Проголосовать: не нравится

    wow i guess that's the most elegant solution to the bits/stdc++ not working in macOS. pbds is also working.

    → Ответить
  • »
    »
    11 месяцев назад, # ^ |
    ← Rev. 3   Проголосовать: нравится 0 Проголосовать: не нравится

    I'm trying your recommendation. Seems the most all around. But I'm facing strange errors in code execution:

    A simple hello world program causes a segfault. And other codes not prints output when executed.

    Compilation:

    clang++ -stdlib=libstdc++ -stdlib++-isystem /opt/homebrew/Cellar/gcc/13.1.0/include/c++/13 -cxx-isystem /opt/homebrew/Cellar/gcc/13.1.0/include/c++/13/aarch64-apple-darwin22 -L /opt/homebrew/Cellar/gcc/13.1.0/lib/gcc/13 -std=c++17 -o a hello.cpp

    Any thoughts?

    → Ответить
    • »
      »
      »
      11 месяцев назад, # ^ |
        Проголосовать: нравится 0 Проголосовать: не нравится

      Same issue.

      → Ответить
    • »
      »
      »
      11 месяцев назад, # ^ |
      ← Rev. 5   Проголосовать: нравится 0 Проголосовать: не нравится

      For now I will keep using g++. To avoid .section compilation errors I'm not declaring arrays of std containers (use vector<vector<int>> adj(maxn) instead of vector<int> adj[maxn]).

      g++ searches for system includes in /Library/Developer/CommandLineTools/SDKs/MacOSX13.sdk (you can check with g++-13 -v ... when compiling, searches for --with-sysroot=...). This path isn't setted by Xcode, it's Command Line Tools that defines these includes (I took some serious time to figure this out) and you can install it from here > Additional Downloads.

      This way I have access to gnu_pbds and can compile with g++-13 -std=c++17 -o a src/main.cpp. But sanitizers not works :(.

      To see where Xcode it's placing the sdks you can run xcrun --show-sdk-path.

      → Ответить
  • »
    »
    11 месяцев назад, # ^ |
      Проголосовать: нравится 0 Проголосовать: не нравится

    As Duds pointed out, this solution may cause mysterious segmentation fault. How to work out this problem?

    P.S. When I tried to compile a single hello world, it looked normal. 

    #include <iostream>

int main() {
  std::cout << "Hello World!" << std::endl;
  return 0;
}

    But when I executed the program, the sanitizer gave me the following information:

    AddressSanitizer:DEADLYSIGNAL
=================================================================
==9741==ERROR: AddressSanitizer: SEGV on unknown address 0xffffffffffffffe8 (pc 0x000102a151d0 bp 0x00016d86a7a0 sp 0x00016d86a7a0 T0)
==9741==The signal is caused by a READ memory access.
    #0 0x102a151d0 in std::ostream::sentry::sentry(std::ostream&)+0x20 (libstdc++.6.dylib:arm64+0x991d0) (BuildId: 151c02a14b16389887c4edd68fe8a80832000000200000000100000000000d00)
    #1 0x102a15c50 in std::basic_ostream<char, std::char_traits<char>>& std::__ostream_insert<char, std::char_traits<char>>(std::basic_ostream<char, std::char_traits<char>>&, char const*, long)+0x30 (libstdc++.6.dylib:arm64+0x99c50) (BuildId: 151c02a14b16389887c4edd68fe8a80832000000200000000100000000000d00)
    #2 0x102a160b0 in std::basic_ostream<char, std::char_traits<char>>& std::operator<<<std::char_traits<char>>(std::basic_ostream<char, std::char_traits<char>>&, char const*)+0x2c (libstdc++.6.dylib:arm64+0x9a0b0) (BuildId: 151c02a14b16389887c4edd68fe8a80832000000200000000100000000000d00)
    #3 0x102597cdc in main tmp.cpp:4
    #4 0x1aaacff24  (<unknown module>)
    → Ответить
»
11 месяцев назад, # |
  Проголосовать: нравится 0 Проголосовать: не нравится

Not a permanent fix but using -std=gnu++20 made the error go away for me (14/17 both have the bug it seems). The -O2 flag didn't work for me.

→ Ответить
»
11 месяцев назад, # |
← Rev. 2   Проголосовать: нравится 0 Проголосовать: не нравится

it worked for me

you may have to change the compiler explicitly to homebrew's g++ file location in the editor and use the flag -std=GNU++17 or -std=c++17 along with it

→ Ответить
»
11 месяцев назад, # |
  Проголосовать: нравится 0 Проголосовать: не нравится

Did you find any fix? Have you tried downgrading the compiler? I am also facing the same problem actually, so wanted to check if anyone had any progress with this

→ Ответить
  • »
    »
    11 месяцев назад, # ^ |
      Проголосовать: нравится 0 Проголосовать: не нравится

    You can either downgrade the compiler to 11.x.x or use clang with libstdc++.

    → Ответить
»
10 месяцев назад, # |
  Проголосовать: нравится 0 Проголосовать: не нравится

I am also facing the same problem.

→ Ответить
»
3 недели назад, # |
  Проголосовать: нравится +5 Проголосовать: не нравится

if anyone still facing the same issue i fixed it by upgrading to gcc version 13.2.0 (Homebrew GCC 13.2.0)

write these steps in your terminal:

step 1: brew update

step 2: brew upgrade gcc

step 3: g++ -v

it'll show apple clang version, in my case it was Apple clang version 15.0.0 (clang-1500.1.0.2.5)

step 4: sudo rm g++

remove already existing g++ file by typing your sudo password

step 5:

ln -s g++-13 g++

step 6:

g++ -v

it'll switch to g++ version from apple clang version and in my case it shows gcc version 13.2.0 (Homebrew GCC 13.2.0)

→ Ответить