| Summary: | gcc-4.5.1-4.fc14.x86_64: Broken Binaries | ||
|---|---|---|---|
| Product: | [Fedora] Fedora | Reporter: | Harald Reindl <h.reindl> |
| Component: | gcc | Assignee: | Jakub Jelinek <jakub> |
| Status: | CLOSED NOTABUG | QA Contact: | Fedora Extras Quality Assurance <extras-qa> |
| Severity: | unspecified | Docs Contact: | |
| Priority: | unspecified | ||
| Version: | 14 | CC: | jakub |
| Target Milestone: | --- | ||
| Target Release: | --- | ||
| Hardware: | Unspecified | ||
| OS: | Unspecified | ||
| Whiteboard: | |||
| Fixed In Version: | Doc Type: | Bug Fix | |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2011-03-28 13:14:39 UTC | Type: | --- |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
|
Description
Harald Reindl
2011-03-28 12:29:23 UTC
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 |