public inbox for gcc-bugs@sourceware.org
help / color / mirror / Atom feed
From: "tkoenig at gcc dot gnu dot org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug fortran/23815] Add -byteswapio flag
Date: Sat, 12 Nov 2005 00:02:00 -0000	[thread overview]
Message-ID: <20051112000252.30128.qmail@sourceware.org> (raw)
In-Reply-To: <bug-23815-7128@http.gcc.gnu.org/bugzilla/>



------- Comment #17 from tkoenig at gcc dot gnu dot org  2005-11-12 00:02 -------
(In reply to comment #14)
> Thomas,
> 
> I'm not in favor of environmental variables, which I think would
> also be Paul Brook's position.  It's too easy to have the variables
> set or unset at the wrong time.

In the docs, I would recommend setting them via

GFORTRAN_CONVERT_BIG_ENDIAN=3 progname

or

(setenv GFORTRAN_CONVERT_BIG_ENDIAN=3 ; progname )


> What are your plans for REAL(10), REAL(16), INTEGER(16), COMPLEX(10),
> and COMPLEX(16)?  AFAIK, the reals may have padding issues.

I don't have enough information about alignment to get
REAL(10) to work on a big-endian system.  If we use those,
we also get bitten by the 12-byte/16-byte alignment issue for
different architectures.  Does any big-endian architecture have
REAL(10)?

(In reply to comment #15)

> The environment variable approach also allows the same executable to be
> used for different scenarios. The only negative I see is if the executable
> was compiled by a different compiler (ifort, pgf95, etc.). A user might 
> expect that the behavior will change with an environment variable setting and
> then wonder why it didn't. Perhaps the same environment variable names used by
> ifort could be used by gfortran to limit this issue a bit?

Ifort uses environment variables based on unit numbers, file extensions,
and I don't know what else.  I'd hate to copy all that.  Also,I'd
rather stick to the GFORTRAN_* namespace of environment variables.


-- 


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


  parent reply	other threads:[~2005-11-12  0:02 UTC|newest]

Thread overview: 34+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <bug-23815-7128@http.gcc.gnu.org/bugzilla/>
2005-10-11 13:25 ` tobi at gcc dot gnu dot org
2005-10-11 18:40 ` tkoenig at gcc dot gnu dot org
2005-10-11 19:01 ` Tobias dot Schlueter at physik dot uni-muenchen dot de
2005-10-11 19:20 ` rrr6399 at futuretek dot com
2005-10-11 19:37 ` tkoenig at gcc dot gnu dot org
2005-11-02 17:16 ` pinskia at gcc dot gnu dot org
2005-11-02 18:17 ` rrr6399 at futuretek dot com
2005-11-02 21:20 ` tkoenig at gcc dot gnu dot org
2005-11-05 22:21 ` tkoenig at gcc dot gnu dot org
2005-11-10 22:39 ` tkoenig at gcc dot gnu dot org
2005-11-10 22:53 ` tkoenig at gcc dot gnu dot org
2005-11-11  4:52 ` kargl at gcc dot gnu dot org
2005-11-11 13:26 ` rrr6399 at futuretek dot com
2005-11-11 23:53 ` tkoenig at gcc dot gnu dot org
2005-11-12  0:02 ` tkoenig at gcc dot gnu dot org [this message]
2005-11-18 21:17 ` tkoenig at gcc dot gnu dot org
2005-11-27 22:15 ` tkoenig at gcc dot gnu dot org
2005-11-27 22:27 ` tkoenig at gcc dot gnu dot org
2005-11-27 22:42 ` sgk at troutmask dot apl dot washington dot edu
2005-12-06 21:45 ` tkoenig at gcc dot gnu dot org
2005-12-10 13:09 ` tkoenig at gcc dot gnu dot org
2005-12-10 20:02 ` tkoenig at gcc dot gnu dot org
2005-12-10 20:12 ` tkoenig at gcc dot gnu dot org
2005-12-13 21:11 ` tkoenig at gcc dot gnu dot org
2006-01-09 22:53 ` tkoenig at gcc dot gnu dot org
2006-01-15 21:07 ` tkoenig at gcc dot gnu dot org
2006-01-27 20:40 ` tkoenig at gcc dot gnu dot org
2006-02-06 20:12 ` tkoenig at gcc dot gnu dot org
2006-02-08 20:14 ` tkoenig at gcc dot gnu dot org
2006-02-08 20:15 ` tkoenig at gcc dot gnu dot org
2006-02-09 15:12 ` tobi at gcc dot gnu dot org
2006-02-09 20:03 ` tkoenig at gcc dot gnu dot org
2005-09-11  5:14 [Bug fortran/23815] New: " rrr6399 at futuretek dot com
2005-09-12 14:29 ` [Bug fortran/23815] " pinskia at gcc dot gnu dot org
2005-09-12 19:22 ` falk at debian dot org

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=20051112000252.30128.qmail@sourceware.org \
    --to=gcc-bugzilla@gcc.gnu.org \
    --cc=gcc-bugs@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: link
Be 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).