--- Comment #15 from jvdelisle at gcc dot gnu dot org 2007-03-16 01:11
---
Subject: Bug 31099
Author: jvdelisle
Date: Fri Mar 16 01:11:01 2007
New Revision: 122973
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=122973
Log:
2007-03-15 Jerry DeLisle <[EMAIL PROTECTED]>
--- Comment #16 from jvdelisle at gcc dot gnu dot org 2007-03-16 01:54
---
Subject: Bug 31099
Author: jvdelisle
Date: Fri Mar 16 01:54:25 2007
New Revision: 122974
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=122974
Log:
2007-03-15 Jerry DeLisle <[EMAIL PROTECTED]>
--- Comment #17 from jvdelisle at gcc dot gnu dot org 2007-03-16 01:57
---
Subject: Bug 31099
Author: jvdelisle
Date: Fri Mar 16 01:57:16 2007
New Revision: 122975
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=122975
Log:
2007-03-15 Jerry DeLisle <[EMAIL PROTECTED]>
--- Comment #17 from dave at hiauly1 dot hia dot nrc dot ca 2007-03-16
02:07 ---
Subject: Re: Bootstrap comparison error at revision 122821
> Did you try reverting the last hunk:
>
> @@ -1816,7 +1833,8 @@
> the new range. */
>
>/* Divisions by zero result in a VARY
--- Comment #5 from jkrahn at nc dot rr dot com 2007-03-16 03:46 ---
BOZ processing was recently broken in gfortran. I assume it relates to the
issues here.
The current problem is shown in this bit of code:
write(*,*)'NaN(8)=',real(z'FFF8',8)
end
gfortran, even with -s
--- Comment #6 from jkrahn at nc dot rr dot com 2007-03-16 03:53 ---
One more comment: I just checked the INT() intrisic for F2003. It actually
still states that a BOZ is initially interpreted as the largest integer type
(ugh!) REAL() has the correct definition of interpreting as the tar
--- Comment #7 from sgk at troutmask dot apl dot washington dot edu
2007-03-16 04:07 ---
Subject: Re: Warn with -std=f95/f2003 when BOZ is used at invalid places
On Fri, Mar 16, 2007 at 03:46:30AM -, jkrahn at nc dot rr dot com wrote:
>
>
> --- Comment #5 from jkrahn at nc d
--- Comment #8 from sgk at troutmask dot apl dot washington dot edu
2007-03-16 04:09 ---
Subject: Re: Warn with -std=f95/f2003 when BOZ is used at invalid places
On Fri, Mar 16, 2007 at 03:53:57AM -, jkrahn at nc dot rr dot com wrote:
>
> I have not checked F2008 yet. My vote is t
There are known problems with attempts at folding TRANSFER in constant
expressions. However, the following code doesn't involve this, and should work
properly even if folding of TRANSFER simply bails out without attempting to
fold anything. Instead, it gives an ICE (in the middle-end, not in the
--- Comment #8 from aoliva at gcc dot gnu dot org 2007-03-16 05:08 ---
Subject: Bug 29906
Author: aoliva
Date: Fri Mar 16 05:08:25 2007
New Revision: 122976
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=122976
Log:
gcc/ChangeLog:
PR debug/29906
* dwarf2out.c (force_type_die): A
--- Comment #9 from aoliva at gcc dot gnu dot org 2007-03-16 05:09 ---
Subject: Bug 29906
Author: aoliva
Date: Fri Mar 16 05:08:47 2007
New Revision: 122977
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=122977
Log:
gcc/ChangeLog:
PR debug/29906
* dwarf2out.c (force_type_die): A
--- Comment #2 from kkojima at gcc dot gnu dot org 2007-03-16 06:09 ---
Could you please try the revision > 122791 or the patch in
http://gcc.gnu.org/ml/gcc-patches/2007-03/msg00584.html?
--
kkojima at gcc dot gnu dot org changed:
What|Removed |Add
--- Comment #3 from ebotcazou at gcc dot gnu dot org 2007-03-16 06:51
---
> So does the version 3.4.3 actually has the data alignment issues handled ?
Not quite sure what you mean exactly. GCC generates code that conforms to the
alignment requirements of the architecture it will run o
--- Comment #1 from fxcoudert at gcc dot gnu dot org 2007-03-16 06:54
---
Further reduced testcase:
character(5) :: string
print *, transfer(string,"a",5)
end
The ICE happens because the front-end generates a MULT_EXPR with a NULL second
argument, in trans-array.c:
if (size &&
101 - 114 of 114 matches
Mail list logo
