Certain method structure cause vweb to not be able to listen anymore

[SunRed]

Describe the bug

The program starts and vweb is seemingly working but no webserver is listening on the port, resulting in the curl error.
Additionally, what should be mentioned, that compilation suddenly takes ~5x as long with the last method included.
So far I could only reproduce it if there are two methods returning a bool, with one having at least one arbitrary argument. This does not occur when using functions instead of struct methods.
This strange behavior was of course observed in a much bigger program but I was able to distill it down to the following code.

Reproduction Steps

module main

import vweb

struct App {
	vweb.Context
}

fn main() {
	vweb.run(&App{}, 8080)
}

[get]
fn (mut app App) index() vweb.Result {
	return app.ok('Hello World')
}

fn (mut app App) bool1() bool {
	return true
}

// If you remove this method, the server is able to listen again
fn (mut app App) bool2(param1 string) bool {
	return true
}

Compile the above code, run the program and request using curl localhost:8080

Expected Behavior

Hello World

Current Behavior

Failed to connect to localhost port 8080 after 1 ms: Couldn't connect to server (Nothing is listening on 8080)

Possible Solution

No response

Additional Information/Context

No response

V version

V 0.4.2 4b03d08

Environment details (OS name and version, etc.)

V full version: V 0.4.2 4b03d08

OS: linux, Linux version 6.1.54-1-lts (linux-lts@archlinux) (gcc (GCC) 13.2.1 20230801, GNU ld (GNU Binutils) 2.41.0) #1 SMP PREEMPT_DYNAMIC Tue, 19 Sep 2023 10:52:23 +0000 (VM)
Processor: 12 cpus, 64bit, little endian, AMD EPYC-Rome Processor

getwd: /home/manuel/vlang-test
vexe: /usr/lib/vlang/v
vexe mtime: 2023-10-04 18:51:15

vroot: NOT writable, value: /usr/lib/vlang
VMODULES: OK, value: /home/manuel/.vmodules
VTMP: OK, value: /tmp/v_1000

Git version: git version 2.42.0
Git vroot status: Error: fatal: not a git repository (or any of the parent directories): .git
.git/config present: false

CC version: cc (GCC) 13.2.1 20230801
thirdparty/tcc status:  N/A

Note

You can vote for this issue using the 👍 reaction. More votes increase the issue's priority for developers.

Take into account that only the 👍 reaction counts as a vote.
Only reactions to the issue itself will be counted as votes, not comments.

[spytheman]

That is extremely weird. Thanks for minimizing it to such a small program.

[SunRed]

A few things I additionally noticed: If you compile it with the -prod flag this issue goes away so this might be an edge case in the unoptimized build with the gcc backend. Also I haven't tested it with the tcc backend yet that could behave differently. Could this be a weird gcc bug?
Also diffing the C output I don't immediately see what could be wrong (and also wouldn't explain the -prod thing anyway). Using gdb to debug the binaries I am not proficient enough to nail down the problem.
Making vweb explicitly listen on ipv4 only using

vweb.run_at(&App{}, vweb.RunParams{
    host: '127.0.0.1'
    port: 8080
    family: .ip
})

instead of both protocols seemingly works.

[spytheman]

Try with 9cb8eac , it should work more consistently now (the listening part).

[SunRed]

Thanks. Sorry I forgot to come back to this. The issue in question seems fixed when I tried it using the latest V 0.4.2 9ec8807 but there is still the weird behavior with the gcc backend that compile time increases significantly with the method structure as posted. It seems some optimisation is triggered since the resulting binary is also vastly smaller compared to not including the last method. But it isn't as small as compiling with the -prod flag.

[SunRed]

Coming back to this once again, the weird gcc backend behavior with this code is fixed with gcc 14.1.1 (current stable release). Tbf, I figured this most likely was a compiler bug but I wanted to leave this issue open in any case.