[Bug target/17180] New: nearly all g77 tests fail on sparc-linux

[Bug target/17180] New: nearly all g77 tests fail on sparc-linux

[debian-gcc at lists dot debian dot org]

seen in various test results, as well as my own builds, i.e.:

failed 20040731: http://gcc.gnu.org/ml/gcc-testresults/2004-08/msg00047.html
failed 20040731: http://gcc.gnu.org/ml/gcc-testresults/2004-08/msg00251.html
failed 20040721: http://gcc.gnu.org/ml/gcc-testresults/2004-07/msg00994.html

ok 20040709: http://gcc.gnu.org/ml/gcc-testresults/2004-07/msg01317.html
ok 3.4.1 release: http://gcc.gnu.org/ml/gcc-testresults/2004-07/msg00786.html
ok 20040710: http://gcc.gnu.org/ml/gcc-testresults/2004-07/msg00632.html

currently no access to a sparc-linux box.

    Matthias

-- 
           Summary: nearly all g77 tests fail on sparc-linux
           Product: gcc
           Version: 3.4.2
            Status: UNCONFIRMED
          Severity: critical
          Priority: P2
         Component: target
        AssignedTo: unassigned at gcc dot gnu dot org
        ReportedBy: debian-gcc at lists dot debian dot org
                CC: gcc-bugs at gcc dot gnu dot org
 GCC build triplet: sparc*-linux
  GCC host triplet: sparc*-linux
GCC target triplet: sparc*-linux


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17180

[Bug target/17180] [3.4 Regression] nearly all g77 tests fail on sparc-linux

[pinskia at gcc dot gnu dot org]

------- Additional Comments From pinskia at gcc dot gnu dot org  2004-08-25 07:16 -------
The only change to the front-end:
2004-07-12  Bud Davis  <bdavis9659@comcast.net>

        * bld.c (ffebld_constant_new_character1, ffebld_constant_new_complex{1,2},
        ffebld_constant_new_hollerith, ffebld_constant_new_integer1,
        ffebld_constant_new_integer{1,2,3,4}_val, ffebld_constant_new_logical1,
        ffebld_constant_new_logical{1,2,3,4}_val, ffebld_constant_new_real{1,2},
        ffebld_constant_new_typeless_ov):
        Fill and use `rlink' and `llink' pointers in _ffebld_ struct.
        * bld.h (struct _ffebld_): remove 'next' pointer, add
        `rlink, llink' pointers; remove `negate' entry.
        * malloc.c (malloc_kill_area_): Adapt for new `mallocArea' pointer.
        (malloc_display_): Adapt.
        (malloc_new_inpool_): Set it.
        (malloc_resize_inpool_): Ditto.


The changes to sparc target:
2004-07-14  Eric Botcazou  <ebotcazou@libertysurf.fr>

        Backport from mainline:
        2004-07-13  Eric Botcazou  <ebotcazou@libertysurf.fr>

        PR target/13926
        * config/sparc/sparc-protos.h (output_ubranch): New prototype.
        * config/sparc/sparc.c (output_ubranch): New function.
        * config/sparc/sparc.md (jump pattern): Use it.
2004-07-17  Eric Botcazou  <ebotcazou@act-europe.fr>

        * libgcc2.c (__enable_execute_stack): New symbol.
        ....

The only change to the middle-end:
2004-07-21  Jakub Jelinek  <jakub@redhat.com>
            Jan Hubicka  <jh@suse.cz>

        PR middle-end/15345
        PR c/16450
        * toplev.c (rest_of_handle_inlining): Set DECL_DEFER_OUTPUT on C
        nested functions as well.
        * tree-optimize.c (tree_rest_of_compilation): Don't clear decl rtls
        for deferred nested inlines.

The rest were changes to someother part of the compiler which should not be able to 

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
            Summary|nearly all g77 tests fail on|[3.4 Regression] nearly all
                   |sparc-linux                 |g77 tests fail on sparc-
                   |                            |linux
   Target Milestone|---                         |3.4.2


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17180

[Bug target/17180] [3.4 Regression] nearly all g77 tests fail on sparc-linux

[mmitchel at gcc dot gnu dot org]

------- Additional Comments From mmitchel at gcc dot gnu dot org  2004-08-29 19:09 -------
Postponed until GCC 3.4.3.

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|3.4.2                       |3.4.3


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17180

[Bug target/17180] [3.4 Regression] nearly all g77 tests fail on sparc-linux

[ebotcazou at gcc dot gnu dot org]

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |ebotcazou at gcc dot gnu dot
                   |                            |org


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17180

[Bug target/17180] [3.4 Regression] nearly all g77 tests fail on sparc-linux

[ebotcazou at gcc dot gnu dot org]

------- Additional Comments From ebotcazou at gcc dot gnu dot org  2004-08-31 04:23 -------
Confirmed on SPARC/Solaris 32-bit too.

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |NEW
     Ever Confirmed|                            |1
   Last reconfirmed|0000-00-00 00:00:00         |2004-08-31 04:23:05
               date|                            |


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17180

[Bug target/17180] [3.4 Regression] nearly all g77 tests fail

[ebotcazou at gcc dot gnu dot org]

------- Additional Comments From ebotcazou at gcc dot gnu dot org  2004-08-31 04:24 -------
Investigating.


-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|ebotcazou at gcc dot gnu dot|
                   |org                         |
         AssignedTo|unassigned at gcc dot gnu   |ebotcazou at gcc dot gnu dot
                   |dot org                     |org
             Status|NEW                         |ASSIGNED
  GCC build triplet|sparc*-linux                |sparc-*-*
   GCC host triplet|sparc*-linux                |sparc-*-*
 GCC target triplet|sparc*-linux                |sparc-*-*
            Summary|[3.4 Regression] nearly all |[3.4 Regression] nearly all
                   |g77 tests fail on sparc-    |g77 tests fail
                   |linux                       |


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17180

[Bug target/17180] [3.4 Regression] nearly all g77 tests fail

[ebotcazou at gcc dot gnu dot org]

------- Additional Comments From ebotcazou at gcc dot gnu dot org  2004-08-31 05:00 -------
Mark, this PR is a showstopper on SPARC/Solaris 32-bit.  I'm working on it and I
respectfully request you not to release 3.4.2 until after it is resolved.  Thanks.


-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |mark at codesourcery dot com


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17180

[Bug target/17180] [3.4 Regression] nearly all g77 tests fail

[mark at codesourcery dot com]

------- Additional Comments From mark at codesourcery dot com  2004-08-31 05:11 -------
Subject: Re:  [3.4 Regression] nearly all g77 tests fail

ebotcazou at gcc dot gnu dot org wrote:

>------- Additional Comments From ebotcazou at gcc dot gnu dot org  2004-08-31 05:00 -------
>Mark, this PR is a showstopper on SPARC/Solaris 32-bit.  I'm working on it and I
>respectfully request you not to release 3.4.2 until after it is resolved.  Thanks.
>  
>
When can we expect a fix?

Thanks,



-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17180

[Bug target/17180] [3.4 Regression] nearly all g77 tests fail

[ebotcazou at gcc dot gnu dot org]

------- Additional Comments From ebotcazou at gcc dot gnu dot org  2004-08-31 05:32 -------
> When can we expect a fix?

Hopefully today.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17180

[Bug target/17180] [3.4 Regression] nearly all g77 tests fail

[ebotcazou at gcc dot gnu dot org]

------- Additional Comments From ebotcazou at gcc dot gnu dot org  2004-08-31 05:47 -------
The problem was introduced/exposed by Bud's patch.

Bud, can you point at the message/discussion on gcc-patches (I failed to find
it) and/or comment upon the patch?  Thanks in advance.


-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |bdavis9659 at comcast dot
                   |                            |net


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17180

[Bug target/17180] [3.4 Regression] nearly all g77 tests fail

[pinskia at gcc dot gnu dot org]

------- Additional Comments From pinskia at gcc dot gnu dot org  2004-08-31 05:53 -------
http://gcc.gnu.org/ml/gcc-patches/2004-07/msg01136.html
That was easy to find.... (using google).

-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17180

[Bug target/17180] [3.4 Regression] nearly all g77 tests fail

[ebotcazou at gcc dot gnu dot org]

------- Additional Comments From ebotcazou at gcc dot gnu dot org  2004-08-31 06:36 -------
> http://gcc.gnu.org/ml/gcc-patches/2004-07/msg01136.html
> That was easy to find.... (using google).

You're the best :-)  I was desperately searching my mailbox with "davis"...

Anyway, I think the patch is flawed because it does pointer frobbing here:

@@ -388,6 +377,7 @@ malloc_new_inpool_ (mallocPool pool, mal
   void *ptr;
   mallocArea_ a;
   unsigned short i;
+  mallocArea_ *temp;
 
   if (pool == NULL)
     pool = malloc_pool_image ();
@@ -397,11 +387,14 @@ malloc_new_inpool_ (mallocPool pool, mal
 	  || malloc_pool_find_ (pool, malloc_pool_image ()));
 #endif
 
-  ptr = malloc_new_ (s + (i = (MALLOC_DEBUG ? strlen (name) + 1 : 0)));
+  ptr = malloc_new_ (sizeof(mallocArea_*) + s + (i = (MALLOC_DEBUG ? strlen
(name) + 1 : 0)));
 #if MALLOC_DEBUG
   strcpy (((char *) (ptr)) + s, name);
 #endif
   a = malloc_new_ (offsetof (struct _malloc_area_, name) + i);
+  temp = (mallocArea_ *) ptr;
+  *temp = a; 
+  ptr = ptr + sizeof(mallocArea_*);
   switch (type)
     {				/* A little optimization to speed up killing
 				   of non-permanent stuff. */


What happens is that we allocate a new 'ffesymbol' in symbol.c:ffesymbol_new_:

  ffesymbol s;

  s = malloc_new_ks (FFESYMBOL_SPACE_POOL_, "FFESYMBOL", sizeof (*s));


The structure 'ffesymbol' contains the field 'accretes' whose type is defined as
'ffetargetOffset', which is actually 64-bit 'long long' on SPARC.  So the
structure gets 8-byte alignment (BIGGEST_ALIGNMENT is 64). When the system
malloc is invoked, it returns a 8-byte aligned address; but then

ptr = ptr + sizeof(mallocArea_*);

destroys the alignment (ptr==0x439cdc) and the compiler dies because it is
trying to do a 8-byte store to an unaligned address (ptr + 0x48).


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17180

[Bug target/17180] [3.4 Regression] nearly all g77 tests fail

[bdavis at gcc dot gnu dot org]

------- Additional Comments From bdavis at gcc dot gnu dot org  2004-08-31 09:31 -------
i don't know how to ensure that the result stays on a 64 bit boundary:

ptr = ptr + sizeof(mallocArea_*);

other than to make the offset 64 bits for everyone.

if desired, i can test this out on i686/gnu/linux ?




--bud davis





-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17180

[Bug target/17180] [3.4 Regression] nearly all g77 tests fail

[ebotcazou at gcc dot gnu dot org]

------- Additional Comments From ebotcazou at gcc dot gnu dot org  2004-08-31 10:35 -------
> i don't know how to ensure that the result stays on a 64 bit boundary:
> 
> ptr = ptr + sizeof(mallocArea_*);
> 
> other than to make the offset 64 bits for everyone.

I think the correct approach is to round to a BIGGEST_ALIGNMENT boundary.  I'm
testing the patch on x86 and SPARC32/64.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17180

[Bug target/17180] [3.4 Regression] nearly all g77 tests fail

[bdavis9659 at comcast dot net]

------- Additional Comments From bdavis9659 at comcast dot net  2004-08-31 10:39 -------
Subject: Re:  [3.4 Regression] nearly all g77 tests fail

On Tue, 2004-08-31 at 01:37, ebotcazou at gcc dot gnu dot org wrote:
 
> 
> What happens is that we allocate a new 'ffesymbol' in symbol.c:ffesymbol_new_:
> 
>   ffesymbol s;
> 
>   s = malloc_new_ks (FFESYMBOL_SPACE_POOL_, "FFESYMBOL", sizeof (*s));
> 
> 
> The structure 'ffesymbol' contains the field 'accretes' whose type is defined as
> 'ffetargetOffset', which is actually 64-bit 'long long' on SPARC.  So the
> structure gets 8-byte alignment (BIGGEST_ALIGNMENT is 64). When the system
> malloc is invoked, it returns a 8-byte aligned address; but then
> 
> ptr = ptr + sizeof(mallocArea_*);
> 
> destroys the alignment (ptr==0x439cdc) and the compiler dies because it is
> trying to do a 8-byte store to an unaligned address (ptr + 0x48).



my intention was that sizeof(mallocArea_*) was the size of a pointer to
mallocArea, so it should be either 4 or 8 depending on the system, which
IMHO should have worked...it is obvious there is something going on here
which i do not understand (not an uncommon occurrence :)

the changes to malloc.c and malloc.h are independent to the other files
in the patch.   they can be reverted and the original focus of the patch
(slow compilation of block data) is still intact.  


some info that may help debugging:

profiling showed that malloc_find_inpool was the biggest cpu consumer
while compiling large fortran files.  the intent was to store a pointer
to the mallocArea at the beginning of every memory block, thus a
malloc_find_inpool would not have to search a list, just return a
pointer.  this implementation meant that the using routines did not
receive the malloc'd pointer, but ptr + sizeof(mallocArea*).



--bud davis



-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17180

[Bug target/17180] [3.4 Regression] nearly all g77 tests fail

[ebotcazou at gcc dot gnu dot org]

------- Additional Comments From ebotcazou at gcc dot gnu dot org  2004-08-31 17:27 -------
> You're replacing both sizeof(mallocArea_) and sizeof(mallocArea_*) with 
> a size based on sizeof(mallocArea_*) roundup up to the byte-version of 
> BIGGEST_ALIGNMENT.  OK, I ssee that mallocArea is itself a pointer, so 
> in both cases the sizes you're replacing are the same.  In any case, it 
> looks as though this patch is safe; at worst, we allocate some more memory.

Wait a minute...  I didn't see that the original code (that is Bud's patch)
contains a mix of sizeof(mallocArea_) and sizeof(mallocArea_*).  This looks
bogus to me, especially:

@@ -388,6 +377,7 @@ malloc_new_inpool_ (mallocPool pool, mal
   void *ptr;
   mallocArea_ a;
   unsigned short i;
+  mallocArea_ *temp;
 
   if (pool == NULL)
     pool = malloc_pool_image ();
@@ -397,11 +387,14 @@ malloc_new_inpool_ (mallocPool pool, mal
 	  || malloc_pool_find_ (pool, malloc_pool_image ()));
 #endif
 
-  ptr = malloc_new_ (s + (i = (MALLOC_DEBUG ? strlen (name) + 1 : 0)));
+  ptr = malloc_new_ (sizeof(mallocArea_*) + s + (i = (MALLOC_DEBUG ? strlen
(name) + 1 : 0)));
 #if MALLOC_DEBUG
   strcpy (((char *) (ptr)) + s, name);
 #endif
   a = malloc_new_ (offsetof (struct _malloc_area_, name) + i);
+  temp = (mallocArea_ *) ptr;
+  *temp = a; 
+  ptr = ptr + sizeof(mallocArea_*);
   switch (type)
     {				/* A little optimization to speed up killing
 				   of non-permanent stuff. */

and happens to work only by accident.  Could you enlighten us, Bud?


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17180

[Bug target/17180] [3.4 Regression] nearly all g77 tests fail

[bdavis at gcc dot gnu dot org]

------- Additional Comments From bdavis at gcc dot gnu dot org  2004-09-01 01:15 -------
there is a mistake on line 308 of malloc.c:

diff -r1.12.14.1 malloc.c
308c308
<   t = (mallocArea_ *) (ptr - sizeof(mallocArea_));
---
>   t = (mallocArea_ *) (ptr - sizeof(mallocArea_ *));

i should have always used sizeof(mallocArea_ *). since mallocArea_ and
mallocArea_* are the same size, this error is not fatal. (i just printed 
them out on linux/i686/gnu and they are both = 4)

the code snippet in question, which i think is:

+  temp = (mallocArea_ *) ptr;
+  *temp = a; 
+  ptr = ptr + sizeof(mallocArea_*);

could be better expressed like this:

  *(mallocArea_ *)ptr = a;
  ptr = ptr + sizeof(mallocArea_*)

*ptr then points to the mallocArea a, after which ptr must be incremented to
point to the remaining allocated memory.

below is a diff with just those two changes, which has been tested on 
i686/gnu/linux. 

[bdavis@localhost f]$ cvs diff malloc.c
Index: malloc.c
===================================================================
RCS file: /cvs/gcc/gcc/gcc/f/Attic/malloc.c,v
retrieving revision 1.12.14.1
diff -r1.12.14.1 malloc.c
308c308
<   t = (mallocArea_ *) (ptr - sizeof(mallocArea_));
---
>   t = (mallocArea_ *) (ptr - sizeof(mallocArea_ *));
380d379
<   mallocArea_ *temp;
395,396c394
<   temp = (mallocArea_ *) ptr;
<   *temp = a;
---
>   *(mallocArea_ *)ptr = a;


with the above correction(s), i think it is OK.  

if you have any other problems, or need me to re-work this
in any way, i will work it with the highest priority. i understand
this is holding up gcc-3.4.2


--bud 

 






-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17180

[Bug target/17180] [3.4 Regression] nearly all g77 tests fail

[ebotcazou at gcc dot gnu dot org]

------- Additional Comments From ebotcazou at gcc dot gnu dot org  2004-09-01 05:10 -------
> i should have always used sizeof(mallocArea_ *). since mallocArea_ and
> mallocArea_* are the same size, this error is not fatal. (i just printed 
> them out on linux/i686/gnu and they are both = 4)
> 
> the code snippet in question, which i think is:
> 
> +  temp = (mallocArea_ *) ptr;
> +  *temp = a; 
> +  ptr = ptr + sizeof(mallocArea_*);
> 
> could be better expressed like this:
> 
>   *(mallocArea_ *)ptr = a;
>   ptr = ptr + sizeof(mallocArea_*)
> 
> *ptr then points to the mallocArea a, after which ptr must be incremented to
> point to the remaining allocated memory.

I don't understand.  The line:

*(mallocArea_ *)ptr = a;

means that you're writing a mallocArea at the address pointed to by ptr.  So you
need to skip that area, which is expressed with:

ptr = ptr + sizeof(mallocArea_);


More generally, the size of the pointer doesn't matter here, only the size of
mallocArea_ is of interest since that's what you write ahead of the chunk of
memory you return.  So I think the correct version is to use sizeof(mallocArea_)
everywhere.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17180

[Bug target/17180] [3.4 Regression] nearly all g77 tests fail

[mmitchel at gcc dot gnu dot org]

------- Additional Comments From mmitchel at gcc dot gnu dot org  2004-09-01 06:03 -------
This patch is OK for 3.4.2.

-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17180

[Bug fortran/17180] [3.4 Regression] nearly all g77 tests fail

[cvs-commit at gcc dot gnu dot org]

------- Additional Comments From cvs-commit at gcc dot gnu dot org  2004-09-01 07:23 -------
Subject: Bug 17180

CVSROOT:	/cvs/gcc
Module name:	gcc
Branch: 	gcc-3_4-branch
Changes by:	ebotcazou@gcc.gnu.org	2004-09-01 07:23:12

Modified files:
	gcc/f          : ChangeLog malloc.c 

Log message:
	PR fortran/17180
	* malloc.c (MALLOC_ALIGNMENT): New constant.
	(ROUNDED_AREA_SIZE): Likewise.
	(malloc_kill_area_): Use ROUNDED_AREA_SIZE.
	(malloc_find_inpool_): Likewise.
	(malloc_new_inpool_): Likewise.
	(malloc_resize_inpool_): Likewise.

Patches:
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/f/ChangeLog.diff?cvsroot=gcc&only_with_tag=gcc-3_4-branch&r1=1.622.2.16&r2=1.622.2.17
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/f/malloc.c.diff?cvsroot=gcc&only_with_tag=gcc-3_4-branch&r1=1.12.14.1&r2=1.12.14.2



-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17180

[Bug fortran/17180] [3.4 Regression] nearly all g77 tests fail

[ebotcazou at gcc dot gnu dot org]

------- Additional Comments From ebotcazou at gcc dot gnu dot org  2004-09-01 07:25 -------
Patch #2 applied.


-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|ASSIGNED                    |RESOLVED
         Resolution|                            |FIXED


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17180

[Bug fortran/17180] [3.4 Regression] nearly all g77 tests fail

[ebotcazou at gcc dot gnu dot org]

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|3.4.3                       |3.4.2


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17180

[Bug fortran/17180] [3.4 Regression] nearly all g77 tests fail

[ebotcazou at gcc dot gnu dot org]

------- Additional Comments From ebotcazou at gcc dot gnu dot org  2004-09-02 06:08 -------
I think the patch is not really correct because the pool is used on the host,
not on the target.  We probably need something like:

struct max_alignment {
  char c;
  union {
    HOST_WIDEST_INT i;
#ifdef HAVE_LONG_DOUBLE
    long double d;
#else
    double d;
#endif
  } u;

#define MAX_ALIGNMENT (offsetof (struct max_alignment, u))


-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|RESOLVED                    |REOPENED
         Resolution|FIXED                       |


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17180

[Bug fortran/17180] [3.4 Regression] nearly all g77 tests fail

[mark at codesourcery dot com]

------- Additional Comments From mark at codesourcery dot com  2004-09-02 07:48 -------
Subject: Re:  [3.4 Regression] nearly all g77 tests fail

ebotcazou at gcc dot gnu dot org wrote:

>------- Additional Comments From ebotcazou at gcc dot gnu dot org  2004-09-02 06:08 -------
>I think the patch is not really correct because the pool is used on the host,
>not on the target.  We probably need something like:
>
>struct max_alignment {
>  char c;
>  union {
>    HOST_WIDEST_INT i;
>#ifdef HAVE_LONG_DOUBLE
>    long double d;
>#else
>    double d;
>#endif
>  } u;
>
>#define MAX_ALIGNMENT (offsetof (struct max_alignment, u))
>  
>
Yes, that makes sense to me.



-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17180

[Bug fortran/17180] [3.4 Regression] nearly all g77 tests fail

[cvs-commit at gcc dot gnu dot org]

------- Additional Comments From cvs-commit at gcc dot gnu dot org  2004-09-02 16:04 -------
Subject: Bug 17180

CVSROOT:	/cvs/gcc
Module name:	gcc
Branch: 	gcc-3_4-branch
Changes by:	ebotcazou@gcc.gnu.org	2004-09-02 16:04:44

Modified files:
	gcc/f          : ChangeLog malloc.c 

Log message:
	PR fortran/17180
	* malloc.c (MALLOC_ALIGNMENT): Rename into MAX_ALIGNMENT
	and use a host-based heuristics to determine it.
	(ROUNDED_AREA_SIZE): Adjust.

Patches:
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/f/ChangeLog.diff?cvsroot=gcc&only_with_tag=gcc-3_4-branch&r1=1.622.2.17&r2=1.622.2.18
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/f/malloc.c.diff?cvsroot=gcc&only_with_tag=gcc-3_4-branch&r1=1.12.14.2&r2=1.12.14.3



-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17180

[Bug fortran/17180] [3.4 Regression] nearly all g77 tests fail

[ebotcazou at gcc dot gnu dot org]

------- Additional Comments From ebotcazou at gcc dot gnu dot org  2004-09-02 16:06 -------
Hopefully correctly fixed this time.


-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|REOPENED                    |RESOLVED
         Resolution|                            |FIXED


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17180