What is the status of the x86 interrupt attribute patch?
One of the last references I see is here and an attempt to update the
middle-end here.
-- Wink
It looks like it will be awhile before its included, what's your guess
on when stage1 will commence for GCC 7?
About how often will you be rebasing hjl/interrupt/stage1 onto master?
On Mon, Jan 18, 2016 at 9:47 AM H.J. Lu wrote:
>
> On Mon, Jan 18, 2016 at 9:39 AM, Wink Saville wrot
I using hjl/interrupt/gcc-5-branch and my program is crashing when I
issue an INT xx. The problem appears to me to be that using
__attribute__ ((interrupt)) causes the a IRET to be emitted when an
IRETQ should be emitted. Below is my trivial do nothing main.c which I
compile with and then use objdu
When I shift a bit field in an expression small bit fields behave
one way and large bit fields another. I'm using gcc 5.3.0 on Arch Linux:
$ gcc --version
gcc (GCC) 5.3.0
Copyright (C) 2015 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
wa
You've convinced me that this isn't a bug, but I assume you'd agree
its weird at best. I tested it with clang and it works as I'd expect:
$ make
clang -x c -m64 -O3 -Wall -o test.o -c test.c
objdump -d test.o > test.txt
clang -m64 -O3 -Wall test.o -o test
wink@wink-desktop:~/prgs/large_fields_are_
What is the process for a patch with a new option to allow a different behavior?
I'm using gcc 5.3.0:
$ gcc --version
gcc (GCC) 5.3.0
Copyright (C) 2015 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
And I've tried to use _Generic to print th
The two links in msg00156.html point to single emails and the
formatting is odd, such as in 13560.txt:
i =3D =5FGeneric(st.bf,
Is there a way to look at the actual email thread using a browser or
some other means?
On Fri, Feb 19, 2016 at 9:30 AM, Joseph Myers wrote:
> See the references I ga
test.c:46:10: warning: format ‘%lx’ expects argument of type ‘long
unsigned int’, but argument 2 has type ‘long unsigned int:33’
[-Wformat=]
printf(" <<1 =0x%016lx\n", bbf.b33 << 1);
^
objdump -d test.o > test.txt
gcc -m64 -Wall -std=c11 test.o -o test
bb
2, 2016 at 3:48 PM, Joseph Myers wrote:
> 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-
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
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
See comment on (c) below
On Wed, Feb 24, 2016 at 1:53 PM Joseph Myers wrote:
>
> On Wed, 24 Feb 2016, Martin Sebor wrote:
>
> > > That can be avoided simply by using unary + in the controlling expression
> > > of _Generic (just as using unary + will avoid an error from sizeof, if you
> > > want t
On Wed, Feb 24, 2016 at 3:38 PM, Joseph Myers wrote:
> On Wed, 24 Feb 2016, Wink Saville wrote:
>
>> > (c) nothing defines semantics of conversion of out-of-range values to
>> > bit-fields other than treating the width as part of the type (or in the
>> > cas
Thanks for the info. What I'll probably do is file a bug and reply to this
thread and the other one when I do.
On Thu, Feb 25, 2016, 2:50 PM Joseph Myers wrote:
>
> On Wed, 24 Feb 2016, Wink Saville wrote:
>
> > Further more things like printing of "big" bit fi
15 matches
Mail list logo
