From: Orion P. <or...@co...> - 2009-02-11 21:01:52
|
Fedora is moving to gcc 4.4 with Fedora 11. I'm trying to build plplot 5.9.2 and getting the following error: 3/ 18 Testing examples_f77 Test command: /bin/bash -c EXAMPLES_DIR=/builddir/build/BUILD/plplot-5.9.2/fedora/examples\ SRC_EXAMPLES_DIR=/builddir/build/BUILD/plplot-5.9.2/examples\ PLPLOT_LIB=/builddir/build/BUILD/plplot-5.9.2/data/\ ./plplot-test.sh\ --verbose\ --device=psc\ --front-end=f77 Test timeout computed to be: 1500 Testing front-end f77 ... x23f fci = 0xbf947ae1, font name pointer = NULL *** PLPLOT ERROR, ABORTING OPERATION *** proc_str: FCI inconsistent with Type1Lookup; internal PLplot error, aborting operation This is on ppc/ppc64 only. Runs find on i386/x86_64. Could be a gcc issue. Who knows. If I break at the plabort call, this is where I'm at: Starting program: /builddir/build/BUILD/plplot-5.9.2/fedora/examples/f77/x23f -dev psc -o test.ps For example 23 prior to page 12 the FCI is 0x80000000 For example 23 prior to page 12 the font family, style and weight are sans-serif upright medium fci = 0xbf947ae1, font name pointer = NULL Breakpoint 2, proc_str (pls=0x400000da300, args=0xfffffffdc60) at /builddir/build/BUILD/plplot-5.9.2/drivers/ps.c:765 765 plabort("proc_str: FCI inconsistent with Type1Lookup; " (gdb) print *pls $9 = {ipls = 0, level = 3, verbose = 0, debug = 0, initialized = 1, dev_initialized = 1, program = 0x1001cb10 "/builddir/build/BUILD/plplot-5.9.2/fedora/examples/f77/x23f", icol0 = 15, ncol0 = 16, icol1 = 0, ncol1 = 128, ncp1 = 6, curcmap = 0, curcolor = {r = 255 '�', g = 255 '�', b = 255 '�', a = 1, name = 0x0}, tmpcolor = {r = 0 '\0', g = 0 '\0', b = 0 '\0', a = 0, name = 0x0}, cmap0 = 0x10020b40, cmap1 = 0x10020cd0, cmap1cp = {{h = 260, l = 0.5, s = 1, p = 0, a = 1, rev = 0}, {h = 260, l = 0.10000000000000001, s = 1, p = 0.44, a = 1, rev = 0}, {h = 260, l = 0.01, s = 1, p = 0.5, a = 1, rev = 0}, { h = 0, l = 0.01, s = 1, p = 0.5, a = 1, rev = 0}, {h = 0, l = 0.10000000000000001, s = 1, p = 0.56000000000000005, a = 1, rev = 0}, { h = 0, l = 0.5, s = 1, p = 1, a = 1, rev = 0}, {h = 0, l = 0, s = 0, p = 0, a = 0, rev = 0} <repeats 250 times>}, width = 0, widthset = 0, widthlock = 0, arrow_x = 0x10021c20, arrow_y = 0x10021c60, arrow_npts = 6, arrow_fill = 0, dispatch_table = 0x10020390, plbuf_read = 0, plbuf_write = 0, device = 12, dev_minor = 0, termin = 0, graphx = 0, nopause = 0, color = 1, colorset = 0, family = 0, member = 0, finc = 0, fflen = 0, bytemax = 0, famadv = 0, dev_fill0 = 1, dev_fill1 = 0, dev_dash = 0, dev_di = 0, dev_flush = 0, dev_swin = 0, dev_text = 1, dev_xor = 0, dev_clear = 0, dev_fastimg = 0, DevName = "psc", '\0' <repeats 76 times>, OutFile = 0x100218e0, BaseName = 0x1001cb80 "test.ps", FileName = 0x1001cb60 "test.ps", output_type = 0, bytecnt = 4039, page = 12, linepos = 0, pdfs = 0x0, dev_npts = 0, dev_x = 0x0, dev_y = 0x0, dev_nptsX = 0, dev_nptsY = 0, dev_ix = 0x0, dev_iy = 0x0, dev_z = 0x0, dev_zmin = 0, dev_zmax = 0, imclxmin = 0, imclxmax = 0, imclymin = 0, imclymax = 0, dev = 0x1001cba0, KeyEH = 0, KeyEH_data = 0x0, ButtonEH = 0, ButtonEH_data = 0x0, LocateEH = 0, LocateEH_data = 0x0, bop_handler = 0, bop_data = 0x0, eop_handler = 0, eop_data = 0x0, xdpi = 72, ydpi = 72, xlength = 540, ylength = 720, xoffset = 0, yoffset = 0, pageset = 0, hack = 0, tidy = 0, tidy_data = 0x0, errcode = 0x0, errmsg = 0x0, geometry = 0x0, window_id = 0, nopixmap = 0, db = 0, ext_resize_draw = 0, server_name = 0x0, server_host = 0x0, server_port = 0x0, user = 0x0, plserver = 0x0, plwindow = 0x0, auto_path = 0x0, tk_file = 0x0, bufmax = 0, dp = 0, server_nokill = 0, plbuf_buffer_grow = 0, plbuf_buffer_size = 0, plbuf_buffer = 0x0, plbuf_top = 0, plbuf_readpos = 0, plbufOwner = 0, difilt = 0, diclpxmi = 0, diclpxma = 0, diclpymi = 0, diclpyma = 0, dipxmin = 0, dipymin = 0, dipxmax = 1, dipymax = 1, dipxax = 0, dipxb = 0, dipyay = 0, dipyb = 0, aspdev = 1.3334568358651353, aspect = 0, aspori = 0, caspfactor = 1, mar = 0, jx = 0, jy = 0, didxax = 0, didxb = 0, didyay = 0, didyb = 0, diorot = 0, dioxax = 0, dioxay = 0, dioxb = 0, dioyax = 0, dioyay = 0, dioyb = 0, dimxax = 0, dimxb = 0, dimyay = 0, dimyb = 0, dimxmin = 0, dimymin = 0, dimxmax = 0, dimymax = 0, dimxpmm = 0, dimypmm = 0, page_status = 0, freeaspect = 0, portrait = 0, patt = 0, inclin = {0, 0}, delta = {2000, 0}, nps = 1, currx = 3527, curry = 2132, mark = {0, 0, 0, 0, 0, 0, 0, 0, 0, 0}, space = {0, 0, 0, 0, 0, 0, 0, 0, 0, 0}, nms = 0, timecnt = 0, alarm = 0, pendn = 1, curel = 0, esc = 35 '#', scale = 0, ---Type <return> to continue, or q <return> to quit--- chrdef = 4.4785777777777778, chrht = 4.4785777777777778, symdef = 4.4785777777777778, symht = 4.4785777777777778, majdef = 3.3589333333333333, majht = 3.3589333333333333, mindef = 1.6794666666666667, minht = 1.6794666666666667, setpre = 0, precis = 0, xdigmax = 4, ydigmax = 4, zdigmax = 3, xdigits = 0, ydigits = 0, zdigits = 0, timefmt = 0x10021ba0 "%c", vppxmi = 72, vppxma = 3527, vppymi = 54, vppyma = 2429, sppxmi = 0, sppxma = 3599, sppymi = 0, sppyma = 2699, clpxmi = 0, clpxma = 3599, clpymi = 0, clpyma = 2699, phyxmi = 0, phyxma = 3599, phyxlen = 3599, phyymi = 0, phyyma = 2699, phyylen = 2699, umx = 71, umy = 71, xpmm = 14.0625, ypmm = 14.0625, base3x = 0, base3y = 0, basecx = 0, basecy = 0, domxmi = 0, domxma = 0, domymi = 0, domyma = 0, zzscl = 0, ranmi = 0, ranma = 0, cxx = 0, cxy = 0, cyx = 0, cyy = 0, cyz = 0, czx = 0, czy = 0, czz = 0, nplwin = 1, plwin = {{dxmi = 0.02, dxma = 0.97999999999999998, dymi = 0.02, dyma = 0.90000000000000002, wxmi = -1.0000000000000001e-05, wxma = 1.0000100000000001, wymi = -1.0000000000000001e-05, wyma = 1.0000100000000001}, {dxmi = 0, dxma = 0, dymi = 0, dyma = 0, wxmi = 0, wxma = 0, wymi = 0, wyma = 0} <repeats 63 times>}, nsubx = 1, nsuby = 1, cursub = 1, spdxmi = 0, spdxma = 1, spdymi = 0, spdyma = 1, vpdxmi = 0.02, vpdxma = 0.97999999999999998, vpdymi = 0.02, vpdyma = 0.90000000000000002, vpwxmi = 0, vpwxma = 1, vpwymi = 0, vpwyma = 1, wpxscl = 3454.930901381972, wpxoff = 71.998560028799417, wpyscl = 2374.9525009499807, wpyoff = 53.99892002159956, wmxscl = 245.68681959694135, wmxoff = 5.118475408269612, wmyscl = 168.89404434133536, wmyoff = 3.8385010077576225, wdxscl = 0.95998080038399214, wdxoff = 0.01999960000799984, wdyscl = 0.87998240035199271, wdyoff = 0.01999960000799984, dev_compression = 0, cfont = 1, FT = 0x0, plPlotterPtr = 0x0, dev_unicode = 1, fci = 3214179041, dev_hrshsym = 1, original_chrdef = 0, original_chrht = 0, psdoc = 0x0} (gdb) print *args $10 = {base = 0, just = 0.5, xform = 0xfffffffde20, x = 1800, y = 2524, refx = 593, refy = 2524, font_face = 0 '\0', unicode_char = 868232, unicode_array = 0x400000e3028, unicode_array_len = 41, string = 0x0} (gdb) print Type1Lookup $11 = {{fci = 2147483648, pfont = 0x400006e2d08 "Helvetica"}, {fci = 2147483649, pfont = 0x400006e2d18 "Times-Roman"}, {fci = 2147483650, pfont = 0x400006e2d28 "Courier"}, {fci = 2147483651, pfont = 0x400006e2d18 "Times-Roman"}, {fci = 2147483652, pfont = 0x400006e2288 "Symbol"}, {fci = 2147483664, pfont = 0x400006e2d30 "Helvetica-Oblique"}, {fci = 2147483665, pfont = 0x400006e2d48 "Times-Italic"}, {fci = 2147483666, pfont = 0x400006e2d58 "Courier-Oblique"}, {fci = 2147483667, pfont = 0x400006e2d48 "Times-Italic"}, {fci = 2147483668, pfont = 0x400006e2288 "Symbol"}, {fci = 2147483680, pfont = 0x400006e2d30 "Helvetica-Oblique"}, {fci = 2147483681, pfont = 0x400006e2d48 "Times-Italic"}, {fci = 2147483682, pfont = 0x400006e2d58 "Courier-Oblique"}, {fci = 2147483683, pfont = 0x400006e2d48 "Times-Italic"}, {fci = 2147483684, pfont = 0x400006e2288 "Symbol"}, {fci = 2147483904, pfont = 0x400006e2d68 "Helvetica-Bold"}, {fci = 2147483905, pfont = 0x400006e2d78 "Times-Bold"}, {fci = 2147483906, pfont = 0x400006e2d88 "Courier-Bold"}, {fci = 2147483907, pfont = 0x400006e2d78 "Times-Bold"}, {fci = 2147483908, pfont = 0x400006e2288 "Symbol"}, {fci = 2147483920, pfont = 0x400006e2d98 "Helvetica-BoldOblique"}, {fci = 2147483921, pfont = 0x400006e2db0 "Times-BoldItalic"}, {fci = 2147483922, pfont = 0x400006e2dc8 "Courier-BoldOblique"}, {fci = 2147483923, pfont = 0x400006e2db0 "Times-BoldItalic"}, {fci = 2147483924, pfont = 0x400006e2288 "Symbol"}, {fci = 2147483936, pfont = 0x400006e2d98 "Helvetica-BoldOblique"}, {fci = 2147483937, pfont = 0x400006e2db0 "Times-BoldItalic"}, {fci = 2147483938, pfont = 0x400006e2dc8 "Courier-BoldOblique"}, {fci = 2147483939, pfont = 0x400006e2db0 "Times-BoldItalic"}, {fci = 2147483940, pfont = 0x400006e2288 "Symbol"}} Seems like I need to track down where fci is getting set incorrectly? -- Orion Poplawski Technical Manager 303-415-9701 x222 NWRA/CoRA Division FAX: 303-415-9702 3380 Mitchell Lane or...@co... Boulder, CO 80301 http://www.cora.nwra.com |
From: Alan W. I. <ir...@be...> - 2009-02-11 22:39:06
|
On 2009-02-11 14:01-0700 Orion Poplawski wrote: > Fedora is moving to gcc 4.4 with Fedora 11. I'm trying to build plplot > 5.9.2 and getting the following error: > fci = 0xbf947ae1 Hi Orion: Just in case you didn't know this already, what distinguishes an FCI from UCS4 code is the most significant bit is turned on (see http://plplot.sourceforge.net/docbook-manual/plplot-html-5.9.2/characters.html#fci). So the above hex pattern does qualify as an FCI, and that is why you got into the FCI part of the code. However, other than that marker bit, the other thing that distinguishes FCI's is only their 3 lowest order hex fields are set. So valid values look like 0x80000???. Clearly, the above value is completely invalid if interpreted as an FCI rather than an ordinary UCS4 character. However, the maximum UCS4 is supposed to be 0x10FFFF so the above is not consistent with UCS4 either. Thus, I think the basic problem is that garbage is getting into the array we use to hold a combination of UCS4 and FCI 32-bit unsigned integers. > Seems like I need to track down where fci is getting set incorrectly? Yes or investigate where an ordinary UCS4 code is being set to garbage. Have you had success before with your ppc hardware? If you have never tested before on that hardware platform, it could be an endian issue for PLplot. Another possibility is it could be an endian issue in some/all of the gcc-4.4 suite of compilers. Sorry, I don't have access to gcc-4.4 to do some complementary tests here. What languages do you have to disable before the problem goes away? If only f77 (or f77 and f95) have the issue, but C does not, then that greatly limits where we have to look for the issue. I assume your fortran compiler is gfortran (i.e., part of the suite of gcc-based compilers), but could you confirm that? Also, if gfortran, is its version consistent with the gcc compiler version? Does valgrind show any memory management issues? Such issues are one way to get garbage in the array of unsigned 32-bit integers (a combination of UCS4 and FCI) that are interpreted for plotting. Hope some of these ideas and questions help you to figure out the source of the problem. Alan __________________________ Alan W. Irwin Astronomical research affiliation with Department of Physics and Astronomy, University of Victoria (astrowww.phys.uvic.ca). Programming affiliations with the FreeEOS equation-of-state implementation for stellar interiors (freeeos.sf.net); PLplot scientific plotting software package (plplot.org); the libLASi project (unifont.org/lasi); the Loads of Linux Links project (loll.sf.net); and the Linux Brochure Project (lbproject.sf.net). __________________________ Linux-powered Science __________________________ |
From: Orion P. <or...@co...> - 2009-02-11 23:27:30
|
Alan W. Irwin wrote: > On 2009-02-11 14:01-0700 Orion Poplawski wrote: > >> Fedora is moving to gcc 4.4 with Fedora 11. I'm trying to build plplot >> 5.9.2 and getting the following error: > >> fci = 0xbf947ae1 > > Hi Orion: > > Just in case you didn't know this already, what distinguishes an FCI from > UCS4 code is the most significant bit is turned on (see > http://plplot.sourceforge.net/docbook-manual/plplot-html-5.9.2/characters.html#fci). > So the above hex pattern does qualify as an FCI, and that is why you got > into the FCI part of the code. > However, other than that marker bit, the other thing that distinguishes FCI's > is only their 3 lowest order hex fields are set. So valid values look like > 0x80000???. Clearly, the above value is completely invalid if interpreted > as an FCI rather than an ordinary UCS4 character. However, the maximum > UCS4 is supposed to be 0x10FFFF so the above is not consistent with UCS4 > either. Thus, I think the basic problem is > that garbage is getting into the array we use to hold a combination of UCS4 > and FCI 32-bit unsigned integers. > >> Seems like I need to track down where fci is getting set incorrectly? > > Yes or investigate where an ordinary UCS4 code is being set to garbage. > breaking on c_plsfci, I get to: Breakpoint 3, c_plsfci (fci=1066695393) at /builddir/build/BUILD/plplot-5.9.2/src/plcore.c:3018 3018 plsc->fci = fci | PL_FCI_MARK; which again seems like a bad fci number. (gdb) print /x fci $2 = 0x3f947ae1 (gdb) bt #0 c_plsfci (fci=1066695393) at /builddir/build/BUILD/plplot-5.9.2/src/plcore.c:3018 #1 0x0000040000065184 in plsfci_ (fci=<value optimized out>) at /builddir/build/BUILD/plplot-5.9.2/bindings/f77/scstubs.c:781 #2 0x0000000010001e84 in x23f () at /builddir/build/BUILD/plplot-5.9.2/fedora/examples/f77/x23f.f:326 #3 0x0000000010004078 in .main () #4 0x00000400005412b8 in .generic_start_main () from /lib64/libc.so.6 #5 0x00000400005414d0 in .__libc_start_main () from /lib64/libc.so.6 #6 0x0000000000000000 in ?? () (gdb) up #1 0x0000040000065184 in plsfci_ (fci=<value optimized out>) at /builddir/build/BUILD/plplot-5.9.2/bindings/f77/scstubs.c:781 781 c_plsfci(f); (gdb) list 776 void 777 PLSFCI(PLINT64 *fci) 778 { 779 PLUNICODE f; 780 f = (PLUNICODE) (*fci & 0xffffffff); 781 c_plsfci(f); 782 } 783 784 void 785 PLSFNAM7(const char *fnam) (gdb) print f No symbol "f" in current context. (gdb) print fci $3 = <value optimized out> (gdb) up #2 0x0000000010001e84 in x23f () at /builddir/build/BUILD/plplot-5.9.2/fedora/examples/f77/x23f.f:326 326 call plsfci(0) So looks like we are definitely having some variable type issues going from Fortran to C. > Have you had success before with your ppc hardware? Compiles fine on ppc with gcc 4.3, new issue with 4.4. Now whether it is really a bug in gcc or simply stricter language adherence is yet to be determined. -- Orion Poplawski Technical Manager 303-415-9701 x222 NWRA/CoRA Division FAX: 303-415-9702 3380 Mitchell Lane or...@co... Boulder, CO 80301 http://www.cora.nwra.com |
From: Orion P. <or...@co...> - 2009-02-11 23:48:10
|
Orion Poplawski wrote: > > So looks like we are definitely having some variable type issues going > from Fortran to C. I've got a simple test case to bug the gcc folks with.... Thanks! -- Orion Poplawski Technical Manager 303-415-9701 x222 NWRA/CoRA Division FAX: 303-415-9702 3380 Mitchell Lane or...@co... Boulder, CO 80301 http://www.cora.nwra.com |
From: Werner S. <sm...@ia...> - 2009-02-11 22:44:31
|
Hi Orion, Orion Poplawski wrote: > Seems like I need to track down where fci is getting set incorrectly? > > Could you also post the backtrace (bt) and change the frame to the example code, so that we know how far in the example we get? Thanks, Werner -- Dr. Werner Smekal Institut fuer Allgemeine Physik Technische Universitaet Wien Wiedner Hauptstr 8-10 A-1040 Wien Austria DVR-Nr: 0005886 email: sm...@ia... web: http://www.iap.tuwien.ac.at/~smekal phone: +43-(0)1-58801-13463 (office) +43-(0)1-58801-13469 (laboratory) fax: +43-(0)1-58801-13499 |
From: Orion P. <or...@co...> - 2009-02-11 23:17:47
|
Werner Smekal wrote: > Hi Orion, > > Orion Poplawski wrote: >> Seems like I need to track down where fci is getting set incorrectly? >> >> > Could you also post the backtrace (bt) and change the frame to the > example code, so that we know how far in the example we get? (gdb) bt #0 proc_str (pls=0x400000da300, args=0xfffffffdc50) at /builddir/build/BUILD/plplot-5.9.2/drivers/ps.c:765 #1 0x00000400006e01dc in plD_esc_ps (pls=0x400000da300, op=<value optimized out>, ptr=<value optimized out>) at /builddir/build/BUILD/plplot-5.9.2/drivers/ps.c:628 #2 0x000004000008ff10 in plP_esc (op=20, ptr=0xfffffffdc50) at /builddir/build/BUILD/plplot-5.9.2/src/plcore.c:206 #3 0x0000040000091a80 in plP_text (base=<value optimized out>, just=<value optimized out>, xform=<value optimized out>, x=<value optimized out>, y=<value optimized out>, refx=<value optimized out>, refy=<value optimized out>, string=0x40000059cd0 "#<0x10>PLplot Example 23 - Set Font with plsfci") at /builddir/build/BUILD/plplot-5.9.2/src/plcore.c:719 #4 0x00000400000ae8d0 in c_plmtex (side=<value optimized out>, disp=1.5, pos=<value optimized out>, just=0.5, text=0x40000059cd0 "#<0x10>PLplot Example 23 - Set Font with plsfci") at /builddir/build/BUILD/plplot-5.9.2/src/plsym.c:529 #5 0x0000040000065c7c in plmtex7_ (side=<value optimized out>, disp=<value optimized out>, pos=<value optimized out>, just=<value optimized out>, text=<value optimized out>) at /builddir/build/BUILD/plplot-5.9.2/bindings/f77/scstubs.c:502 #6 0x0000040000046850 in plmtex (side=DWARF-2 expression error: DW_OP_reg operations must be used either alone or in conjuction with DW_OP_piece. ) at /builddir/build/BUILD/plplot-5.9.2/fedora/bindings/f77/sfstubs.f:600 #7 0x0000000010003f64 in x23f () at /builddir/build/BUILD/plplot-5.9.2/fedora/examples/f77/x23f.f:346 #8 0x0000000010004078 in .main () #9 0x00000400005412b8 in .generic_start_main () from /lib64/libc.so.6 #10 0x00000400005414d0 in .__libc_start_main () from /lib64/libc.so.6 #11 0x0000000000000000 in ?? () (gdb) up 7 #7 0x0000000010003f64 in x23f () at /builddir/build/BUILD/plplot-5.9.2/fedora/examples/f77/x23f.f:346 346 & 'Set Font with ##<FCI COMMAND STRING/> constructs') Current language: auto; currently fortran (gdb) list 341 & '#<0x10>PLplot Example 23 - '// 342 & 'Set Font with ##<0xmn> constructs') 343 elseif(page == 15) then 344 call plmtex('t', 1.5d0, 0.5d0, 0.5d0, 345 & '#<0x10>PLplot Example 23 - '// 346 & 'Set Font with ##<FCI COMMAND STRING/> constructs') 347 endif 348 call plschr(0.d0, 0.75d0) 349 do 150 i=0,fci_combinations-1 350 family_index = mod(i,5) -- Orion Poplawski Technical Manager 303-415-9701 x222 NWRA/CoRA Division FAX: 303-415-9702 3380 Mitchell Lane or...@co... Boulder, CO 80301 http://www.cora.nwra.com |
From: Orion P. <or...@co...> - 2009-02-12 22:21:52
Attachments:
plplot-5.9.2-f77.patch
|
Orion Poplawski wrote: > #2 0x0000000010001e84 in x23f () > at /builddir/build/BUILD/plplot-5.9.2/fedora/examples/f77/x23f.f:326 > 326 call plsfci(0) > This is clearly wrong. plsfci takes a 64-bit integer. The attached patch fixes. The x23f.f90 example uses "0_plunicode" to specify the type. I don't know if "PL_INT_0" is the best name, but it shows the general solution. -- Orion Poplawski Technical Manager 303-415-9701 x222 NWRA/CoRA Division FAX: 303-415-9702 3380 Mitchell Lane or...@co... Boulder, CO 80301 http://www.cora.nwra.com |
From: Alan W. I. <ir...@be...> - 2009-02-13 00:15:12
|
On 2009-02-12 15:01-0700 Orion Poplawski wrote: > Orion Poplawski wrote: >> #2 0x0000000010001e84 in x23f () >> at /builddir/build/BUILD/plplot-5.9.2/fedora/examples/f77/x23f.f:326 >> 326 call plsfci(0) >> > > This is clearly wrong. plsfci takes a 64-bit integer. The attached patch > fixes. The x23f.f90 example uses "0_plunicode" to specify the type. I don't > know if "PL_INT_0" is the best name, but it shows the general solution. Hi Andrew, I mostly address this to you since you were the pl[gs]fci implementer for most languages (as discussed in a thread started by you last July 31). At the time, I found a similar error to Orion's for the f95 case, and you almost immediately found a fix. At the time we were overly focussed on just getting something to work, but in retrospect I have some questions about the whole approach taken to deal with the f77 bindings (and probably other bindings as well) for pl[sg]fci. I notice the following comment from you in bindings/f77/scstubs.c. "Note: Fortran does not have unsigned integers so we need to use a 64 bit signed integer which corresponds to a fortran integer*8 in order to contain the number." Could you explain that comment? My question is why is it necessary to use the 64-bit type PLINT64 at the C level of the f77 interface (and therefore 64-bit types in all calling fortran routines) when only 32-bits are actually required to store the unsigned bit pattern? According to "info gfortran" typeless BOZ constants (i.e., binary, octal, or hexadecimal bit patterns) are allowed anywhere that ordinary integers can be used, and there is a similar statement in the Intel fortran compiler programmer's reference. For gfortran I tried the following simple test code: integer*4 hello hello = Z'80000001' write(*,*) hello end That would not compile by default. It complained about an overflow. I think that is a gfortran implementation error since the size of the BOZ constant on the right is not larger than the size of the integer*4 on the left, and no such error would have occurred it I had said hello = -2147483647 instead. However, when I specified the option -fno-range-check, the above source code compiled, and the resulting executable gave the correct result, -2^31 + 1 = -2147483647. I assume from the writeup in the Intel Fortran programmer's reference manual, you would get the same result from Intel Fortran (and perhaps other modern Fortran compilers as well?). In any case, using a typeless BOZ constant to make sure the most significant bit is set to mark the integer as an FCI is an unlikely case which normally would not happen since if you don't specify that FCI marker, the C code for plsfci applies it anyway. Also, when you look at plgfci, it should just fill the 4 bytes of memory with the appropriate bit pattern, and I cannot see what could go wrong if those 4 bytes of memory were integer*4. Anyhow, I am tentatively concluding we should be doing absolutely nothing special at the f77 interface level to deal with pl[sg]fci. We simply want 4 bytes sent to the C library or returned from it, and integer*4 should have sufficient storage for the task, if we don't interfere at the interface level to translate to 8 bytes and that back to 4 bytes again. Andrew, do you see anything obviously wrong with the simple approach I just outlined for transferring a 4-byte bit pattern from the f77 level to our C library and back again? Alan __________________________ Alan W. Irwin Astronomical research affiliation with Department of Physics and Astronomy, University of Victoria (astrowww.phys.uvic.ca). Programming affiliations with the FreeEOS equation-of-state implementation for stellar interiors (freeeos.sf.net); PLplot scientific plotting software package (plplot.org); the libLASi project (unifont.org/lasi); the Loads of Linux Links project (loll.sf.net); and the Linux Brochure Project (lbproject.sf.net). __________________________ Linux-powered Science __________________________ |
From: Andrew R. <and...@us...> - 2009-02-13 09:50:55
|
On Thu, Feb 12, 2009 at 04:14:57PM -0800, Alan Irwin wrote: > On 2009-02-12 15:01-0700 Orion Poplawski wrote: > > > Orion Poplawski wrote: > >> #2 0x0000000010001e84 in x23f () > >> at /builddir/build/BUILD/plplot-5.9.2/fedora/examples/f77/x23f.f:326 > >> 326 call plsfci(0) > >> > > > > This is clearly wrong. plsfci takes a 64-bit integer. The attached patch > > fixes. The x23f.f90 example uses "0_plunicode" to specify the type. I don't > > know if "PL_INT_0" is the best name, but it shows the general solution. > > Hi Andrew, > > I mostly address this to you since you were the pl[gs]fci implementer for > most languages (as discussed in a thread started by you last July 31). At > the time, I found a similar error to Orion's for the f95 case, and you > almost immediately found a fix. At the time we were overly focussed on just > getting something to work, but in retrospect I have some questions about the > whole approach taken to deal with the f77 bindings (and probably other > bindings as well) for pl[sg]fci. > > I notice the following comment from you in bindings/f77/scstubs.c. > > "Note: Fortran does not have unsigned integers so we need to use a > 64 bit signed integer which corresponds to a fortran integer*8 > in order to contain the number." > > Could you explain that comment? My question is why is it necessary to use > the 64-bit type PLINT64 at the C level of the f77 interface (and therefore > 64-bit types in all calling fortran routines) when only 32-bits are actually > required to store the unsigned bit pattern? The real problem is that PLUNICODE was defined as a unsigned 32-bit integer. Many languages, including fortran do not have unsigned types, and so we only have 31 bits available for the value. The fact that the top bit is always set in an fci character means that we can never represent these numbers using a 32-bit integer. Of course we can try various tricks casting unsigned integers to a signed integer - which is what you did, but obviously this doesn't work. It is also potentially confusing for the user who queries the value of an fci and doesn't get the value they expect. We chose to go for 64-bit integers for these languages to ensure the values fitted. With hindsight a safer choice would have been to make PLUNICODE an signed 32-bit int, but it's a bit late for that now. > According to "info gfortran" typeless BOZ constants (i.e., binary, octal, or > hexadecimal bit patterns) are allowed anywhere that ordinary integers can be > used, and there is a similar statement in the Intel fortran compiler > programmer's reference. For gfortran I tried the following simple test > code: > > integer*4 hello > hello = Z'80000001' > write(*,*) hello > end > > That would not compile by default. It complained about an overflow. I think > that is a gfortran implementation error since the size of the BOZ constant > on the right is not larger than the size of the integer*4 on the left, and > no such error would have occurred it I had said > > hello = -2147483647 > > instead. However, when I specified the option -fno-range-check, the above > source code compiled, and the resulting executable gave the correct result, > -2^31 + 1 = -2147483647. I assume from the writeup in the Intel Fortran > programmer's reference manual, you would get the same result from Intel > Fortran (and perhaps other modern Fortran compilers as well?). In any case, > using a typeless BOZ constant to make sure the most significant bit is set > to mark the integer as an FCI is an unlikely case which normally would not > happen since if you don't specify that FCI marker, the C code for plsfci > applies it anyway. Also, when you look at plgfci, it should just fill the > 4 bytes of memory with the appropriate bit pattern, and I cannot see what > could go wrong if those 4 bytes of memory were integer*4. > > Anyhow, I am tentatively concluding we should be doing absolutely nothing > special at the f77 interface level to deal with pl[sg]fci. We simply want 4 > bytes sent to the C library or returned from it, and integer*4 should have > sufficient storage for the task, if we don't interfere at the interface > level to translate to 8 bytes and that back to 4 bytes again. > > Andrew, do you see anything obviously wrong with the simple approach I just > outlined for transferring a 4-byte bit pattern from the f77 level to our C > library and back again? It sounds like your approach would work for at least gfortran and probably ifort. It is not particularly nice, but neither is the current solution. We need to make it clear that fci is only to be thought of as a 4 byte bit pattern. We may run into problems with other compilers at some stage. We will also need to bodge example 23 to print out the fci value correctly. I'm happy for you to give it a try. Andrew > Alan > __________________________ > Alan W. Irwin > > Astronomical research affiliation with Department of Physics and Astronomy, > University of Victoria (astrowww.phys.uvic.ca). > > Programming affiliations with the FreeEOS equation-of-state implementation > for stellar interiors (freeeos.sf.net); PLplot scientific plotting software > package (plplot.org); the libLASi project (unifont.org/lasi); the Loads of > Linux Links project (loll.sf.net); and the Linux Brochure Project > (lbproject.sf.net). > __________________________ > > Linux-powered Science > __________________________ > > ------------------------------------------------------------------------------ > Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA > -OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise > -Strategies to boost innovation and cut costs with open source participation > -Receive a $600 discount off the registration fee with the source code: SFAD > http://p.sf.net/sfu/XcvMzF8H > _______________________________________________ > Plplot-devel mailing list > Plp...@li... > https://lists.sourceforge.net/lists/listinfo/plplot-devel > |
From: trc <kea...@ya...> - 2009-02-13 17:55:50
|
Andrew Ross wrote: > On Thu, Feb 12, 2009 at 04:14:57PM -0800, Alan Irwin wrote: >> On 2009-02-12 15:01-0700 Orion Poplawski wrote: >> >>> Orion Poplawski wrote: >>>> #2 0x0000000010001e84 in x23f () >>>> at /builddir/build/BUILD/plplot-5.9.2/fedora/examples/f77/x23f.f:326 >>>> 326 call plsfci(0) >>>> >>> This is clearly wrong. plsfci takes a 64-bit integer. The attached patch >>> fixes. The x23f.f90 example uses "0_plunicode" to specify the type. I don't >>> know if "PL_INT_0" is the best name, but it shows the general solution. >> Hi Andrew, >> >> I mostly address this to you since you were the pl[gs]fci implementer for >> most languages (as discussed in a thread started by you last July 31). At >> the time, I found a similar error to Orion's for the f95 case, and you >> almost immediately found a fix. At the time we were overly focussed on just >> getting something to work, but in retrospect I have some questions about the >> whole approach taken to deal with the f77 bindings (and probably other >> bindings as well) for pl[sg]fci. >> >> I notice the following comment from you in bindings/f77/scstubs.c. >> >> "Note: Fortran does not have unsigned integers so we need to use a >> 64 bit signed integer which corresponds to a fortran integer*8 >> in order to contain the number." >> >> Could you explain that comment? My question is why is it necessary to use >> the 64-bit type PLINT64 at the C level of the f77 interface (and therefore >> 64-bit types in all calling fortran routines) when only 32-bits are actually >> required to store the unsigned bit pattern? > > The real problem is that PLUNICODE was defined as a unsigned 32-bit > integer. Many languages, including fortran do not have unsigned types, > and so we only have 31 bits available for the value. The fact that the > top bit is always set in an fci character means that we can never > represent these numbers using a 32-bit integer. Of course we can try > various tricks casting unsigned integers to a signed integer - which is > what you did, but obviously this doesn't work. It is also potentially > confusing for the user who queries the value of an fci and doesn't get > the value they expect. We chose to go for 64-bit integers for these > languages to ensure the values fitted. With hindsight a safer choice > would have been to make PLUNICODE an signed 32-bit int, but it's a bit > late for that now. > >> According to "info gfortran" typeless BOZ constants (i.e., binary, octal, or >> hexadecimal bit patterns) are allowed anywhere that ordinary integers can be >> used, and there is a similar statement in the Intel fortran compiler >> programmer's reference. For gfortran I tried the following simple test >> code: >> >> integer*4 hello >> hello = Z'80000001' >> write(*,*) hello >> end >> >> That would not compile by default. It complained about an overflow. I think >> that is a gfortran implementation error since the size of the BOZ constant >> on the right is not larger than the size of the integer*4 on the left, and >> no such error would have occurred it I had said >> >> hello = -2147483647 >> >> instead. However, when I specified the option -fno-range-check, the above >> source code compiled, and the resulting executable gave the correct result, >> -2^31 + 1 = -2147483647. I assume from the writeup in the Intel Fortran >> programmer's reference manual, you would get the same result from Intel >> Fortran (and perhaps other modern Fortran compilers as well?). In any case, >> using a typeless BOZ constant to make sure the most significant bit is set >> to mark the integer as an FCI is an unlikely case which normally would not >> happen since if you don't specify that FCI marker, the C code for plsfci >> applies it anyway. Also, when you look at plgfci, it should just fill the >> 4 bytes of memory with the appropriate bit pattern, and I cannot see what >> could go wrong if those 4 bytes of memory were integer*4. >> >> Anyhow, I am tentatively concluding we should be doing absolutely nothing >> special at the f77 interface level to deal with pl[sg]fci. We simply want 4 >> bytes sent to the C library or returned from it, and integer*4 should have >> sufficient storage for the task, if we don't interfere at the interface >> level to translate to 8 bytes and that back to 4 bytes again. >> >> Andrew, do you see anything obviously wrong with the simple approach I just >> outlined for transferring a 4-byte bit pattern from the f77 level to our C >> library and back again? > > It sounds like your approach would work for at least gfortran and > probably ifort. It is not particularly nice, but neither is the current > solution. We need to make it clear that fci is only to be thought of as > a 4 byte bit pattern. We may run into problems with other compilers at > some stage. We will also need to bodge example 23 to print out the fci > value correctly. > > I'm happy for you to give it a try. > > Andrew > Hi, I think this is an f77 issue only. For f95 see below. The reason for the error is a mismatch between the fortran and c code. For a call such as in x023f call plsfci(0) an f77 compiler will generate an integer*4 temporary for the argument 0 and pass that address to PLSFCI (see f77/scstubs.c) . However PLSFCI interprets it as an integer*8 (PLINT64) pointer taking in the adjacent 4 bytes. It is only luck that this code works with other compilers and architectures. An f77 compiler will also generate the wrong code for any calls to plsfci with an integer*4 variable. When Orion added the integer*8 parameter the f77 compiler would have created an integer*8 temporary and the program worked as expected. f95 compilers should generate the correct integer*8 code from the module declaration. Kind Regards Terrence |
From: Alan W. I. <ir...@be...> - 2009-02-13 19:16:04
|
On 2009-02-13 09:50-0000 Andrew Ross wrote: > The real problem is that PLUNICODE was defined as a unsigned 32-bit > integer. Many languages, including fortran do not have unsigned types, > and so we only have 31 bits available for the value. For Fortran, my experience is it is normal to assume arbitrary 32-bit patterns can be stored in 32-bit integers. Thus, there is an extra freedom allowed for that language because there is no distinction between unsigned and signed integers. I do realize that long experience (I started with Fortran in 1968) with a language does not necessarily mean wisdom, but if I am right, the compiler integer overflow error I am getting in the gfortran case without a special compilation option is really a gfortran implementation error (a reduction of the freedom that most fortran compilers will have for this issue). > It sounds like your approach would work for at least gfortran and > probably ifort. It is not particularly nice, but neither is the current > solution. We need to make it clear that fci is only to be thought of as > a 4 byte bit pattern. We may run into problems with other compilers at > some stage. We will also need to bodge example 23 to print out the fci > value correctly. > > I'm happy for you to give it a try. I did so (revision 9523) for the f77 interface. It works fine for gfortran. Will everybody (especially Orion) with access to fortran compilers please give this simplified approach a try? Note, in the 23rd example I had to work around the gfortran implementation error by dropping the '8' marker from the hex constants describing the various fci values. That was fine for plsfci (which simply puts back the marker if it does not exist), but I had to explicitly put in the '8' marker when using the #<0x8nnnnnnn> form of changing the FCI in the middle of strings. Fortunately, that is going to be a rare case, because I believe that users will ordinarily use that form explicitly (just type it into the string) rather than attempting to format it from a predetermined array of FCI values. Alan __________________________ Alan W. Irwin Astronomical research affiliation with Department of Physics and Astronomy, University of Victoria (astrowww.phys.uvic.ca). Programming affiliations with the FreeEOS equation-of-state implementation for stellar interiors (freeeos.sf.net); PLplot scientific plotting software package (plplot.org); the libLASi project (unifont.org/lasi); the Loads of Linux Links project (loll.sf.net); and the Linux Brochure Project (lbproject.sf.net). __________________________ Linux-powered Science __________________________ |
From: Alan W. I. <ir...@be...> - 2009-02-23 19:25:25
|
On 2009-02-13 11:15-0800 Alan W. Irwin wrote: > On 2009-02-13 09:50-0000 Andrew Ross wrote: > >> [...]I'm happy for you to give it [simplified approach for PLUNICODE mapping to fortran integer*4] a try. > > I did so (revision 9523) for the f77 interface. It works fine for gfortran. > Will everybody (especially Orion) with access to fortran compilers please > give this simplified approach a try? I assume this approach works for everybody who has tested it since I got no feedback. Accordingly, I have just (revision 9590) implemented this simplified approach for f95 as well. It works for gfortran, but requires testing for other fortran compilers as well. Alan __________________________ Alan W. Irwin Astronomical research affiliation with Department of Physics and Astronomy, University of Victoria (astrowww.phys.uvic.ca). Programming affiliations with the FreeEOS equation-of-state implementation for stellar interiors (freeeos.sf.net); PLplot scientific plotting software package (plplot.org); the libLASi project (unifont.org/lasi); the Loads of Linux Links project (loll.sf.net); and the Linux Brochure Project (lbproject.sf.net). __________________________ Linux-powered Science __________________________ |
From: Orion P. <or...@co...> - 2009-02-23 22:36:57
|
Alan W. Irwin wrote: > On 2009-02-13 11:15-0800 Alan W. Irwin wrote: > >> On 2009-02-13 09:50-0000 Andrew Ross wrote: >> >>> [...]I'm happy for you to give it [simplified approach for PLUNICODE > mapping to fortran integer*4] a try. >> >> I did so (revision 9523) for the f77 interface. It works fine for >> gfortran. >> Will everybody (especially Orion) with access to fortran compilers please >> give this simplified approach a try? > > I assume this approach works for everybody who has tested it since I got no > feedback. Accordingly, I have just (revision 9590) implemented this > simplified approach for f95 as well. It works for gfortran, but requires > testing for other fortran compilers as well. Sorry for the delay, but it all tests out fine here (Fedora development w/ gfortran 4.4.0). -- Orion Poplawski Technical Manager 303-415-9701 x222 NWRA/CoRA Division FAX: 303-415-9702 3380 Mitchell Lane or...@co... Boulder, CO 80301 http://www.cora.nwra.com |