Bug 485232 - build qt-4.5-rc1 breaks with internal compiler error
build qt-4.5-rc1 breaks with internal compiler error
Product: Fedora
Classification: Fedora
Component: gcc (Show other bugs)
powerpc Linux
medium Severity medium
: ---
: ---
Assigned To: Jakub Jelinek
Fedora Extras Quality Assurance
Depends On:
  Show dependency treegraph
Reported: 2009-02-12 10:03 EST by Ngo Than
Modified: 2009-02-16 07:48 EST (History)
3 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2009-02-16 07:48:32 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

External Trackers
Tracker ID Priority Status Summary Last Updated
GNU Compiler Collection 39175 None None None Never

  None (edit)
Description Ngo Than 2009-02-12 10:03:19 EST
Description of problem:
build qt-4.5-rc1 breaks with internal compiler error

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

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


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.

Comment 1 Kevin Kofler 2009-02-13 08:29:30 EST
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))
       || 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\";
    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 08:31:49 EST
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 08:35:37 EST
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 07:48:32 EST
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.