Re: [RFA/libiberty] Darwin has case-insensitive filesystems

> There's a difference between case preserving and case sensitive, > though, and we really don't have a portable way to detect > case-sensitivity on a per-directory basis, sow how can we do better? That's roughly my thoughts on this issue. It's true that this property is not an OS property, and we

Re: C++ PATCH for c++/49107 (excessive instantiation due to noexcept)

Another testcase attached to 49107 shows that we can't force noexcept instantiation as part of implicitly declaring special member functions; we need to defer their noexcept-specifications as well. While I was working on this I noticed that it's not necessary to save and restore input_location

Re: [RFA/libiberty] Darwin has case-insensitive filesystems

On Jun 15, 2011, at 12:01 AM, DJ Delorie wrote: > >> This is wrong as not all FSs are case insensitive. In fact HFS+ can >> be case sensitive too. I think you need better check than just >> saying all Darwin is case insensitive. This is just like using >> FAT32 on Linux. In fact I think HAVE

Re: Improve DSE in the presence of calls

On Tue, May 10, 2011 at 12:18 PM, Easwaran Raman wrote: > On Tue, May 3, 2011 at 9:40 AM, Easwaran Raman wrote: >> On Mon, May 2, 2011 at 8:37 PM, Jeff Law wrote: >>> -BEGIN PGP SIGNED MESSAGE- >>> Hash: SHA1 >>> >>> On 04/26/11 16:06, Easwaran Raman wrote: >>> > You're right. T

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

On Tue, Jun 14, 2011 at 4:59 PM, Fang, Changpeng wrote: > > >> >> So, is it OK to commit this patch to trunk, and H.J's original patch + this >> to 4.6 branch? > >>I have no problems on -mtune=Bulldozer.  But I object -mtune=generic >>change and did suggest a different approach for -mtune=generic

Stream struct function. (issue4620043)

Save the DECL_STRUCT_FUNCTION(...) field of FUNCTION_DECL. This change factors common functionality with the LTO streamer. Index: gcc/testsuite/ChangeLog.pph 2011-06-14 Lawrence Crowl * g++.dg/pph/x1tmplfunc.cc: Replace ICE xfail with an assembly diff xfail. Index: gcc/cp/Ch

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

> > So, is it OK to commit this patch to trunk, and H.J's original patch + this > to 4.6 branch? >I have no problems on -mtune=Bulldozer. But I object -mtune=generic >change and did suggest a different approach for -mtune=generic. What's your suggested approach for -mtune=generic? My underst

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

On Tue, Jun 14, 2011 at 4:01 PM, Fang, Changpeng wrote: > A similar argument is for software prefetching, which we observed a ~2% > benefit on greyhound (not that much > for Bulldozer). We would also prefer turning on software prefetching at -O3 > for -mtune=generic. Sure, we can put everything

Re: Dump only functions with name matching patterns

Attached the patch. David On Tue, Jun 14, 2011 at 4:21 PM, Xinliang David Li wrote: > This is the second (hopefully the last in the series of dumper > changes) follow-up patch. > > It adds a control so that verbosity of the dump can be greatly reduced > (and hopefully simplify gcc developer's li

Re: Dump only functions with name matching patterns

This is the second (hopefully the last in the series of dumper changes) follow-up patch. It adds a control so that verbosity of the dump can be greatly reduced (and hopefully simplify gcc developer's life a little). For instance: -fdump-tree-dce="foo[0-9]$" to dump IR (and debug trace) only for

Re: Dump before flag

Here is one the of follow up patches: support of -before_preparation, -before, -after, -after_cleanup dump flags. The default dumping behavior does not change at all, but if any one of the above flags is specified, the function IR will be dumped into a file with the corresponding suffix. The enh

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

A similar argument is for software prefetching, which we observed a ~2% benefit on greyhound (not that much for Bulldozer). We would also prefer turning on software prefetching at -O3 for -mtune=generic. --Changprng From: H.J. Lu [hjl.to...@gmail.co

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

On Tue, Jun 14, 2011 at 3:41 PM, Fang, Changpeng wrote: >>It probably should go to the 4.6 branch as well. > > H.J. Lu's original patch that splits unaligned load and store was checked in > gcc 4.7 > trunk. We found that,  splitting unaligned store is beneficial to bdver1, > splitting unaligned

Re: [Patch, AVR]: Fix PR46779

On 06/14/2011 02:29 PM, Georg-Johann Lay wrote: > http://gcc.gnu.org/ml/gcc-patches/2011-06/msg01029.html It does look like a step in the right direction. > I tested on some handcrafted examples and on the code attached to > PR46278. The generated code looked very good and so I started > regressi

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

>It probably should go to the 4.6 branch as well. H.J. Lu's original patch that splits unaligned load and store was checked in gcc 4.7 trunk. We found that, splitting unaligned store is beneficial to bdver1, splitting unaligned load degrades cfp2006 by 1.3% in geomean on Bulldozer. As a result,

Re: [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

[v3] use noexcept in pointer_traits

I missed the "noexcept" qualifier off this function when I added it recently. 2011-06-14 Jonathan Wakely * include/bits/ptr_traits.h (pointer_traits::pointer_to): Use noexcept. Tested x86_64-linux and committed to trunk Index: include/bits/ptr_traits.h

PING: PATCH: PR other/49325: Incorrect target HAVE_INITFINI_ARRAY check

On Wed, Jun 8, 2011 at 9:49 AM, H.J. Lu wrote: > Hi, > > Target HAVE_INITFINI_ARRAY support was added by: > > http://gcc.gnu.org/ml/gcc-patches/2002-11/msg00387.html > > Unfortunately, it checks if host supports init_array/fini_array > sections, not target.  It will generate wrong result for cross

Re: [RFA/libiberty] Darwin has case-insensitive filesystems

> This is wrong as not all FSs are case insensitive. In fact HFS+ can > be case sensitive too. I think you need better check than just > saying all Darwin is case insensitive. This is just like using > FAT32 on Linux. In fact I think HAVE_DOS_BASED_FILE_SYSTEM is > incorrect also for NTFS as i

Re: [RFA/libiberty] Darwin has case-insensitive filesystems

On Tue, Jun 14, 2011 at 2:33 PM, Joel Brobecker wrote: > Hello, > > HFS+, the FS on Darwin, is case insensitive. So this patch adjusts > filename_cmp.c to ignore the casing when comparing filenames on Darwin. This is wrong as not all FSs are case insensitive. In fact HFS+ can be case sensitive t

Re: [RFA/libiberty] Darwin has case-insensitive filesystems

Looks OK to me.

[RFA/libiberty] Darwin has case-insensitive filesystems

Hello, HFS+, the FS on Darwin, is case insensitive. So this patch adjusts filename_cmp.c to ignore the casing when comparing filenames on Darwin. This is visible in GDB when trying to break on a file whose name is, say 'Mixed_Case.adb', but was compiled using 'mixed_case.adb' as the filename. In

Re: [Patch, AVR]: Fix PR46779

Denis Chertykov schrieb: 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_

Re: Ping: The TI C6X port

On 06/06/2011 07:26 AM, Bernd Schmidt wrote: Ping^3 for the C6X port. Now with extra patches: Additional preliminary scheduler tweaks: http://gcc.gnu.org/ml/gcc-patches/2011-05/msg02408.html It is ok for me. Thanks, Bernd. Allow alternatives in attr "predicable": http://gcc.gnu.org/ml/gcc-pa

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

Sorry, Rietveld didn't send out the updated patch along with my mail. Here it is. Sharad 2011-06-14 Sharad Singhai Google Ref 3 * doc/gcov.texi: Document gcov intermediate format. * gcov.c (get_gcov_file_intermediate_name): New function. (output_intermedi

[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

[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-

[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

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

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: [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: [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: 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 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: [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: [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: [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,

[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

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,

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

[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

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

[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: 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   >> >

[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 [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

[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

[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

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

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++/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

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

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,

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: 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: 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: [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

[google] backport r174930 to google/main

Backported r174930 to google/main. David

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

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

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.

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 [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: 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. > >

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: [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.

[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: 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

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

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: 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.

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: 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

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: 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

[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, 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

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

[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: [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

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: [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

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: 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

[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: [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

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

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: [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

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: 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

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)

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

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: [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)); >>> +

[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, 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? >

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] 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: [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__

  1   2   >