Hello all,
I am not expert but I would like bring attention to some
facts which come to my mind
On Monday 22 of August 2016 18:19:06 Andy Ross wrote:
> --- 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
>
On 22/08/16 17:09, Andy Ross wrote:
> The reproduction is straightforward. Just build any cross gcc with
> --enable-newlib (e.g. the one in the Zephyr SDK) and compile this
> (on any 32 or 64 bit 2's complement architecture) with newlib's
> headers.
>
> #include
>
> extern void takes_fm
On Mon, 22 Aug 2016, Andy Ross wrote:
> And gcc, as seen by this patch, sets it to a long because it thinks
> that's what newlib *wants*.
That would be because a newlib version that included the change
commit 843e635aaa02f16f314688ba5dd8a5edc3929095
Author: Jeff Johnston
Date: Fri Dec 16 19:0
Andrew Pinski wrote:
> On Mon, Aug 22, 2016 at 9:42 AM, Andy Ross wrote:
> > I don't follow. There's no change to the ABI, the generated code is
> > identical in all cases. Can you explain what you mean?
>
> The encoding of int and long are different in C++. So if you have a
> library built whe
On Mon, Aug 22, 2016 at 9:42 AM, Andy Ross wrote:
> Andrew Pinski wrote:
>> Why do you think the above code does not have a bug in it? int32_t
>> is long and changing it now is changing the ABI (especially for
>> C++).
>
> I don't follow. There's no change to the ABI, the generated code is
> ide
Andrew Pinski wrote:
> Why do you think the above code does not have a bug in it? int32_t
> is long and changing it now is changing the ABI (especially for
> C++).
I don't follow. There's no change to the ABI, the generated code is
identical in all cases. Can you explain what you mean?
The pro
On Mon, Aug 22, 2016 at 9:09 AM, Andy Ross wrote:
> The reproduction is straightforward. Just build any cross gcc with
> --enable-newlib (e.g. the one in the Zephyr SDK) and compile this
> (on any 32 or 64 bit 2's complement architecture) with newlib's
> headers.
>
> #include
>
> extern
Same code. Includes an attempt to format a change log entry in a more
gcc-friendly way. I'm new here.
>From c208b51fb55c6758c1059dfaee398c27da398e9d Mon Sep 17 00:00:00 2001
From: Andy Ross
Date: Fri, 19 Aug 2016 09:40:42 -0700
Subject: [PATCH] newlib-stdint.h: Remove 32 bit longs
This would m
The reproduction is straightforward. Just build any cross gcc with
--enable-newlib (e.g. the one in the Zephyr SDK) and compile this
(on any 32 or 64 bit 2's complement architecture) with newlib's
headers.
#include
extern void takes_fmt(const char *fmt, ...)
__attribute__ ((form
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 wrote:
>On Fri
On Fri, Aug 19, 2016 at 12:16 PM, Andy Ross 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
11 matches
Mail list logo
