integer*1 k, k2, k3, ka call c_i1(ISHFT(k,-BIT_SIZE(k))) end subroutine c_i1(i) integer*1 i end Compile this at -O1 on ppc, we recieve an error message: /usr/bin/ld: f90-intrinsic-bit.o 8 byte literal section (__TEXT,__literal8) size is not a multiple of 8 bytes collect2: ld returned 1 exit status If we look into the .s file, we have: .literal8 LC0: .byte 0 But that means the even though the type of the constant decl is of size one, the type of the value which is stored there is of size 8 which is just wrong. I think this worked before but I could be wrong.
This is just a reduction of the "gfortran.dg/g77/f90-intrinsic-bit.f" test. reference testresults (not from me): http://gcc.gnu.org/ml/gcc-testresults/2005-01/msg00348.html
*** Bug 19335 has been marked as a duplicate of this bug. ***
Oh, one more thing from PR 19335, -fmerge-constants is what causes it to fail.
Created attachment 7906 [details] Putative patch 2005-01-08 Tobias Schl"uter <tobias.schlueter@physik.uni-muenchen.de> PR fortran/19334 * trans-intrinsic.c (gfc_conv_intrinsic_ishft): Correct type-safety problem.
nope, this patch did not fix it.
Is the reduced testcase also not fixed by the patch, or is this a new issue?
Hm, I've instrumented the tree-dumper to print the widths and signednesses of integer constants, i.e. Index: tree-pretty-print.c =================================================================== RCS file: /cvs/gcc/gcc/gcc/tree-pretty-print.c,v retrieving revision 2.52 diff -u -p -r2.52 tree-pretty-print.c --- tree-pretty-print.c 9 Dec 2004 10:54:36 -0000 2.52 +++ tree-pretty-print.c 9 Jan 2005 12:20:44 -0000 @@ -532,6 +532,18 @@ dump_generic_node (pretty_printer *buffe } else pp_wide_integer (buffer, TREE_INT_CST_LOW (node)); + + if (tree_int_cst_sgn (TYPE_MIN_VALUE (TREE_TYPE (node))) < 0) + { + /* signed type. */ + pp_string (buffer, "_S"); + } + else + { + /* unsigned type. */ + pp_string (buffer, "_U"); + } + pp_wide_integer (buffer, TYPE_PRECISION (TREE_TYPE (node))); break; case REAL_CST: now for gfortran both with and without my patch I get: [tobi@marktplatz tests]$ cat pr19334.f90.t02.original MAIN__ () { int1 k; { int1 C.454 = 0_S8; c_i1 (&C.454); } } c_i1 (i) { (void) 0_U32; which looks correct. The same goes for the optimized dump: [tobi@marktplatz tests]$ cat pr19334.f90.t63.optimized ;; Function MAIN__ (MAIN__) Analyzing Edge Insertions. MAIN__ () { int1 C.454 = 0_S8; int1 k; <bb 0>: c_i1 (&C.454); return; } ;; Function c_i1 (c_i1__) Analyzing Edge Insertions. c_i1 (i) { <bb 0>: return; } Maybe this is an optimizer issue? Or is there something else I should be looking for?
also, I'm on i686, which could be making a difference even though it shouldn't at this stage.
int1 C.454 = 0_S8; The 8 is where the problem is, it is just plainly wrong, it should be 1.
Subject: Re: ISHFT has the wrong type for constant values pinskia at gcc dot gnu dot org wrote: > ------- Additional Comments From pinskia at gcc dot gnu dot org 2005-01-09 15:29 ------- > int1 C.454 = 0_S8; > > The 8 is where the problem is, it is just plainly wrong, it should be 1. > 8 bits, unless I'm completely mistaken.
Then this must be a target bug, I will look into it.
Reduced case (from FP19335) still fails on powerpc-darwin with Tobias' patch. The output from gfortran -fdump-tree-gimple (I hope this was the right thing to do) is the same with and without -fmerge-constants, though the second fails at link time. Here is the tree, with Tobias' modification to the pretty printer: MAIN__ () { int1 k; k = 0_S8; _gfortran_filename = "reduced.f"; _gfortran_line = 3_S32; _gfortran_ioparm.unit = 6_S32; _gfortran_ioparm.list_format = 1_S32; _gfortran_st_write (); { int1 C.417 = 0_S8; _gfortran_transfer_integer (&C.417, 1_S32); } _gfortran_st_write_done (); }
Here is a reduced testcase now without ISHFT: call c_i1(0_1) end
(In reply to comment #12) > The output from gfortran -fdump-tree-gimple (I hope this was the right thing to > do) -fdump-tree-original gives you the output of the frontend, so if the frontend produces crap, it will be in this dump. In your case it didn't make a difference, but usually the gimple dump is much harder to read because the originial generic gets converted to ssa form (single static assignment). IIUC, of course.
(In reply to comment #14) > (In reply to comment #12) > > The output from gfortran -fdump-tree-gimple (I hope this was the right thing to > > do) > > -fdump-tree-original gives you the output of the frontend, so if the frontend > produces crap, it will be in this dump. In your case it didn't make a > difference, but usually the gimple dump is much harder to read because the > originial generic gets converted to ssa form (single static assignment). IIUC, > of course. Actually -fdump-tree-gimple dumps gimple form which is a lowered form of generic (not all the way down but slightly more, in that gimple have a simplified grammar per statement and generic).
Patch here: <http://gcc.gnu.org/ml/gcc-patches/2005-01/msg00491.html>.
Fixed.
Subject: Bug 19334 CVSROOT: /cvs/gcc Module name: gcc Changes by: pinskia@gcc.gnu.org 2005-01-13 00:47:45 Modified files: gcc : ChangeLog gcc/config : darwin.c Log message: 2005-01-12 Andrew Pinski <pinskia@physics.uc.edu> PR target/19334 * config/darwin.c (machopic_select_section): Use TYPE_SIZE_UNIT instead of TYPE_SIZE where we mean the number of bytes. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/ChangeLog.diff?cvsroot=gcc&r1=2.7104&r2=2.7105 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/config/darwin.c.diff?cvsroot=gcc&r1=1.104&r2=1.105