public inbox for newlib@sourceware.org
 help / color / mirror / Atom feed
From: Joel Sherrill <joel.sherrill@oarcorp.com>
To: Andrew Pinski <pinskia@gmail.com>,Andy Ross <andrew.j.ross@intel.com>
Cc: GCC Patches <gcc-patches@gcc.gnu.org>,"<newlib@sourceware.org>"
	<newlib@sourceware.org>
Subject: Re: [PATCH] newlib-stdint.h: Remove 32 bit longs
Date: Sat, 20 Aug 2016 01:42:00 -0000	[thread overview]
Message-ID: <E14AB9B3-7DD2-47AF-A6E0-4A48EE7EC068@oarcorp.com> (raw)
In-Reply-To: <CA+=Sn1nAj0n2DJgwCUY434qxq-09zw62=+xt1JLbzS9dHo46jA@mail.gmail.com>

RTEMS uses the PRI constants and we don't see warnings. Is there a specific test case which would demonstrate this is actually broken. The file newlib-stdint.h will impact more targets than Zephyr and I think they owe a demo case.

On August 19, 2016 7:37:22 PM EDT, Andrew Pinski <pinskia@gmail.com> wrote:
>On Fri, Aug 19, 2016 at 12:16 PM, Andy Ross <andrew.j.ross@intel.com>
>wrote:
>> We ran into this issue in the Zephyr project with our toolchain (gcc
>> built with --enable-newlib).  Basically GCC appears to be honoring a
>> legacy requirement to give newlib a "long" instead of "int" for
>> __INT32_TYPE__, which then leaks out through the current newlib
>> headers as a long-valued int32_t, which produces gcc warnings when a
>> uint32_t is passed to an unqualified printf format specifier like
>> "%d".
>>
>> But the newlib headers, if __INT32_TYPE__ is *not* defined by the
>> compiler, have code to chose a "int" over "long" immediately
>> thereafter.  It seems whatever requirement this was honoring isn't
>> valid anymore.
>
>Couple of things missing here.  A changelog is the first thing.
>The second thing is it seems like Zephyr project should be using the
>PRIdx, etc. instead of just %d for int32_t to be portable.
>
>Thanks,
>Andrew
>
>
>>
>> From 784fb1760a930d0309f878bbae7bfd38137f5689 Mon Sep 17 00:00:00
>2001
>> From: Andy Ross <andrew.j.ross@intel.com>
>> Date: Fri, 19 Aug 2016 09:40:42 -0700
>> Subject: [PATCH] newlib-stdint.h: Remove 32 bit longs
>>
>> This would make __INT32_TYPE__ a "long" instead of an "int", which
>> would then percolate down in newlib's own headers into a typedef for
>> int32_t.  Which is wrong.  Newlib's headers, if __INT32_TYPE__ were
>> not defined, actually would chose an int for this type.  The comment
>> that newlib uses a 32 bit long appears to be a lie, perhaps
>> historical.
>>
>> Signed-off-by: Andy Ross <andrew.j.ross@intel.com>
>> ---
>>  gcc/config/newlib-stdint.h | 5 ++---
>>  1 file changed, 2 insertions(+), 3 deletions(-)
>>
>> diff --git a/gcc/config/newlib-stdint.h b/gcc/config/newlib-stdint.h
>> index eb99556..0275948 100644
>> --- a/gcc/config/newlib-stdint.h
>> +++ b/gcc/config/newlib-stdint.h
>> @@ -22,10 +22,9 @@ a copy of the GCC Runtime Library Exception along
>with this program;
>>  see the files COPYING3 and COPYING.RUNTIME respectively.  If not,
>see
>>  <http://www.gnu.org/licenses/>.  */
>>
>> -/* newlib uses 32-bit long in certain cases for all non-SPU
>> -   targets.  */
>> +/* newlib used to use a 32-bit long, no longer */
>>  #ifndef STDINT_LONG32
>> -#define STDINT_LONG32 (LONG_TYPE_SIZE == 32)
>> +#define STDINT_LONG32 0
>>  #endif
>>
>>  #define SIG_ATOMIC_TYPE "int"
>> --
>> 2.7.4
>>

--joel

  reply	other threads:[~2016-08-20  1:42 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-08-19 19:16 Andy Ross
2016-08-19 23:37 ` Andrew Pinski
2016-08-20  1:42   ` Joel Sherrill [this message]
2016-08-22 16:10     ` Andy Ross
2016-08-22 16:37       ` Andrew Pinski
2016-08-22 16:43         ` Andy Ross
2016-08-22 16:47           ` Andrew Pinski
2016-08-22 16:56             ` Andy Ross
2016-08-22 18:00       ` Joseph Myers
2016-08-22 18:35       ` Richard Earnshaw
2016-08-22 20:27       ` Hans-Bernhard Bröker
2016-08-22 20:35         ` Andy Ross
2016-08-22 16:19 ` Andy Ross
2016-08-22 22:27   ` Pavel Pisa

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=E14AB9B3-7DD2-47AF-A6E0-4A48EE7EC068@oarcorp.com \
    --to=joel.sherrill@oarcorp.com \
    --cc=andrew.j.ross@intel.com \
    --cc=gcc-patches@gcc.gnu.org \
    --cc=newlib@sourceware.org \
    --cc=pinskia@gmail.com \
    /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).