The error: character too large for enclosing character literal type

For context this is what I want to do:

#pragma GCC push_options "..."
#if '£' != 0xC2A3
#	error "Must set -fexec-charset=utf-8 and -finput-charset=utf-8"
#	include <abort_compilation>
#endif
#pragma GCC pop_options

Edit: Who downvoted? Why did you downvote? Don't just be a pretend critic, actually give helpful critism.

So I want to install c++ compiler which will suport c++20 and I also want to use the header file <bits/stdc++.h>.

when i installed MSYS2 i did not get bits headerfile.

when i installed mingw from sourceforge it gave me gcc 6.x which doesnt support c++20

please help me getting both with an easy process.

I want to do something like this:

#if !defined(FILE_IS_UTF8)
# error "File MUST be in UTF-8 encoding!"
/* Make absolute certain the compiler quits at
this point by including a header that is not
supposed to exist */
# include <abort_compilation.h>
#endif

Is there a way to do so?

This is all there is to my makefile. I only have one source file, no custom headers, so I don't understand why I'm not getting the debug symbols I need to diagnose a segfault I'm getting. Anyone able to help?

OUT:=bcw.elf
OBJ:=bcw.o
COPTS:=-D_GNUSOURCE --std=gnu2x -fPIC
DBGOPTS:=-g3 -fno-eliminate-unused-debug-symbols -D_DEBUG
PKGOPTS:=pkg-config --cflags --libs libnotify
LINKOPTS:=-lsndfile -lao -lnotify

all: build

rebuild: clean build

by-seer: rebuild
	seergdb --start ./$(OUT)

by-gede: rebuild
	gede --args ./$(OUT)

build:
	gcc $(DBGOPTS) $(COPTS) -o $(OBJ) `$(PKGOPTS)` -c bcw.c
	gcc $(DBGOPTS)  -o $(OUT) $(OBJ) $(LINKOPTS)

clean:
	$(if $(wildcard $(OUT)),$(RM) $(OUT),echo Nothing to clean)
  
.PHONY: all clean build rebuild by-seer

Doubt it's of relevance but on Manjaro amd64, latest kernel. The symbols I need are not from the standard headers, just my code.

Edit: Never mind. Somehow while I was learning how to shift the debug symbols into a separate file both issues resolved themselves. My little app (BCW stands for Battery Charge Watcher) is doing exactly as I wanted. It alerts me when the battery continues dipping below 20% or conitues rising above 80%. I'll need to cleanup the code but I'll post it here in a response later. For now however the makefile is clean enough so I'll post the new look:

CC:=gcc
SRC:=bcw.c
OBJ:=bcw.c.o
OUT:=bcw.elf
COPTS:=-D_GNUSOURCE --std=gnu2x -fPIC
DBGOPTS:=-g3 -fno-eliminate-unused-debug-symbols -D_DEBUG
PKGOPTS:=pkg-config --cflags --libs libnotify
LINKOPTS:=-lsndfile -lao -lnotify

all: build

rebuild: clean build

by-seer: rebuild
	seergdb --start ./$(OUT)

by-gede: rebuild
	gede --args ./$(OUT)

build: $(OUT)

$(OUT): $(OBJ)
	gcc $(DBGOPTS) -o $@ `$(PKGOPTS)` $^ $(LINKOPTS)
	objcopy --only-keep-debug $@ $@.debug
	strip -g $@
	objcopy --add-gnu-debuglink=$@.debug $@

$(OBJ): $(SRC)
	gcc $(DBGOPTS) $(COPTS) -o $@ `$(PKGOPTS)` -c $^

clean:
	$(if $(wildcard $(OUT)),$(RM) $(OUT),echo Nothing to clean)

.PHONY: all clean build rebuild by-seer

Where can I locate the files which implement Context Free Grammar for C language ?
What are the steps to make changes to C's CFG and see its effect for a file when we compile it ?

I need to rebuild a big Code::Blocks project based on wxWidgets, 'cause i need to upgrade the compiler from 10.3 to 13.2 (on Windows, using MinGW64) and use -std=gnu++17 instead of -std=gnu++11.

I have a lot of these errors:

 C:_SVILUPPO__TOOLCHAINS_\MinGW64-13.2\x86_64-w64-mingw32\include\rpcndr.h|64|error: reference to 'byte' is ambiguous|
 C:_SVILUPPO__TOOLCHAINS_\MinGW64-13.2\lib\gcc\x86_64-w64-mingw32\13.2.0\include\c++\cstddef|69|note: candidates are: 'enum class std::byte'|
 C:_SVILUPPO__TOOLCHAINS_\MinGW64-13.2\x86_64-w64-mingw32\include\rpcndr.h|63|note:                 'typedef unsigned char byte'|

In the project there was a global typedef uint8_t byte;: i commented it and then replaced all "byte" variables to uint8_t, but still i can't get rid of those errors, and i'm unable to get what causes it.

I've succesfully compiled the latest wxWidgets from the sources, and also a side project who produce a library, so it HAVE to be a problem in this specific project.

What should i do? What #include may cause the problem?

​

Thanks

Why does

gcc myopengl.c -lGL -lGLU -lglut -o myopengl

work, but

gcc -lGL -lGLU -lglut myopengl.c -o myopengl

does not?

Suppose we have the following code sequence in C:

struct A {
    bool a; /* B if a==1 otherwise A */
};

struct B {
    bool a; /* B if a==1 otherwise A */
    int b;
};

void foo(struct B *s) {
    if (!s) return;

    if (s->a != 1) return;

    // do we need a compiler barrier here

    // to make sure the compiler does not

    // reorder access of s->b across s->a?

    if (s->b != 2) return;
    ...
}

void bar() {
    struct A *a = (struct A *)malloc(sizeof(*a));
    struct B *b = (struct B *)a;
    foo(b);
}

In this case, one thing that is for sure is **s->b is only safe to access given that the condition s->a is true**. So from the compiler's POV:

1. does the type punning case in bar() makes foo() an UB even with -fno-strict-aliasing?
2. if not UB, would it happen to reorder two if branches in foo()?
3. if not UB, is a compiler barrier necessary as commented to restore this foo() to be a well-defined function?

I'm making 2 projects with cpp and I find quite dificult to make everything that involve casting instances to other types, for example.

I know Arduino IDE is not a good IDE to code anda maybe I want to use another IDE before burning my code in my cards, do you have any suggestion?

IDK, what kind of project do the people who want do build a portifolio with cpp do?

I really hope someone here has some idea as to what is going on. I am using platformio to build firmware for an STM32 board. I asked this question in platformio community and didn't get any replies.

I am trying to benchmark code that handles ADC samples, to make sure I am processing things fast enough. At the start of the callback I turn on D2, turn it off at the end, and monitor that on my oscilloscope. The other day I stopped multiplying a variable by 2.0f, and suddenly execution time jumped up. Very minor tweaks to code are seeming to have very large impacts on execution time. I assume it has to do with compiler optimizations, so I set -O0 in the build flags, and at first it seemed like things were normal and I could benchmark as needed. In the past, commenting out certain functions would make a difference, so when it jumped up today, I added a second call to BSL_LCD_Clear(), and sure enough, execution time went back down. Just to be clear, the execution time DROPS, when I add the second call. The thing is, that code isn’t even reached most of the time. It’s only executed after a signal pulse has been detected, and the execution time is high even when no pulse is detected. I thought -O0 disabled all optimizations, but now I guess I am unsure. What other compiler options can I try to figure out why removing an extra function call that isn’t even called, causes exection time to jump out dramatically? The BSP_LCD_Clear() function is not the only one that affects it. In the past it was whether or not I stopped the ADC, and I forgot what it was before that.

Above is what I initially posted on the platformio group. Since that time I have been having execution times jump all over the place due to small changes. To clarify, if I don't change code, and just rebuild, execution times stay the same, but the smallest of code changes can result in huge swings in execution time, even when they are not run with each interrupt call. With every minor change, it seems I have to change the -O flags or disable branch predictions to get execution time back down. Is there some other option I am missing in GCC? I am about to lose my mind.

void HAL_ADC_ConvHalfCpltCallback(ADC_HandleTypeDef* hadc) {
  memcpy(&adc_buffer[0], &dma_buffer[0], sizeof(uint16_t) * (ADC_BUFFER_LENGTH / 2));
}

void HAL_ADC_ConvCpltCallback(ADC_HandleTypeDef* hadc) {
  static uint32_t onCount = 0;
  HAL_GPIO_WritePin(ARDUINO_D2_GPIO_Port, ARDUINO_D2_Pin, GPIO_PIN_SET);

  memcpy(&adc_buffer[ADC_BUFFER_LENGTH / 2], &dma_buffer[ADC_BUFFER_LENGTH / 2], sizeof(uint16_t) * (ADC_BUFFER_LENGTH / 2));

  bool on = IsOn();
  if(on) {
    onCount++;
  } else {
    if(onCount >= 8) {
      StopADC();
      Render();
      StartADC();
    }
    onCount = 0;
  }

  HAL_GPIO_WritePin(ARDUINO_D2_GPIO_Port, ARDUINO_D2_Pin, GPIO_PIN_RESET);
}

void Render() {
  BSP_LCD_Clear(LCD_COLOR_BLACK);
  BSP_LCD_Clear(LCD_COLOR_BLACK); // Commenting this out causes execution time to jump.

  DisplayFFT();
  DisplaySignals();

  while (!(LTDC->CDSR & LTDC_CDSR_VSYNCS)) {};
  BSP_LCD_SetLayerVisible_NoReload(activeLayer, ENABLE);
  activeLayer ^= 1;
  BSP_LCD_SetLayerVisible(activeLayer, DISABLE);
  BSP_LCD_SelectLayer(activeLayer);
}

I'm running antiX Linux on a 64-bit ASUS laptop

I need the latest & greatest version of `gcc’ in order to compile from source the latest & greatest Gambit-C Scheme compiler.

got gcc cloned from github!

Got objdir directory made in top of source tree.
cd objdir
../configure [options ???] [target ????]

I need advise for the options & target please.

for “target” is –host=x86_64-pc-linux-gnu ok?

for “options”. I have zero clue!!
TIA …

Right now I'm curious what will/won't trigger a warning from -Wattributes, but in full generality I would like a list of all the warnings.

Closest I can find is https://gcc.gnu.org/onlinedocs/gcc/Warning-Options.html but that is not exactly what I'm looking for.

I need to compile SPEC2017 CPU for my work that needs to be run on a simulator (gem5), unfortunately the simulator does not support vector instructions. Can someone tell me if there is a compiler flag that makes a note of this fact and only generates scalar instructions when compiling the program?

For reference, my version of gcc is 9.5 (this is the only version that I am allowed to use)

Thanks

Im compiling GCC on some old PPC64 computer, and it's taking a really long time, it's about 24 hours now. I don't expect that to be fast, but just wondered if there is some way to +- estimate the current progress. For example from files inside working directory or something like that. Next time I will cross-compile, but for now Im just letting this run. I tried to browse the build directory to see if I can find something interesting. There is a stage_current wile which says "stage2", plus I run "find . -name *.0|wc l", to find that there are currently 2635 ".o" files compiled. Any tip on how to estimate what is the progress of this?

Hello, I encountered a weird warning, as stated in the title, the warning is:

...
warning: the compiler differs from the one used to build the kernel
The kernel was built by: x86_64-linux-gnu-gcc-11 (Ubuntu 11.4.0-1ubuntu1~22.04) 11.4.0
You are using:           gcc (Ubuntu 11.4.0-1ubuntu1~22.04) 11.4.0
...

Other info:

$ cat /proc/version
Linux version 6.2.0-39-generic (buildd@lcy02-amd64-045) (x86_64-linux-gnu-gcc-11 (Ubuntu 11.4.0-1ubuntu1~22.04) 11.4.0, GNU ld (GNU Binutils for Ubuntu) 2.38) #40~22.04.1-Ubuntu SMP PREEMPT_DYNAMIC Thu Nov 16 10:53:04 UTC 2

$ gcc -v
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/11/lto-wrapper
OFFLOAD_TARGET_NAMES=nvptx-none:amdgcn-amdhsa
OFFLOAD_TARGET_DEFAULT=1
Target: x86_64-linux-gnu
...
gcc version 11.4.0 (Ubuntu 11.4.0-1ubuntu1~22.04)

Can anyone help? Thanks!

I tried updating GCC via console and via GUI but both didn't update my gcc. Can i reinstall it without breaking anything or how do i solve this issue?
(and yes i made sure to update AND upgrade)

I have compiled the following program:

#include <stdio.h>
#include <string.h>

// filename: buffer2.c

void test(char *buf) {
        char smallbuf[32];
        printf("debug1: smallbuf char[32] @%p\n", smallbuf);
        strcpy(smallbuf, buf);
        printf("%s\n", smallbuf);
}

int main(int argc, char **argv) {
        printf("debug0: test address @%p\n", test);
        printf("debug0: printf address @%p\n", printf);
        test(argv[1]);
        return 0;
}

with this command: gcc buffer2.c -fPIE -m32 -o buffer

output of checksec:

./checksec.sh --file buffer
RELRO           STACK CANARY      NX            PIE             RPATH      RUNPATH      FILE
Full RELRO      Canary found      NX enabled    PIE enabled     No RPATH   No RUNPATH   buffer

With this configuration if I execute this program twice, I will obtain the same printf address:

$ ./buffer
debug0: test address u/0x5661a1ad
debug0: printf address @0xf7c57520
debug1: smallbuf char[32] @0xff940e50
Segmentation fault (core dumped)
$ ./buffer
debug0: test address @0x566241ad
debug0: printf address @0xf7c57520
debug1: smallbuf char[32] @0xff8b9580

Shouldn't the address of printf change each time the program is executed with PIE and ASLR enabled? I asked people around me but no one is able to explain me why it behaves like this. The expected output would be that at least 1 byte of the printf's address changes.

Additional information that might be relevant:

• GCC Version: 11.4.0
• OS: Ubuntu 22.04
• Kernel: 6.2.0-35-generic
• libc: glibc 2.35

I also tried to do the same operations with a fresh install of ubuntu 22.04 and obtained the same results.

This issue doesn't appear when the program is compiled for 64 bits.

--

Some people noticed the issue as well. It seems related to https://bugs.launchpad.net/ubuntu-kernel-tests/+bug/1983357 and should be fixed with the 6.5.0-25.25 kernel (on ubuntu)

EDIT : Follow-up on the issue.

I tend to stick documentation inside ifdef blocks like

#ifdef DOCS

​

#endif // DOCS

I'm running into problems because GCC doesn't ignore the contents of the blocks. For example it's erroring out because of a line like:

TEMPERATURE (°C) DIGITAL OUTPUT

It doesn't like the extended ascii.

MAX31856Driver.h:9:14: error: extended character ° is not valid in an identifier
    9 | TEMPERATURE (°C) DIGITAL OUTPUT

​

Is there any option to make GCC ignore these blocks? I thought that's how it should work by default. Visual Studio ignores anything inside the blocks.

This is GCC 12.2.0-14 on a Pi4.

i know what i can define using -D but it define only in source file but how to define in specific header file ?

My syntax is this:

x86_64-w64-mingw32-gcc main.c -o game -L/boot/usr/x86_64-w64-mingw32/lib -lSDL2 -lSDL2_image -lSDL2main

Supposedly I'm supposded to link against SDL2.lib and SDL2main.lib, but I cannot find those files, all I see is "libSDL2main.a" and "libSDL2.a", there are no .lib files in the lib directory

Normally, when I compile Obj-C, I have to type a rather long command with the right options.

Here's what I have to type every time:

gcc PROGRAM.m `gnustep-config --objc-flags` -lobjc -lgnustep-base -o PROGRAM`

The question is, can I shorten the command by way of an alias or a shell script so I don't have to type all those options but still get the same results? Preferably so that I can have different program names.

Any help is greatly appreciated by my keyboard.

-TronNerd82

When I try to retrieve a stack trace from GCC I always have the same result. I doesn't depend on where it has been called because the software I am working on is giving me exactly the same stack.

Main.cpp

#include <stacktrace>
#include <iostream>

int main(void)
{
    std::cout << std::stacktrace::current() << std::endl;
    return 0;
}

Compilation

$ g++ -g3 -std=c++23 Main.cpp -lstdc++_libbacktrace

Result

0#      at :32764
1#      at :32764
2#      at :32764
3#      at :32764
4#

Setup

I am running arch linux with this version of GCC:

$ gcc -v
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-pc-linux-gnu/13.2.1/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: /build/gcc/src/gcc/configure --enable-languages=ada,c,c++,d,fortran,go,lto,objc,obj-c++ --enable-bootstrap --prefix=/usr --libdir=/usr/lib --libexecdir=/usr/lib --mandir=/usr/share/man --infodir=/usr/share/info --with-bugurl=https://bugs.archlinux.org/ --with-build-config=bootstrap-lto --with-linker-hash-style=gnu --with-system-zlib --enable-__cxa_atexit --enable-cet=auto --enable-checking=release --enable-clocale=gnu --enable-default-pie --enable-default-ssp --enable-gnu-indirect-function --enable-gnu-unique-object --enable-libstdcxx-backtrace --enable-link-serialization=1 --enable-linker-build-id --enable-lto --enable-multilib --enable-plugin --enable-shared --enable-threads=posix --disable-libssp --disable-libstdcxx-pch --disable-werror
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 13.2.1 20230801 (GCC) 

Any help would be appreciated, thank you.

I am getting this issue with gcc and I have looked this up- https://unix.stackexchange.com/questions/206410/why-gcc-show-unknown-in-target-x86-64-unknown-linux-gnu-in-arch-linux and I have found a config.guess - https://gcc.gnu.org/git/?p=gcc.git;a=blob;f=config.guess;hb=HEAD

and am wanting to modify it and I just want to make sure that deleting unknown line 134 -137 next to UNAME will do the trick or if this issue has to do with something else. I am using LinuxMint, my gcc -v is 9, I use VS Code and thats where this problem manifests the Most.

When i execute from the System terminal everything seems fine.

I am trying to implement a dwarf parser in c++ without using any external dependencies. As mentioned in dwarf5 standard, debug info first 4 bytes or 12 bytes denotes the unit length Basically this:

unit_length (initial length) A 4-byte or 12-byte unsigned integer representing the length of the3 .debug_info contribution for that compilation unit, not including the length field itself. In the 32-bit DWARF format, this is a 4-byte unsigned integer (which must be less than 0xfffffff0); in the 64-bit DWARF format, this consists of the 4-byte value 0xffffffff followed by an 8-byte unsigned integer that gives the actual length (see Section 7.4 on page 196).

When I am dumping .debug_info section hexadecimally using objdump I am getting this(see readelf output below).

objdump -s -j .debug_info hello.o

hello.o: file format elf64-x86-64

Contents of section .debug_info:

0000 01000000 00000000 9a000000 00000000 ................
0010 01000000 00000000 789c9bc6 c0c0c0ca ........x.......
0020 c0c801a4 18984084 2c031a10 42623372 ......@.,...Bb3r
0030 b0832916 0805d1c6 c804e5b1 4178ac20 ..).........Ax.
0040 8a998535 33af04a8 8115498e 05aa2002 ...53.....I... .
0050 8bf18c73 58131918 99394172 4c137318 ...sX....9ArL.s.
0060 180011e5 0560

So according to this the length should be 0x01000000 but actual length is 0x96.(see readelf output below) readelf -wi hello.o Contents of the .debug_info section:

Compilation Unit @ offset 0: Length: 0x96 (32-bit) Version: 5 Unit Type: DW_UT_compile (1) Abbrev Offset: 0 Pointer Size: 8

I know, I am missing something basic but even after reading standards for many times. I am unable to find my mistake. One more thing, I searched for some basic dwaf parser so that I can understand what they are doing but was unable to find any. All of the parser were big libraries which was difficult to understand. If any of you can atleast provide some readble and understandable parser code, It will be helpful too.

I have to compile gcc with jit support from source because my work's SLES 15 SP4 does not have the package (i need it for emacs native-comp), but having an issue that I can't seem to google.

So when I run the libgccjit tutorial example myself, I get

ld: cannot find crtbeginS.o: No such file or directory
ld: cannot find -lgcc: No such file or directory
ld: cannot find -lgcc\_s: No such file or directory 
libgccjit.so: error: error  invoking gcc driver

I have tried to search for these errors with context of libgccjit and can't find anything.

I used the default gcc7 that was already installed on the system to compile gcc-13.2.0, so maybe i need to recompile gcc-13 using gcc-11?

The crtbeginS.o is located under install_dir/lib/gcc/x86_64-pc-linux-gnu/13.2.0 which install_dir/lib is appended to my LD_LIBRARY_PATH... so... not sure what the deal is. I don't know what `-lgcc` or -lgcc_s` is or how to find it.

​

Hi, if this is too stupid, tell me and I will delete the post.

Weird stuff happened to me when I was trying to put together a docker image on the Linux on ChromeOS, which is some virtualized Debian 11. Is this something GCC team should see or am I just behind on some other deep tech stuff?

```
➜ ~ cd text-generation-webui

➜ text-generation-webui git:(main) ✗ docker compose up --build

[+] Building 28.1s (20/40)

=> [text-generation-webui internal] load build definition from Dockerfile 0.0s

=> => transferring dockerfile: 115B 0.0s

=> [text-generation-webui internal] load .dockerignore 0.0s

=> => transferring context: 123B 0.0s

=> [text-generation-webui internal] load metadata for docker.io/nvidia/cuda 1.0s

=> [text-generation-webui internal] load metadata for docker.io/nvidia/cuda 1.0s

=> [text-generation-webui internal] load build context 0.0s

=> => transferring context: 13.66kB 0.0s

=> [text-generation-webui stage-1 1/28] FROM docker.io/nvidia/cuda:11.8.0- 0.0s

=> [text-generation-webui builder 1/7] FROM docker.io/nvidia/cuda:11.8.0-de 0.0s

=> CACHED [text-generation-webui builder 2/7] RUN apt-get update && apt 0.0s

=> CACHED [text-generation-webui builder 3/7] RUN git clone https://github. 0.0s

=> CACHED [text-generation-webui builder 4/7] WORKDIR /build 0.0s

=> CACHED [text-generation-webui builder 5/7] RUN python3 -m venv /build/ve 0.0s

=> CACHED [text-generation-webui builder 6/7] RUN . /build/venv/bin/activat 0.0s

=> CACHED [text-generation-webui stage-1 2/28] RUN apt-get update && a 0.0s

=> CACHED [text-generation-webui stage-1 3/28] RUN --mount=type=cache,targ 0.0s

=> CACHED [text-generation-webui stage-1 4/28] RUN mkdir /app 0.0s

=> CACHED [text-generation-webui stage-1 5/28] WORKDIR /app 0.0s

=> CACHED [text-generation-webui stage-1 6/28] RUN test -n "HEAD" && git r 0.0s

=> CACHED [text-generation-webui stage-1 7/28] RUN virtualenv /app/venv 0.0s

=> CACHED [text-generation-webui stage-1 8/28] RUN . /app/venv/bin/activat 0.0s

=> ERROR [text-generation-webui builder 7/7] RUN . /build/venv/bin/activat 27.0s

------

> [text-generation-webui builder 7/7] RUN . /build/venv/bin/activate && python3 setup_cuda.py bdist_wheel -d .:

3.877 No CUDA runtime is found, using CUDA_HOME='/usr/local/cuda'

3.919 running bdist_wheel

3.943 running build

3.943 running build_ext

3.943 /build/venv/lib/python3.10/site-packages/torch/utils/cpp_extension.py:476: UserWarning: Attempted to use ninja as the BuildExtension backend but we could not find ninja.. Falling back to using the slow distutils backend.

3.943 warnings.warn(msg.format('we could not find ninja.'))

3.994 /build/venv/lib/python3.10/site-packages/torch/utils/cpp_extension.py:388: UserWarning: The detected CUDA version (11.8) has a minor version mismatch with the version that was used to compile PyTorch (11.7). Most likely this shouldn't be a problem.

3.994 warnings.warn(CUDA_MISMATCH_WARN.format(cuda_str_version, torch.version.cuda))

3.994 /build/venv/lib/python3.10/site-packages/torch/utils/cpp_extension.py:398: UserWarning: There are no x86_64-linux-gnu-g++ version bounds defined for CUDA version 11.8

3.994 warnings.warn(f'There are no {compiler_name} version bounds defined for CUDA version {cuda_str_version}')

3.995 building 'quant_cuda' extension

3.996 creating build

3.996 creating build/temp.linux-x86_64-cpython-310

3.996 x86_64-linux-gnu-gcc -Wno-unused-result -Wsign-compare -DNDEBUG -g -fwrapv -O2 -Wall -g -fstack-protector-strong -Wformat -Werror=format-security -g -fwrapv -O2 -fPIC -I/build/venv/lib/python3.10/site-packages/torch/include -I/build/venv/lib/python3.10/site-packages/torch/include/torch/csrc/api/include -I/build/venv/lib/python3.10/site-packages/torch/include/TH -I/build/venv/lib/python3.10/site-packages/torch/include/THC -I/usr/local/cuda/include -I/build/venv/include -I/usr/include/python3.10 -c quant_cuda.cpp -o build/temp.linux-x86_64-cpython-310/quant_cuda.o -DTORCH_API_INCLUDE_EXTENSION_H -DPYBIND11_COMPILER_TYPE=\"_gcc\" -DPYBIND11_STDLIB=\"_libstdcpp\" -DPYBIND11_BUILD_ABI=\"_cxxabi1011\" -DTORCH_EXTENSION_NAME=quant_cuda -D_GLIBCXX_USE_CXX11_ABI=0 -std=c++17

26.41 In file included from /usr/include/c++/11/bits/shared_ptr.h:53,

26.41 from /usr/include/c++/11/memory:77,

26.41 from /build/venv/lib/python3.10/site-packages/torch/include/c10/util/C++17.h:8,

26.41 from /build/venv/lib/python3.10/site-packages/torch/include/c10/util/string_view.h:4,

26.41 from /build/venv/lib/python3.10/site-packages/torch/include/c10/util/StringUtil.h:6,

26.41 from /build/venv/lib/python3.10/site-packages/torch/include/c10/util/Exception.h:6,

26.41 from /build/venv/lib/python3.10/site-packages/torch/include/c10/core/Device.h:5,

26.41 from /build/venv/lib/python3.10/site-packages/torch/include/ATen/core/TensorBody.h:11,

26.41 from /build/venv/lib/python3.10/site-packages/torch/include/ATen/core/Tensor.h:3,

26.41 from /build/venv/lib/python3.10/site-packages/torch/include/ATen/Tensor.h:3,

26.41 from /build/venv/lib/python3.10/site-packages/torch/include/torch/csrc/autograd/function_hook.h:3,

26.41 from /build/venv/lib/python3.10/site-packages/torch/include/torch/csrc/autograd/cpp_hook.h:2,

26.41 from /build/venv/lib/python3.10/site-packages/torch/include/torch/csrc/autograd/variable.h:6,

26.41 from /build/venv/lib/python3.10/site-packages/torch/include/torch/csrc/autograd/autograd.h:3,

26.41 from /build/venv/lib/python3.10/site-packages/torch/include/torch/csrc/api/include/torch/autograd.h:3,

26.41 from /build/venv/lib/python3.10/site-packages/torch/include/torch/csrc/api/include/torch/all.h:7,

26.41 from quant_cuda.cpp:1:

26.41 /usr/include/c++/11/bits/shared_ptr_base.h: In instantiation of ‘std::__shared_count<_Lp>::__shared_count(_Tp*&, std::_Sp_alloc_shared_tag<_Alloc>, _Args&& ...) [with _Tp = torch::nn::UnfoldImpl; _Alloc = std::allocator<torch::nn::UnfoldImpl>; _Args = {const torch::nn::UnfoldImpl&}; __gnu_cxx::_Lock_policy _Lp = __gnu_cxx::_S_atomic]’:

26.41 /usr/include/c++/11/bits/shared_ptr_base.h:1342:14: required from ‘std::__shared_ptr<_Tp, _Lp>::__shared_ptr(std::_Sp_alloc_shared_tag<_Tp>, _Args&& ...) [with _Alloc = std::allocator<torch::nn::UnfoldImpl>; _Args = {const torch::nn::UnfoldImpl&}; _Tp = torch::nn::UnfoldImpl; __gnu_cxx::_Lock_policy _Lp = __gnu_cxx::_S_atomic]’

26.41 /usr/include/c++/11/bits/shared_ptr.h:409:59: required from ‘std::shared_ptr<_Tp>::shared_ptr(std::_Sp_alloc_shared_tag<_Tp>, _Args&& ...) [with _Alloc = std::allocator<torch::nn::UnfoldImpl>; _Args = {const torch::nn::UnfoldImpl&}; _Tp = torch::nn::UnfoldImpl]’

26.41 /usr/include/c++/11/bits/shared_ptr.h:862:14: required from ‘std::shared_ptr<_Tp> std::allocate_shared(const _Alloc&, _Args&& ...) [with _Tp = torch::nn::UnfoldImpl; _Alloc = std::allocator<torch::nn::UnfoldImpl>; _Args = {const torch::nn::UnfoldImpl&}]’

26.41 /usr/include/c++/11/bits/shared_ptr.h:878:39: required from ‘std::shared_ptr<_Tp> std::make_shared(_Args&& ...) [with _Tp = torch::nn::UnfoldImpl; _Args = {const torch::nn::UnfoldImpl&}]’

26.41 /build/venv/lib/python3.10/site-packages/torch/include/torch/csrc/api/include/torch/nn/cloneable.h:40:42: required from ‘std::shared_ptr<torch::nn::Module> torch::nn::Cloneable<Derived>::clone(const c10::optional<c10::Device>&) const [with Derived = torch::nn::UnfoldImpl]’

26.41 /build/venv/lib/python3.10/site-packages/torch/include/torch/csrc/api/include/torch/nn/cloneable.h:35:27: required from here

26.41 /usr/include/c++/11/bits/shared_ptr_base.h:655:9: internal compiler error: Segmentation fault

26.41 655 | }

26.41 | ^

26.43 0xe3335f internal_error(char const*, ...)

26.43 ???:0

26.43 0x13a1bc7 gt_ggc_mx_lang_tree_node(void*)

26.43 ???:0

26.43 0x13a26a4 gt_ggc_mx_lang_tree_node(void*)

26.43 ???:0

26.43 0x13a210b gt_ggc_mx_lang_tree_node(void*)

26.43 ???:0

26.43 0x13ad04c gt_ggc_mx_lang_decl(void*)

26.43 ???:0

26.43 0x13a2862 gt_ggc_mx_lang_tree_node(void*)

26.43 ???:0

26.43 0x13acd1d gt_ggc_mx_vec_tree_va_gc_(void*)

26.43 ???:0

26.43 0x13ad202 gt_ggc_mx_lang_type(void*)

26.43 ???:0

26.43 0x13a3164 gt_ggc_mx_lang_tree_node(void*)

26.43 ???:0

26.43 0x13a2b15 gt_ggc_mx_lang_tree_node(void*)

26.43 ???:0

26.43 0x13acd1d gt_ggc_mx_vec_tree_va_gc_(void*)

26.43 ???:0

26.43 0x13ad202 gt_ggc_mx_lang_type(void*)

26.43 ???:0

26.43 0x13a3164 gt_ggc_mx_lang_tree_node(void*)

26.43 ???:0

26.43 0x13a268c gt_ggc_mx_lang_tree_node(void*)

26.43 ???:0

26.43 0x13a210b gt_ggc_mx_lang_tree_node(void*)

26.43 ???:0

26.43 0x13ad04c gt_ggc_mx_lang_decl(void*)

26.43 ???:0

26.43 0x13a2862 gt_ggc_mx_lang_tree_node(void*)

26.43 ???:0

26.43 0x13acd1d gt_ggc_mx_vec_tree_va_gc_(void*)

26.43 ???:0

26.43 0x13ad202 gt_ggc_mx_lang_type(void*)

26.43 ???:0

26.43 0x13a3164 gt_ggc_mx_lang_tree_node(void*)

26.43 ???:0

26.43 Please submit a full bug report,

26.43 with preprocessed source if appropriate.

26.43 Please include the complete backtrace with any bug report.

26.43 See <file:///usr/share/doc/gcc-11/README.Bugs> for instructions.

26.49 error: command '/usr/bin/x86_64-linux-gnu-gcc' failed with exit code 1

------

failed to solve: executor failed running [/bin/sh -c . /build/venv/bin/activate && python3 setup_cuda.py bdist_wheel -d .]: exit code: 1

```

Improvements:

• Support #ifdef/#elif/#else/#endif
• Support the tcc compiler
• Add command history
• Python terminal style Ctrl-D Ctrl-C
• Various bug fixes

https://github.com/hanoglu/TermiC