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
> 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
> g
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 sound
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 appr
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
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-pat
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
> 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 (i
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 cove
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;
*
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
> (MIP
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 func
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 se
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
14 matches
Mail list logo
