Re: Implement stack arrays even for unknown sizes

> The resulting speed up for nf.f90 is rather remarkable. What specific > feature of the fortran leads to a 30=>15s ? I think it is the automatic array in the subroutine trisolve. Note that the speedup is rather 27->19s and may be darwin specific (slow malloc). Note also that -fstack-arrays pre

Re: [gc-improv] Permanent vs function RTL obstack fix

On Tue, Apr 12, 2011 at 4:54 AM, Jeff Law wrote: > On 04/11/11 18:21, Mike Stump wrote: >> On Apr 11, 2011, at 1:03 PM, Jeff Law wrote: >>> The obvious solution is you copy the object, but then you have to be >>> able to distinguish within the object, what fields point to other >>> temporary objec

Re: [Patch, libfortran] Don't define _GNU_SOURCE in AM_CPPFLAGS

Hi Janne, * Janne Blomqvist wrote on Mon, Apr 11, 2011 at 10:34:58PM CEST: > the attached patch removes the definition of _GNU_SOURCE from > AM_CPPFLAGS. This is not needed anymore since nowadays we're calling > AC_USE_SYSTEM_EXTENSIONS in configure.ac which causes _GNU_SOURCE to > be defined in c

Re: Implement stack arrays even for unknown sizes

Dear Michael, Thanks for updating the patch. I am afraid that my attention to gfortran is somewhat limited at present. However, I see that Dominique has verified your patch and that all is well. The resulting speed up for nf.f90 is rather remarkable. What specific feature of the fortran leads

Re: Ping [Patch,AVR]: Fix PR target/44643

2011/4/11 Georg-Johann Lay : > Georg-Johann Lay schrieb: >> This is fix of PR44643 which is triggered by >> >> http://savannah.nongnu.org/bugs/?32988 >> >> i.e. include/avr/pgmspace.h:PSTR has to be changed, too: PSTR has to >> generate __c as "static const char[]", not as "static char[]". Note >>

Re: Ping: [Patch][AVR]: Initial builtins support

2011/4/11 Georg-Johann Lay : > Georg-Johann Lay schrieb: >> This patch adds builtin support for some RTL builtins to avr backend. >> One builtin implements loop for delay of specific number of ticks >> (under the assumption IRQs are off), others simply map to machine >> instructions like SEI, CLI,

Re: Ping: [Patch,AVR]: Fix PR45263

2011/4/11 Georg-Johann Lay : > Georg-Johann Lay schrieb: >> Tested patch v2 from 2010-04-02 now for atmega2560 on avrtest >> simulator. In main, var1 and var2 are initialized as expected and >> anObject.getVal() is 30. >> >> Without patch the program hangs. > > > 2011-04-11  Georg-Johann Lay   > >

Re: [gc-improv] Permanent vs function RTL obstack fix

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 04/11/11 18:21, Mike Stump wrote: > On Apr 11, 2011, at 1:03 PM, Jeff Law wrote: >> The obvious solution is you copy the object, but then you have to be >> able to distinguish within the object, what fields point to other >> temporary objects vs per

Re: Add a mode argument to LEGITIMATE_CONSTANT_P, and make it a hook

On Mon, 4 Apr 2011, Richard Sandiford wrote: > Pretty much as the subject says. > OK to install? CRIS and MMIX parts are ok. brgds, H-P PS. FWIW anyone: for "my" targets, a CC to me usually gets a faster response.

Re: Simple enhancement to -dA dump

On Sun, 3 Apr 2011, Xinliang David Li wrote: > 2011-04-03 Xinliang David Li > > * final.c (dump_basic_block_info): New function. + fprintf (file, "# BLOCK %d", bb->index); Random spotting: please use ASM_COMMENT_START instead of the naked "#". brgds, H-P

Re: Target header etc. cleanup patch

On Sat, 2 Apr 2011, Joseph S. Myers wrote: > * cris-protos.h had an unused STDIO_INCLUDED definition, which I > removed. Been there since the first commit, it seems. Certainly this bit is ok. A nit: you had several lines consisting of "*." (with the obvious expansion) in the changelogs you post

Re: [gc-improv] Permanent vs function RTL obstack fix

On Apr 11, 2011, at 1:03 PM, Jeff Law wrote: > The obvious solution is you copy the object, but then you have to be > able to distinguish within the object, what fields point to other > temporary objects vs permanent objects so that you can copy the > referenced temporary objects, but not the perma

Re: ObjC: interface hashtable rewritten for speed and simplicity

On Apr 11, 2011, at 11:21 AM, Nicola Pero wrote: > This patch rewrites the ObjC interface hashtable for speed, saving > in excess of 100k function calls per typical compilation run in my > benchmarks. Does this change a log n lookup to a linear search look up?

Re: ObjC: do not prepare instance variables for output unless there is an actual error message to print

On Apr 11, 2011, at 11:20 AM, Nicola Pero wrote: > This is another very small optimization. Whenever the ObjC compiler > found an instance variable, it was preparing it for printing it > in error messages. > Ok to commit ? Ok.

Re: ObjC: some minor optimizations

On Apr 11, 2011, at 10:09 AM, Nicola Pero wrote: > This patch removes some very minor inefficiencies in the ObjC compiler code. > Ok to commit ? Ok. I do wonder if namespaces and Objective-C work well together...

C++ PATCHes for c++/48535 (SFINAE with T{})

To make the 48535 testcase work I needed to fix three separate issues: 1) build_compound_literal wasn't sfinae-enabled. 2) build_compound_literal didn't handle list-initialization of references. 3) We weren't dealing properly with invalid array initialization. Tested x86_64-pc-linux-gnu, applyin

Avoid doing superfluous work in force_nonfallthru

The new force_nonfallthru was modelled on redirect_edge_and_branch_force, but this means that it is doing superfluous work when the edge can be turned into a non-fallthru edge without creating a new basic block. Fixed thusly, bootstrapped/regested on x86_64-suse-linux, applied. 2011-04-11 Eri

Re: C++/c-common PATCH to conversion from scoped enum to bool (part of 48450)

On 04/07/2011 05:41 PM, Jason Merrill wrote: PR 48450 has to do with SFINAE bugs, but one of them turns out to be a different sort of bug: we were failing to convert from a non-constant value of scoped enum type to bool, because that conversion was doing a != 0, which requires an implicit convers

C++ PATCH for c++/48523 (lamda, 'this', templates)

Our rewriting for use of 'this' in a lambda used cp_build_indirect_ref, which assumes that we aren't in a template. Using build_x_indirect_ref instead works better. Tested x86_64-pc-linux-gnu, applying to trunk and 4.6. commit 9b7a53bda8938ff42074b1f38a3e0b68cb37e52e Author: Jason Merrill Dat

C++ PATCH for c++/48457 (rvalue references and function lvalues)

Recent discussion of how to deal with rvalue references and functions ended with the decision that an expression of function type is always an lvalue, even if it is derived from an rvalue reference, but that rvalue references can bind to function lvalues. Tested x86_64-pc-linux-gnu, applying t

Re: [PATCH] Remove VRPs use of TYPE_MIN/MAX_VALUE

> Is your concern the cost of calling lower/upper_bound_in_type? Yes, all the more so if other uses of TYPE_MIN/MAX_VALUE get replaced over time. IMO this is going backwards. The Ada compiler heavily uses types with non-canonical bounds and was changed so it's hard to believe that this isn't

Re: [PATCH 5/n, i386]: Merge SSE and AVX patterns using "enable" attribute.

On Mon, Apr 11, 2011 at 10:54 PM, Uros Bizjak wrote: > Attached patch merges "Parallel bitwise logical operations" section of > sse.md.  In addition to the merge, the patch also enables these > patterns for TARGET_SSE (using PS version of the insn) and handles > TARGET_SSE_PACKED_SINGLE_INSN_OPTI

Re: [PATCH] Fix ICE with C compound literals (PR c/48517)

On Mon, 11 Apr 2011, Jakub Jelinek wrote: > 2011-04-11 Jakub Jelinek > > PR c/48517 > * c-typeck.c (store_init_value): Set TREE_TYPE (decl) to > qualified type. > > * gcc.dg/pr48517.c: New test. OK, though I think the test would go better in gcc.c-torture/compile sinc

Re: [PATCH] Error out on uses of void type expressions in inline asm in C FE (PR c/48552)

On Mon, 11 Apr 2011, Jakub Jelinek wrote: > 2011-04-11 Jakub Jelinek > > PR c/48552 > * c-typeck.c (build_asm_expr): Error out on attempts to use > void type outputs or inputs for constraints that allow reg or > don't allow memory. > > * gcc.dg/pr48552-1.c: New t

Re: Implement stack arrays even for unknown sizes

With the new patch (+the fix for the uninitialized tmp), the polyhedron tests pass: Date & Time : 11 Apr 2011 21:20:59 Test Name : pbharness Compile Command : gfc %n.f90 -Ofast -funroll-loops -ftree-loop-lin

Re: Clean up i386/gnu.h

On 04/11/2011 12:28 PM, Joseph S. Myers wrote: > * config/i386/gnu.h (GNU_USER_LINK_EMULATION): Define. > (CPP_SPEC, CC1_SPEC, ENDFILE_SPEC): Remove. Ok. r~

Re: Clean up k*gnu configurations

On 04/11/2011 01:11 PM, Joseph S. Myers wrote: > * config.gcc (x86_64-*-kfreebsd*-gnu): Use i386/kfreebsd-gnu.h. > * config/i386/kfreebsd-gnu.h (GNU_USER_DYNAMIC_LINKER32, > GNU_USER_DYNAMIC_LINKER64): Define. > (REG_NAME): Don't undefine. > (MD_UNWIND_SUPPORT): Undefi

Re: [PATCH, rs6000] Make LR/CTR moves expensive for Power7 also

On Mon, Apr 11, 2011 at 4:03 PM, Pat Haugen wrote: > The following was overlooked on initial Power7 support. > > Bootstrap/regtest on powerpc64-linux with no new regressions. Ok for trunk > and 4.6? > > -Pat > > > 2011-04-11  Pat Haugen > >        * config/rs6000/rs6000.c (rs6000_register_move_co

[PATCH 5/n, i386]: Merge SSE and AVX patterns using "enable" attribute.

Hello! Attached patch merges "Parallel bitwise logical operations" section of sse.md. In addition to the merge, the patch also enables these patterns for TARGET_SSE (using PS version of the insn) and handles TARGET_SSE_PACKED_SINGLE_INSN_OPTIMAL target flag. 2011-04-12 Uros Bizjak *

Re: [C++0x] Range-based for statements and ADL

On Fri, Apr 8, 2011 at 5:45 PM, Jason Merrill wrote: >> +         error ("range-based % expression must have complete >> type"); >> +           error ("range-based % expression has an % member " >> +                  "but not a %"); > > Let's give the type of the range initializer in these error m

[Patch, libfortran] Don't define _GNU_SOURCE in AM_CPPFLAGS

Hi, the attached patch removes the definition of _GNU_SOURCE from AM_CPPFLAGS. This is not needed anymore since nowadays we're calling AC_USE_SYSTEM_EXTENSIONS in configure.ac which causes _GNU_SOURCE to be defined in config.h. Regtested on x86_64-unknown-linux-gnu, Ok for trunk? (I'm not commit

[Patch, libfortran] PR 47571 Fix bootstrap failure on alpha*-dec-osf*

Hi, the attached patch hopefully fixes the bootstrap failure on alpha*-dec-osf* due to said platform having clock_gettime() in librt, supporting weak symbols but not weak undefined symbols. The patch is the same as #38 in the PR discussion + adding alpha*-dec-osf* to the acinclude.m4 blacklist. R

Clean up k*gnu configurations

Now that gnu-user*.h and linux*.h config headers have more or less the proper contents, the next stage in stopping non-Linux-kernel-based targets from using linux*.h is to get the correct contents into the headers for the non-Linux-kernel-based targets. This patch (partly based on changes and info

Re: [gc-improv] Permanent vs function RTL obstack fix

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 04/10/11 12:22, Laurynas Biveinis wrote: > > It is certainly true that moving away from GC will make some kinds of > bugs possible again, but I hope that not enough to be an unmanageable > concern. It's definitely a huge concern. More for tree obj

[PATCH, rs6000] Make LR/CTR moves expensive for Power7 also

The following was overlooked on initial Power7 support. Bootstrap/regtest on powerpc64-linux with no new regressions. Ok for trunk and 4.6? -Pat 2011-04-11 Pat Haugen * config/rs6000/rs6000.c (rs6000_register_move_cost): Make LR/CTR moves expensive on Power7 also. Index:

Re: [gc-improv] Permanent vs function RTL obstack fix

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 04/10/11 12:27, Laurynas Biveinis wrote: > 2011/4/9 Steven Bosscher : >> 4. RTL per function. GCC expands one GIMPLE function at a time, and >> the idea is to initialize the RTL obstack once when expanding starts, >> let it grow until final, and blo

Re: [build] Avoid ld -v error message with Sun ld on SPARC

From: Rainer Orth Date: Mon, 11 Apr 2011 14:57:58 +0200 > The follwing patch uses the easy way out and just tests ld_ver. Tested > with make configure-gcc on sparc-sun-solaris2.11 with Sun as/ld, GNU > as/Sun ld, and GNU as/ld without change to gcc/auto-host.h and no linker > error. Just out of

[PATCH] Fix ICE with C compound literals (PR c/48517)

Hi! On the following testcase build_unary_op ICEs, because the element type of the array variable (which is TREE_READONLY) unexpectedly is not TYPE_READONLY. The problem seems to come from store_init_value, which replaces the type of the variable with build_distinct_type_copy (TYPE_MAIN_VARIANT (

[PATCH] Error out on uses of void type expressions in inline asm in C FE (PR c/48552)

Hi! Several of the functions in the following testcases ICE. Unlike C++ FE, C FE doesn't error out on void type derefs right away, just warns. But using void type expression for "r" or "=r" doesn't make sense and was ICEing. The patch still tollerates it for constraints that allow only mem, as

PING: PATCH: Remove 26 element limit in vector

On Mon, Apr 4, 2011 at 6:05 PM, H.J. Lu wrote: > On Thu, Mar 31, 2011 at 5:05 AM, Kenneth Zadeck > wrote: >> we hit this limit trying to write the explicit semantics for a >> vec_interleave_evenv32qi. >> >> ;;(define_insn "vec_interleave_evenv32qi" >> ;;  [(set (match_operand:V32QI 0 "register_op

Re: Ping Patch: add {tree,gimple}-pretty-print.h & realmpfr.h to PLUGIN_HEADERS

On Mon, Apr 11, 2011 at 15:31, Basile Starynkevitch wrote: > On Mon, 11 Apr 2011 15:27:15 -0400 > Diego Novillo wrote: > >> On Mon, Apr 11, 2011 at 15:24, Basile Starynkevitch >> wrote: >> >> > 2011-04-11  Basile Starynkevitch   >> >        * Makefile.in (PLUGIN_HEADERS): Add gimple-pretty-print

Re: Ping Patch: add {tree,gimple}-pretty-print.h & realmpfr.h to PLUGIN_HEADERS

On Mon, 11 Apr 2011 15:27:15 -0400 Diego Novillo wrote: > On Mon, Apr 11, 2011 at 15:24, Basile Starynkevitch > wrote: > > > 2011-04-11  Basile Starynkevitch   > >        * Makefile.in (PLUGIN_HEADERS): Add gimple-pretty-print.h > >        tree-pretty-print.h & realmpfr.h. > > OK. Committed r

Re: [Patch, fortran] PR48456 - [4.6/4.7 Regression] Realloc on assignment: ICE in fold_binary_loc and PR48360 - [4.6/4.7 Regression] ICE on array assignment statement with allocatable LHS

Paul Richard Thomas wrote: This patch is perfectly obvious and fixes both regressions in one go. Bootstrapped and regtested on FC9/x86_64 - OK for trunk? OK for the trunk - and for 4.6(.1). Thanks for the patch! Tobias 2011-04-11 Paul Thomas PR fortran/48360 PR fortran/484

Clean up i386/gnu.h

Now that gnu-user*.h and linux*.h config headers have more or less the proper contents, the next stage in stopping non-Linux-kernel-based targets from using linux*.h is to get the correct contents into the headers for the non-Linux-kernel-based targets. This patch does so for i386/gnu.h. GNU_USER

Re: Ping Patch: add {tree,gimple}-pretty-print.h & realmpfr.h to PLUGIN_HEADERS

On Mon, Apr 11, 2011 at 15:24, Basile Starynkevitch wrote: > 2011-04-11  Basile Starynkevitch   >        * Makefile.in (PLUGIN_HEADERS): Add gimple-pretty-print.h >        tree-pretty-print.h & realmpfr.h. OK. Diego.

[Patch, fortran] PR48456 - [4.6/4.7 Regression] Realloc on assignment: ICE in fold_binary_loc and PR48360 - [4.6/4.7 Regression] ICE on array assignment statement with allocatable LHS

This patch is perfectly obvious and fixes both regressions in one go. Bootstrapped and regtested on FC9/x86_64 - OK for trunk? Paul PS Now for PR48462 :-) 2011-04-11 Paul Thomas PR fortran/48360 PR fortran/48456 * trans-array.c (get_std_lbound): For derived type vari

Ping Patch: add {tree,gimple}-pretty-print.h & realmpfr.h to PLUGIN_HEADERS

On Thu, 7 Apr 2011 21:43:44 +0200 Basile Starynkevitch wrote: > > The following tiny patch add some files to PLUGIN_HEADERS. ## gcc/ChangeLog entry 2011-04-11 Basile Starynkevitch * Makefile.in (PLUGIN_HEADERS): Add gimple-pretty-print.h tree-pretty-print.h & realmpfr.h.

patch PR48464

The following patch fixes PR48464. The description of the problem can be found on http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48464 Committed as obvious after successful bootstrap on x86-64. 2011-04-11 Vladimir Makarov PR middle-end/48464 * ira.c (setup_pressure_classes): F

Re: Implement stack arrays even for unknown sizes

On 04/11/2011 06:04 PM, Michael Matz wrote: === *** trans-array.c (revision 172206) --- trans-array.c (working copy) *** gfc_trans_auto_array_allocation (tree de [...] ! gfc_add_init_cleanup (block, inittr

ObjC: interface hashtable rewritten for speed and simplicity

This patch rewrites the ObjC interface hashtable for speed, saving in excess of 100k function calls per typical compilation run in my benchmarks. I did extensively benchmark this solution (and other solutions) while developing it a few months ago. trunk has changed substantially in the meanwhile,

ObjC: do not prepare instance variables for output unless there is an actual error message to print

This is another very small optimization. Whenever the ObjC compiler found an instance variable, it was preparing it for printing it in error messages. Of course, in the typical ObjC compilation run with Foundation and AppKit the compiler will see about 1.5k instance variables, none of which will

[testsuite] Fix gcc.dg/torture/pr47917.c on Tru64 UNIX V5.1

As on several platforms, gcc.dg/torture/pr47917.c was failing on Tru64 UNIX V5.1. To get a standards-conformant snprintf (and vsnprintf), one needs to define _ISO_C_SOURCE=19990L (sic!). Initially, I tried to solve the problem in a general way by always defining that macro with -stdc=c99|gnu99, b

Re: [patch] make default linker --hash-style configurable option

Ping? On Mon, Apr 4, 2011 at 5:01 PM, Joseph S. Myers wrote: > On Tue, 5 Apr 2011, Matthias Klose wrote: ... >> Linux distributions pass more than that by default to the linker, e.g. >> --as-needed and --no-copy-dt-needed-entries.  Wouldn't it make more sense to >> add >> something like --with-l

[v3] Actually run some tests in parallel-mode for check-parallel

Hi, noticed last week. Enabling the tests is also useful to have a clearer picture of which parallel-mode std algorithms need to be fixed vs C++0x. Tested x86_64-linux check-parallel, committing to mainline. Paolo. // 2011-04-11 Paolo Carlini * testsuite/25_al

Re: [patch i386]: Cleanup calling convention handling in i386.c and fix PR target/9601 and PR target/11772

2011/4/11 Richard Henderson : > On 04/10/2011 12:01 AM, Kai Tietz wrote: >> I had introduced an const issue by recent patch. Attached patch fixes that. > > Patch is ok. Applied at revision 172268. Thanks, Kai

Re: [PATCH 3/6] Allow jumps in epilogues

On 04/05/2011 02:58 PM, Bernd Schmidt wrote: > * dwarf2out.c (struct dw_cfi_struct): Remove member dw_cfi_next. > (dw_cfi_ref): Add DEF_VEC_P and some DEF_VEC_ALLOC_Ps. > (cfi_vec): New typedef. > (struct dw_fde_struct): Make dw_fde_cfi a cfi_vec. Replace > dw_fde_swit

ObjC: some minor optimizations

This patch removes some very minor inefficiencies in the ObjC compiler code. Ok to commit ? Thanks Index: gcc/objc/ChangeLog === --- gcc/objc/ChangeLog (revision 172239) +++ gcc/objc/ChangeLog (working copy) @@ -1,3 +1,8 @@ +2011-0

Re: Ping Re: Split up config/i386/linux.h etc.

On 04/11/2011 05:55 AM, Joseph S. Myers wrote: > Ping. This patch > is pending > review. There's also a followup patch > pending review. > Both ok. r~

Re: Implement stack arrays even for unknown sizes

On Apr 11 2011, H.J. Lu wrote: Is that possible to raise stack limit when -fstack-arrays is used? In some systems, yes. In others (including most Unices), not without evil contortions that will assuredly break something else (like debuggers and some MPIs). Regards, Nick Maclaren.

Re: Ping: [Patch,AVR]: Fix PR45263

Georg-Johann Lay schrieb: > Georg-Johann Lay schrieb: >> Weddington, Eric schrieb: -Original Message- From: Georg-Johann Lay [mailto:a...@gjlay.de] Sent: Friday, April 01, 2011 4:01 PM To: Georg-Johann Lay Cc: gcc-patches@gcc.gnu.org; Denis Chertykov; Anatoly Sokolo

Re: Implement stack arrays even for unknown sizes

On Mon, Apr 11, 2011 at 9:04 AM, Michael Matz wrote: > On Sat, 9 Apr 2011, Paul Richard Thomas wrote: > >> I find that both nf.f90 and capacita.f90 segfault in runtime for any >> stack size. > > Try this patch.  I've verified that capacita and nf work with it and > -march=native -ffast-math -funro

Re: Implement stack arrays even for unknown sizes

I am trying the new patch. Updating failed with ../../work/gcc/fortran/trans-array.c: In function 'gfc_trans_auto_array_allocation': ../../work/gcc/fortran/trans-array.c:4881:24: error: 'tmp' may be used uninitialized in this function [-Werror=uninitialized] cc1: all warnings being treated as er

Re: Implement stack arrays even for unknown sizes

On Mon, Apr 11, 2011 at 6:04 PM, Michael Matz wrote: > On Sat, 9 Apr 2011, Paul Richard Thomas wrote: > >> I find that both nf.f90 and capacita.f90 segfault in runtime for any >> stack size. > > Try this patch.  I've verified that capacita and nf work with it and > -march=native -ffast-math -funro

Add debugging functions for cp_parser (issue4389045)

This patch adds a debugging function to print the state of a cp_parser instance. It prints all the status fields in the structure and a window of 20 tokens around the current token. This patch is against the pph branch, but it should apply almost cleanly to trunk. OK for mainline? Diego. cp/

Re: Implement stack arrays even for unknown sizes

On Sat, 9 Apr 2011, Paul Richard Thomas wrote: > I find that both nf.f90 and capacita.f90 segfault in runtime for any > stack size. Try this patch. I've verified that capacita and nf work with it and -march=native -ffast-math -funroll-loops -fstack-arrays -O3 . In fact all of polyhedron work

Re: [patch i386]: Cleanup calling convention handling in i386.c and fix PR target/9601 and PR target/11772

On 04/10/2011 12:01 AM, Kai Tietz wrote: > I had introduced an const issue by recent patch. Attached patch fixes that. Patch is ok. r~

[PATCH] Fixup missing host_integerp call

This fixes a missed check before calling tree_int_cst_low. Bootstrapped and tested on x86_64-unknown-linux-gnu, applied. Richard. 2011-04-11 Richard Guenther * gimplify.c (gimple_fold_indirect_ref): Check host_integerp before calling tree_low_cst. Index: gcc/gimplify.c

Re: [PATCH] Remove VRPs use of TYPE_MIN/MAX_VALUE

On Mon, 11 Apr 2011, Eric Botcazou wrote: > > Such types are still there for enumeral type kinds. Also the C family > > frontends leak arithmetic in array TYPE_DOMAIN types. > > The arithmetic needs to be fixed to use the base type instead (i.e. TREE_TYPE > of type, which is guaranteed to be si

Re: [PATCH][1/n][C] Do not sign-extend sizetypes

On Mon, 11 Apr 2011, Richard Guenther wrote: > c-family/ > * c-common.c (complete_array_type): Build a range type of > proper type. OK. -- Joseph S. Myers jos...@codesourcery.com

Re: [PATCH 5/7] Tweaks to C++ -> call graph interface

OK. Jason

Fix -Ttext= etc. handling

A problem was reported on IRC where the -Ttext= etc. joined-argument options no longer worked because they were passed to the linker as -T text= etc.; the driver only knew about the separate-argument -Ttext etc. versions as distinct from the -T option. This patch fixes this by adding these option

Re: [PATCH] Remove VRPs use of TYPE_MIN/MAX_VALUE

> Such types are still there for enumeral type kinds. Also the C family > frontends leak arithmetic in array TYPE_DOMAIN types. The arithmetic needs to be fixed to use the base type instead (i.e. TREE_TYPE of type, which is guaranteed to be sizetype for TYPE_DOMAIN types). > I don't see how we

Re: Implement stack arrays even for unknown sizes

Hi, On Mon, 11 Apr 2011, Eric Botcazou wrote: > > See? That's whay I meant with having to use a large ulimit for stack > > size. Usually stack overflows symptom is a simple segfault. What ulimit > > -s have you used for your capacita tests? > > Compiling with -fstack-check should give the seg

Re: [PATCH][1/n][C] Do not sign-extend sizetypes

On 11 April 2011 15:25, Richard Guenther wrote: > !   set_min_and_max_values_for_integral_type (t, precision, > !                                           /*is_unsinged=*/true); s/ng/gn/ Jay.

[PATCH][1/n][C] Do not sign-extend sizetypes

This is another try at making sizetype behavior more consistent with other integral types. In particular this series will eventually succeed in making TYPE_UNSIGNED tell the truth for sizetypes ... This first patch replaces a hack in the C frontend to handle zero-sized arrays (int a[] = {}) by s

Re: [PATCH 4/7] Removal of cgraph_node function

Hi, On Mon, Apr 11, 2011 at 12:28:36PM +0200, Jan Hubicka wrote: > > 2011-04-06 Martin Jambor > > > > * cgraph.h (cgraph_node): Remove function declaration. > > (cgraph_create_node): Declare. > > (cgraph_get_create_node): Likewise. > > > > * cgraph.c (cgraph_create_node): Rena

Re: [PATCH] Remove VRPs use of TYPE_MIN/MAX_VALUE

On Mon, 11 Apr 2011, Eric Botcazou wrote: > > The middle-end treats conversions between integral types that differ > > in TYPE_MIN/MAX_VALUE but not in TYPE_PRECISION or signedness as useless. > > This is inconsistent with VRP extracting range information from such > > types (and it is not clear h

Re: Implement stack arrays even for unknown sizes

> What ulimit -s have you used for your capacita tests? On *-apple-darwin* the stacksize is limited to (kbytes, -s) 65532 and it is hard coded. It is my (very limited) understanding that this limit can be bypassed by using something such as -Wl,-stack_size,0xf000 (for 1Gbytes in 64 bit mode -i

Re: Implement stack arrays even for unknown sizes

> See? That's whay I meant with having to use a large ulimit for stack > size. Usually stack overflows symptom is a simple segfault. What ulimit > -s have you used for your capacita tests? Compiling with -fstack-check should give the segfault reliably. -- Eric Botcazou

Re: [PATCH 2/7] cgraph_node -> cgraph_get_node conversions accepting NULL results

Hi, On Mon, Apr 11, 2011 at 12:18:24PM +0200, Jan Hubicka wrote: > > 2011-04-06 Martin Jambor > > > > gcc/ > > * cgraph.c (cgraph_local_info): Call cgraph_get_node instead > > of cgraph_node, handle NULL return value. > > (cgraph_global_info): Likewise. > > (cgraph_rtl_info): L

Re: [PATCH] Remove VRPs use of TYPE_MIN/MAX_VALUE

> The middle-end treats conversions between integral types that differ > in TYPE_MIN/MAX_VALUE but not in TYPE_PRECISION or signedness as useless. > This is inconsistent with VRP extracting range information from such > types (and it is not clear how NOP conversions behave here anyway). IIRC we ag

Re: [build, lto] Only accept -fuse-linker-plugin if linker supports -plugin (PR lto/46944)

Rainer Orth writes: > Richard Guenther writes: > >> I think we should do the linker version checks which relate to linker-plugin >> use on the plugin-linker instead. So if I specify a separate but known >> buggy linker I don't want it to be used by default. > > Here's a patch that does this. I

Re: [PATCH][RFC] Make called function type explicit, make function pointer type conversions useless

On Fri, Apr 8, 2011 at 11:49, Richard Guenther wrote: > I'll leave this for comments over the weekend, and if there are none > will go ahead and check this in early next week. The approach looks fine to me. Thanks. Diego.

Re: [pph] Debug Cleanup (issue4380046)

On Fri, Apr 8, 2011 at 22:00, Lawrence Crowl wrote: > Split pph_output_tree into pph_output_tree and pph_output_tree_aux. > The former is the primary external interface, and pph_output_tree_aux > is the internal (recursive) auxillary, which is used for function > bodies. Hm, why? They both seem

[build] Avoid ld -v error message with Sun ld on SPARC

While observing the output from gcc/configure on Solaris 11/SPARC, I noticed the following error: checking assembler for GOTDATA_OP relocs... ld: fatal: unrecognized option '-v' ld: fatal: use the -z help option for usage information yes There are at least two problems here: * Sun ld doesn't sup

Ping Re: Split up config/i386/linux.h etc.

Ping. This patch is pending review. There's also a followup patch pending review. -- Joseph S. Myers jos...@codesourcery.com

[testsuite] Avoid absolute paths in .sum files (PR testsuite/21164)

When comparing gcc testsuite results from two (slightly) different source tree with dg-cmp-results.sh, I ran into an old issue: some testsuites log absolute paths for either sources or executables, rendering comparison difficult. The libjava side of this problem was logged as PR libgcj/21164, but

Re: [Patch, Fortran] PR 18918 - Fix/Add multi-image support to UCOBOUND

On Tuesday 05 April 2011 19:44:29 Tobias Burnus wrote: > This patch adds multi-image support to UCOBOUND. In the -fcoarray=single > case, the last dimension is just "LCOARRAY (coarray, dim=corank)". > However, if there are multiple images, one has for corank-1 coarrays: > "lcobound(coarray) + num_i

Re: Implement stack arrays even for unknown sizes

Hi, On Mon, Apr 11, 2011 at 01:49:16PM +0200, Michael Matz wrote: > Hi, > > On Sun, 10 Apr 2011, Dominique Dhumieres wrote: > > > > I find that both nf.f90 and capacita.f90 segfault in runtime for any > > > stack size. > > > > On x86_64-apple-darwin10, nf.f90 "works". However if I run it throug

Re: Implement stack arrays even for unknown sizes

Hi, On Sun, 10 Apr 2011, Dominique Dhumieres wrote: > > I find that both nf.f90 and capacita.f90 segfault in runtime for any stack > > size. > > On x86_64-apple-darwin10, nf.f90 "works". However if I run it through > valgrind I get > > ==64815== Memcheck, a memory error detector > ==64815== Co

Re:Ping: [Patch][AVR]: Initial builtins support

Georg-Johann Lay schrieb: > This patch adds builtin support for some RTL builtins to avr backend. > One builtin implements loop for delay of specific number of ticks > (under the assumption IRQs are off), others simply map to machine > instructions like SEI, CLI, NOP, SLEEP, WDR, FMUL, FMAULS, FMUL

[PATCH] Remove VRPs use of TYPE_MIN/MAX_VALUE

The middle-end treats conversions between integral types that differ in TYPE_MIN/MAX_VALUE but not in TYPE_PRECISION or signedness as useless. This is inconsistent with VRP extracting range information from such types (and it is not clear how NOP conversions behave here anyway). The following pat

Re: Ping [Patch,AVR]: Fix PR target/44643

Georg-Johann Lay schrieb: > This is fix of PR44643 which is triggered by > > http://savannah.nongnu.org/bugs/?32988 > > i.e. include/avr/pgmspace.h:PSTR has to be changed, too: PSTR has to > generate __c as "static const char[]", not as "static char[]". Note > that avr-libc has to be changed anyw

Re: [patch, ARM] PR48250, rehaul arm_legitimize_reload_address()

On Fri, 2011-04-08 at 15:52 +0800, Chung-Lin Tang wrote: > Hi Richard, > here's a new patch, with some quite significant changes to > arm_legitimize_reload_address(). This time fully utilizing the > sign-magnitude offset macro you gave in the last thread, and adapting > your description into embed

[PATCH] Fix combiner ICEs after my recent patch (PR rtl-optimization/48549)

Hi! On the testcase below we ICE since my PR48343 patch. The problem is that update_cfg_for_uncondjump delete_insns the noop move, if the insn to be deleted is last_combined_insn (which can be both if it is i3 or when retrying and undobuf.other_insn happens to be last_combined_insn), next propagat

Re: Avoid global state in arm_handle_option

On Thu, 2011-04-07 at 22:06 +, Joseph S. Myers wrote: > This patch stops the ARM handle_option hook from using global state - > in fact removing the hook altogether by using .opt Enum facilities for > what it did. > > The -march, -mcpu and -mtune option values are made to use Enum. The > Enu

Re: [PATCH, PR 48195] Move around ipa_check_create_node_params and ipa_check_create_edge_args

> Bootstrapped and tested on x86_64-linux on both trunk and 4.6 branch > without any issues. OK for both? OK, please add changelog ;) I always wondered why we do the resizing in such a convoluted way. Honza > > Thanks, > > Martin > > > Index: src/gcc/ipa-cp.c > ==

[build, doc] Cleanup --enable-threads support

While developing the patch to remove --enable-threads=solaris support, I noticed a couple of other inconsistencies in this area. * Use of non-existant (at least in-tree) thread models. * Missing documenation (if you can call naming them documentation) for others. This patch fixes both, bootstr

Re: [PATCH 4/7] Removal of cgraph_node function

> 2011-04-06 Martin Jambor > > * cgraph.h (cgraph_node): Remove function declaration. > (cgraph_create_node): Declare. > (cgraph_get_create_node): Likewise. > > * cgraph.c (cgraph_create_node): Renamed to cgraph_create_node_1. > Updated all callers. > (cgrap

Re: [PATCH 3/7] cgraph_node -> cgraph_get_node with asserts

> 2011-04-06 Martin Jambor > > * tree-inline.c (tree_function_versioning): Call cgraph_get_node > instead of cgraph_node and assert it does not return NULL. > * lto-streamer-in.c (lto_read_body): Likewise. > * omp-low.c (new_omp_context): Likewise. > (create_task_c

  1   2   >