Bug 485232 - build qt-4.5-rc1 breaks with internal compiler error
Summary: build qt-4.5-rc1 breaks with internal compiler error
Keywords:
Status: CLOSED RAWHIDE
Alias: None
Product: Fedora
Classification: Fedora
Component: gcc
Version: rawhide
Hardware: powerpc
OS: Linux
medium
medium
Target Milestone: ---
Assignee: Jakub Jelinek
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2009-02-12 15:03 UTC by Than Ngo
Modified: 2009-02-16 12:48 UTC (History)
3 users (show)

Fixed In Version:
Clone Of:
Environment:
Last Closed: 2009-02-16 12:48:32 UTC
Type: ---
Embargoed:

Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
GNU Compiler Collection 39175 0 None None None Never

Description Than Ngo 2009-02-12 15:03:19 UTC 
Description of problem:
build qt-4.5-rc1 breaks with internal compiler error

Version-Release number of selected component (if applicable):
qt-4.5-rc1

How reproducible:
just build qt-4.5-rc1 in rawhide

  
Actual results:
qt build breaks with errors:

cc1plus: note: initialized from here
tools/qstring.cpp: In function 'int qFindString(const QChar*, int, int, const QChar*, int, Qt::CaseSensitivity)':
tools/qstring.cpp:2325: internal compiler error: in output_480, at config/rs6000/rs6000.md:11763
Please submit a full bug report,
with preprocessed source if appropriate.
See <http://bugzilla.redhat.com/bugzilla> for instructions.
{standard input}: Assembler messages:
{standard input}:25512: Error: open CFI at the end of file; missing .cfi_endproc directive


http://koji.fedoraproject.org/koji/taskinfo?taskID=1121585

Expected results:
it should build without any problem

Additional info:
it breaks with the same error with old gcc-4.3. I didn't commit qt-4.5-rc1 in our CVS yet. You can get the qt-4.5 srpm if you want, please ping me on irc.

Thanks
Comment 1 Kevin Kofler 2009-02-13 13:29:30 UTC 
The offending GCC code:

(define_insn "*sibcall_value_nonlocal_sysv<mode>"
  [(set (match_operand 0 "" "")
	(call (mem:SI (match_operand:P 1 "symbol_ref_operand" "s,s"))
	      (match_operand 2 "" "")))
   (use (match_operand:SI 3 "immediate_operand" "O,n"))
   (use (reg:SI LR_REGNO))
   (return)]
  "(DEFAULT_ABI == ABI_DARWIN
       || DEFAULT_ABI == ABI_V4)
   && (INTVAL (operands[3]) & CALL_LONG) == 0"
  "*
{
  if (INTVAL (operands[2]) & CALL_V4_SET_FP_ARGS)
    output_asm_insn (\"crxor 6,6,6\", operands);

  else if (INTVAL (operands[2]) & CALL_V4_CLEAR_FP_ARGS)
    output_asm_insn (\"creqv 6,6,6\", operands);

  if (DEFAULT_ABI == ABI_V4 && flag_pic)
    {
      gcc_assert (!TARGET_SECURE_PLT);
      return \"b %z1@plt\";
    }
  else
    return \"b %z1\";
}"
  [(set_attr "type" "branch,branch")
   (set_attr "length" "4,8")])

We trip on the gcc_assert (!TARGET_SECURE_PLT);.

Could -mbss-plt be used to work around this for now? Or would that break ABI compatibility, SELinux or whatever?
Comment 2 Kevin Kofler 2009-02-13 13:31:49 UTC 
But it looks like Jakub has a GCC patch in the upstream GCC bug report already, so I guess we don't have to waste time with workarounds.
Comment 3 Jakub Jelinek 2009-02-13 13:35:37 UTC 
We use -msecure-plt for security reasons, so using -mbss-plt would be terribly bad idea.  If you want workaround (I'm already building gcc with the patch in koji), just don't nedlessly prototype functions after they have been defined.
Comment 4 Jakub Jelinek 2009-02-16 12:48:32 UTC 
Fixed in gcc-4.4.0-0.18.
Note You need to log in before you can comment on or make changes to this bug.