Bug 529512

Summary: internal compiler error when building EMBOSS
Product: [Fedora] Fedora Reporter: Julian Sikorski <belegdol>
Component: gccAssignee: Jakub Jelinek <jakub>
Status: CLOSED RAWHIDE QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: medium Docs Contact:
Priority: low    
Version: rawhideCC: jakub
Target Milestone: ---   
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2009-10-19 08:52:38 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Bug Depends On:    
Bug Blocks: 496133    
Attachments:
Description Flags
preprocessed source none

Description Julian Sikorski 2009-10-17 23:29:51 UTC 
Created attachment 365144 [details]
preprocessed source

Description of problem:
When trying to build the newly imported EMBOSS on devel and F-12, the build process fails with an internal compiler error:

ajutil.c: In function 'ajByteRevLen2':
ajutil.c:311: internal compiler error: in simplify_subreg, at simplify-rtx.c:5063

The full build logs are available from koji.
F-12: http://koji.fedoraproject.org/koji/getfile?taskID=1752269&name=build.log
devel: http://koji.fedoraproject.org/koji/getfile?taskID=1752263&name=build.log

Preprocessed source is attached.

Version-Release number of selected component (if applicable):
4.4.1-20.fc12

How reproducible:
always

Steps to Reproduce:
1. Try to rebuild EMBOSS-6.1.0-5 on F-12 or devel
  
Actual results:
Build fails

Expected results:
Build works

Additional info:
Please let me know if you need anything else.
Comment 1 Jakub Jelinek 2009-10-19 08:52:38 UTC 
Strictly speaking, the code triggers undefined behavior when cd moves before revdata.chars in ajByteRevShort, pointer arithmetics is only valid within the object and after the last byte in it (in the latter case can't be dereferenced though).

That said, gcc shouldn't ICE on it anyway and I've fixed this in gcc-4.4.2-4.fc12.