Re: vector comparisons in C++

2012-09-13 Thread Marc Glisse
On Thu, 13 Sep 2012, Jason Merrill wrote: Furthermore, this builtin support would be useful for implementing a C++ class for vector arithmetic, just as it is with std::complex. I'm not aware of any other portable way to implement such a class. I forgot to say: it is always possible to do the

PR libstdc++/54576: random_device isn't protected by _GLIBCXX_USE_C99_STDINT_TR1

2012-09-13 Thread H.J. Lu
Hi, include/random has #ifdef _GLIBCXX_USE_C99_STDINT_TR1 #include // For uint_fast32_t, uint_fast64_t, uint_least32_t #include #include #endif // _GLIBCXX_USE_C99_STDINT_TR1 random_device is defined in . But src/c++11/random.cc has #include ... void random_device::_M_init(const std::

PATCH: PR debug/54568: --eh-frame-hdr should also be enabled for static executable

2012-09-13 Thread H.J. Lu
Hi, There is no reason why --eh-frame-hdr can't be used with static executable on Linux. This patch enables --eh-frame-hdr for static executable on Linux and adds an exception test for static executable. Other platforms may also work correctly. But I can't verify it. Tested on Linux/x86-64. OK

Re: [PATCH] Combine location with block using block_locations

2012-09-13 Thread Dehao Chen
On Fri, Sep 14, 2012 at 12:49 AM, Tom Tromey wrote: >> "Dehao" == Dehao Chen writes: > > Dehao> + static htab_t location_adhoc_data_htab; > Dehao> + static source_location curr_adhoc_loc; > Dehao> + static struct location_adhoc_data *location_adhoc_data; > Dehao> + static unsigned int allocat

Re: [PATCH] Changes in mode switching

2012-09-13 Thread Vladimir Yakovlev
Hello, I reproduced the failure and found reason of it. I understood haw it resolve and now I need small changes only - additional argument of EMIT_MODE_SET. Is it good fo trunk? Thank you, Vladimir 2012-09-14 Vladimir Yakovlev * (optimize_mode_switching): Added an argument EMIT_MODE

Re: [PATCH] Combine location with block using block_locations

2012-09-13 Thread Richard Guenther
On Thu, Sep 13, 2012 at 7:37 PM, Mike Stump wrote: > On Sep 13, 2012, at 6:52 AM, Robert Dewar wrote: >> Sure, it is obvious that you don't want -g to affect -O1 or -O2 code, >> but I think if you have -Og (if and when we have that), it would not >> be a bad thing for -g to affect that. > > No, i

<    1   2