[Bug tree-optimization/36630] [4.3/4.4 Regression] ICE in vect_update_ivs_after_vectorizer

[irar at gcc dot gnu dot org]

--- Comment #10 from irar at gcc dot gnu dot org  2008-09-07 07:15 ---
Subject: Bug 36630

Author: irar
Date: Sun Sep  7 07:14:03 2008
New Revision: 140081

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=140081
Log:
PR tree-optimization/36630
* tree-vect-transform.c (vect_update_ivs_after_vectorizer):
Call STRIP_NOPS before calling evolution_part_in_loop_num.


Added:
branches/gcc-4_3-branch/gcc/testsuite/gcc.dg/vect/pr36630.c
Modified:
branches/gcc-4_3-branch/gcc/ChangeLog
branches/gcc-4_3-branch/gcc/testsuite/ChangeLog
branches/gcc-4_3-branch/gcc/tree-vect-transform.c


-- 


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

[Bug middle-end/37334] gcc.dg/fastmath-2.c doesn't work

[victork at gcc dot gnu dot org]

--- Comment #3 from victork at gcc dot gnu dot org  2008-09-07 07:35 ---
Subject: Bug 37334

Author: victork
Date: Sun Sep  7 07:34:30 2008
New Revision: 140082

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=140082
Log:
2008-09-07  Victor Kaplansky  <[EMAIL PROTECTED]>

PR testsuite/37334
* gcc/testsuite/gcc.dg/fastmath-2.c: Add volatile to
definition of b, change -ffast-math to -ffinite-math-only
and rename test to ...
* gcc/testsuite/gcc.dg/div-double-1.c: ... this.


Added:
trunk/gcc/testsuite/gcc.dg/div-double-1.c
Removed:
trunk/gcc/testsuite/gcc.dg/fastmath-2.c
Modified:
trunk/gcc/testsuite/ChangeLog


-- 


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

[Bug fortran/37400] [4.4 Regression] implicit character(len=*,kind=kind('A')) (Q) ... no longer gives the right answer.

[burnus at gcc dot gnu dot org]

--- Comment #1 from burnus at gcc dot gnu dot org  2008-09-07 07:50 ---
The problem is that for
   implicit character(len=*,kind=kind('A')) (Q)
the length of the first parameter string is used everywhere. The following
fixes it, but I have no idea why it is a regression / why it worked before.

(I'm almost positive that we will forget to do something similar for deferred
derived-type len parameter of F2003.)


Index: symbol.c
===
--- symbol.c(Revision 140081)
+++ symbol.c(Arbeitskopie)
@@ -257,6 +257,12 @@ gfc_set_default_type (gfc_symbol *sym, i
   sym->ts = *ts;
   sym->attr.implicit_type = 1;

+  if (ts->cl)
+{
+  sym->ts.cl = gfc_get_charlen ();
+  *sym->ts.cl = *ts->cl;
+}
+
   if (sym->attr.is_bind_c == 1)
 {
   /* BIND(C) variables should not be implicitly declared.  */


-- 

burnus at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever Confirmed|0   |1
   Keywords||wrong-code
   Last reconfirmed|-00-00 00:00:00 |2008-09-07 07:50:29
   date||


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

[Bug fortran/19925] Implied do-loop in an initialization expression is broken

[linuxl4 at sohu dot com]

--- Comment #27 from linuxl4 at sohu dot com  2008-09-07 08:25 ---
somebody fix it please.


-- 


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

[Bug fortran/37400] [4.4 Regression] implicit character(len=*,kind=kind('A')) (Q) ... no longer gives the right answer.

[domob at gcc dot gnu dot org]

--- Comment #2 from domob at gcc dot gnu dot org  2008-09-07 08:34 ---
(In reply to comment #1)
> The problem is that for
>implicit character(len=*,kind=kind('A')) (Q)
> the length of the first parameter string is used everywhere. The following
> fixes it, but I have no idea why it is a regression / why it worked before.

Could this have something to do with my used-before-typed patch that might have
changed a little when/why symbols get their IMPLICIT type?  Other than that, I
can't imagine anything, either.

But your patch looks good, just intuitively...


-- 


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

[Bug tree-optimization/35642] [4.4 Regression] short * short multiplication not vectorized on Power

[irar at gcc dot gnu dot org]

--- Comment #18 from irar at gcc dot gnu dot org  2008-09-07 08:55 ---
Subject: Bug 35642

Author: irar
Date: Sun Sep  7 08:54:00 2008
New Revision: 140083

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=140083
Log:

PR tree-optimization/35642
* config/rs6000/altivec.md (mulv8hi3): Implement.


Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/rs6000/altivec.md
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/lib/target-supports.exp


-- 


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

[Bug fortran/37203] Check ORDER= of RESHAPE

[tkoenig at gcc dot gnu dot org]

--- Comment #2 from tkoenig at gcc dot gnu dot org  2008-09-07 09:12 ---
I'm working on the run-time test.


-- 


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

[Bug fortran/37400] [4.4 Regression] implicit character(len=*,kind=kind('A')) (Q) ... no longer gives the right answer.

[dominiq at lps dot ens dot fr]

--- Comment #3 from dominiq at lps dot ens dot fr  2008-09-07 09:13 ---
Subject: Re:  [4.4 Regression] implicit
 character(len=*,kind=kind('A')) (Q) ... no longer gives the right answer.

> But your patch looks good, just intuitively...

The patch works as expected, at least on my quick tests. I'll do a full
regtesting this afternoon.

Thanks for the quick fix.

Dominique


-- 


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

[Bug target/37396] bootstrap broken on hppa-linux-gnu trunk with ada (20080906)

[charlet at gcc dot gnu dot org]

--- Comment #2 from charlet at gcc dot gnu dot org  2008-09-07 09:39 ---
This is a bug in your base compiler, not in GCC 4.4.0.
See other past reports on this issue, where the bug was in the distributor
(Debian ?) compiler, and not in any official GCC releases.

Arno


-- 

charlet at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||WORKSFORME


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

[Bug tree-optimization/36630] [4.3/4.4 Regression] ICE in vect_update_ivs_after_vectorizer

[irar at gcc dot gnu dot org]

--- Comment #11 from irar at gcc dot gnu dot org  2008-09-07 10:07 ---
Subject: Bug 36630

Author: irar
Date: Sun Sep  7 10:05:37 2008
New Revision: 140085

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=140085
Log:
PR tree-optimization/36630
* tree-vect-transform.c (vect_update_ivs_after_vectorizer):
Call STRIP_NOPS before calling evolution_part_in_loop_num.


Added:
trunk/gcc/testsuite/gcc.dg/vect/pr36630.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/testsuite/ChangeLog
trunk/gcc/tree-vect-transform.c


-- 


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

[Bug tree-optimization/35642] [4.4 Regression] short * short multiplication not vectorized on Power

[irar at il dot ibm dot com]

--- Comment #19 from irar at il dot ibm dot com  2008-09-07 11:05 ---
Fixed.


-- 

irar at il dot ibm dot com changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED


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

[Bug tree-optimization/36630] [4.3/4.4 Regression] ICE in vect_update_ivs_after_vectorizer

[irar at il dot ibm dot com]

--- Comment #12 from irar at il dot ibm dot com  2008-09-07 11:05 ---
Fixed.


-- 

irar at il dot ibm dot com changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED


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

[Bug fortran/37407] New: gbytes.f:4: erreur interne du compilateur: dans error_print, �

[preuter64 at yahoo dot de]

Hi ! 

I get an internal error that tells me to ask you for help :

gfortran -c -g -fconvert=big-endian -frecord-marker=4 gbytes.f

gbytes.f:4: erreur interne du compilateur: dans error_print, à
fortran/error.c:471
Veuillez soumettre un rapport complet d'anomalies,
avec le source pré-traité si nécessaire.
Consultez http://gcc.gnu.org/bugs.html> pour plus de détail.
For Debian GNU/Linux specific bug reporting instructions,
see .


Here is the source of gbytes.f :

---
---

  SUBROUTINE GBYTE (IN,IOUT,ISKIP,NBYTE)
integer in(*), iout(*)
  CALL GBYTES (IN,IOUT,ISKIP,NBYTE,0,1)
  RETURN
  END

  SUBROUTINE GBYTES (IN,IOUT,ISKIP,NBYTE,NSKIP,N)
C  Get bytes - unpack bits:  Extract arbitrary size values from a
C  packed bit string, right justifying each value in the unpacked
C  array.
  DIMENSION IN(*), IOUT(*)
CIN= packed array input
CIO= unpacked array output
CISKIP = initial number of bits to skip
CNBYTE = number of bits to take
CNSKIP = additional number of bits to skip on each iteration
CN = number of iterations
C** MACHINE SPECIFIC CHANGES START HERE
C  Machine dependent information required:
CLMWD   = Number of bits in a word on this machine
CMASKS  = Set of word masks where the first element has only the
C right most bit set to 1, the second has the two, ...
CLEFTSH = Shift left bits in word M to the by N bits
CRGHTSH = Shift right
COR = Logical OR (add) on this machine.
CAND= Logical AND (multiply) on this machine
C  This is for Sun UNIX Fortran, DEC Alpha, and RS6000
  PARAMETER (LMWD=32)
  DIMENSION MASKS(LMWD)
  SAVE  MASKS
  DATA  MASKS /Z'1',Z'3',Z'7',Z'F', Z'1F',Z'3F',Z'7F',Z'FF',
 +Z'1FF',Z'3FF',Z'7FF',Z'FFF', Z'1FFF',Z'3FFF',Z'7FFF',Z'',
 +Z'1',   Z'3',   Z'7',   Z'F',
 +Z'1F',  Z'3F',  Z'7F',  Z'FF',
 +Z'1FF', Z'3FF', Z'7FF', Z'FFF',
 +Z'1FFF',Z'3FFF',Z'7FFF',Z''/
C+Z'1',   Z'3',   Z'7',   Z'F',
C+Z'1F',  Z'3F',  Z'7F',  Z'FF',
C+Z'1FF', Z'3FF', Z'7FF', Z'FFF',
C+Z'1FFF',Z'3FFF',Z'7FFF','',
C+Z'1',   Z'3',   Z'7',
C+Z'F',
C+Z'1F',  Z'3F',  Z'7F',
C Z'FF',
C+Z'1FF', Z'3FF', Z'7FF',
C Z'FFF',
C+Z'1FFF',Z'3FFF',Z'7FFF',
C ''/
C  IBM PC using Microsoft Fortran uses different syntax:
C DATA MASKS/16#1,16#3,16#7,16#F,16#1F,16#3F,16#7F,16#FF,
C+ 16#1FF,16#3FF,16#7FF,16#FFF,16#1FFF,16#3FFF,16#7FFF,16#,
C+ 16#1,16#3,16#7,16#F,16#1F,16#3F,
C+ 16#7F,16#FF,16#1FF,16#3FF,16#7FF,16#FFF,
C+ 16#1FFF,16#3FFF,16#7FFF,16#/
  INTEGER RGHTSH, OR, AND
  LEFTSH(M,N) = ISHFT(M,N)
  RGHTSH(M,N) = ISHFT(M,-N)
C OR(M,N)  = M.OR.N
C AND(M,N) = M.AND.N
C OR(M,N)  = IOR(M,N)
C AND(M,N) = IAND(M,N)
C** MACHINE SPECIFIC CHANGES END HERE
C  History:  written by Robert C. Gammill, jul 1972.


C  NBYTE must be less than or equal to LMWD
  ICON = LMWD-NBYTE
  IF (ICON.LT.0) RETURN
  MASK = MASKS (NBYTE)
C  INDEX  = number of words into IN before the next "byte" appears
C  II = number of bits the "byte" is from the left side of the word
C  ISTEP  = number of bits from the start of one "byte" to the next
C  IWORDS = number of words to skip from one "byte" to the next
C  IBITS  = number of bits to skip after skipping IWORDS
C  MOVER  = number of bits to the right, a byte must be moved to be
C   right adjusted
  INDEX = ISKIP/LMWD
  II= MOD (ISKIP,LMWD)
  ISTEP = NBYTE+NSKIP
  IWORDS= ISTEP/LMWD
  IBITS = MOD (ISTEP,LMWD)

  DO 6 I=1,N
  MOVER = ICON-II
  IF (MOVER) 2,3,4

C  The "byte" is split across a word break.
2 MOVEL = -MOVER
  MOVER = LMWD-MOVEL
  NP1 = LEFTSH (IN(INDEX+1),MOVEL)
  NP2 = RGHTSH (IN(INDEX+2),MOVER)
  IOUT(I) = IAND (IOR (NP1,NP2) , MASK)
  GO TO 5
C  The "byte" is already right adjusted.
3 IOUT(I) = IAND (IN (INDEX+1) ,

[Bug fortran/37203] Check ORDER= of RESHAPE

[tkoenig at gcc dot gnu dot org]

--- Comment #3 from tkoenig at gcc dot gnu dot org  2008-09-07 13:34 ---
Subject: Bug 37203

Author: tkoenig
Date: Sun Sep  7 13:33:18 2008
New Revision: 140086

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=140086
Log:
2008-09-07  Thomas Koenig  <[EMAIL PROTECTED]>

PR fortran/37203
* intrinsics/reshape_generic.c:  Add checking on
out-of-bounds and duplicate values of order argument.
* m4/reshape.m4:  Likewise.
* generated/reshape_c10.c: Regenerated.
* generated/reshape_c16.c: Regenerated.
* generated/reshape_c4.c: Regenerated.
* generated/reshape_c8.c: Regenerated.
* generated/reshape_i16.c: Regenerated.
* generated/reshape_i4.c: Regenerated.
* generated/reshape_i8.c: Regenerated.
* generated/reshape_r10.c: Regenerated.
* generated/reshape_r16.c: Regenerated.
* generated/reshape_r4.c: Regenerated.
* generated/reshape_r8.c: Regenerated.

2008-09-07  Thomas Koenig  <[EMAIL PROTECTED]>

PR fortran/37203
* gfortran.d/reshape_order_1.f90:  New test case.
* gfortran.d/reshape_order_2.f90:  New test case.
* gfortran.d/reshape_order_3.f90:  New test case.
* gfortran.d/reshape_order_4.f90:  New test case.


Added:
trunk/gcc/testsuite/gfortran.dg/reshape_order_1.f90
trunk/gcc/testsuite/gfortran.dg/reshape_order_2.f90
trunk/gcc/testsuite/gfortran.dg/reshape_order_3.f90
trunk/gcc/testsuite/gfortran.dg/reshape_order_4.f90
Modified:
trunk/gcc/testsuite/ChangeLog
trunk/libgfortran/ChangeLog
trunk/libgfortran/generated/reshape_c10.c
trunk/libgfortran/generated/reshape_c16.c
trunk/libgfortran/generated/reshape_c4.c
trunk/libgfortran/generated/reshape_c8.c
trunk/libgfortran/generated/reshape_i16.c
trunk/libgfortran/generated/reshape_i4.c
trunk/libgfortran/generated/reshape_i8.c
trunk/libgfortran/generated/reshape_r10.c
trunk/libgfortran/generated/reshape_r16.c
trunk/libgfortran/generated/reshape_r4.c
trunk/libgfortran/generated/reshape_r8.c
trunk/libgfortran/intrinsics/reshape_generic.c
trunk/libgfortran/m4/reshape.m4


-- 


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

[Bug fortran/37407] gbytes.f:4: erreur interne du compilateur: dans error_print, �

[tkoenig at gcc dot gnu dot org]

--- Comment #1 from tkoenig at gcc dot gnu dot org  2008-09-07 13:54 ---
4.2.1 is rather old.

Using 4.2.4 (Debian 4.2.4-3) on the same code, I get

$ gfortran-4.2 -c -g -fconvert=big-endian -frecord-marker=4 bytes.f
bytes.f:36.65:

 +Z'1FFF',Z'3FFF',Z'7FFF',Z''/
1
Error: Arithmetic overflow converting INTEGER(8) to INTEGER(4) at (1)

The error goes away if I supply the -fno-range-check option.

Judging from the position of the ICE, this is probably an error
in error reporting.  Could you try simply to add "-fno-range-check"
and see if the error (and the ICE) go away?

Alternatively, you could upgrade your compiler (I would recommend
4.3.2, which has just been released).


-- 

tkoenig at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||tkoenig at gcc dot gnu dot
   ||org
   Severity|blocker |normal
 Status|UNCONFIRMED |WAITING


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

[Bug rtl-optimization/37377] [4.4 Regression] Bootstrap failure compiling libgcc

[ebotcazou at gcc dot gnu dot org]

--- Comment #8 from ebotcazou at gcc dot gnu dot org  2008-09-07 13:58 
---
> See
>
> http://gcc.gnu.org/ml/gcc-testresults/2008-09/msg00384.html
> 
> Mainline can bootstrap with i586-linux. But there are some additional
> testsuite failures.

Thanks for trying to reproduce, this is very helpful.  I'm sorry, I forgot
something: you must configure with RTL checking (--enable-checking=yes,rtl)
in order to have the miscompilation.

I'm going to attach a simplified testcase (which can be compiled by any x86
compiler) and the analysis.


-- 


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

[Bug fortran/37199] array assignment from function writes out of bounds

[domob at gcc dot gnu dot org]

-- 

domob at gcc dot gnu dot org changed:

   What|Removed |Added

 AssignedTo|unassigned at gcc dot gnu   |domob at gcc dot gnu dot org
   |dot org |
 Status|NEW |ASSIGNED
   Last reconfirmed|2008-08-22 11:57:37 |2008-09-07 14:04:38
   date||


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

[Bug fortran/37407] gbytes.f:4: erreur interne du compilateur: dans error_print, �

[preuter64 at yahoo dot de]

--- Comment #2 from preuter64 at yahoo dot de  2008-09-07 14:12 ---
Subject: Re:  gbytes.f:4: erreur interne du compilateur:
dans error_print, X

Dear!

The option does the trick, and the program compiles !

Thanks for your help!

   Patrick


tkoenig at gcc dot gnu dot org <[EMAIL PROTECTED]> a écrit :

>
>
> --- Comment #1 from tkoenig at gcc dot gnu dot org  2008-09-07   
> 13:54 ---
> 4.2.1 is rather old.
>
> Using 4.2.4 (Debian 4.2.4-3) on the same code, I get
>
> $ gfortran-4.2 -c -g -fconvert=big-endian -frecord-marker=4 bytes.f
> bytes.f:36.65:
>
>  +Z'1FFF',Z'3FFF',Z'7FFF',Z''/
> 1
> Error: Arithmetic overflow converting INTEGER(8) to INTEGER(4) at (1)
>
> The error goes away if I supply the -fno-range-check option.
>
> Judging from the position of the ICE, this is probably an error
> in error reporting.  Could you try simply to add "-fno-range-check"
> and see if the error (and the ICE) go away?
>
> Alternatively, you could upgrade your compiler (I would recommend
> 4.3.2, which has just been released).
>
>
> --
>
> tkoenig at gcc dot gnu dot org changed:
>
>What|Removed |Added
> 
>  CC||tkoenig at gcc dot gnu dot
>||org
>Severity|blocker |normal
>  Status|UNCONFIRMED |WAITING
>
>
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37407
>
> --- You are receiving this mail because: ---
> You reported the bug, or are watching the reporter.
>


-- 


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

[Bug preprocessor/37215] ICE on 'gcc -E -dM -fpreprocessed - < /dev/null'

[patriciak784-gccmainling at yahoo dot de]

--- Comment #5 from patriciak784-gccmainling at yahoo dot de  2008-09-07 
14:41 ---
Sorry, my "patch" doesn't always fix the problem. It is just strange. Sometimes
it works, sometimes not...


-- 


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

[Bug fortran/37199] array assignment from function writes out of bounds

[domob at gcc dot gnu dot org]

--- Comment #4 from domob at gcc dot gnu dot org  2008-09-07 14:46 ---
 parm.12.dim[0].ubound = D.1541;
 parm.12.dim[0].stride = NON_LVALUE_EXPR ;
 parm.12.data = (void *) &(*ifm.11)[0];
 parm.12.offset = NON_LVALUE_EXPR ;
 D.1547 = MAX_EXPR <(parm.12.dim[0].ubound - parm.12.dim[0].lbound) + 1,
0>;
-D.1548 = D.1547 + -1;
+D.1548 = D.1547 + -2;
 atmp.13.dtype = 281;
 atmp.13.dim[0].stride = 1;
 atmp.13.dim[0].lbound = 0;
 atmp.13.dim[0].ubound = D.1548;

This one (from the diffs on my machine) is the problematic one.  The value
subtracted should be -1 independently of the lower bound.  D.1548 will later be
used in calculating the size of the temporary allocated, and for a lower-bound
of 2, for instance, one element will be missing (for lower-bound 3 it would be
2 elements).

I'm not yet completely sure what the problem is for a lower bound of 0 or -1,
though.  There, too much memory is allocated and the atmp's (the result
array's) upper bound is too large.  But I'll try to locate the problem in
gfortran now and fix it and see what this does for all kinds of bounds.


-- 


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

[Bug rtl-optimization/37377] [4.4 Regression] Bootstrap failure compiling libgcc

[ebotcazou at gcc dot gnu dot org]

--- Comment #9 from ebotcazou at gcc dot gnu dot org  2008-09-07 15:45 
---
Created an attachment (id=16247)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16247&action=view)
Simplified testcase.

It is still big, but only 2 functions eventually reach IRA.

Compile with -O2 -fomit-frame-pointer -mtune=pentium.


-- 

ebotcazou at gcc dot gnu dot org changed:

   What|Removed |Added

  Attachment #16225|0   |1
is obsolete||


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

[Bug rtl-optimization/37377] [4.4 Regression] Bootstrap failure compiling libgcc

[ebotcazou at gcc dot gnu dot org]

--- Comment #10 from ebotcazou at gcc dot gnu dot org  2008-09-07 16:01 
---
The problem is the 4th line in

  Remove r222:a590->a10(mem)
  Remove r69:a566->a389(mem)
  Remove r69:a549->a389(mem)
  Remove r376:a432->a12(mem)
  Remove r220:a148->a9(mem)

(r373 is now r376 on mainline) generated by generate_edge_moves:

/* Actually it is not a optimization we need this code because
   the memory (remember about equivalent memory) might be ROM
   (or placed in read only section).  */
if (ALLOCNO_HARD_REGNO (dest_allocno) < 0
&& ALLOCNO_HARD_REGNO (src_allocno) >= 0
&& not_modified_p (src_allocno, dest_allocno))
  {
ALLOCNO_MEM_OPTIMIZED_DEST (src_allocno) = dest_allocno;
ALLOCNO_MEM_OPTIMIZED_DEST_P (dest_allocno) = true;
if (internal_flag_ira_verbose > 3 && ira_dump_file != NULL)
  fprintf (ira_dump_file, "  Remove r%d:a%d->a%d(mem)\n",
   regno, ALLOCNO_NUM (src_allocno),
   ALLOCNO_NUM (dest_allocno));
continue;
  }

Here's the list of allocnos for r376:

579:r376 l205  562:r376 l215  545:r376 l235
  526:r376 l245  507:r376 l255  460:r376 l225  446:r376 l195
  432:r376 l8 5  398:r376 l7 5  386:r376 l9   mem  366:r376 l13  mem
  343:r376 l14  mem  320:r376 l16  mem  295:r376 l17  mem  270:r376 l18  mem
  227:r376 l15  mem  213:r376 l12  mem  199:r376 l11  mem  167:r376 l10  mem
   12:r376 l0   mem

The move putting back r376 to its memory location is not generated on a border
of the "5" domain.  This domain contains the 2nd and 3rd insns of comment #4.
Moreover, the live range of a460 is not added to that of a12 during flattening
so r376 is not detected as conflicting with r90 (formerly r85) and r92 (f r87).
In the end, the memory location of r376 is reused within the "5" domain without
being reset at the border.

If I comment out the code quoted above, the compiler bootstraps fine.


-- 


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

[Bug fortran/19925] Implied do-loop in an initialization expression is broken

[sgk at troutmask dot apl dot washington dot edu]

--- Comment #28 from sgk at troutmask dot apl dot washington dot edu  
2008-09-07 16:33 ---
Subject: Re:  Implied do-loop in an initialization expression is broken

On Sun, Sep 07, 2008 at 08:25:54AM -, linuxl4 at sohu dot com wrote:
> 
> somebody fix it please.
> 

If it were easy to fix, someone would have done this already.
Please read the audit trail.


-- 


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

[Bug rtl-optimization/37408] New: [4.3/4.4 regression] Invalid insn scheduling

[schwab at suse dot de]

This is broken during sched2 pass.  Compiled with -m64 -O2.

lwz 10,1492(7)   # nargs,<--- uninitialized
std 9,1272(7)# specpdl.19,
li 9,16  # iftmp.21,
std 3,1488(7)# nargs, nargs
std 4,1496(7)# args, args
cmpwi 7,10,3 #, tmp307,


-- 
   Summary: [4.3/4.4 regression] Invalid insn scheduling
   Product: gcc
   Version: 4.3.1
Status: UNCONFIRMED
  Keywords: wrong-code
  Severity: normal
  Priority: P3
 Component: rtl-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: schwab at suse dot de
GCC target triplet: powerpc64-*-*


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

[Bug rtl-optimization/37408] [4.3/4.4 regression] Invalid insn scheduling

[schwab at suse dot de]

--- Comment #1 from schwab at suse dot de  2008-09-07 16:48 ---
Created an attachment (id=16248)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16248&action=view)
Testcase


-- 


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

[Bug fortran/37407] gbytes.f:4: erreur interne du compilateur: dans error_print, �

[burnus at gcc dot gnu dot org]

--- Comment #3 from burnus at gcc dot gnu dot org  2008-09-07 17:18 ---
(In reply to comment #2)
> The option does the trick, and the program compiles !

Closed the bug based on this comment.


-- 

burnus at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|WAITING |RESOLVED
 Resolution||WORKSFORME


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

[Bug target/37395] Bootstrap fails in stage 2 due to segfault compiling c-parser

[daney at gcc dot gnu dot org]

--- Comment #3 from daney at gcc dot gnu dot org  2008-09-07 17:30 ---
It is also working on r140069


http://gcc.gnu.org/ml/gcc-testresults/2008-09/msg00612.html


-- 


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

[Bug target/28126] gcc moves an expensive instruction outside of a conditional

[daney at gcc dot gnu dot org]

--- Comment #11 from daney at gcc dot gnu dot org  2008-09-07 17:32 ---
Can we close this now?

I think it is fixed.


-- 


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

[Bug driver/37409] New: -fwhole-program option breaks collect2-generated global constructors

[danglin at gcc dot gnu dot org]

Executing on host: /test/gnu/gcc/objdir/gcc/xgcc -B/test/gnu/gcc/objdir/gcc/
/te
st/gnu/gcc/gcc/gcc/testsuite/gcc.dg/struct/w_prof_global_array.c-O3
-fwhole-
program -combine -fipa-type-escape -fprofile-generate  -lm   -o
/test/gnu/gcc/ob
jdir/gcc/testsuite/gcc/w_prof_global_array.x01(timeout = 300)
/usr/ccs/bin/ld: Unsatisfied symbols:
   _GLOBAL__FI_w_prof_global_array_x01 (first referenced in +init option)
(code)
   _GLOBAL__FD_w_prof_global_array_x01 (first referenced in +fini option)
(code)
collect2: ld returned 1 exit status
compiler exited with status 1

With -Wl,-debug, I see

== output_file =
/test/gnu/gcc/objdir/gcc/testsuite/gcc/w_prof_global_ar
ray.exe, c_file = /var/tmp//ccVomji2.c

write_c_file - output name is
/test/gnu/gcc/objdir/gcc/testsuite/gcc/w_prof_glob
al_array.exe, prefix is w_prof_global_array_exe
static int count;
typedef void entry_pt();
extern entry_pt x2 __asm__ ("_GLOBAL__I_65535_0_main");
void _GLOBAL__FI_w_prof_global_array_exe() {
static entry_pt *ctors[] = {
x2,
};
entry_pt **p;
if (count++ != 0) return;
p = ctors + 1;
while (p > ctors) (*--p)();
}
void _GLOBAL__FD_w_prof_global_array_exe() {
}
== end of c_file

/test/gnu/gcc/objdir/gcc/xgcc -x c -c -o /var/tmp//ccgqCYtU.o
-B/test/gnu/gcc/ob
jdir/gcc/ -fwhole-program -fipa-type-escape -fprofile-generate
-fno-profile-arcs
 -fno-test-coverage -fno-branch-probabilities -fno-exceptions -w
/var/tmp//ccVom
ji2.c
/test/gnu/gcc/objdir/gcc/collect-ld -z -u main -u __gcc_plt_call -o
/test/gnu/gc
c/objdir/gcc/testsuite/gcc/w_prof_global_array.exe /usr/ccs/lib/crt0.o
/var/tmp/
/ccgqCYtU.o /lib/unix98.o -L/test/gnu/gcc/objdir/gcc -L/usr/ccs/lib
-L/opt/langt
ools/lib /var/tmp//ccQX5WvC.o -lm -lgcov -lgcc -lgcc_eh -lc -lgcc -lgcc_eh
+init
 _GLOBAL__FI_w_prof_global_array_exe +fini _GLOBAL__FD_w_prof_global_array_exe
/usr/ccs/bin/ld: Unsatisfied symbols:
   _GLOBAL__FI_w_prof_global_array_exe (first referenced in +init option)
(code)
   _GLOBAL__FD_w_prof_global_array_exe (first referenced in +fini option)
(code)

This is the .s file for the collect2 c file:

.LEVEL 1.1
.SPACE $PRIVATE$
.SUBSPA $DATA$,QUAD=1,ALIGN=8,ACCESS=31
.SUBSPA $BSS$,QUAD=1,ALIGN=8,ACCESS=31,ZERO,SORT=82
.SPACE $TEXT$
.SUBSPA $LIT$,QUAD=0,ALIGN=8,ACCESS=44
.SUBSPA $CODE$,QUAD=0,ALIGN=8,ACCESS=44,CODE_ONLY
.IMPORT $global$,DATA
.IMPORT $$dyncall,MILLICODE
.SPACE $PRIVATE$
.SUBSPA $BSS$

.align 4
count:
.block 4
.SPACE $PRIVATE$
.SUBSPA $DATA$

.align 4
ctors.1225:
.word   P%_GLOBAL__I_65535_0_main
.IMPORT _GLOBAL__I_65535_0_main,CODE

Without the -fwhole-program option, the constructors are retained.


-- 
   Summary: -fwhole-program option breaks collect2-generated global
constructors
   Product: gcc
   Version: 4.4.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: driver
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: danglin at gcc dot gnu dot org
 GCC build triplet: hppa2.0w-hp-hpux11.11
  GCC host triplet: hppa2.0w-hp-hpux11.11
GCC target triplet: hppa2.0w-hp-hpux11.11


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

[Bug debug/37410] New: DW_TAG_imported_module is not in its DW_TAG_lexical_block

[jan dot kratochvil at redhat dot com]

DW_TAG_imported_module (c++ `using namespace') has validity only in the same
block in which they are stated.  It works right for the compiled code but it
gets defined for the whole function in DWARF.

DW_TAG_imported_module should be located in DW_TAG_lexical_block.  Without the
`int block_create;'  declaration the whole DW_TAG_lexical_block is missing
there so it should be created when needed.

The testcase produces:
1
2

Tests on Fedora:
compat-gcc-34-c++-3.4.6-9.x86_64 has no DW_TAG_imported_module there at all.
gcc-4.3.2-3.x86_64 and gcc-4.1.2-33.x86_64 produce the output below.

 <1><6f>: Abbrev Number: 5 (DW_TAG_subprogram)
<70>   DW_AT_external: 1
<71>   DW_AT_name: (indirect string, offset: 0x7f): main
<75>   DW_AT_decl_file   : 1
<76>   DW_AT_decl_line   : 13   
<77>   DW_AT_type: <0x57>   
<7b>   DW_AT_low_pc  : 0x4005ac 
<83>   DW_AT_high_pc : 0x4005fc 
<8b>   DW_AT_frame_base  : 0x0  (location list)
<8f>   DW_AT_sibling : <0xf2>   
 <2><93>: Abbrev Number: 6 (DW_TAG_imported_module)
<94>   DW_AT_decl_file   : 1
<95>   DW_AT_decl_line   : 19   
<96>   DW_AT_import  : <0xf2>   [Abbrev Number: 11 (DW_TAG_namespace)]
 <2><9a>: Abbrev Number: 6 (DW_TAG_imported_module)
<9b>   DW_AT_decl_file   : 1
<9c>   DW_AT_decl_line   : 27   
<9d>   DW_AT_import  : <0x10e>  [Abbrev Number: 11 (DW_TAG_namespace)]
 <2>: Abbrev Number: 7 (DW_TAG_variable)
   DW_AT_name: x
   DW_AT_decl_file   : 1
   DW_AT_decl_line   : 15   
   DW_AT_type: <0x57>   
   DW_AT_location: 2 byte block: 91 64  (DW_OP_fbreg: -28)
 <2>: Abbrev Number: 8 (DW_TAG_lexical_block)
   DW_AT_low_pc  : 0x4005b4 
   DW_AT_high_pc : 0x4005d2 
   DW_AT_sibling : <0xd1>   
 <3>: Abbrev Number: 9 (DW_TAG_variable)  
   DW_AT_name: (indirect string, offset: 0x32): block_create
   DW_AT_decl_file   : 1
   DW_AT_decl_line   : 18   
   DW_AT_type: <0x57>   
   DW_AT_location: 2 byte block: 91 68  (DW_OP_fbreg: -24)
 <2>: Abbrev Number: 10 (DW_TAG_lexical_block)
   DW_AT_low_pc  : 0x4005d2 
   DW_AT_high_pc : 0x4005f0 
 <3>: Abbrev Number: 9 (DW_TAG_variable)
   DW_AT_name: (indirect string, offset: 0x32): block_create
   DW_AT_decl_file   : 1
   DW_AT_decl_line   : 26   
   DW_AT_type: <0x57>   
   DW_AT_location: 2 byte block: 91 6c  (DW_OP_fbreg: -20)


-- 
   Summary: DW_TAG_imported_module is not in its
DW_TAG_lexical_block
   Product: gcc
   Version: 4.3.2
Status: UNCONFIRMED
  Severity: minor
  Priority: P3
 Component: debug
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: jan dot kratochvil at redhat dot com
 GCC build triplet: x86_64-fedora-linux-gnu
  GCC host triplet: x86_64-fedora-linux-gnu
GCC target triplet: x86_64-fedora-linux-gnu


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

[Bug debug/37410] DW_TAG_imported_module is not in its DW_TAG_lexical_block

[jan dot kratochvil at redhat dot com]

--- Comment #1 from jan dot kratochvil at redhat dot com  2008-09-07 17:56 
---
Created an attachment (id=16249)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16249&action=view)
Testcase.


-- 


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

[Bug fortran/37319] [4.4 Regression] FAIL: gfortran.dg/function_kinds_5.f90

[dominiq at lps dot ens dot fr]

--- Comment #2 from dominiq at lps dot ens dot fr  2008-09-07 18:25 ---
Confirmed on http://gcc.gnu.org/ml/gcc-testresults/2008-09/msg00195.html and
http://gcc.gnu.org/ml/gcc-testresults/2008-09/msg00505.html.

This looks like a missing or wrong initialisation.


-- 


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

[Bug fortran/37319] [4.4 Regression] FAIL: gfortran.dg/function_kinds_5.f90

[dominiq at lps dot ens dot fr]

--- Comment #3 from dominiq at lps dot ens dot fr  2008-09-07 18:35 ---
Note that in the window 139588 to 139622 there is no change in gfortran. The
most important change is the IRA merge at 139590. This may have caused a
miscompilation of some gfortran code (this happened with transfer) or only
exposed the problem on i686-apple-darwin9 (I don't see it on ppc).

Any idea on how to debug this pr?


-- 


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

[Bug fortran/37411] New: gfortran internal error

[jonasson at hi dot is]

The following module file causes gfortran to give segmentation fault.
Specifically, given the command "gfortran -c b1.f90" produces:

  b1.f90: In function 'sub':
  b1:12: internal compiler error: Segmentation fault

This happens with several different versions of the compiler (4.3.1, 4.3.0,
4.2.3, 4.2.1) on a few different platforms (cygwin, ubuntu linux, suse linux).

The module is compiled correctly by g95, nag f95, ifort and absoft af95.

Finally, here is the error producing file:

MODULE B1
CONTAINS
  subroutine sub()
integer :: x(1)
character(3) :: st
st = fun(x)
  end subroutine sub

  function fun(x) result(st)
integer, intent(in) :: x(1)
character(lenf(x)) :: st
st = 'abc'
  end function fun

  pure integer function lenf(x)
integer, intent(in) :: x(1)
lenf = x(1)
  end function lenf
END MODULE B1


-- 
   Summary: gfortran internal error
   Product: gcc
   Version: 4.3.0
Status: UNCONFIRMED
  Severity: major
  Priority: P3
 Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: jonasson at hi dot is


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

[Bug fortran/37199] array assignment from function writes out of bounds

[domob at gcc dot gnu dot org]

--- Comment #5 from domob at gcc dot gnu dot org  2008-09-07 19:00 ---
program bounds_issue
  real, pointer :: pdf0(:)
  allocate(pdf0(0:282))
  pdf0 = f(pdf0)

contains
  function f(x)
real, intent(in) :: x(0:)  ! x(1:), f(1:...) works
real :: f(0:ubound(x,dim=1))   ! x(-1:), f(-1:...) crashes
f = 0.0
  end function
end program bounds_issue

---

For the temporary array holding the result and the loop assigning back to pdf0,
the bounds of f(0:ubound(x,dim=1)) are used.  The interface mapping of x in the
upper bound however does not supply an array-spec to the symbol, and thus
UBOUND(x) returns the number of elements in x rather than the real upper bound
matching the fixed lower-bound of 0 as for an entity not being a full array.

Thus, the loop starts at 0 because of the constant lower bound but runs one
element too far because the upper bound is evaluated as if the lower was 1. 
This leads to the segfault in any case but when 1 is indeed the lower bound. 
It seems to be possible to simply copy the array-spec to new_sym in
gfc_add_interface_mapping, I'm working this out at the moment.


-- 


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

[Bug fortran/37411] gfortran internal error

[dominiq at lps dot ens dot fr]

--- Comment #1 from dominiq at lps dot ens dot fr  2008-09-07 19:01 ---
Confirmed on powerpc-apple-darwin9 (4.2.3, 4.3.2 and trunk):

pr37411.f90: In function 'sub':
pr37411.f90:12: internal compiler error: Bus error


-- 


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

[Bug driver/37409] -fwhole-program option breaks collect2-generated global constructors

[danglin at gcc dot gnu dot org]

--- Comment #1 from danglin at gcc dot gnu dot org  2008-09-07 19:07 ---
It looks like this option can be removed in the LINK_SPEC define.


-- 

danglin at gcc dot gnu dot org changed:

   What|Removed |Added

Summary|-fwhole-program option  |-fwhole-program option
   |breaks collect2-generated   |breaks collect2-generated
   |global constructors |global constructors


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

[Bug target/37381] [4.4 Regression] ICE in ia64_speculate_insn, at config/ia64/ia64.c:6902

[hjl dot tools at gmail dot com]

--- Comment #3 from hjl dot tools at gmail dot com  2008-09-07 20:06 ---
Adding -mno-sched-ar-data-spec fixes the crash. This bug is
introduced by selective scheduling.


-- 

hjl dot tools at gmail dot com changed:

   What|Removed |Added

 CC||amonakov at gmail dot com


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

Re: [Bug rtl-optimization/37408] New: [4.3/4.4 regression] Invalid insn scheduling

[Andrew Thomas Pinski]

Sent from my iPhone

On Sep 7, 2008, at 9:47, "schwab at suse dot de" <[EMAIL PROTECTED] 
> wrote:



This is broken during sched2 pass.  Compiled with -m64 -O2.

   lwz 10,1492(7)   # nargs,<--- uninitialized
   std 9,1272(7)# specpdl.19,
   li 9,16  # iftmp.21,
   std 3,1488(7)# nargs, nargs
   std 4,1496(7)# args, args
   cmpwi 7,10,3 #, tmp307,



Just looking at the assembler suggest an aliasing issue. I had a quick  
look at the code but I did see anything would give an alaising issue.  
Though there were some unions.




--
  Summary: [4.3/4.4 regression] Invalid insn scheduling
  Product: gcc
  Version: 4.3.1
   Status: UNCONFIRMED
 Keywords: wrong-code
 Severity: normal
 Priority: P3
Component: rtl-optimization
   AssignedTo: unassigned at gcc dot gnu dot org
   ReportedBy: schwab at suse dot de
GCC target triplet: powerpc64-*-*


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

[Bug fortran/37411] ICE (segfault) in trans-array.c

[burnus at gcc dot gnu dot org]

--- Comment #2 from burnus at gcc dot gnu dot org  2008-09-07 20:09 ---
==17304== Invalid read of size 4
==17304==at 0x49F779: gfc_conv_array_parameter (trans-array.c:5179)
==17304==by 0x4B05C0: gfc_conv_function_call (trans-expr.c:2582)
==17304==by 0x4B1A7D: gfc_conv_function_expr (trans-expr.c:3252)
==17304==by 0x4B62F9: gfc_apply_interface_mapping (trans-expr.c:2036)

The following seems to fix it (not extensively tested):

--- trans-array.c   (revision 140091)
+++ trans-array.c   (working copy)
@@ -5176,7 +5176,7 @@ gfc_conv_array_parameter (gfc_se * se, g

   if (sym->ts.type == BT_CHARACTER)
se->string_length = sym->ts.cl->backend_decl;
-  if (!sym->attr.pointer && sym->as->type != AS_ASSUMED_SHAPE
+  if (!sym->attr.pointer && sym->as && sym->as->type != AS_ASSUMED_SHAPE
   && !sym->attr.allocatable)
 {
  /* Some variables are declared directly, others are declared as


-- 

burnus at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever Confirmed|0   |1
   Keywords||ice-on-valid-code
   Last reconfirmed|-00-00 00:00:00 |2008-09-07 20:09:05
   date||
Summary|gfortran internal error |ICE (segfault) in trans-
   ||array.c


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

[Bug rtl-optimization/37408] [4.3/4.4 regression] Invalid insn scheduling

[pinskia at gmail dot com]

--- Comment #2 from pinskia at gmail dot com  2008-09-07 20:10 ---
Subject: Re:   New: [4.3/4.4 regression] Invalid insn scheduling



Sent from my iPhone

On Sep 7, 2008, at 9:47, "schwab at suse dot de" <[EMAIL PROTECTED] 
 > wrote:

> This is broken during sched2 pass.  Compiled with -m64 -O2.
>
>lwz 10,1492(7)   # nargs,<--- uninitialized
>std 9,1272(7)# specpdl.19,
>li 9,16  # iftmp.21,
>std 3,1488(7)# nargs, nargs
>std 4,1496(7)# args, args
>cmpwi 7,10,3 #, tmp307,
>

Just looking at the assembler suggest an aliasing issue. I had a quick  
look at the code but I did see anything would give an alaising issue.  
Though there were some unions.

>
> -- 
>   Summary: [4.3/4.4 regression] Invalid insn scheduling
>   Product: gcc
>   Version: 4.3.1
>Status: UNCONFIRMED
>  Keywords: wrong-code
>  Severity: normal
>  Priority: P3
> Component: rtl-optimization
>AssignedTo: unassigned at gcc dot gnu dot org
>ReportedBy: schwab at suse dot de
> GCC target triplet: powerpc64-*-*
>
>
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37408
>


-- 


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

[Bug target/37394] [4.4 Regression] Segfault in ia64_variable_issue with -O -fschedule-insns2

[hjl dot tools at gmail dot com]

--- Comment #5 from hjl dot tools at gmail dot com  2008-09-07 20:11 ---
--- gcc/opts.c.over 2008-09-07 12:50:39.0 -0700
+++ gcc/opts.c  2008-09-07 12:47:04.0 -0700
@@ -1001,13 +1001,13 @@ decode_options (unsigned int argc, const
   flag_unwind_tables = targetm.unwind_tables_default;
 }

+  handle_options (argc, argv, lang_mask);
+
 #ifdef OPTIMIZATION_OPTIONS
   /* Allow default optimizations to be specified on a per-machine basis.  */
   OPTIMIZATION_OPTIONS (optimize, optimize_size);
 #endif

-  handle_options (argc, argv, lang_mask);
-
   /* Handle related options for unit-at-a-time, toplevel-reorder, and
  section-anchors.  */
   if (!flag_unit_at_a_time)

Michael, this patch allows ia64_optimization_options to override
-fschedule-insns2. But I am not sure if it is a proper fix.


-- 


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

[Bug rtl-optimization/37408] [4.3/4.4 regression] Invalid insn scheduling

[schwab at suse dot de]

--- Comment #3 from schwab at suse dot de  2008-09-07 20:29 ---
The corresponding code line:

  register const unsigned char **new_argv
= (const unsigned char **) __builtin_alloca 2) > (nargs - 2) ? (2) :
(nargs - 2))) * sizeof (char *));


-- 


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

[Bug fortran/37412] New: No error on repeated declaration

[jonasson at hi dot is]

The following program compiles OK with no message that st is being redefined.

function fun() result(st)
  character(2) st
  character(1) st
  st = '1'
end function fun


-- 
   Summary: No error on repeated declaration
   Product: gcc
   Version: 4.3.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: jonasson at hi dot is


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

[Bug fortran/37400] [4.4 Regression] implicit character(len=*,kind=kind('A')) (Q) ... no longer gives the right answer.

[dominiq at lps dot ens dot fr]

--- Comment #4 from dominiq at lps dot ens dot fr  2008-09-07 21:10 ---
Regtests passed without regressions on i686-apple-darwin9. Thanks again for the
patch.


-- 


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

[Bug middle-end/37380] [4.4 Regression] ../../gcc/libcpp/charset.c:1103: error: 'cvt.77.width' is used uninitialized in this function

[andreast at gcc dot gnu dot org]

-- 

andreast at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever Confirmed|0   |1
   Last reconfirmed|-00-00 00:00:00 |2008-09-07 21:11:45
   date||


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

[Bug fortran/37412] No error on repeated declaration

[dominiq at lps dot ens dot fr]

--- Comment #1 from dominiq at lps dot ens dot fr  2008-09-07 21:15 ---
Confirmed with 4.2.3 and 4.3.2, with 4.4.0 (trunk) I get:

[ibook-dhum] f90/bug% gfc -Wall pr37412.f90
pr37412.f90:3.17:

  character(1) st
1
Warning: Symbol 'st' at (1) already has basic type of CHARACTER

Now I am not sure which statement is the winner. Is this defined somewhere?


-- 


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

[Bug fortran/37412] No error on repeated declaration

[burnus at gcc dot gnu dot org]

--- Comment #2 from burnus at gcc dot gnu dot org  2008-09-07 21:35 ---
(In reply to comment #1)
> Warning: Symbol 'st' at (1) already has basic type of CHARACTER

I think one should print here an error as the LEN type parameter is different. 

The same issue exists for the KIND type parameter.

> Now I am not sure which statement is the winner. Is this defined somewhere?

I think it is a bug (cf. above) and thus not really defined. However, testing
with gfortran 4.3 implies that the latter definition wins.


-- 

burnus at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever Confirmed|0   |1
   Keywords||accepts-invalid
   Last reconfirmed|-00-00 00:00:00 |2008-09-07 21:35:53
   date||


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

[Bug c++/37413] New: Spurious warning about undefining "__STDC_LIMIT_MACROS"

[bagnara at cs dot unipr dot it]

$ cat bug.cc
#define __STDC_LIMIT_MACROS

#ifdef __STDC_LIMIT_MACROS
#undef __STDC_LIMIT_MACROS
#endif

$ g++ -W -Wall -c bug.cc
bug.cc:4:8: warning: undefining "__STDC_LIMIT_MACROS"
$ g++ -v
Using built-in specs.
Target: x86_64-redhat-linux
Configured with: ../configure --prefix=/usr --mandir=/usr/share/man
--infodir=/usr/share/info --enable-shared --enable-threads=posix
--enable-checking=release --with-system-zlib --enable-__cxa_atexit
--disable-libunwind-exceptions --enable-libgcj-multifile
--enable-languages=c,c++,objc,obj-c++,java,fortran,ada --enable-java-awt=gtk
--disable-dssi --enable-plugin
--with-java-home=/usr/lib/jvm/java-1.4.2-gcj-1.4.2.0/jre --with-cpu=generic
--host=x86_64-redhat-linux
Thread model: posix
gcc version 4.1.2 20070626 (Red Hat 4.1.2-13)
$


-- 
   Summary: Spurious warning about undefining "__STDC_LIMIT_MACROS"
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: bagnara at cs dot unipr dot it
  GCC host triplet: x86_64-unknown-linux-gnu


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

[Bug fortran/37412] No error on repeated declaration

[dominiq at lps dot ens dot fr]

--- Comment #3 from dominiq at lps dot ens dot fr  2008-09-07 22:06 ---
With -std=f95 all the gfortran versions I have reject the code with:

[ibook-dhum] f90/bug% gfc -std=f95 pr37412.f90
pr37412.f90:3.17:

  character(1) st
1
Error: Symbol 'st' at (1) already has basic type of CHARACTER

> I think one should print here an error as the LEN type parameter is 
> different. 
>
> The same issue exists for the KIND type parameter.

I agree this would avoid to wonder which statement is taken into account.


-- 


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

[Bug c++/34859] g++ -D__STDC_LIMIT_MACROS -D__STDC_LIMIT_MACROS causes error

[pinskia at gcc dot gnu dot org]

--- Comment #8 from pinskia at gcc dot gnu dot org  2008-09-07 22:14 ---
*** Bug 37413 has been marked as a duplicate of this bug. ***


-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||bagnara at cs dot unipr dot
   ||it


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

[Bug c++/37413] Spurious warning about undefining "__STDC_LIMIT_MACROS"

[pinskia at gcc dot gnu dot org]

--- Comment #1 from pinskia at gcc dot gnu dot org  2008-09-07 22:14 ---


*** This bug has been marked as a duplicate of 34859 ***


-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||DUPLICATE


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

[Bug middle-end/37414] New: [4.4 regression] ICE with -ffast-math

[reichelt at gcc dot gnu dot org]

The following code snippet triggers an ICE on mainline (i686-pc-linux-gnu)#
when compiled with "-ffast-math":

===
double foo(double x) { return x; }
double y = 2*foo(1);
===

bug0.cc:2: internal compiler error: Segmentation fault
Please submit a full bug report, [etc.]

The bug was introduced between 2008-08-23 and 2008-08-29.


-- 
   Summary: [4.4 regression] ICE with -ffast-math
   Product: gcc
   Version: 4.4.0
Status: UNCONFIRMED
  Keywords: ice-on-valid-code, monitored
  Severity: normal
  Priority: P3
 Component: middle-end
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: reichelt at gcc dot gnu dot org


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

[Bug middle-end/37414] [4.4 regression] ICE with -ffast-math

[reichelt at gcc dot gnu dot org]

-- 

reichelt at gcc dot gnu dot org changed:

   What|Removed |Added

   Target Milestone|--- |4.4.0


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

[Bug c++/30156] [4.2/4.3/4.4 regression] ICE on invalid template declaration

[reichelt at gcc dot gnu dot org]

--- Comment #5 from reichelt at gcc dot gnu dot org  2008-09-07 23:17 
---


*** This bug has been marked as a duplicate of 37348 ***


-- 

reichelt at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||DUPLICATE


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

[Bug c++/37348] [4.2/4.3/4.4 Regression] internal compiler error: tree check: expected var_decl, have field_decl in cp_finish_decl, at cp/decl.c:5461

[reichelt at gcc dot gnu dot org]

--- Comment #6 from reichelt at gcc dot gnu dot org  2008-09-07 23:17 
---
*** Bug 30156 has been marked as a duplicate of this bug. ***


-- 

reichelt at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||reichelt at gcc dot gnu dot
   ||org


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

[Bug driver/37415] New: [4.4 regression] ICE with -ftree-store-ccp

[reichelt at gcc dot gnu dot org]

Compiling an arbitrary program with "-ftree-store-ccp" triggers an ICE
on mainline:

cc1: internal compiler error: in common_handle_option, at opts.c:2068
Please submit a full bug report, [etc.]

Richard, this seems to be fallout from your patch:

2008-08-29  Richard Guenther  <[EMAIL PROTECTED]>

* common.opt (ftree-store-ccp): Mark as preserved for
backward compatibility.
* doc/invoke.texi (-ftree-store-ccp): Remove documentation.
* tree-pass.h (pass_store_ccp): Remove.
[...]


-- 
   Summary: [4.4 regression] ICE with -ftree-store-ccp
   Product: gcc
   Version: 4.4.0
Status: UNCONFIRMED
  Keywords: ice-on-valid-code, monitored
  Severity: normal
  Priority: P3
 Component: driver
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: reichelt at gcc dot gnu dot org


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

[Bug driver/37415] [4.4 regression] ICE with -ftree-store-ccp

[reichelt at gcc dot gnu dot org]

-- 

reichelt at gcc dot gnu dot org changed:

   What|Removed |Added

   Target Milestone|--- |4.4.0


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

[Bug middle-end/37415] [4.4 regression] ICE with -ftree-store-ccp

[pinskia at gcc dot gnu dot org]

--- Comment #1 from pinskia at gcc dot gnu dot org  2008-09-07 23:38 ---
Just like PR 34317 and PR 34382.


-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
  Component|driver  |middle-end
 Ever Confirmed|0   |1
   Last reconfirmed|-00-00 00:00:00 |2008-09-07 23:38:44
   date||


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

[Bug tree-optimization/37310] [4.3 Regression] gfortran errors in compilation and the making for upgraded compilers

[petermorgan at grapevine dot net dot au]

--- Comment #15 from petermorgan at grapevine dot net dot au  2008-09-07 
23:56 ---
Subject: Re:  [4.3 Regression] gfortran errors
 in compilation and the making for upgraded compilers

Dear Andrew

Thanks message below. Unfortunately this is not the correct test case. 
The test case involves  involves the routine tssum.

I will redo the test case in case there are difficulties with the test 
module.

regards and thanks

peter

pinskia at gcc dot gnu dot org wrote:
> --- Comment #14 from pinskia at gcc dot gnu dot org  2008-09-06 23:06 
> ---
> Reduced testcase:
>   real*8 in_mjd(500), in_xyz_std(6,500)
>   real*8 ref_xyz(3), ref_llu(3), ref_neu(3)
>   common / ts_r8 /sec_rel, in_mjd, in_xyz_std, ref_llu, ref_neu
>   real*8 locref(3)
> locref(1) = ref_llu(1)
> call loc_to_geod(locref, neuref)
> write(*,*) in_mjd(i)
>end
> --- CUT ---
> Works on the trunk.
>
>
>   

-- 
***
* *
*  Peter and Carol Morgan *
*  20 Goodparla St*
*  Hawker, ACT, 2614  *
*  Australia  *
* *
* Home Phone  +61 (0)2 6254 0137  *
* Peter's Mobile  +61 (0)4 1854 0137  *
* *
* *
***


-- 


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

[Bug target/37394] [4.4 Regression] Segfault in ia64_variable_issue with -O -fschedule-insns2

[hjl dot tools at gmail dot com]

--- Comment #6 from hjl dot tools at gmail dot com  2008-09-08 00:04 ---
We have OPTIMIZATION_OPTIONS which is executed once just after
the optimization level is determined and before the remainder
of the command options have been parsed. This macro is run once
at program startup and when the optimization options are changed
via "pragma GCC optimize" or by using the "optimize" attribute.

We have OVERRIDE_OPTIONS which is executed once just after all
the command options have been parsed.

They don't cover this case as well as the case in

http://gcc.gnu.org/ml/gcc-patches/2008-08/msg00524.html


-- 

hjl dot tools at gmail dot com changed:

   What|Removed |Added

 CC||xuepeng dot guo at intel dot
   ||com


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

[Bug tree-optimization/37310] [4.3 Regression] gfortran errors in compilation and the making for upgraded compilers

[petermorgan at grapevine dot net dot au]

--- Comment #16 from petermorgan at grapevine dot net dot au  2008-09-08 
00:43 ---
Created an attachment (id=16250)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16250&action=view)
An updated code fragment, old version tsummc00.f, showing the compilation
error.

A smaller code fragment to tsummc001.f which also shows the compilation error.
Here is the output from my test starting with with a version call to gfortran
and ending with an error free compilation when there is no optimization.

[EMAIL PROTECTED] test]$ gfortran -v
Using built-in specs.
Target: x86_64-unknown-linux-gnu
Configured with: ../gcc-4.3.1.source/configure --prefix=/opt
--with-mpfr-lib=/opt/lib --with-mpfr-include=/opt/include --disable-multilib
Thread model: posix
gcc version 4.3.1 (GCC) 
[EMAIL PROTECTED] test]$  gfortran -c -O3  tssumd00.f
tssumd00.f: In function 'remove_ejmp':
tssumd00.f:91: internal compiler error: in set_uids_in_ptset, at
tree-ssa-structalias.c:4789
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.
[EMAIL PROTECTED] test]$ gfortran -c   tssumd00.f


The extensive parameter lists and common blocks are important. They are
normally invoked by the use of include files. The error in in this test also
occurs in a second place in the suite. In both case there are two include
statement lines. In this module everything is okay when only one include
statement is requested. I am searching for other locations in the suite where
there may be two used of include. This is a relatively slow process. 


-- 

petermorgan at grapevine dot net dot au changed:

   What|Removed |Added

  Attachment #16199|0   |1
is obsolete||


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

[Bug driver/37409] -fwhole-program option breaks collect2-generated global constructors

[danglin at gcc dot gnu dot org]

--- Comment #2 from danglin at gcc dot gnu dot org  2008-09-08 04:27 ---
Subject: Bug 37409

Author: danglin
Date: Mon Sep  8 04:26:15 2008
New Revision: 140099

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=140099
Log:
PR driver/37409
* pa-hpux.h (LINK_SPEC): Strip -fwhole-program.
* pa-hpux10.h (LINK_SPEC): Likewise.
* pa-hpux11.h (LINK_SPEC): Likewise.
`

Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/pa/pa-hpux.h
trunk/gcc/config/pa/pa-hpux10.h
trunk/gcc/config/pa/pa-hpux11.h


-- 


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

[Bug driver/37409] -fwhole-program option breaks collect2-generated global constructors

[danglin at gcc dot gnu dot org]

--- Comment #3 from danglin at gcc dot gnu dot org  2008-09-08 04:34 ---
Fixed.


-- 


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

[Bug target/33034] FAIL: gcc.c-torture/unsorted/DFcmp.c & SFset.c: internal compiler error: in extract_insn, at recog.c:2077

[christian dot joensson at gmail dot com]

--- Comment #6 from christian dot joensson at gmail dot com  2008-09-08 
05:30 ---
Subject: Re:  FAIL: gcc.c-torture/unsorted/DFcmp.c & SFset.c: internal compiler
error: in extract_insn, at recog.c:2077

> I've seen these in 4.3-based toolchains, but don't see them with recent trunk.
> Do you still get them with current trunk or not?  If not, I think we can close
> this as FIXED in 4.4.

I don't have any sparc64 linux system available at the time, but maybe
Matthias Klose can comment on this.


-- 


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

[Bug fortran/37412] No error on repeated declaration

[domob at gcc dot gnu dot org]

--- Comment #4 from domob at gcc dot gnu dot org  2008-09-08 06:36 ---
IIRC, this behaviour is due to a patch I submitted some time ago.  Maybe I
could change this warning into an error even for non-standard conforming mode
in case the length or a kind parameter differs.  What do you think?


-- 


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

[Bug tree-optimization/37416] New: Failure to return number of loop iterations

[irar at il dot ibm dot com]

For the loop in testcase of pr36630:

void
foo (unsigned char *x, short y)
{
  short i;

  i = 2;
  while (i < y)
{
  x[i - 1] = x[i];
  i = i + 1;
}
}

we used to get 
# of iterations (short unsigned int) y_3(D) + 65533, bounded by 32764
and now we get scev_not_known.

Also Sebastian noticed (from pr36630):

> I also have remarked on one of the graphite testcases scop-matmult.c
> that we had a regression in the precision of the number of iterations from
> last graphite merge till yesterday's merge, i.e. from 138275 to 139870
> We used to have a symbolic number of iterations, but now the result
> is scev_dont_know.  I have not yet tracked this down to the patch that
> produced this regression.
> 
> Sebastian


-- 
   Summary: Failure to return number of  loop iterations
   Product: gcc
   Version: 4.4.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: irar at il dot ibm dot com


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

[Bug middle-end/37414] [4.4 regression] ICE with -ffast-math

[ubizjak at gmail dot com]

--- Comment #1 from ubizjak at gmail dot com  2008-09-08 06:50 ---
Confirmed:

Program received signal SIGSEGV, Segmentation fault.
0x082ac655 in optimize_function_for_speed_p (fun=0x0) at
../../gcc-svn/trunk/gcc/predict.c:205
/home/uros/gcc-svn/trunk/gcc/predict.c:205:6178:beg:0x82ac655
(gdb) bt
#0  0x082ac655 in optimize_function_for_speed_p (fun=0x0) at
../../gcc-svn/trunk/gcc/predict.c:205
#1  0x081f3c53 in fold_binary (code=MULT_EXPR, type=0xb7c4e478, op0=0xb7f56294,
op1=0xb7cd39bc) at ../../gcc-svn/trunk/gcc/fold-const.c:10414


-- 

ubizjak at gmail dot com changed:

   What|Removed |Added

 CC||hubicka at gcc dot gnu dot
   ||org
 Status|UNCONFIRMED |NEW
 Ever Confirmed|0   |1
   Last reconfirmed|-00-00 00:00:00 |2008-09-08 06:50:37
   date||


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

[Bug debug/37322] [4.4 Regression] FAIL: gfortran.dg/debug/pr35154-dwarf2.f

[jakub at gcc dot gnu dot org]

--- Comment #5 from jakub at gcc dot gnu dot org  2008-09-08 06:51 ---
Given http://gcc.gnu.org/ml/gcc-testresults/2008-09/msg00370.html
I think we can safely close this now.


-- 

jakub at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||FIXED


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

[ bebas promosi ] Bahagiakan keluarga anda.... !!!, 9/8/2008, 7:00 am

[bebas-promosi]

Reminder from: bebas-promosi Yahoo! Group
 http://groups.yahoo.com/group/bebas-promosi/cal

Bahagiakan keluarga anda !!!
Monday September 8, 2008
7:00 am - 8:00 am
(This event repeats every day.)
(The next reminder for this event will be sent in 5 hours, 48 minutes.)

Notes:
Apabila Anda menginginkan penghasilan tambahan dengan Mudah, Murah dan Cepat, 
kami adalah pilihan yang tepat, karena kami menerepkan system yang baru dan 
dipadukan dengan system-system yang ada dan sudah terbukti menghasilkan uang 
dengan cepat... di dunia Internet.
Untuk informasi lebih lanjut, kunjungi segera  
http://www.arisankeluarga.com/index.php?id=r12al


All Rights Reserved
 Copyright © 2008 
 Yahoo! Inc.
 http://www.yahoo.com

Privacy Policy:
 http://privacy.yahoo.com/privacy/us

Terms of Service:
 http://docs.yahoo.com/info/terms/