[Bug fortran/30406] New: ICE in LOGICAL(8) functions

[Bug fortran/30406] New: ICE in LOGICAL(8) functions

[dominiq at lps dot ens dot fr]

The following code:

function f(l)
logical(8) :: f
logical(8) :: l
f = .not.l
end function f

gives:

logic_sim.f90: In function 'f':
logic_sim.f90:1: internal compiler error: in emit_move_insn, at expr.c:3276
Please submit a full bug report,
with preprocessed source if appropriate.
See <URL:http://gcc.gnu.org/bugs.html> for instructions.


-- 
           Summary: ICE in LOGICAL(8) functions
           Product: gcc
           Version: 4.3.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: fortran
        AssignedTo: unassigned at gcc dot gnu dot org
        ReportedBy: dominiq at lps dot ens dot fr
GCC target triplet: powerpc-apple-darwin7


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

[Bug fortran/30406] ICE in LOGICAL(8) functions

[burnus at gcc dot gnu dot org]

------- Comment #1 from burnus at gcc dot gnu dot org  2007-01-08 13:33 -------
Which version of gfortran did you use and which options?
I cannot reproduce it with 4.3.0 20070108 on x86_64-unknown-linux-gnu.
(Thus it is either platform specific or a newer or older bug than my version.)


-- 

burnus at gcc dot gnu dot org changed:

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


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

[Bug fortran/30406] ICE in LOGICAL(8) functions

[dominiq at lps dot ens dot fr]

------- Comment #2 from dominiq at lps dot ens dot fr  2007-01-08 13:42 -------
Subject: Re:  ICE in LOGICAL(8) functions

Which version of gfortran did you use and which options?

PPC OSX 10.3, version 4.3.0 20070105 

Note that I did not see the ICE on x86_64-unknown-linux-gnu
version 4.3.0 20061231.


-- 


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

[Bug fortran/30406] ICE in LOGICAL(8) functions

[kargl at gcc dot gnu dot org]

------- Comment #3 from kargl at gcc dot gnu dot org  2007-01-08 17:38 -------
Dominique, can you post the output file created with -fdump-tree-originial.
Like Tobias, I can compile this without a problem.  Here's my dump

f (l)
{
  logical8 __result_f;

  __result_f = *l == 0;
  return __result_f;
}

If yours is the same, we have a target specific problem.


-- 

kargl at gcc dot gnu dot org changed:

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


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

[Bug fortran/30406] ICE in LOGICAL(8) functions

[pinskia at gcc dot gnu dot org]

------- Comment #4 from pinskia at gcc dot gnu dot org  2007-01-08 17:43 -------
(In reply to comment #3)
> Dominique, can you post the output file created with -fdump-tree-originial.
> Like Tobias, I can compile this without a problem.  Here's my dump
> If yours is the same, we have a target specific problem.

Not always, the ICE could be exposed by a target check but it could also be a
generic Fortran front-end bug.
"fdump-tree-originial" does not show the return type or even the types of the
arguments.


-- 

pinskia at gcc dot gnu dot org changed:

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


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

[Bug fortran/30406] ICE in LOGICAL(8) functions

[dominiq at lps dot ens dot fr]

------- Comment #5 from dominiq at lps dot ens dot fr  2007-01-08 19:05 -------
Subject: Re:  ICE in LOGICAL(8) functions

> Dominique, can you post the output file created with -fdump-tree-originial.

Unfotunately I also got an ICE with  -fdump-tree-original.

The crash trace gives:

0   f951        0x000552cc resolve_code + 0x17ac (resolve.c:5093)
1   f951        0x000554d8 resolve_codes + 0x28 (resolve.c:7273)
2   f951        0x00055550 gfc_resolve + 0x2c (resolve.c:7301)
3   f951        0x000494f8 gfc_parse_file + 0x210 (parse.c:3250)
4   f951        0x0006a914 gfc_be_parse_file + 0x1c (f95-lang.c:307)
5   f951        0x000f9274 toplev_main + 0x814 (toplev.c:1031)
6   f951        0x00002824 _start + 0x188 (crt.c:267)
7   dyld        0x8fe1a31c _dyld_start + 0x64

Could not it be some missing definition for logical(8) on PPC Darwin?


-- 


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

[Bug fortran/30406] ICE in LOGICAL(8) functions

[dominiq at lps dot ens dot fr]

------- Comment #6 from dominiq at lps dot ens dot fr  2007-01-08 20:19 -------
Subject: Re:  ICE in LOGICAL(8) functions

I got the same error with OSX 10.4, gcc version 4.2.0 20060617.
I was wrong in my previous mail, -fdump-tree-original gives:

f (l)
{
  logical8 __result_f;

  __result_f = *l == 0;
  return __result_f;
}

looks like yours.


-- 


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

[Bug fortran/30406] ICE in LOGICAL(8) functions

[sgk at troutmask dot apl dot washington dot edu]

------- Comment #7 from sgk at troutmask dot apl dot washington dot edu  2007-01-08 20:34 -------
Subject: Re:  ICE in LOGICAL(8) functions

On Mon, Jan 08, 2007 at 08:19:10PM -0000, dominiq at lps dot ens dot fr wrote:
> 
> I got the same error with OSX 10.4, gcc version 4.2.0 20060617.
> I was wrong in my previous mail, -fdump-tree-original gives:
> 
> f (l)
> {
>   logical8 __result_f;
> 
>   __result_f = *l == 0;
>   return __result_f;
> }
> 
> looks like yours.
> 

Can you verify that OSX on PPC has logical(8)?  If you have
integer(8), you should logical(8).

   logical(8) x
   x = .true.
   print *, x
   end 

should be sufficient.

Unfortunately, I don't have OSX or PPC hardware.


-- 


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

[Bug fortran/30406] ICE in LOGICAL(8) functions

[dominiq at lps dot ens dot fr]

------- Comment #8 from dominiq at lps dot ens dot fr  2007-01-08 20:49 -------
Subject: Re:  ICE in LOGICAL(8) functions

> Can you verify that OSX on PPC has logical(8)?

I have tested:

logical(8) :: l1, l2
l1 = .true.
l2 = .false.
print *, l1.neqv.l2, kind(l1.neqv.l2)
end

it returns 

T           8

as it should.

I have also tested logical(n), with n = 1, 2, 4 without ICE
for the function test.


-- 


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

[Bug fortran/30406] ICE in LOGICAL(8) functions

[fxcoudert at gcc dot gnu dot org]

------- Comment #9 from fxcoudert at gcc dot gnu dot org  2007-01-09 16:13 -------
Confirmed on MacOS 10.4.8, using gfortran 4.3.0 20070102 (experimental). Cannot
do more at the moment.


-- 

fxcoudert at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |fxcoudert at gcc dot gnu dot
                   |                            |org
             Status|UNCONFIRMED                 |NEW
     Ever Confirmed|0                           |1
           Keywords|                            |ice-on-valid-code
   Last reconfirmed|0000-00-00 00:00:00         |2007-01-09 16:13:11
               date|                            |


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

[Bug fortran/30406] ICE in LOGICAL(8) functions

[dominiq at lps dot ens dot fr]

------- Comment #10 from dominiq at lps dot ens dot fr  2007-01-09 22:06 -------
Subject: Re:  ICE in LOGICAL(8) functions

First, the crash report I have posted yesterday has nothing to do
with this bug that is really an internal compiler error (caught
within the compiler) and not a crash.

Second, what is the C equivalent of logical(8)? I am wondering
if the same ICE occurs in the equivalent C code.


-- 


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

[Bug fortran/30406] ICE in LOGICAL(8) functions

[pinskia at gcc dot gnu dot org]

------- Comment #11 from pinskia at gcc dot gnu dot org  2007-01-09 22:08 -------
(In reply to comment #10)
> Second, what is the C equivalent of logical(8)? I am wondering
> if the same ICE occurs in the equivalent C code.

In C (and C++) Boolean types only have one size, on ppc-darwin that size is 4
(on the rest of the normal targets it is 1).

I am going to look into this when I get a chance and also figure out why my
darwin box is not working :).


-- 


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

[Bug fortran/30406] ICE in LOGICAL(8) functions

[dominiq at lps dot ens dot fr]

------- Comment #12 from dominiq at lps dot ens dot fr  2007-01-09 22:10 -------
Subject: Re:  ICE in LOGICAL(8) functions

> In C (and C++) Boolean types only have one size ...

Too bad!-)


-- 


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

[Bug fortran/30406] ICE in LOGICAL(8) functions

[fxcoudert at gcc dot gnu dot org]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 3081 bytes --]



------- Comment #13 from fxcoudert at gcc dot gnu dot org  2007-01-10 06:43 -------
$ cat > a.f90
function f(l)
logical(8) :: f
logical(8) :: l
f = .not.l
end function f
$ gfortran a.f90 
a.f90: In function ‘f’:
a.f90:1: internal compiler error: in emit_move_insn, at expr.c:3276
$ gfortran -v
Using built-in specs.
Target: powerpc-apple-darwin8.8.0
Configured with: ../trunk/configure --prefix=/Users/fx/gfortran/devel/irun
--enable-languages=c,fortran --with-gmp=/Users/fx/gfortran/gfortran_libs/macosx
--disable-bootstrap
Thread model: posix
gcc version 4.3.0 20070109 (experimental)


The backtrace is:

Breakpoint 1, fancy_abort (file=0x6b45d8 "../../trunk/gcc/expr.c", line=3276,
function=0x6b4920 "emit_move_insn") at ../../trunk/gcc/diagnostic.c:642
642       internal_error ("in %s, at %s:%d", function, trim_filename (file),
line);
(gdb) where
#0  fancy_abort (file=0x6b45d8 "../../trunk/gcc/expr.c", line=3276,
function=0x6b4920 "emit_move_insn") at ../../trunk/gcc/diagnostic.c:642
#1  0x00207778 in emit_move_insn (x=0x42e65b80, y=0x42e65af0) at
../../trunk/gcc/expr.c:3275
#2  0x00475e7c in expand_value_return (val=0x42e65af0) at
../../trunk/gcc/stmt.c:1548
#3  0x004799fc in expand_return (retval=0x42e78640) at
../../trunk/gcc/stmt.c:1732
#4  0x00204d28 in expand_expr_real_1 (exp=0x42e78540, target=0x42e0dbb0,
tmode=VOIDmode, modifier=EXPAND_NORMAL, alt_rtl=0x0) at
../../trunk/gcc/expr.c:8629
#5  0x00206478 in expand_expr_real (exp=0x42e78540, target=0x42e0dbb0,
tmode=VOIDmode, modifier=EXPAND_NORMAL, alt_rtl=0x0) at
../../trunk/gcc/expr.c:6717
#6  0x00478ef8 in expand_expr_stmt (exp=0x42e78540) at
../../trunk/gcc/expr.h:496
#7  0x00481450 in expand_gimple_basic_block (bb=0x42e0f140) at
../../trunk/gcc/cfgexpand.c:1530
#8  0x00481df0 in tree_expand_cfg () at ../../trunk/gcc/cfgexpand.c:1800
#9  0x002c434c in execute_one_pass (pass=0x7b3074) at
../../trunk/gcc/passes.c:942
#10 0x002c44c8 in execute_pass_list (pass=0x7b3074) at
../../trunk/gcc/passes.c:990
#11 0x002b4aa4 in tree_rest_of_compilation (fndecl=0x42e79200) at
../../trunk/gcc/tree-optimize.c:543
#12 0x0017d48c in cgraph_expand_function (node=0x42e0b700) at
../../trunk/gcc/cgraphunit.c:989
#13 0x0017d888 in cgraph_assemble_pending_functions () at
../../trunk/gcc/cgraphunit.c:358
#14 0x0017df2c in cgraph_finalize_function (decl=0x42e79200, nested=0 '\0') at
../../trunk/gcc/cgraphunit.c:476
#15 0x0008dc2c in gfc_generate_function_code (ns=0x43012e00) at
../../trunk/gcc/fortran/trans-decl.c:3323
#16 0x0004d164 in gfc_parse_file () at ../../trunk/gcc/fortran/parse.c:3263
#17 0x00070130 in gfc_be_parse_file (set_yydebug=7030232) at
../../trunk/gcc/fortran/f95-lang.c:307


-- 

fxcoudert at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
      Known to fail|                            |4.3.0
   Last reconfirmed|2007-01-09 16:13:11         |2007-01-10 06:43:58
               date|                            |


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

[Bug fortran/30406] ICE in LOGICAL(8) functions

[fxcoudert at gcc dot gnu dot org]

------- Comment #14 from fxcoudert at gcc dot gnu dot org  2007-01-10 08:11 -------
In emit_move_insn, the failing assert is:

(gdb) l 3275
3270    {
3271      enum machine_mode mode = GET_MODE (x);
3272      rtx y_cst = NULL_RTX;
3273      rtx last_insn, set;
3274
3275      gcc_assert (mode != BLKmode
3276                  && (GET_MODE (y) == mode || GET_MODE (y) == VOIDmode));
3277
3278      if (CONSTANT_P (y))
3279        {
(gdb) p debug_rtx(x)
(reg:SI 122 [ <result> ])
$14 = void
(gdb) p debug_rtx(y)
(reg:DI 119 [ D.951 ])
$15 = void

Clearly, the modes are incompatible. When cgraph_finalize_function is called
(frame 14), decl is:

(gdb) p debug_tree(decl)
 <function_decl 0x42e79200 f
    type <function_type 0x42e77c40
        type <boolean_type 0x42e218c0 logical8 public unsigned DI
            size <integer_cst 0x42e0a8a0 constant invariant 64>
            unit size <integer_cst 0x42e0a8c0 constant invariant 8>
            align 64 symtab 0 alias set -1 canonical type 0x42e218c0 precision
1 min <integer_cst 0x42e23080 0> max <integer_cst 0x42e230c0 1>
reference_to_this <reference_type 0x42e77bd0>>
        SI
        size <integer_cst 0x42e0a700 constant invariant 32>
        unit size <integer_cst 0x42e0a3c0 constant invariant 4>
        align 32 symtab 0 alias set -1 structural equality
        arg-types <tree_list 0x42e78400 value <reference_type 0x42e77bd0>
            chain <tree_list 0x42e78420 value <void_type 0x42e199a0 void>>>>
    public static SI file a.f90 line 1 initial <block 0x41d71480>
    arguments <parm_decl 0x42e15120 l
        type <reference_type 0x42e77bd0 type <boolean_type 0x42e218c0 logical8>
            unsigned SI size <integer_cst 0x42e0a700 32> unit size <integer_cst
0x42e0a3c0 4>
            align 32 symtab 0 alias set -1 canonical type 0x42e77bd0>
        readonly used unsigned SI file a.f90 line 1 size <integer_cst
0x42e0a700 32> unit size <integer_cst 0x42e0a3c0 4>
        align 32 context <function_decl 0x42e79200 f> initial <reference_type
0x42e77bd0>
        (mem/f/c/i:SI (reg/f:SI 114 virtual-incoming-args) [0 l+0 S4 A32])
arg-type <reference_type 0x42e77bd0>
        incoming-rtl (reg:SI 3 r3 [ l ])>
    result <result_decl 0x42e150c0 D.946 type <boolean_type 0x42e218c0
logical8>
        unsigned ignored regdecl DI file a.f90 line 1 size <integer_cst
0x42e0a8a0 64> unit size <integer_cst 0x42e0a8c0 8>
        align 64 context <function_decl 0x42e79200 f>
        (reg:SI 122 [ <result> ])>
    (mem:SI (symbol_ref:SI ("f_") [flags 0x403] <function_decl 0x42e79200 f>)
[0 S4 A8])
    saved-insns 0x42e14240 chain <function_decl 0x42e79180
_gfortran_st_set_nml_var_dim>>

I think the problem might be related to "(reg:SI 120 [ <result> ])" in the
result section, but I'm not a tree expert enough to be positive.

PS: the same testcase works when compiled with -m64. It can also be reduced to:
function f()
  logical(8) :: f
  f=.false._8
end function f


-- 

fxcoudert at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Last reconfirmed|2007-01-10 06:43:58         |2007-01-10 08:11:39
               date|                            |


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

[Bug fortran/30406] ICE in LOGICAL(8) functions

[pinskia at gcc dot gnu dot org]

------- Comment #15 from pinskia at gcc dot gnu dot org  2007-01-10 09:07 -------
The result decl should have a RTL of a DI mode:
<result_decl 0x42e150c0 D.946 type <boolean_type 0x42e218c0
logical8>
        unsigned ignored regdecl DI file a.f90 line 1 size <integer_cst
0x42e0a8a0 64> unit size <integer_cst 0x42e0a8c0 8>
        align 64 context <function_decl 0x42e79200 f>
        (reg:SI 122 [ <result> ])>

The mode of the decl is correct but the RTL of the decl is incorrect.  I will
look into this more this weekend.


-- 


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

[Bug fortran/30406] ICE in LOGICAL(8) functions

[pinskia at gcc dot gnu dot org]

------- Comment #16 from pinskia at gcc dot gnu dot org  2007-01-10 22:51 -------
The type is correct when the decl is created:
Breakpoint 3, build_decl_stat (code=RESULT_DECL, name=0x0, type=0xb7c55384) at
../../gcc/tree.c:3250
3250      t = make_node_stat (code PASS_MEM_STAT);
(gdb) p debug_generic_expr (type)
logical8
$1 = void
(gdb) p debug_tree (type)
 <boolean_type 0xb7c55384 logical8 public unsigned DI
    size <integer_cst 0xb7c3b520 type <integer_type 0xb7c4d064 bit_size_type>
constant invariant 64>
    unit size <integer_cst 0xb7c3b540 type <integer_type 0xb7c4d000> constant
invariant 8>
    align 64 symtab 0 alias set -1 canonical type 0xb7c55384 precision 1 min
<integer_cst 0xb7c3bb60 0> max <integer_cst 0xb7c3bba0 1> reference_to_this
<reference_type 0xb7ca8320>>


-- 


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

[Bug fortran/30406] ICE in LOGICAL(8) functions

[pinskia at gcc dot gnu dot org]

------- Comment #17 from pinskia at gcc dot gnu dot org  2007-01-10 22:56 -------
hard_function_value returns the wrong rtl ...


-- 


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

[Bug target/30406] ICE in LOGICAL(8) functions

[pinskia at gcc dot gnu dot org]

------- Comment #18 from pinskia at gcc dot gnu dot org  2007-01-10 23:02 -------
rs6000_function_value looks at TYPE_PRECISION ....


-- 

pinskia at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
          Component|fortran                     |target


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

[Bug target/30406] ICE in LOGICAL(8) functions

[pinskia at gcc dot gnu dot org]

------- Comment #19 from pinskia at gcc dot gnu dot org  2007-01-10 23:04 -------
  if ((INTEGRAL_TYPE_P (valtype)
       && TYPE_PRECISION (valtype) < BITS_PER_WORD)
      || POINTER_TYPE_P (valtype))
    mode = TARGET_32BIT ? SImode : DImode;
  else
    mode = TYPE_MODE (valtype);
--------------------------
I think this should be written as:
  if ((INTEGRAL_TYPE_P (valtype)
       && TYPE_PRECISION (valtype) < BITS_PER_WORD)
      || POINTER_TYPE_P (valtype))
    mode = TARGET_32BIT ? SImode : DImode;
  else
    mode = TYPE_MODE (valtype);


-- 


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

[Bug target/30406] ICE in LOGICAL(8) functions

[pinskia at gcc dot gnu dot org]

------- Comment #20 from pinskia at gcc dot gnu dot org  2007-01-10 23:04 -------
Ignore that last comment (though that is where the problem is).


-- 


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

[Bug target/30406] ICE in LOGICAL(8) functions

[pinskia at gcc dot gnu dot org]

------- Comment #21 from pinskia at gcc dot gnu dot org  2007-01-10 23:09 -------
Happens on all PPC including GNU/Linux.


-- 

pinskia at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
 GCC target triplet|powerpc-apple-darwin        |powerpc-*


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

[Bug target/30406] ICE in LOGICAL(8) functions

[pinskia at gcc dot gnu dot org]

------- Comment #22 from pinskia at gcc dot gnu dot org  2007-01-10 23:20 -------
It should be rewritten as:
  if ((INTEGRAL_TYPE_P (valtype)
       && GET_MODE_BITSIZE (TYPE_MODE (valtype)) < BITS_PER_WORD)
      || POINTER_TYPE_P (valtype))
    mode = TARGET_32BIT ? SImode : DImode;
  else
    mode = TYPE_MODE (valtype);

TYPE_PRECISION is incorrect as it says the numbers of bits used and not the
number of bits for the type itself.


-- 


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

[Bug target/30406] ICE in LOGICAL(8) functions

[fxcoudert at gcc dot gnu dot org]

------- Comment #23 from fxcoudert at gcc dot gnu dot org  2007-01-11 08:08 -------
The same code seems to be present in 4.1 and 4.2 branches. Andrew, would you
mind include add a testcase to testsuite/gfortran.dg/ when you commit a patch?
(if Andrew doesn't commit the patch, same request for the person actually doing
it :)


-- 

fxcoudert at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
      Known to fail|4.3.0                       |4.3.0 4.2.0 4.1.2


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

[Bug target/30406] ICE in LOGICAL(8) functions

[dominiq at lps dot ens dot fr]

------- Comment #24 from dominiq at lps dot ens dot fr  2007-01-13 17:09 -------
I have applied the change to the latest snapshot (4.3.0 20070112) and the tests
compile now without error on OSX 10.3.9.

Thanks.


-- 


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

[Bug target/30406] ICE in LOGICAL(8) functions

[dominiq at lps dot ens dot fr]

------- Comment #25 from dominiq at lps dot ens dot fr  2007-01-29 15:13 -------
What is the fate of the patch in comment #22?


-- 


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

[Bug target/30406] ICE in LOGICAL(8) functions

[fxcoudert at gcc dot gnu dot org]

------- Comment #26 from fxcoudert at gcc dot gnu dot org  2007-01-29 15:30 -------
(In reply to comment #25)
> What is the fate of the patch in comment #22?

I suppose Andrew should submit it for review by the PowerPC maintainers. If he
doesn't have time, you could do it (unless he objects): bootstrap and regtest
the patch (complete regtest, not only Fortran), post the patch (with ChangeLog
entry and a testcase for addition to our testsuite) to gcc-patches, CCing the
PowerPC maintainers (Geoff Keating and David Edelsohn), asking for it to be
reviewed.


-- 

fxcoudert at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Last reconfirmed|2007-01-10 08:11:39         |2007-01-29 15:30:59
               date|                            |


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

[Bug target/30406] ICE in LOGICAL(8) functions

[pinskia at gcc dot gnu dot org]

------- Comment #27 from pinskia at gcc dot gnu dot org  2007-01-29 17:57 -------
(In reply to comment #26)
> (In reply to comment #25)
> > What is the fate of the patch in comment #22?
> 
> I suppose Andrew should submit it for review by the PowerPC maintainers.

I will try to regest test it later today on powerpc-linux-gnu (on a PS3
really).


-- 


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

[Bug target/30406] ICE in LOGICAL(8) functions

[dominiq at lps dot ens dot fr]

------- Comment #28 from dominiq at lps dot ens dot fr  2007-01-29 20:47 -------
Subject: Re:  ICE in LOGICAL(8) functions

> I suppose Andrew should submit it for review by the PowerPC maintainers.
> If he doesn't have time, you could do it (unless he objects):

Never do today what someone else can do tomorrow?

> bootstrap and regtest the patch (complete regtest, not only Fortran),

Applied to gcc-4.3-20070126 and built through fink. I only learnt two 
weeks ago how to run "test_installed", so I am very new in the regtest 
game.  The summaries follow:

=== gcc Summary ===

# of expected passes            43171
# of unexpected failures        39
# of unexpected successes       3
# of expected failures          109
# of unresolved testcases       2
# of untested testcases         28
# of unsupported tests          460
/sw/lib/gcc4//bin/gcc  version 4.3.0 20070126 (experimental)

WARNING: Couldn't find the global config file.
Test Run By dominiq on Mon Jan 29 19:52:53 2007
Native configuration is powerpc-apple-darwin7.9.0

=== g++ Summary ===

# of expected passes            12135
# of unexpected failures        1427
# of unexpected successes       3
# of expected failures          80
# of unresolved testcases       90
# of unsupported tests          131
/sw/lib/gcc4//bin/g++  version 4.3.0 20070126 (experimental)

WARNING: Couldn't find the global config file.
Test Run By dominiq on Mon Jan 29 20:18:55 2007
Native configuration is powerpc-apple-darwin7.9.0

Here the results are probably due to a hack I am applying to avoid 
spurious warning at link time. I have also several messages such as:

/sw/lib/odcctools/bin/ld: warning can't open dynamic library: 
/libgcc_s.1.dylib referenced from: 
/sw/lib/gcc4/lib/gcc/powerpc-apple-darwin7/4.3.0/../../../libstdc++.dylib 
(checking for undefined symbols may be affected) (No such file or directory,
errno = 2)

The lib should be /sw/lib/gcc4/lib/libgcc_s.1.dylib, I'ld have to 
investigate the origin of the problem

=== gfortran Summary ===

# of expected passes            15904
# of unexpected failures        24
# of expected failures          7
# of unsupported tests          57
/sw/lib/gcc4//bin/gfortran  version 4.3.0 20070126 (experimental)

WARNING: Couldn't find the global config file.
Test Run By dominiq on Mon Jan 29 21:12:00 2007
Native configuration is powerpc-apple-darwin7.9.0

Note that I moved away the files 
gcc/testsuite/gfortran.dg/actual_array_interface_1.f90
(which is empty) and
gcc/testsuite/gfortran.dg/intrinsic_actual_2.f90
whose executable is hanging under OSX (see my post:
http://gcc.gnu.org/ml/fortran/2006-11/msg00394.html)

Note also that beside the files large_real_kind_2.F90 and
large_real_kind_form_io_2.f90, I have also some failures such as:

WARNING: gfortran.dg/iso_fortran_env_3.f90  -O0  compilation failed to produce 
executable

I do not see when compiling the file directly (will all the failing 
options I have tested). The errors are:

  use iso_fortran_env, foo => numeric_storage_size
                     1
Error: Symbol 'numeric_storage_size' referenced at (1) not found in module
'iso_fortran_env'
/Users/dominiq/test/gcc-4.3-20070126/gcc/testsuite/gfortran.dg/iso_fortran_env_3.f90:18.29:

  use iso_fortran_env, only : numeric_storage_size, character_storage_size
                            1
Error: Symbol 'numeric_storage_size' referenced at (1) not found in module
'iso_fortran_env'
/Users/dominiq/test/gcc-4.3-20070126/gcc/testsuite/gfortran.dg/iso_fortran_env_3.f90:18.51:

  use iso_fortran_env, only : numeric_storage_size, character_storage_size
                                                  1
Error: Symbol 'character_storage_size' referenced at (1) not found in module
'iso_fortran_env'
compiler exited with status 1

=== objc Summary ===

# of expected passes            2976
# of unsupported tests          1
/sw/lib/gcc4//bin/gcc  version 4.3.0 20070126 (experimental)

Note that I have several errors such as:

Running
/Users/dominiq/test/gcc-4.3-20070126/gcc/testsuite/objc.dg/gnu-encoding/gnu-encoding.exp
...
ERROR: tcl error sourcing
/Users/dominiq/test/gcc-4.3-20070126/gcc/testsuite/objc.dg/gnu-encoding/gnu-encoding.exp.
ERROR: can't read "HOSTCC": no such variable
    while executing
"remote_exec host "$HOSTCC $HOSTCFLAGS $generator_cmd""
    invoked from within
"set status [remote_exec host "$HOSTCC $HOSTCFLAGS $generator_cmd"]"
    (file
"/Users/dominiq/test/gcc-4.3-20070126/gcc/testsuite/objc.dg/gnu-encoding/gnu-encoding.exp"
line 40)
    invoked from within
"source
/Users/dominiq/test/gcc-4.3-20070126/gcc/testsuite/objc.dg/gnu-encoding/gnu-encoding.exp"
    ("uplevel" body line 1)
    invoked from within
"uplevel #0 source
/Users/dominiq/test/gcc-4.3-20070126/gcc/testsuite/objc.dg/gnu-encoding/gnu-encoding.exp"
    invoked from within
"catch "uplevel #0 source $test_file_name""

> post the patch 

--- gcc-4.3-20070126/gcc/config/rs6000/rs6000.c Thu Jan 25 21:32:06 2007
+++ gcc-4.3-20070127/gcc/config/rs6000/rs6000.c Sat Jan 27 00:06:05 2007
@@ -20325,7 +20325,7 @@
     }

   if ((INTEGRAL_TYPE_P (valtype)
-       && TYPE_PRECISION (valtype) < BITS_PER_WORD)
+       && GET_MODE_BITSIZE (TYPE_MODE (valtype)) < BITS_PER_WORD)
       || POINTER_TYPE_P (valtype))
     mode = TARGET_32BIT ? SImode : DImode;
   else

> (with ChangeLog entry 

I am not sure to be ready to count spaces!

> and a testcase for addition to our testsuite) 

! { dg-do compile }
! This checks the fix for PR30406.
!
! Contributed by Francois-Xavier Coudert <fxcoudert@gcc.gnu.org>
!===============================================================

function f()
  logical(8) :: f
  f=.false._8
end function f

> to gcc-patches,

I'll have to learn the cannonical form!

> CCing the PowerPC maintainers (Geoff Keating and David Edelsohn), asking
> for it to be reviewed.

I am refraining to comment.


-- 


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

[Bug target/30406] ICE in LOGICAL(8) functions

[fxcoudert at gcc dot gnu dot org]

------- Comment #29 from fxcoudert at gcc dot gnu dot org  2007-02-10 17:24 -------
Hi Dominique,

Patch posted (http://gcc.gnu.org/ml/gcc-patches/2007-02/msg00927.html), so you
look how it's done. Patches in PR tend to not get reviewed, so we need people
to post them to the list. Yes, it takes time, but it's useful if you want bugs
fixed.


-- 

fxcoudert at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Keywords|                            |patch
   Last reconfirmed|2007-01-29 15:30:59         |2007-02-10 17:24:22
               date|                            |


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

[Bug target/30406] ICE in LOGICAL(8) functions

[dominiq at lps dot ens dot fr]

------- Comment #30 from dominiq at lps dot ens dot fr  2007-02-10 22:12 -------
Subject: Re:  ICE in LOGICAL(8) functions

Francois-Xavier,

Thanks for the work.  In order to improve future contributions,
I have a few questions:

(1) do you need a regtesting of the patch on 4.2 and OSX 10.4?
Will 4.2.0 20070124 good enough or should I upgrade to a more
recent version?

(2) > Patches in PR tend to not get reviewed, so we need people
> to post them to the list.

Does this mean, that when I fill a PR, I should put
fortran@gcc.gnu.org in the cc list?

(3) Can people like me post on gcc-patches@gcc.gnu.org?


-- 


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

[Bug target/30406] ICE in LOGICAL(8) functions

[fxcoudert at gcc dot gnu dot org]

------- Comment #31 from fxcoudert at gcc dot gnu dot org  2007-02-10 22:21 -------
(In reply to comment #30)
> (1) do you need a regtesting of the patch on 4.2 and OSX 10.4?
> Will 4.2.0 20070124 good enough or should I upgrade to a more
> recent version?

It's OK. The change is simple and that part of code (this part of the powerpc
backend) hasn't changed for a long time.

>> (2) Patches in PR tend to not get reviewed, so we need people
>> to post them to the list.
> 
> Does this mean, that when I fill a PR, I should put
> fortran@gcc.gnu.org in the cc list?

No, otherwise the list will be flooded with bugzilla mail and we will all get
lost reading through it. bugzilla PRs are fine because the itemize problems and
gather the advances in the investigations in one central place. We don't want
everyone's attention spreaded on all the problems, because that would be very
inefficient: we want people to pick a task, and go for it, with help of a few
others.

But, when a patch is designed for a bug, then its needs to be reviewed by a
maintainer of the relevant part of the compiler, and approved. This means, it
needs to be posted to the gcc-patches mailing-list, because maintainers
(although they go through the PRs every now and then) can't keep an eye on all
of them.

> (3) Can people like me post on gcc-patches@gcc.gnu.org?

Anyone who has a patch that he wants reviewed can post it on gcc-patches.
Usually, one posts patches of one's own design, but not necessary (as long as
the person who designed the patch agrees with it): it can help relieve people
who created the patch of some of the administrative burden, like the
regtesting.

You'll note there are certain contraints on patch submission, to make sure we
keep a certain standard in patches and don't waste reviewers' time. Building,
regtesting, adding testcases and ChangeLog entries is part of that. You can
read a few gcc-patches discussions on the web archives to get a better idea of
how it works.


-- 


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

[Bug target/30406] ICE in LOGICAL(8) functions

[pinskia at gcc dot gnu dot org]

------- Comment #32 from pinskia at gcc dot gnu dot org  2007-02-10 22:42 -------
This was on my list of patches to submit today really, I finally actually got
time to able to submit patches today.  I was able to submit two other patches
today and I have another one in testing right now.


-- 


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

[Bug target/30406] ICE in LOGICAL(8) functions

[dominiq at lps dot ens dot fr]

------- Comment #33 from dominiq at lps dot ens dot fr  2007-02-10 22:44 -------
Subject: Re:  ICE in LOGICAL(8) functions

Thanks for the advice, I'll try to follow it next time.


-- 


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

[Bug target/30406] ICE in LOGICAL(8) functions

[fxcoudert at gcc dot gnu dot org]

------- Comment #34 from fxcoudert at gcc dot gnu dot org  2007-02-13 19:04 -------
(In reply to comment #32)
> This was on my list of patches to submit today really, I finally actually got
> time to able to submit patches today.  I was able to submit two other patches
> today and I have another one in testing right now.

Patch approved here: http://gcc.gnu.org/ml/gcc-patches/2007-02/msg01053.html,
but I'm in no position to commit now (until March 5th).


-- 


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

[Bug target/30406] ICE in LOGICAL(8) functions

[fxcoudert at gcc dot gnu dot org]

------- Comment #35 from fxcoudert at gcc dot gnu dot org  2007-03-04 08:10 -------
Subject: Bug 30406

Author: fxcoudert
Date: Sun Mar  4 08:10:25 2007
New Revision: 122523

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=122523
Log:
        PR target/30406

        * config/rs6000/rs6000.c (rs6000_function_value): Look at bit size
        instead of precision.

        * gfortran.dg/logical_3.f90: New test.

Added:
    trunk/gcc/testsuite/gfortran.dg/logical_3.f90
Modified:
    trunk/gcc/ChangeLog
    trunk/gcc/config/rs6000/rs6000.c
    trunk/gcc/testsuite/ChangeLog


-- 


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

[Bug target/30406] [4.1/4.2 only] ICE in LOGICAL(8) functions

[fxcoudert at gcc dot gnu dot org]

-- 

fxcoudert at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
         AssignedTo|unassigned at gcc dot gnu   |fxcoudert at gcc dot gnu dot
                   |dot org                     |org
             Status|NEW                         |ASSIGNED
      Known to fail|4.3.0 4.2.0 4.1.2           |4.2.0 4.1.2
      Known to work|                            |4.3.0
   Last reconfirmed|2007-02-10 17:24:22         |2007-03-04 08:11:37
               date|                            |
            Summary|ICE in LOGICAL(8) functions |[4.1/4.2 only] ICE in
                   |                            |LOGICAL(8) functions
   Target Milestone|---                         |4.2.0


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

[Bug target/30406] [4.1/4.2 only] ICE in LOGICAL(8) functions

[mmitchel at gcc dot gnu dot org]

-- 

mmitchel at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Priority|P3                          |P5


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

[Bug target/30406] [4.1/4.2 only] ICE in LOGICAL(8) functions

[fxcoudert at gcc dot gnu dot org]

------- Comment #36 from fxcoudert at gcc dot gnu dot org  2007-03-08 12:35 -------
Subject: Bug 30406

Author: fxcoudert
Date: Thu Mar  8 12:34:59 2007
New Revision: 122697

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=122697
Log:
        PR target/30406
        * config/rs6000/rs6000.c (rs6000_function_value): Look at bit size
        instead of precision.
        * gfortran.dg/logical_3.f90: New test.

        PR libfortran/31001
        * intrinsics/pack_generic.c (pack_internal): Add special checks
        for zero-sized arrays.
        * gfortran.dg/zero_sized_3.f90: New test.

Added:
    branches/gcc-4_2-branch/gcc/testsuite/gfortran.dg/logical_3.f90
      - copied unchanged from r122523,
trunk/gcc/testsuite/gfortran.dg/logical_3.f90
    branches/gcc-4_2-branch/gcc/testsuite/gfortran.dg/zero_sized_3.f90
      - copied unchanged from r122507,
trunk/gcc/testsuite/gfortran.dg/zero_sized_3.f90
Modified:
    branches/gcc-4_2-branch/gcc/ChangeLog
    branches/gcc-4_2-branch/gcc/config/rs6000/rs6000.c
    branches/gcc-4_2-branch/gcc/testsuite/ChangeLog
    branches/gcc-4_2-branch/libgfortran/ChangeLog
    branches/gcc-4_2-branch/libgfortran/intrinsics/pack_generic.c


-- 


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

[Bug target/30406] [4.1 only] ICE in LOGICAL(8) functions

[burnus at gcc dot gnu dot org]

------- Comment #37 from burnus at gcc dot gnu dot org  2007-03-08 13:24 -------
Can this be closed or do you intent to backport it to 4.1?


-- 

burnus at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
            Summary|[4.1/4.2 only] ICE in       |[4.1 only] ICE in LOGICAL(8)
                   |LOGICAL(8) functions        |functions


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

[Bug target/30406] [4.1 only] ICE in LOGICAL(8) functions

[fxcoudert at gcc dot gnu dot org]

------- Comment #38 from fxcoudert at gcc dot gnu dot org  2007-03-08 13:33 -------
No backport to 4.1, said the maintainer. Closing accordingly.


-- 

fxcoudert at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|ASSIGNED                    |RESOLVED
      Known to fail|4.2.0 4.1.2                 |4.1.2
      Known to work|4.3.0                       |4.3.0 4.2.0
         Resolution|                            |FIXED


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