On Oct 30, 2015, at 1:56 AM, Eric Botcazou wrote:
>> It won’t. Fixing the language line for the options and a make to ensure it
>> still builds for you is enough testing.
>
> I was talking about the feature itself though, not about the option per se.
> The feature is tested for C & C++ but not
> It won’t. Fixing the language line for the options and a make to ensure it
> still builds for you is enough testing.
I was talking about the feature itself though, not about the option per se.
The feature is tested for C & C++ but not for ObjC & ObjC++ so there might be
surprises.
> None is
On Wed, 28 Oct 2015, Mike Stump wrote:
> On Oct 28, 2015, at 3:04 PM, Eric Botcazou wrote:
> >> Why is -fsso-struct= listed only for C and C++, not ObjC and ObjC++?
> >
> > Because it was not tested with the latter 2 languages at all and may
> > require
> > specific adjustments in the respecti
On Oct 28, 2015, at 3:04 PM, Eric Botcazou wrote:
>> Why is -fsso-struct= listed only for C and C++, not ObjC and ObjC++?
>
> Because it was not tested with the latter 2 languages at all and may require
> specific adjustments in the respective front-ends to work.
It won’t. Fixing the language
> Why is -fsso-struct= listed only for C and C++, not ObjC and ObjC++?
Because it was not tested with the latter 2 languages at all and may require
specific adjustments in the respective front-ends to work.
> Almost all C options should be supported for ObjC and almost all C++
> options should b
On 10/28/2015 10:43 AM, Joseph Myers wrote:
Why is -fsso-struct= listed only for C and C++, not ObjC and ObjC++?
Almost all C options should be supported for ObjC and almost all C++
options should be supported for ObjC++ (and the existing cases that aren't
in c.opt generally look dubious).
I miss
Why is -fsso-struct= listed only for C and C++, not ObjC and ObjC++?
Almost all C options should be supported for ObjC and almost all C++
options should be supported for ObjC++ (and the existing cases that aren't
in c.opt generally look dubious).
--
Joseph S. Myers
jos...@codesourcery.com
> > + if (BYTES_BIG_ENDIAN != WORDS_BIG_ENDIAN)
> > +error ("scalar_storage_order is not supported");
>
> You might want to consider indicating why it's not supported. Not that
> I expect folks to be using this on a pdp11 :-)
Done, I added "because endianness is not uniform".
> > - /*
On 10/06/2015 05:02 AM, Eric Botcazou wrote:
This is the C front-end + C family part.
* doc/extend.texi (type attributes): Document scalar_storage_order.
(Structure-Packing Pragmas): Rename into...
(Structure-Layout Pragmas): ...this. Document scalar_storage_order.
This is the C front-end + C family part.
* doc/extend.texi (type attributes): Document scalar_storage_order.
(Structure-Packing Pragmas): Rename into...
(Structure-Layout Pragmas): ...this. Document scalar_storage_order.
* doc/invoke.texi (C Dialect Options): Docum
> You appear to be duplicating the documentation of an unrelated attribute.
Merge glitch, now fixed, thanks.
> What happens when typeof is applied to a field with reversed storage
> order?
You mean a scalar field contained in an aggregate type with reverse SSO? Then
nothing, nothing is changed
> "illegal" -> "invalid" or "not permitted"
The ISO standard for Ada contains this (1.1.2 Structure):
Legality Rules
27 Rules that are enforced at compile time. A construct is legal if it obeys
all of the Legality Rules.
and "illegal" is documented in the Index.
But the standard for C doesn't
> A very cursory glance at the patch set but should we restrict this
> attribute to apply only to scalar types rather than allow them on vector
> extensions. I haven't had enough coffee this morning but a first
> thought is that if it does apply on vector type extensions, clarifying
> the lane ord
On Tue, 16 Jun 2015, Eric Botcazou wrote:
> +@item unused
> +@cindex @code{unused} type attribute
> +When attached to a type (including a @code{union} or a @code{struct}),
> +this attribute means that variables of that type are meant to appear
> +possibly unused. GCC does not produce a warning fo
Eric Botcazou writes:
> This is the C front-end + C family part.
>
> * doc/extend.texi (type attributes): Document scalar_storage_order.
> * doc/invoke.texi (Warnings): Document -Wno-scalar-storage-order.
> c-family/
> * c-common.c (c_common_attributes): Add scalar_storage_order.
On Tue, Jun 16, 2015 at 2:06 AM, Ramana Radhakrishnan
wrote:
>
>
> On 16/06/15 09:54, Eric Botcazou wrote:
>>
>> This is the C front-end + C family part.
>>
>> * doc/extend.texi (type attributes): Document
>> scalar_storage_order.
>> * doc/invoke.texi (Warnings): Document -Wno-scal
On 16/06/15 09:54, Eric Botcazou wrote:
This is the C front-end + C family part.
* doc/extend.texi (type attributes): Document scalar_storage_order.
* doc/invoke.texi (Warnings): Document -Wno-scalar-storage-order.
c-family/
* c-common.c (c_common_attributes): Add scala
This is the C front-end + C family part.
* doc/extend.texi (type attributes): Document scalar_storage_order.
* doc/invoke.texi (Warnings): Document -Wno-scalar-storage-order.
c-family/
* c-common.c (c_common_attributes): Add scalar_storage_order.
(handle_scalar_stor
18 matches
Mail list logo
