When submitting a solution in C++, please select either C++14 (GCC 6-32) or C++17 (GCC 7-32) as your compiler. ×

Xiaohuba's blog

By Xiaohuba, history, 10 months ago, In English

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

  • Vote: I like it
  • +7
  • Vote: I do not like it

»
10 months ago, # |
  Vote: I like it 0 Vote: I do not like it

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

»
10 months ago, # |
  Vote: I like it +8 Vote: I do not like it

Try compiling with -O2.

  • »
    »
    10 months ago, # ^ |
      Vote: I like it +18 Vote: I do not like it

    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.

    • »
      »
      »
      10 months ago, # ^ |
        Vote: I like it +8 Vote: I do not like it

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

  • »
    »
    10 months ago, # ^ |
      Vote: I like it 0 Vote: I do not like it

    For me, it doesn't work. :(

»
10 months ago, # |
  Vote: I like it 0 Vote: I do not like it

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.

»
10 months ago, # |
Rev. 3   Vote: I like it 0 Vote: I do not like it

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

»
10 months ago, # |
  Vote: I like it 0 Vote: I do not like it

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

»
10 months ago, # |
  Vote: I like it 0 Vote: I do not like it

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.

»
10 months ago, # |
  Vote: I like it 0 Vote: I do not like it

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

  • »
    »
    10 months ago, # ^ |
    Rev. 2   Vote: I like it 0 Vote: I do not like it

    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

    • »
      »
      »
      10 months ago, # ^ |
        Vote: I like it 0 Vote: I do not like it

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

»
10 months ago, # |
  Vote: I like it 0 Vote: I do not like it

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
  • »
    »
    10 months ago, # ^ |
      Vote: I like it 0 Vote: I do not like it

    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

    • »
      »
      »
      10 months ago, # ^ |
        Vote: I like it 0 Vote: I do not like it

      Yes, if libstdc++ in your system provides gnu pbds.

  • »
    »
    10 months ago, # ^ |
      Vote: I like it 0 Vote: I do not like it

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

  • »
    »
    10 months ago, # ^ |
    Rev. 3   Vote: I like it 0 Vote: I do not like it

    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?

    • »
      »
      »
      10 months ago, # ^ |
        Vote: I like it 0 Vote: I do not like it

      Same issue.

    • »
      »
      »
      10 months ago, # ^ |
      Rev. 5   Vote: I like it 0 Vote: I do not like it

      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.

  • »
    »
    10 months ago, # ^ |
      Vote: I like it 0 Vote: I do not like it

    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>)
    
    • »
      »
      »
      10 months ago, # ^ |
        Vote: I like it 0 Vote: I do not like it

      GCC 11 works just fine for me, so you may want to install that particular version.

»
10 months ago, # |
  Vote: I like it 0 Vote: I do not like it

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.

»
10 months ago, # |
Rev. 2   Vote: I like it 0 Vote: I do not like it

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

»
10 months ago, # |
  Vote: I like it 0 Vote: I do not like it

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

  • »
    »
    10 months ago, # ^ |
      Vote: I like it 0 Vote: I do not like it

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

»
9 months ago, # |
  Vote: I like it 0 Vote: I do not like it

I am also facing the same problem.