Bug 11476 - [3.4 only] [arc-elf] gcc ICE on newlib's vfprintf.c
Summary: [3.4 only] [arc-elf] gcc ICE on newlib's vfprintf.c
Alias: None
Product: gcc
Classification: Unclassified
Component: target (show other bugs)
Version: 3.4.0
: P2 normal
Target Milestone: 3.4.3
Assignee: Not yet assigned to anyone
Keywords: ice-on-valid-code
: 17240 (view as bug list)
Depends on:
Reported: 2003-07-09 14:55 UTC by Dara Hazeghi
Modified: 2004-09-11 21:19 UTC (History)
2 users (show)

See Also:
Target: arc-elf32
Known to work:
Known to fail:
Last reconfirmed: 2003-12-02 18:32:20

testcase from newlib (10.04 KB, application/octet-stream)
2003-07-09 14:56 UTC, Dara Hazeghi

Note You need to log in before you can comment on or make changes to this bug.
Description Dara Hazeghi 2003-07-09 14:55:17 UTC
With gcc mainline (20030707) and the patch for 11043, when building a combined tree for arc-
elf32, I get:

Making all in stdio
make[4]: Entering directory `/home/dara/mainline/objdir/arc-elf32/newlib/libc/stdio'
/home/dara/mainline/objdir/gcc/xgcc -B/home/dara/mainline/objdir/gcc/ -nostdinc -B/home/
dara/mainline/objdir/arc-elf32/newlib/ -isystem /home/dara/mainline/objdir/arc-elf32/newlib/
targ-include -isystem /home/dara/mainline/src/newlib/libc/include -B/usr/local/arc-elf32/arc-
elf32/bin/ -B/usr/local/arc-elf32/arc-elf32/lib/ -isystem /usr/local/arc-elf32/arc-elf32/include 
-isystem /usr/local/arc-elf32/arc-elf32/sys-include -L/home/dara/mainline/objdir/ld -
DPACKAGE=\"newlib\" -DVERSION=\"1.11.0\"  -I. -I../../../../../src/newlib/libc/stdio  -O2 -fno-
builtin    -O2 -g -O2  -O2 -O2 -save-temps -fshort-enums -c ../../../../../src/newlib/libc/stdio/
../../../../../src/newlib/libc/stdio/vfprintf.c: In function `_vfprintf_r':
../../../../../src/newlib/libc/stdio/vfprintf.c:767: internal compiler error: in build, at tree.c:2378
Please submit a full bug report,
with preprocessed source if appropriate.
See <URL:http://gcc.gnu.org/bugs.html> for instructions.
make[4]: *** [vfprintf.o] Error 1
make[4]: Leaving directory `/home/dara/mainline/objdir/arc-elf32/newlib/libc/stdio'

Testcase also failes with -O0.
Comment 1 Dara Hazeghi 2003-07-09 14:56:21 UTC
Created attachment 4369 [details]
testcase from newlib
Comment 2 Andrew Pinski 2003-07-09 16:05:05 UTC
I can confirm this on the mainline (20030709):
Here is the simplified case:
typedef __builtin_va_list __gnuc_va_list;
typedef __gnuc_va_list va_list;

_vfprintf_r(int i , va_list ap)
 __builtin_va_arg(ap,long double);
Comment 3 Nathanael C. Nerode 2003-07-09 22:29:03 UTC
Suspending until ARC gets a maintainer.
Comment 4 Dara Hazeghi 2003-08-21 18:32:54 UTC
FWIW it's still present on mainline (20030821).
Comment 5 Andrew Pinski 2003-08-21 18:36:27 UTC
I think the problem is that the "long double" type is 0 aka not defined as something or arc does 
not support "long double" in __builtin_va_arg yet.
Comment 6 Andrew Pinski 2003-08-21 18:48:25 UTC
This should be suspended still.
Comment 7 Rich D'Addio 2004-02-05 21:23:40 UTC
This is caused by a lack of long double support.

Also anything else that requires floating point support will
probably fail as well, since soft-float is not support either.
Comment 8 Andrew Pinski 2004-08-31 03:36:41 UTC
*** Bug 17240 has been marked as a duplicate of this bug. ***
Comment 9 Ramana Radhakrishnan 2004-09-04 10:39:03 UTC
In continuation with this bug, we figured out that there were a few calls to
build with unary operators without side effects. The exact place in tree.c where
this fails had the following comment . 

--- tree.c 
  /* The only one-operand cases we handle here are those with side-effects.
	 Others are handled with build1.  So don't bother checked if the
	 arg has side-effects since we'll already have set it.

	 ??? This really should use build1 too.  */
      if (TREE_CODE_CLASS (code) != 's')
	abort ();

In the case for all these aborts the nodes being passed were unary operators,
for example (INDIRECT_REF which has a code of 'r' ) which is not a side effect
unary node. 

The following patch fixes this .

2004-09-04 Ramana Radhakrishnan <ramana.radhakrishnan@codito.com>

PR/ 11476

  * Fix calls to build for unary operators without sideeffects for ARC. 

--- arc.c.orig  2004-09-04 16:00:15.000000000 +0530
+++ arc.c       2004-09-04 16:00:42.000000000 +0530
@@ -2284,8 +2284,8 @@
       tree type_ptr_ptr = build_pointer_type (type_ptr);

-      addr = build (INDIRECT_REF, type_ptr,
-                   build (NOP_EXPR, type_ptr_ptr, valist));
+      addr = build1 (INDIRECT_REF, type_ptr,
+                   build1 (NOP_EXPR, type_ptr_ptr, valist));

       incr = build (PLUS_EXPR, TREE_TYPE (valist),
                    valist, build_int_2 (UNITS_PER_WORD, 0));
@@ -2305,12 +2305,12 @@
          /* AP = (TYPE *)(((int)AP + 7) & -8)  */

-         addr = build (NOP_EXPR, integer_type_node, valist);
+         addr = build1 (NOP_EXPR, integer_type_node, valist);
          addr = fold (build (PLUS_EXPR, integer_type_node, addr,
                              build_int_2 (7, 0)));
          addr = fold (build (BIT_AND_EXPR, integer_type_node, addr,
                              build_int_2 (-8, 0)));
-         addr = fold (build (NOP_EXPR, TREE_TYPE (valist), addr));
+         addr = fold (build1 (NOP_EXPR, TREE_TYPE (valist), addr));

       /* The increment is always rounded_size past the aligned pointer.  */

and continues with the build.

Comment 10 Andrew Pinski 2004-09-07 07:39:04 UTC
I should note that is only for 3.4 as 3.5 changes how fold works and now build1 is really called when 
build is called with one parameter.
Comment 11 CVS Commits 2004-09-11 21:15:30 UTC
Subject: Bug 11476

CVSROOT:	/cvs/gcc
Module name:	gcc
Branch: 	gcc-3_4-branch
Changes by:	pinskia@gcc.gnu.org	2004-09-11 21:15:21

Modified files:
	gcc            : ChangeLog 
	gcc/config/arc : arc.c 

Log message:
	2004-09-11  Ramana Radhakrishnan <ramana.radhakrishnan@codito.com>
	PR target/11476
	* gcc/config/arc/arc.c (arc_va_args): Call build1 instead
	of build for unary tree operators.


Comment 12 Andrew Pinski 2004-09-11 21:19:01 UTC
Fixed.  I should note this does not need fixing on the mainline because of the change in build and that 
the code which did this was removed.