On Mon, Oct 19, 2015 at 11:14:30PM -0600, Jeff Law wrote:
> >>+All global register variable declarations must precede all function
> >>+definitions. If such a declaration appears after function definitions,
> >>+the declaration would be too late to prevent the register from being used
> >>+for oth
On Mon, Oct 19, 2015 at 11:25:27PM -0600, Jeff Law wrote:
> >>+Defining a register variable does not reserve the register; it
> >>+remains available for other uses in places where flow control determines
> >>+the variable's value is not live. For this reason, the following uses
> >
> >This is misl
Hi,
--- sched-int.h ---
/* Information about the dependency. */
struct _dep
{
struct dep_replacement *replace;
};
typedef dep_def *dep_t;
--- sched-deps.c ---
static void
copy_dep (dep_t to, dep_t from)
{
memcpy (to, from, sizeof (*to)); // oops?
}
This might be source of doubl
On 10/20/2015 03:12 AM, Segher Boessenkool wrote:
On Mon, Oct 19, 2015 at 11:14:30PM -0600, Jeff Law wrote:
+All global register variable declarations must precede all function
+definitions. If such a declaration appears after function definitions,
+the declaration would be too late to prevent
On 10/20/2015 03:29 AM, Segher Boessenkool wrote:
On Mon, Oct 19, 2015 at 11:25:27PM -0600, Jeff Law wrote:
+Defining a register variable does not reserve the register; it
+remains available for other uses in places where flow control determines
+the variable's value is not live. For this reaso
On 10/20/2015 03:43 AM, Konstantin Vladimirov wrote:
Hi,
--- sched-int.h ---
/* Information about the dependency. */
struct _dep
{
struct dep_replacement *replace;
};
typedef dep_def *dep_t;
--- sched-deps.c ---
static void
copy_dep (dep_t to, dep_t from)
{
memcpy (to, from,
On Mon, Oct 19, 2015 at 11:22:06PM -0600, Jeff Law wrote:
> WRT your hope to limit this to only uses in extended asms. That'd be
> nice, but that's never been an explicit limitation. I would strongly
> hesitate to add that limitation at this point in time.
r88265 (from 2004) made explicit that
Hi Richard,
On 10/16/2015 05:09 AM, Richard Biener wrote:
This means it is time to get things you want to have in GCC 6 finalized
and reviewed. As usual there may be exceptions to late reviewed features
but don't count on that. Likewise target specific features can sneak in
during Stage 3 if m
On 10/20/2015 09:13 AM, Segher Boessenkool wrote:
On Mon, Oct 19, 2015 at 11:22:06PM -0600, Jeff Law wrote:
WRT your hope to limit this to only uses in extended asms. That'd be
nice, but that's never been an explicit limitation. I would strongly
hesitate to add that limitation at this point in
On 10/20/2015 09:42 AM, Pierre-Marie de Rodat wrote:
Hi Richard,
On 10/16/2015 05:09 AM, Richard Biener wrote:
This means it is time to get things you want to have in GCC 6 finalized
and reviewed. As usual there may be exceptions to late reviewed features
but don't count on that. Likewise tar
On 10/20/2015 05:00 PM, Jeff Law wrote:
> But the technical reality is I can't see a use outside the extended asm.
I can. In the past (and probably still today) GCC did an awful job of
allocating registers in a large function. This was visible in a
bytecode interpreter, where the programmer kno
On 10/20/2015 10:05 AM, Andrew Haley wrote:
On 10/20/2015 05:00 PM, Jeff Law wrote:
But the technical reality is I can't see a use outside the extended asm.
I can. In the past (and probably still today) GCC did an awful job of
allocating registers in a large function. This was visible in a
b
On 10/20/2015 05:12 PM, Jeff Law wrote:
> On 10/20/2015 10:05 AM, Andrew Haley wrote:
>> On 10/20/2015 05:00 PM, Jeff Law wrote:
>>> But the technical reality is I can't see a use outside the extended asm.
>>
>> I can. In the past (and probably still today) GCC did an awful job of
>> allocating re
On 10/20/2015 10:15 AM, Andrew Haley wrote:
But in that case, what do we guarantee.
We certainly don't guarantee that those objects will be in their
requested register at any point other than at the asm statements.
OK, but this usage did work in the past: that it now doesn't is a
regression.
On 10/20/2015 05:22 PM, Jeff Law wrote:
> On 10/20/2015 10:15 AM, Andrew Haley wrote:
>>> But in that case, what do we guarantee.
>>>
>>> We certainly don't guarantee that those objects will be in their
>>> requested register at any point other than at the asm statements.
>>
>> OK, but this usage d
On 10/20/2015 10:39 AM, Andrew Haley wrote:
On 10/20/2015 05:22 PM, Jeff Law wrote:
On 10/20/2015 10:15 AM, Andrew Haley wrote:
But in that case, what do we guarantee.
We certainly don't guarantee that those objects will be in their
requested register at any point other than at the asm stateme
On Tue, Oct 20, 2015 at 10:22:53AM -0600, Jeff Law wrote:
> bz21182 has a testcase that's still helped by local register variables.
I tried it out, and it now is much worse *with* the reg vars than
without (and -O2 vs. -O3 makes no difference at all). It doesn't look
to have used the pre-determin
On 10/20/2015 11:11 AM, Segher Boessenkool wrote:
On Tue, Oct 20, 2015 at 10:22:53AM -0600, Jeff Law wrote:
bz21182 has a testcase that's still helped by local register variables.
I tried it out, and it now is much worse *with* the reg vars than
without (and -O2 vs. -O3 makes no difference at
On 10/20/2015 12:01 PM, Jeff Law wrote:
* The patch series for transition to standard DWARF for Ada
(https://gcc.gnu.org/ml/gcc-patches/2015-08/msg01857.html). There are 8
patches, each one depending on the previous one, except the 6/8 one
(https://gcc.gnu.org/ml/gcc-patches/2015-07/msg01361.h
On 10/20/2015 01:16 PM, Pierre-Marie de Rodat wrote:
On 10/20/2015 12:01 PM, Jeff Law wrote:
* The patch series for transition to standard DWARF for Ada
(https://gcc.gnu.org/ml/gcc-patches/2015-08/msg01857.html). There are 8
patches, each one depending on the previous one, except the 6/8 one
On Tue, Oct 20, 2015 at 12:01:26PM -0600, Jeff Law wrote:
> On 10/20/2015 11:11 AM, Segher Boessenkool wrote:
> >On Tue, Oct 20, 2015 at 10:22:53AM -0600, Jeff Law wrote:
> >>bz21182 has a testcase that's still helped by local register variables.
> >
> >I tried it out, and it now is much worse *wit
I have a question about the TARGET_PROMOTE_PROTOTYPES macro. This macro
says that types like short or char should be promoted to ints when
passed as arguments, even if there is a prototype for the argument.
Now when I look at the code generated on MIPS or x86 it looks like there
is conversion cod
Snapshot gcc-5-20151020 is now available on
ftp://gcc.gnu.org/pub/gcc/snapshots/5-20151020/
and on various mirrors, see http://gcc.gnu.org/mirrors.html for details.
This snapshot has been generated from the GCC 5 SVN branch
with the following options: svn://gcc.gnu.org/svn/gcc/branches/gcc-5
Another question on SO:
http://stackoverflow.com/questions/33238856/official-status-of-c11-support-in-gcc
If the wording is not changed, these questions will appear more and
more, and some users will hesitate to use new C++ standards and even
switch to other compilers.
Ilya Popov
On 21 October 2015 at 00:22, Ilya Popov wrote:
> Another question on SO:
> http://stackoverflow.com/questions/33238856/official-status-of-c11-support-in-gcc
>
> If the wording is not changed, these questions will appear more and more,
> and some users will hesitate to use new C++ standards and eve
Abot the patches themselves... Hard to review again, sigh...
I know, and I'm sorry.
I just can't see any way to completely re-org the text without the patch
becoming a nightmare. I was hoping the html links would make that
easier, but I guess not. On the plus side, Explicit reg vars is the
- Eventually the compiler may work differently than it does now.
That is helpful. It's a way signaling that things may change and that
depending on the precise syntax and semantics may be unwise.
From time to time, particularly with GCC extensions, it has been
necessary to declare certain u
Line too long. I know quite a bit of doc does that, but that's no
excuse :-)
Reduced to < 79.
+Registers can be a limited resource on some systems and allowing the
They are a limited resource on almost all systems. "Scarce resource"?
"Scarce" it is. I've left the rest alone for the mome
I'm trying to sum up what was discussed here. What I'm hearing is
(quoting Jeff):
> the technical reality is I can't see a use outside the extended asm.
Andrew has discussed some other uses, but as Jeff observed:
> Given the way the optimizers and register allocation work,
> I don't think we
On 10/20/2015 10:14 PM, David Wohlferd wrote:
Abot the patches themselves... Hard to review again, sigh...
I know, and I'm sorry.
I just can't see any way to completely re-org the text without the patch
becoming a nightmare. I was hoping the html links would make that
easier, but I guess not
On 10/20/2015 01:40 PM, Segher Boessenkool wrote:
On Tue, Oct 20, 2015 at 12:01:26PM -0600, Jeff Law wrote:
On 10/20/2015 11:11 AM, Segher Boessenkool wrote:
On Tue, Oct 20, 2015 at 10:22:53AM -0600, Jeff Law wrote:
bz21182 has a testcase that's still helped by local register variables.
I tr
On 10/20/2015 10:16 PM, David Wohlferd wrote:
- Eventually the compiler may work differently than it does now.
That is helpful. It's a way signaling that things may change and that
depending on the precise syntax and semantics may be unwise.
From time to time, particularly with GCC extension
On 10/20/2015 10:35 PM, David Wohlferd wrote:
> Given the way the optimizers and register allocation work,
> I don't think we can make guarantees around [Andrew's] use
> of the feature. It happens to still work and may work
> forever, but I'm not going to set it in stone.
If the only usage
33 matches
Mail list logo
