[C++14] Admit C++ keywords as literal suffixes.

[Ed Smith-Rowland]

I understand that the literal operators for complex numbers for C++14 
faltered at least in part because of the perceived ugliness of the float 
operator:


constexpr complex
operator"" i_f();  //  fugly

The obvious choice
constexpr complex
operator"" if();

failed because 'if' is a keyword.  The 'if' keyword can never be exposed 
in this context either by usage in a literal or by explicit call.


Allowing keywords as literal operator suffixes turns out to be a 6-liner 
if gcc.  I actually think *disallowing* them is a bit of a bug.  (Not 
sure if it was me or the standard).


I don't know if that's the wording but I just wanted to offer a working 
implementation of the idea.


Ed

Index: gcc/cp/parser.c
===
--- gcc/cp/parser.c (revision 200158)
+++ gcc/cp/parser.c (working copy)
@@ -12359,6 +12358,13 @@
  return cp_literal_operator_id (name);
}
}
+  else if (token->type == CPP_KEYWORD)
+   {
+ id = ridpointers [(int) token->keyword];
+ cp_lexer_consume_token (parser->lexer);
+ const char *name = IDENTIFIER_POINTER (id);
+ return cp_literal_operator_id (name);
+   }
   else
{
  error ("expected suffix identifier");

Re: Loop induction variable optimization question

[Chung-Ju Wu]

2013/6/18 Steve Ellcey :
> On Mon, 2013-06-17 at 21:36 +0200, Oleg Endo wrote:
>
>>
>> Sorry for not having an answer.  I got curious, because just yesterday I
>> was looking at this one
>> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55190
>> and thought that this is related, although it doesn't seem to.
>> I've tried the two functions of yours on SH and there it produces the
>> same machine code with -O2.  -O3 results in a call to memcpy, while
>> -O3 -fno-tree-loop-distribute-patterns again results in the same code.
>>
>> Cheers,
>> Oleg
>
> Thanks for the pointer.  It made me realize I should try running my test
> with -fno-ivopts.  That got rid of the '-4' usage and I wound up getting
> the code that I was after.  I still hope someone can help me understand
> why ivopts made the transformation it did though.  I am afraid that just
> turning off ivopts may have a larger affect then I am after.
>
> Steve Ellcey
> sell...@mips.com
>
>
>
>

This may have something to do with sequence point concept.
(C99 5.1.2.3, C99 Annex C)

To my understanding, the following two statements are not equivalent
if you take sequence point into consideration:
  (1) *d++ = *s++;
  (2) *d = *s; d++; s++;

The case (2) has a sequence point after ';', which mean '++'
is taken place after the expression *d=*s has been evaluated.
But for the case (1), compiler is free to reorder evaluations,
which may move the post-increments above the assignment
and then ivopt convert it using -4 offset for memory reference.

There remains space to discuss whether it is worth for ivopt
to do such transformation.  Apparently it is not good for your case,
but it may be helpful to reduce register pressure for
the target with few registers.


Best regards,
jasonwucj

Re: Loop induction variable optimization question

[Steve Ellcey]

On Mon, 2013-06-17 at 21:36 +0200, Oleg Endo wrote:

> 
> Sorry for not having an answer.  I got curious, because just yesterday I
> was looking at this one
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55190
> and thought that this is related, although it doesn't seem to.
> I've tried the two functions of yours on SH and there it produces the
> same machine code with -O2.  -O3 results in a call to memcpy, while
> -O3 -fno-tree-loop-distribute-patterns again results in the same code.
> 
> Cheers,
> Oleg

Thanks for the pointer.  It made me realize I should try running my test
with -fno-ivopts.  That got rid of the '-4' usage and I wound up getting
the code that I was after.  I still hope someone can help me understand
why ivopts made the transformation it did though.  I am afraid that just
turning off ivopts may have a larger affect then I am after.

Steve Ellcey
sell...@mips.com

Re: Loop induction variable optimization question

[Oleg Endo]

On Mon, 2013-06-17 at 10:07 -0700, Steve Ellcey wrote:
> I have a loop induction variable question involving post increment.
> If I have this loop:
> 
> [...]

> My question is is: why (and where) did ivopts decide to move the
> post-increments above the usages in the first loop?  In my case
> (MIPS) the second loop generates better code for me then the first
> loop and I would like to avoid the '-4' offsets that are used.
> Ideally, one would think that GCC should generate the same code
> for both of these loops but it does not.
> 

Sorry for not having an answer.  I got curious, because just yesterday I
was looking at this one
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55190
and thought that this is related, although it doesn't seem to.
I've tried the two functions of yours on SH and there it produces the
same machine code with -O2.  -O3 results in a call to memcpy, while
-O3 -fno-tree-loop-distribute-patterns again results in the same code.

Cheers,
Oleg

Loop induction variable optimization question

[Steve Ellcey]

I have a loop induction variable question involving post increment.
If I have this loop:

void *memcpy_word_ptr(int * __restrict d, int * __restrict s, unsigned int n )
{
  int i;
  for(i=0; i:
  # d_22 = PHI 
  # s_23 = PHI 
  # i_24 = PHI 
  d_10 = d_22 + 4;
  s_11 = s_23 + 4;
  _12 = *s_23;
  *d_22 = _12;
  i_14 = i_24 + 1;
  i.2_8 = (unsigned int) i_14;
  if (i.2_8 < n_9(D))
goto ;  # bb 6 just loops back to bb 4
  else
goto ;

into this loop (using -4 offsets to compensate for incrementing the 's' and 'd'
variables before their use:

  :
  # d_22 = PHI 
  # s_23 = PHI 
  # i_24 = PHI 
  d_10 = d_22 + 4;
  s_11 = s_23 + 4;
  _12 = MEM[base: s_11, offset: 4294967292B];
  MEM[base: d_10, offset: 4294967292B] = _12;
  i_14 = i_24 + 1;
  if (i_14 != _2)
goto ;  # bb 6 just loops back to bb 4
  else
goto ;


But if I increment s and d by hand after the copy like this:

void *memcpy_word_ptr(int * __restrict d, int * __restrict s, unsigned int n )
{
  int i;
  for(i=0; i:
  # d_22 = PHI 
  # s_23 = PHI 
  # i_24 = PHI 
  _10 = *s_23;
  *d_22 = _10;
  d_12 = d_22 + 4;
  s_13 = s_23 + 4;
  i_14 = i_24 + 1;
  i.0_8 = (unsigned int) i_14;
  if (i.0_8 < n_9(D))
goto ;  # bb 6 just loops back to bb 4
  else
goto ;

into this loop (with 0 offsets):

  :
  # d_22 = PHI 
  # s_23 = PHI 
  # i_24 = PHI 
  _10 = MEM[base: s_23, offset: 0B];
  MEM[base: d_22, offset: 0B] = _10;
  d_12 = d_22 + 4;
  s_13 = s_23 + 4;
  i_14 = i_24 + 1;
  if (i_14 != _2)
goto ;  # bb 6 just loops back to bb 4
  else
goto ;


My question is is: why (and where) did ivopts decide to move the
post-increments above the usages in the first loop?  In my case
(MIPS) the second loop generates better code for me then the first
loop and I would like to avoid the '-4' offsets that are used.
Ideally, one would think that GCC should generate the same code
for both of these loops but it does not.

Steve Ellcey
sell...@mips.com

Re: Generate coverage informations in different sections.

[Frediano Ziglio]

On Mon, 2013-06-17 at 17:32 +0200, Jan Hubicka wrote:
> > Hi,
> >   I'm a Xen developer. We have coverage support (lcov replacement) in
> > order to extract coverage information. However would be very helpful to
> > have a way to put counters, structures and strings (file names) related
> > to coverage in different section. Actually there are no such options (it
> > would be better for us to separate counters and structures/strings).
> 
> You mean to have something like .text.gcov/.data.gcov etc to place the 
> counters?
> I suppose it is not that hard to implement, but I wonder how it is going to 
> help
> you?
> 
> Honza

If you put all gcov info in a section of memory (say an array of bytes)
you can then dump them and pass the base pointer for fixup and split the
tool that parse this blob.

In this case the problem is that Xen have no file system support so
currently there is some code in Xen itself that build a blob based on
all gcov information to get exported. If data are contiguous in memory
and in a specific area you can just dump this memory section as raw data
without having to worry about gcc chnages in the future (supposing the
sections are still the same).

Actually you could even share the memory between Xen and userspace in
order to achieve it.

Frediano

> > 
> > I tried to change generated .s files in order to separate these
> > informations but without success (I'm not so expert with gas, last gcc
> > require common section).
> > 
> > Is it difficult to implement such a feature in next gcc?
> > 
> > Do somebody have a better idea?
> > 
> > Frediano
> > 

Re: Generate coverage informations in different sections.

[Jan Hubicka]

> Hi,
>   I'm a Xen developer. We have coverage support (lcov replacement) in
> order to extract coverage information. However would be very helpful to
> have a way to put counters, structures and strings (file names) related
> to coverage in different section. Actually there are no such options (it
> would be better for us to separate counters and structures/strings).

You mean to have something like .text.gcov/.data.gcov etc to place the counters?
I suppose it is not that hard to implement, but I wonder how it is going to help
you?

Honza
> 
> I tried to change generated .s files in order to separate these
> informations but without success (I'm not so expert with gas, last gcc
> require common section).
> 
> Is it difficult to implement such a feature in next gcc?
> 
> Do somebody have a better idea?
> 
> Frediano
> 

Re: unusable libatomic.so built in certain environments

[Joseph S. Myers]

On Mon, 17 Jun 2013, Jan Beulich wrote:

> expect runtime properties to be taken into account here. And
> for cross builds I'd expect a way to control whether the final
> binary would be using GNU IFUNC symbols rather than just
> making this dependent upon tool chain capabilities.

For cross builds to glibc target I'd quite like a --with-glibc-version or 
similar configure option that specifies the (minimum) version of glibc 
assumed to be present on the target (strictly, for glibc multilibs, in the 
case of a toolchain mixing glibc and non-glibc multilibs, though not all 
relevant features effectively support per-multilib configuration).

At present, there is some code in gcc/configure.ac that checks the 
target's features.h if this is available at configure time, some checking 
bits/wordsize.h for a different purpose, and some that checks for native 
configuration and runs ldd --version (for STB_GNU_UNIQUE support), which 
isn't cross-friendly at all.

This should be refactored to a single place where a target glibc version 
(major and minor version numbers) is determined, which could then use a 
new configure option specifying the target version to assume if headers 
should not be used to detect it.  Such a configure macro could I suppose 
be made usable in target library configuration, though the cases I've been 
interested in are cases of configuring the compiler itself.

Making a configure option override version detection from target headers 
(version detection from ldd --version should simply be avoided completely 
and replaced by use of headers / configure option) is useful, in 
particular, when building an initial bootstrap compiler before target 
glibc headers are available.  Specifically, if you want such a compiler to 
build a glibc the same as would be the eventual result of an iterative 
process of alternating GCC and glibc builds, without needing to override 
any autoconf tests in either GCC or glibc with *_cv_* settings, such an 
option is needed as I described in 
 to avoid 
needing to pass gcc_cv_libc_provides_ssp=yes on some architectures when 
configuring the initial bootstrap GCC.

-- 
Joseph S. Myers
jos...@codesourcery.com

unusable libatomic.so built in certain environments

[Jan Beulich]

In an environment with relatively old core components (dynamic
loader and glibc) but with up-to-date binutils (perhaps built along
with gcc) libatomic.so gets built in a way such that it is unusable
on the build system. A similar issue was reported in a mail leading
to http://gcc.gnu.org/ml/gcc-patches/2013-02/msg00315.html,
but I don't view switching back to old binutils as an acceptable
option.

Looking at the libatomic configury, I also do not see a way to
suppress the use of GNU IFUNC symbols. Am I overlooking
something, or is this an outright bug in a configuration no-one
really ever thought about? At least in a non-cross build I'd
expect runtime properties to be taken into account here. And
for cross builds I'd expect a way to control whether the final
binary would be using GNU IFUNC symbols rather than just
making this dependent upon tool chain capabilities.

Thanks, Jan

Generate coverage informations in different sections.

[Frediano Ziglio]

Hi,
  I'm a Xen developer. We have coverage support (lcov replacement) in
order to extract coverage information. However would be very helpful to
have a way to put counters, structures and strings (file names) related
to coverage in different section. Actually there are no such options (it
would be better for us to separate counters and structures/strings).

I tried to change generated .s files in order to separate these
informations but without success (I'm not so expert with gas, last gcc
require common section).

Is it difficult to implement such a feature in next gcc?

Do somebody have a better idea?

Frediano

Re: [PR43721] Failure to optimise (a/b) and (a%b) into single call

[Richard Biener]

On Mon, 17 Jun 2013, Kugan wrote:

> Hi,
> 
> I am attempting to fix Bug 43721 - Failure to optimise (a/b) and (a%b) into
> single __aeabi_idivmod call
> (http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43721)
> 
> execute_cse_sincos tree level pass does similar cse so I attempted to use
> similar approach here. Div/mod cse is not really using built-in functions
> though at this level.

The issue with performing the transform at the same time as we
transform SINCOS is that the vectorizer will now no longer be able
to vectorize these loops.  It would need to be taught how to
handle the builtin calls (basically undo the transformation, I don't
know of any ISA that can do vectorized combined div/mod).  Which
means it should rather be done at the point we CSE reciprocals
(which also replaces computes with builtin target function calls).

> For the case of div and mod operations, after CSE is performed, there isnt a
> way to represent the resulting stament in gimple. We will endup with divmod
> taking two arguments and returning double the size of one arguments in the
> three address format (divmod will return reminder and quotient so the return
> type is double the size of argument type).
> 
> Since GIMPLE_ASSIGN will result in type checking failure in this case, I
> atempted use built-in functions (GIMPLE_CALL to represent the runtime library
> call). Name for the function here  is target specific and can be obtained from
> sdivmod_optab so the builtin function name defined in tree level is not used.
> I am not entirelt sure this is the right approach so I am attaching the first
> cut of the patch to get your feedback and understand the right approach to
> this problem.

If we don't want to expose new builtins to the user (I'm not sure we
want that), then using "internal functions" is an easier way to
avoid these issues (see gimple.h and internal-fn.(def|h)).

Generally the transform looks useful to me as it moves forward with
the general idea of moving pattern recognition done during RTL expansion
to an earlier place.

For the use of a larger integer type and shifts to represent
the modulo and division result I don't think that's the very best
idea.  Instead resorting to a complex integer type as return
value looks more appealing (similar to sincos using cexpi here).
That way you also avoid the ugly hard-coding of bit-sizes.

+  if (HAVE_divsi3
+   || (GET_MODE_BITSIZE (TYPE_MODE (type)) != 32)

watch out for types whose TYPE_PRECISION is not the bitsize
of their mode.  Also it should be GET_MODE_PRECISION here.

+   || !optab_libfunc (TYPE_UNSIGNED (type)? udivmod_optab : 
sdivmod_optab,
+TYPE_MODE (type)))

targets that use a libfunc should also get this optimization, as
it always removes computations.  I think the proper test is
for whether the target can do division and/or modulus without
using a libfunc, not whether there is a divmod optab/libfunc.

Others knowing this piece of the compiler better may want to comment
here, of course.

Thanks,
Richard.

Re: Libitm issues porting to POWER8 HTM

[Patrick Marlier]

Hi Peter,

On Sat, Jun 15, 2013 at 2:44 AM, Peter Bergner  wrote:
> I'm currently implementing support for hardware transactional memory in
> the rs6000 backend for POWER8.  Things seem to be mostly working, but I
> have run into a few issues I'm wondering whether other people are seeing.

It sounds great! Is it already publicly available?

> Finially, when compiling (static or non-static) static-ctor.C, I'm seeing:
>
> /home/bergner/gcc/gcc-fsf-mainline-htm/libitm/testsuite/libitm.c++/static_ctor.C:12:18:
>  error: unsafe function call 'void __cxa_guard_release(long long int*)' 
> within 'transaction_safe' function
>static int y = x;
>   ^
> /home/bergner/gcc/gcc-fsf-mainline-htm/libitm/testsuite/libitm.c++/static_ctor.C:12:18:
>  error: unsafe function call 'int __cxa_guard_acquire(long long int*)' within 
> 'transaction_safe' function
>
> Does x86 not get calls to __cxa_guard_acquire and __cxa_guard_release for
> this access, so it doesn't see this error?  To be honest, I'm not sure
> what we're supposed to do with this error.

Sorry I don't have answers to your previous questions (I may have in
the future when I will get a CPU with HTM).

About the last one, this fails for a long long time now (even on x86):
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51173
Indeed, static constructors are not transaction safe yet and we should
have a workaround for this...
--
Patrick

Re: designated initializers extension and sparc

[Eric Botcazou]

> I wrote the following test:
> 
> union foo { int i; double d; };
> 
> int main(int argc, char **argv)
> {
>  union foo f = { .d = 4 };
> 
>  ASSERT_EQ(0, f.i);
>  ASSERT_FEQ(4.0, f.d);
> 
>  return 0;
> }
> 
> ASSERT_EQ and ASSERT_FEQ are some macros which checks the falue and
> gives some error messages.
> 
> It seems that this extension should be bi-endian, however it fails on
> the sparc.
> What the problem with the test?

Type punning through union is actually the preferred way to expose endianness.
Ask yourself how the 'int' and the 'double' are laid out on the SPARC.

-- 
Eric Botcazou

Re: designated initializers extension and sparc

[Gabriel Paubert]

On Mon, Jun 17, 2013 at 01:28:56AM +0300, Sergey Kljopov wrote:
> Hi,
> 
> Reading the text
> -
> In a structure initializer, specify the name of a field to
> initialize with `.fieldname =' before the element value. For
> example, given the following structure,
>  struct point { int x, y; };
> the following initialization
>  struct point p = { .y = yvalue, .x = xvalue };
> is equivalent to
>  struct point p = { xvalue, yvalue };
> Another syntax which has the same meaning, obsolete since GCC 2.5,
> is `fieldname:', as shown here:
>  struct point p = { y: yvalue, x: xvalue };
> The `[index]' or `.fieldname' is known as a designator. You can also
> use a designator (or the obsolete colon syntax) when initializing a
> union, to specify which element of the union should be used. For
> example,
>  union foo { int i; double d; };
>  union foo f = { .d = 4 };
> will convert 4 to a double to store it in the union using the second
> element. By contrast, casting 4 to type union foo would store it
> into the union as the integer i, since it is an integer. (See Cast
> to Union.)
> -
> I wrote the following test:
> 
> union foo { int i; double d; };
> 
> int main(int argc, char **argv)
> {
> union foo f = { .d = 4 };
> 
> ASSERT_EQ(0, f.i);
> ASSERT_FEQ(4.0, f.d);
> 
> return 0;
> }
> 
> ASSERT_EQ and ASSERT_FEQ are some macros which checks the falue and
> gives some error messages.
> 
> It seems that this extension should be bi-endian, 

It is not. But this is off-topic on this mailing list, which is about
the development of the compiler, not using it. 

Please try gcc-help instead.

Gabriel