Re: [ping] Re: [patch, powerpc] #undef LINK_EH_SPEC before defining it

On Fri, Mar 04, 2011 at 05:30:10PM +1030, Alan Modra wrote: > On Wed, Feb 16, 2011 at 11:36:09PM +0100, Matthias Klose wrote: > > >../../src/gcc/config/rs6000/sysv4.h:839:1: warning: "LINK_EH_SPEC" > > >redefined > > >In file included from ./tm.h:33, > > >from ../../src/gcc/cp/rtti.c:27: > > >../.

Re: ivopts improvement

On 03/03/2011 03:28 PM, Tom de Vries wrote: reg-tested on x86_64. Better? Yes, very much so (talking about patch 6.5; the other one is an optimization but not essential based on the new comments). Just one question: what happens if the COND_EXPR is indeed turned into a MAX_EXPR? Is it a mi

Re: [PATCH, i386] Introduce a flag to generate only 128-bit avx instructions

On 03/04/2011 03:59 AM, Fang, Changpeng wrote: > +mprefers-avx128 > +Target Report Var(flag_prefers_avx128) Init(0) Use "mprefer-avx128". A switch should use a verb in command form -- you're telling the compiler what to do. Change both the switch and the flag spelling. > +Auto-vectorizer pref

Re: [ping] Re: [patch, powerpc] #undef LINK_EH_SPEC before defining it

On Wed, Feb 16, 2011 at 11:36:09PM +0100, Matthias Klose wrote: > >../../src/gcc/config/rs6000/sysv4.h:839:1: warning: "LINK_EH_SPEC" redefined > >In file included from ./tm.h:33, > >from ../../src/gcc/cp/rtti.c:27: > >../../src/gcc/config/freebsd-spec.h:135:1: warning: this is the location of > >

Re: build_function_call and TREE_ADDRESSABLE

Warn off anyone trying to do as I did, and the bit about inlines is no longer relevant. OK to apply? * tree.h (TREE_ADDRESSABLE): Note that direct calls set the flag on FUNCTION_DECLs. Index: gcc/tree.h === --- gcc/t

Re: PowerPC32 .gnu.attributes

Re http://gcc.gnu.org/ml/gcc-patches/2011-02/msg01525.html Updated patch, using cgraph to decide whether a function is visible outside of the object file. Bootstrapped and regression tested powerpc-linux. OK for 4.6? * config/rs6000/linux.h (TARGET_ASM_FILE_END): Don't define. *

Re: [4.7] Avoid global state in m32c_handle_option

> Tested building cc1 and xgcc for cross to m32c-elf. Will commit to > trunk for 4.7 in the absence of target maintainer objections. Go for it :-)

[4.7] Avoid global state in microblaze_handle_option

This patch, for 4.7 and relative to a tree with applied, stops the Microblaze handle_option hook from using global state. Everything the hook does - warnings and setting a variable also set by another option - can be done using .opt features

[4.7] Avoid global state in m32r_handle_option

This patch, for 4.7 and relative to a tree with applied, stops the M32R handle_option hook from using global state. Some options are converted to using .opt features; in particular, -mmodel= and -msdata= are converted to use Enum. (Because

[4.7] Avoid global state in m32c_handle_option

This patch, for 4.7 and relative to a tree with applied, stops the M32C handle_option hook from using global state. All the hook did was process an integer argument and set a variable to indicate that the option had been used explicitly; th

[4.7] Avoid global state in iq2000_handle_option

This patch, for 4.7 and relative to a tree with applied, stops the IQ2000 handle_option hook from using global state. Because all the hook did was handle fixed sets of arguments to particular options (setting a variable for one, ignoring th

Re: [PATCH, i386 AVX] Type error in vpmaddubsw instruction pattern

On Thursday, March 3, 2011, Uros Bizjak wrote: > On Thu, Mar 3, 2011 at 12:11 PM, Liu wrote: > >> When I read sse.md, I find there is a type error in vpmaddubsw >> define_insn pattern. >> Attached is the patch that fix the type error. >> Is it OK to commit to 4.6 trunk? > > The same problem is wi

Re: [RFA] libiberty/hashtab.c, higher_prime_index: avoid array overrun

> I was just wondering whether now would be a good time to mention Probably not, gcc being in stage 4 and all...

Re: [RFA] libiberty/hashtab.c, higher_prime_index: avoid array overrun

On 03/03/2011 23:00, Mike Stump wrote: > On Mar 3, 2011, at 2:26 PM, Michael Snyder wrote: >> DJ Delorie wrote: As written, the function will access element [30] of a 30-element array. >>> Um, no? >> Y-uh-huh! > > fight fight fight... :-) There can be only one. I was just wondering wheth

Re: [PING^2] [PR46003, C++] Fix the assertion failure in build_target_expr

On 03/02/2011 12:53 PM, Yufeng Zhang wrote: The calls to build_cplus_new in convert_like_real don't seem to be redundant. Hmm, I guess you're right. I think rather that the problem is in build_conditional_expr; it should have a template case that just determines the appropriate type and then

Re: build_function_call and TREE_ADDRESSABLE

On Thu, Mar 03, 2011 at 04:43:15PM +0100, Richard Guenther wrote: > On Thu, Mar 3, 2011 at 4:42 PM, Richard Guenther > wrote: > > On Thu, Mar 3, 2011 at 3:33 PM, Alan Modra wrote: > >> TREE_ADDRESSABLE comment says "In a FUNCTION_DECL, nonzero means its > >> address is needed".  However, as I poi

Re: [RFA] libiberty/hashtab.c, higher_prime_index: avoid array overrun

Mike Stump wrote: On Mar 3, 2011, at 2:26 PM, Michael Snyder wrote: DJ Delorie wrote: As written, the function will access element [30] of a 30-element array. Um, no? Y-uh-huh! fight fight fight... :-) There can be only one. Oh, did I forget the smiley? ;-)

Re: [RFA] libiberty/hashtab.c, higher_prime_index: avoid array overrun

On Mar 3, 2011, at 2:26 PM, Michael Snyder wrote: > DJ Delorie wrote: >>> As written, the function will access element [30] of a 30-element array. >> Um, no? > > Y-uh-huh! fight fight fight... :-) There can be only one.

Re: [RFA] libiberty/hashtab.c, higher_prime_index: avoid array overrun

Bizzare, the problem isn't the hash loop, it's the error handler at the end! It never uses [30] for the main loop, only if you give it a number between 0xfffb and 0x - and in the case where it would use [30], it's supposed to abort anyway. I couldn't figure out why your patch worked

Re: [RFA] libiberty/hashtab.c, higher_prime_index: avoid array overrun

DJ Delorie wrote: As written, the function will access element [30] of a 30-element array. Um, no? unsigned int mid = low + (high - low) / 2; This can never give mid == high unless low == high, which won't happen in that loop. The math wants to search everything from (including) low to

Re: [RFA] libiberty/hashtab.c, higher_prime_index: avoid array overrun

DJ Delorie wrote: As written, the function will access element [30] of a 30-element array. Um, no? Y-uh-huh! unsigned int mid = low + (high - low) / 2; This can never give mid == high unless low == high, which won't happen in that loop. The math wants to search everything from (incl

Fix !EXIT_IGNORE_STACK vs over-aligned variables

DJ reported this yesterday on m32c, but this would affect all such targets: mcore, m32c, arc, h8300, m68hc11. In my opinion, we ought to work with these targets to add the few insns to their epilogue to handle alloca, rather than keep these very infrequently used code paths. Material for 4.7, for

Re: [RFA] libiberty/hashtab.c, higher_prime_index: avoid array overrun

> As written, the function will access element [30] of a 30-element array. Um, no? unsigned int mid = low + (high - low) / 2; This can never give mid == high unless low == high, which won't happen in that loop. The math wants to search everything from (including) low to (excluding) high.

[RFA] libiberty/hashtab.c, higher_prime_index: avoid array overrun

As written, the function will access element [30] of a 30-element array. OK? 2011-03-03 Michael Snyder * hashtab.c (higher_prime_index): Prevent array overrun. Index: hashtab.c === RCS file: /cvs/src/src/libiberty/hasht

Re: libiberty/cplus-dem.c, ada-demangle: plug memory leak.

Jakub Jelinek wrote: On Thu, Mar 03, 2011 at 01:20:28PM -0800, Michael Snyder wrote: 2011-03-03 Michael Snyder * libiberty/cplus-dem.c (ada_demangle): Stop memory leak. Also fix a one line indent problem. No libiberty/ in libiberty/ChangeLog. @@ -1129,10 +1129,11 @@ ada_d

Re: libiberty/cplus-dem.c, ada-demangle: plug memory leak.

On Thu, Mar 03, 2011 at 01:20:28PM -0800, Michael Snyder wrote: > 2011-03-03 Michael Snyder > > * libiberty/cplus-dem.c (ada_demangle): Stop memory leak. > Also fix a one line indent problem. No libiberty/ in libiberty/ChangeLog. > @@ -1129,10 +1129,11 @@ ada_demangle (const char

libiberty/cplus-dem.c, ada-demangle: plug memory leak.

We don't have a separate libiberty list, do we? 2011-03-03 Michael Snyder * libiberty/cplus-dem.c (ada_demangle): Stop memory leak. Also fix a one line indent problem. Index: cplus-dem.c === RCS file: /cvs/src/sr

[PATCH, i386] Fix wrong mode in pmaddubsw instruction pattern

On Thu, Mar 3, 2011 at 3:29 PM, Uros Bizjak wrote: >> When I read sse.md, I find there is a type error in vpmaddubsw >> define_insn pattern. >> Attached is the patch that fix the type error. >> Is it OK to commit to 4.6 trunk? > > The same problem is with ssse3_pmadddubsw128 pattern.  Can you als

[gomp3.1] C/C++ min/max reductions

Hi! This patch adds min/max reduction support for C/C++, which was quite easy given that the middle-end already needs to support it for Fortran. Tested on x86_64-linux, committed to gomp-3_1-branch. 2011-03-03 Jakub Jelinek * c-parser.c (c_parser_omp_clause_reduction): Handle min and

[patch, committed, ia64-hp-hpux*] Fix -flto failures

This patch fixes g++.dg/lto/20091022-2, g++.dg/torture/pr33572.C, and g++.dg/torture/pr39417.C on IA64 HP-UX when compiled with -flto. In this case the tests generate references to __gcc_personality_v0 which is not defined in libgcc_s.so on HP-UX. This patch fixes the problem by including the __g

RE: [Patch, AVR]: PR42240 - Fix epilogue of naked functions

> -Original Message- > From: Georg-Johann Lay [mailto:a...@gjlay.de] > Sent: Thursday, March 03, 2011 11:01 AM > To: Denis Chertykov > Cc: gcc-patches@gcc.gnu.org; Anatoly Sokolov; Weddington, Eric > Subject: Re: [Patch, AVR]: PR42240 - Fix epilogue of naked functions > > > Denis. > > I

Re: [Patch, AVR]: PR42240 - Fix epilogue of naked functions

Denis Chertykov schrieb: Denis. This are backports to 4.3, 4.4, 4.5 branch, respectively (branches/gcc-4_*-branch/) Why you want to backport so deep ? IMHO trunk and 4.5 is enough. Applied to 4.5 Denis. I don't know what the policy concerning the depth of backporting bugfixes actually is

RE: [PATCH, i386] Introduce a flag to generate only 128-bit avx instructions

Yes, you are right. I renamed the flag to -mprefers-avx128 and modified the documentation. Is this OK to commit to 4.6? Thanks, Changpeng From: Richard Henderson [r...@redhat.com] Sent: Wednesday, March 02, 2011 3:50 PM To: Fang, Changpeng Cc: Jakub Je

Re: [Patch, AVR]: PR42240 - Fix epilogue of naked functions

>> Denis. > > This are backports to 4.3, 4.4, 4.5 branch, respectively > (branches/gcc-4_*-branch/) Why you want to backport so deep ? IMHO trunk and 4.5 is enough. Applied to 4.5 Denis.

[RFC] OpenMP 3.1 atomics

Hi! This patch is a WIP patch for OpenMP 3.1 atomics, so far for C FE only. It handles parsing (I created 3 new tree codes for atomic read, atomic capture of the old and of the new value), gimplification and omp expansion thereof, but currently both atomic read and atomic write are implemented alw

Re: [C++ Patch] PR 47974

OK. Jason

Re: C++ PATCH for c++/47950 (ICE with condition in template)

On 03/03/2011 12:08 AM, Jason Merrill wrote: The problem here was that we were folding the initializer too many times, so we lost the TREE_CONSTANT on the TARGET_EXPR. Since we already fold in cp_parser_initializer_clause, it's redundant to do so in cp_parser_condition as well. It occurred to m

[PATCH] Fix PR46399 - missing mode promotion for libcall args - updated

Hi, I've refreshed the patch: [PATCH] Fix PR46399 - missing mode promotion for libcall args http://gcc.gnu.org/ml/gcc-patches/2011-02/msg01595.html after removing the FUNCTION_VALUE target macro with: [Committed] S/390: Remove deprecated target macro FUNCTION_VALUE http://gcc.gnu.org/ml/gcc-pat

[PATCH] Fix PR47975

Bah, whoever invented #define TYPE_MODE(NODE) \ (TREE_CODE (TYPE_CHECK (NODE)) == VECTOR_TYPE \ ? vector_type_mode (NODE) : (NODE)->type.mode) needs to be clue-batted (yes, I know your name!!! ;)) Bootstrap and regtest running on x86_64-unknown-linux-gnu. Richard. 2011-03-03 Richard Gue

[committed] Fix OpenMP ICE on invalid during gimplification (PR c/47963)

Hi! omp_notice_variable isn't prepared to see INTEGER_CST (which wouldn't be there on valid code where DECL_SIZE is a DECL). Fixed thusly, bootstrapped/regtested on x86_64-linux and i686-linux, committed to trunk. 2011-03-03 Jakub Jelinek PR c/47963 * gimplify.c (omp_add_varia

[C++ Patch] PR 47974

Hi, another ICE on invalid, 4.6 regression, a simple patch for it attached. Tested x86_64-linux. Ok? Thanks, Paolo. /cp 2011-03-03 Paolo Carlini PR c++/47974 * pt.c (tsubst_template_args): Check argument t for error_mark_node. /testsuite 2011-03-03 Paolo Carlini

[PATCH] Fix PR47968, extract_bit_field_1 oddness

This fixes PR47968, we are trying to expand a bitfield extraction through vec_extract but strip subregs making the inputs invalid. We try to compensate for this searching for a more proper vector mode but then we have a strange requirement that NUNITS should stay the same when the most important t

Re: [PATCH] Try to canonicalize MEM_REFs that are put into MEM_EXPRs for DEBUG_INSNs (PR debug/47283, take 2)

On Thu, Mar 3, 2011 at 4:11 PM, Jakub Jelinek wrote: > On Thu, Mar 03, 2011 at 03:31:55PM +1000, Richard Henderson wrote: >> Do you really want to fallthru with newexp here? >> In theory it could have folded to anything.  My guess is that >> you want to restart instead... > > Here is an updated pa

Re: build_function_call and TREE_ADDRESSABLE

On Thu, Mar 3, 2011 at 4:42 PM, Richard Guenther wrote: > On Thu, Mar 3, 2011 at 3:33 PM, Alan Modra wrote: >> TREE_ADDRESSABLE comment says "In a FUNCTION_DECL, nonzero means its >> address is needed".  However, as I point out in >> http://gcc.gnu.org/ml/gcc-patches/2011-02/msg01525.html, this f

Re: build_function_call and TREE_ADDRESSABLE

On Thu, Mar 3, 2011 at 3:33 PM, Alan Modra wrote: > TREE_ADDRESSABLE comment says "In a FUNCTION_DECL, nonzero means its > address is needed".  However, as I point out in > http://gcc.gnu.org/ml/gcc-patches/2011-02/msg01525.html, this flag > gets set when making normal calls.  It wasn't always lik

[PATCH] Try to canonicalize MEM_REFs that are put into MEM_EXPRs for DEBUG_INSNs (PR debug/47283, take 2)

On Thu, Mar 03, 2011 at 03:31:55PM +1000, Richard Henderson wrote: > Do you really want to fallthru with newexp here? > In theory it could have folded to anything. My guess is that > you want to restart instead... Here is an updated patch that does that, and also as requested by Richard Guenther

build_function_call and TREE_ADDRESSABLE

TREE_ADDRESSABLE comment says "In a FUNCTION_DECL, nonzero means its address is needed". However, as I point out in http://gcc.gnu.org/ml/gcc-patches/2011-02/msg01525.html, this flag gets set when making normal calls. It wasn't always like this. gcc-4.0 was careful to not set TREE_ADDRESSABLE on

Re: [PATCH, i386 AVX] Type error in vpmaddubsw instruction pattern

On Thu, Mar 3, 2011 at 12:11 PM, Liu wrote: > When I read sse.md, I find there is a type error in vpmaddubsw > define_insn pattern. > Attached is the patch that fix the type error. > Is it OK to commit to 4.6 trunk? The same problem is with ssse3_pmadddubsw128 pattern. Can you also provide the

Re: ivopts improvement

Hi Paolo, On 03/03/2011 09:44 AM, Paolo Bonzini wrote: > On 03/02/2011 11:01 PM, Tom de Vries wrote: >> + if (TREE_CODE (nit) == COND_EXPR) >> +{ >> + if (!loop_only_exit_p (loop, exit)) >> +return false; >> + >> + return iv_elimination_compare_lt (use, cand, bound, nit, com

Re: [Patch, AVR]: PR42240 - Fix epilogue of naked functions

Denis Chertykov schrieb: > 2011/2/26 Georg-Johann Lay : >> Georg-Johann Lay schrieb: >> >> http://gcc.gnu.org/ml/gcc-patches/2011-02/msg01441.html >> >>> The patch implements target hook TARGET_CANNOT_MODIFY_JUMPS_P in order >>> to inhibit post-reload bb reorder for naked functions. >>> >>> It's ba

[PATCH][4.5] Fix -Werror bootstrap

Bootstrapped on x86_64-unknown-linux-gnu, applied. Richard. 2011-03-03 Richard Guenther * tree-vect-stmt.c (vectorizable_operation): Remove unused vars. Index: gcc/tree-vect-stmts.c === *** gcc/tree-vect-stmts.c (

[Committed] S/390: Remove deprecated target macro FUNCTION_VALUE

Hi, this patch removes the use of the deprecated FUNCTION_VALUE macro in the S/390 back end. Bootstrapped on s390 and s390x. No regression. Committed to mainline. Bye, -Andreas- 2011-03-03 Andreas Krebbel * config/s390/s390.c (s390_function_value): Rename to ... (s390_fun

[PATCH, C++ testsuite] Fix g++.dg/abi/arm_cxa_vec1.C

Hi, Here is a patch that fixes a problem in one g++ test case. A typo (of using the macro ___ARM_EABI__ rather than __ARM_EABI__) has made the original test case almost a NOP. Also with a few other changes that make the test work properly. I have already tested the updated test case that it stil

[PATCH] Fix and be more forgiving in the alias oracle

As PR47283 shows we still have issues with debug insns and the alias oracle. This patch makes us give conservative answers for refs_may_alias_p_1 like we do in the other oracle entires (where I noticed a bug, fixed with this patch). I'll keep the assert for checking-enabled builds as we probably