gcc12 build error

[chipitsine]

Tool Name and Version

gcc12

Code Report

gcc -Iinclude  -O2 -g  -Wall -Wextra -Wundef -Wdeclaration-after-statement -Wfatal-errors -Wtype-limits -Wshift-negative-value -Wshift-overflow=2 -Wduplicated-cond -Wnull-dereference -fwrapv -Wno-address-of-packed-member -Wno-unused-label -Wno-sign-compare -Wno-unused-parameter -Wno-clobbered -Wno-missing-field-initializers -Wno-cast-function-type -Wno-string-plus-int -Wno-atomic-alignment -Werror     -DDEBUG_STRICT -DDEBUG_MEMORY_POOLS -DUSE_EPOLL  -DUSE_NETFILTER -DUSE_PCRE -DUSE_PCRE_JIT   -DUSE_POLL -DUSE_THREAD -DUSE_BACKTRACE   -DUSE_TPROXY -DUSE_LINUX_TPROXY -DUSE_LINUX_SPLICE -DUSE_LIBCRYPT -DUSE_CRYPT_H  -DUSE_GETADDRINFO -DUSE_OPENSSL -DUSE_LUA -DUSE_ACCEPT4  -DUSE_ZLIB  -DUSE_CPU_AFFINITY -DUSE_TFO -DUSE_NS -DUSE_DL -DUSE_RT    -DUSE_SYSTEMD  -DUSE_PRCTL  -DUSE_THREAD_DUMP   -DUSE_QUIC    -I/root/opt/include  -DUSE_PCRE -I/usr/include  -DCONFIG_HAPROXY_VERSION=\"2.7-dev1\" -DCONFIG_HAPROXY_DATE=\"2022/06/24\" -c -o src/cache.o src/cache.c
In file included from include/haproxy/api.h:34,
                 from include/haproxy/regex-t.h:28,
                 from include/haproxy/pattern-t.h:28,
                 from include/haproxy/acl-t.h:25,
                 from include/haproxy/acl.h:25,
                 from src/haproxy.c:85:
src/haproxy.c: In function 'run_poll_loop':
include/haproxy/atomic.h:428:39: error: '__atomic_load_8' writing 8 bytes into a region of size 0 overflows the destination [-Werror=stringop-overflow=]
  428 | #define _HA_ATOMIC_LOAD(val)          __atomic_load_n(val, __ATOMIC_RELAXED)
      |                                       ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
src/haproxy.c:2843:45: note: in expansion of macro '_HA_ATOMIC_LOAD'
 2843 |                                         if (_HA_ATOMIC_LOAD(&ha_tgroup_ctx[i].stopping_threads) != ha_tgroup_info[i].threads_enabled)
      |                                             ^~~~~~~~~~~~~~~
compilation terminated due to -Wfatal-errors.
cc1: all warnings being treated as errors
make: *** [Makefile:1034: src/haproxy.o] Error 1
make: *** Waiting for unfinished jobs....

Additional Information

No response

Output of haproxy -vv

no

[wtarreau]

So the compiler seems to do stupid things again, by considering that a loop going from 0 to 1 (excluded) and reading an array of size 1 is writing an array of size zero!!! The apparently offending code is:

	for (i = 0; i < global.nbtgroups; i++)
		if (_HA_ATOMIC_LOAD(&ha_tgroup_ctx[i].stopping_threads) != ha_tgroup_info[i].threads_enabled)
			break;

I mean, ha_tgroup_ctx[] is declared as being of size MAX_TGROUPS=1, so element zero is always valid. It's hard to know what to do here to please it but this is getting seriously annoying if we can't even dereference properly declared and sized arrays now :-(

And as this report made me doubt, I did this to double-check that the array was properly sized:

--- a/include/haproxy/tinfo.h
+++ b/include/haproxy/tinfo.h
@@ -26,6 +26,10 @@
 #include <haproxy/tinfo-t.h>
 
 /* the structs are in thread.c */
+#if MAX_TGROUPS < 1
+#error MAX_TGROUPS not valid
+#endif
+

And it doesn't trigger, so there's not even any doubt at any place where this file is loaded. In fact, it looks so stupidly simple that I have no idea how to modify this to please gcc here!

[chipitsine]

in theory we can add -Wno-error=stringop-overflow (maybe for gcc only ?)

[chipitsine]

I can try to bisect on gcc

[chipitsine]

I'm almost done with gcc bisecting (my low end laptop takes 8-9 hours for each gcc build, one hash left to verify).

@wtarreau , I will open gcc bug and I count on you to help there with details.
however, gcc was very responsive last time, I hope we'll be good there.

[wtarreau]

It's very possible that you will end up on an issue that was already reported one way or another, especially for something that gross, so it's important to look in their issue tracker first and plug onto an existing one with your bisect info once you find one. It may help them figure the impacts of certain choices and see how to refine some such warning options so that they actually emit relevant stuff. Thanks and good luck :-)

[chipitsine]

my kungfu in searching issues in gcc bugzilla is not as strong as bisecting.

from current situation, breaking change was introduced in november 2021, it is still reproduced on master branch, I'm afraid we'll be first reporters.

[chipitsine]

looks like breaking change introduced in http://gcc.gnu.org/git/?p=gcc.git;a=commit;h=88b504b7a8c5affb0ffa97990d22af2b199e36ed

I'm double checking...

[chipitsine]

reported to gcc: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106297

[wtarreau]

Thank you Ilya.

[chipitsine]

the issue is acknowledged on gcc side

[wtarreau]

Thank you Ilya. I had tried on my side to create a smaller and simpler reproducer but I failed, so I think that a bit of complexity is needed to confuse the compiler. In the event I would manage to create a 20-line reproducer, I'd update the bugzilla entry.

[chipitsine]

btw, gcc12 build is green again https://gitlab.com/chipitsine/haproxy-ci-playground/-/jobs/2757118359

surprisingly, I did not expect that before gcc bug is fixed