At the moment this only affects those who use a bleeding-edge Linux
distribution such as `Arch` (my platform). However, the problem will spread as
the new `gcc` version rolls out to other distributions.
Simple Nim code such as the following
type
TestObj = object of RootObj
name: string
TestSubObj = object of TestObj
objname: string
proc `=destroy`(x: TestObj) =
`=destroy`(x.name)
proc `=destroy`(x: TestSubObj) =
`=destroy`(x.objname)
`=destroy`(TestObj(x))
proc testCase() =
let t1 {.used.} = TestSubObj(objname: "tso1", name: "to1")
proc main() =
testCase()
main()
Run
produces C code that the new `gcc` compiler rejects:
[~/scratch/Nim/gcc_issue]$ nim c --lineDir:on --listCmd scratch.nim
<<<... snip ...>>>
CC: scratch.nim: gcc -c -w -fmax-errors=3 -pthread -I/opt/nim-2.0.4/lib
-I/home/louis/scratch/Nim/gcc_issue -o
/home/louis/.cache/nim/scratch_d/@mscratch.nim.c.o
/home/louis/.cache/nim/scratch_d/@mscratch.nim.c
/home/louis/scratch/Nim/gcc_issue/scratch.nim: In function
‘eqtrace___scratch_u41’:
/home/louis/scratch/Nim/gcc_issue/scratch.nim:14:147: error: passing
argument 1 of ‘eqtrace___scratch_u21’ from incompatible pointer type
[-Wincompatible-pointer-types]
14 | `=destroy`(TestObj(x))
|
^
|
|
|
tyObject_TestSubObj__1UxhUPhRwHx7QycQdth9aLg *
/home/louis/scratch/Nim/gcc_issue/scratch.nim:14:96: note: expected
‘tyObject_TestObj__Mpx6odriMQroF5fNNkP8KQ *’ but argument is of type
‘tyObject_TestSubObj__1UxhUPhRwHx7QycQdth9aLg *’
14 | `=destroy`(TestObj(x))
|
^
Error: execution of an external compiler program 'gcc -c -w -fmax-errors=3
-pthread -I/opt/nim-2.0.4/lib -I/home/louis/scratch/Nim/gcc_issue -o
/home/louis/.cache/nim/scratch_d/@mscratch.nim.c.o
/home/louis/.cache/nim/scratch_d/@mscratch.nim.c' failed with exit code: 1
Run
Starting in version 14.1, certain code that used to cause `gcc` to issue
warnings now cause errors. The one that I encountered above is type casting of
pointers - see the section `Type checking on pointer types` in [Porting to GCC
14](https://gcc.gnu.org/gcc-14/porting_to.html).
So far I have found that using one of the following work-arounds gets past the
problem:
* Pass the `-fpermissive` compile option to gcc (`nim c --passC:-fpermissive
scratch.nim`)
* Compile to C++ (`nim cpp scratch.nim`)
* Use a different C compiler such as `clang` (`nim c --cc:clang scratch.nim`)
Some ideas that did _not_ work:
* Pass the `-fno-strict-aliasing` compile option to gcc
* Install and use a legacy gcc compiler (in `Arch` the legacy gcc package is
`gcc13`). Unfortunately Nim rejects the command name for the legacy compiler
(`gcc-13`).
This one came as a shock to me. I'll be glad when we get Incremental
Compilation with a backend whose updates don't arbitrarily break our code.
