Note: This is a public test instance of Red Hat Bugzilla. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback at
Bug 771438 - gcc-4.7 ICE on arm hardware floating point
Summary: gcc-4.7 ICE on arm hardware floating point
Alias: None
Product: Fedora
Classification: Fedora
Component: gcc
Version: rawhide
Hardware: Unspecified
OS: Unspecified
Target Milestone: ---
Assignee: Jakub Jelinek
QA Contact: Fedora Extras Quality Assurance
Depends On:
Blocks: ARMTracker
TreeView+ depends on / blocked
Reported: 2012-01-03 19:03 UTC by Dennis Gilmore
Modified: 2012-01-05 13:15 UTC (History)
3 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Last Closed: 2012-01-05 13:15:01 UTC
Type: ---

Attachments (Terms of Use)
.out file (1.04 MB, application/octet-stream)
2012-01-03 19:03 UTC, Dennis Gilmore
no flags Details

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

Description Dennis Gilmore 2012-01-03 19:03:21 UTC
Created attachment 550505 [details]
.out file

Description of problem:

../../gcc/java/class.c:3246:0: internal compiler error: in output_loc_list, at dwarf2out.c:8190
Please submit a full bug report,
with preprocessed source if appropriate.
See <> for instructions.

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

full build log can be found at due to some work going on on the arm buildsys i did local mock builds to test.

Comment 1 Jakub Jelinek 2012-01-03 19:24:22 UTC
Likely dup of

Comment 2 Jakub Jelinek 2012-01-04 11:03:54 UTC
We can always work around this as in (completely untested):

--- gcc/dwarf2out.c	2012-01-03 16:22:48.794866121 +0100
+++ gcc/dwarf2out.c	2012-01-04 11:50:30.516022278 +0100
@@ -8166,6 +8166,13 @@ output_loc_list (dw_loc_list_ref list_he
       /* Don't output an entry that starts and ends at the same address.  */
       if (strcmp (curr->begin, curr->end) == 0 && !curr->force)
+      size = size_of_locs (curr->expr);
+      /* If the expression is too large, drop it on the floor.  We could
+	 perhaps put it into DW_TAG_dwarf_procedure and refer to that
+	 in the expression, but >= 64KB expressions for a single value
+	 in a single range are unlikely very useful.  */
+      if (size > 0xffff)
+	continue;
       if (!have_multiple_function_sections)
 	  dw2_asm_output_delta (DWARF2_ADDR_SIZE, curr->begin, curr->section,
@@ -8184,7 +8191,6 @@ output_loc_list (dw_loc_list_ref list_he
 			       "Location list end address (%s)",
-      size = size_of_locs (curr->expr);
       /* Output the block length for this list of location operations.  */
       gcc_assert (size <= 0xffff);

But it would be nice to a) find out how can we limit the excessive expression sizes still during var-tracking, because it might consume lots of compile time memory b) if we can't do anything smarter at least in cases like PR51695 where the expression is so huge just because it keeps computing the same values again and again and again.  If we remembered we have computed some VALUE (with a non-trivial expression of more than say 16 rtxes in it), we could represent it
as tmpforvalueXXX = the_rtx, and then just use the temporary in all places.
In the DWARF expression it would mean we'd compute (all the temporaries) first
and keep them pushed into the DWARF stack, then once all those are computed we'd just DW_OP_picked the values we want (as many times as needed).
So, e.g. in the pr51695 case, we'd have a temporary for:
(if_then_else:SI (lt (mem/c/i:SI (symbol_ref:DI ("v") [flags 0x2]  <var_decl 0x7 f431dcea140 v>) [2 v+0 S4 A32]) (const_int 0 [0]))
(xor:SI (ashift:SI (mem/c/i:SI (symbol_ref:DI ("v") [flags 0x2]  <var_decl 0x7f431dcea140 v>) [2 v+0 S4 A32]) (const_int 1 [0x1]))
(const_int -1550293667 [0xffffffffa398655d]))
(ashift:SI (mem/c/i:SI (symbol_ref:DI ("v") [flags 0x2]  <var_decl 0x7f431dcea140 v>) [2 v+0 S4 A32]) (const_int 1 [0x1])))
expression and use it in all the places where it is used (in that testcase this is used over 2000 times), then perhaps some larger expression that uses these many times would be again a temporary, etc. and here we could end up with a DWARF expression of only few dozens of bytes.

Comment 3 Jakub Jelinek 2012-01-05 13:15:01 UTC
gcc-4.7.0-0.3.fc17 contains this workaround.

Note You need to log in before you can comment on or make changes to this bug.