This is the mail archive of the
mailing list for the GCC project.
Re: Darwin bootstrap failure following wide int merge
- From: Jakub Jelinek <jakub at redhat dot com>
- To: Richard Biener <richard dot guenther at gmail dot com>
- Cc: FX <fxcoudert at gmail dot com>, Mike Stump <mikestump at comcast dot net>, echristo at gmail dot com, Stan Shebs <stanshebs at earthlink dot net>, GCC Development <gcc at gcc dot gnu dot org>, glisse at gcc dot gnu dot org, Kenneth Zadeck <zadeck at naturalbridge dot com>, gcc-patches <gcc-patches at gcc dot gnu dot org>, Gerald Pfeifer <gerald at pfeifer dot com>, rsandifo at linux dot vnet dot ibm dot com
- Date: Wed, 28 May 2014 16:00:32 +0200
- Subject: Re: Darwin bootstrap failure following wide int merge
- Authentication-results: sourceware.org; auth=none
- References: <20140528065033 dot GV10386 at tucnak dot redhat dot com> <CAFiYyc2tLShbmh_4RzMqCO+yky8voEOhTpY1aqjYMLq+dAP8Pg at mail dot gmail dot com> <87fvjub9an dot fsf at talisman dot default> <CAFiYyc3OHoky7X8eNmz28xvJy_=ayCB2xwf3K7iSEoVyy+rHRw at mail dot gmail dot com> <CAFiYyc2Lh74GAxLaOoPCs9OOXFa=mvcsakLFNd_RMPfX4wpBqA at mail dot gmail dot com> <87k396xmfs dot fsf at sandifor-thinkpad dot stglab dot manchester dot uk dot ibm dot com> <CAFiYyc1tiR1zF+V1npe4+QxnewW4X7Obrigsy=QOsCeAVozQ8A at mail dot gmail dot com> <20140528111456 dot GB10386 at tucnak dot redhat dot com> <D5D0BC18-C4B0-4D37-872C-0696A7449C47 at gmail dot com> <CAFiYyc2WfSkcwPmVMUXr1MhshNGEZPgB=Fgt7AXZ2gs3Ahwvbw at mail dot gmail dot com>
- Reply-to: Jakub Jelinek <jakub at redhat dot com>
On Wed, May 28, 2014 at 03:47:52PM +0200, Richard Biener wrote:
> On Wed, May 28, 2014 at 3:15 PM, FX <firstname.lastname@example.org> wrote:
> >> After lengthy IRC discussions, what Richard and I can live with is
> >> && !defined(__clang__) in this particular case that uses longlong.h
> >> in GCC sources, with a comment why.
> > Iâll test this patch and commit if there is no problem. But right now, current trunk doesnât build on x86_64-apple-darwin due to error below. Richard, could this be due to your revision 211013?
> Hum, yeah. But why does it even warn if sizeof (long) == sizeof (long long)?
Because using the right format strings is important for portability.
> I suppose casting the result of CWI_ELT () to uint64_t fixes this. Do
> similar errors happen elsewhere?
> (the hex printfs expect unsigned types but CWI_ELT returns a signed
I think the sign shouldn't be a problem, but perhaps there is a mismatch
between HOST_WIDE_INT definition and HOST_WIDE_INT_PRINT_HEX?
Defining HOST_WIDE_INT to long long or long based on whether long is 64-bit
or not, but using PRIx64 etc. unconditionally is just wrong, either
HOST_WIDE_INT should be uint64_t and then you should use PRI*64, or it is
not, and then you should keep using what has been used in the past,
different macros depending on how HOST_WIDE_INT is defined.