public inbox for gcc-prs@sourceware.org help / color / mirror / Atom feed
From: l.e.matthias@larc.nasa.gov To: gcc-gnats@gcc.gnu.org Cc: l.e.matthias@larc.nasa.gov Subject: c/5077: Strange Code Generation Date: Tue, 11 Dec 2001 10:16:00 -0000 [thread overview] Message-ID: <200112111805.NAA67432@darrin.larc.nasa.gov> (raw) >Number: 5077 >Category: c >Synopsis: Strange Code Generation >Confidential: no >Severity: critical >Priority: medium >Responsible: unassigned >State: open >Class: wrong-code >Submitter-Id: net >Arrival-Date: Tue Dec 11 10:16:00 PST 2001 >Closed-Date: >Last-Modified: >Originator: Larry Matthias >Release: 3.0.1 >Organization: SAIC/NASA Langley Research Center (757) 864-7556 >Environment: System: IRIX64 darrin 6.5 01101245 IP27 host: mips-sgi-irix6.5 build: mips-sgi-irix6.5 target: mips-sgi-irix6.5 configured with: ../configure --prefix=/usr/freeware --enable-version-specific-runtime-libs --disable-shared --enable-threads --enable-haifa >Description: We have a software system built with gcc on the Sun using version 2.8.1 of gcc that works properly. I am trying to port this code over to the SGI. I initially built the code using version 2.95.2 and it compiles and links properly. But during execution of the application the code exits a loop and then quits (but with no error messages). I attempted to debug the problem by adding print statements into the specifc module that was crashing. It was then that I noticed that by adding or removing printf statements the code would quit at different places in the loop. The loop iterates for 29 steps but quits before completing. If I leave a printf statement in the code it will read ten items and then quit. If I remove the printf statement it will read in 20 items and then quit. Adding and removing printf statements is causing the application to fail at different times. I then tried this code with version 3.0.1 and saw identical results. So I have an application that works under Sunos using version 2.8.1 but fails under IRIX using either version 2.95.2 or 3.0.1. I can think of no reason why the code should crash differently by the changing of a printf statement. Even more important than the irratic behavior of the application is to understand why it is crashing to begin with. >How-To-Repeat: Our application consists of over 5000 lines of code. This code performs subsetting of scientific data from the Multi-angle Imaging Spectoradiometer (MISR) satellite instrument from JPL. It uses the libraries HDF and HDF-EOS to access the scientific data. The particular loop that fails is reading global attributes and copying them to an output file. The code is allocating and freeing memory inside of this loop so the problem may have something to do with memory. Since this is a rather complex piece of code I am unsure how we can get it to repeat the problem in your environment. We would need to get the HDF and HDF-EOS libraries for you as well as the application. Please contact me about how we could set this up. >Fix: I know of no work around for this problem. >Release-Note: >Audit-Trail: >Unformatted:
next reply other threads:[~2001-12-11 18:16 UTC|newest] Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top 2001-12-11 10:16 l.e.matthias [this message] 2002-04-26 1:53 rth
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=200112111805.NAA67432@darrin.larc.nasa.gov \ --to=l.e.matthias@larc.nasa.gov \ --cc=gcc-gnats@gcc.gnu.org \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).