public inbox for gcc-patches@gcc.gnu.org
 help / color / mirror / Atom feed
From: Jonathan Wakely <jwakely.gcc@gmail.com>
To: John Marino <gnugcc@marino.st>
Cc: "Joseph S. Myers" <joseph@codesourcery.com>,
	gcc-patches <gcc-patches@gcc.gnu.org>,
		Gerald Pfeifer <gerald@pfeifer.com>,
	"manu at gcc dot gnu.org" <manu@gcc.gnu.org>,
		"Eric Botcazou (gnu.org)" <ebotcazou@gcc.gnu.org>
Subject: Re: Contributing new gcc targets: i386-*-dragonfly and x86-64-*-dragonfly
Date: Thu, 08 May 2014 13:15:00 -0000	[thread overview]
Message-ID: <CAH6eHdT1heyqo3f-08z20Zihn8-KYL+j6EpzEtK7BdbvzgX7CA@mail.gmail.com> (raw)
In-Reply-To: <53649694.6050508@marino.st>

On 3 May 2014 08:11, John Marino wrote:
> On 5/2/2014 22:15, Joseph S. Myers wrote:
>> On Fri, 2 May 2014, John Marino wrote:
>>
>>> 1) I don't know which type definitions are missing (iow, the important
>>> ones from sys/type.h that are required to build gcc)
>>
>> The default presumption should be:
>>
>> * <stddef.h> from GCC provides what it needs to provide; nothing extra is
>> needed and such a #include should not be needed at all.
>>
>> * Special measures to avoid duplicate typedefs (where some other header
>> also defines one of the typedefs defined in <stddef.h>) aren't in fact
>> needed, because GCC allows duplicate typedefs in system headers (even
>> outside C11 mode - in C11 mode it's a standard feature).
>>
>> So try removing that #include.  If that causes problems, investigate based
>> on the actual problems seen.
>
> Hi Joseph,
> Removing the include worked after also removing the #ifdef __DragonFly
> with regards to the rune_t type definition.
>
> I built gcc with a full bootstraps on both DragonFly platforms
> successfully.  stddef.h is much simpler now:
>
> --- gcc/ginclude/stddef.h.orig
> +++ gcc/ginclude/stddef.h
> @@ -133,6 +133,7 @@
>  #ifndef _BSD_PTRDIFF_T_
>  #ifndef ___int_ptrdiff_t_h
>  #ifndef _GCC_PTRDIFF_T
> +#ifndef _PTRDIFF_T_DECLARED /* DragonFly */
>  #define _PTRDIFF_T
>  #define _T_PTRDIFF_
>  #define _T_PTRDIFF
> @@ -141,10 +142,12 @@
>  #define _BSD_PTRDIFF_T_
>  #define ___int_ptrdiff_t_h
>  #define _GCC_PTRDIFF_T
> +#define _PTRDIFF_T_DECLARED
>  #ifndef __PTRDIFF_TYPE__
>  #define __PTRDIFF_TYPE__ long int
>  #endif
>  typedef __PTRDIFF_TYPE__ ptrdiff_t;
> +#endif /* _PTRDIFF_T_DECLARED */
>  #endif /* _GCC_PTRDIFF_T */
>  #endif /* ___int_ptrdiff_t_h */
>  #endif /* _BSD_PTRDIFF_T_ */
> @@ -198,6 +201,7 @@
>  #define _GCC_SIZE_T
>  #define _SIZET_
>  #if (defined (__FreeBSD__) && (__FreeBSD__ >= 5)) \
> +  || defined(__DragonFly__) \
>    || defined(__FreeBSD_kernel__)
>  /* __size_t is a typedef on FreeBSD 5, must not trash it. */
>  #elif defined (__VMS__)
>
>
> revised patchset  :
> http://leaf.dragonflybsd.org/~marino/gcc-df-target/patches/patch-dragonfly-target
> revised changelog :
> http://leaf.dragonflybsd.org/~marino/gcc-df-target/changelog_entries/gcc_ChangeLog_entry.txt
> revised commit msg:
> http://leaf.dragonflybsd.org/~marino/gcc-df-target/proposed_commit-msg.txt
>
> Good catch!  Does the rest of the patch set look good to you?  I think
> all the non-obvious patches have been reviewed collectively by various
> people now and may be ready to be approved now.

Ian's approved the libiberty.h change, Joseph's approved the stddef.h
change, I've approved the libstdc++ parts.

IIUC it still needs explicit approval for the rest, e.g. trivial
adjustments to configuration stuff in libitm and libcilkrts. Are there
specific maintainers for those libs?

The rest look obvious to me, it doesn't touch other targets at all
except for one bit that replaces a check for __FreeBSD__ >= 7 with a
grep for the dl_iterate_phdr function in a system header, which only
affects FreeBSD and looks OK to me.

Anyone willing to give it an overall approval?

  reply	other threads:[~2014-05-08 13:15 UTC|newest]

Thread overview: 25+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-04-19 19:41 John Marino
2014-04-20 19:05 ` Jonathan Wakely
2014-04-21  4:41   ` John Marino
2014-04-29 15:39     ` [PING] " John Marino
2014-04-29 17:25       ` Ian Lance Taylor
2014-04-29 18:50         ` John Marino
2014-04-30  0:07           ` Ian Lance Taylor
2014-05-01 23:03 ` Joseph S. Myers
2014-05-01 23:46   ` John Marino
2014-05-02 17:49     ` Joseph S. Myers
2014-05-02 18:17       ` John Marino
2014-05-02 20:15         ` Joseph S. Myers
2014-05-02 20:20           ` John Marino
2014-05-03  7:12           ` John Marino
2014-05-08 13:15             ` Jonathan Wakely [this message]
2014-05-08 13:32               ` Jeff Law
2014-05-08 13:36                 ` John Marino
2014-05-09  5:27             ` Jeff Law
2014-05-09  7:15               ` John Marino
2014-05-12 16:59                 ` Jeff Law
2014-05-12 17:10                   ` John Marino
2014-05-12 17:14                     ` Jeff Law
2014-05-13 14:10                       ` Jonathan Wakely
2014-05-21 11:43                     ` Jonathan Wakely
2015-04-09 20:12                       ` [doc] Add John Marino to doc/contrib.texi (was: Contributing new gcc targets: i386-*-dragonfly and x86-64-*-dragonfly) Gerald Pfeifer

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=CAH6eHdT1heyqo3f-08z20Zihn8-KYL+j6EpzEtK7BdbvzgX7CA@mail.gmail.com \
    --to=jwakely.gcc@gmail.com \
    --cc=ebotcazou@gcc.gnu.org \
    --cc=gcc-patches@gcc.gnu.org \
    --cc=gerald@pfeifer.com \
    --cc=gnugcc@marino.st \
    --cc=joseph@codesourcery.com \
    --cc=manu@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).