[PATCH, i386]: Add castmode mode attribute

Hello! This patch will simplify macroization of AVX2 stuff. No functional changes. 2011-08-06 Uros Bizjak * config/i386/i386.md (ssemodesuffix): Remove V8SI mode. * config/i386/sse.md (castmode): New mode attribute. (avx__): Rename from avx__. Bootstrapped on

Re: [patch, fortran] PR 37721, warn about target > source in TRANSFER

Am 05.08.2011 23:57, schrieb Thomas Koenig: Committed as rev. 177486. Looks like this caused a regression in c_ptr_tests_16.f90. Don't know why, am investigating. Thomas

Re: [build] Move unwinder to toplevel libgcc (v2)

I'm seeing this bootstrap failure on ia64 (configured with --with-system-libunwind): /usr/local/gcc/gcc-20110806/Build/./prev-gcc/g++ -B/usr/local/gcc/gcc-20110806/Build/./prev-gcc/ -B/usr/ia64-suse-linux/bin/ -nostdinc++ -B/usr/local/gcc/gcc-20110806/Build/prev-ia64-suse-linux/libstdc

libobjc: fix for PR/49882 ("class_getSuperClass() returns nil on a newly allocated, but not registered, class")

This patch fixes PR libobjc/49882. Applied to trunk. Thanks Index: libobjc/ChangeLog === --- libobjc/ChangeLog (revision 177503) +++ libobjc/ChangeLog (working copy) @@ -1,3 +1,10 @@ +2011-08-06 Nicola Pero + + PR libob

libobjc: Fix obvious typo in comment

Fixes a typo in a comment in my last patch. Applied to trunk. Thanks Index: ChangeLog === --- ChangeLog (revision 177505) +++ ChangeLog (working copy) @@ -1,5 +1,9 @@ 2011-08-06 Nicola Pero + * class.c (class_getSupe

Re: [build] Move unwinder to toplevel libgcc (v2)

On Friday 05 August 2011 21:48:34 Paolo Bonzini wrote: > On Fri, Aug 5, 2011 at 20:18, Mikael Morin wrote: > > I suppose it is this patch that breaks bootstrap The culprit is indeed r177447. > > Adding a -I flag? I suppose that makes sense even if crtstuff is > moved soon to toplevel libgcc. Ho

Re: [PATCH, testsuite, i386] AVX2 support for GCC

On Thu, Aug 4, 2011 at 11:20 AM, Kirill Yukhin wrote: > During last few months I was working on AVX2 support for GCC. > > Here is a patch which conforms (hopefully) to Spec which can be found at [1] Whoa, mega-patch for review. This will be attacked in stages. 1. Typo fixes to fma_ patterns (and

Re: [PATCH] PR c++/33255 - Support -Wunused-local-typedefs warning

So I finally got back to this and updated the patch according to the comments below. Jason Merrill writes: > On 07/27/2011 01:54 PM, Dodji Seketeli wrote: >> + /* Set of typedefs that are used in this function. */ >> + struct pointer_set_t * GTY((skip)) used_local_typedefs; > > Is there a re

Re: C++ PATCH to allow VLAs with C++0x auto

On 08/05/2011 09:10 PM, Jason Merrill wrote: Paolo asked for GCC to allow deduction of auto from a variable-length array. Since auto doesn't have the issues involved with normal template deduction from VLAs (namely, the type not being link-time constant), this seems reasonable to me. Thanks!

[PATCH, i386]: Simplify frame->save_regs_using_mov calculation.

Hello! No functional changes. 2011-08-06 Uros Bizjak * config/i386/i386.c (ix86_compute_frame_layout): Simplify frame->save_regs_using_mov calculation. Tested on x86_64-pc-linux-gnu {,-m32}, committed to mainline SVN. Uros. Index: i386.c

[patch testsuite]: Adjust gcc.dg/tree-ssa tests for LLP64 target

Hello, this adjusts some testcases for LLP64 target x86_64 mingw. ChangeLog 2011-08-06 Kai Tietz * gcc.dg/tree-ssa/pr23455.c: Adjust testcases for LLP64 for x86_64 mingw target. * gcc.dg/tree-ssa/loop-1.c: Likewise. * gcc.dg/tree-ssa/ssa-store-ccp-2.c: Likewis

PATCH: Add testcases for PRs 48084/49504/49860

Hi, I checked in this patch to add testcases for PRs 48084/49504/49860. H.J. Index: gcc.target/i386/pr49504.c === --- gcc.target/i386/pr49504.c (revision 0) +++ gcc.target/i386/pr49504.c (revision 0) @@ -0,0 +1,18 @@ +/* PR targe

libobjc: Fix PR libobjc/50002 ("class_replaceMethod does not work on class methods")

This patch fixes PR libobjc/50002. The problem was that replacing an existing class method wouldn't work because the messaging tables weren't being refreshed for class methods when a method was replaced. This patch also includes three other related changes: * a new couple of comprehensive tes

PATCH: Add testcases for PRs 47766/47715

Hi, I checked in this patch to add testcases for PRs 47766/47715. H.J. --- Index: gcc.dg/pr47766.c === --- gcc.dg/pr47766.c(revision 0) +++ gcc.dg/pr47766.c(revision 0) @@ -0,0 +1,13 @@ +/* { dg-do compile } */ +/* { dg-opti

Re: [build] Move unwinder to toplevel libgcc (v2)

On 08/06/2011 12:43 PM, Mikael Morin wrote: On Friday 05 August 2011 21:48:34 Paolo Bonzini wrote: On Fri, Aug 5, 2011 at 20:18, Mikael Morin wrote: I suppose it is this patch that breaks bootstrap The culprit is indeed r177447. Adding a -I flag? I suppose that makes sense even if crtstuf

PATCH: Add testcases for PRs 47449/47446

Hi, I checked in this patch to add testcases for PRs 47449/47446. H.J. Index: gcc.target/i386/pr47449.c === --- gcc.target/i386/pr47449.c (revision 0) +++ gcc.target/i386/pr47449.c (revision 0) @@ -0,0 +1,12 @@ +/* { dg-do compil

Re: PING: PATCH: PR target/46770: Use .init_array/.fini_array sections

PING. On Fri, Jul 22, 2011 at 7:06 AM, H.J. Lu wrote: > On Fri, Jul 22, 2011 at 7:00 AM, H.J. Lu wrote: >> On Fri, Jul 22, 2011 at 6:03 AM, H.J. Lu wrote: >>> On Fri, Jul 22, 2011 at 5:30 AM, Jakub Jelinek wrote: On Fri, Jul 22, 2011 at 04:59:28AM -0700, H.J. Lu wrote: > @@ -2660,6 +2

Re: [PATCH] Handle BIT_NOT_EXPR in VRP

On 08/05/2011 02:31 PM, Richard Guenther wrote: This extends VRP to handle BIT_NOT_EXPR by composing ~X as -X - 1 (which should give us anti-range handling for free). Just a small detail, but why not -1 - X which saves the NEGATE_EXPR? :) Paolo

PATCH: Add testcases for PRs 47727/47372/47715

Hi, I checkd in this patch to add testcases for PRs 47727/47372/47715. H.J. -- Index: gcc.dg/pr47372-2.c === --- gcc.dg/pr47372-2.c (revision 0) +++ gcc.dg/pr47372-2.c (revision 0) @@ -0,0 +1,17 @@ +/* { dg-do compile } */ +/* { dg

PATCH: Add testcases for PR 47381

Hi, I checked in this patch to add testcases for PR 47381. H.J. --- Index: gcc.target/i386/pr47381.c === --- gcc.target/i386/pr47381.c (revision 0) +++ gcc.target/i386/pr47381.c (revision 0) @@ -0,0 +1,13 @@ +/* { dg-do compile }

Re: [build] Move unwinder to toplevel libgcc (v2)

On Saturday 06 August 2011 16:31:48 Paolo Bonzini wrote: > Can you try this instead? It works. Thanks Mikael

Re: [build] Move unwinder to toplevel libgcc (v2)

On 08/06/2011 05:07 PM, Mikael Morin wrote: On Saturday 06 August 2011 16:31:48 Paolo Bonzini wrote: Can you try this instead? It works. Thanks Committed, thanks. Paolo

[patch, Fortran, committed] Fix PR 50004

Hello world, I have committed the attached patch as obvious after regression-testing. The problem was that gfc_typenode_for_spec was clobbering the typespec for the ISO C types by converting them to integer. Don't know why I hadn't seen this before. Regards Thomas 2011-08-06 Thoma

Re: [Patch, Fortran, OOP] PR 49638: [OOP] length parameter is ignored when overriding type bound character functions with constant length.

Hi Janus, 2011/8/5 Mikael Morin: On Friday 05 August 2011 23:02:33 Thomas Koenig wrote: The extra argument controls whether we check variable symbols for equality or just their names. For the overriding checks it is sufficient to check for names, because the arguments of the overriding procedu

Re: [Patch, Fortran, OOP] PR 49638: [OOP] length parameter is ignored when overriding type bound character functions with constant length.

On Saturday 06 August 2011 17:39:06 Thomas Koenig wrote: > > As Thomas mentions, certain cases are still not handled correctly > > (e.g. A+B+C vs C+B+A, and other mathematical transformations), but I > > hope they are sufficiently exotic (so that we can wait for bug reports > > to roll in). In addi

Re: [Patch, Fortran, OOP] PR 49638: [OOP] length parameter is ignored when overriding type bound character functions with constant length.

>> It is wrong to assume that expressions are unequal because we cannot >> prove they are equal, with all the limitations that we currently >> have.  This will introduce rejects-valid bugs. > In the PR at > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49638#c8 > I quote the standard: > > 4.5.7.3 (ty

Re: [Patch, Fortran, OOP] PR 49638: [OOP] length parameter is ignored when overriding type bound character functions with constant length.

Hi Thomas, >> The string length expressions of overridden procedures have to be >> identical, but with exchanged dummy arguments. Since the dummy >> arguments of overridden procedures must have the same name as in the >> base procedure, it is sufficient the check for equal names. Checking >> for

Re: [Patch, Fortran, OOP] PR 49638: [OOP] length parameter is ignored when overriding type bound character functions with constant length.

>> This lets me think that one should enable the comparison by name for dummy >> arguments only. Other variables should compare normally. > > Good point. I have attached a new version of the patch, which adds > this constraint, plus: > > 1) I have moved 'check_typebound_override' to interface.c and

Re: [Patch, Fortran, OOP] PR 49638: [OOP] length parameter is ignored when overriding type bound character functions with constant length.

Am 06.08.2011 18:16, schrieb Janus Weil: without any regressions. Can anybody think of a case where the names can be > identical, but the variables different? (I can't). Well, I'd say this can only happen if both variables reside in different namespaces (i.e. different modules or procedures).

Re: [Patch, Fortran, OOP] PR 49638: [OOP] length parameter is ignored when overriding type bound character functions with constant length.

On Saturday 06 August 2011 18:06:58 Janus Weil wrote: > >> It is wrong to assume that expressions are unequal because we cannot > >> prove they are equal, with all the limitations that we currently > >> have. This will introduce rejects-valid bugs. > > > > In the PR at > > http://gcc.gnu.org/bugz

Re: [Patch, Fortran, OOP] PR 49638: [OOP] length parameter is ignored when overriding type bound character functions with constant length.

>>> without any regressions.  Can anybody think of a case where the names can >>> be >>> >  identical, but the variables different?  (I can't). >> >> Well, I'd say this can only happen if both variables reside in >> different namespaces (i.e. different modules or procedures). >> > > gfc_are_identic

[PATCH, i386]: Update gcc.target/i386/sse-{22,23}.c

Hello! 2011-08-06 Uros Bizjak * gcc.target/i386/sse-22.c (dg-options): Add -march=k8. (pragma GCC target): Add avx, fma4, lzcnt and bmi options. * gcc.target/i386/sse-23.c (pragma GCC target): Add avx, fma4, lzcnt and bmi options. Tested on x86_64-pc-linux-gnu,

Re: [Patch, Fortran, OOP] PR 49638: [OOP] length parameter is ignored when overriding type bound character functions with constant length.

> Here is a variant of the original test case from the PR, which will be > accepted if we only check for names (but it should actually be > rejected): > > > module world > >  implicit none > >  type :: world_1 >   contains >     procedure, nopass :: string => w1_string >  end type > >  type, extend

Re: [PATCH 9/9] dwarf2cfi: Generate and connect traces.

On Thu, Jul 14, 2011 at 4:07 PM, Richard Henderson wrote: > This kinda-sorta corresponds to Bernd's 007-dw2cfi patch.  Certainly > the same concepts of splitting the instruction stream into extended > basic blocks is the same.  This patch does a bit better job with the > documentation.  Also, I'm

Re: [PATCH, libiberty]: Check result of fwrite in test-expandargv.c

On Fri, Aug 5, 2011 at 11:51 PM, Uros Bizjak wrote: > My system warns during compilation of libiberty test-expandargv.c test: > > gcc -DHAVE_CONFIG_H -g -O2 -I.. > -I../../../gcc-svn/trunk/libiberty/testsuite/../../include > -DHAVE_CONFIG_H -I.. -o test-expandargv \ >        ../../../gcc-svn/trun

Re: [Patch, Fortran, OOP] PR 49638: [OOP] length parameter is ignored when overriding type bound character functions with constant length.

On Saturday 06 August 2011 19:10:09 Janus Weil wrote: > Now, if Thomas says it's fine for the other cases, too, then it seems > we can really get away with a much simpler patch. Hope we're not > missing anything, though ... > What about this case: two module variables from two different modules?

Re: [Patch, Fortran, OOP] PR 49638: [OOP] length parameter is ignored when overriding type bound character functions with constant length.

2011/8/6 Mikael Morin : > On Saturday 06 August 2011 19:10:09 Janus Weil wrote: >> Now, if Thomas says it's fine for the other cases, too, then it seems >> we can really get away with a much simpler patch. Hope we're not >> missing anything, though ... >> > > What about this case: two module variab

Re: [Patch, Fortran, OOP] PR 49638: [OOP] length parameter is ignored when overriding type bound character functions with constant length.

On Sat, Aug 06, 2011 at 06:45:36PM +0200, Mikael Morin wrote: > On Saturday 06 August 2011 18:06:58 Janus Weil wrote: > > >> It is wrong to assume that expressions are unequal because we cannot > > >> prove they are equal, with all the limitations that we currently > > >> have. This will introduce

[PATCH, alpha]: Fix PR target/50001, ICE in reload_combine_note_use, at postreload.c:1538

Hello! The problem was that exception_receiver pattern recorded a stack slot that referred to virtual-stack-vars. Recent changes moved generation of exception landing pads after virtuals were instantiated, so in bbpart pass we emitted: (insn 262 266 263 51 (unspec_volatile [ (mem/c:DI

Re: [build] Move unwinder to toplevel libgcc (v2)

Thanks again for doing this. Rainer Orth writes: > * config.host (unwind_header): New variable. > (*-*-freebsd*): Set tmake_file to t-eh-dw2-dip. > (*-*-linux*, frv-*-*linux*, *-*-kfreebsd*-gnu, *-*-knetbsd*-gnu, > *-*-gnu*): Likewise, also for *-*-kopensolaris*-gnu. >

Re: [build] Move sync, mips16.S to toplevel libgcc

Rainer Orth writes: > Rainer Orth writes: >> Another easy part in the toplevel libgcc move was sync.c and related >> stuff. While doing this, it turned out to be easier to move the rest of >> gcc/config/mips/t-libgcc-mips16 rather than leave it behind. >> >> The patch is untested except for incl

Re: [Patch, Fortran, OOP] PR 49638: [OOP] length parameter is ignored when overriding type bound character functions with constant length.

Hi Janus, + /* Check string length. */ + if (proc_target->result->ts.type == BT_CHARACTER + && proc_target->result->ts.u.cl&& old_target->result->ts.u.cl + && gfc_dep_compare_expr (proc_target->result->ts.u.cl->length, + old_target->resu

Re: [Patch, Fortran, OOP] PR 49638: [OOP] length parameter is ignored when overriding type bound character functions with constant length.

Hi Thomas, >> +      /* Check string length.  */ >> +      if (proc_target->result->ts.type == BT_CHARACTER >> +       &&  proc_target->result->ts.u.cl&&  old_target->result->ts.u.cl >> +       &&  gfc_dep_compare_expr (proc_target->result->ts.u.cl->length, >> +                                  ol

Re: [Patch, Fortran, OOP] PR 49638: [OOP] length parameter is ignored when overriding type bound character functions with constant length.

Am 06.08.2011 21:26, schrieb Janus Weil: Hi Thomas, + /* Check string length. */ + if (proc_target->result->ts.type == BT_CHARACTER +&&proc_target->result->ts.u.cl&&old_target->result->ts.u.cl +&&gfc_dep_compare_expr (proc_target->result->ts.u.cl->length, +

Re: [Patch, Fortran, OOP] PR 49638: [OOP] length parameter is ignored when overriding type bound character functions with constant length.

>> For the overriding check, we don't care about which expr is larger, we >> want to know whether they are the same or not. So, in many cases we >> will just get a warning, although we definitely know that the expr's >> are different. >> >> Example: Differing expr_type, e.g. one procedure has len=3

[PATCH, alpha]: Fix g++.dg/opt/devirt2.C, use specific scan pattern for alpha*-*-*

Hello! 2011-08-06 Uros Bizjak PR testsuite/48727 * g++.dg/opt/devirt2.C: Use specific pattern for alpha*-*-*. Tested on alphaev68-pc-linux-gnu, committed to mainline SVN. Uros. Index: g++.dg/opt/devirt2.C === ---

Re: [Patch, Fortran, OOP] PR 49638: [OOP] length parameter is ignored when overriding type bound character functions with constant length.

Am 06.08.2011 23:10, schrieb Janus Weil: I'm know that this does not exactly fit in any of your categories. However, I still think that throwing an error for every case where we can not prove that the expressions are equal is a good approximation for the purpose, and everything beyond that is mos

Re: [Patch, Fortran, OOP] PR 49638: [OOP] length parameter is ignored when overriding type bound character functions with constant length.

2011/8/6 Thomas Koenig : > Am 06.08.2011 23:10, schrieb Janus Weil: >> >> I'm know that this does not exactly fit in any of your categories. >> However, I still think that throwing an error for every case where we >> can not prove that the expressions are equal is a good approximation >> for the pu

Re: [Patch, Fortran, OOP] PR 49638: [OOP] length parameter is ignored when overriding type bound character functions with constant length.

On Sunday 07 August 2011 00:21:46 Janus Weil wrote: > Well, ok. After this amount of discussion, how about we start with the > easy things: Here is a preparational patch (basically a subset of the > previous one), which does not do any real changes yet, only some > preparation and cleanup: > * It m

Re: [patch testsuite]: Adjust gcc.dg/tree-ssa tests for LLP64 target

On Aug 6, 2011, at 6:04 AM, Kai Tietz wrote: > this adjusts some testcases for LLP64 target x86_64 mingw. Ok. Please watch for any comments on stdarg... I don't have any, but others might.

Re: [PATCH] PR c++/33255 - Support -Wunused-local-typedefs warning

On 08/06/2011 06:57 AM, Dodji Seketeli wrote: @@ -4340,6 +4340,8 @@ c_sizeof_or_alignof_type (location_t loc, value = fold_convert_loc (loc, size_type_node, value); gcc_assert (!TYPE_IS_SIZETYPE (TREE_TYPE (value))); + maybe_record_local_typedef_use (type); Why is this still needed? +