[wwwdocs] IA-32/x86-64 Changes for upcoming 4.8.0 series (Broadwell)

Hi, Attached patch for changes.html reflecting new CPU codename Broadwell builtins. Could you please have a look? Thanks, K bdw-html.patch Description: Binary data

Re: [PATCH, libstdc++] Make empty std::string storage readonly

On 29 August 2012 13:25, Michael Haubenwallner wrote: > > On 08/28/2012 08:12 PM, Jonathan Wakely wrote: >> On 28 August 2012 18:27, Michael Haubenwallner wrote: Does it actually produce a segfault? I suppose it might on some platforms, but not all, so I'm not sure it's worth changin

[Patch ARM] Fix PR54252

Hi, This is a fix for a pretty serious regression in GCC 4.7 onwards where GCC is likely to put out wrong alignment specifiers in case of the neon intrinsics. These specifiers appear to be much larger than the alignment specifiers allowed by the architecture for the memory sizes allowed by the

[PATCH, libstdc++] Fix PR54172

Hello The attached patch fixes a race condition in __cxa_guard_acquire, a regression from 4.6. When the code was refactored to use the new atomic intrinsics, the fact that __atomic_compare_exchange_n updates the "expected" variable with the current value was missed. That causes the loop to pos

[PATCH, libstdc++] Use acquire semantics in case of CAS failure

Hello I detected this issue as I was updating the patches to send to the mailing list. I have not created a bug report. When the CAS operation fails and expected == guard_bit, __cxa_guard_acquire will return immediately indicating that the initialisation has already succeeded. However, it's mi

[PATCH, libstdc++] Improve slightly __cxa_guard_acquire

Hello The attached patch is a simple improvement to make a thread that failed to set the waiting bit to exit the function earlier, if it detects that another thread has successfully finished initialising. It matches the CAS code from a few lines above. The change from RELAXED to ACQUIRE is not

Re: [wwwdocs] IA-32/x86-64 Changes for upcoming 4.8.0 series (Broadwell)

On Thu, Aug 30, 2012 at 2:13 AM, Kirill Yukhin wrote: > Hi, > Attached patch for changes.html reflecting new CPU codename Broadwell > builtins. > > Could you please have a look? > > Thanks, K Please drop for the new Intel processor codename Broadwell. Just Support for the new RDSEED, ADCX, ADO

Re: VxWorks Patches Back from the Dead!

On 8/25/2012 11:35 PM, rbmj wrote: On 8/24/2012 4:59 PM, Bruce Korb wrote: Hi Robert, If you are going to defer, then: On Fri, Aug 24, 2012 at 1:20 PM, rbmj wrote: diff --git a/fixincludes/fixinc.in b/fixincludes/fixinc.in index e73aed9..de7be35 100755 --- a/fixincludes/fixinc.in +++ b/fixin

Re: VxWorks Patches Back from the Dead!

On 8/23/2012 7:54 AM, Paolo Bonzini wrote: Il 23/08/2012 13:46, rbmj ha scritto: On 8/23/2012 4:24 AM, Paolo Bonzini wrote: Subject: [PATCH 10/10] Make open() call more compatible in gcc/gcov-io.c In gcc/gcov-io.c, the call to open() only has two arguments. This is fine, as long as the system

Re: [wwwdocs] IA-32/x86-64 Changes for upcoming 4.8.0 series (Broadwell)

On Thu, 30 Aug 2012, H.J. Lu wrote: > Please drop for the new Intel processor codename Broadwell. Just > > Support for the new RDSEED, ADCX, ADOX and PREFETCHW intrinsics Put ... around each of the four and refer to "command-line options". This is fine with those changes. Thanks, Gerald

Re: VxWorks Patches Back from the Dead!

Hi Robert, On Thu, Aug 30, 2012 at 6:30 AM, rbmj wrote: >> Done, and patch is attached. >> > > OK. make install doesn't seem to like it as much as I do. It complains > because it tries to install macro_list and can't find it. Proposed > solutions: > > 2. Change line to read test -f ${MACRO_LIS

Re: [PATCH] Set correct source location for deallocator calls

On 08/17/2012 03:02 PM, Dehao Chen wrote: > I spend a whole day working on this, but find it very difficult to add > such a java test because: > > * First, libjava testsuits are all runtime tests, i.e., it compiles > the byte code to native code, execute it, and compares the output to > expected o

Re: [PATCH] Set correct source location for deallocator calls

On Thu, Aug 30, 2012 at 3:28 PM, Richard Henderson wrote: > On 08/17/2012 03:02 PM, Dehao Chen wrote: >> I spend a whole day working on this, but find it very difficult to add >> such a java test because: >> >> * First, libjava testsuits are all runtime tests, i.e., it compiles >> the byte code to

Re: [PATCH] OpenBSD/amd64 support and OpenBSD/i386 cleanup

On 08/26/2012 08:07 AM, Gerald Pfeifer wrote: > If anyone wants to approve this, I volunteer to commit the patch. > > Gerald > > > libgcc/: > > 2011-12-27 Mark Kettenis > > * config.host (x86_64-*-openbsd*): New target. > > gcc/: > > 2011-12-27 Mark Kettenis > > * config.g

[PATCH 3/3] Compute predicates for phi node results in ipa-inline-analysis.c

Hi, this is a new version of the patch which makes ipa analysis produce predicates for PHI node results, at least at the bottom of the simplest diamond and semi-diamond CFG subgraphs. This time I also analyze the conditions again rather than extracting information from CFG edges, which means I ca

Re: [PATCH] Set correct source location for deallocator calls

On 08/30/2012 03:28 PM, Richard Henderson wrote: > On 08/17/2012 03:02 PM, Dehao Chen wrote: >> I spend a whole day working on this, but find it very difficult to add >> such a java test because: >> >> * First, libjava testsuits are all runtime tests, i.e., it compiles >> the byte code to native co

Re: [PATCH] Add counter histogram to fdo summary (issue6465057)

> On Wed, Aug 29, 2012 at 6:12 AM, Jan Hubicka wrote: > >> Index: libgcc/libgcov.c > >> === > >> --- libgcc/libgcov.c (revision 190736) > >> +++ libgcc/libgcov.c (working copy) > >> @@ -276,6 +276,78 @@ gcov_version (struct gcov_inf

Re: out-of-line and arch-specific random_device

> From: Ulrich Drepper > Date: Tue, 28 Aug 2012 05:57:08 +0200 This patch (commit r190787) broke build for non-_GLIBCXX_USE_RANDOM_TR1 targets. (See libstdc++-v3/configure.ac and its crossconfig.m4 for a list.) > Index: libstdc++-v3/include/bits/random.h > ==

Re: [middle-end] Add machine_mode to address_cost target hook

On 08/29/2012 05:46 PM, Oleg Endo wrote: Hello, While experimenting a little bit with an idea for an address mode selection RTL pass for SH, I realized that SH's sh_address_cost function is quite broken. When trying to fix it, I ran against a wall, since the mode of the MEM is not passed to the

Re: [PATCH] Set correct source location for deallocator calls

On 08/30/2012 08:20 AM, Andrew Haley wrote: > Is the problem simply that the logic to > scan the assembly code isn't present in the libgcj testsuite? Yes, exactly. r~

Re: out-of-line and arch-specific random_device

On Thu, Aug 30, 2012 at 11:52 AM, Hans-Peter Nilsson wrote: >> From: Ulrich Drepper >> Date: Tue, 28 Aug 2012 05:57:08 +0200 > > This patch (commit r190787) broke build for non-_GLIBCXX_USE_RANDOM_TR1 > targets. (See libstdc++-v3/configure.ac and its crossconfig.m4 for a > list.) Should be fixe

Re: faster random number engine

On Wed, 29 Aug 2012 14:34:40 -0400 Ulrich Drepper wrote: > On Wed, Aug 29, 2012 at 11:43 AM, Paolo Carlini > wro > > The substance isn't of course. But normally we don't have __gnu_cxx > > things in the same std header. Can't we have a new ext/random and > > put it in there? If we can separate t

Re: Memset/memcpy patch

On Mon, Dec 12, 2011 at 6:02 AM, Jan Hubicka wrote: >> Any update? > > I will look into it today, but anyway I think it is stage1 material, so we > have some time to progress on it. > > Honza Hi Honza, The old patch was reverted and the new patch was posted at http://gcc.gnu.org/ml/gcc-patches

Re: [v3] libstdc++/54005

> Pretty minor change, as per PR. This version seems more appropriate > for templatized types. .. this wasn't right, commentary as per bugzilla. tested x86/linux -benjamin 2012-08-07 Benjamin Kosnik PR libstdc++/54005 continued * include/std/atomic: Use __atomic_lock_free with * includ

Ping^4 Re: Add --no-sysroot-suffix driver option

Ping^4. This patch is still pending review. -- Joseph S. Myers jos...@codesourcery.com

Re: [PATCH] MIPS16 TLS support for GCC

Chung-Lin Tang writes: > On 2012/8/30 02:44 AM, Richard Sandiford wrote: >> Chung-Lin Tang writes: >>> On 2012/7/6 02:23 PM, Richard Sandiford wrote: Richard Sandiford writes: >> (3) Also related to libraries, I edited CRT_CALL_STATIC_FUNCTION to emit >> a 32-bit code sequence under

Re: [PATCH, i386]: Implement atomic_fetch_sub

On 08/23/2012 08:59 AM, Andrew MacLeod wrote: > 2012-08-23 Andrew MacLeod > > gcc > PR target/54087 > * optabs.c (expand_atomic_fetch_op_no_fallback): New. Factored code > from expand_atomic_fetch_op. > (expand_atomic_fetch_op): iTry atomic_{add|sub} operations in term

[PATCH, PR 54409] Remapping inlining predicates fix

Hi, this patch fixes PR 54409. The condition for dealing with offset maps when remapping predicates which I have added recently was wrong, fortunately a subsequent assert caught this. We cannot shift stuff by an offset when it is passed by value. Conversely, the condition was unnecessarily rest

C++ PATCHes for c++/50545, 51222

I've been surprised at the number of issues that have come up while I've been working on implementing the notion of instantiation-dependent expressions, which aren't currently described in the standard other than as "expression involving a template parameter". I checked in fixes for several of