[google] Fix a bug leading to inconsistent comdat group in LIPO mode (issue4616041)

The patch will be committed to google/main to fix a problem in LIPO model that leads to 'reference to discarded comdat section' ld warning. The problem is caused by inconsistent comdat groups between primary and aux modules because thunks were skipped in aux module. 2011-06-14 David Li

Re: [patch, libgfortran] PR48906 Wrong rounding results with -m32

On Tue, Jun 14, 2011 at 06:51, jerry DeLisle wrote: >> It should be easy to implement: >> >> After the switch between F and E editing, we just need to shift the >> decimal point and decrement the exponent. No new rounding is required, >> because we keep the number of significant digits. >> > > OK,

Re: [PATCH, SMS] Fix violation of memory dependence

Revital Eres wrote on 13/06/2011 10:29:06 AM: > From: Revital Eres > To: Ayal Zaks/Haifa/IBM@IBMIL > Cc: gcc-patches@gcc.gnu.org, Patch Tracking > Date: 13/06/2011 10:29 AM > Subject: [PATCH, SMS] Fix violation of memory dependence > > Hello, > > The attached patch fixes violation of memory dep

Re: [PATCH, SMS] Fix violation of memory dependence

Hello, > Yes, this is a straightforward fix to a wrong-code bug, as discussed > offline. Other alternatives that might introduce less edges: > o connect predecessors of u with v, and u with successors of v, when > removing edge (u,v). Maybe there are other cases which rely on transitivity > (?).

Re: RFA (fold): PATCH for c++/49290 (folding *(T*)(ar+10))

On Mon, 13 Jun 2011, Jason Merrill wrote: > On 06/13/2011 06:51 AM, Richard Guenther wrote: > > But I suppose you want the array-ref be folded to a constant eventually? > > Right. > > I'm not going to keep arguing about VIEW_CONVERT_EXPR, but that brings me back > to my original question: is it

Re: RFC: Fix GCSE exp_equiv_p on MEMs with different MEM_ATTRS (PR rtl-optimization/49390)

On Mon, 13 Jun 2011, Jakub Jelinek wrote: > Hi! > > As the testcase shows, the > http://gcc.gnu.org/ml/gcc-patches/2010-06/msg02945.html > patch looks wrong, MEM_ATTRS matters quite a lot for the > alias oracle, so ignoring it leads to miscompilations. > > Instead of just reverting the patch, th

Re: [PATCH, SMS] Fix violation of memory dependence

Hello, >> You could check first thing if (from->cuid == to->cuid), for code clarity. > > I will address this point separately and commit the current version of > the patch as is if that's OK. Re-thinking about that, I'll prepare a new version of the patch which addresses this and re-send it. Sor

Re: [PATCH] Only run pr48377.c testcase on i?86/x86_64

> This limits this testcase to i?86/x86_64 (moving to gcc.target/ would > be harder because it relies on all the weirdo vectorization options to be > passed), because apparently on strict alignment targets we don't handle > aligned (1) non-aggregates correctly. Or should it be instead xfailed > ju

Re: [testsuite]: Skip tests for targets with int < 32 bits

Jakub Jelinek schrieb: > On Mon, Jun 13, 2011 at 08:18:52PM +0200, Georg-Johann Lay wrote: >> For exammple, I added this line to, e.g. >> * gcc.c-torture/execute/cmpsi-2.c >> * gcc.c-torture/execute/pr45262.c >> in trunk r172757 >> http://gcc.gnu.org/viewcvs?view=revision&revision=172757 > > That

Re: RFC: Fix GCSE exp_equiv_p on MEMs with different MEM_ATTRS (PR rtl-optimization/49390)

On 06/14/2011 10:43 AM, Richard Guenther wrote: > The patch that reverted the MEM_ATTR comparison didn't come > with a single testcase (ugh, I realize I approved it though ;)). > Bernd, do you have any testcases? It was a missed-optimization problem, but I think it only showed up with a modified

Re: [PATCH] Only run pr48377.c testcase on i?86/x86_64

On Tue, Jun 14, 2011 at 11:10:13AM +0200, Eric Botcazou wrote: > > This limits this testcase to i?86/x86_64 (moving to gcc.target/ would > > be harder because it relies on all the weirdo vectorization options to be > > passed), because apparently on strict alignment targets we don't handle > > alig

Ping^5: Re: Updated^2: RFA: Fix middle-end/46500 (void * encapsulated)

Except or the fortran/java bits (committed), this patch hasn't been reviewed for five weeks: http://gcc.gnu.org/ml/gcc-patches/2011-05/msg00582.html

Re: RFC: Fix GCSE exp_equiv_p on MEMs with different MEM_ATTRS (PR rtl-optimization/49390)

On Tue, 14 Jun 2011, Bernd Schmidt wrote: > On 06/14/2011 10:43 AM, Richard Guenther wrote: > > The patch that reverted the MEM_ATTR comparison didn't come > > with a single testcase (ugh, I realize I approved it though ;)). > > > Bernd, do you have any testcases? > > It was a missed-optimizatio

Re: [patch] Don't insert pattern statements into the code (was Fix PR tree-optimization/49318)

On Mon, Jun 13, 2011 at 2:43 PM, Ira Rosen wrote: > On 10 June 2011 12:14, Richard Guenther wrote: >> In the end I think we should not generate the pattern stmt during >> pattern matching but only mark the relevant statements with a >> pattern kind.  Say, for each pattern we have a "main" stateme

Re: Ping: [testsuite]: Skip tests for targets with int < 32 bits

On Mon, Jun 13, 2011 at 2:45 PM, Georg-Johann Lay wrote: > Ping #1 for: > http://gcc.gnu.org/ml/gcc-patches/2011-06/msg00746.html Ok. THanks, Richard. > > Georg-Johann Lay: >> >> This patch fixes testsuite failures because the testcases assume >> sizeof(int) >= 4. >> >>        * gcc.c-torture/c

Re: Do not stream BINFO_VIRTUALs to ltrans unit

On Mon, Jun 13, 2011 at 2:54 PM, Jan Hubicka wrote: > Hi, > by accident I noticed that BINFO_VIRTUALs streaming is really expensive. It > about doubles amount of IL and types streamed by Mozilla. > > One obvious optimization is to not stream into ltrans unit where it is > too late to do any useful

Re: [4.6 PATCH] Workaround for stack slot sharing problems with unrolling (PR fortran/49103)

On Mon, Jun 13, 2011 at 10:38 PM, Jakub Jelinek wrote: > On Tue, Jun 07, 2011 at 12:24:06PM +0200, Richard Guenther wrote: >> Probably easier and more complete to do >> >>             if (lhs && TREE_CODE (lhs) != SSA_NAME) >>               { >>                  tree base = get_base_address (lhs);

Re: [PATCH, PR 49089] Don't split AVX256 unaligned loads by default on bdver1 and generic

On Tue, Jun 14, 2011 at 1:59 AM, Fang, Changpeng wrote: > Hi, > > The patch ( http://gcc.gnu.org/ml/gcc-patches/2011-02/txt00059.txt ) which > introduces splitting avx256 unaligned loads. > However, we found that it causes significant regressions for cpu2006 ( > http://gcc.gnu.org/bugzilla/show_

Re: [google] Add intermediate text format for gcov (issue4595053)

On Tue, Jun 14, 2011 at 8:14 AM, Sharad Singhai wrote: > This patch adds an intermediate gcov text format which does not require > source code. This format can be used by lcov or other tools. > > I have bootstrapped it on x86 and all tests pass. Okay for main? I think there should be either a spe

Re: [PATCH, PR 49089] Don't split AVX256 unaligned loads by default on bdver1 and generic

On Tue, Jun 14, 2011 at 12:13:47PM +0200, Richard Guenther wrote: > On Tue, Jun 14, 2011 at 1:59 AM, Fang, Changpeng > wrote: > > The patch ( http://gcc.gnu.org/ml/gcc-patches/2011-02/txt00059.txt ) which > > introduces splitting avx256 unaligned loads. > > However, we found that it causes signi

Re: [Patch, AVR]: Fix PR46779

Denis Chertykov schrieb: > 2011/6/13 Georg-Johann Lay : >> So you think is is pointless/discouraged to give a more realistic >> description of AVR addressing be means of MODE_CODE_BASE_REG_CLASS (instead >> of BASE_REG_CLASS) resp. REGNO_MODE_CODE_OK_FOR_BASE_P? >> >>> Look carefully at `out_movqi_

Re: Ping^5: Re: Updated^2: RFA: Fix middle-end/46500 (void * encapsulated)

On Tue, Jun 14, 2011 at 11:40 AM, Joern Rennecke wrote: > Except or the fortran/java bits (committed), this patch hasn't been > reviewed for five weeks: > http://gcc.gnu.org/ml/gcc-patches/2011-05/msg00582.html A patch doing s/CUMULATIVE_ARGS*/cumulative_args_t/ only is ok. Posting compressed at

Re: [patch] Don't insert pattern statements into the code (was Fix PR tree-optimization/49318)

On 14 June 2011 13:02, Richard Guenther wrote: > On Mon, Jun 13, 2011 at 2:43 PM, Ira Rosen wrote: >> On 10 June 2011 12:14, Richard Guenther wrote: >>> In the end I think we should not generate the pattern stmt during >>> pattern matching but only mark the relevant statements with a >>> pattern

Re: Ping: The TI C6X port

Ping^4 for the C6X port. > Additional preliminary scheduler tweaks: > http://gcc.gnu.org/ml/gcc-patches/2011-05/msg02408.html > > Allow alternatives in attr "predicable": > http://gcc.gnu.org/ml/gcc-patches/2011-06/msg00094.html > > regrename across basic block boundaries: > http://gcc.gnu.org/m

Re: Ping^5: Re: Updated^2: RFA: Fix middle-end/46500 (void * encapsulated)

Quoting Richard Guenther : On Tue, Jun 14, 2011 at 11:40 AM, Joern Rennecke wrote: Except or the fortran/java bits (committed), this patch hasn't been reviewed for five weeks: http://gcc.gnu.org/ml/gcc-patches/2011-05/msg00582.html A patch doing s/CUMULATIVE_ARGS*/cumulative_args_t/ only is

Re: [PATH] PR/49139 fix always_inline failures diagnostics

Unfortunately still not satisfactory, I've been testing it against a few packages, and I notice excessive warnings with the use of __typeof (__error) that doesn't propagate the inline keyword. For instance, a reduced use extracted from the glibc extern __inline __attribute__ ((__always_inline__

Re: [patch] Don't insert pattern statements into the code (was Fix PR tree-optimization/49318)

On Tue, Jun 14, 2011 at 12:38 PM, Ira Rosen wrote: > On 14 June 2011 13:02, Richard Guenther wrote: >> On Mon, Jun 13, 2011 at 2:43 PM, Ira Rosen wrote: >>> On 10 June 2011 12:14, Richard Guenther wrote: In the end I think we should not generate the pattern stmt during pattern matchin

Re: Ping^5: Re: Updated^2: RFA: Fix middle-end/46500 (void * encapsulated)

On Tue, Jun 14, 2011 at 1:16 PM, Joern Rennecke wrote: > Quoting Richard Guenther : > >> On Tue, Jun 14, 2011 at 11:40 AM, Joern Rennecke >> wrote: >>> >>> Except or the fortran/java bits (committed), this patch hasn't been >>> reviewed for five weeks: >>> http://gcc.gnu.org/ml/gcc-patches/2011-0

Re: [Patch, AVR]: Fix PR46779

2011/6/14 Georg-Johann Lay : > Denis Chertykov schrieb: >> 2011/6/13 Georg-Johann Lay : >>> So you think is is pointless/discouraged to give a more realistic >>> description of AVR addressing be means of MODE_CODE_BASE_REG_CLASS (instead >>> of BASE_REG_CLASS) resp. REGNO_MODE_CODE_OK_FOR_BASE_P? >

[PATCH] sel-sched: Avoid placing bookkeeping code above a fence (PR49349)

Hello, Quoting myself from the PR audit trail, It's a rare bug in sel-sched: we fail to schedule some code in non-pipelining mode. The root cause is that we put bookkeeping instructions above a fence that is placed on the last insn (uncond. jump) of the bookkeeping block. We could either make s

Re: [patch] Don't insert pattern statements into the code (was Fix PR tree-optimization/49318)

On 14 June 2011 14:27, Richard Guenther wrote: >>> >>>   /* Mark the stmts that are involved in the pattern. */ >>> -  gsi_insert_before (&si, pattern_stmt, GSI_SAME_STMT); >>>   set_vinfo_for_stmt (pattern_stmt, >>>                      new_stmt_vec_info (pattern_stmt, loop_vinfo, NULL)); >>> +

Re: [patch] Don't insert pattern statements into the code (was Fix PR tree-optimization/49318)

On Tue, Jun 14, 2011 at 1:38 PM, Ira Rosen wrote: > On 14 June 2011 14:27, Richard Guenther wrote: >   /* Mark the stmts that are involved in the pattern. */ -  gsi_insert_before (&si, pattern_stmt, GSI_SAME_STMT);   set_vinfo_for_stmt (pattern_stmt,                      

Re: Ping^5: Re: Updated^2: RFA: Fix middle-end/46500 (void * encapsulated)

On 06/14/2011 01:29 PM, Richard Guenther wrote: > On Tue, Jun 14, 2011 at 1:16 PM, Joern Rennecke wrote: >> Quoting Richard Guenther : >> >>> On Tue, Jun 14, 2011 at 11:40 AM, Joern Rennecke >>> wrote: Except or the fortran/java bits (committed), this patch hasn't been reviewed for

Fix dealII LTO link error

Hi, this patch solves problem with DealII and WHOPR. The code to handle comdat groups was written with assumption that everything in the group is COMDAT that is not always true. Bootstrapped/regtested x86_64-linux, comitted. Honza * cgraph.c (cgraph_make_decl_local): Handle DECL_ONE_ON

Re: Ping^5: Re: Updated^2: RFA: Fix middle-end/46500 (void * encapsulated)

Quoting Bernd Schmidt : I'm not getting the point of the use of attribute((transparent_union)). Without that attribute, lots of ABIs add a lot of overhead for function argument and return value passing. E.g. instead of putting the argument in a register, put it on the stack, and place a point

Re: Cgraph alias reorg 8/14 (ipa-cp and ipa-prop update)

> > Index: ipa-cp.c > > === > > --- ipa-cp.c(revision 174905) > > +++ ipa-cp.c(working copy) > > @@ -818,7 +828,7 @@ ipcp_iterate_stage (void) > > /* Some lattices have changed from IPA_TOP to IPA_BOTTOM. > >

Re: [PATCH, PR 49089] Don't split AVX256 unaligned loads by default on bdver1 and generic

On Tue, Jun 14, 2011 at 3:16 AM, Jakub Jelinek wrote: > On Tue, Jun 14, 2011 at 12:13:47PM +0200, Richard Guenther wrote: >> On Tue, Jun 14, 2011 at 1:59 AM, Fang, Changpeng >> wrote: >> > The patch ( http://gcc.gnu.org/ml/gcc-patches/2011-02/txt00059.txt ) which >> > introduces splitting avx25

PING^4 APPROVED patch for AMD64 targets running GNU/kFreeBSD, anyone?

This patch for AMD64 targets running GNU/kFreeBSD has been approved already, would anyone be so kind to commit it? I'm afraid I don't have write perms currently. See: http://gcc.gnu.org/ml/gcc-patches/2011-06/msg00884.html Thank you very much :-) 2011/6/10 Richard Henderson : > On 06/10/2011 01

Re: Ping^5: Re: Updated^2: RFA: Fix middle-end/46500 (void * encapsulated)

On 06/14/2011 02:53 PM, Joern Rennecke wrote: > Quoting Bernd Schmidt : > >> I'm not getting the point of the use of attribute((transparent_union)). > > Without that attribute, lots of ABIs add a lot of overhead for function > argument and return value passing. * These functions are not hotspots

Re: [Design notes, RFC] Address-lowering prototype design (PR46556)

On Fri, Jun 10, 2011 at 5:11 PM, William J. Schmidt wrote: > On Tue, 2011-06-07 at 16:49 +0200, Richard Guenther wrote: >> On Tue, Jun 7, 2011 at 4:14 PM, William J. Schmidt >> wrote: > > > >> >> > Loss of aliasing information >> >> > >> >> > The most serious problem

[testsuite] Require lto support in g++.dg/torture/pr48954.C

The new g++.dg/torture/pr48954.C testcase FAILs on alpha-dec-osf5.1b: FAIL: g++.dg/torture/pr48954.C -O0 (test for excess errors) Excess errors: cc1plus: error: LTO support has not been enabled in this configuration The following test fixes this, tested with the appropriate runtest invocation,

Re: Dump before flag

On Fri, Jun 10, 2011 at 8:44 PM, Xinliang David Li wrote: > This is the revised patch as suggested. > > How does it look? } +static void +execute_function_dump (void *data ATTRIBUTE_UNUSED) function needs a comment. Ok with that change. Please always specify how you tested the patch - the pa

Re: Ping^5: Re: Updated^2: RFA: Fix middle-end/46500 (void * encapsulated)

Quoting Bernd Schmidt : If the point of your ENABLE_CHECKING machinery (which I also don't really understand) is to avoid exactly that kind of bug, then the ENABLE_CHECKING code should go away along with the use of transparent_union. No, it does a lot more than that. It gives a sanity check t

Re: [Design notes, RFC] Address-lowering prototype design (PR46556)

On Tue, 2011-06-14 at 15:39 +0200, Richard Guenther wrote: > On Fri, Jun 10, 2011 at 5:11 PM, William J. Schmidt > wrote: > > On Tue, 2011-06-07 at 16:49 +0200, Richard Guenther wrote: > >> On Tue, Jun 7, 2011 at 4:14 PM, William J. Schmidt > >> wrote: > > > > > > > >> >> > Loss of aliasing info

Fix comdat unsharing

Hi, cgraph_address_taken_from_non_vtable_p was written with asumption that all references to functions take addresses. This is not true for aliases. Bootstrapped/regtested x86_64-linux, comitted. Honza Index: ChangeLog === --- Cha

Re: [PATCH] Only run pr48377.c testcase on i?86/x86_64

> Well, Steve has a patch for non_strict_align effective_target > in http://gcc.gnu.org/ml/gcc-patches/2011-06/msg00673.html > (with s/strict_align/non_strict_align/g ), I was hoping it would be > reviewed and I'd just adjust the testcase to use it as well. Would it be applied to the 4.6 branch as

[build, libgcc] Correctly apply c_flags in shared-object.mk

When I first did a Solaris 11/x86 bootstrap with gld after checking in my ENABLE_EXECUTE_STACK patch, I found that several acats and gnat.dg tests were failing. This hadn't happened with Sun ld. Reghunting revealed that this had been introduced by that patch. Fortunately, not the code itself was

Re: Cgraph alias reorg 13/14 (disable inlining functions called once at -O0

> I think we also suggested at some point that -O1 optimizations > shouldn't interfere with debugging too much. But if it is what we did before > it's certainly fine. FWIW we have some evidences that -finline-functions-called-once really help at -O1 in terms of performances (with the 4.5 back-en

Re: [PATCH, PR43864] Gimple level duplicate block cleanup.

On Fri, Jun 10, 2011 at 6:54 PM, Tom de Vries wrote: > Hi Richard, > > thanks for the review. > > On 06/08/2011 11:55 AM, Richard Guenther wrote: >> On Wed, Jun 8, 2011 at 11:42 AM, Tom de Vries wrote: >>> Hi Richard, >>> >>> I have a patch for PR43864. The patch adds a gimple level duplicate blo

[v3] Use noexcept in and tempbuf

Hi, tested x86_64-linux, committed. Paolo. /// 2011-06-14 Paolo Carlini * include/std/functional: Use noexcept. * include/bits/stl_tempbuf.h: Likewise. Index: include/std/functional === --- inclu

Re: PATCH [1/n]: Prepare x32: PR middle-end/47364: internal compiler error: in emit_move_insn, at expr.c:3355

On Sun, Jun 12, 2011 at 6:28 PM, H.J. Lu wrote: > On Sun, Jun 12, 2011 at 7:33 AM, H.J. Lu wrote: >> On Sun, Jun 12, 2011 at 7:00 AM, H.J. Lu wrote: >>> On Sun, Jun 12, 2011 at 6:50 AM, Richard Guenther >>> wrote: On Sun, Jun 12, 2011 at 3:18 PM, H.J. Lu wrote: > On Sun, Jun 12, 2011

Re: [Design notes, RFC] Address-lowering prototype design (PR46556)

On Tue, Jun 14, 2011 at 4:18 PM, William J. Schmidt wrote: > On Tue, 2011-06-14 at 15:39 +0200, Richard Guenther wrote: >> On Fri, Jun 10, 2011 at 5:11 PM, William J. Schmidt >> wrote: >> > On Tue, 2011-06-07 at 16:49 +0200, Richard Guenther wrote: >> >> On Tue, Jun 7, 2011 at 4:14 PM, William J.

Re: RFC: Fix GCSE exp_equiv_p on MEMs with different MEM_ATTRS (PR rtl-optimization/49390)

On Tue, Jun 14, 2011 at 11:49:08AM +0200, Richard Guenther wrote: > So I'd say we revert your patch for now and if somebody feels like > implementing the above ... Ok, here is what I've bootstrapped/regtested on x86_64-linux and i686-linux and committed to trunk and 4.6 branch: 2011-06-14 Jakub

Unreviewed libffi patch

The following patch has remained unreviewed for a week: [libffi] Fix libffi.call/huge_struct.c on Tru64 UNIX http://gcc.gnu.org/ml/gcc-patches/2011-06/msg00644.html It needs a libffi maintainer or global reviewer. Thanks. Rainer -- --

Re: PING^4 APPROVED patch for AMD64 targets running GNU/kFreeBSD, anyone?

Hello! > This patch for AMD64 targets running GNU/kFreeBSD has been approved > already, would anyone be so kind to commit it? I'm afraid I don't have > write perms currently. I have committed your patch to SVN mainline after bootstrapping it on x86_64-pc-linux-gnu. Thanks, Uros.

RFA PR middle-end/48770

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 This version incorporates suggestions from Bernd. Basically we have reload1.c set reload_completed internally rather than deferring it into ira.c. That allows the call to reload() to return whether or not a DCE pass is desirable at the end of reload

Re: Unreviewed libffi patch

On 14.06.11 17:22, Rainer Orth wrote: The following patch has remained unreviewed for a week: [libffi] Fix libffi.call/huge_struct.c on Tru64 UNIX http://gcc.gnu.org/ml/gcc-patches/2011-06/msg00644.html It needs a libffi maintainer or global reviewer. From the test suite pov

Re: Unreviewed libffi patch

On 06/14/2011 04:22 PM, Rainer Orth wrote: > The following patch has remained unreviewed for a week: I think it wasn't cc'd to libffi-disc...@sourceware.org > [libffi] Fix libffi.call/huge_struct.c on Tru64 UNIX > http://gcc.gnu.org/ml/gcc-patches/2011-06/msg00644.html > > It needs

[PATCH] Ensure incoming location is available in debug info for parameters (PR debug/49382)

Hi! As detailed in the PR, when gdb attempts to print originally passed values to parameters instead of current values using call site info, if the parameter is modified already before the first real instruction in the function, it will find there already the modified value. E.g. void foo (int x)

Re: [testsuite]: Skip tests for targets with int < 32 bits

On Jun 14, 2011, at 2:20 AM, Georg-Johann Lay wrote: > testsuite/ > > * gcc.c-torture/execute/cmpsi-2.c: Undo 172757. Please always include the PR number in the changelog entries when there is one. This autolinks the work to the PR. Use the exact formatting found in the changelog file.

Re: [PATCH] Only run pr48377.c testcase on i?86/x86_64

On Tue, Jun 14, 2011 at 04:52:18PM +0200, Eric Botcazou wrote: > > Well, Steve has a patch for non_strict_align effective_target > > in http://gcc.gnu.org/ml/gcc-patches/2011-06/msg00673.html > > (with s/strict_align/non_strict_align/g ), I was hoping it would be > > reviewed and I'd just adjust th

Re: Dump before flag

On Tue, Jun 14, 2011 at 6:58 AM, Richard Guenther wrote: > On Fri, Jun 10, 2011 at 8:44 PM, Xinliang David Li wrote: >> This is the revised patch as suggested. >> >> How does it look? > >  } > > +static void > +execute_function_dump (void *data ATTRIBUTE_UNUSED) > > function needs a comment. > >

PATCH [6/n]: Prepare x32: PR middle-end/47449: Don't propagate hard register non-local goto save area

Hi, RTL-based forward propagation pass shouldn't propagate hard register. OK for trunk? Thanks. H.J. --- 2011-06-14 H.J. Lu PR middle-end/47449 * fwprop.c (forward_propagate_subreg): Don't propagate hard register nor zero/sign extended hard register. diff --git a/gc

Re: Unreviewed libffi patch

Andrew Haley writes: > On 06/14/2011 04:22 PM, Rainer Orth wrote: >> The following patch has remained unreviewed for a week: > > I think it wasn't cc'd to libffi-disc...@sourceware.org Right, I hadn't known/had forgotten about that since all my libffi fixes happen in GCC context. I'd only Cc'ed

PATCH [7/n]: Prepare x32: Use Use long long builtin for x86-64

Hi, long may be 32bit for x86-64. But long long is always 64bit. This patch uses long long builtin for 64bit. OK for trunk? Thanks. H.J. --- 2011-06-14 H.J. Lu * longlong.h (count_leading_zeros): Use long long builtin for x86-64. (count_trailing_zeros): Likewise.

RFA minor DF cleanup

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 As I've noted in prior messages; I'm looking to improve our path isolation to improve code generation and reduce false positives from warnings. The patch that's been in my queue for some time now (and I suspect it's the final patch to our current imp

Re: [Design notes, RFC] Address-lowering prototype design (PR46556)

On Tue, 2011-06-14 at 17:21 +0200, Richard Guenther wrote: > On Tue, Jun 14, 2011 at 4:18 PM, William J. Schmidt > wrote: > > On Tue, 2011-06-14 at 15:39 +0200, Richard Guenther wrote: > >> On Fri, Jun 10, 2011 at 5:11 PM, William J. Schmidt > >> wrote: > >> > On Tue, 2011-06-07 at 16:49 +0200, R

[google] backport r174930 to google/main

Backported r174930 to google/main. David

Re: [PATCH] Ensure incoming location is available in debug info for parameters (PR debug/49382)

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 06/14/11 09:51, Jakub Jelinek wrote: > Hi! > > As detailed in the PR, when gdb attempts to print originally passed > values to parameters instead of current values using call site info, > if the parameter is modified already before the first real i

Re: PATCH [1/n]: Prepare x32: PR middle-end/47364: internal compiler error: in emit_move_insn, at expr.c:3355

On Tue, Jun 14, 2011 at 8:11 AM, Richard Guenther wrote: > On Sun, Jun 12, 2011 at 6:28 PM, H.J. Lu wrote: >> On Sun, Jun 12, 2011 at 7:33 AM, H.J. Lu wrote: >>> On Sun, Jun 12, 2011 at 7:00 AM, H.J. Lu wrote: On Sun, Jun 12, 2011 at 6:50 AM, Richard Guenther wrote: > On Sun, Jun

Re: Improve DSE in the presence of calls

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 05/10/11 13:18, Easwaran Raman wrote: >>> I am not sure I understand the problem here. If there is a wild read >>> from asm, the instruction has the wild_read flag set. The if statement >>> checks if that flag is set and if so it clears the bitmap

Re: Create common hooks structure shared between driver and cc1

On Wed, May 25, 2011 at 12:21 PM, Joseph S. Myers wrote: > Here is a revised version of my patch > to create > the common hooks structure.  Tested in the same way as the original > patch.  OK to commit? > > 2011-05-25  Joseph Myers   > >  

Re: Move option-related hooks to common structure

On Fri, May 27, 2011 at 9:13 AM, Joseph S. Myers wrote: > > 2011-05-27  Joseph Myers   > >        * target-def.h (TARGET_HAVE_NAMED_SECTIONS): Move to >        common/common-target-def.h. >        * target.def (default_target_flags, handle_option, >        supports_split_stack, optimization_table,

C++ PATCH for c++/49290 (ICE regression on *(T*)(ar+10))

In this testcase, we were hitting an assert that I put in to make sure that fold_indirect_ref_1 was doing its job and folding everything that ought to be folded. But fold_indirect_ref_1 doesn't want to mess with type identity, so it can't fold if, say, the array element type has different cv-q

C++ PATCH for c++/49369 (wrong cv-quals on base member in unevaluated context)

We were forgetting to propagate cv-quals from 'this' to the result along one code path. Fixed by moving the cv-qual propagation up so it's shared by all code paths. Tested x86_64-pc-linux-gnu, applying to trunk and 4.6. commit a7eeb9dc7b67d159f46e9d8e7976332bd73332ca Author: Jason Merrill Dat

Re: PATCH [7/n]: Prepare x32: Use Use long long builtin for x86-64

On Tue, Jun 14, 2011 at 6:04 PM, H.J. Lu wrote: > long may be 32bit for x86-64. But long long is always 64bit.  This > patch uses long long builtin for 64bit.  OK for trunk? > > Thanks. > > > H.J. > --- > 2011-06-14  H.J. Lu   > >        * longlong.h (count_leading_zeros): Use long long builtin f

C++ PATCH for c++/49117 (error message regression on conversion failure)

PR 49117 complains that the error message given on conversion failure regressed from 4.5 to 4.6 in that it no longer prints the source type. So I've added it back in. While I was at it, I've also tweaked the compiler to also print the typedef-stripped version of a type when appropriate, which

[x32] PATCH: Add GLIBC_DYNAMIC_LINKERX32 to kfreebsd-gnu64.h

Hi, I checked this patch into x32 branch. H.J. --- commit 7cce5a5ab2012d170287e705741ed29828a8af0e Author: H.J. Lu Date: Tue Jun 14 10:40:05 2011 -0700 Add GLIBC_DYNAMIC_LINKERX32 to kfreebsd-gnu64.h. diff --git a/gcc/ChangeLog.x32 b/gcc/ChangeLog.x32 index 64a40a6..afea916 100644 --- a

[testsuite] ARM tests should ignore warning about conflicting switches

Many tests in gcc.target/arm that specify "-march=" fail compilation when multilib flags include "-mcpu=" due to warnings about conflicts in switches, but then go on to pass the remainder of the test. This patch causes some of those tests to ignore that compiler warning; I'll get to the rest later

Re: PATCH [1/n]: Add initial -x32 support

On Sun, Jun 05, 2011 at 12:54:41PM -0700, H.J. Lu wrote: > Hi, > > I'd like to start submitting a series of patches to enable x32: > > https://sites.google.com/site/x32abi/ > > The GCC x32 branch is very stable. There are no unexpected failures in > C, C++, Fortran and Objective C testsuites. S

[v2] Mark noexcept some destructors, add tests

Hi, tested x86_64-linux, committed to mainline. Paolo. 2011-06-14 Paolo Carlini * include/std/valarray (~valarray): Use noexcept. * include/bits/unique_ptr.h (~unique_ptr): Likewise. * testsuite/26_numerics/valarray/noexcept_move_construct.cc

Re: PATCH [7/n]: Prepare x32: Use Use long long builtin for x86-64

On Tue, Jun 14, 2011 at 10:37 AM, Uros Bizjak wrote: > On Tue, Jun 14, 2011 at 6:04 PM, H.J. Lu wrote: > >> long may be 32bit for x86-64. But long long is always 64bit.  This >> patch uses long long builtin for 64bit.  OK for trunk? >> >> Thanks. >> >> >> H.J. >> --- >> 2011-06-14  H.J. Lu   >> >

[testsuite] skip ARM tests if no THUMB support

Fix three ARM tests so they are skipped for multilibs that don't support THUMB. OK for trunk and 4.6? Janis 2011-06-14 Janis Johnson * gcc.target/arm/pr45701-1.c: Require thumb support. * gcc.target/arm/pr45701-2.c: Likewise. * gcc.target/arm/thumb-branch1.c: Likewise.

Re: [testsuite] ARM tests should ignore warning about conflicting switches

On 06/14/2011 10:47 AM, Janis Johnson wrote: > Many tests in gcc.target/arm that specify "-march=" fail compilation > when multilib flags include "-mcpu=" due to warnings about conflicts in > switches, but then go on to pass the remainder of the test. This patch > causes some of those tests to ign

[pph] pph_in_binding_level fixing shadowed_labels read (issue4589054)

We weren't reading in shadowed labels properly. The local variable *sl also turned out to be useless, the compiler just didn't mention it until now as it was "used" by the bad VEC_iterate call. This doesn't fix any currently exposed pph bugs, but does help with me with the patch I'm currently wri

C++ PATCH for c++/49389 (wrong value category for .*)

If the object expression is an rvalue, the result should be as well. Tested x86_64-pc-linux-gnu, applying to trunk. commit 93619457bb3756b091d86a13d1aa72880bb1ac62 Author: Jason Merrill Date: Mon Jun 13 22:19:24 2011 -0400 PR c++/49389 * typeck2.c (build_m_component_ref): Preserve r

fix pr48459

In this pr, during the initialization of the dwarf2 backend, we attempt to cache a translation from a local stack frame address to the CFA. We do this optimistically, hoping to cut down the work later for every local stack frame address that we find in the actual variables dumped. Unfortunately,

[google] Merge r173574 to google/gcc-4_6 to fix an incompatibility between C++98 and C++0x (issue4592057)

In C++0x mode, without this patch, calls to a user-defined trunc() function with an argument in namespace std and a parameter type that has an implicit conversion from the argument's type, cause infinite recursion in std::trunc(). This patch also includes http://gcc.gnu.org/viewcvs/trunk/libstd

Re: [testsuite] ARM tests should ignore warning about conflicting switches

On Jun 14, 2011, at 10:47 AM, Janis Johnson wrote: > Many tests in gcc.target/arm that specify "-march=" fail compilation > when multilib flags include "-mcpu=" due to warnings about conflicts in > switches, but then go on to pass the remainder of the test. > OK for trunk and 4.6? Ok. As usual,

Re: [testsuite] skip ARM tests if no THUMB support

On Jun 14, 2011, at 10:58 AM, Janis Johnson wrote: > Fix three ARM tests so they are skipped for multilibs that don't support > THUMB. OK for trunk and 4.6? Ok.

Re: [pph] pph_in_binding_level fixing shadowed_labels read (issue4589054)

On Tue, Jun 14, 2011 at 13:59, Gabriel Charette wrote: > 2011-06-14  Gabriel Charette   > >        * pph-streamer-in.c (pph_in_binding_level): Fix read >        of shadowed_labels. >        (pph_in_binding_level): Removed *sl. OK, committed as rev 175050. Diego.

Re: [google] Merge r173574 to google/gcc-4_6 to fix an incompatibility between C++98 and C++0x (issue4592057)

On Tue, Jun 14, 2011 at 14:45, Jeffrey Yasskin wrote: > In C++0x mode, without this patch, calls to a user-defined trunc() function > with an argument in namespace std and > a parameter type that has an implicit conversion from the argument's type, > cause infinite recursion in std::trunc(). > >

Re: Dump before flag

Committed after Bootstrapping and regression testing on x86-64/linux. The follow up patch will come soon. Thanks, David On Tue, Jun 14, 2011 at 8:57 AM, Xinliang David Li wrote: > On Tue, Jun 14, 2011 at 6:58 AM, Richard Guenther > wrote: >> On Fri, Jun 10, 2011 at 8:44 PM, Xinliang David Li

Re: [google] Merge r173574 to google/gcc-4_6 to fix an incompatibility between C++98 and C++0x (issue4592057)

On Tue, Jun 14, 2011 at 12:38 PM, Diego Novillo wrote: > On Tue, Jun 14, 2011 at 14:45, Jeffrey Yasskin wrote: >> In C++0x mode, without this patch, calls to a user-defined trunc() function >> with an argument in namespace std and >> a parameter type that has an implicit conversion from the argu

Re: [google] Merge r173574 to google/gcc-4_6 to fix an incompatibility between C++98 and C++0x (issue4592057)

On Tue, Jun 14, 2011 at 15:59, Jeffrey Yasskin wrote: > It's already in trunk, so my impression was that it was going to be > automatically merged to google/main. I only need a manual merge to get > it into our release branches. Yeah, in this case it's not too different since we'll be switching

Re: RFA (fold): PATCH for c++/49290 (folding *(T*)(ar+10))

On Jun 13, 2011, at 3:57 AM, Richard Guenther wrote: > That's not exactly an example - I can't think of how you want or need > to use VIEW_CONVERT_EXPRs to implement said divmod instruction or why > you would need anything special for the _argument_ of said instruction. Oh, I completely misunderst

Re: [PATCH] sel-sched: Avoid placing bookkeeping code above a fence (PR49349)

On 06/14/2011 07:34 AM, Alexander Monakov wrote: Hello, Quoting myself from the PR audit trail, It's a rare bug in sel-sched: we fail to schedule some code in non-pipelining mode. The root cause is that we put bookkeeping instructions above a fence that is placed on the last insn (uncond. jump

[testsuite] (committed) let more ARM tests ignore warnings about conflicting switches

I made other changes to these tests earlier today, then the patch to ignore warnings for conflicting options was approved. I've committed this to trunk. Janis 2011-06-14 Janis Johnson * gcc.target/arm/pr45701-1.c: Ignore warnings about conflicting switches. * gcc.target/arm/p

[testsuite] skip ARM tests if no thumb2 support

These tests apparently require thumb2 support (I don't yet know much about ARM). OK for trunk, and later 4.6? Janis 2011-06-14 Janis Johnson * gcc.target/arm/pr42879.c: Skip if no thumb2 support, ignore compiler warning about switch conflicts. * gcc.target/arm/pr45701-

[PATCH, PR 48613] Don't stream jump functions if there are none

Hi, the patch below fixes PR 48613 which is an ICE with -O0 -findirect-inlining. Rather than adding "&& optimize" here and there, at this place we can easily see whether there is something to do or not by testing ipa_node_params_vector for NULL. And the flag-triggering combinations can -and are

  1   2   >