Joseph,
Thanks for the unary + suggestion.
It definitely makes sense that the bit field length must be known for
handling things like assignments, but it doesn't have to be part of
the type signature.
Martin,
I've updated bug 65471: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65471
I create
On Mon, 22 Feb 2016, Martin Sebor wrote:
> for the C standard not to support it. (The problem is simply that
> wording that specifies the feature was poorly chosen and GCC seems
> to follow it a bit too strictly, and to the detriment of usability.)
The wording for bit-fields, although unclear in
On 02/21/2016 06:44 PM, Wink Saville wrote:
I've tried you hack, but it doesn't work with "long bit fields". Also,
I've run into another problem. Instead of using unsigned char for
the bit field I changed it to a long unsigned int:33 and now I can't
print it without a warning.
That's unfortunat
On Mon, 22 Feb 2016, Wink Saville wrote:
> I understand "long" bit fields are in ISO, but its a gcc extension so
> it would seem it should play nice with as much of the language as
> possible.
>
> It seems the root of the problem here is the length encoding
> in the type, why does gcc do that, do
I'm sorry I meant:
I understand "long" bit lengths are NOT in ISO, "
On Mon, Feb 22, 2016 at 4:06 PM, Wink Saville wrote:
> I understand "long" bit fields are in ISO, but its a gcc extension so
> it would seem it should play nice with as much of the language as
> possible.
>
> It seems the
I understand "long" bit fields are in ISO, but its a gcc extension so
it would seem it should play nice with as much of the language as
possible.
It seems the root of the problem here is the length encoding
in the type, why does gcc do that, does the standard
require it?
On Mon, Feb 22, 2016 at 3
On Mon, 22 Feb 2016, Wink Saville wrote:
> What about printing of "long" bit fields? I wonder if there should be an
> option which indicates that bit field types should not include their length.
"long" bit-fields aren't even guaranteed by ISO C to be supported at all;
portable code must avoid th
I wonder if ISO C really ought to have a new Constraint "The controlling
expression of a generic selection shall not be an expression that
designates a bit-field member." (so requiring a diagnostic), much like
such expressions being disallowed in sizeof, to reflect the special nature
of bit-fie
On Sun, 21 Feb 2016, Prasad Ghangal wrote:
> - pedwarn_init (loc, 0,
> -"excess elements in array initializer");
> + pedwarn_init (loc, 0, "excess elements in array initializer "
> + "(%lu elements, expected %lu)",
> + tree_to_uhwi (const
On 02/22/2016 11:52 AM, Bin.Cheng wrote:
Hi,
I still don't quite follow this method. If I pop up chroot
environment with new glibc, it's still possible that the new glibc
isn't compatible with the default gcc in chroot. Won't this a
chicken-egg problem because we want to build our gcc against n
On Mon, Feb 1, 2016 at 7:45 PM, Jeff Law wrote:
> On 02/01/2016 12:07 PM, Bin.Cheng wrote:
>>
>> On Mon, Feb 1, 2016 at 6:08 PM, Andreas Schwab
>> wrote:
>>>
>>> "Bin.Cheng" writes:
>>>
Seems to me Andrew was right in comment of PR69559, that we simply
couldn't bootstrap GCC with sysro
Hi, Jim
On Mon, Feb 22, 2016 at 12:53 PM, Jim Wilson wrote:
> On Mon, Feb 22, 2016 at 7:55 AM, David Edelsohn wrote:
>> If I remove extendqihi2 (extend:HI pattern) from the PowerPC port,
>> will that cause any problems for the GCC RTL type system or inhibit
>> optimizations? I see that Alpha a
On Mon, Feb 22, 2016 at 7:55 AM, David Edelsohn wrote:
> If I remove extendqihi2 (extend:HI pattern) from the PowerPC port,
> will that cause any problems for the GCC RTL type system or inhibit
> optimizations? I see that Alpha and SPARC define extendqihi2, but
> IA-64 and AArch64 do not, so the
On Mon, 2016-02-22 at 11:14 -0500, David Edelsohn wrote:
> I am pleased to announce that the GCC Steering Committee has
> appointed David Malcolm as libcpp and diagnostic messages maintainer.
>
> Please join me in congratulating David on his new role.
> David, please update your listin
I am pleased to announce that the GCC Steering Committee has
appointed David Malcolm as libcpp and diagnostic messages maintainer.
Please join me in congratulating David on his new role.
David, please update your listing in the MAINTAINERS file.
Happy hacking!
David
On 02/22/2016 08:55 AM, David Edelsohn wrote:
csmith has uncovered a latent bug in the the PowerPC port for a
combiner pattern involving extendqihi2 (the alternative in the pattern
has never triggered for real code in over 10 years). Basic extendqihi2
works correctly (the instructions extend to e
csmith has uncovered a latent bug in the the PowerPC port for a
combiner pattern involving extendqihi2 (the alternative in the pattern
has never triggered for real code in over 10 years). Basic extendqihi2
works correctly (the instructions extend to entire register, but the
upper bits are ignored).
Hi,
On Sat, 20 Feb 2016, Richard Smith wrote:
> > An empty type is a type where it and all of its subobjects
> > (recursively) are of class, structure, union, or array type.
> >
> > doesn't cover "trivially-copyable".
>
> That's correct. Whether a type is trivially copyable is unrelated to
> w
Hi,
On Fri, 19 Feb 2016, Richard Smith wrote:
> >> > The trivially copyable is gone again. Why is it not necessary?
> >>
> >> The C++ ABI doesn't defer to the C psABI for types that aren't
> >> trivially-copyable. See
> >> http://mentorembedded.github.io/cxx-abi/abi.html#normal-call
> >
> > Hmm,
On Mon, 22 Feb 2016, Prathamesh Kulkarni wrote:
> Hi Richard,
> As discussed in private mail, this version of patch attempts to
> increase alignment
> of global struct decl if it contains an an array field(s) and array's
> offset is a multiple of the alignment of vector type corresponding to
> it'
On Mon, Feb 22, 2016 at 02:57:43PM +0530, Hari Narasimhan H.N wrote:
> Dear Sir,
>
> We are getting the following error "section type conflict" with xtensa
> gcc when a const and non const global variable is placed in the same
> section?
>
> I am using a bare metal cross gcc toolchain for Xtensa
Dear Sir,
We are getting the following error "section type conflict" with xtensa
gcc when a const and non const global variable is placed in the same
section?
I am using a bare metal cross gcc toolchain for Xtensa architecture
built as per instructions in
http://wiki.linux-xtensa.org/index.php/Cr
Hi Richard,
As discussed in private mail, this version of patch attempts to
increase alignment
of global struct decl if it contains an an array field(s) and array's
offset is a multiple of the alignment of vector type corresponding to
it's scalar type and recursively checks for nested structs.
eg:
23 matches
Mail list logo
