On 20/11/15 01:23, David Wohlferd wrote:
> I tried to picture the most basic case I can think of that uses
> something clobber-able:
>
> for (int x=0; x < 1000; x++)
>asm("#stuff");
>
> This generates very simple and highly performant code:
>
> movl$1000, %eax
> .L2:
>
On 11/20/2015 2:17 AM, Andrew Haley wrote:
On 20/11/15 01:23, David Wohlferd wrote:
I tried to picture the most basic case I can think of that uses
something clobber-able:
for (int x=0; x < 1000; x++)
asm("#stuff");
This generates very simple and highly performant code:
On 11/19/2015 7:14 PM, Segher Boessenkool wrote:
On Thu, Nov 19, 2015 at 05:23:55PM -0800, David Wohlferd wrote:
For that reason, I'd like to propose adding 2 new clobbers to extended
asm as part of this work:
"clobberall" - This gives extended the same semantics as whatever the
new basic asm w
On 20/11/15 10:37, David Wohlferd wrote:
> The intent for 24414 is to change basic asm such that it will become
> (quoting jeff) "an opaque blob that read/write/clobber any register or
> memory location." Such being the case, "memory" is not sufficient:
>
> #define CLOBBERALL "eax", "ebx", "ecx
On 11/20/2015 3:14 AM, Andrew Haley wrote:
On 20/11/15 10:37, David Wohlferd wrote:
The intent for 24414 is to change basic asm such that it will become
(quoting jeff) "an opaque blob that read/write/clobber any register or
memory location." Such being the case, "memory" is not sufficient:
#de
Status
==
We plan to do a GCC 5.3 release candidate at the end of next week
followed by the actual release a week after that.
So now is the time to look at your regression bugs in bugzilla and
do some backporting for things already fixed on trunk.
Quality Data
Priority
On 11/20/2015 01:38 PM, David Wohlferd wrote:
On 11/20/2015 3:14 AM, Andrew Haley wrote:
On 20/11/15 10:37, David Wohlferd wrote:
The intent for 24414 is to change basic asm such that it will become
(quoting jeff) "an opaque blob that read/write/clobber any register or
memory location." Such b
Hey,
I wanted to reach out and let you know about this link which isn’t
working -
http://developer.apple.com/documentation/Cocoa/Conceptual/ObjectiveC/, I
found it on this page -
http://gd.tuwien.ac.at/.vhost/www.gnu.org/software/gcc/readings.html.
You’re link includes this text - "Objective
On Fri, Nov 20, 2015 at 7:53 AM, Richard Biener wrote:
>
> Status
> ==
>
> We plan to do a GCC 5.3 release candidate at the end of next week
> followed by the actual release a week after that.
>
> So now is the time to look at your regression bugs in bugzilla and
> do some backporting for thin
On 20 November 2015 at 13:12, wrote:
> Hey,
>
> I wanted to reach out and let you know about this link which isn’t working -
> http://developer.apple.com/documentation/Cocoa/Conceptual/ObjectiveC/, I
> found it on this page -
> http://gd.tuwien.ac.at/.vhost/www.gnu.org/software/gcc/readings.html.
On Fri, Nov 20, 2015 at 02:45:05AM -0800, David Wohlferd wrote:
> On 11/19/2015 7:14 PM, Segher Boessenkool wrote:
> >On Thu, Nov 19, 2015 at 05:23:55PM -0800, David Wohlferd wrote:
> >>For that reason, I'd like to propose adding 2 new clobbers to extended
> >>asm as part of this work:
> >>
> >>"cl
On Fri, Nov 20, 2015 at 02:05:01PM +0100, Richard Henderson wrote:
> I'd be perfectly happy to deprecate and later completely remove basic asm
> within functions.
>
> Because IMO it's essentially useless. It has no inputs, no outputs, and no
> way to tell the compiler what machine state has bee
On 11/20/2015 04:20 PM, Segher Boessenkool wrote:
On Fri, Nov 20, 2015 at 02:05:01PM +0100, Richard Henderson wrote:
I'd be perfectly happy to deprecate and later completely remove basic asm
within functions.
Because IMO it's essentially useless. It has no inputs, no outputs, and no
way to tel
Sebastian,
I have tried to build GCC with Graphite and ISL on AIX and encountered
two problems:
(1) isl/ctx.h
typedef enum {
isl_stat_error = -1,
isl_stat_ok = 0,
} isl_stat;
GCC complains about the comma in "isl_stat_ok = 0,". This seems like
a general bug that should appear o
On Fri, Nov 20, 2015 at 04:29:50PM +0100, Richard Henderson wrote:
> On 11/20/2015 04:20 PM, Segher Boessenkool wrote:
> >On Fri, Nov 20, 2015 at 02:05:01PM +0100, Richard Henderson wrote:
> >>I'd be perfectly happy to deprecate and later completely remove basic asm
> >>within functions.
> >>
> >>B
On 11/20/2015 04:34 PM, Jakub Jelinek wrote:
Isn't that going to break too much code though? I mean, e.g. including
libgcc...
I don't know. My suspicion is very little.
But that's actually what I'd like to know before we start adjusting code in
other ways wrt basic asms.
r~
On Fri, Nov 20, 2015 at 9:31 AM, David Edelsohn wrote:
> Sebastian,
>
> I have tried to build GCC with Graphite and ISL on AIX and encountered
> two problems:
>
> (1) isl/ctx.h
>
> typedef enum {
> isl_stat_error = -1,
> isl_stat_ok = 0,
> } isl_stat;
>
> GCC complains about the co
On Fri, Nov 20, 2015 at 04:29:50PM +0100, Richard Henderson wrote:
> >>It seems to me that it would be better to remove the feature, forcing what
> >>must be an extremely small number of users to audit and update to extended
> >>asm.
> >
> >Should asm("bla"); then be an extended asm with no input
On Fri, Nov 20, 2015 at 10:14:47AM -0600, Sebastian Pop wrote:
> On Fri, Nov 20, 2015 at 9:31 AM, David Edelsohn wrote:
> > Sebastian,
> >
> > I have tried to build GCC with Graphite and ISL on AIX and encountered
> > two problems:
> >
> > (1) isl/ctx.h
> >
> > typedef enum {
> > isl_stat_
Thanks David for reporting these problems.
On Fri, Nov 20, 2015 at 9:31 AM, David Edelsohn wrote:
> (2) All of the graphite*.c files include ISL headers first. This
> order is not supported by GCC development and creates conflicts for
> types and definitions provided / overridden by GCC headers,
On Fri, Nov 20, 2015 at 10:23 AM, Sven Verdoolaege wrote:
> On Fri, Nov 20, 2015 at 10:14:47AM -0600, Sebastian Pop wrote:
>> On Fri, Nov 20, 2015 at 9:31 AM, David Edelsohn wrote:
>> > Sebastian,
>> >
>> > I have tried to build GCC with Graphite and ISL on AIX and encountered
>> > two problems:
On Fri, Nov 20, 2015 at 11:31 AM, Sebastian Pop wrote:
> On Fri, Nov 20, 2015 at 10:23 AM, Sven Verdoolaege
> wrote:
>> On Fri, Nov 20, 2015 at 10:14:47AM -0600, Sebastian Pop wrote:
>>> On Fri, Nov 20, 2015 at 9:31 AM, David Edelsohn wrote:
>>> > Sebastian,
>>> >
>>> > I have tried to build GC
On 11/20/2015 04:14 AM, Andrew Haley wrote:
On 20/11/15 10:37, David Wohlferd wrote:
The intent for 24414 is to change basic asm such that it will become
(quoting jeff) "an opaque blob that read/write/clobber any register or
memory location." Such being the case, "memory" is not sufficient:
#d
On Fri, Nov 20, 2015 at 11:28 AM, Sebastian Pop wrote:
> Thanks David for reporting these problems.
>
> On Fri, Nov 20, 2015 at 9:31 AM, David Edelsohn wrote:
>> (2) All of the graphite*.c files include ISL headers first. This
>> order is not supported by GCC development and creates conflicts fo
On Fri, Nov 20, 2015 at 10:43 AM, David Edelsohn wrote:
> On Fri, Nov 20, 2015 at 11:28 AM, Sebastian Pop wrote:
>> Thanks David for reporting these problems.
>>
>> On Fri, Nov 20, 2015 at 9:31 AM, David Edelsohn wrote:
>>> (2) All of the graphite*.c files include ISL headers first. This
>>> or
On Tue, 17 Nov 2015, Joseph Myers wrote:
> > Any or all of these options may have effects beyond propagating the IEEE
> > Std 754 compliance mode down to the assembler and the linker. In
> > particular `-mieee=strict' is expected to guarantee code generated to
> > fully comply to IEEE Std 754 ra
On 11/20/2015 06:05 AM, Richard Henderson wrote:
I'd be perfectly happy to deprecate and later completely remove basic
asm within functions.
Because IMO it's essentially useless. It has no inputs, no outputs, and
no way to tell the compiler what machine state has been changed. We can
say tha
On Fri, 20 Nov 2015, Maciej W. Rozycki wrote:
> The target audience for the `-mieee=strict' option is in my idea a
> non-technical user, say a physicist, who does not necessarily know or is
> fluent with the guts of computer hardware and who has the need to build
> and reliably run their softw
> On Nov 20, 2015, at 1:24 PM, Jeff Law wrote:
>
> On 11/20/2015 06:05 AM, Richard Henderson wrote:
>
>> ...
>> It seems to me that it would be better to remove the feature, forcing
>> what must be an extremely small number of users to audit and update to
>> extended asm.
> That might be a litt
On 11/20/2015 07:56 AM, Segher Boessenkool wrote:
When basic asm changes, I expect that having a way to "just do what it
used to do" is going to be useful for some people.
24414 says the documented behaviour hasn't been true for at least
fourteen years. It isn't likely anyone is relying on tha
> On Nov 20, 2015, at 3:01 PM, Jeff Law wrote:
>
> On 11/20/2015 07:56 AM, Segher Boessenkool wrote:
>
> When basic asm changes, I expect that having a way to "just do what it
> used to do" is going to be useful for some people.
24414 says the documented behaviour hasn't been true
On 11/20/2015 8:14 AM, Richard Henderson wrote:
On 11/20/2015 04:34 PM, Jakub Jelinek wrote:
Isn't that going to break too much code though? I mean, e.g. including
libgcc...
I don't know. My suspicion is very little.
But that's actually what I'd like to know before we start adjusting
code
32 matches
Mail list logo
