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()
[~/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
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.
So far I have found that using one of the following work-arounds gets past the problem:
Some ideas that did not work:
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.
Have you tried --passC:"-Wno-error=incompatible-function-pointer-types" ?
Awhile back, I ran into the same problem with
Can we pin this post?
Posts in the forum are easily lost and this one is going to be useful for a while. Thanks in advance.
more fixing for gcc 14 is coming
fixes #23665; rework spawn with gcc 14 and fixes other tests => https://github.com/nim-lang/Nim/pull/23660
rework ctypes with gcc 14 => https://github.com/nim-lang/Nim/pull/23636
gcc 14 CI support will come soon when tests pass => https://github.com/nim-lang/Nim/pull/23673
It looks like there may be another similar defect targeting gcc14.2 (Arch again). When recompiling a personal CLI tool that uses the docopt library I am getting a similar error.
This can be reproduced by running the test suite for docopt 0.7.1: :
$ git clone https://github.com/docopt/docopt.nim
$ cd docopt
$ git checkout v0.7.1
$ nimble test
<<<... snip ...>>>
/home/jdb/projects/third-party/docopt.nim/src/docopt.nim: In function ‘_ZN4test12single_matchE3refIN4test24ArgumentcolonObjectType_EE3seqI3refIN4test23PatterncolonObjectType_EEE’:
/home/jdb/projects/third-party/docopt.nim/src/docopt.nim:238:263: error: assignment to ‘tyObject_PatterncolonObjectType___lXfbQ9c5hfGswttAihJ79c2w *’ from incompatible pointer type ‘tyObject_ArgumentcolonObjectType___4WrxrWmB9aqSxzDk2md9cgPg *’ [-Wincompatible-pointer-types]
238 | raise new_exception(ValueError, "Not found")
| ^
/home/jdb/projects/third-party/docopt.nim/src/docopt.nim: In function ‘_ZN4test12single_matchE3refIN4test23CommandcolonObjectType_EE3seqI3refIN4test23PatterncolonObjectType_EEE’:
/home/jdb/projects/third-party/docopt.nim/src/docopt.nim:247:460: error: assignment to ‘tyObject_PatterncolonObjectType___lXfbQ9c5hfGswttAihJ79c2w *’ from incompatible pointer type ‘tyObject_CommandcolonObjectType___vPz31XMzxwUHxxGl9bp7J5Q *’ [-Wincompatible-pointer-types]
247 | raise new_exception(ValueError, "Not found")
| ^
Error: execution of an external compiler program 'gcc -c -w -fmax-errors=3 -pthread -g3 -Og -I/home/jdb/.asdf/installs/nim/2.0.8/lib -I/home/jdb/projects/third-party/docopt.nim/test -o /home/jdb/.cache/nim/test_d/@mtest.nim.c.o /home/jdb/.cache/nim/test_d/@mtest.nim.c' failed with exit code: 1
If I modify the test invocation (shown below) to pass --passC:-fpermissive it compiles successfully and the tests pass.
diff --git a/docopt.nimble b/docopt.nimble
index 5b028b8..5f49379 100644
--- a/docopt.nimble
+++ b/docopt.nimble
@@ -8,6 +8,6 @@ requires "nim >= 0.20.0"
requires "regex >= 0.11.1"
task test, "Test":
- exec "nimble c --verbosity:0 -r -y test/test"
+ exec "nimble c --verbosity:0 -r -y test/test --passC:-fpermissive"
for f in listFiles("examples"):
- if f[^4..^1] == ".nim": exec "nimble compile --verbosity:0 --hints:off " & f
+ if f[^4..^1] == ".nim": exec "nimble compile --verbosity:0 --hints:off --passC:-fpermissive " & fThe relevant lines from docopt (as best I can tell) seem to be:
# lines 85-87
type
MatchResult = tuple[matched: bool; left, collected: seq[Pattern]]
SingleMatchResult = tuple[pos: int, match: Pattern]
# lines 234-238
method single_match(self: Argument, left: seq[Pattern]): SingleMatchResult =
for n, pattern in left:
if pattern.class == "Argument":
return (n, argument(self.name, pattern.value))
raise new_exception(ValueError, "Not found")
# lines 240-247
method single_match(self: Command, left: seq[Pattern]): SingleMatchResult =
for n, pattern in left:
if pattern.class == "Argument":
if pattern.value.kind == vkStr and $pattern.value == self.name:
return (n, command(self.name, val(true)))
else:
break
raise new_exception(ValueError, "Not found")I didn't see any related issues in GitHub. I'm happy to create one.