I'm compiling amanda 2.6.0p1 on Fedora 9 with gcc 4.3.0. I started seeing a
problem where it was trying to connect to port 0 on localhost rather that a
given port number:
connect(3, {sa_family=AF_INET, sin_port=htons(0),
sin_addr=inet_addr("127.0.0.1")}, 16) = -1 ECONNREFUSED (Connection refused)
I've tracked it down to inside the stream_client_internal() function in
stream.c.
Here is some of the source (uses macros - preprocessed source file will be
attached) (lines 227-232)
/* copy the first (preferred) address we found */
copy_sockaddr(&svaddr, res_addr->ai_addr);
SS_SET_PORT(&svaddr, port);
SS_INIT(&claddr, svaddr.ss_family);
SS_SET_INADDR_ANY(&claddr);
client_socket = connect_portrange(&claddr, (in_port_t)portrange[0],
(in_port_t)portrange[1],
"tcp", &svaddr, nonblock);
Basically we copy the information returned from the resolver into svaddr, set
the port, make a matching client claddr structure and connect to it.
Compiled as above with:
gcc -DHAVE_CONFIG_H -I. -I../config -I../gnulib -D_GNU_SOURCE -I/usr/include
-Wextra -Wparentheses -Wdeclaration-after-statement -Wmissing-prototypes
-Wstrict-prototypes -Wmissing-declarations -Wformat -Wsign-compare
-Wfloat-equal -Wold-style-definition -Wno-strict-aliasing -Wno-unknown-pragmas
-O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector
--param=ssp-buffer-size=4 -m32 -march=i386 -mtune=generic
-fasynchronous-unwind-tables -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64
-pthread -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include -c stream.c -fPIC
-DPIC -o .libs/stream.o
it appears that the port value of svaddr is not set so we attempt to connect to
port 0.
If I insert:
dbprintf(_("stream_client: port=%d, svaddr->ss_family=%d,
svaddr->sin_port=%d\n"), port, svaddr.ss_family, ((struct sockaddr_in
*)(&svaddr))->sin_port);
between SS_SET_PORT and SS_INIT, the program runs as expected. So it appears
that by referencing those variables we can fix the compiler.
It also works if compiled and run on with 4.1.2.
Looks like an aliasing issue - works with -fno-strict-aliasing. Now is the
code or gcc wrong? I'm afraid that there is a lot of structure pointer munging
to support multiple platforms. Not sure how to get around that.
--
Summary: Apparent optimization bug, possible regression
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: orion at cora dot nwra dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36360
