[v3] __once_proxy(void) workaround for implicit extern "C" systems

This is necessary for systems that treat all system headers as implicitly extern "C" (at least AIX and OpenBSD) because otherwise the empty parameter list is treated as declaring void __once_proxy(...) This has come up recently because we are now enabling etc. on additional platforms. PR

vector garbaged collected while still in use

I have seen compiler build error (segmentation fault) in libstdc++-v3. It turns out that a vector allocated in gc memory is GCed before the vector is released. The gc call is from a call to synethesize_method from cp_finish_decl. The following patch fixes the problem. Compiler bootstraps and teste

Re: [Patch, Fortran, OOP] PR 50919: Don't use vtable for NON_OVERRIDABLE TBP

Dear Janus, On Mon, Nov 7, 2011 at 12:14 AM, Janus Weil wrote: > The patch actually consists of two parts: > 1) The resolve.c part prevents the conversion to a PPC call via the > _vptr (for functions and subroutines). This is obviously OK > 2) The class.c parts prevents adding the non-overrida

Re: [PATCH] Add an intermediate coverage format for gcov

Sorry about the delay. I have updated the patch to output demangled names under a new option (-m) and added a test case. Okay for trunk? Sharad 2011-11-06 Sharad Singhai * doc/gcov.texi: Document gcov intermediate format. * gcov.c (print_usage): Handle new option. (pr

Re: [patch] 19/n: trans-mem: middle end/misc patches (LAST PATCH)

False. You get the equivalent of bootstrap comparison mismatches. If we actually used tm during the bootstrap. The simplest thing to do is to change the hash this table uses. E.g. use the DECL_UID right from the start, rather than the pointer. Woah! Can it be that easy? That's as easy as c

Re: Many testsuite failures on x86_64 due recent "fix" about f16cintrin.h header

On Sun, Nov 6, 2011 at 2:13 PM, Dominique Dhumieres wrote: > Following http://gcc.gnu.org/ml/gcc-patches/2011-10/msg02901.html, I have > applied > the following patch on x86_64-apple-darwin10 > > --- ../_clean/gcc/config.gcc    2011-11-05 22:25:37.0 +0100 > +++ gcc/config.gcc      2011-11

Re: increase call_saved_regs[] in caller-save.c

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 11/04/11 14:23, Peter Bergner wrote: > On Fri, 2011-11-04 at 12:25 -0600, Jeff Law wrote: >> The only way I can think of to have two pseudos assigned the same >> hard reg at the same point in the insn stream is if the two >> pseudos are known to hav

[C++ PATCH] PR 50958 and correct lookup of literal operators

The lookup rules require that all the operators for a given name be searched for one that has the exact same arguments implied by the literal. Also, an error concerning the length of raw operator strings was fixed. Index: gcc/testsuite/g++.dg/cpp0x/udlit-raw-length.C ===

Re: increase call_saved_regs[] in caller-save.c

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 11/04/11 17:37, DJ Delorie wrote: >> The only way I can think of to have two pseudos assigned the >> same hard reg at the same point in the insn stream is if the two >> pseudos are known to have the same value. > > Since all we're doing is figuring

C++/c-common PATCH for c++/35688 (wrong visibility of template instantiation)

The function constrain_visibility_for_template tries to set the visibility of a template instantiation properly by giving it the minimum visibility of the template itself and the template arguments. But this PR points out that we were failing to do that in the case that the template is within

Re: cxx-mem-model merge [6 of 9] - libstdc++-v3

On 11/06/2011 07:38 PM, Hans-Peter Nilsson wrote: This (formally a change in the range 181027:181034) got me three libstdc++ regressions for cris-elf, which has no "atomic" support whatsoever (well, not the version represented in "cris-elf"), so something is amiss at the bottom of the default pa

Re: [trans-mem] XFAIL known failures

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 11/03/11 17:40, Aldy Hernandez wrote: > On 11/03/11 18:30, Andrew Pinski wrote: >> On Thu, Nov 3, 2011 at 3:12 PM, Aldy Hernandez >> wrote: >>> These are known failures, mostly missed optimizations. >>> XFAILing them. >> >> I think you should file

Re: [Patch] ARM EABI support for RTEMS

On 11/04/2011 03:30 PM, Sebastian Huber wrote: On 11/04/2011 01:57 PM, Sebastian Huber wrote: It builds well and the test suite runs currently. http://gcc.gnu.org/ml/gcc-testresults/2011-11/msg00407.html The second version of your patch is OK with me and seems to work fine. Patch commited

Re: [patch] 19/n: trans-mem: middle end/misc patches (LAST PATCH)

On 11/06/11 12:20, Richard Henderson wrote: - if (!computed_goto_p (stmt)) + if (!computed_goto_p (stmt)) { - tree new_dest = main_block_label (gimple_goto_dest (stmt)); - gimple_goto_set_dest (stmt, new_dest); + label = gimple_got

Re: [PATCH] More improvements to sparc VIS vec_init code generation.

From: Richard Henderson Date: Sun, 06 Nov 2011 09:55:17 -0800 > On 11/05/2011 07:39 PM, David Miller wrote: >> Richard, is there a better way to represent this in RTL? These >> instructions basically load a single byte or half-word into the bottom >> of a 64-bit float register, and clear the res

Re: [v3] corrections to C++11 status table

On 6 November 2011 22:10, Jonathan Wakely wrote: > We don't provide or - the latter is listed as "C > library dependency" but AFAIK we don't provide even if > is present. > >        * doc/xml/manual/status_cxx2011.xml: Document and >         as missing. > > Committed to trunk. Joseph has just

Re: Implement C1X _Alignas, _Alignof, max_align_t, stdalign.h

On 7 November 2011 00:37, Joseph S. Myers wrote: > On Mon, 7 Nov 2011, Jonathan Wakely wrote: > >> On 6 November 2011 23:53, Joseph S. Myers wrote: >> > >> > As with stdnoreturn.h, the contents of stdalign.h are conditioned out >> > for C++; I'll leave it to C++ people to work out what's most usefu

[patch, win32, applied] Update libgcj version number in win32 crtbegin.

Hi list, The win32 crtbegin code needs to know the full name of the libgcj DLL, including in particular the trailing version suffix generated from the libtool version info, and so far it's not autogenerated but needs to be manually synced. This patch updates the two places where we have i

Re: cxx-mem-model merge [6 of 9] - libstdc++-v3

> From: Andrew MacLeod > Date: Fri, 4 Nov 2011 00:50:47 +0100 > These are the changes to libstdc++ to make use of the new atomics. I > changed the files to use the new atomics, and bkoz did a shuffling of > the include file layout to better suit the new c++ approach. > > previously, libstdc++ p

Re: Implement C1X _Alignas, _Alignof, max_align_t, stdalign.h

On Mon, 7 Nov 2011, Jonathan Wakely wrote: > On 6 November 2011 23:53, Joseph S. Myers wrote: > > > > As with stdnoreturn.h, the contents of stdalign.h are conditioned out > > for C++; I'll leave it to C++ people to work out what's most useful > > there if something nonempty is wanted (stdnoreturn

Re: Implement C1X _Alignas, _Alignof, max_align_t, stdalign.h

On 6 November 2011 23:53, Joseph S. Myers wrote: > > As with stdnoreturn.h, the contents of stdalign.h are conditioned out > for C++; I'll leave it to C++ people to work out what's most useful > there if something nonempty is wanted (stdnoreturn.h is empty for C++, > stdbool.h defines _Bool and boo

Fix various minor issues in gcse.c

While working on PR rtl-opt/50904, I ran into long-standing minor issues in gcse.c that can easily be addressed: - a few outdated comments, - poor interface with note_stores, - edge_list being sometimes a global variable and sometimes a parameter, - gcse_emit_move_after takes source and de

Re: PR lto/50964: [trans-mem] fail gracefully when -flto and -fgnu-tm

On Sun, Nov 6, 2011 at 18:56, Andrew Pinski wrote: > Why not just fix the issue instead of erroring out?  No other option > has issues with LTO other than TM.  In fact I think this should have > been a merge blocker really. I disagree. TM is a new experimental feature. It is fine if it is not

Re: [v3] define string::pop_back()

I first posted this a month ago, this adjusts the exports and moves the tests under separate char and wchar_t directories as requested by Paolo. * include/bits/basic_string.h (basic_string::at): Move adjacent to other overload. (basic_string::pop_back): Define. * in

Re: PR lto/50964: [trans-mem] fail gracefully when -flto and -fgnu-tm

On Sun, Nov 6, 2011 at 12:03 PM, Aldy Hernandez wrote: > As per your comment in the PR... > > OK for branch? Why not just fix the issue instead of erroring out? No other option has issues with LTO other than TM. In fact I think this should have been a merge blocker really. Thanks, Andrew Pins

Implement C1X _Alignas, _Alignof, max_align_t, stdalign.h

This patch adds support for most of the C1X alignment features (_Alignas, _Alignof, max_align_t, stdalign.h). _Alignof is essentially GNU __alignof__, but restricted to be applied to types not expressions and not allowed on function types. It goes through the existing code, but with diagnostics f

Re: [patch] 6/n: trans-mem: runtime

On Sun, 2011-11-06 at 23:04 +, Joseph S. Myers wrote: > On Sun, 6 Nov 2011, Torvald Riegel wrote: > > > Is the attached patch what you'd like to see? It doesn't yet use the > > It's plausible, but really a build system maintainer should look at it. > So, can we keep this as-is then and fix

Re: repost: [DF] Use HARD_REG_SETs instead of bitmaps

On Mon, 7 Nov 2011, Jakub Jelinek wrote: On Mon, Nov 07, 2011 at 12:01:29AM +0200, Dimitrios Apostolou wrote: On Sun, 6 Nov 2011, Joern Rennecke wrote: But where HARD_REG_SETS make no material difference in speed, and the compilation unit has no other tight coupling with tm.h, it would really b

[v3] fix autoconf examples for testing C++11 support

The autoconf examples at http://gcc.gnu.org/onlinedocs/libstdc++/manual/backwards.html#id541888 are incorrect, relying on pre-standard semantics for rvalue references, and missing out several C++11 headers. This patch corrects those examples. This also tweaks some markup in the file, and adds som

[Patch, Fortran, OOP] PR 50919: Don't use vtable for NON_OVERRIDABLE TBP

Hi all, up to now we call all type-bound procedures in a dynamic way, i.e. through their entry in the vtable. However, for non-overridable procedures this is not necessary. Since they can not be overridden, a call to those can be resolved at compile time to an ordinary function call, without the n

Re: [patch] 6/n: trans-mem: runtime

On Sun, 6 Nov 2011, Torvald Riegel wrote: > Is the attached patch what you'd like to see? It doesn't yet use the It's plausible, but really a build system maintainer should look at it. -- Joseph S. Myers jos...@codesourcery.com

Re: repost: [DF] Use HARD_REG_SETs instead of bitmaps

On Mon, Nov 07, 2011 at 12:01:29AM +0200, Dimitrios Apostolou wrote: > On Sun, 6 Nov 2011, Joern Rennecke wrote: > >But where HARD_REG_SETS make no material difference in speed, and the > >compilation unit has no other tight coupling with tm.h, it would really > >be cleaner to move from HARD_REG_SE

Re: repost: [DF] Use HARD_REG_SETs instead of bitmaps

Quoting Dimitrios Apostolou : Working with bitmaps in gcc made me really miss the simple bitmap.h of the linux kernel. I'm not sure if we can borrow from there. More info at: http://lxr.linux.no/#linux+v3.1/include/linux/bitmap.h You would need the Copyright holders to assign their Copyright

[patch tree-optimization 2/2]: Branch-cost optimizations

Hello, the second patch extends the tree-ssa-ifcombine pass so, that it chains up simple if-and/or-if patterns via associative bitwise-and/or operations. This allows for example optimization for cases like: if (c == 0) return 2; if (c == 1) return 2; if (c == 2) return 2; ... as now reassocia

[patch tree-optimization 1/2]: Branch-cost optimizations

Hello, By this patch branch-cost optimization is moved from tree AST to cfgexpand from gimple to RTL. By this we are able to do better optimization on conditionals simliar for all targets and do the final transition for branch-cost that late it shows best effect. This patch is splitted up int

[v3] corrections to C++11 status table

We don't provide or - the latter is listed as "C library dependency" but AFAIK we don't provide even if is present. * doc/xml/manual/status_cxx2011.xml: Document and as missing. Committed to trunk. Index: doc/xml/manual/status_cxx2011.xml

Re: repost: [DF] Use HARD_REG_SETs instead of bitmaps

On Sun, 6 Nov 2011, Joern Rennecke wrote: But where HARD_REG_SETS make no material difference in speed, and the compilation unit has no other tight coupling with tm.h, it would really be cleaner to move from HARD_REG_SETS to a target-independent type, like sbitmap or bitmap. Maybe we want someth

Re: repost: [DF] Use HARD_REG_SETs instead of bitmaps

Quoting Jakub Jelinek : The middle-end uses HARD_REG_SET in lots of places, so supposedly when you want to support more than one target, you need to ensure that hard-reg-set.h header won't use FIRST_PSEUDO_REGISTER of one randomly selected target you want to support, but instead somehow computed

Re: [Patch, Fortran] Cleanup of gfc_extend_expr

>> I think the patch is fine and can be committed.  But, give >> Steven a chance to respond before committing. > > Thanks, Steve. I think three days should be long enough. Will commit > later today (if no one protests in the meantime). Committed as r181044. Cheers, Janus

Re: [patch] 19/n: trans-mem: middle end/misc patches (LAST PATCH)

Actually, the table organization is irrelevant, because upon registering of the table in the runtime, we qsort the entire thing. False. You get the equivalent of bootstrap comparison mismatches. If we actually used tm during the bootstrap. The simplest thing to do is to change the hash this

Re: [patch] 19/n: trans-mem: middle end/misc patches (LAST PATCH)

> On 11/04/11 04:14, Richard Guenther wrote: >>> new_version = cgraph_create_node (new_decl); >>> >>> - new_version->analyzed = true; >>> + new_version->analyzed = old_version->analyzed; >> >> Hm? analyzed means "with body", sure you have a body if you clone. Incidentally, for TM we also

Re: PR lto/50964: [trans-mem] fail gracefully when -flto and -fgnu-tm

On 11-11-06 16:05 , Aldy Hernandez wrote: "LTO support is currently not supported with transactional memory" 'support' mentioned one too many times. Maybe 'LTO is currently not supported with transactional memory'? Diego. How is this? OK. Thanks. Diego.

Re: PR lto/50964: [trans-mem] fail gracefully when -flto and -fgnu-tm

"LTO support is currently not supported with transactional memory" 'support' mentioned one too many times. Maybe 'LTO is currently not supported with transactional memory'? Diego. How is this? * opts.c (finish_options): Error out when using -flto and -fgnu-tm. Index: opts.

Re: repost: [DF] Use HARD_REG_SETs instead of bitmaps

On Sun, Nov 06, 2011 at 03:48:16PM -0500, Joern Rennecke wrote: > >Or keep HARD_REG_SET type as is and just use a new struct type which > >contains HARD_REG_SET or HARD_REG_SET * in it. > >struct hard_reg_set_ptr; > >void (*live_on_entry) (struct hard_reg_set_ptr *); > >in the target* headers and >

Re: repost: [DF] Use HARD_REG_SETs instead of bitmaps

Jakub Jelinek: On Sun, Nov 06, 2011 at 01:12:21PM +0100, Paolo Bonzini wrote: > What about adding a macro indirection to more functions (like you > did with SET_HARD_REG_BIT and friends), so that pass-by-value can be > changed to pass-by-reference without affecting all the uses > throughout the c

Re: PR lto/50964: [trans-mem] fail gracefully when -flto and -fgnu-tm

On Sun, Nov 6, 2011 at 15:03, Aldy Hernandez wrote: > As per your comment in the PR... > > OK for branch? "LTO support is currently not supported with transactional memory" 'support' mentioned one too many times. Maybe 'LTO is currently not supported with transactional memory'? Diego.

Re: [C++ Patch] PR 47695

OK. Jason

Re: [patch] 19/n: trans-mem: middle end/misc patches (LAST PATCH)

On 11/06/2011 10:53 AM, Aldy Hernandez wrote: >> Did you check bootstrapping GCC with TM enabled and address-space >> randomization turned on? > > Actually, the table organization is irrelevant, because upon > registering of the table in the runtime, we qsort the entire thing. False. You get the

Re: Many testsuite failures on x86_64 due recent "fix" about f16cintrin.h header

Following http://gcc.gnu.org/ml/gcc-patches/2011-10/msg02901.html, I have applied the following patch on x86_64-apple-darwin10 --- ../_clean/gcc/config.gcc2011-11-05 22:25:37.0 +0100 +++ gcc/config.gcc 2011-11-06 12:35:57.0 +0100 @@ -350,7 +350,7 @@ i[34567]86-*-*)

PR lto/50964: [trans-mem] fail gracefully when -flto and -fgnu-tm

As per your comment in the PR... OK for branch? * opts.c (finish_options): Error out when using -flto and -fgnu-tm. Index: opts.c === --- opts.c (revision 181028) +++ opts.c (working copy) @@ -784,6 +784,8

Re: [PATCH] Don't prevent merging of bbs because of user labels (PR tree-optimization/50693)

On Sun, Nov 06, 2011 at 06:14:18PM +0100, Eric Botcazou wrote: > > As has been suggested by Alexandre in the PR, this patch allows merging > > basic blocks which couldn't be merged before because of user (non-forced) > > labels at the beginning of the second basic blocks. > > With this patch the us

Re: [patch] 6/n: trans-mem: runtime

On Thu, 2011-11-03 at 20:15 +, Joseph S. Myers wrote: > On Thu, 3 Nov 2011, Aldy Hernandez wrote: > > > Index: libitm/acinclude.m4 > > === > > --- libitm/acinclude.m4 (.../trunk) (revision 0) > > +++ libitm/acinclude.m4

[committed] Update PA libfunc initialization

This update is to allow libfunc initialization for other target features. Tested on hppa64-hp-hpux11.11. Committed to trunk. Dave -- J. David Anglin dave.ang...@nrc-cnrc.gc.ca National Research Council of Canada (613) 990-0752 (FAX: 952-6602) 2011-

Re: [PATCH] Fix libgcc_tm.h dependency in libgcc Makefile

On 11/06/2011 06:43 PM, John David Anglin wrote: This is fixes a trunk build error noticed on hppa-linux at -j4. Tested on hppa-unknown-linux-gnu and hppa64-hp-hpux11.11. Ok? Ok. Paolo

Re: [v3] Re: put __stl_prime_list in comdat section

Xinliang David Li writes: > Ping .. (the Nov 7 cutoff date is close ..). The cutoff date is typically not rigorously applied to patches submitted before the deadline but approved after the deadline. However, this patch is OK. Thanks. Ian > > On Sat, Nov 5, 2011 at 12:22 PM, Xinliang David L

Re: [PATCH Atom] Fix for PR target/50962 (bad AGU stall avoidance)

On 11/06/2011 02:12 AM, Ilya Enkovich wrote: > It would be great to have computed type here but ix86_use_lea_for_mov > will check types of other instructions and then call > extract_insn_cached. It will cause infinite loop, right? Hum. That does cause a problem. No objection to the patch approve

Re: [PATCH] More improvements to sparc VIS vec_init code generation.

On 11/05/2011 07:39 PM, David Miller wrote: > Richard, is there a better way to represent this in RTL? These > instructions basically load a single byte or half-word into the bottom > of a 64-bit float register, and clear the rest of that register with > zeros. So the v4hi one is essentially load

Re: [patch] 19/n: trans-mem: middle end/misc patches (LAST PATCH)

[rth, more comments for you below] On 11/04/11 04:14, Richard Guenther wrote: new_version = cgraph_create_node (new_decl); - new_version->analyzed = true; + new_version->analyzed = old_version->analyzed; Hm? analyzed means "with body", sure you have a body if you clone. new_ve

[patch] SLP conditions

Hi, This patch adds a support of conditions in SLP. It also fixes a bug in pattern handling in SLP (we should put pattern statements instead of original statements in the root), and allows pattern def-stmts in SLP. Bootstrapped on powerpc64-suse-linux and tested on powerpc64-suse-linux and x86_64

Re: [PATCH i386] PR47698 no CMOV for volatile mem

On Wed, Nov 2, 2011 at 3:42 PM, Richard Guenther wrote: > On Sat, 29 Oct 2011, Sergey Ostanevich wrote: > >> On Fri, Oct 28, 2011 at 7:25 PM, Sergey Ostanevich >> wrote: >> > On Fri, Oct 28, 2011 at 4:52 PM, Richard Guenther >> > wrote: >> >> On Fri, 28 Oct 2011, Sergey Ostanevich wrote: >> >>

Re: [v3] Re: put __stl_prime_list in comdat section

Ping .. (the Nov 7 cutoff date is close ..). thanks, David On Sat, Nov 5, 2011 at 12:22 PM, Xinliang David Li wrote: > thanks. The attached is the revised patch. > > David > > On Sat, Nov 5, 2011 at 11:52 AM, Paolo Carlini > wrote: >> On 11/05/2011 07:32 PM, Xinliang David Li wrote: >>> >>> H

[C++ Patch] PR 47695

Hi, duplicate diagnostics for (a pretty common error, I would guess): void f() = delete; void g() { f(); } 47695.C: In function ‘void g()’: 47695.C:2:12: error: use of deleted function ‘void f()’ 47695.C:1:6: error: declared here 47695.C:2:14: error: use of deleted function ‘void f()’ 47695.C:1

Re: cxx-mem-model merge c-family.patch [1/8]

On 11/06/2011 09:58 AM, Andrew MacLeod wrote: Just checked in the patches. I will also post the exact patches now. I am also checking out mainline and building it again. Andrew 2011-11-06 Andrew MacLeod Richard Henderson Merged from cxx-mem-model. *

Re: cxx-mem-model merge testsuite part 2 patch 7/8

On 11/06/2011 09:58 AM, Andrew MacLeod wrote: Just checked in the patches. I will also post the exact patches now. I am also checking out mainline and building it again. Andrew Index: gcc/testsuite/gcc.dg/gomp/atomic-14.c

Re: cxx-mem-model merge fortran patch 2/8

On 11/06/2011 09:58 AM, Andrew MacLeod wrote: Just checked in the patches. I will also post the exact patches now. I am also checking out mainline and building it again. Andrew 2011-11-06 Andrew MacLeod Aldy Hernandez Merged from cxx-mem-model. * typ

Re: [Patch,Fortran] PR39427/37829 - implement F2003's constructors

Last try: Also gzip the release notes - let's see whether it mailserver accepts that email. Tobias PS: I really hate that the email get's simply dropped without any reject email or any other status. Seemingly, my other emails without patches go through! I just realized that my patch email di

[PATCH] Fix libgcc_tm.h dependency in libgcc Makefile

This is fixes a trunk build error noticed on hppa-linux at -j4. Tested on hppa-unknown-linux-gnu and hppa64-hp-hpux11.11. Ok? Dave -- J. David Anglin dave.ang...@nrc-cnrc.gc.ca National Research Council of Canada (613) 990-0752 (FAX: 952-6602) 2011

[patch] 20/n: trans-mem: Unified change logs

The patch adds unified changelogs. (Before merging, we would remove the ChangeLog.tm-merge files and add their contents to the respective ChangeLog files). libitm/ChangeLog would stay as is, I suppose. OK for branch? commit d54f6c956fab68f5961f245e02817c6720c0758d Author: Torvald Riegel Date: S

Re: Enhance performance test

Attached patch applied. 2011-11-06 François Dumont * testsuite/performance/23_containers/insert_erase/41975.cc: Add tests to check performance with or without cache of hash code and with string type that has a costlier hash functor than int type. François On 11/05/

Re: [Patch,Fortran] PR39427/37829 - implement F2003's constructors

Am 06.11.2011 17:26, schrieb Tobias Burnus: I just realized that my patch email did not come through - however, I did not get any reject email. Let's try first without patch - it's available at http://users.physik.fu-berlin.de/~tburnus/tmp/constructor.diff I wondered whether the patch exceede

Re: [patch] 17/n: trans-mem: compiler trans-mem main engine

On Fri, 2011-11-04 at 22:48 +0100, Torvald Riegel wrote: > On Thu, 2011-11-03 at 20:38 +, Joseph S. Myers wrote: > > Make sure that you do need each #include present in this and any other new > > file. Since 2008 a lot of includes of tm.h and toplev.h have been removed > > and diagnostic-cor

Re: [Patch,Fortran] PR39427/37829 - implement F2003's constructors

Last try: Also gzip the release notes - let's see whether it mailserver accepts that email. Tobias PS: I really hate that the email get's simply dropped without any reject email or any other status. Seemingly, my other emails without patches go through! I just realized that my patch email d

Re: [Patch,Fortran] PR39427/37829 - implement F2003's constructors

Am 06.11.2011 17:26, schrieb Tobias Burnus: I just realized that my patch email did not come through - however, I did not get any reject email. Let's try first without patch - it's available at http://users.physik.fu-berlin.de/~tburnus/tmp/constructor.diff Possibly it is too large - it's bel

Re: [patch, Fortran] Fix PR 50690

Hi Tobias, I'm just back from holiday, which it took me a bit longer to reply. Actually, the test case is *not* OK. If one compiles the original test case of the PR (or your workshare2.f90) with "-O" and looks at "-fdump-tree-original", one finds: #pragma omp parallel default(shared)

[C++ Patch] PR 47695

Hi, duplicate diagnostics for (a pretty common error, I would guess): void f() = delete; void g() { f(); } 47695.C: In function ‘void g()’: 47695.C:2:12: error: use of deleted function ‘void f()’ 47695.C:1:6: error: declared here 47695.C:2:14: error: use of deleted function ‘void f()’ 47695.C:1:

Re: [PATCH] Don't prevent merging of bbs because of user labels (PR tree-optimization/50693)

> As has been suggested by Alexandre in the PR, this patch allows merging > basic blocks which couldn't be merged before because of user (non-forced) > labels at the beginning of the second basic blocks. > With this patch the user label is thrown away (for -g0 or -g > -fno-var-tracking-assignments)

Re: [rs6000] fix PR 30282, load from stack moved past stack update

On Fri, Nov 4, 2011 at 9:43 AM, Alan Modra wrote: > This patch fixes PR30282, caused by instructions being scheduled over > the stack reset.  Note that only for ABI_V4 do we currently have > frame_reg_rtx != sp_reg_rtx in rs6000_emit_stack_reset, so the patch > doesn't emit *less* blockages.  I di

Re: [patch] 20/n: trans-mem: Unified change logs

On Sun, 2011-11-06 at 06:09 -0800, Aldy Hernandez wrote: > On 11/06/11 06:05, Torvald Riegel wrote: > > The patch adds unified changelogs. (Before merging, we would remove the > > ChangeLog.tm-merge files and add their contents to the respective > > ChangeLog files). libitm/ChangeLog would stay as

Re: [Patch,Fortran] PR39427/37829 - implement F2003's constructors

Also the following failed. Thus, the patch links again: - http://users.physik.fu-berlin.de/~tburnus/tmp/constructor.diff - Release notes: http://users.physik.fu-berlin.de/~tburnus/tmp/releasenotes.diff Tobias PS: I really hate that the email get's simply dropped without any reject email or an

Re: [Patch,Fortran] PR39427/37829 - implement F2003's constructors

I just realized that my patch email did not come through - however, I did not get any reject email. Let's try first without patch - it's available at http://users.physik.fu-berlin.de/~tburnus/tmp/constructor.diff Tobias Rouson, Damian wrote: Bravo! Thanks for all the hard work, Tobias. Alt

Re: [Patch,Fortran] PR39427/37829 - implement F2003's constructors

Bravo! Thanks for all the hard work, Tobias. Although I realize many people will (correctly) label the constructor capability as syntactic sugar, it supports an idiom that is common across OOP languages as you point out. Common idioms have expressive power. Damian On 11/6/11 6:29 AM, "Tobias B

Re: [patch] 6/n: trans-mem: runtime

On Thu, 2011-11-03 at 20:15 +, Joseph S. Myers wrote: > Do you need a FLAGS_TO_PASS setting as in > ? (The way to > test is to do a multilib build and install, passing infodir=/some/where on > the "make install" line, and see if the m

Re: [patch] 17/n: trans-mem: compiler trans-mem main engine

On 11/06/11 07:28, Torvald Riegel wrote: On Fri, 2011-11-04 at 22:48 +0100, Torvald Riegel wrote: On Thu, 2011-11-03 at 20:38 +, Joseph S. Myers wrote: Make sure that you do need each #include present in this and any other new file. Since 2008 a lot of includes of tm.h and toplev.h have be

cxx-mem-model branch merged to mainline - revision 181031

Just checked in the patches. I will also post the exact patches now. I am also checking out mainline and building it again. Andrew

Re: r181016 - in /trunk: contrib/ChangeLog contrib/...

Quoting "Joseph S. Myers" : All these properties look wrong; I see no reason for any of those files to be executable. Indeed. I didn't know svn add would do that. I've removed these spurious properties.

Re: r181016 - in /trunk: contrib/ChangeLog contrib/...

On Sat, 5 Nov 2011, amyl...@gcc.gnu.org wrote: > Propchange: trunk/gcc/config/epiphany/epiphany-modes.def > ('svn:executable' added) > > Propchange: trunk/gcc/config/epiphany/epiphany-protos.h > ('svn:executable' added) > > Propchange: trunk/gcc/config/epiphany/epiphany.c

Re: [patch] 20/n: trans-mem: Unified change logs

On 11/06/11 06:05, Torvald Riegel wrote: The patch adds unified changelogs. (Before merging, we would remove the ChangeLog.tm-merge files and add their contents to the respective ChangeLog files). libitm/ChangeLog would stay as is, I suppose. OK for branch? Thanks so much. OK.

Re: [patch] 9/n: trans-mem: compiler ChangeLog entries

On Fri, 2011-11-04 at 15:34 +0100, Michael Matz wrote: > Hi, > > On Thu, 3 Nov 2011, Aldy Hernandez wrote: > > > +2010-05-28 Aldy Hernandez > > + > > + * target-def.h (TARGET_VECTORIZE_BUILTIN_TM_LOAD): Define. > > + (TARGET_VECTORIZE_BUILTIN_TM_STORE): Same. > > + (TARGET_VECTORIZE): Ad

Re: Use of vector instructions in memmov/memset expanding

> > There is rolled loop algorithm, that doesn't use SSE-modes - such > architectures could use it instead of unrolled_loop. I think the > performance wouldn't suffer much from that. > For the most of modern processors, SSE-moves are faster than several > word-sized moves, so this change in unroll

Re: [PATCH] PR target/50038 fix: redundant zero extensions removal

2011/11/6 Richard Guenther : > On Sun, Nov 6, 2011 at 11:50 AM, Ilya Enkovich wrote: >> Hello, >> >> 2011/11/5 Eric Botcazou : Here is a patch which fixes redundant zero extensions problem. Issue is resolved by expanding implicit_zee pass functionality to cover zero and sign extends

[PATCH] Fix fallout from inlinable flag handling change

This fixes ipa-prop to properly re-compute inlinability which can change from false to true if a mismatched argument is dropped. Bootstrapped and tested onx 86_64-unknown-linux-gnu, applied. Richard. 2011-11-6 Richard Guenther * ipa-prop.c (ipa_modify_call_arguments): Re-compute

Re: repost: [DF] Use HARD_REG_SETs instead of bitmaps

On Sun, Nov 06, 2011 at 01:12:21PM +0100, Paolo Bonzini wrote: > On 11/06/2011 03:19 AM, Dimitrios Apostolou wrote: > > > >I understand major hassle is when the register file is big, too much > >data is being copied on a function call, when it has a HARD_REG_SET as a > >pass by value parameter. So

Re: repost: [DF] Use HARD_REG_SETs instead of bitmaps

On 11/06/2011 03:19 AM, Dimitrios Apostolou wrote: I understand major hassle is when the register file is big, too much data is being copied on a function call, when it has a HARD_REG_SET as a pass by value parameter. So I did some testing on SPARC, which has the biggest register file I know of,

Re: [Patch, Fortran] Cleanup of gfc_extend_expr

2011/11/3 Steve Kargl : > On Thu, Nov 03, 2011 at 10:56:47PM +0100, Janus Weil wrote: >> > At least add a comment about the re-use (abuse?) of the >> > enum. >> >> Updated patch attached, which adds a short comment on the usage of 'match'. > > Thanks. > >> > This should reduce confusion months from

Re: [Patch, Fortran] Cleanup of gfc_extend_expr

> Sounds like what everything needs is a differently named enum: say > three_way_logic. Well, one might just rename the present enum 'match' (which anyway lacks the usual 'gfc' prefix), to something like 'gfc_three_way_logic' (or whatever name you prefer), with appropriately named values. Then on

Re: [PATCH] PR target/50038 fix: redundant zero extensions removal

On Sun, Nov 6, 2011 at 11:50 AM, Ilya Enkovich wrote: > Hello, > > 2011/11/5 Eric Botcazou : >>> Here is a patch which fixes redundant zero extensions problem. Issue >>> is resolved by expanding implicit_zee pass functionality to cover zero >>> and sign extends of different modes. Could please som

Many testsuite failures on x86_64 due recent "fix" about f16cintrin.h header

Hi, In ChangeLog is mentioned a change to config/config.gcc, which doesn't exist. I assume the change is meant for config.gcc within gcc/ folder, but also for this file no change was applied. By this f16cintrin.h header isn't installed at all. Cuprit patch is: 2011-11-05 Quentin Neill

Re: [PATCH] PR target/50038 fix: redundant zero extensions removal

Hello, 2011/11/5 Eric Botcazou : >> Here is a patch which fixes redundant zero extensions problem. Issue >> is resolved by expanding implicit_zee pass functionality to cover zero >> and sign extends of different modes. Could please someone review it? > > Could you explain the undelying idea?  The

Re: [patch] 3/n: trans-mem: runtime

On Sat, 5 Nov 2011, Aldy Hernandez wrote: I believe this should become "2009, 2011" or "2009, 2010, 2011" when it's applied to trunk. I assume the same thing goes for the rest of similar files. Yes, that's my understanding, I just didn't want to bother you with a response to every single patch

Re: [PATCH Atom] Fix for PR target/50962 (bad AGU stall avoidance)

Hi, 2011/11/5 Richard Henderson : >> +  if (!TARGET_OPT_AGU || optimize_function_for_size_p (cfun)) > > Surely optimize_insn_for_size_p (), so that cold blocks are optimized for > size. OK. >> +      else if (ix86_use_lea_for_mov(insn, operands)) >> +     return "lea{q}\t{%a1, %0|%0, %a1}"; > >

  1   2   >