Re: serious libgcc regression added recently

From: Jakub Jelinek Date: Thu, 3 Nov 2011 09:22:51 +0100 > On Wed, Nov 02, 2011 at 11:41:08PM -0400, David Miller wrote: >> --- a/libgcc/configure.ac >> +++ b/libgcc/configure.ac >> @@ -255,11 +255,12 @@ AC_CACHE_CHECK([whether assembler supports CFI >> directives], [libgcc_cv_cfi], >>[libgc

Re: [SPARC] Consolidate movtf patterns

From: Eric Botcazou Date: Thu, 3 Nov 2011 17:26:28 +0100 > Tested on SPARC/Solaris, applied on the mainline. Thanks for doing this work Eric.

Re: [PATCH] Canonicalize sparc movcc patterns such that operand 0 always appears in operand 4.

From: David Miller Date: Wed, 02 Nov 2011 16:17:33 -0400 (EDT) > From: Eric Botcazou > Date: Wed, 2 Nov 2011 13:29:45 +0100 > >> This has reintroduced PR target/49965. > > I am working on fixing this right now, thanks for reporting Eric. This took longer than expected to fix :-) There are se

Re: [wwwdocs] Buildstat update for 4.6

On Thu, Nov 03, 2011 at 08:00:28PM +, Iain Sandoe wrote: > I updated the *-darwin9 tests to include Java as well as Ada. > > http://gcc.gnu.org/ml/gcc-testresults/2011-11/msg00037.html > http://gcc.gnu.org/ml/gcc-testresults/2011-11/msg00036.html > Thanks for the heads up. I missed them since

Re: [google] ThreadSanitizer instrumentation pass (issue 5303083)

On Thu, Nov 3, 2011 at 6:31 AM, wrote: > On 2011/11/01 16:59:04, davidxl wrote: >> >> that means some existing bugs get exposed. > > It is quite likely. > >> Your previous version >> simply skipped the target mem refs. > > Hummm... how can non-handling of some expressions lead to crashes? I > wou

Re: [google] ThreadSanitizer instrumentation pass (issue 5303083)

> http://codereview.appspot.com/5303083/diff/1/gcc/tree-tsan.c#newcode911 >> >> gcc/tree-tsan.c:911: bbd->has_sb = 0; >> Where is the code that instrument function calls? > > I do not instrument calls. Instead I instrument func entry/exit. > How are calls to locking and synchronization functions t

C++ PATCH for c++/48370 (extending lifetime of temps in aggregate initialization)

12.2 states that a temporary bound to a reference lives as long as the reference itself. We have done that for reference variables, but not in other cases, such as aggregate initialization of a struct with reference members. In C++11, elements of a std::initializer_list have the same semantic

Re: [patch] 1/n: trans-mem: libitm runtime tests

On 11/03/2011 01:32 PM, Richard Henderson wrote: > Indeed. The skeleton for libitm was libgomp. And libgomp does do > fortran stuff, which leads directly to the two errant fortran > references spotted by Joseph. > > Will fix. Here's the fix for both gfortran references. Committed to the branch.

Re: [C++ Patch / RFC] PR 48420

On 11/03/2011 05:06 PM, Jason Merrill wrote: I'd rather use maybe_constant_value here, but I think you don't need to check the actual value at all; if we have decided that there is a conversion from bool to pointer, it must be a null pointer constant, and so false. Ah! Thanks for the explanatio

Re: [Patch, fortran] [00/66] PR fortran/43829 Inline sum and product (AKA scalarization of reductions)

On Tuesday 01 November 2011 22:07:48 Paul Richard Thomas wrote: > The only, slight worry that I have is that it is going to make Richi's > middle end scalarization nearly impossible to use for gfortran. > However, the enhanced capability that this patch brings makes it a > worthy addition to gfortr

Re: [patch] 14/n: trans-mem: compiler documentation

On 11/03/11 19:30, Joseph S. Myers wrote: On Thu, 3 Nov 2011, Aldy Hernandez wrote: I thought so too, but couldn't find how. Libitm is in another directory (libitm/libitm.texi). Does anyone know how to do this? When installed, all info files are presumed to go in one directory, HTML files i

[patch committed] Fix sh-elf build failure

Hi, The attached is an obvious fix to restore sh-elf cross build. Applied on trunk. Regards, kaz -- [libgcc] 2011-11-04 Kaz Kojima * config/sh/t-sh: Use $(gcc_compile) instead of $(compile). --- libgcc/config/sh/t-sh.orig 2011-11-03 09:27:12.0 +0900 +++ libgcc/config

Re: [patch] 14/n: trans-mem: compiler documentation

On Thu, 3 Nov 2011, Aldy Hernandez wrote: > > > I thought so too, but couldn't find how. Libitm is in another directory > > > (libitm/libitm.texi). Does anyone know how to do this? > > > > When installed, all info files are presumed to go in one directory, HTML > > files in parallel directories

Re: RFA: Add Epiphany port

On Thu, 3 Nov 2011, Joern Rennecke wrote: > > Comment about the reason for this option? > > Would this be OK? > > /* { dg-options "-O2" } */ > +/* Using -mshort-calls avoids constant loading the function addresses in > + registers and thus getting the counts wrong. */ > +/* { dg-options "-O2

Re: cxx-mem-model merge [3 of 9] doc

I don't see any changes to md.texi to document how machine descriptions should implement the new functionality, either here or in any other patch in the series, but such documentation is certainly required. -- Joseph S. Myers jos...@codesourcery.com

Re: [patch] 14/n: trans-mem: compiler documentation

I thought so too, but couldn't find how. Libitm is in another directory (libitm/libitm.texi). Does anyone know how to do this? When installed, all info files are presumed to go in one directory, HTML files in parallel directories, etc.; you use the five-argument form of @xref with "libitm" a

Re: cxx-mem-model merge [4 of 9] c-family

On Thu, 3 Nov 2011, Andrew MacLeod wrote: > + if (VEC_length (tree, params) != n_param) > + { > + error ("Incorrect number of arguments to function %qE", function); Diagnostics start with lowercase letters. The functions such as "error" that implicitly use input_location are depreca

Re: RFA: Add Epiphany port

Quoting "Joseph S. Myers" : +@item -mstack-offse@var{num} It appears to be -mstack-offset=@var{num}, not -mstack-offse@var{num}. Yes, I typoed a backspace for an =. Index: gcc/testsuite/gcc.dg/pragma-pack-3.c === --- gcc/tests

Re: cxx-mem-model merge [3 of 9] doc

On Thu, 3 Nov 2011, Andrew MacLeod wrote: > Index: doc/extend.texi Generally watch the line lengths in this patch - you should rewrap the paragraphs to a width of about 70 characters (no more than 80) before putting them on trunk. @item, @deftypefn etc. lines that can't be wrapped may be long

Re: cxx-mem-model merge [0 of 9]

On Thu, Nov 3, 2011 at 4:59 PM, Andrew MacLeod wrote: > wow, that could be a lot of work.  Is that really what every branch merge > does? Yes, I did just that for the pointer plus merge and Daniel did it for the DF merge (which was much bigger). Thanks, Andrew Pinski

Re: cxx-mem-model merge [0 of 9]

On 11/03/2011 07:54 PM, Joseph S. Myers wrote: On Thu, 3 Nov 2011, Andrew MacLeod wrote: Whats the deal on Changelogs? Do we just put the entire branch changelog at the top of the current changelog with a comment 'merged from cxx-mem-model' or something to that effect? It just buggers up the

Re: cxx-mem-model merge [0 of 9]

On Thu, 3 Nov 2011, Andrew MacLeod wrote: > Whats the deal on Changelogs? Do we just put the entire branch changelog at > the top of the current changelog with a comment 'merged from cxx-mem-model' > or something to that effect? It just buggers up the date linearality of > changelogs. Or do I

cxx-mem-model merge [8 of 9] testsuite - gomp

These are the changed rth made to the GOMP testsuite.. looks primarily like consolidation to c-c++-common from 2 other directories. 2011-10-31 Richard Henderson * c-c++-common/gomp/atomic-10.c: Use cas_int; match __atomic builtin. * c-c++-common/gomp/atomic-3.c: Likewise.

Re: RFA: Add Epiphany port

On Thu, 3 Nov 2011, Joern Rennecke wrote: > @@ -2723,7 +2723,8 @@ least version 2.20.1), and GNU C library > @item long_call/short_call > @cindex indirect calls on ARM > This attribute specifies how a particular function is called on > -ARM@. Both attributes override the @option{-mlong-calls}

cxx-mem-model merge [5 of 9] fortran

This patch simply mimics the builtin-types.def changes so that fortran can build. 2011-11-02 Andrew MacLeod * types.def (BT_FN_BOOL_SIZE): Remove. (BT_FN_BOOL_SIZE_CONST_VPTR): Add. 2011-10-25 Andrew MacLeod * types.def (BT_FN_VOID_SIZE_VPTR_PTR_INT, BT_F

cxx-mem-model merge [4 of 9] c-family

These changes are primarily recognition of all __atomic builtins plus the expansion of the generic versions of the atomics. If a generic function call uses an object which is compatible with a lock free integral size, then the call is translated into one of those. This provides lock free suppo

cxx-mem-model merge [3 of 9] doc

These are the documentation changes for the __atomic builtins. Changefile entries are part of the gcc patch. Index: doc/extend.texi === *** doc/extend.texi (.../trunk/gcc) (revision 180790) --- doc/extend.texi (.../branches/

cxx-mem-model merge [0 of 9]

This is the patchset (9 diffs) for the cxx-mem-model branch which implements the C++11 (and future C1x) memory model. These patches have all been extracted from the branch. They were individually applied to a mainline checkout where a bootstrap was performed and a testsuite regression was run

Re: [trans-mem] XFAIL known failures

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 a bug about each missed optimization and reference the bug # in the testcase. This is so we don't lose

Re: [patch] 1/n: trans-mem: libitm runtime tests

On 11/03/11 17:36, Jakub Jelinek wrote: On Thu, Nov 03, 2011 at 05:26:43PM -0500, Aldy Hernandez wrote: I'm going to assume the tests themselves are good. It'd be nice if they all stated what they were testing, but I don't consider that a requirement. If the tests were written independently ra

Re: [trans-mem] XFAIL known failures

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 a bug about each missed optimization and reference the bug # in the testcase. This is so we don't lose track of the missed optimizations. Thanks

Re: [patch] 14/n: trans-mem: compiler documentation

On Thu, 3 Nov 2011, Aldy Hernandez wrote: > > > > +For more information on GCC's support for transactional memory, see > > > +the accompanying documentation for @file{libitm}. > > > > It should be possible to use a proper Texinfo cross-reference linking to > > the other manual. > > I thought so

[cxx-mem-model 2/2] arm: Install __sync libfuncs for Linux.

Cc: Richard Earnshaw --- gcc/config/arm/arm.c |4 1 files changed, 4 insertions(+), 0 deletions(-) diff --git a/gcc/config/arm/arm.c b/gcc/config/arm/arm.c index 5f0d562..9963faa 100644 --- a/gcc/config/arm/arm.c +++ b/gcc/config/arm/arm.c @@ -1096,6 +1096,10 @@ arm_set_fixed_conv_libfu

[cxx-mem-model 1/2] Allow libcalls to be installed for legacy __sync optabs.

This allows a target which implements the __sync interfaces in libgcc to continue to use them transparently with the new __atomic builtins. It is assumed that these libgcc routines DO NOT use spinlocks. This is true of all extant libgcc instances. --- gcc/builtins.c |2 +- gcc/genopinit.c |

[cxx-mem-model 0/2] Support the legacy __sync libcalls

Not installing to the branch because amacleod is busy preparing the merge. This can be committed after that's done. Something similar to the second patch needs to be done for: sh[34]-linux hppa-linux mips16 Given that it's a matter of two lines for each target, the most important of which

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

On Thu, 3 Nov 2011, Torvald Riegel wrote: > On Thu, 2011-11-03 at 16:18 -0500, Aldy Hernandez wrote: > > On 11/03/11 15:42, Joseph S. Myers wrote: > > > Also, you should actually remove the gpl.texi and funding.texi includes as > > > part of removing the Invariant Sections. > > > > > > > Torvald,

Re: [patch] 1/n: trans-mem: libitm runtime tests

On Thu, Nov 03, 2011 at 05:26:43PM -0500, Aldy Hernandez wrote: > >I'm going to assume the tests themselves are good. It'd be nice if > >they all stated what they were testing, but I don't consider that a > >requirement. If the tests were written independently rather than > >extracted from anothe

Re: [patch] 14/n: trans-mem: compiler documentation

+For more information on GCC's support for transactional memory, see +the accompanying documentation for @file{libitm}. It should be possible to use a proper Texinfo cross-reference linking to the other manual. I thought so too, but couldn't find how. Libitm is in another directory (libitm

Re: [Patch, Fortran] PR 50933 Fix type-compat check for BIND(C) DT

On Thu, Nov 03, 2011 at 11:18:46PM +0100, Tobias Burnus wrote: > gfortran only regarded different decls of SEQUENCE as the same but not > BIND(C) types. > > Interestingly, the c.l.f thread with this example (and some more) was > already mentioned in the fixed PR fortran/45211 for which only othe

Re: [patch] 1/n: trans-mem: libitm runtime tests

On 11/03/11 15:33, Jeff Law wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 11/03/11 11:44, Aldy Hernandez wrote: These are all new files, thus require no ChangeLog entries (for the tests themselves anyhow). However, I will post a separate ChangeLog for the entire libitm. Note copyrig

Re: [Patch, Fortran] PR 50960 - Mark PARAMETER as TREE_READONLY

On Thu, Nov 03, 2011 at 11:06:15PM +0100, Tobias Burnus wrote: > Dear all, > > gfortran stores PARAMETERS which are array or derived types as global > static variable. This prevents the compiler from optimizing those > parameters. > > Using TREE_READONLY, one can allow the compiler to make use

[v3] doxygen markup for tr2

Some doxygen markup tweaks to get the tr2 components to show up. Also, I've regenerated doc/html. tested x86/linux -benjamin 2011-11-03 Benjamin Kosnik * doc/doxygen/doxygroups.cc: Add markup for namespace tr2. * include/tr2/bool_set: Adjust doxygen markup. * include/tr2/dynamic_bitset:

Re: [Patch, Fortran] Cleanup of gfc_extend_expr

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 when > > someone wonders why gfc_

[Patch, Fortran] PR 50933 Fix type-compat check for BIND(C) DT

gfortran only regarded different decls of SEQUENCE as the same but not BIND(C) types. Interestingly, the c.l.f thread with this example (and some more) was already mentioned in the fixed PR fortran/45211 for which only other issues were fixed. Build and regtested on x86-64-linux. OK? Tobias

[trans-mem] XFAIL known failures

These are known failures, mostly missed optimizations. XFAILing them. Committed to branch. libitm/ * testsuite/libitm.c/reentrant.c: XFAIL. * testsuite/libitm.c++/static_ctor.C: XFAIL. gcc/ * testsuite/gcc.dg/tm/memopt-3.c: XFAIL. * testsuite/gcc.dg/tm/memopt-4.c:

Re: [PATCH] Fix fixuns_trunc2 and vec_pack_ufix_trunc_

On 11/03/2011 02:17 PM, Jakub Jelinek wrote: > * config/i386/i386.c (ix86_expand_adjust_ufix_to_sfix_si): Add > XORP argument. Subtract 0x1p31 instead of 0x1p32. Use normal > signalling comparison instead of non-signalling. Store into > *XORP pseudo holding 0x8000 int

[Patch, Fortran] PR 50960 - Mark PARAMETER as TREE_READONLY

Dear all, gfortran stores PARAMETERS which are array or derived types as global static variable. This prevents the compiler from optimizing those parameters. Using TREE_READONLY, one can allow the compiler to make use of the values and do further optimizations. Build and regtested on x86_6

Re: [Patch, Fortran] Cleanup of gfc_extend_expr

> 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'. > This should reduce confusion months from when > someone wonders why gfc_extend_expr returns a "match" > for a non-matching function. Well, I think my a

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

On Thu, 2011-11-03 at 16:18 -0500, Aldy Hernandez wrote: > On 11/03/11 15:42, Joseph S. Myers wrote: > > Also, you should actually remove the gpl.texi and funding.texi includes as > > part of removing the Invariant Sections. > > > > Torvald, similarly here. Please wait for Joseph's approval of yo

Re: [patch] 10/n: trans-mem: compiler tests (1 of 3)

On 11/03/11 15:22, Joseph S. Myers wrote: On Thu, 3 Nov 2011, Aldy Hernandez wrote: +#if (__SIZEOF_LONG_LONG__ == __SIZEOF_POINTER__) +typedef unsigned long long ptrcast; +#elif (__SIZEOF_LONG__ == __SIZEOF_POINTER__) +typedef unsigned long ptrcast; +#elif (__SIZEOF_INT__ == __SIZEOF_POINTER__)

Re: [Patch]: Fix PR rtl-optimization/50448

> PR rtl-optimization/50448 > * cprop.c (try_replace_reg): Try to simplify SET_SRC given the > substitution. The whole patch is about SET_DEST though, so I'm a little confused. And the head comment of try_replace_reg reads: /* Try to replace all non-SET_DEST occurrences of FRO

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

On 11/03/11 15:42, Joseph S. Myers wrote: Also, you should actually remove the gpl.texi and funding.texi includes as part of removing the Invariant Sections. Torvald, similarly here. Please wait for Joseph's approval of your patch, and then commit.

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

On 11/03/11 15:41, Joseph S. Myers wrote: On Thu, 3 Nov 2011, Aldy Hernandez wrote: As far as I know this is not printed by the FSF, and under 400 pages, so as per you can omit

[PATCH] Fix fixuns_trunc2 and vec_pack_ufix_trunc_

Hi! This patch fixes the other bug I've mentioned. Subtracting 0x1p32 doesn't work in all cases correctly, so this patch changes it to do what we do for scalar -O2 -m32 -msse2 -mfpmath=sse double -> uint and float -> uint conversions, in particular subtract just 0x1p31 instead of 0x1p32, doing th

Committed: fix cris-elf fallout from libgcc move

Committed after testing cross to cris-elf and crisv32-elf; for the former back to the two regressions before the recent libgcc move. Ironically, the *reference* in the quoted failure: > complex-1.c:(.text+0x9e): undefined reference to `__nesf2' should not have been there in the first place, as the

Re: [PATCH]: Handle STRICT_LOW_PART in slim RTL dumps

On 11/03/2011 01:39 PM, Uros Bizjak wrote: > 2011-11-03 Uros Bizjak > > * sched-vis.c (print_value): Handle STRICT_LOW_PART. Ok. r~

Re: except.c: fix setjmp buffer size math

On Thu, 3 Nov 2011, Mike Stump wrote: > On Nov 3, 2011, at 2:14 AM, Eric Botcazou wrote: > > >>* except.c (init_eh): Fix setjmp buffer size calculations for > >>targets where pointers are not word-sized. > > > > This will shrink the buffer for most such targets though. > > I prefer: >

[PATCH]: Handle STRICT_LOW_PART in slim RTL dumps

Hello! Currently slim RTL dump prints STRICT_LOW_PART as: 48 strict_low_part=flags:CCZ!=0 Attached patch fixes these dumps to print: 48 strict_low_part(ax:QI)=flags:CCZ!=0 2011-11-03 Uros Bizjak * sched-vis.c (print_value): Handle STRICT_LOW_PART. Tested on x86_64-pc-linux-g

Re: [patch] 16/n: trans-mem: compiler parser/front-end

On 11/03/2011 01:34 PM, Joseph S. Myers wrote: > On Thu, 3 Nov 2011, Aldy Hernandez wrote: > >> +/* Parse a transaction attribute (GCC Extension). >> + >> + transaction-attribute: >> + attributes >> + [ [ any-word ] ] > > I don't see any syntax production comments including > transacti

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

Also, you should actually remove the gpl.texi and funding.texi includes as part of removing the Invariant Sections. -- Joseph S. Myers jos...@codesourcery.com

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

On Thu, 3 Nov 2011, Aldy Hernandez wrote: > > As far as I know this is not printed by the FSF, and under 400 pages, so > > as per > > > > you can omit invariant sections and cover

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

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-core.h introduced as an alternative to diagnostic.h for many users. If tm.h is needed, it's good to have a comment on the #includ

Re: [patch] 16/n: trans-mem: compiler parser/front-end

On Thu, 3 Nov 2011, Aldy Hernandez wrote: > +/* Parse a transaction attribute (GCC Extension). > + > + transaction-attribute: > + attributes > + [ [ any-word ] ] I don't see any syntax production comments including transaction-attribute. Please update the comments to include this in

Re: [patch] 1/n: trans-mem: libitm runtime tests

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 11/03/11 11:44, Aldy Hernandez wrote: > These are all new files, thus require no ChangeLog entries (for > the tests themselves anyhow). However, I will post a separate > ChangeLog for the entire libitm. Note copyright dates... Make sure they're no

Re: [patch] 1/n: trans-mem: libitm runtime tests

On 11/03/2011 01:21 PM, Richard Henderson wrote: > On 11/03/2011 01:08 PM, Aldy Hernandez wrote: >> On 11/03/11 15:00, Joseph S. Myers wrote: >>> Why are you using gfortran-dg.exp and gfortran-dg-runtest when as far as I >>> can tell there is nothing Fortran-related in these tests? >>> >> >> Richar

Re: [patch] 14/n: trans-mem: compiler documentation

On Thu, 3 Nov 2011, Aldy Hernandez wrote: > Index: gcc/doc/tm.texi.in > === > --- gcc/doc/tm.texi.in(.../trunk) (revision 180744) > +++ gcc/doc/tm.texi.in(.../branches/transactional-memory) > (revision > 18077

Re: [patch] 10/n: trans-mem: compiler tests (1 of 3)

On Thu, 3 Nov 2011, Aldy Hernandez wrote: > +#if (__SIZEOF_LONG_LONG__ == __SIZEOF_POINTER__) > +typedef unsigned long long ptrcast; > +#elif (__SIZEOF_LONG__ == __SIZEOF_POINTER__) > +typedef unsigned long ptrcast; > +#elif (__SIZEOF_INT__ == __SIZEOF_POINTER__) > +typedef unsigned int ptrcast; >

Re: [patch] 1/n: trans-mem: libitm runtime tests

On 11/03/2011 01:08 PM, Aldy Hernandez wrote: > On 11/03/11 15:00, Joseph S. Myers wrote: >> Why are you using gfortran-dg.exp and gfortran-dg-runtest when as far as I >> can tell there is nothing Fortran-related in these tests? >> > > Richard? Um... cut-and-paste from the wrong original file?

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

On Thu, 3 Nov 2011, Aldy Hernandez wrote: > +# We need gfortran to compile parts of the library > +# We can't use AC_PROG_FC because it expects a fully working gfortran. > +#AC_PROG_FC(gfortran) > +FC="$GFORTRAN" > +AC_PROG_FC(gfortran) > +FCFLAGS="$FCFLAGS -Wall" I don't actually see where gfort

Re: expr.c: don't assume MUL for scaling pointers

On 11/02/2011 08:23 PM, DJ Delorie wrote: > GCC assumes the target has a multiply insn, but better code is > generated using shifts if it doesn't (vs a libcall). Found with the > rl78-elf port. > > * expr.c (expand_expr_real_2): Don't try to emit a MUL-based > expression if the target

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

As far as I know this is not printed by the FSF, and under 400 pages, so as per you can omit invariant sections and cover texts. +Published by the Free Software Foundation +51

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

On Thu, 3 Nov 2011, Aldy Hernandez wrote: > Index: libitm/acinclude.m4 > === > --- libitm/acinclude.m4 (.../trunk) (revision 0) > +++ libitm/acinclude.m4 (.../branches/transactional-memory) > (revision > 180773) >

Re: [patch] 1/n: trans-mem: libitm runtime tests

On 11/03/11 15:00, Joseph S. Myers wrote: Why are you using gfortran-dg.exp and gfortran-dg-runtest when as far as I can tell there is nothing Fortran-related in these tests? Richard?

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

On Thu, 3 Nov 2011, Aldy Hernandez wrote: > +Permission is granted to copy, distribute and/or modify this document > +under the terms of the GNU Free Documentation License, Version 1.2 or > +any later version published by the Free Software Foundation; with the > +Invariant Sections being ``Funding

Re: [patch] 13/n: trans-mem: compiler backend (x86)

On 11/03/2011 11:55 AM, Andrew Pinski wrote: > On Thu, Nov 3, 2011 at 11:43 AM, Aldy Hernandez wrote: >> +/* Return the builtin decl needed to load a vector of TYPE. */ > ... >> + >> +/* Return the builtin decl needed to store a vector of TYPE. */ > > Is there a reason why the middle-end could

Re: [wwwdocs] Buildstat update for 4.6

On 3 Nov 2011, at 19:42, Tom G. Christensen wrote: Latest results for 4.6.x -tgc Testresults for 4.6.2: arm-unknown-rtemseabi4.11 (2) hppa2.0w-hp-hpux11.11 hppa64-hp-hpux11.11 i386-pc-solaris2.8 i686-apple-darwin9 i686-pc-linux-gnu (2) powerpc-apple-darwin8.11.0 powerpc-apple-darwin9

Re: [patch] 1/n: trans-mem: libitm runtime tests

Why are you using gfortran-dg.exp and gfortran-dg-runtest when as far as I can tell there is nothing Fortran-related in these tests? -- Joseph S. Myers jos...@codesourcery.com

Re: RFA: Add Epiphany port

On 11/03/2011 12:04 PM, Joern Rennecke wrote: > I could conceivably implement __builtin_epiphany_fmadd in a header file > using fma, reordering the operands, but that would only make the port > messier. The semantics of fma are not documented in extend.texi. Well, we managed to get the docs into

[wwwdocs] Buildstat update for 4.6

Latest results for 4.6.x -tgc Testresults for 4.6.2: arm-unknown-rtemseabi4.11 (2) hppa2.0w-hp-hpux11.11 hppa64-hp-hpux11.11 i386-pc-solaris2.8 i686-apple-darwin9 i686-pc-linux-gnu (2) powerpc-apple-darwin8.11.0 powerpc-apple-darwin9 powerpc64-unknown-linux-gnu s390-ibm-linux-

Re: [PATCH] [Annotalysis] Fix ICE caused by ipa-sra optimization.

On Thu, Nov 3, 2011 at 15:31, Delesley Hutchins wrote: > New patch with suggested changes incorporated.  Warning now on by > default, asserts put back if ipa-sra not enabled, and style fixes. Thanks. I only found two nits: (1) some comments need an extra space after the final '.', (b) diagnosti

Re: [PATCH] [Annotalysis] Fix ICE caused by ipa-sra optimization.

New patch with suggested changes incorporated. Warning now on by default, asserts put back if ipa-sra not enabled, and style fixes. -DeLesley On Thu, Nov 3, 2011 at 11:06 AM, Diego Novillo wrote: > On Thu, Nov 3, 2011 at 12:41, Delesley Hutchins wrote: >>> I wonder... how about disabling IPA

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

This is everything else that doesn't fit neatly into any other category. Here are the middle end changes, as well as pass ordering code, along with varasm and a potpourri of other small changes. This is the last patch. Please let me know if there is anything else (reasonable) you would like

[patch] 19/n: trans-mem: compiler tree/gimple stuff

These are misc tree and gimple patches, which I consider front-ish-end changes. Index: gcc/tree.c === --- gcc/tree.c (.../trunk) (revision 180744) +++ gcc/tree.c (.../branches/transactional-memory) (revision 180773) @@ -95

[patch] 18/n: trans-mem: Makefile.in

Index: gcc/Makefile.in === --- gcc/Makefile.in (.../trunk) (revision 180744) +++ gcc/Makefile.in (.../branches/transactional-memory) (revision 180773) @@ -912,7 +912,8 @@ RTL_H = $(RTL_BASE_H) genrtl.h vecir.h RTL_ER

Re: Massive breakage with your libgcc patches

Bernd Schmidt writes: > I've tried again on x86_64, still no such failure. Are you quite sure > the binutils directory is up-to-date? (Try a clean checkout with CVS). It was up-to-date, but somehow mangled (haven't yet investigated how/why). Anyway, with a fresh anon-CVS checkout of the 2.22 br

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

> But doesn't that imply that a hard register is getting inserted into > the array more than once. While I don't see explicit code to prevent > this, I'm having a hard time seeing how that can actually happen. The test case is qsort.c from newlib. I added some runtime checks to caller-saves and

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

Here is the main engine (trans-mem.c and trans-mem.h). The file trans-mem.c did not fit within the 100k that the list restricts me to, so I am attaching the patch for both of these files as a bzip2 file. If it is preferable for me to split this one file in two separate posts, I can do so. t

Re: [PATCH] Fix up floatunsv{4,8}siv{4,8}sf2

On Thu, Nov 3, 2011 at 6:54 PM, Jakub Jelinek wrote: > As mentioned in the last mail, the testcase in that patch > shows a bug in the unsigned int -> float vectorization > on i?86/x86_64.  E.g. 0x808fU converted to float > by scalar code is 0x1.02p+31, but by vector code > is 0x1p+31, i.e

Re: RFA: Add Epiphany port

Quoting Andrew Pinski : On Thu, Nov 3, 2011 at 11:08 AM, Joern Rennecke wrote: +@smallexample +float __builtin_epiphany_fmadd (float a, float b, float c) /* a + b * c */ +float __builtin_epiphany_fmsub (float a, float b, float c) /* a - b * c */ +@end smallexample I don't think you need tar

[patch] 16/n: trans-mem: compiler parser/front-end

Parser and some front-end stuff, like tree definitions, etc. Index: gcc/c-parser.c === --- gcc/c-parser.c (.../trunk) (revision 180744) +++ gcc/c-parser.c (.../branches/transactional-memory) (revision 180773) @@ -1

Re: RFA: Fix dse / postreload not to bypass add expanders

> This patch makes emit_inc_dec_insn_before use add3_insn / gen_move_insn > so that the appropriate expanders are used to create the new instructions, > and for dse it use the available register liveness information to check > that no live fixed hard register, like a flags register, is clobbered in

Re: [patch] 13/n: trans-mem: compiler backend (x86)

On Thu, Nov 3, 2011 at 11:43 AM, Aldy Hernandez wrote: > +/* Return the builtin decl needed to load a vector of TYPE.  */ ... > + > +/* Return the builtin decl needed to store a vector of TYPE.  */ Is there a reason why the middle-end could not handle vector types by default? Instead of the targ

[patch] 15/n: trans-mem: compiler C++ changes

Jason, all the compiler changes (including C++) are in a separate post: http://gcc.gnu.org/ml/gcc-patches/2011-11/msg00380.html If you would prefer, I can reply to this message and provide the C++ changelog entries separately. Index: gcc/cp/class.c

[patch] 14/n: trans-mem: compiler documentation

Index: gcc/doc/tm.texi === --- gcc/doc/tm.texi (.../trunk) (revision 180744) +++ gcc/doc/tm.texi (.../branches/transactional-memory) (revision 180773) @@ -5758,6 +5758,16 @@ mode returned by @code{TARGET_VECTORIZE_ T

[patch] 13/n: trans-mem: compiler backend (x86)

Index: gcc/config/i386/i386-builtin-types.def === --- gcc/config/i386/i386-builtin-types.def (.../trunk) (revision 180744) +++ gcc/config/i386/i386-builtin-types.def (.../branches/transactional-memory) (revision 180773) @@

[PATCH, i386]: Use operands[N] consistently in i386.md

Hello! For some reason, several expanders use operandN internal variable instead of operands[N] from the array. Attached patch fixes this oversight. 2011-11-03 Uros Bizjak * config/i386/i386.md (lround2, rint2, floor2, lfloor2, btrunc2, lwp_lwpval3): Use operands[N] in

Re: Massive breakage with your libgcc patches

On 11/03/11 19:12, Rainer Orth wrote: > Bernd Schmidt writes: > > [Trimming the Cc: list.] > >> On 11/03/11 18:01, Rainer Orth wrote: >>> Bernd Schmidt writes: A cross environment for -elf targets typicaly just requires building up binutils/newlib, and that should be rather quick to s

[patch] 11/n: trans-mem: compiler tests (2 of 3)

Index: gcc/testsuite/g++.dg/tm/wrap-2.C === --- gcc/testsuite/g++.dg/tm/wrap-2.C(.../trunk) (revision 0) +++ gcc/testsuite/g++.dg/tm/wrap-2.C (.../branches/transactional-memory) (revision 180773) @@ -0,0 +1,16 @@ +/* { dg-do

Re: RFA: Add Epiphany port

On Thu, Nov 3, 2011 at 11:08 AM, Joern Rennecke wrote: > +@smallexample > +float __builtin_epiphany_fmadd (float a, float b, float c) /* a + b * c */ > +float __builtin_epiphany_fmsub (float a, float b, float c) /* a - b * c */ > +@end smallexample I don't think you need target specific builtins

[patch] 8d/n: trans-mem: toplevel/misc changes (configury/makefile/config)

Index: ChangeLog.tm === --- ChangeLog.tm(.../trunk) (revision 0) +++ ChangeLog.tm(.../branches/transactional-memory) (revision 180773) @@ -0,0 +1,89 @@ +2011-11-02 Aldy Hernandez + + * Merge from main

  1   2   >