* config/svr4.h
@ 1998-04-12 12:43 John Carr
1998-04-12 18:31 ` config/svr4.h Jeffrey A Law
0 siblings, 1 reply; 3+ messages in thread
From: John Carr @ 1998-04-12 12:43 UTC (permalink / raw)
To: egcs
SVR4 .size directives are wrong when HOST_WIDE_INT is larger than int.
Sun Apr 12 14:21:06 1998 John Carr <jfc@mit.edu>
* svr4.h (ASM_DECLARE_OBJECT_NAME, ASM_FINISH_DECLARE_OBJECT):
Make printf format and argument match.
*** svr4.h.orig Tue Jan 27 17:11:52 1998
--- svr4.h Sun Apr 12 14:20:23 1998
***************
*** 792,798 ****
size_directive_output = 1; \
fprintf (FILE, "\t%s\t ", SIZE_ASM_OP); \
assemble_name (FILE, NAME); \
! fprintf (FILE, ",%d\n", int_size_in_bytes (TREE_TYPE (DECL))); \
} \
ASM_OUTPUT_LABEL(FILE, NAME); \
} while (0)
--- 792,798 ----
size_directive_output = 1; \
fprintf (FILE, "\t%s\t ", SIZE_ASM_OP); \
assemble_name (FILE, NAME); \
! fprintf (FILE, ",%ld\n", (long)int_size_in_bytes (TREE_TYPE (DECL))); \
} \
ASM_OUTPUT_LABEL(FILE, NAME); \
} while (0)
***************
*** 814,820 ****
size_directive_output = 1; \
fprintf (FILE, "\t%s\t ", SIZE_ASM_OP); \
assemble_name (FILE, name); \
! fprintf (FILE, ",%d\n", int_size_in_bytes (TREE_TYPE (DECL))); \
} \
} while (0)
--- 814,820 ----
size_directive_output = 1; \
fprintf (FILE, "\t%s\t ", SIZE_ASM_OP); \
assemble_name (FILE, name); \
! fprintf (FILE, ",%ld\n", (long)int_size_in_bytes (TREE_TYPE (DECL)));\
} \
} while (0)
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: config/svr4.h
1998-04-12 12:43 config/svr4.h John Carr
@ 1998-04-12 18:31 ` Jeffrey A Law
0 siblings, 0 replies; 3+ messages in thread
From: Jeffrey A Law @ 1998-04-12 18:31 UTC (permalink / raw)
To: John Carr; +Cc: egcs
In message < 199804121942.PAA07117@jfc. >you write:
>
> SVR4 .size directives are wrong when HOST_WIDE_INT is larger than int.
>
> Sun Apr 12 14:21:06 1998 John Carr <jfc@mit.edu>
>
> * svr4.h (ASM_DECLARE_OBJECT_NAME, ASM_FINISH_DECLARE_OBJECT):
> Make printf format and argument match.
>
Is there some reason not to use HOST_WIDE_INT_PRINT_DEC like we're
doing elsewhere?
jeff
^ permalink raw reply [flat|nested] 3+ messages in thread
* config/svr4.h
@ 2010-12-03 22:40 Joseph S. Myers
0 siblings, 0 replies; 3+ messages in thread
From: Joseph S. Myers @ 2010-12-03 22:40 UTC (permalink / raw)
To: gcc
The configuration header config/svr4.h is used 74 times in config.gcc
(plus one reference in a comment).
This header is nominally "Operating system specific defines to be used
when targeting GCC for some generic System V Release 4 system". GCC no
longer supports any generic System V Release 4 systems (various generic
such targets were obsoleted in 4.3). Instead, this header is used for
various configurations with nothing much in common including bare-metal
systems, GNU/Linux, uClinux, RTEMS, HP-UX, VxWork, NetBSD, OpenBSD,
NetWare, QNX and TPF - but for many of these, only for a subset of the
supported architectures.
I don't believe there is any common essence of SVR4-ness among currently
supported targets such that it makes sense to have a common header.
Figuring out what options in specs should be added to .opt file for what
targets also requires going through all 74 cases to find which specs in
this header are overridden when (any serious hookization of SIZE_TYPE,
PTRDIFF_TYPE and WCHAR_TYPE would also require figuring out just when the
definitions in this header are relevant). Thus, I propose to remove this
header, moving parts of it that are actually relevant and used for
individual targets into more appropriate headers for those targets. For
the target macros AS_NEEDS_DASH_FOR_PIPED_INPUT, MD_EXEC_PREFIX,
MD_STARTFILE_PREFIX, TARGET_POSIX_IO I propose to do this on a per-macro
basis (taking MD_*_PREFIX together), removing macro definitions from this
header and putting them in better places for the targets that need them.
For the other macros I propose to go through the targets one by one, and
for each target put the required macros in another header and stop that
target using svr4.h.
svr3.h in principle has the same issue (no "generic System V Release 3
system" support in GCC), but as (a) it defines no specs and (b) it's only
used by one target (mcore-*-pe*) it doesn't really cause problems in
practice. Thus I don't currently plan to do anything with it.
(I am not expecting any comments on this plan; this message is simply to
avoid repeating what's wrong with svr4.h and what I am doing about it in
every individual patch submission.)
--
Joseph S. Myers
joseph@codesourcery.com
^ permalink raw reply [flat|nested] 3+ messages in thread
end of thread, other threads:[~2010-12-03 22:40 UTC | newest]
Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
1998-04-12 12:43 config/svr4.h John Carr
1998-04-12 18:31 ` config/svr4.h Jeffrey A Law
2010-12-03 22:40 config/svr4.h Joseph S. Myers
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).