Bug 19411 - Simple program causes gcc to run out of memory
Summary: Simple program causes gcc to run out of memory
Status: RESOLVED FIXED
Alias: None
Product: gcc
Classification: Unclassified
Component: target (show other bugs)
Version: 3.4.3
: P3 normal
Target Milestone: 4.1.0
Assignee: Not yet assigned to anyone
URL:
Keywords: memory-hog
: 19821 21758 23759 (view as bug list)
Depends on:
Blocks:
 
Reported: 2005-01-12 22:55 UTC by athena
Modified: 2024-07-25 07:43 UTC (History)
5 users (show)

See Also:
Host: powerpc-unknown-linux-gnu
Target: powerpc-unknown-linux-gnu
Build: powerpc-unknown-linux-gnu
Known to work:
Known to fail: 4.0.0
Last reconfirmed: 2005-02-07 06:58:47

Attachments
Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this bug.
Description athena 2005-01-12 22:55:00 UTC 

A simple program causes gcc to use inordinate amounts of memory
and finally crash.

Environment:
System: Linux glauke 2.6.8-powerpc #1 Sun Oct 3 13:22:21 CEST 2004 ppc GNU/Linux
Architecture: ppc

host: powerpc-unknown-linux-gnu
build: powerpc-unknown-linux-gnu
target: powerpc-unknown-linux-gnu
configured with: ../src/configure -v --enable-languages=c,c++,java,f77,pascal,objc,ada --prefix=/usr --libexecdir=/usr/lib --with-gxx-include-dir=/usr/include/c++/3.4 --enable-shared --with-system-zlib --enable-nls --without-included-gettext --program-suffix=-3.4 --enable-__cxa_atexit --enable-libstdcxx-allocator=mt --enable-clocale=gnu --enable-libstdcxx-debug --enable-java-gc=boehm --enable-java-awt=gtk --disable-multilib --disable-softfloat powerpc-linux

How-To-Repeat:

Compile this program as follows:

  gcc-3.4 -maltivec prog.c

prog.c follows:

#include <altivec.h>

vector float foo(vector float a)
{
     return vec_add(a, 
		    vec_add(a, 
			    vec_add(a, 
				    vec_add(a, a))));
}
Comment 1 athena 2005-01-12 22:55:00 UTC 
Fix:

Declare explicit temporary variables for the intermediate results.
Comment 2 Andrew Pinski 2005-01-12 23:07:37 UTC 
This is the preprocessor f'ing up.  The macros are complex which cause the problem, I might be able 
get a self contained example later on.
Comment 3 Alan Modra 2005-02-07 06:58:47 UTC 
I wouldn't blame the preprocessor.  The macros in altivec.h for C support have
multiple occurences of their arguments.  __builtin_choose_expr only evaluates
one occurence, but that doesn't stop the preprocessor *substituting* the macro
args multiple times.
  vec_add (a, a) expands to 8006 chars,
  vec_add (a, vec_add (a, a)) expands to 321430
  vec_add (1, vec_add (a, vec_add (a, a))) expands to 12231542
and I didn't even try four levels.

Perhaps this comment in altivec.h explains it..
/* "... and so I think no man in a century will suffer as greatly as
   you will."  */
Comment 4 Andrew Pinski 2005-02-08 13:27:48 UTC 
*** Bug 19821 has been marked as a duplicate of this bug. ***
Comment 5 Alan Modra 2005-02-16 01:03:02 UTC 
Changing to target since this is due to Aldy's altivec.h implementation.
Comment 6 Andrew Pinski 2005-05-06 06:22:29 UTC 
Fixed in 4.1.0 and above by:
2005-05-02  Paolo Bonzini  <bonzini@gnu.org>

        * c-common.c (resolve_overloaded_builtin): Forward to target
        hook for BUILT_IN_MD built-ins.
....
Comment 7 Andrew Pinski 2005-05-25 22:14:47 UTC 
*** Bug 21758 has been marked as a duplicate of this bug. ***
Comment 8 Andrew Pinski 2005-09-07 00:25:01 UTC 
*** Bug 23759 has been marked as a duplicate of this bug. ***