On Tue, 11 Jun 2019 18:01:55 -0500
Segher Boessenkool wrote:
> On Tue, Jun 11, 2019 at 09:44:30PM +0100, Jozef Lawrynowicz wrote:
> > --- a/gcc/lto/lto-lang.c
> > +++ b/gcc/lto/lto-lang.c
> > @@ -1260,9 +1260,9 @@ lto_build_c_type_nodes (void)
> > if (int_n_enabled_p[i])
> > {
> >
Hi Jozef,
On Tue, Jun 11, 2019 at 09:44:30PM +0100, Jozef Lawrynowicz wrote:
> Thanks for the pointers, they've put me on the right track I think.
>
> It doesn't look like we can create the new type in the msp430 backend - the
> SIZE_TYPE macro is examined quite early and only a couple of basic b
On Mon, 10 Jun 2019 17:09:10 -0500
Segher Boessenkool wrote:
> On Mon, Jun 10, 2019 at 08:58:00PM +0100, Jozef Lawrynowicz wrote:
> > On Mon, 10 Jun 2019 13:32:42 -0500
> > Segher Boessenkool wrote:
> > > That is not a fix, that is sweeping the problem under the rug.
> > >
> > > As a somewhat
On Mon, Jun 10, 2019 at 08:58:00PM +0100, Jozef Lawrynowicz wrote:
> On Mon, 10 Jun 2019 13:32:42 -0500
> Segher Boessenkool wrote:
> > That is not a fix, that is sweeping the problem under the rug.
> >
> > As a somewhat dirty hack I added
> >
> > #if __MSP430X_LARGE__
> > #undef __SIZE_TYPE__
>
On Mon, 10 Jun 2019 13:32:42 -0500
Segher Boessenkool wrote:
> On Mon, Jun 10, 2019 at 05:20:31PM +0100, Jozef Lawrynowicz wrote:
> > On Thu, 6 Jun 2019 10:09:32 +0200
> > Richard Biener wrote:
> >
> > > On Wed, Jun 5, 2019 at 3:26 PM Jozef Lawrynowicz
> > > wrote:
> > > >
> > > > I would
On Mon, Jun 10, 2019 at 05:20:31PM +0100, Jozef Lawrynowicz wrote:
> On Thu, 6 Jun 2019 10:09:32 +0200
> Richard Biener wrote:
>
> > On Wed, Jun 5, 2019 at 3:26 PM Jozef Lawrynowicz
> > wrote:
> > >
> > > I would appreciate if anyone can help me decide if:
> > > - It would be OK for the use of
On Thu, 6 Jun 2019 10:09:32 +0200
Richard Biener wrote:
> On Wed, Jun 5, 2019 at 3:26 PM Jozef Lawrynowicz wrote:
> >
> > I would appreciate if anyone can help me decide if:
> > - It would be OK for the use of builtin macros such as __SIZE_TYPE__ to
> > somehow
> > not trigger the "pedantic e
On Wed, 5 Jun 2019 17:12:25 -0500
Segher Boessenkool wrote:
> On Wed, Jun 05, 2019 at 08:49:39PM +0100, Jozef Lawrynowicz wrote:
> > On Wed, 5 Jun 2019 11:49:21 -0500
> > Segher Boessenkool wrote:
> > > The documentation says
> > >
> > > '-pedantic' and other options cause warnings for many
On Wed, Jun 5, 2019 at 3:26 PM Jozef Lawrynowicz wrote:
>
> The MSP430 target in the large memory model uses the (non-ISO) __int20 type
> for
> SIZE_TYPE and PTRDIFF_TYPE.
> The preprocessor therefore expands a builtin such as __SIZE_TYPE__ to
> "__int20 unsigned" in user code.
> When compiling w
On Wed, Jun 05, 2019 at 08:49:39PM +0100, Jozef Lawrynowicz wrote:
> On Wed, 5 Jun 2019 11:49:21 -0500
> Segher Boessenkool wrote:
> > The documentation says
> >
> > '-pedantic' and other options cause warnings for many GNU C extensions.
> > You can prevent such warnings within one expression
On Wed, 5 Jun 2019 11:49:21 -0500
Segher Boessenkool wrote:
> On Wed, Jun 05, 2019 at 02:25:59PM +0100, Jozef Lawrynowicz wrote:
> > I'm assuming it would not be valid to modify the behaviour of __extension__
> > so it can be placed within a declaration, and not just at the
> > beginning. However
On Wed, Jun 05, 2019 at 02:25:59PM +0100, Jozef Lawrynowicz wrote:
> I'm assuming it would not be valid to modify the behaviour of __extension__
> so it can be placed within a declaration, and not just at the
> beginning. However, there is minimal documentation on this keyword (it does
> not
> sta
The MSP430 target in the large memory model uses the (non-ISO) __int20 type for
SIZE_TYPE and PTRDIFF_TYPE.
The preprocessor therefore expands a builtin such as __SIZE_TYPE__ to
"__int20 unsigned" in user code.
When compiling with the "-pedantic-errors" flag, the use of any of these
builtin macros
13 matches
Mail list logo
