Hide Forgot
GCC 4.5 from F14 seems to break some optimizings while the F13 version with the same flags does not resulting in broken binarys optflags: x86_64 -O3 -g -march=core2 -mtune=core2 -fopenmp -mmmx -msse2 -msse3 -msse4 -pipe -fno-delete-null-pointer-checks -fstack-protector -mfpmath=sse -D_FORTIFY_SOURCE=2 rpmbuild --rebuild http://kojipkgs.fedoraproject.org/packages/zlib/1.2.5/2.fc14/src/zlib-1.2.5-2.fc14.src.rpm After that Firefox crashs with a segfault AFAIK other binarys are working well and the reason for me is that we are running a couple of virtual machines in a ESXi-Cluster and all hosts are XEON-Core2-CPUs so mod_deflate and other compressions could use the hardware better as with generic builds ______________________________ if you build httpd on F14 with this settings and "O6" this is no problem on F13, with Fedora 14 httpd works but "ab -c 30 -n 10000 http://testurl/" is giving a segfault at the end after display the results (iilegal opcode) ______________________________ http://www.patrickfrei.ch/webalizer/ segfault if any optimizings are set on F14 while O3 and mtune=core2 on F13 are running well (illegal opcode in this case)
I'm definitely not going to debug random packages just because they fail with some set of compiler flags while they work with others, usually it is just a bug in those packages where they rely on undefined behavior somewhere, like violate aliasing requirements, use uninitialized variables etc. If you suspect a compiler issue, generally you should provide a small self-contained testcase, see also http://gcc.gnu.org/bugs.html for how bugs should be reported. If you have a working set of flags and non-working, you can do a binary search in between objects built with working and non-working flags, narrow it down to at least a single compilation unit, compile that with -Wall -W etc. to get better diagnostics. BTW, if you are running -msse4 compiled code on Core2 CPUs, illegal opcodes are to be expected, SSE4 is only implemented by Nehalem/Westmere/SandyBridge CPUs.
> I'm definitely not going to debug random packages just because > they fail with > some set of compiler flags while they work with others, usually it is just a > bug in those packages where they rely on undefined behavior somewhere, like > violate aliasing requirements, use uninitialized variables etc. in basics i understand, but i notice this problems only with the newer GCC in F14 while F13 on the same machine with same flags does not show any unexoected results > If you suspect a compiler issue, generally you should provide a small > self-contained testcase, see also http://gcc.gnu.org/bugs.html for how bugs > should be reported. If you have a working set of flags and non-working, you > can do a binary search in between objects built with working and non-working > flags, narrow it down to at least a single compilation unit, > compile that with > -Wall -W etc. to get better diagnostics hm - i am enduser (web-developer) so my skills are not enough > BTW, if you are running -msse4 compiled code on Core2 CPUs, > illegal opcodes are > > to be expected, SSE4 is only implemented > by Nehalem/Westmere/SandyBridge CPUs all machines (servers and involved workstations) are supporting SSE4 while the "Q9300" is the oldest cpu in our company model name : Intel(R) Core(TM)2 Quad CPU Q9300 @ 2.50GHz flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx lm constant_tsc arch_perfmon pebs bts rep_good aperfmperf pni dtes64 monitor ds_cpl vmx smx est tm2 ssse3 cx16 xtpr pdcm sse4_1 lahf_lm tpr_shadow vnmi flexpriority model name : Intel(R) Core(TM)2 Duo CPU P8400 @ 2.26GHz flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx lm constant_tsc arch_perfmon pebs bts rep_good aperfmperf pni dtes64 monitor ds_cpl vmx smx est tm2 ssse3 cx16 xtpr pdcm sse4_1 xsave lahf_lm ida tpr_shadow vnmi flexpriority model name : Intel(R) Xeon(R) CPU E5450 @ 3.00GHz flags : fpu vme de pse tsc msr pae mce cx8 apic mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss syscall nx lm constant_tsc up arch_perfmon pebs bts rep_good xtopology tsc_reliable nonstop_tsc aperfmperf pni ssse3 cx16 sse4_1 hypervisor lahf_lm
sse4_1 in /proc/cpuinfo doesn't mean the CPU supports SSE4, it only means it supports SSE4.1. -msse4 means both -msse4.1 and -msse4.2, so you'd need to see both sse4_1 and sse4_2 in /proc/cpuinfo. You should just use -msse4.1 when targetting CPUs that only support SSE4.1.
the crashs with firefox with rebuild zlib are happening on the following cpu too but thank you for the hint for -msse4.1 anyways! Intel(R) Core(TM) i3 CPU M 350 @ 2.27GHz flags: fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall rdtscp lm constant_tsc arch_perfmon pebs bts rep_good xtopology nonstop_tsc aperfmperf pni dtes64 monitor ds_cpl vmx est tm2 ssse3 cx16 xtpr pdcm sse4_1 sse4_2 popcnt lahf_lm arat tpr_shadow vnmi flexpriority ept vpid
would it be possible to push updates to gcc since F14 ships 4.5.1 (2010-09-24) and there are many bugfixes upstream which is on 4.5.3? http://gcc.gnu.org/bugzilla/buglist.cgi?bug_status=RESOLVED&resolution=FIXED&target_milestone=4.5.3