Re: [wwwdocs] gcc-4.6/porting_to.html
On Wed, 16 Mar 2011, Benjamin Kosnik wrote: > Needs some more work, here's a rough draft. s/Porting to the new tools/Porting to the new version/ ? brgds, H-P
Re: [wwwdocs] gcc-4.6/porting_to.html
On Wed, Mar 16, 2011 at 11:51:30PM -0700, Benjamin Kosnik wrote:
> +
> + To fix, first see if the unused variable or parameter can be removed
> + without changing the result or logic of the surrounding code. If not,
> + annoate it with __attribute__((__unused__))
annotate
Also, I think we should mention that casting the var to void is another
option.
And I think it is worth mentioning that sometimes the RHS can have important
side-effects, in which case it is desirable to just drop the LHS and =,
while sometimes the RHS is just uselessly computed and can be dropped
altogether with the assignment and unused variable.
> + Strict overflow warnings
> +
> +
> + Using the -Wstrict-overflow flag
> + with -Werror and optmization flags above -O2
> + may result in compile errors when using glibc optimizations
> + for strcmp.
> +
> +
> +
> + For example,
> +
> +
> +
> + #include
> + void do_rm_rf (const char *p) { if (strcmp (p, "/") == 0) return; }
> +
This has been actually fixed, so we shouldn't mention this.
> +
> + Jim Meyering, href="http://lists.fedoraproject.org/pipermail/devel/2011-March/149355.html";>gcc-4.6.0-0.12.fc15.x86_64
> breaks strcmp?
And this reference too.
Thanks for writing this.
Jakub
Re: C++ PATCH for c++/48132 (ICE with constexpr and array)
On Wed, Mar 16, 2011 at 9:00 PM, Jason Merrill wrote:
> Jakub was right that we were failing to add indices to the array CONSTRUCTOR
> along this code path. It seems appropriate to add them earlier, in
> reshape_init, like we do for classes, so this patch fixes the bug that way.
>
> Tested x86_64-pc-linux-gnu, applying to trunk. Also OK for 4.6.0? The risk
> is that something else not caught by the testsuite could be confused by
> adding the indices slightly sooner, but that seems unlikely.
Ok for 4.6.0.
Thanks,
Richard.
> commit 4d360926bf71c078e6c6962b7aee997c2e5974e6
> Author: Jason Merrill
> Date: Wed Mar 16 15:15:56 2011 -0400
>
> PR c++/48132
> * decl.c (check_array_designated_initializer): Allow integer index.
> (reshape_init_array_1): Set index on the elements.
>
> diff --git a/gcc/cp/decl.c b/gcc/cp/decl.c
> index f9d90ad..3139ad8 100644
> --- a/gcc/cp/decl.c
> +++ b/gcc/cp/decl.c
> @@ -4596,6 +4596,9 @@ check_array_designated_initializer (const
> constructor_elt *ce)
> if (ce->index == error_mark_node)
> error ("name used in a GNU-style designated "
> "initializer for an array");
> + else if (TREE_CODE (ce->index) == INTEGER_CST)
> + /* An index added by reshape_init. */
> + return true;
> else
> {
> gcc_assert (TREE_CODE (ce->index) == IDENTIFIER_NODE);
> @@ -4899,7 +4902,8 @@ reshape_init_array_1 (tree elt_type, tree max_index,
> reshape_iter *d)
> elt_init = reshape_init_r (elt_type, d,
> /*first_initializer_p=*/false);
> if (elt_init == error_mark_node)
> return error_mark_node;
> - CONSTRUCTOR_APPEND_ELT (CONSTRUCTOR_ELTS (new_init), NULL_TREE,
> elt_init);
> + CONSTRUCTOR_APPEND_ELT (CONSTRUCTOR_ELTS (new_init),
> + size_int (index), elt_init);
> }
>
> return new_init;
> diff --git a/gcc/testsuite/g++.dg/cpp0x/constexpr-array3.C
> b/gcc/testsuite/g++.dg/cpp0x/constexpr-array3.C
> new file mode 100644
> index 000..145a430
> --- /dev/null
> +++ b/gcc/testsuite/g++.dg/cpp0x/constexpr-array3.C
> @@ -0,0 +1,14 @@
> +// PR c++/48132
> +// { dg-options -std=c++0x }
> +
> +struct C
> +{
> + constexpr C (int x) : c (x) {}
> + int c;
> +};
> +
> +void
> +foo ()
> +{
> + C a[] = { C (0) };
> +}
>
>
Re: C++ PATCH for c++/48113 (SFINAE bug causing bind regression in libstdc++)
On Wed, Mar 16, 2011 at 8:51 PM, Jason Merrill wrote:
> convert_for_initialization is sfinae-enabled, but it was calling
> ocp_convert, which is not. This patch changes it to use the newer
> perform_implicit_conversion_flags instead. To make that work, I needed to
> add support for LOOKUP_PREFER_RVALUE to that code path.
>
> Tested x86_64-pc-linux-gnu, applying to trunk.
>
> Also OK for 4.6.0? The risk is that swapping to
> perform_implicit_conversion_flags will have other differences of behavior,
> but the library regression seems pretty major, so I think it's worth the
> risk.
Ok for 4.6.0. I guess we need to do a RC2 anyway.
Thanks,
Richard.
> commit fb46d045ce1b2ee71402942a42b61921cec7c41f
> Author: Jason Merrill
> Date: Mon Mar 14 14:49:58 2011 -0400
>
> PR c++/48113
> * typeck.c (convert_for_initialization): Use
> perform_implicit_conversion_flags.
> * call.c (standard_conversion): If LOOKUP_PREFER_RVALUE, set
> rvaluedness_matches_p on ck_rvalue.
> (convert_like_real) [ck_rvalue]: And restore it here.
>
> diff --git a/gcc/cp/call.c b/gcc/cp/call.c
> index f75c248..436c956 100644
> --- a/gcc/cp/call.c
> +++ b/gcc/cp/call.c
> @@ -98,7 +98,9 @@ struct conversion {
> BOOL_BITFIELD base_p : 1;
> /* If KIND is ck_ref_bind, true when either an lvalue reference is
> being bound to an lvalue expression or an rvalue reference is
> - being bound to an rvalue expression. */
> + being bound to an rvalue expression. If KIND is ck_rvalue,
> + true when we should treat an lvalue as an rvalue (12.8p33). If
> + KIND is ck_base, always false. */
> BOOL_BITFIELD rvaluedness_matches_p: 1;
> BOOL_BITFIELD check_narrowing: 1;
> /* The type of the expression resulting from the conversion. */
> @@ -897,6 +899,8 @@ standard_conversion (tree to, tree from, tree expr, bool
> c_cast_p,
> }
> }
> conv = build_conv (ck_rvalue, from, conv);
> + if (flags & LOOKUP_PREFER_RVALUE)
> + conv->rvaluedness_matches_p = true;
> }
>
> /* Allow conversion between `__complex__' data types. */
> @@ -5489,6 +5493,8 @@ convert_like_real (conversion *convs, tree expr, tree
> fn, int argnum,
> conversion (i.e. the second step of copy-initialization), so
> don't allow any more. */
> flags |= LOOKUP_NO_CONVERSION;
> + if (convs->rvaluedness_matches_p)
> + flags |= LOOKUP_PREFER_RVALUE;
> if (TREE_CODE (expr) == TARGET_EXPR
> && TARGET_EXPR_LIST_INIT_P (expr))
> /* Copy-list-initialization doesn't actually involve a copy. */
> diff --git a/gcc/cp/typeck.c b/gcc/cp/typeck.c
> index c062f0f..0e8a6d7 100644
> --- a/gcc/cp/typeck.c
> +++ b/gcc/cp/typeck.c
> @@ -7454,7 +7454,7 @@ convert_for_initialization (tree exp, tree type, tree
> rhs, int flags,
> return rhs;
>
> if (MAYBE_CLASS_TYPE_P (type))
> - return ocp_convert (type, rhs, CONV_IMPLICIT|CONV_FORCE_TEMP, flags);
> + return perform_implicit_conversion_flags (type, rhs, complain, flags);
>
> return convert_for_assignment (type, rhs, errtype, fndecl, parmnum,
> complain, flags);
> diff --git a/gcc/testsuite/g++.dg/cpp0x/initlist38.C
> b/gcc/testsuite/g++.dg/cpp0x/initlist38.C
> index 818d69a..32e20d5 100644
> --- a/gcc/testsuite/g++.dg/cpp0x/initlist38.C
> +++ b/gcc/testsuite/g++.dg/cpp0x/initlist38.C
> @@ -17,5 +17,5 @@ int main()
> f({});
> B b0 = { };
> B b1 { }; // OK, uses #1
> - B b2 { 1 }; // { dg-error "conversion" }
> + B b2 { 1 }; // { dg-error "could not convert" }
> }
> diff --git a/gcc/testsuite/g++.dg/cpp0x/pr45908.C
> b/gcc/testsuite/g++.dg/cpp0x/pr45908.C
> index 1a821e5..3a85088 100644
> --- a/gcc/testsuite/g++.dg/cpp0x/pr45908.C
> +++ b/gcc/testsuite/g++.dg/cpp0x/pr45908.C
> @@ -14,5 +14,5 @@ struct vector {
> class block {
> vector v;
> auto end() const -> decltype(v.begin())
> - { return v.begin(); } // { dg-error "conversion" }
> + { return v.begin(); } // { dg-error "could not convert" }
> };
> diff --git a/gcc/testsuite/g++.dg/cpp0x/sfinae6.C
> b/gcc/testsuite/g++.dg/cpp0x/sfinae6.C
> new file mode 100644
> index 000..401d536
> --- /dev/null
> +++ b/gcc/testsuite/g++.dg/cpp0x/sfinae6.C
> @@ -0,0 +1,31 @@
> +// PR c++/48113
> +// { dg-options -std=c++0x }
> +
> +template T declval();
> +
> +struct tuple { };
> +
> +struct F1
> +{
> + void operator()(tuple, int);
> +};
> +
> +typedef void (*F2)(tuple, int);
> +
> +template
> +struct Bind
> +{
> + template + typename R = decltype( F()(declval(), A()) )>
> + R f(A);
> +
> + template + typename R = decltype( F()(declval(), A()) )>
> + R f(A) volatile;
> +};
> +
> +int main()
> +{
> + Bind().f(0); // OK
> + Bind().f(0); // ERROR, should be OK
> +}
> diff --git a/gcc/testsuite/g++.old-deja/g++.jason/conversion11.C
> b/gcc/testsuite/g++.old-deja/g++.jason/conversion11.C
> index 607cf9c..6621a27 100644
> --- a/gcc/testsui
Re: C++ PATCH for c++/48113 (SFINAE bug causing bind regression in libstdc++)
On Thu, Mar 17, 2011 at 09:26:36AM +0100, Richard Guenther wrote: > Ok for 4.6.0. I guess we need to do a RC2 anyway. Yeah, certainly. I'll roll one during the weekend, it would be nice if all the pending fixes still desirable for 4.6.0 make it till then and after RC2 we'd try to allow only very high severity bugfixes. Some sort of safe workaround for PR47571 is IMHO e.g. acceptable before RC2, but not afterwards, and probably want PR48161 fixed too. Jakub
Re: PR45273 - The compiler depends on the host double
On Thu, Mar 17, 2011 at 12:24 AM, Steven Bosscher wrote: > Hi, > > The attached patch replace sreal math with mpfr math in predict.c and > host double math in mcf.c also with mpfr math. > > Bootstrapped&tested (incl. ada) on x86_64-unknown-linux-gnu. OK for trunk? > > Anyone a better suggestion for PRED_PRECISION? It at least seems you are introducing another host dependency here with using HOST_BITS_PER_WIDE_INT. Why not simply use a fixed value of 32? Can you try to explain +/* Using greater precision than the host's widest integer is a recepe for + random profile inconsistencies due to excess precision. */ ? The comment should tell why this is the case, otherwise it isn't helpful. Eliminating sreal for mpfr sounds like a good idea in general. Did you try to measure compile-time differences? Btw, ipa-inline.c contains some real host double arithmetic ... Thanks, Richard. > > Ciao! > Steven >
Re: [PATCH] Ensure DEBUG_INSNs don't contain MEMs with non-canonical MEM_EXPRs (PR debug/48134)
On Thu, Mar 17, 2011 at 12:32 AM, Jakub Jelinek wrote:
> Hi!
>
> Currently expand_debug_expr doesn't always guarantee canonical
> MEM_EXPRs, if MEM_EXPR isn't canonical, sometimes aliasing code ICEs on it
> (since recent Richard's change fortunately only if --enable-checking=yes).
>
> The following patch canonicalizes those using fold and if canonicalization
> isn't successful, just clears the MEM_EXPR.
>
> Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk and
> 4.6.1?
>
> 2011-03-17 Jakub Jelinek
>
> PR debug/48134
> * cfgexpand.c (expand_debug_expr) : Use fold to
> canonicalize MEM_EXPR, if it still isn't canonical afterwards, just
> clear MEM_EXPR.
>
> * gcc.dg/pr48134.c: New test.
>
> --- gcc/cfgexpand.c.jj 2011-03-16 18:30:12.0 +0100
> +++ gcc/cfgexpand.c 2011-03-16 22:05:13.0 +0100
> @@ -2712,6 +2712,8 @@ expand_debug_expr (tree exp)
>
> if (MEM_P (op0))
> {
> + tree mem_exp;
> +
> if (mode1 == VOIDmode)
> /* Bitfield. */
> mode1 = smallest_mode_for_size (bitsize, MODE_INT);
> @@ -2736,6 +2738,12 @@ expand_debug_expr (tree exp)
> if (op0 == orig_op0)
> op0 = shallow_copy_rtx (op0);
> set_mem_attributes (op0, exp, 0);
> + mem_exp = fold (exp);
> + if (!SSA_VAR_P (mem_exp)
> + && TREE_CODE (mem_exp) != MEM_REF
> + && TREE_CODE (mem_exp) != TARGET_MEM_REF)
> + mem_exp = NULL_TREE;
> + set_mem_expr (op0, mem_exp);
That will, for the testcase drop the MEM[&t.s].w completely, right?
I think you eventually want to use maybe_fold_reference which does
canonicalize mem-refs after propagation (but also watch for bogus
debug information due to constant folding of initializers I
ran into because of setting DECL_INITIAL to error_mark_node for
unused globals - I'll try to dig up the patch I had to fix that).
Richard.
> }
>
> if (bitpos == 0 && mode == GET_MODE (op0))
> --- gcc/testsuite/gcc.dg/pr48134.c.jj 2011-03-16 22:04:35.0 +0100
> +++ gcc/testsuite/gcc.dg/pr48134.c 2011-03-16 22:02:13.0 +0100
> @@ -0,0 +1,25 @@
> +/* PR debug/48134 */
> +/* { dg-do compile } */
> +/* { dg-options "-O2 -fstack-check=specific -fno-tree-dse -fno-tree-fre
> -fno-tree-loop-optimize -g" } */
> +
> +struct S { int w, z; };
> +struct T { struct S s; };
> +int i;
> +
> +static inline struct S
> +bar (struct S x)
> +{
> + i++;
> + return x;
> +}
> +
> +int
> +foo (struct T t, struct S s)
> +{
> + struct S *c = &s;
> + if (i)
> + c = &t.s;
> + t.s.w = 3;
> + s = bar (*c);
> + return t.s.w;
> +}
>
> Jakub
>
Re: [patch i386,c,c++]: PR/12171 - calling convention omitted in error message
PING, ok for 4.7?
2011/1/4 Jason Merrill :
> On 01/01/2011 01:07 PM, Kai Tietz wrote:
>>
>> Well, as here no further agreement was found, I post here the
>> alternative suggested by Joseph. I am open-minded which approach will
>> be chosen. I just want to fix this long pending issue.
>> I split up this patch in two parts. The first simply extends the
>> struct attribute_spec by new member 'on_diagnostic' and extends the
>> the uses of this structure by this new field. This new member
>> specifies if the attribute shall be show on diagnostic output, or not.
>
> This seems like a reasonable approach, but I'd prefer to describe/name the
> field as indicating that the attribute affects type compatibility (since
> that's why we want to see the attribute in diagnostics), and making the
> default comp_type_attributes use that information.
>
> Jason
>
--
| (\_/) This is Bunny. Copy and paste
| (='.'=) Bunny into your signature to help
| (")_(") him gain world domination
Re: [libgfortran, patch] More than 26 temporary files with weak mktemp()
On Wed, Mar 16, 2011 at 23:50, FX wrote: >> If M$ mktemp when already 26 files exist with the same prefix at least >> properly fails, then it would be better to just retry with a changed prefix >> if it fails. > > > Done exactly that. Manually tested on i586-pc-mingw32, regtested on > x86_64-linux by editing config.h to fake the absence of mkstemp(). OK for > trunk? Some minor nits: - Use the type size_t for tempdirlen as that is the return type of strlen() and argument type for get_mem(). - You can use a const size_t variable for the length of the string "slash" rather than calling strlen() in the do-while loop. - Don't set errno as we anyway loop until we successfully open a file with O_CREAT|O_EXCL. With these changes, Ok for trunk (4.7, that is). -- Janne Blomqvist
[libgfortran, 4.6] Don't use clock_gettime on Tru64 UNIX (PR fortran/47571)
The conditional use of clock_gettime via weakrefs completely broke Fortran on Tru64 UNIX: while the function is available in librt, the platform doesn't support weakrefs, so every execution test fails due to the undefined symbol. While a proper patch is being tested for mainline (to be backported to 4.6.1), I'd like to get this workaround into the 4.6 branch. alpha-dec-osf5.1b bootstrap on the branch is still running, but so far only a few fortran tests fail (as they did before) and not all execution tests. Already approved by Janne Blomqvist in the PR, provided the RMs agree. Jakub, ok for the 4.6 branch once the bootstrap has finished successfully? Thanks. Rainer 2011-03-16 Rainer Orth PR fortran/47571 * intrinsics/system_clock.c [__alpha__ && __osf__] (HAVE_CLOCK_GETTIME): Undef. diff -r 3a5a11b25084 libgfortran/intrinsics/system_clock.c --- a/libgfortran/intrinsics/system_clock.c Tue Mar 15 12:05:24 2011 +0100 +++ b/libgfortran/intrinsics/system_clock.c Wed Mar 16 13:45:24 2011 +0100 @@ -29,6 +29,13 @@ #include "time_1.h" +/* Tru64 UNIX doesn't support weakrefs, so the trickery below completely + breaks libgfortran (PR fortran/47571). Don't use clock_gettime until a + proper solution has been tested. */ +#if defined(__alpha__) && defined(__osf__) +#undef HAVE_CLOCK_GETTIME +#endif + #ifdef HAVE_CLOCK_GETTIME /* POSIX states that CLOCK_REALTIME must be present if clock_gettime is available, others are optional. */ -- - Rainer Orth, Center for Biotechnology, Bielefeld University
Re: [libgfortran, 4.6] Don't use clock_gettime on Tru64 UNIX (PR fortran/47571)
On Thu, Mar 17, 2011 at 11:23:56AM +0100, Rainer Orth wrote: > The conditional use of clock_gettime via weakrefs completely broke > Fortran on Tru64 UNIX: while the function is available in librt, the > platform doesn't support weakrefs, so every execution test fails due to > the undefined symbol. While a proper patch is being tested for mainline > (to be backported to 4.6.1), I'd like to get this workaround into the > 4.6 branch. > > alpha-dec-osf5.1b bootstrap on the branch is still running, but so far > only a few fortran tests fail (as they did before) and not all > execution tests. > > Already approved by Janne Blomqvist in the PR, provided the RMs agree. > > Jakub, ok for the 4.6 branch once the bootstrap has finished > successfully? Ok, but for 4.6.1 and 4.7 please revert it and apply the real fix. > 2011-03-16 Rainer Orth > > PR fortran/47571 > * intrinsics/system_clock.c [__alpha__ && __osf__] > (HAVE_CLOCK_GETTIME): Undef. Jakub
RX: Adjust memory move cost
Hi Guys, I am applying the patch below to tweak the MEMORY_MOVE_COST macro for the RX port on the 4.5 branch. Writing to memory is actually faster than reading on the RX, so the cost can be reduced as shown. Cheers Nick gcc/ChangeLog 2011-03-17 Nick Clifton * config/rx/rx.h (MEMORY_MOVE_COST): Reduce the cost of stores. Index: gcc/config/rx/rx.h === --- gcc/config/rx/rx.h (revision 171086) +++ gcc/config/rx/rx.h (working copy) @@ -659,7 +659,8 @@ #define BRANCH_COST(SPEED, PREDICT) 1 #define REGISTER_MOVE_COST(MODE, FROM, TO)2 -#define MEMORY_MOVE_COST(MODE, REGCLASS, IN) (2 + memory_move_secondary_cost (MODE, REGCLASS, IN)) +#define MEMORY_MOVE_COST(MODE, REGCLASS, IN) \ + (((IN) ? 2 : 0) + memory_move_secondary_cost (MODE, REGCLASS, IN)) #define SELECT_CC_MODE(OP,X,Y) rx_select_cc_mode ((OP), (X), (Y))
Re: [Patch][AVR]: Support tail calls
2011/3/16 Georg-Johann Lay > > Richard Henderson schrieb: >> >> On 03/16/2011 03:32 AM, Georg-Johann Lay wrote: >> >>> Richard Henderson schrieb: >>> On 03/11/2011 05:43 AM, Georg-Johann Lay wrote: > I did not find a way to make this work together with -mcall-prologues. > Please let me know if you have suggestion on how call prologues can be > combine with tail calls. You need a new symbol in libgcc for this. It should be easy enough to have the sibcall epilogue load up Z+EIND before jumping to the new symbol (perhaps called __sibcall_restores__). This new symbol would be just like the existing __epilogue_restores__ except that it would finish with an eijmp/ijmp instruction (depending on multilib) instead of a ret instruction. >>> >>> The point is that the intent of -mprologue-saves is to save program >>> memory space (flash). If we load the callee's address in the epilogue, >>> the epilogue's size will increase. Moreover, adding an other lengthy >>> function besides __epilogue_restores__ to libgcc, that will increase >>> code size because in many cases we will see both epilogue flavors >>> being dragged into application. >> >> All true, but supposing there are enough tail calls then on balance >> you'll still save flash space. > > Only if epilogue size decreses. As tail-call saves at most 2 bytes and > storing the address (either return-to in epilogue or jump-to caller) will > take more than 2 bytes. So nothing is won. > >> An intermediate alternative is to simply override TARGET_CALL_PROLOGUES >> in sibcall epilogues. I.e. let __prologue_saves__ be generated as usual, >> and __epilogue_restores__ be generated as usual for normal epilogues, but >> test for sibcall_p in computing "minimize". > > This means that long epilogues that with call-prologues would deflate then > would no more deflate and had to be coded inline in epilogue. > > Maybe we can take the patch as-is, let approve it and fiddle out more > optimization opportunities later? Is it tested for regressions ? Denis.
Re: PR debug/47510
Yesterday after discussing this on IRC, Jakub expressed his personal opinion by saying the patch could go in 4.6. I mistakenly took it as a formal approval from the RMs and I committed it. I should have waited for an approval by email. So I have just reverted the patch from 4.6 now. Sorry for that. Back to the discussion now :-) Mark Mitchell writes: > On 3/16/2011 1:04 PM, Dodji Seketeli wrote: > >> Would the RMs (in CC) object to this patch going into 4.6? > What would be the justification for that? It's a regression from 4.5, caused by the fix for PR c++/44188. One of the observed side effect is that a DW_TAG_typedef DIE can now have children DIEs. That is not desirable in itself and makes GDB crash. > I don't see any evidence that this is a regression This is because the bug wasn't flagged as a regression. It is now. > A bug that affects debugging is never *that* serious compared to (for > example) silent wrong-code generation. I agree that fixing silent wrong-code generation bugs is always paramount. But I believe that a bug that suddenly leads GDB to a crash is not something we would want to let happen at this point either. -- Dodji
Re: PR debug/47510
On Thu, 17 Mar 2011, Dodji Seketeli wrote: > Yesterday after discussing this on IRC, Jakub expressed his personal > opinion by saying the patch could go in 4.6. I mistakenly took it as a > formal approval from the RMs and I committed it. I should have waited > for an approval by email. So I have just reverted the patch from 4.6 > now. Sorry for that. > > Back to the discussion now :-) > > Mark Mitchell writes: > > > On 3/16/2011 1:04 PM, Dodji Seketeli wrote: > > > >> Would the RMs (in CC) object to this patch going into 4.6? > > > What would be the justification for that? > > It's a regression from 4.5, caused by the fix for PR c++/44188. One of > the observed side effect is that a DW_TAG_typedef DIE can now have > children DIEs. That is not desirable in itself and makes GDB crash. > > > I don't see any evidence that this is a regression > > This is because the bug wasn't flagged as a regression. It is now. > > > A bug that affects debugging is never *that* serious compared to (for > > example) silent wrong-code generation. > > I agree that fixing silent wrong-code generation bugs is always > paramount. But I believe that a bug that suddenly leads GDB to a crash > is not something we would want to let happen at this point either. I agree that crashing GDB isn't desirable, we should avoid that for 4.6.0. Richard.
Re: [V850] Hookize OUTPUT_ADDR_CONST_EXTRA
Hi Anatoly, * config/v850/v850.h (OUTPUT_ADDR_CONST_EXTRA): Remove. * config/v850/v850-protos.h (v850_output_addr_const_extra): Remove. * config/v850/v850.c (v850_output_addr_const_extra): Mace static. Change return type to bool. (TARGET_ASM_OUTPUT_ADDR_CONST_EXTRA): Define. Approved - please apply. Cheers Nick
Re: [4.7] Avoid global state in sparc_handle_option
> 2011-03-13 Joseph Myers > > * config/sparc/sparc-opts.h: New. Do you really need all the dates in there? > * config/sparc/sparc.c (sparc_handle_option, sparc_select, > sparc_cpu, fpu_option_set, TARGET_HANDLE_OPTION): Remove. > (sparc_option_override): Store processor_type enumeration rather > than string in cpu_default. Remove name and enumeration from > cpu_table. Directly default -mcpu then default -mtune from -mcpu > without using sparc_select. Use target_flags_explicit instead of > fpu_option_set. > * config/sparc/sparc.h (enum processor_type): Move to > sparc-opts.h. > (sparc_cpu, struct sparc_cpu_select, sparc_select): Remove. > * config/sparc/sparc.opt (config/sparc/sparc-opts.h): New > HeaderInclude entry. > (mcpu=, mtune=): Use Var and Enum. > (sparc_processor_type): New Enum and EnumValue entries. The sparc_cpu/sparc_cpu_option naming is confusing. What about replacing the latter with sparc_cpu_and_features or something along these lines? Otherwise looks good, thanks. -- Eric Botcazou
Re: [wwwdocs] gcc-4.6/porting_to.html
On Wed, 16 Mar 2011 23:51:30 -0700 Benjamin Kosnik wrote: > Needs some more work, here's a rough draft. The one I've seen most often other than including cstddef is due to linker options starting with -- (eg. --export-dynamic, --no-undefined) now being errors. Previously they were just silently ignored. The fix of course is to prepend "-Wl," to these flags. http://gcc.gnu.org/PR46410 -- fonts, gcc-porting, it makes no sense how it makes no sense toolchain, wxwidgets but i'll take it free anytime @ gentoo.orgEFFD 380E 047A 4B51 D2BD C64F 8AA8 8346 F9A4 0662 signature.asc Description: PGP signature
Re: [ARM] PR 47553: vld1q_lane_u8 & co. don't accept lanes >= 8
Hi Ramana, I am tempted to consider this one for the other release branches since this is correcting a test in the interface for an intrinsic which has been wrong for a long time but would like the opinion of the other maintainers about this. I think that I would agree with you here. Certainly I would not object if you wanted to apply the patch to the 4.5 branch. Cheers Nick
Re: RX: 4.5 branch: Fix alignment and addressing issues.
Hi Andrew, + (set_attr "length" "5")] ;; Worst case sceanario. FIXME: If we defined separate patterns +);; rather than using iterators we could specify exact sizes. You can set up the correct length even without using separate patterns. The problem is that the lengths depend upon an *two* iterators and the MEM involved as well. For example: (define_insn "*comparesi3_" [(set (reg:CC CC_REG) (compare:CC (match_operand:SI 0 "register_operand" "=r") (extend_types:SI (match_operand:small_int_modes 1 "rx_restricted_mem_operand" "Q"] "" "cmp\t%1, %0" [(set_attr "timings" "33") (set_attr "length" "5")] ;; Worst case sceanario. FIXME: This insn is 2 bytes long if operand[1] is just MEM (REG) (ie no offset) *and* the extend_types is zero-extend. It is 3 bytes long if operands[1] is MEM (REG) and the extend_types is sign-extend. It is also 3 bytes long if operands[1] is MEM (REG+INT) and the INT is < 256 (for QImode extensions) or less than (256 * 2) for HImode extensions and the extend type is zero-extend. It is 4 bytes long if ... [snip - you get the idea]. So really I think that I should be defining the ADJUST_INSN_LENGTH macro to handle these patterns. I'll look into that. Cheers Nick
[Ada] Avoid too large read generated for complex packed array type
This change prevents the compiler from generating too large reads (typically a
few bytes, essentially only visible with valgrind) when it is manipulating
complex packed array types.
Tested on i586-suse-linux, applied on the mainline.
2011-03-17 Eric Botcazou
* gcc-interface/gigi.h (smaller_form_type_p): Declare.
* gcc-interface/trans.c (smaller_form_type_p): Make global and move...
* gcc-interface/utils.c (smaller_form_type_p): ...to here.
(convert): Deal with conversions from a smaller form type specially.
--
Eric Botcazou
Index: gcc-interface/utils.c
===
--- gcc-interface/utils.c (revision 170943)
+++ gcc-interface/utils.c (working copy)
@@ -4043,6 +4043,18 @@ convert (tree type, tree expr)
} while (TREE_CODE (child_etype) == RECORD_TYPE);
}
+ /* If we are converting from a smaller form of record type back to it, just
+ make a VIEW_CONVERT_EXPR. But first pad the expression to have the same
+ size on both sides. */
+ else if (ecode == RECORD_TYPE && code == RECORD_TYPE
+ && smaller_form_type_p (etype, type))
+{
+ expr = convert (maybe_pad_type (etype, TYPE_SIZE (type), 0, Empty,
+ false, false, false, true),
+ expr);
+ return build1 (VIEW_CONVERT_EXPR, type, expr);
+}
+
/* In all other cases of related types, make a NOP_EXPR. */
else if (TYPE_MAIN_VARIANT (type) == TYPE_MAIN_VARIANT (etype))
return fold_convert (type, expr);
@@ -4672,6 +4684,30 @@ type_for_nonaliased_component_p (tree gn
return true;
}
+/* Return true if TYPE is a smaller form of ORIG_TYPE. */
+
+bool
+smaller_form_type_p (tree type, tree orig_type)
+{
+ tree size, osize;
+
+ /* We're not interested in variants here. */
+ if (TYPE_MAIN_VARIANT (type) == TYPE_MAIN_VARIANT (orig_type))
+return false;
+
+ /* Like a variant, a packable version keeps the original TYPE_NAME. */
+ if (TYPE_NAME (type) != TYPE_NAME (orig_type))
+return false;
+
+ size = TYPE_SIZE (type);
+ osize = TYPE_SIZE (orig_type);
+
+ if (!(TREE_CODE (size) == INTEGER_CST && TREE_CODE (osize) == INTEGER_CST))
+return false;
+
+ return tree_int_cst_lt (size, osize) != 0;
+}
+
/* Perform final processing on global variables. */
void
Index: gcc-interface/gigi.h
===
--- gcc-interface/gigi.h (revision 170943)
+++ gcc-interface/gigi.h (working copy)
@@ -756,6 +756,9 @@ extern bool is_double_scalar_or_array (E
component of an aggregate type. */
extern bool type_for_nonaliased_component_p (tree gnu_type);
+/* Return true if TYPE is a smaller form of ORIG_TYPE. */
+extern bool smaller_form_type_p (tree type, tree orig_type);
+
/* Return the base type of TYPE. */
extern tree get_base_type (tree type);
Index: gcc-interface/trans.c
===
--- gcc-interface/trans.c (revision 170943)
+++ gcc-interface/trans.c (working copy)
@@ -205,7 +205,6 @@ static tree emit_check (tree, tree, int,
static tree build_unary_op_trapv (enum tree_code, tree, tree, Node_Id);
static tree build_binary_op_trapv (enum tree_code, tree, tree, tree, Node_Id);
static tree convert_with_check (Entity_Id, tree, bool, bool, bool, Node_Id);
-static bool smaller_form_type_p (tree, tree);
static bool addressable_p (tree, tree);
static tree assoc_to_constructor (Entity_Id, Node_Id, tree);
static tree extract_values (tree, tree);
@@ -7222,30 +7221,6 @@ convert_with_check (Entity_Id gnat_type,
return convert (gnu_type, gnu_result);
}
-/* Return true if TYPE is a smaller form of ORIG_TYPE. */
-
-static bool
-smaller_form_type_p (tree type, tree orig_type)
-{
- tree size, osize;
-
- /* We're not interested in variants here. */
- if (TYPE_MAIN_VARIANT (type) == TYPE_MAIN_VARIANT (orig_type))
-return false;
-
- /* Like a variant, a packable version keeps the original TYPE_NAME. */
- if (TYPE_NAME (type) != TYPE_NAME (orig_type))
-return false;
-
- size = TYPE_SIZE (type);
- osize = TYPE_SIZE (orig_type);
-
- if (!(TREE_CODE (size) == INTEGER_CST && TREE_CODE (osize) == INTEGER_CST))
-return false;
-
- return tree_int_cst_lt (size, osize) != 0;
-}
-
/* Return true if GNU_EXPR can be directly addressed. This is the case
unless it is an expression involving computation or if it involves a
reference to a bitfield or to an object not sufficiently aligned for
Re: [PATCH] Ensure DEBUG_INSNs don't contain MEMs with non-canonical MEM_EXPRs (PR debug/48134)
On Thu, Mar 17, 2011 at 9:41 AM, Richard Guenther
wrote:
> On Thu, Mar 17, 2011 at 12:32 AM, Jakub Jelinek wrote:
>> Hi!
>>
>> Currently expand_debug_expr doesn't always guarantee canonical
>> MEM_EXPRs, if MEM_EXPR isn't canonical, sometimes aliasing code ICEs on it
>> (since recent Richard's change fortunately only if --enable-checking=yes).
>>
>> The following patch canonicalizes those using fold and if canonicalization
>> isn't successful, just clears the MEM_EXPR.
>>
>> Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk and
>> 4.6.1?
>>
>> 2011-03-17 Jakub Jelinek
>>
>> PR debug/48134
>> * cfgexpand.c (expand_debug_expr) : Use fold to
>> canonicalize MEM_EXPR, if it still isn't canonical afterwards, just
>> clear MEM_EXPR.
>>
>> * gcc.dg/pr48134.c: New test.
>>
>> --- gcc/cfgexpand.c.jj 2011-03-16 18:30:12.0 +0100
>> +++ gcc/cfgexpand.c 2011-03-16 22:05:13.0 +0100
>> @@ -2712,6 +2712,8 @@ expand_debug_expr (tree exp)
>>
>> if (MEM_P (op0))
>> {
>> + tree mem_exp;
>> +
>> if (mode1 == VOIDmode)
>> /* Bitfield. */
>> mode1 = smallest_mode_for_size (bitsize, MODE_INT);
>> @@ -2736,6 +2738,12 @@ expand_debug_expr (tree exp)
>> if (op0 == orig_op0)
>> op0 = shallow_copy_rtx (op0);
>> set_mem_attributes (op0, exp, 0);
>> + mem_exp = fold (exp);
>> + if (!SSA_VAR_P (mem_exp)
>> + && TREE_CODE (mem_exp) != MEM_REF
>> + && TREE_CODE (mem_exp) != TARGET_MEM_REF)
>> + mem_exp = NULL_TREE;
>> + set_mem_expr (op0, mem_exp);
>
> That will, for the testcase drop the MEM[&t.s].w completely, right?
> I think you eventually want to use maybe_fold_reference which does
> canonicalize mem-refs after propagation (but also watch for bogus
> debug information due to constant folding of initializers I
> ran into because of setting DECL_INITIAL to error_mark_node for
> unused globals - I'll try to dig up the patch I had to fix that).
I am testing the following.
Richard.
fix-pr48134
Description: Binary data
[PATCH] Fix PR48165
This fixes PR48165, we need to properly return sizetype quantities from
compute_object_offset.
Bootstrapped and tested on x86_64-unknown-linux-gnu, applied to trunk
and the branch.
Richard.
2011-03-17 Richard Guenther
PR middle-end/48165
* tree-object-size.c (compute_object_offset): Properly return
the offset operand of MEM_REFs as sizetype.
* g++.dg/torture/pr48165.C: New testcase.
Index: gcc/tree-object-size.c
===
*** gcc/tree-object-size.c (revision 171086)
--- gcc/tree-object-size.c (working copy)
*** compute_object_offset (const_tree expr,
*** 143,149
case MEM_REF:
gcc_assert (TREE_CODE (TREE_OPERAND (expr, 0)) == ADDR_EXPR);
! return TREE_OPERAND (expr, 1);
default:
return error_mark_node;
--- 143,149
case MEM_REF:
gcc_assert (TREE_CODE (TREE_OPERAND (expr, 0)) == ADDR_EXPR);
! return double_int_to_tree (sizetype, mem_ref_offset (expr));
default:
return error_mark_node;
Index: gcc/testsuite/g++.dg/torture/pr48165.C
===
*** gcc/testsuite/g++.dg/torture/pr48165.C (revision 0)
--- gcc/testsuite/g++.dg/torture/pr48165.C (revision 0)
***
*** 0
--- 1,38
+ /* { dg-do compile } */
+
+ typedef __SIZE_TYPE__ size_t;
+
+ extern "C" {
+ extern __inline __attribute__ ((__always_inline__))
+ __attribute__ ((__gnu_inline__, __artificial__)) void *
+ memcpy (void *__restrict __dest, __const void *__restrict __src,
+ size_t __len) throw ()
+ {
+ return __builtin___memcpy_chk (__dest, __src, __len,
+ __builtin_object_size (__dest, 0));
+ }
+ }
+
+ typedef char TCODE[20];
+ typedef TCODE TCODE_ARRAY[5];
+ typedef struct PARAM
+ {
+ TCODE_ARRAY tcode;
+ } PARAM;
+
+ static void foo (void* p)
+ {
+ char buffer[4+sizeof(PARAM)];
+ PARAM *param = (PARAM *)(buffer + 4);
+ int i;
+
+ for (i=0; i < 5; i++)
+ {
+ memcpy( param->tcode[i], p, 20 );
+ }
+ }
+
+ void bar (void* p)
+ {
+ foo (p);
+ }
[PATCH] Fix PR48148
This fixes PR48148, we shouldn't keep abstract origin references
for external decls.
Bootstrapped and tested on x86_64-unknown-linux-gnu, applied.
Richard.
2011-03-17 Richard Guenther
PR bootstrap/48148
* lto-cgraph.c (input_overwrite_node): Clear the abstract
origin for decls in other ltrans units.
(input_varpool_node): Likewise.
Index: gcc/lto-cgraph.c
===
--- gcc/lto-cgraph.c(revision 171091)
+++ gcc/lto-cgraph.c(working copy)
@@ -975,6 +975,7 @@ input_overwrite_node (struct lto_file_de
|| node->clone_of->decl != node->decl))
{
DECL_EXTERNAL (node->decl) = 1;
+ DECL_ABSTRACT_ORIGIN (node->decl) = NULL_TREE;
TREE_STATIC (node->decl) = 0;
}
node->alias = bp_unpack_value (bp, 1);
@@ -1146,6 +1147,7 @@ input_varpool_node (struct lto_file_decl
if (node->in_other_partition)
{
DECL_EXTERNAL (node->decl) = 1;
+ DECL_ABSTRACT_ORIGIN (node->decl) = NULL_TREE;
TREE_STATIC (node->decl) = 0;
}
aliases_p = bp_unpack_value (&bp, 1);
Re: [PING][PATCH] Cleanup, use bitmap_set_range/bitmap_clear_range instead of bitmap_set_bit/bitmap_clear_bit loops.
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 03/16/11 15:32, Anatoly Sokolov wrote: > Hello. > >> On 12/08/10 11:46, Anatoly Sokolov wrote: >>> Hi. >>> >>>This patch converts loops of bitmap_set_bit/bitmap_clear_bit in to >>> bitmap_set_range/bitmap_clear_range functions call. >>> >>>The patch has been bootstrapped on and regression tested on >>> x86_64-unknown-linux-gnu for c. >>> >>>OK to install? >>> >>> * cfgcleanup.c (mark_effect): Use >>> bitmap_set_range/bitmap_clear_range >>> instead of loop. Use HARD_REGISTER_NUM_P predicate. >>> * haifa-sched.c (setup_ref_regs): Ditto. >>> * caller-save.c (add_used_regs_1): Ditto. >>> * dse.c (look_for_hardregs): Ditto. >>> * df-problems.c (df_simulate_one_insn_forwards): Ditto. >>> * sched-rgn.c (check_live_1): Ditto. >> This looks like a reasonable cleanup, but I can't see how this fixes >> any kind of bug, so it should be postponed until stage1 reopens. If >> you could attach it to the GCC 4.7 pending patches metabug that would >> help ensure it doens't get lost. >> > > > http://gcc.gnu.org/ml/gcc-patches/2010-12/msg00686.html > OK to commit? Yes. Please go ahead and commit. Thanks, Jeff -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/ iQEcBAEBAgAGBQJNggvXAAoJEBRtltQi2kC7fbsH/0jO7ZgdD1srfPKi1mM0Os30 uR7I5R3lwh4i5q/+ENVG+7CLrL6TkvicYUo4Zm56kg82Cpj0UWt28y2jirBVtGaT gDAtV3kclzek5EspOizFKAc+0Ws0qpsnWITFBsyej7LxnpHVyqNzd+J8x43fDjYx ZCuohQ+Q0hP4ROofM2UpgpQZqkzmL2roAekIId3va1i8PJxEcMYBUDl3tlUF2ciN Fa7qdI0qwU/celFKz8a2/gguhq1f3KvD/tZ3ArhHH2GLsAxbfsud3EebKcZx3OkD /1/XOSpMyic/to5J6y8hnGglTOPmdvsWZ5nJ5pY+i8J5Atisod7JZm6KtGaZcGg= =J+wW -END PGP SIGNATURE-
Re: [PATCH] Fix PR48148
On Thu, Mar 17, 2011 at 6:24 AM, Richard Guenther wrote: > > This fixes PR48148, we shouldn't keep abstract origin references > for external decls. > > Bootstrapped and tested on x86_64-unknown-linux-gnu, applied. > > Richard. > > 2011-03-17 Richard Guenther > > PR bootstrap/48148 > * lto-cgraph.c (input_overwrite_node): Clear the abstract > origin for decls in other ltrans units. > (input_varpool_node): Likewise. > Bootstrap also failed with bootstrap-profiled, but without LTO. I don't see how it can fix it. -- H.J.
Re: [libgfortran, 4.6] Don't use clock_gettime on Tru64 UNIX (PR fortran/47571)
Jakub Jelinek writes: >> Jakub, ok for the 4.6 branch once the bootstrap has finished >> successfully? > > Ok, but for 4.6.1 and 4.7 please revert it and apply the real fix. I think Janne meant to apply the real fix to 4.7, so I can keep the workaround locally for mainline. I just wanted to avoid releasing 4.6.0 with Fortran completely broken. Rainer
[doc] Update install.texi for Solaris 2, IRIX, Tru64 UNIX
I've just reviewed install.texi for my platforms and found it mostly
accurate. A few minor changes are desirable for the 4.6 release, but
also apply to mainline since the file is identical there:
* Update recommendations to binutils 2.21 since this is what I've been
testing.
* Remove download URL for Sun Studio compilers since AFAIK we're not
supposed to link to non-free software.
Tested with make doc/gccinstall.info doc/gccinstall.pdf
`pwd`/HTML/gcc-4.7.0/gccinstall/index.html (the latter seems a bit
contorted to regen just a single html document) and visually inspection.
Ok for mainline and 4.6 branch?
Rainer
2011-03-16 Rainer Orth
gcc:
* doc/install.texi (Specific, alpha*-dec-osf5.1): Update for
binutils 2.21.
(Specific, i?86-*-solaris2.[89]): Likewise.
(Specific, i?86-*-solaris2.10): Likewise.
(Specific, mips-sgi-irix6): Likewise.
(Specific, *-*-solaris2*): Remove Sun Studio download URL.
Update for binutils 2.21.
diff -r 86718f6d9f54 gcc/doc/install.texi
--- a/gcc/doc/install.texi Wed Mar 16 08:40:07 2011 +
+++ b/gcc/doc/install.texi Wed Mar 16 19:03:28 2011 +0100
@@ -3102,7 +3102,7 @@
the OS version used, you need a data segment size between 512 MB and
1 GB, so simply use @command{ulimit -Sd unlimited}.
-As of GNU binutils 2.20.1, neither GNU @command{as} nor GNU @command{ld}
+As of GNU binutils 2.21, neither GNU @command{as} nor GNU @command{ld}
are supported on Tru64 UNIX, so you must not configure GCC with
@option{--with-gnu-as} or @option{--with-gnu-ld}.
@@ -3534,7 +3534,7 @@
While GCC works around them, several features are missing, so it is
@c FIXME: which ones?
recommended to use the GNU assembler instead. There is no bundled
-version, but the current version, from GNU binutils 2.20.1, is known to
+version, but the current version, from GNU binutils 2.21, is known to
work.
Solaris@tie{}2/x86 doesn't support the execution of SSE/SSE2 instructions
@@ -3560,7 +3560,7 @@
@file{/usr/sfw/bin/gas}. The versions included in Solaris 10, from GNU
binutils 2.15, and Solaris 11, from GNU binutils 2.19, work fine,
although the current version, from GNU binutils
-2.20.1, is known to work, too. Recent versions of the Sun assembler in
+2.21, is known to work, too. Recent versions of the Sun assembler in
@file{/usr/ccs/bin/as} work almost as well, though.
@c FIXME: as patch requirements?
@@ -3568,7 +3568,7 @@
linker instead, which is available in @file{/usr/sfw/bin/gld}, note that
due to a packaging bug the version in Solaris 10, from GNU binutils
2.15, cannot be used, while the version in Solaris 11, from GNU binutils
-2.19, works, as does the latest version, from GNU binutils 2.20.1.
+2.19, works, as does the latest version, from GNU binutils 2.21.
To use GNU @command{as}, configure with the options
@option{--with-gnu-as --with-as=@//usr/@/sfw/@/bin/@/gas}. It may be necessary
@@ -3997,7 +3997,7 @@
have the 64-bit libraries installed.
GCC must be configured with GNU @command{as}. The latest version, from GNU
-binutils 2.20.1, is known to work. On the other hand, bootstrap fails
+binutils 2.21, is known to work. On the other hand, bootstrap fails
with GNU @command{ld} at least since GNU binutils 2.17.
The @option{--enable-libgcj}
@@ -4140,8 +4140,7 @@
Support for Solaris 7 has been removed in GCC 4.6.
Sun does not ship a C compiler with Solaris 2, though you can download
-the Sun Studio compilers for free from
-@uref{http://developers.sun.com/sunstudio/downloads/}. Alternatively,
+the Sun Studio compilers for free. Alternatively,
you can install a pre-built GCC to bootstrap and install GCC. See the
@uref{binaries.html,,binaries page} for details.
@@ -4184,7 +4183,7 @@
conjunction with the Sun linker. The GNU @command{as}
versions included in Solaris 10, from GNU binutils 2.15, and Solaris 11,
from GNU binutils 2.19, are known to work. They can be found in
-@file{/usr/sfw/bin/gas}. Current versions of GNU binutils (2.20.1)
+@file{/usr/sfw/bin/gas}. Current versions of GNU binutils (2.21)
are known to work as well. Note that your mileage may vary
if you use a combination of the GNU tools and the Sun tools: while the
combination GNU @command{as} + Sun @command{ld} should reasonably work,
@@ -4193,7 +4192,7 @@
@c FIXME: still?
GNU @command{ld} usually works as well, although the version included in
Solaris 10 cannot be used due to several bugs. Again, the current
-version (2.20.1) is known to work, but generally lacks platform specific
+version (2.21) is known to work, but generally lacks platform specific
features, so better stay with Sun @command{ld}.
To enable symbol versioning in @samp{libstdc++} with Sun @command{ld},
--
-
Rainer Orth, Center for Biotechnology, Bielefeld University
Re: [wwwdocs] gcc-4.6/porting_to.html
On 17.03.2011 07:51, Benjamin Kosnik wrote: > > Needs some more work, here's a rough draft. > > -benjamin + As a workaround, remove -Werror until the new warnings + are fixed, or for conversion warnings + add -Wno-unused-but-set-variable + or -Wno-unused-but-set-parameter. + what about recommending keeping -Werror and adding -Wno-error=unused-but-set-variable or -Wno-error=unused-but-set-parameter? Then the warnings remain, but don't cause an error. Matthias
Re: [PATCH][i386] Implement ix86_emit_swdivsf more efficiently
Hi, On Mon, 14 Mar 2011, Richard Guenther wrote: > This rewrites the iteration step of swdivsf to be more register > efficient (two registers instead of four, no load of a FP constant). > This matches how ICC emits the rcp sequence and causes no overall loss > of precision (Micha might still remember the exact details). I haven't done a full error analysis for the intermediate rounding steps, but merely a statistical analysis for a subset of dividends and the full set of divisors. On AMD and Intel processors (that matters because rcpss accuracy is different on both) the sum of all absolute errors between the quotient as from divss and the quotients from either our old and the new method is better for the new method. The max error is 2ulps in each case. Ciao, Michael.
Re: [patch] Enhance conditional store sinking
On Wed, Mar 16, 2011 at 12:47 PM, Ira Rosen wrote:
> On 16 March 2011 12:29, Richard Guenther wrote:
>> On Wed, Mar 16, 2011 at 7:49 AM, Ira Rosen wrote:
>>> Hi,
>>>
>>> This patch adds a support of conditional store sinking for cases with
>>> multiple data references in then and else basic blocks. The
>>> correctness of the transformation is checked by verifying that there
>>> are no read-after-write and write-after-write dependencies.
>>>
>>> Bootstrapped and tested on powerpc64-suse-linux.
>>> OK for trunk?
>>
>> I will look at the patch later, but can you add a testcase that we don't sink
>>
>> if (..)
>> {
>> *a = i;
>> *b = j;
>> }
>> else
>> {
>> *b = j;
>> *a = i;
>> }
>>
>> if *a and *b may alias?
>
> Done.
Comments inline
> Thanks,
> Ira
>
> ChangeLog:
>
> * tree-data-ref.c (dr_equal_offsets_p1): Moved and renamed from
> tree-vect-data-refs.c vect_equal_offsets.
> (dr_equal_offsets_p): New function.
> * tree-data-ref.h (dr_equal_offsets_p): Declare.
> * tree-vect-data-refs.c (vect_equal_offsets): Move to tree-data-ref.c.
> (vect_drs_dependent_in_basic_block): Update calls to vect_equal_offsets.
> (vect_check_interleaving): Likewise.
> * tree-ssa-phiopt.c: Include cfgloop.h and tree-data-ref.h.
> (cond_if_else_store_replacement): Rename to...
> (cond_if_else_store_replacement_1): ... this. Change arguments and
> documentation.
> (cond_if_else_store_replacement): New function.
> * Makefile.in (tree-ssa-phiopt.o): Adjust dependencies.
>
> testsuite/ChangeLog:
>
> * gcc.dg/vect/vect-cselim-1.c: New test.
> * gcc.dg/vect/vect-cselim-2.c: New test.
>
>
> Index: tree-data-ref.c
> ===
> --- tree-data-ref.c (revision 170712)
> +++ tree-data-ref.c (working copy)
> @@ -991,6 +991,48 @@ create_data_ref (loop_p nest, loop_p loop, tree me
> return dr;
> }
>
> +/* Check if OFFSET1 and OFFSET2 (DR_OFFSETs of some data-refs) are identical
> + expressions. */
> +static bool
> +dr_equal_offsets_p1 (tree offset1, tree offset2)
> +{
> + bool res;
> +
> + STRIP_NOPS (offset1);
> + STRIP_NOPS (offset2);
> +
> + if (offset1 == offset2)
> + return true;
> +
> + if (TREE_CODE (offset1) != TREE_CODE (offset2)
> + || (!BINARY_CLASS_P (offset1) && !UNARY_CLASS_P (offset1)))
> + return false;
> +
> + res = dr_equal_offsets_p1 (TREE_OPERAND (offset1, 0),
> + TREE_OPERAND (offset2, 0));
> +
> + if (!res || !BINARY_CLASS_P (offset1))
> + return res;
> +
> + res = dr_equal_offsets_p1 (TREE_OPERAND (offset1, 1),
> + TREE_OPERAND (offset2, 1));
> +
> + return res;
> +}
> +
> +/* Check if DRA and DRB have equal offsets. */
> +bool
> +dr_equal_offsets_p (struct data_reference *dra,
> + struct data_reference *drb)
> +{
> + tree offset1, offset2;
> +
> + offset1 = DR_OFFSET (dra);
> + offset2 = DR_OFFSET (drb);
> +
> + return dr_equal_offsets_p1 (offset1, offset2);
> +}
> +
> /* Returns true if FNA == FNB. */
>
> static bool
> Index: tree-data-ref.h
> ===
> --- tree-data-ref.h (revision 170712)
> +++ tree-data-ref.h (working copy)
> @@ -430,6 +430,8 @@ extern void compute_all_dependences (VEC (data_ref
> extern void create_rdg_vertices (struct graph *, VEC (gimple, heap) *);
> extern bool dr_may_alias_p (const struct data_reference *,
> const struct data_reference *);
> +extern bool dr_equal_offsets_p (struct data_reference *,
> + struct data_reference *);
>
>
> /* Return true when the base objects of data references A and B are
> Index: tree-vect-data-refs.c
> ===
> --- tree-vect-data-refs.c (revision 170712)
> +++ tree-vect-data-refs.c (working copy)
> @@ -289,39 +289,6 @@ vect_update_interleaving_chain (struct data_refere
> }
> }
>
> -
> -/* Function vect_equal_offsets.
> -
> - Check if OFFSET1 and OFFSET2 are identical expressions. */
> -
> -static bool
> -vect_equal_offsets (tree offset1, tree offset2)
> -{
> - bool res;
> -
> - STRIP_NOPS (offset1);
> - STRIP_NOPS (offset2);
> -
> - if (offset1 == offset2)
> - return true;
> -
> - if (TREE_CODE (offset1) != TREE_CODE (offset2)
> - || (!BINARY_CLASS_P (offset1) && !UNARY_CLASS_P (offset1)))
> - return false;
> -
> - res = vect_equal_offsets (TREE_OPERAND (offset1, 0),
> - TREE_OPERAND (offset2, 0));
> -
> - if (!res || !BINARY_CLASS_P (offset1))
> - return res;
> -
> - res = vect_equal_offsets (TREE_OPERAND (offset1, 1),
> - TREE_OPERAND (offset2, 1));
> -
> - return res;
> -}
> -
> -
> /* Check dependence between DRA and DRB for basic block vectorization.
> If the accesses share same bases and offsets, we can compare their initial
Re: [PATCH] Don't emit entry_value/call_site stuff if -gstrict-dwarf (PR bootstrap/48153)
On 03/16/2011 04:20 PM, Jakub Jelinek wrote: > PR bootstrap/48153 > * dwarf2out.c (mem_loc_descriptor) : Return NULL > if dwarf_strict. > (gen_subprogram_die): Don't add call_site DIEs if dwarf_strict. > Clear call_arg_locations and call_arg_loc_last always. Ok. r~
Re: [PATCH] Fix prepare_call_arguments for types passed by reference (PR middle-end/48152)
On 03/16/2011 04:16 PM, Jakub Jelinek wrote: > PR middle-end/48152 > * var-tracking.c (prepare_call_arguments): If argument needs to be > passed by reference, adjust argtype and mode. Ok. r~
Re: [patch] Enhance conditional store sinking
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 03/17/11 08:48, Richard Guenther wrote: > > The gimple_uids are not initialized here, you need to make sure to > call renumber_gimple_stmt_uids () before starting. Note that phiopt > incrementally changes the IL, so I'm not sure those uids will stay > valid as stmts are moved across blocks. BTW, it's probably worth noting that renumber_gimple_stmt_uids doesn't assign UIDs for PHI nodes. Worse yet, someone might have called renumber_gimple_stmt_uids_in_blocks which *does* assign UIDs to PHIs. The net result is you can have a PHI with a UID that conflicts with a statement's UID or a PHI with no UID. It may not matter for this code, but having been recently bitten by this, I thought I'd mention it. jeff -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/ iQEcBAEBAgAGBQJNgiBoAAoJEBRtltQi2kC7dLMH+QEhaTqTxoqDnOeMFTb0OLLi 31BT3yDcSD0gEkFCZQB5qWo7RBBaepnRMtDpOxmGKcY8VlCvWdRDz6aFLlzDphzC XWD/M4i01Of0tjIlCJqDVsUZklD2dvPOz0pwQpX5fteoGNedNGp5Xwq72Wq5YRKW IcgpsRN/xbFA4HDk8ZfW5dkb+eQQptGHz5zj9KUz0pQbjqGS6e0oFIHCygwVW7u/ zhGuD16OhtNS6Z5gkVs9j1POZOSAb7GawB0p5W0lJigzqRfLPIYLuOjtgZrLdgXQ 3oK6uMX4WwZJK3PBT7Lo8MNTTnxjJZc4iL0SLArtd+U11QnxnsSIqKX9FBtX25A= =d7Vy -END PGP SIGNATURE-
[PATCH] Fix PR48134
This fixes PR48134, when propagating into debug-stmts we should fold
them, like we do elsewhere.
Bootstrapped and tested on x86_64-unknown-linux-gnu, applied to trunk.
Richard.
2011-03-17 Richard Guenther
PR middle-end/48134
* tree-ssa.c (insert_debug_temp_for_var_def): If we propagated
a value make sure to fold the statement.
* gcc.dg/pr48134.c: New testcase.
Index: gcc/tree-ssa.c
===
*** gcc/tree-ssa.c (revision 171086)
--- gcc/tree-ssa.c (working copy)
*** insert_debug_temp_for_var_def (gimple_st
*** 455,467
continue;
if (value)
! FOR_EACH_IMM_USE_ON_STMT (use_p, imm_iter)
! /* unshare_expr is not needed here. vexpr is either a
!SINGLE_RHS, that can be safely shared, some other RHS
!that was unshared when we found it had a single debug
!use, or a DEBUG_EXPR_DECL, that can be safely
!shared. */
! SET_USE (use_p, value);
else
gimple_debug_bind_reset_value (stmt);
--- 455,473
continue;
if (value)
! {
! FOR_EACH_IMM_USE_ON_STMT (use_p, imm_iter)
! /* unshare_expr is not needed here. vexpr is either a
! SINGLE_RHS, that can be safely shared, some other RHS
! that was unshared when we found it had a single debug
! use, or a DEBUG_EXPR_DECL, that can be safely
! shared. */
! SET_USE (use_p, value);
! /* If we didn't replace uses with a debug decl fold the
!resulting expression. Otherwise we end up with invalid IL. */
! if (TREE_CODE (value) != DEBUG_EXPR_DECL)
! fold_stmt_inplace (stmt);
! }
else
gimple_debug_bind_reset_value (stmt);
Index: gcc/testsuite/gcc.dg/pr48134.c
===
*** gcc/testsuite/gcc.dg/pr48134.c (revision 0)
--- gcc/testsuite/gcc.dg/pr48134.c (revision 0)
***
*** 0
--- 1,31
+ /* { dg-do compile } */
+ /* { dg-options "-O2 -fstack-check=specific -fno-tree-dse -fno-tree-fre
-fno-tree-loop-optimize -g" } */
+
+ struct S
+ {
+ int w, z;
+ };
+ struct T
+ {
+ struct S s;
+ };
+
+ int i;
+
+ static inline struct S
+ bar (struct S x)
+ {
+ i++;
+ return x;
+ }
+
+ int
+ foo (struct T t, struct S s)
+ {
+ struct S *c = &s;
+ if (i)
+ c = &t.s;
+ t.s.w = 3;
+ s = bar (*c);
+ return t.s.w;
+ }
Re: [patch] Enhance conditional store sinking
On Thu, Mar 17, 2011 at 3:53 PM, Jeff Law wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > On 03/17/11 08:48, Richard Guenther wrote: >> >> The gimple_uids are not initialized here, you need to make sure to >> call renumber_gimple_stmt_uids () before starting. Note that phiopt >> incrementally changes the IL, so I'm not sure those uids will stay >> valid as stmts are moved across blocks. > BTW, it's probably worth noting that renumber_gimple_stmt_uids doesn't > assign UIDs for PHI nodes. Worse yet, someone might have called > renumber_gimple_stmt_uids_in_blocks which *does* assign UIDs to PHIs. > The net result is you can have a PHI with a UID that conflicts with a > statement's UID or a PHI with no UID. > > It may not matter for this code, but having been recently bitten by > this, I thought I'd mention it. Yep ;) It's worth fixing this inconsistency btw. Richard. > > > jeff > -BEGIN PGP SIGNATURE- > Version: GnuPG v1.4.11 (GNU/Linux) > Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/ > > iQEcBAEBAgAGBQJNgiBoAAoJEBRtltQi2kC7dLMH+QEhaTqTxoqDnOeMFTb0OLLi > 31BT3yDcSD0gEkFCZQB5qWo7RBBaepnRMtDpOxmGKcY8VlCvWdRDz6aFLlzDphzC > XWD/M4i01Of0tjIlCJqDVsUZklD2dvPOz0pwQpX5fteoGNedNGp5Xwq72Wq5YRKW > IcgpsRN/xbFA4HDk8ZfW5dkb+eQQptGHz5zj9KUz0pQbjqGS6e0oFIHCygwVW7u/ > zhGuD16OhtNS6Z5gkVs9j1POZOSAb7GawB0p5W0lJigzqRfLPIYLuOjtgZrLdgXQ > 3oK6uMX4WwZJK3PBT7Lo8MNTTnxjJZc4iL0SLArtd+U11QnxnsSIqKX9FBtX25A= > =d7Vy > -END PGP SIGNATURE- >
Re: [patch][4.7] Enhance XOR handling in simplify-rtx.c
On 03/16/2011 06:55 PM, Chung-Lin Tang wrote: > You have to use DeMorgan's Law to distribute the ~ operator: Duh. Not sure where my head was yesterday. Let's enhance the comment for someone else having an off day. Perhaps /* Given (xor (and A B) C), using P^Q == ~P&Q | ~Q&P and DeMorgan's we can transform A&B ^ C == ~(A&B)&C | ~C&(A&B) == (~A|~B)&C | A&B&~C == ~A&C | ~B&C | A&B&~C Attempt a few simplifications when B and C are both constants. */ > + if (GET_CODE (op0) == AND > + && CONST_INT_P (op1) && CONST_INT_P (XEXP (op0, 1))) Should have a newline before the second && here. Ok with those changes. r~
[PATCH][RFC] Unify constant folding
This tries to move us towards a single constant-folding machinery
on gimple, usable by the various value-numbering passes we have
(CCP, VRP, SCCVN and eventually DOM, not yet in this patch). At
least VRP and SCCVN should in theory perform the same constant
propagations as CCP does but they do not at the moment which is
especially awkward as while there is a VRP pass after loop
optimizations a CCP pass is missing.
Thus, this patch makes VRP and SCCVN dispatch to the constant
folding implementation from CCP which is the most complete one.
For this valueization needs to be implementation dependent and
thus uses a callback function.
Starting from ccp_fold which is now gimple_fold_stmt_to_constant
(I probably should move it to gimple-fold.c) all dependent functions
also get the valueization callback. To avoid the overhead for
indirect function calls I have started to place the actual
implementations in header files as static inlines with the
theory that in each of the value-numbering implementations there
will be a single kind of valueization and thus IPA-CP should
de-virtualize them all (making it a C-like template case).
That's the part I'd like to get feedback on - the patch doesn't
yet move fold_const_aggregate_ref_1 or gimple_fold_stmt_to_constant_1
to a header file. Is this too ugly and do we just want to pay
the price of some indirect function calls?
get_addr_base_and_unit_offset_1 is used more widely throughout the
compiler, so I think that case is definitely worth the few
extra copies.
Tried re-bootstrapping and testing the following variant, but
bootstrap is currently broken.
Thanks,
Richard.
2011-03-17 Richard Guenther
PR tree-optimization/46562
* tree.c (build_invariant_address): New function.
* tree.h (build_invariant_address): Declare.
* tree-dfa.c (get_addr_base_and_unit_offset): Wrap around
a renamed function moved ...
* tree-flow-inline.h (get_addr_base_and_unit_offset_1): ... here.
Take valueization callback parameter.
* tree-flow.h (gimple_fold_stmt_to_constant): Declare.
* tree-ssa-ccp.c (gimple_fold_stmt_to_constant_1): New function
split out from ccp_fold. Take a valueization callback parameter.
Valueize all operands.
(gimple_fold_stmt_to_constant): New wrapper function.
(ccp_fold): Use gimple_fold_stmt_to_constant_1 for shared parts.
(fold_const_aggregate_ref_1): New function split out from
fold_const_aggregate_ref. Take a valueization callback parameter.
(fold_const_aggregate_ref): Wrap fold_const_aggregate_ref_1.
* tree-ssa-sccvn.c (simplify_binary_expression): Simplify
invariant POINTER_PLUS_EXPRs to invariant form.
(vn_valueize): New function.
(try_to_simplify): Simplify by using gimple_fold_stmt_to_constant.
* tree-vrp.c (vrp_valueize): New function.
(vrp_visit_assignment_or_call): Use gimple_fold_stmt_to_constant
to fold statements to constants.
* tree-ssa-pre.c (eliminate): Properly guard propagation of
function declarations.
* c-c++-common/pr46562-2.c: New testcase.
* c-c++-common/pr46562.c: Likewise.
Index: gcc/tree.c
===
*** gcc/tree.c.orig 2011-03-17 15:56:58.0 +0100
--- gcc/tree.c 2011-03-17 16:12:23.0 +0100
*** reference_alias_ptr_type (const_tree t)
*** 4013,4018
--- 4013,4032
return build_pointer_type (TYPE_MAIN_VARIANT (TREE_TYPE (base)));
}
+ /* Return an invariant ADDR_EXPR of type TYPE taking the address of BASE
+offsetted by OFFSET units. */
+
+ tree
+ build_invariant_address (tree type, tree base, HOST_WIDE_INT offset)
+ {
+ tree ref = fold_build2 (MEM_REF, TREE_TYPE (type),
+ build_fold_addr_expr (base),
+ build_int_cst (ptr_type_node, offset));
+ tree addr = build1 (ADDR_EXPR, type, ref);
+ recompute_tree_invariant_for_addr_expr (addr);
+ return addr;
+ }
+
/* Similar except don't specify the TREE_TYPE
and leave the TREE_SIDE_EFFECTS as 0.
It is permissible for arguments to be null,
Index: gcc/tree.h
===
*** gcc/tree.h.orig 2011-03-17 15:56:58.0 +0100
--- gcc/tree.h 2011-03-17 16:12:23.0 +0100
*** extern tree build_simple_mem_ref_loc (lo
*** 5094,5099
--- 5094,5100
build_simple_mem_ref_loc (UNKNOWN_LOCATION, T)
extern double_int mem_ref_offset (const_tree);
extern tree reference_alias_ptr_type (const_tree);
+ extern tree build_invariant_address (tree, tree, HOST_WIDE_INT);
extern tree constant_boolean_node (int, tree);
extern tree div_if_zero_remainder (enum tree_code, const_tree, const_tree);
Index: gcc/tree-flow-inline.h
===
*** gcc/tree-flow-inline.h.orig
Re: [PATCH] PR/Target 47998
At Wed, 16 Mar 2011 10:22:20 -0600,
Jeff Law wrote:
>
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> On 03/16/11 09:32, Yoshinori Sato wrote:
> > Hi All,
> >
> > This problem optimize rule missing.
> > gen_lowpart got invalid operand.
> >
> > I attached fix patch.
> >
> > diff --git a/gcc/ChangeLog b/gcc/ChangeLog
> > index ca9398c..9982644 100644
> > --- a/gcc/ChangeLog
> > +++ b/gcc/ChangeLog
> > @@ -1,3 +1,9 @@
> > +2011-03-16 Yoshinori Sato
> > +
> > + PR/target 47998
> > + * config/h8300/h8300.md
> > + (peephole): Add rule.
>
> It appears that you're restricting operands1 to be a REG/SUBREG, if
> that's what your intention is, then changing the operand predicate seems
> to be a better solution.
>
> Furthermore, you'd need to explain why restricting operand1 to be a
> REG/SUBREG is the right thing to do.
This rtl machied it.
(const:SI (plus:SI (symbol_ref:SI ("buf") )
(const_int 31 [0x1f])))
But gen_lowpart_general not supported this operand.
So assert test failed.
I think this rule is inapposite.
> It'd also be helpful to know why this problem does not occur on the
> trunk or gcc-4.6 branches, which appear to have the same code as the
> gcc-4.5 branch for the peephole.
Trunk is not happen in test case.
It generate other rtl.
> Jeff
> -BEGIN PGP SIGNATURE-
> Version: GnuPG v1.4.11 (GNU/Linux)
> Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/
>
> iQEcBAEBAgAGBQJNgOO8AAoJEBRtltQi2kC7Od0H/1P3Qp7e8idEu3WLdmHhsA6M
> R2KL7+UY1ZzLJpF8+cVjIVRfSTRGc+F8URtqIvaYxP3NJB+ZYiiSVE9jPxegSSDy
> /pqx0fLpQach0e4IcPzxFPg/HQkZBnwhW3bkCjxnUARH6hnbbIjFMxfBjJFAZQn+
> QghwaZRutJE6RirbxyqmzEoCzfO76aZ3OJQOxwGYpwsMjoNKFknls0wYXvV6xBBC
> +vyamc1hN+/g6X8OH7vfWEP6Q3E9rSrtan+2wCYBZvBXFYWjBbFEfZD94yg5VMbZ
> EFoSlmKZCn+c+bsop0T/jsUMBgy05Tv1orbdjsQ0aXKjsGusWlcboo6Is4Inonk=
> =Qmwv
> -END PGP SIGNATURE-
--
Yoshinori Sato
Re: RX: 4.5 branch: Fix alignment and addressing issues.
On 03/17/2011 05:31 AM, Nick Clifton wrote: > So really I think that I should be defining the ADJUST_INSN_LENGTH macro to > handle these patterns. I'll look into that. What is length used for in the rx port? I don't see any branch shortening going on here; out of range branches are completely handled by the assembler. You might be better off simply deleting the length attribute, so that the compiler skips the bulk of the shorten_branches pass. r~
Re: [patch i386,c,c++]: PR/12171 - calling convention omitted in error message
On 03/17/2011 04:46 AM, Kai Tietz wrote: PING, ok for 4.7? Did you have a response to my comment below? 2011/1/4 Jason Merrill: On 01/01/2011 01:07 PM, Kai Tietz wrote: Well, as here no further agreement was found, I post here the alternative suggested by Joseph. I am open-minded which approach will be chosen. I just want to fix this long pending issue. I split up this patch in two parts. The first simply extends the struct attribute_spec by new member 'on_diagnostic' and extends the the uses of this structure by this new field. This new member specifies if the attribute shall be show on diagnostic output, or not. This seems like a reasonable approach, but I'd prefer to describe/name the field as indicating that the attribute affects type compatibility (since that's why we want to see the attribute in diagnostics), and making the default comp_type_attributes use that information.
Re: C++ PATCH for c++/48089 (ICE with invalid constexpr ctor)
On 03/16/2011 11:44 PM, Gabriel Dos Reis wrote: I am not sure we need more infrastructure or more complexity in the implementation. The (C++98) language already requires us to initialize subobjects in their order of declaration. That is what we do here. All we need is to check that a member, whose value is being used in the initialization of another member (which might be itself like in this PR) is initialized. When we look up `this' in the evaluation environment, we can tell whether a particular slot has been initialized. Right, my point is that initialization and then lookup of that stored value is something that does not otherwise exist in constant expressions. Jason
[Patch] Disable -fstack-limit for bfin -mfdpic
-fstack-limit- is not supported for bfin with -mfdpic and crashes if you try to use it. The attached patch warns the user that -fstack-limit is ignored with the -mfdpic switch for Blackfin and then disables it. 2011-03-17 Stuart Henderson Originally From Bernd Schmidt * config/bfin/bfin.c (override_options): Disable -fstack-limit for FD-PIC. I don't have write permissions. Stu upstream.patch Description: upstream.patch
Re: PR45273 - The compiler depends on the host double
On 03/17/2011 01:35 AM, Richard Guenther wrote: >> Anyone a better suggestion for PRED_PRECISION? > > It at least seems you are introducing another host dependency here with using > HOST_BITS_PER_WIDE_INT. Why not simply use a fixed value of 32? Or 64, given that's the exact precision that sreal used. r~
C++ PATCH for c++/48166 (ICE with invalid function-cv-quals)
I missed one case where we needed to change cp_type_quals to
type_memfn_quals. After that fix we gave the correct error, but still
ICEd, so to avoid that I go ahead and strip the offending cv-quals.
Tested x86_64-pc-linux-gnu, applying to trunk, will apply to 4.6.1 after
4.6.0 release.
commit 3ac9d1e0b60a71e6ff154d4c8996ebedb7ba9652
Author: Jason Merrill
Date: Thu Mar 17 10:24:48 2011 -0400
PR c++/48166
* decl.c (revert_static_member_fn): Strip function-cv-quals.
diff --git a/gcc/cp/decl.c b/gcc/cp/decl.c
index a7da574..0985749 100644
--- a/gcc/cp/decl.c
+++ b/gcc/cp/decl.c
@@ -13344,10 +13344,14 @@ static_fn_type (tree memfntype)
void
revert_static_member_fn (tree decl)
{
- TREE_TYPE (decl) = static_fn_type (decl);
+ tree stype = static_fn_type (decl);
- if (cp_type_quals (TREE_TYPE (decl)) != TYPE_UNQUALIFIED)
-error ("static member function %q#D declared with type qualifiers", decl);
+ if (type_memfn_quals (stype) != TYPE_UNQUALIFIED)
+{
+ error ("static member function %q#D declared with type qualifiers",
decl);
+ stype = apply_memfn_quals (stype, TYPE_UNQUALIFIED);
+}
+ TREE_TYPE (decl) = stype;
if (DECL_ARGUMENTS (decl))
DECL_ARGUMENTS (decl) = DECL_CHAIN (DECL_ARGUMENTS (decl));
diff --git a/gcc/testsuite/g++.dg/parse/memfnquals1.C
b/gcc/testsuite/g++.dg/parse/memfnquals1.C
new file mode 100644
index 000..ce8af7b
--- /dev/null
+++ b/gcc/testsuite/g++.dg/parse/memfnquals1.C
@@ -0,0 +1,6 @@
+// PR c++/48166
+
+struct foo {
+ static void func ();
+};
+void foo::func () const {} // { dg-error "type qualifiers" }
Re: PR debug/47510
On 3/17/2011 4:08 AM, Dodji Seketeli wrote: > Yesterday after discussing this on IRC, Jakub expressed his personal > opinion by saying the patch could go in 4.6. I mistakenly took it as a > formal approval from the RMs and I committed it. I should have waited > for an approval by email. You don't have to apologize -- an approval from any RM, in any forum (IRC, email, etc.) is sufficient authorization. > It's a regression from 4.5, caused by the fix for PR c++/44188. And, in any case, if it's a regression it's OK with me. Thank you, -- Mark Mitchell CodeSourcery m...@codesourcery.com (650) 331-3385 x713
Re: [patch i386,c,c++]: PR/12171 - calling convention omitted in error message
2011/3/17 Jason Merrill : > On 03/17/2011 04:46 AM, Kai Tietz wrote: >> >> PING, ok for 4.7? > > Did you have a response to my comment below? > >> 2011/1/4 Jason Merrill: >>> >>> On 01/01/2011 01:07 PM, Kai Tietz wrote: Well, as here no further agreement was found, I post here the alternative suggested by Joseph. I am open-minded which approach will be chosen. I just want to fix this long pending issue. I split up this patch in two parts. The first simply extends the struct attribute_spec by new member 'on_diagnostic' and extends the the uses of this structure by this new field. This new member specifies if the attribute shall be show on diagnostic output, or not. >>> >>> This seems like a reasonable approach, but I'd prefer to describe/name >>> the >>> field as indicating that the attribute affects type compatibility (since >>> that's why we want to see the attribute in diagnostics), and making the >>> default comp_type_attributes use that information. > > I thought to use here instead of on_diagnostic (which is IMHO fine too as it indicates for now only that attribute shall be displayed on diagnostics) "affects_abi". I think it makes sense to keep that name as short as possible. Regards, Kai
Re: [patch i386,c,c++]: PR/12171 - calling convention omitted in error message
On 03/17/2011 12:08 PM, Kai Tietz wrote: I thought to use here instead of on_diagnostic (which is IMHO fine too as it indicates for now only that attribute shall be displayed on diagnostics) "affects_abi". I think it makes sense to keep that name as short as possible. Hmm, type compatibility is higher level than the ABI; it affects whether two declarations are considered to be the same. I think clarity is more important than a short name for something that shouldn't be used in that many places. I'd prefer "affects_type_identity". And does changing comp_type_attributes to check it make sense to you? Jason
C++ PATCH for core resolution 1212 (decltype of non-call xvalue)
Now that we have reasonable terminology for talking about expressions
involving rvalue references, we can ditch the clumsy rule about decltype
of a call in favor of just saying that decltype of an xvalue is an
rvalue reference.
Tested x86_64-pc-linux-gnu, applying to trunk.
commit 2ac0fa349f5a2c3bef8eda3ef73c550ee8d3e71b
Author: Jason Merrill
Date: Thu Mar 17 10:35:40 2011 -0400
Core 1212
* semantics.c (finish_decltype_type): Return T&& for xvalue.
* typeck.c (unlowered_expr_type): Preserve cv-quals.
diff --git a/gcc/cp/semantics.c b/gcc/cp/semantics.c
index 7519d26..cafca56 100644
--- a/gcc/cp/semantics.c
+++ b/gcc/cp/semantics.c
@@ -4787,7 +4787,6 @@ finish_decltype_type (tree expr, bool
id_expression_or_member_access_p)
&& processing_template_decl
&& TREE_CODE (expr) == COMPONENT_REF))
{
-treat_as_dependent:
type = cxx_make_type (DECLTYPE_TYPE);
DECLTYPE_TYPE_EXPR (type) = expr;
DECLTYPE_TYPE_ID_EXPR_OR_MEMBER_ACCESS_P (type)
@@ -4899,91 +4898,34 @@ finish_decltype_type (tree expr, bool
id_expression_or_member_access_p)
}
else
{
- /* Expressions of reference type are sometimes wrapped in
- INDIRECT_REFs. INDIRECT_REFs are just internal compiler
- representation, not part of the language, so we have to look
- through them. */
- if (TREE_CODE (expr) == INDIRECT_REF
- && TREE_CODE (TREE_TYPE (TREE_OPERAND (expr, 0)))
- == REFERENCE_TYPE)
-expr = TREE_OPERAND (expr, 0);
+ /* Within a lambda-expression:
- if (TREE_CODE (expr) == CALL_EXPR)
-{
- /* If e is a function call (5.2.2 [expr.call]) or an
- invocation of an overloaded operator (parentheses around e
- are ignored), decltype(e) is defined as the return type of
- that function. */
- tree fndecl = get_callee_fndecl (expr);
- if (fndecl && fndecl != error_mark_node)
-type = TREE_TYPE (TREE_TYPE (fndecl));
- else
-{
- tree target_type = TREE_TYPE (CALL_EXPR_FN (expr));
- if ((TREE_CODE (target_type) == REFERENCE_TYPE
- || TREE_CODE (target_type) == POINTER_TYPE)
- && (TREE_CODE (TREE_TYPE (target_type)) == FUNCTION_TYPE
- || TREE_CODE (TREE_TYPE (target_type)) == METHOD_TYPE))
-type = TREE_TYPE (TREE_TYPE (target_type));
- else if (processing_template_decl)
- /* Within a template finish_call_expr doesn't resolve
- CALL_EXPR_FN, so even though this decltype isn't really
- dependent let's defer resolving it. */
- goto treat_as_dependent;
- else
-sorry ("unable to determine the declared type of expression
%<%E%>",
- expr);
-}
-}
- else
-{
- type = is_bitfield_expr_with_lowered_type (expr);
- if (type)
-{
- /* Bitfields are special, because their type encodes the
- number of bits they store. If the expression referenced a
- bitfield, TYPE now has the declared type of that
- bitfield. */
- type = cp_build_qualified_type (type,
- cp_type_quals (TREE_TYPE
(expr)));
-
- if (real_lvalue_p (expr))
-type = build_reference_type (type);
-}
- /* Within a lambda-expression:
-
-Every occurrence of decltype((x)) where x is a possibly
-parenthesized id-expression that names an entity of
-automatic storage duration is treated as if x were
-transformed into an access to a corresponding data member
-of the closure type that would have been declared if x
-were a use of the denoted entity. */
- else if (outer_automatic_var_p (expr)
- && current_function_decl
- && LAMBDA_FUNCTION_P (current_function_decl))
- type = capture_decltype (expr);
- else
-{
- /* Otherwise, where T is the type of e, if e is an lvalue,
- decltype(e) is defined as T&, otherwise decltype(e) is
- defined as T. */
- type = TREE_TYPE (expr);
- if (type == error_mark_node)
-return error_mark_node;
- else if (expr == current_class_ptr)
-/* If the expression is just "this", we want the
- cv-unqualified pointer for the "this" type. */
-type = TYPE_MAIN_VARIANT (type);
- else if (real_lvalue_p (expr))
-{
- if (TREE_CODE (type) != REFERENCE_TYPE
- || TYPE_REF_IS_RVALUE (type))
-type = build_reference_type (n
Re: [patch i386,c,c++]: PR/12171 - calling convention omitted in error message
2011/3/17 Jason Merrill : > On 03/17/2011 12:08 PM, Kai Tietz wrote: >> >> I thought to use here instead of on_diagnostic (which is IMHO fine too >> as it indicates for now only that attribute shall be displayed on >> diagnostics) "affects_abi". I think it makes sense to keep that name >> as short as possible. > > Hmm, type compatibility is higher level than the ABI; it affects whether two > declarations are considered to be the same. I think clarity is more > important than a short name for something that shouldn't be used in that > many places. I'd prefer "affects_type_identity". I will update the patch and using this name > And does changing comp_type_attributes to check it make sense to you? Well, in general it would, but not all of those affecting type identity in 64-bit vs. 32-bit case. Most of them affect type identity only in 32-bit, but not for 64-bit )at least so for amd64/x86). So I don't think we will profit here much. Kai
Re: [AVR] Hookize LIBCALL_VALUE and FUNCTION_VALUE_REGNO_P
On 03/16/2011 02:46 PM, Georg-Johann Lay wrote:
> Anatoly Sokolov schrieb:
>
>> /* Returns register number for function return value.*/
>>
>> -int
>> +static inline int
>> avr_ret_register (void)
>> {
>>return 24;
>> }
>
> I always wondered why that works.
>
> SI is returned in r22..r25 (not in r24..27)
> DI is returnet in r18..r25 (not in r24..31)
>
> So according to docs, possible return regs are 18, 22, 24.
It doesn't, quite. But value_regno_p isn't used for much anymore.
Probably the most important thing remaining is in keep_with_call_p,
where we attempt to prevent the lifetime of a return value from
being extended too much.
Otherwise it's only used in __builtin_apply, which I continue to
hope we can eliminate.
Anyway, for the benefit of keep_with_call_p, you're best off matching
all register numbers between 18 and 25. That allows the Right Thing
to happen even if the DImode value is completely decomposed into its
QImode subregs.
Anatoly, I'll go ahead and approve the patch as-is, given that it is
an exact translation of the current state of the backend. Any logic
fixes to the backend can be done with separate patches.
r~
Re: RX: 4.5 branch: Fix alignment and addressing issues.
> What is length used for in the rx port? We have a local patch that uses the length to decide if/when to align labels; it goes along with the label alignment change I made a while back. However, the patch works best in 4.5 (align patch not backported) and there are other optimization problems with 4.6 that make the alignment not work as well as it should. The RX incurs a one-cycle penalty if you branch to an insn that spans a fetch line. So, we want to align by adding no more than N-1 bytes for an N-byte insn. A 3-byte insn will only be aligned if doing so adds 1 or 2 bytes; if 3 bytes are needed, the insn does not span a fetch line.
Re: PR debug/47510
Mark Mitchell writes: > And, in any case, if it's a regression it's OK with me. Thanks. I have committed the patch back into 4.6. -- Dodji
Re: [PATCH] PR/Target 47998
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 03/17/11 09:31, Yoshinori Sato wrote:
> At Wed, 16 Mar 2011 10:22:20 -0600,
> Jeff Law wrote:
>>
> On 03/16/11 09:32, Yoshinori Sato wrote:
Hi All,
This problem optimize rule missing.
gen_lowpart got invalid operand.
I attached fix patch.
diff --git a/gcc/ChangeLog b/gcc/ChangeLog
index ca9398c..9982644 100644
--- a/gcc/ChangeLog
+++ b/gcc/ChangeLog
@@ -1,3 +1,9 @@
+2011-03-16 Yoshinori Sato
+
+ PR/target 47998
+ * config/h8300/h8300.md
+ (peephole): Add rule.
>
> It appears that you're restricting operands1 to be a REG/SUBREG, if
> that's what your intention is, then changing the operand predicate seems
> to be a better solution.
>
> Furthermore, you'd need to explain why restricting operand1 to be a
> REG/SUBREG is the right thing to do.
>
>> This rtl machied it.
>> (const:SI (plus:SI (symbol_ref:SI ("buf") )
>> (const_int 31 [0x1f])))
>
>> But gen_lowpart_general not supported this operand.
>> So assert test failed.
>> I think this rule is inapposite.
OK. That's helpful. It seems to me that your change will cause poorer
code generation when operand1 is a MEM.
I think you can address this problem by changing the "general_operand"
predicate to "general_operand_dst". While the name
"general_operand_dst" is unfortunate given the proposed usage in the
peephole, I think it's the proper predicate. Using that should fix your
bug without causing poorer code generation.
I think you should fix the other closely related peepholes (there are 3
or 4 which do similar things and appear to all have the same underlying
problem allowing (const (plus ...)) then passing that operand to
gen_lowpart.
Jeff
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/
iQEcBAEBAgAGBQJNgju7AAoJEBRtltQi2kC77VAIAIirYQqVC22HsvpXD/03dRmd
clu8flmbwATTCpDcH1NqLJVE9rbKFKdyKhPKXtjO3LvhfVT8wtghXeeE1rddzjWQ
J64T7rMuB4sKSThlhLTkDUF2rByEijVwWlMsUIIHq5TXIkAaCHri/tFgCXou2pOr
+t+jVVjEscQS2x+swVqTOoQecPuwlzCS5iKcoEtvBcJARs2Bsj54sXwcrTaPxM9R
uI2U3f7Nh9aHhXYfk6dBjo4RNxud0Rr0giUbEEr2vyYLembJFJ58ghroADChe78p
bH1TBxtFJPCSI1umnEgarw/TXAEMfwKaoefmRsLsoNuUyLOiPZvrp/W5op+Q23Q=
=/+MT
-END PGP SIGNATURE-
[Ada] Fix ICE on declaration of discriminated record type
This is an internal error in self_referential_size on the code generated for
the elaboration of a discriminated record type which contains an array whose
upper bound depends on the discriminant and whose nominal subtype is an
unconstrained array type whose index type has a component of a constant
aggregate as upper bound. Pretty convoluted setup, but still.
Fixed in gigi by trying harder to prove that variables generated for the
elaboration of types are read-only.
Tested on i586-suse-linux, applied on the mainline.
2011-03-17 Eric Botcazou
* gcc-interface/decl.c (elaborate_expression_1): Try harder to find
out whether the expression is read-only. Short-circuit placeholder
case and rename a couple of local variables.
2011-03-17 Eric Botcazou
* gnat.dg/specs/elab2.ads: New test.
* gnat.dg/specs/elab2_pkg.ads: New helper.
--
Eric Botcazou
Index: gcc-interface/decl.c
===
--- gcc-interface/decl.c (revision 170943)
+++ gcc-interface/decl.c (working copy)
@@ -6003,15 +6003,9 @@ static tree
elaborate_expression_1 (tree gnu_expr, Entity_Id gnat_entity, tree gnu_name,
bool definition, bool need_debug)
{
- /* Skip any conversions and simple arithmetics to see if the expression
- is a read-only variable.
- ??? This really should remain read-only, but we have to think about
- the typing of the tree here. */
- tree gnu_inner_expr
-= skip_simple_arithmetic (remove_conversions (gnu_expr, true));
- tree gnu_decl = NULL_TREE;
- bool expr_global = Is_Public (gnat_entity) || global_bindings_p ();
- bool expr_variable;
+ const bool expr_global_p = Is_Public (gnat_entity) || global_bindings_p ();
+ bool expr_variable_p;
+ tree gnu_decl;
/* In most cases, we won't see a naked FIELD_DECL because a discriminant
reference will have been replaced with a COMPONENT_REF when the type
@@ -6023,39 +6017,62 @@ elaborate_expression_1 (tree gnu_expr, E
build0 (PLACEHOLDER_EXPR, DECL_CONTEXT (gnu_expr)),
gnu_expr, NULL_TREE);
- /* If GNU_EXPR is neither a placeholder nor a constant, nor a variable
- that is read-only, make a variable that is initialized to contain the
- bound when the package containing the definition is elaborated. If
- this entity is defined at top level and a bound or discriminant value
- isn't a constant or a reference to a discriminant, replace the bound
- by the variable; otherwise use a SAVE_EXPR if needed. Note that we
- rely here on the fact that an expression cannot contain both the
- discriminant and some other variable. */
- expr_variable = (!CONSTANT_CLASS_P (gnu_expr)
- && !(TREE_CODE (gnu_inner_expr) == VAR_DECL
- && (TREE_READONLY (gnu_inner_expr)
- || DECL_READONLY_ONCE_ELAB (gnu_inner_expr)))
- && !CONTAINS_PLACEHOLDER_P (gnu_expr));
-
- /* If GNU_EXPR contains a discriminant, we can't elaborate a variable. */
- if (need_debug && CONTAINS_PLACEHOLDER_P (gnu_expr))
-need_debug = false;
+ /* If GNU_EXPR contains a placeholder, just return it. We rely on the fact
+ that an expression cannot contain both a discriminant and a variable. */
+ if (CONTAINS_PLACEHOLDER_P (gnu_expr))
+return gnu_expr;
+
+ /* If GNU_EXPR is neither a constant nor based on a read-only variable, make
+ a variable that is initialized to contain the expression when the package
+ containing the definition is elaborated. If this entity is defined at top
+ level, replace the expression by the variable; otherwise use a SAVE_EXPR
+ if this is necessary. */
+ if (CONSTANT_CLASS_P (gnu_expr))
+expr_variable_p = false;
+ else
+{
+ /* Skip any conversions and simple arithmetics to see if the expression
+ is based on a read-only variable.
+ ??? This really should remain read-only, but we have to think about
+ the typing of the tree here. */
+ tree inner
+ = skip_simple_arithmetic (remove_conversions (gnu_expr, true));
+
+ if (handled_component_p (inner))
+ {
+ HOST_WIDE_INT bitsize, bitpos;
+ tree offset;
+ enum machine_mode mode;
+ int unsignedp, volatilep;
+
+ inner = get_inner_reference (inner, &bitsize, &bitpos, &offset,
+ &mode, &unsignedp, &volatilep, false);
+ /* If the offset is variable, err on the side of caution. */
+ if (offset)
+ inner = NULL_TREE;
+ }
+
+ expr_variable_p
+ = !(inner
+ && TREE_CODE (inner) == VAR_DECL
+ && (TREE_READONLY (inner) || DECL_READONLY_ONCE_ELAB (inner)));
+}
/* Now create the variable if we need it. */
- if (need_debug || (expr_variable && expr_global))
+ if (need_debug || (expr_variable_p && expr_global_p))
gnu_decl
= create_var_decl (create_concat_name (gnat_entity,
IDENTIFIER_POINTER (gnu_name)),
NULL_TREE, TREE_TYPE (gnu_expr), gnu_expr,
!need_debug, Is_Public (gnat_entity),
- !definition, expr_global, NULL, gnat_
Re: [PATCH] Fix PR48148
On Thu, Mar 17, 2011 at 6:24 AM, Richard Guenther wrote: > > This fixes PR48148, we shouldn't keep abstract origin references > for external decls. > > Bootstrapped and tested on x86_64-unknown-linux-gnu, applied. > > Richard. > > 2011-03-17 Richard Guenther > > PR bootstrap/48148 > * lto-cgraph.c (input_overwrite_node): Clear the abstract > origin for decls in other ltrans units. > (input_varpool_node): Likewise. > It doesn't work: http://gcc.gnu.org/ml/gcc-regression/2011-03/msg00146.html -- H.J.
[testsuite] Remove explicit -O2 from gcc.c-torture/compile/pr44686.c
Hi,
I'm about to check in the following as obvious. The explicit -O2
defeats the different O levels the torture mechanism tries.
Tested on x86_64-linux by running
make -k check RUNTESTFLAGS="compile.exp=pr44686.c"
and verifying all tests passed.
Thanks,
Martin
Index: gcc/testsuite/gcc.c-torture/compile/pr44686.c
===
--- gcc/testsuite/gcc.c-torture/compile/pr44686.c (revision 170933)
+++ gcc/testsuite/gcc.c-torture/compile/pr44686.c (working copy)
@@ -1,4 +1,4 @@
-/* { dg-options "-O2 -fipa-pta -fprofile-generate" } */
+/* { dg-options "-fipa-pta -fprofile-generate" } */
void *
memcpy (void *a, const void *b, __SIZE_TYPE__ len)
{
Re: C++ PATCH for c++/48089 (ICE with invalid constexpr ctor)
On Thu, Mar 17, 2011 at 10:41 AM, Jason Merrill wrote: > On 03/16/2011 11:44 PM, Gabriel Dos Reis wrote: >> >> I am not sure we need more infrastructure or more complexity >> in the implementation. The (C++98) language already requires >> us to initialize subobjects in their order of declaration. That is what >> we do here. All we need is to check that a member, whose value >> is being used in the initialization of another member >> (which might be itself like in this PR) is initialized. When we look up >> `this' in the evaluation environment, we can tell whether a particular >> slot has been initialized. > > Right, my point is that initialization and then lookup of that stored value > is something that does not otherwise exist in constant expressions. In C++93, no. But, we changed that with constexpr :-) The same capability is offered for any constexpr structures or arrays -- either at global scopes or local. For GNU extensions, the same issue arise for designated initializers in array initializations. -- Gaby
PATCH: PR target/48171: Missing "Save" on -mavx and -mfma
Hi, All i386 ISA options, except for -mavx and -mfma, have Save. This patch fixes it. OK for trunk and 4.6? Thanks. H.J. --- 2011-03-17 H.J. Lu PR target/48171 * config/i386/i386.opt: Add Save to -mavx and -mfma. diff --git a/gcc/config/i386/i386.opt b/gcc/config/i386/i386.opt index 0563bc1..2b1ffc3 100644 --- a/gcc/config/i386/i386.opt +++ b/gcc/config/i386/i386.opt @@ -329,11 +329,11 @@ Target Undocumented Alias(mavx) Warn(%<-msse5%> was removed) ;; Deprecated mavx -Target Report Mask(ISA_AVX) Var(ix86_isa_flags) +Target Report Mask(ISA_AVX) Var(ix86_isa_flags) Save Support MMX, SSE, SSE2, SSE3, SSSE3, SSE4.1, SSE4.2 and AVX built-in functions and code generation mfma -Target Report Mask(ISA_FMA) Var(ix86_isa_flags) +Target Report Mask(ISA_FMA) Var(ix86_isa_flags) Save Support MMX, SSE, SSE2, SSE3, SSSE3, SSE4.1, SSE4.2, AVX and FMA built-in functions and code generation msse4a
PATCH: PR debug/48160: prepare_call_arguments failed to handle subreg
Hi Jason, Richard, This patch: http://gcc.gnu.org/ml/gcc-patches/2011-03/msg00814.html failed to handle SUBREG in prepare_call_arguments. This patch fixes it. OK for trunk? Thanks. H.J. --- 2011-03-16 H.J. Lu PR debug/48160 * var-tracking.c (prepare_call_arguments): Check SUBREG. diff --git a/gcc/var-tracking.c b/gcc/var-tracking.c index 266f11f..cfa74a6 100644 --- a/gcc/var-tracking.c +++ b/gcc/var-tracking.c @@ -5763,7 +5763,11 @@ prepare_call_arguments (basic_block bb, rtx insn) /* Try harder, when passing address of a constant pool integer it can be easily read back. */ - val = CSELIB_VAL_PTR (XEXP (item, 1)); + item = XEXP (item, 1); + if (GET_CODE (item) == SUBREG) + item = SUBREG_REG (item); + gcc_assert (GET_CODE (item) == VALUE); + val = CSELIB_VAL_PTR (item); for (l = val->locs; l; l = l->next) if (GET_CODE (l->loc) == SYMBOL_REF && TREE_CONSTANT_POOL_ADDRESS_P (l->loc)
[PATCH] Adjust DECL_INCOMING_RTL for pass_by_reference parameters (PR debug/48163)
Hi!
If a PARM_DECL is not passed by reference because the FE decides so
(then the PARM_DECL is DECL_BY_REFERENCE and has pointer type), but
because pass_by_reference said so, then apparently DECL_INCOMING
is the Pmode pointer to the MEM instead of the actual incoming location
and the fact that expansion decided that isn't stored anywhere.
While we could in theory reconstruct that by doing all the
INIT_CUMULATIVE_ARGS/*function_arg{,_advance}/pass_by_reference etc.,
that is fairly costly to do and just guessing whether it is the case
isn't reliable.
One place where we want to know that is in expand_debug_expr since
my recent change to add ENTRY_VALUE if debug stmts reference a parameter
that isn't used in the function at all. But the debug info emitters
want to know that too, and DECL_INCOMING_RTL seems to be there just
for them.
I was considering adding some DECL_INCOMING_BY_REFERENCE bit to PARM_DECL,
but I think it is actually better if DECL_INCOMING_RTL in that case is
just a MEM of the right mode with the register (or stack slot MEM) as
address.
This patch fixes both the problem of e.g. complex-1.c on cris-elf
where expand_debug_expr was upset that DECL_INCOMING_RTL was SImode,
but the argument was supposed to be DFmode, and also e.g. improves
debug info for -g -m32 -O+ on powerpc-linux:
struct S { char buf[16]; };
void foo (struct S a, int b, int c, int d, int e, int f, int g, int h, struct S
i)
{
}
without the patch there is no location info for A and I parameters,
with this patch the location info is present and correct.
Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?
2011-03-17 Jakub Jelinek
PR debug/48163
* function.c (assign_parms): For data.passed_pointer parms
use MEM of data.entry_parm instead of data.entry_parm itself
as DECL_INCOMING_RTL.
* dwarf2out.c (rtl_for_decl_location): Use DECL_INCOMING_RTL
also when passed and declared mode is the same, DECL_RTL
is a MEM with pseudo as address and DECL_INCOMING_RTL is
a MEM too.
--- gcc/function.c.jj 2011-03-11 12:16:39.0 +0100
+++ gcc/function.c 2011-03-17 11:44:41.0 +0100
@@ -3403,7 +3403,15 @@ assign_parms (tree fndecl)
}
/* Record permanently how this parm was passed. */
- set_decl_incoming_rtl (parm, data.entry_parm, data.passed_pointer);
+ if (data.passed_pointer)
+ {
+ rtx incoming_rtl
+ = gen_rtx_MEM (TYPE_MODE (TREE_TYPE (data.passed_type)),
+ data.entry_parm);
+ set_decl_incoming_rtl (parm, incoming_rtl, true);
+ }
+ else
+ set_decl_incoming_rtl (parm, data.entry_parm, false);
/* Update info on where next arg arrives in registers. */
targetm.calls.function_arg_advance (&all.args_so_far, data.promoted_mode,
--- gcc/dwarf2out.c.jj 2011-03-17 09:38:00.0 +0100
+++ gcc/dwarf2out.c 2011-03-17 12:07:01.0 +0100
@@ -16719,7 +16719,13 @@ rtl_for_decl_location (tree decl)
}
else if (TREE_CODE (decl) == PARM_DECL)
{
- if (rtl == NULL_RTX || is_pseudo_reg (rtl))
+ if (rtl == NULL_RTX
+ || is_pseudo_reg (rtl)
+ || (MEM_P (rtl)
+ && is_pseudo_reg (XEXP (rtl, 0))
+ && DECL_INCOMING_RTL (decl)
+ && MEM_P (DECL_INCOMING_RTL (decl))
+ && GET_MODE (rtl) == GET_MODE (DECL_INCOMING_RTL (decl
{
tree declared_type = TREE_TYPE (decl);
tree passed_type = DECL_ARG_TYPE (decl);
@@ -16731,7 +16737,8 @@ rtl_for_decl_location (tree decl)
all cases where (rtl == NULL_RTX) just below. */
if (dmode == pmode)
rtl = DECL_INCOMING_RTL (decl);
- else if (SCALAR_INT_MODE_P (dmode)
+ else if ((rtl == NULL_RTX || is_pseudo_reg (rtl))
+ && SCALAR_INT_MODE_P (dmode)
&& GET_MODE_SIZE (dmode) <= GET_MODE_SIZE (pmode)
&& DECL_INCOMING_RTL (decl))
{
Jakub
[PATCH] Fix handling of calls to constants (PR debug/48163)
Hi!
On calls.c testcase on cris we ICE from prepare_call_arguments on
calls like
typedef void (*T) ();
((T) 0x10) ();
Calling cselib_lookup with VOIDmode can't do any good, but there is
not reason why we should cselib_lookup constants, we can just use them
as is.
Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?
2011-03-17 Jakub Jelinek
PR debug/48163
* var-tracking.c (prepare_call_arguments): If CALL target
is a non-SYMBOL_REF CONSTANT_P, just add that into the list as
pc instead of looking it up using cselib_lookup and use
Pmode for it if x has VOIDmode.
* dwarf2out.c (gen_subprogram_die): If also both first and
second CONCAT arguments are VOIDmode, use mode of CONCAT itself.
--- gcc/var-tracking.c.jj 2011-03-17 09:37:59.0 +0100
+++ gcc/var-tracking.c 2011-03-17 12:45:18.0 +0100
@@ -5807,7 +5807,16 @@ prepare_call_arguments (basic_block bb,
if (GET_CODE (x) == CALL && MEM_P (XEXP (x, 0)))
{
x = XEXP (XEXP (x, 0), 0);
- if (GET_CODE (x) != SYMBOL_REF)
+ if (GET_CODE (x) == SYMBOL_REF)
+ /* Don't record anything. */;
+ else if (CONSTANT_P (x))
+ {
+ x = gen_rtx_CONCAT (GET_MODE (x) == VOIDmode ? Pmode : GET_MODE (x),
+ pc_rtx, x);
+ call_arguments
+ = gen_rtx_EXPR_LIST (VOIDmode, x, call_arguments);
+ }
+ else
{
cselib_val *val = cselib_lookup (x, GET_MODE (x), 0, VOIDmode);
if (val && cselib_preserved_value_p (val))
--- gcc/dwarf2out.c.jj 2011-03-17 12:07:01.0 +0100
+++ gcc/dwarf2out.c 2011-03-17 12:54:51.0 +0100
@@ -19479,7 +19479,11 @@ gen_subprogram_die (tree decl, dw_die_re
== REGNO (XEXP (XEXP (XEXP (next_arg, 0), 0), 0)))
next_arg = XEXP (next_arg, 1);
if (mode == VOIDmode)
- mode = GET_MODE (XEXP (XEXP (arg, 0), 0));
+ {
+ mode = GET_MODE (XEXP (XEXP (arg, 0), 0));
+ if (mode == VOIDmode)
+ mode = GET_MODE (XEXP (arg, 0));
+ }
if (GET_MODE_CLASS (mode) != MODE_INT
|| GET_MODE_SIZE (mode) > DWARF2_ADDR_SIZE)
continue;
Jakub
Re: PATCH: PR target/48171: Missing "Save" on -mavx and -mfma
On Thu, Mar 17, 2011 at 6:51 PM, H.J. Lu wrote: > All i386 ISA options, except for -mavx and -mfma, have Save. This patch > fixes it. OK for trunk and 4.6? > > 2011-03-17 H.J. Lu > > PR target/48171 > * config/i386/i386.opt: Add Save to -mavx and -mfma. OK for 4.7 and 4.6 with the approval from RM. Thanks, Uros.
[PATCH] Fix hppa-* --enable-checking=release bootstrap (PR bootstrap/48161)
Hi!
When expanding
D.2070_29 = &MEM[(struct V *)0B].v[D.2034_30]{lb: 0 sz: 12};
expand_expr_addr_expr_1 is called with EXPAND_SUM, and result
ends up being (const_int 0) (from the NULL address), while
tmp (the offset) is a pseudo register. With EXPAND_SUM we want
to ensure no insns are emitted, so just gen_rtx_PLUS directly.
But having CONST_INT as the first argument and REG as second argument
of commutative RTL is invalid.
Fixed thusly, bootstrapped/regtested on x86_64-linux and i686-linux
and Dave tested it on hppa. Ok for trunk/4.6 (it is a P1 regression)?
2011-03-17 Jakub Jelinek
PR bootstrap/48161
* expr.c (expand_expr_addr_expr_1): Swap PLUS operands if
needed.
* gcc.c-torture/compile/pr48161.c: New test.
--- gcc/expr.c.jj 2011-03-14 14:12:15.0 +0100
+++ gcc/expr.c 2011-03-17 16:49:01.0 +0100
@@ -6971,7 +6971,12 @@ expand_expr_addr_expr_1 (tree exp, rtx t
tmp = convert_memory_address_addr_space (tmode, tmp, as);
if (modifier == EXPAND_SUM || modifier == EXPAND_INITIALIZER)
- result = gen_rtx_PLUS (tmode, result, tmp);
+ {
+ if (swap_commutative_operands_p (result, tmp))
+ result = gen_rtx_PLUS (tmode, tmp, result);
+ else
+ result = gen_rtx_PLUS (tmode, result, tmp);
+ }
else
{
subtarget = bitpos ? NULL_RTX : target;
--- gcc/testsuite/gcc.c-torture/compile/pr48161.c.jj2011-03-09
16:32:56.85501 +0100
+++ gcc/testsuite/gcc.c-torture/compile/pr48161.c 2011-03-17
17:20:34.0 +0100
@@ -0,0 +1,24 @@
+/* PR bootstrap/48161 */
+
+struct T { int u; };
+struct G { int l; int t; int r; };
+struct V { struct G v[10]; };
+struct { struct V b; } *h;
+void bar (void);
+
+struct G *
+baz (struct V *x, unsigned y)
+{
+ return &x->v[y];
+}
+
+int
+foo (struct T *x, struct T *y)
+{
+ if ((baz (&h->b, y->u)->t ? baz (&h->b, y->u)->t : 0)
+ - baz (h ? &h->b : 0, x->u)->r
+ - (baz (h ? &h->b : 0, x->u)->t > 0 ? 5 : 0))
+return 1;
+ bar ();
+ return 0;
+}
Jakub
Re: Cleaning up expand optabs code
On 03/17/2011 09:32 AM, Richard Sandiford wrote:
> This patch adds a few helper functions for dealing with optabs:
>
> - insn_operand_matches (ICODE, OPNO, X)
> - (maybe_)legitimize_insn_target (ICODE, OPNO, TARGET, MODE)
> - (maybe_)legitimize_insn_source (ICODE, OPNO, SOURCE, MODE)
Cool.
Why pass in MODE in the later two cases? Seems to me that your
argument for omitting it for insn_operand_matches is just as
compelling for the other functions...
> - I first tried to make insn_operand_matches an inline function,
> but I can't think of a good header file that is guaranteed to
> know about both recog.h and insn-codes.h.
Meh. I can't imagine it mattering so much. Anyway, an lto build
of gcc itself would fix that if needed, right? ;-)
> - char_rtx = const0_rtx;
> - char_mode = insn_data[(int) icode].operand[2].mode;
> - if (! (*insn_data[(int) icode].operand[2].predicate) (char_rtx,
> - char_mode))
> - char_rtx = copy_to_mode_reg (char_mode, char_rtx);
> -
> - pat = GEN_FCN (icode) (result, gen_rtx_MEM (BLKmode, src_reg),
> - char_rtx, GEN_INT (align));
> - if (! pat)
> - return NULL_RTX;
> + if (!(char_rtx = maybe_legitimize_insn_source (icode, 2, const0_rtx,
> + VOIDmode))
> + || !(pat = GEN_FCN (icode) (result, gen_rtx_MEM (BLKmode, src_reg),
> + char_rtx, GEN_INT (align
> + {
> + delete_insns_since (before_strlen);
> + return NULL_RTX;
> + }
>emit_insn (pat);
I'm not so fond of burying assignments into conditionals. I know we
do it a lot in gcc, and it's a tad harder to avoid here than ...
> - if (!insn_data[icode].operand[1].predicate (val, mode))
> - val = force_reg (mode, val);
> -
> - insn = GEN_FCN (icode) (mem, val);
> - if (insn)
> + start = get_last_insn ();
> + if ((val = maybe_legitimize_insn_source (icode, 1, const0_rtx, mode))
> + && (insn = GEN_FCN (icode) (mem, val)))
> {
> emit_insn (insn);
> return;
> }
> + delete_insns_since (start);
... here, where it's just as readable to write
val = maybe_legitimize_insn_source (icode, 1, const0_rtx, mode);
if (val)
{
insn = GEN_FCN (icode) (mem, val);
if (insn)
{
emit_insn (insn);
return;
}
}
delete_insns_since (start);
> + if ((temp = maybe_legitimize_insn_target (icode, 0, target, tmp_mode))
> + && (xop0 = maybe_legitimize_insn_source (icode, 1, xop0, mode0))
> + && (xop1 = maybe_legitimize_insn_source (icode, 2, xop1, mode1))
> + && (pat = GEN_FCN (icode) (temp, xop0, xop1)))
Although, these patterns occur often enough that I wonder if there's a way
to tidy them up into a single function call. We could either use a set of
functions like
target = maybe_legitimize_emit_insn_ts (icode, target, src1);
target = maybe_legitimize_emit_insn_tss (icode, target, src1, src2);
or have a single function with variadic source operands. Probably the
separate functions is better for error checking within the compiler. We
can validate the correct function was called for a given icode based on
the n_operands stored in the insn_data, and the compiler itself will make
sure that we didn't omit an argument for that function.
The interface I was considering here would validate the target and all
of the sources, emit the insn or delete_insns_since, and return the new
target or NULL if no insn was emitted.
All that said, I'm very much in favour of this cleanup.
r~
Re: RX: 4.5 branch: Fix alignment and addressing issues.
On Mar 17, 2011, at 5:31 AM, Nick Clifton wrote: >> You can set up the correct length even without using separate patterns. > > The problem is And why is that a problem? You get to write arbitrarily complex C code that can depend upon insn and operands. I presume that you can do that. See: (set (attr "length") (symbol_ref "arm_attr_length_move_neon (insn)"))]) from arm, for example.
Re: PATCH: PR debug/48160: prepare_call_arguments failed to handle subreg
On 03/17/2011 11:06 AM, H.J. Lu wrote: > PR debug/48160 > * var-tracking.c (prepare_call_arguments): Check SUBREG. Ok. r~
Re: [PATCH] Fix hppa-* --enable-checking=release bootstrap (PR bootstrap/48161)
On 03/17/2011 11:46 AM, Jakub Jelinek wrote:
> - result = gen_rtx_PLUS (tmode, result, tmp);
> + {
> + if (swap_commutative_operands_p (result, tmp))
> + result = gen_rtx_PLUS (tmode, tmp, result);
> + else
> + result = gen_rtx_PLUS (tmode, result, tmp);
Hum. What about simplify_gen_binary (PLUS, tmode, result, tmp)
which will also do the swap?
I'm not wed to this though. I guess I'd be ok with the patch either way.
r~
Re: [PATCH] Adjust DECL_INCOMING_RTL for pass_by_reference parameters (PR debug/48163)
On 03/17/2011 11:36 AM, Jakub Jelinek wrote: > PR debug/48163 > * function.c (assign_parms): For data.passed_pointer parms > use MEM of data.entry_parm instead of data.entry_parm itself > as DECL_INCOMING_RTL. > * dwarf2out.c (rtl_for_decl_location): Use DECL_INCOMING_RTL > also when passed and declared mode is the same, DECL_RTL > is a MEM with pseudo as address and DECL_INCOMING_RTL is > a MEM too. Ok. r~
Re: [PATCH] Fix handling of calls to constants (PR debug/48163)
On 03/17/2011 11:40 AM, Jakub Jelinek wrote: > PR debug/48163 > * var-tracking.c (prepare_call_arguments): If CALL target > is a non-SYMBOL_REF CONSTANT_P, just add that into the list as > pc instead of looking it up using cselib_lookup and use > Pmode for it if x has VOIDmode. > * dwarf2out.c (gen_subprogram_die): If also both first and > second CONCAT arguments are VOIDmode, use mode of CONCAT itself. Ok. r~
Re: [PATCH] Fix hppa-* --enable-checking=release bootstrap (PR bootstrap/48161)
On Thu, Mar 17, 2011 at 12:54:44PM -0700, Richard Henderson wrote:
> On 03/17/2011 11:46 AM, Jakub Jelinek wrote:
> > - result = gen_rtx_PLUS (tmode, result, tmp);
> > + {
> > + if (swap_commutative_operands_p (result, tmp))
> > + result = gen_rtx_PLUS (tmode, tmp, result);
> > + else
> > + result = gen_rtx_PLUS (tmode, result, tmp);
>
> Hum. What about simplify_gen_binary (PLUS, tmode, result, tmp)
> which will also do the swap?
You're right, that will magically handle even the hypothetical
case when both result and tmp will be constants and handles
even better this exact case (where result is (const_int 0) ).
The following fixes the testcase in cross to hppa-* as well.
I'll bootstrap/regtest it momentarily, ok if it passes?
2011-03-17 Richard Henderson
Jakub Jelinek
PR bootstrap/48161
* expr.c (expand_expr_addr_expr_1): Use simplify_gen_binary
instead of gen_rtx_PLUS if EXPAND_SUM or EXPAND_INITIALIZER.
* gcc.c-torture/compile/pr48161.c: New test.
--- gcc/expr.c.jj 2011-03-14 14:12:15.0 +0100
+++ gcc/expr.c 2011-03-17 16:49:01.0 +0100
@@ -6971,7 +6971,7 @@ expand_expr_addr_expr_1 (tree exp, rtx t
tmp = convert_memory_address_addr_space (tmode, tmp, as);
if (modifier == EXPAND_SUM || modifier == EXPAND_INITIALIZER)
- result = gen_rtx_PLUS (tmode, result, tmp);
+ result = simplify_gen_binary (PLUS, tmode, result, tmp);
else
{
subtarget = bitpos ? NULL_RTX : target;
--- gcc/testsuite/gcc.c-torture/compile/pr48161.c.jj2011-03-09
16:32:56.85501 +0100
+++ gcc/testsuite/gcc.c-torture/compile/pr48161.c 2011-03-17
17:20:34.0 +0100
@@ -0,0 +1,24 @@
+/* PR bootstrap/48161 */
+
+struct T { int u; };
+struct G { int l; int t; int r; };
+struct V { struct G v[10]; };
+struct { struct V b; } *h;
+void bar (void);
+
+struct G *
+baz (struct V *x, unsigned y)
+{
+ return &x->v[y];
+}
+
+int
+foo (struct T *x, struct T *y)
+{
+ if ((baz (&h->b, y->u)->t ? baz (&h->b, y->u)->t : 0)
+ - baz (h ? &h->b : 0, x->u)->r
+ - (baz (h ? &h->b : 0, x->u)->t > 0 ? 5 : 0))
+return 1;
+ bar ();
+ return 0;
+}
Jakub
Reinstalled patch for 37273
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
I had pulled the patch for 37273 during the 4.6 cycle due to exposing
several latent problems. I've just reinstalled it and will (of course)
keep an eye out for any problems.
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/
iQEcBAEBAgAGBQJNgmqWAAoJEBRtltQi2kC7rgQH/3IyYYayg+H52UrzyVjG4M4Z
p4bIaLrAcHwDc0iYQAQyo3+bnBHK9b8ZDaw6fnAJAOmwbLSqSBy3ensHdxylZseM
fJ7e579XfL9DQjdJvoAR70LTVvgqqyAMWqSjZ8Q/1SrXTqLVLcSB/D5y+leN21Bf
jYwoS+GKzOV2FHH890AYkRcE4wY33zOB5XLIYOt/WWTju/I3DVCypA0zbvyk7ylv
FONAsOdFPnqEn3f+0ZkkS3VpaLFHYvOPqnKGo34Iy3wUjUnk7K3iTAtb9HzAf01V
ls1ijzpjW/aJrjbv+NsC2vHtAWP5lpSNrjzcrrhaDEBs+jer0v857e3vnUJ3jSI=
=WVh4
-END PGP SIGNATURE-
Index: ira-costs.c
===
*** ira-costs.c (revision 171110)
--- ira-costs.c (working copy)
***
*** 1,5
/* IRA hard register and memory cost calculation for allocnos or pseudos.
!Copyright (C) 2006, 2007, 2008, 2009, 2010
Free Software Foundation, Inc.
Contributed by Vladimir Makarov .
--- 1,5
/* IRA hard register and memory cost calculation for allocnos or pseudos.
!Copyright (C) 2006, 2007, 2008, 2009, 2010, 2011
Free Software Foundation, Inc.
Contributed by Vladimir Makarov .
*** scan_one_insn (rtx insn)
*** 1009,1014
--- 1009,1015
enum rtx_code pat_code;
rtx set, note;
int i, k;
+ bool counted_mem;
if (!NONDEBUG_INSN_P (insn))
return insn;
*** scan_one_insn (rtx insn)
*** 1018,1032
|| pat_code == ADDR_VEC || pat_code == ADDR_DIFF_VEC)
return insn;
set = single_set (insn);
extract_insn (insn);
/* If this insn loads a parameter from its stack slot, then it
represents a savings, rather than a cost, if the parameter is
! stored in memory. Record this fact. */
if (set != 0 && REG_P (SET_DEST (set)) && MEM_P (SET_SRC (set))
&& (note = find_reg_note (insn, REG_EQUIV, NULL_RTX)) != NULL_RTX
! && MEM_P (XEXP (note, 0)))
{
enum reg_class cl = GENERAL_REGS;
rtx reg = SET_DEST (set);
--- 1019,1041
|| pat_code == ADDR_VEC || pat_code == ADDR_DIFF_VEC)
return insn;
+ counted_mem = false;
set = single_set (insn);
extract_insn (insn);
/* If this insn loads a parameter from its stack slot, then it
represents a savings, rather than a cost, if the parameter is
! stored in memory. Record this fact.
!
! Similarly if we're loading other constants from memory (constant
! pool, TOC references, small data areas, etc) and this is the only
! assignment to the destination pseudo. */
if (set != 0 && REG_P (SET_DEST (set)) && MEM_P (SET_SRC (set))
&& (note = find_reg_note (insn, REG_EQUIV, NULL_RTX)) != NULL_RTX
! && ((MEM_P (XEXP (note, 0)))
! || (CONSTANT_P (XEXP (note, 0))
! && LEGITIMATE_CONSTANT_P (XEXP (note, 0))
! && REG_N_SETS (REGNO (SET_DEST (set))) == 1)))
{
enum reg_class cl = GENERAL_REGS;
rtx reg = SET_DEST (set);
*** scan_one_insn (rtx insn)
*** 1038,1043
--- 1047,1053
-= ira_memory_move_cost[GET_MODE (reg)][cl][1] * frequency;
record_address_regs (GET_MODE (SET_SRC (set)), XEXP (SET_SRC (set), 0),
0, MEM, SCRATCH, frequency * 2);
+ counted_mem = true;
}
record_operand_costs (insn, pref);
*** scan_one_insn (rtx insn)
*** 1052,1058
struct costs *p = COSTS (costs, COST_INDEX (regno));
struct costs *q = op_costs[i];
! p->mem_cost += q->mem_cost;
for (k = 0; k < cost_classes_num; k++)
p->cost[k] += q->cost[k];
}
--- 1062,1071
struct costs *p = COSTS (costs, COST_INDEX (regno));
struct costs *q = op_costs[i];
! /* If the already accounted for the memory "cost" above, don't
! do so again. */
! if (!counted_mem)
! p->mem_cost += q->mem_cost;
for (k = 0; k < cost_classes_num; k++)
p->cost[k] += q->cost[k];
}
Fix problem with guality tests
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
The guality tests can randomly fail due to expect buffering issues.
Given this output:
Breakpoint 1 at 0x4004d6: file
/home/gcc/virgin-gcc/gcc/testsuite/gcc.dg/guality/pr43479.c, line 18.^M
^M
Breakpoint 1, foo (k=7, l=Unhandled dwarf expression opcode 0xf3^M
) at /home/gcc/virgin-gcc/gcc/testsuite/gcc.dg/guality/pr43479.c:22^M
22asm volatile ("" : : "r" (k), "r" (l));^M
$1 = 8^M
$2 = 8^M
And this matcher:
remote_expect target [timeout_value] {
-re {[\n\r]\$1 = ([^\n\r]*)[\n\r]+\$2 = ([^\n\r]*)[\n\r]} {
set first $expect_out(1,string)
set second $expect_out(2,string)
if { $first == $second } {
pass "$testname"
} else {
send_log "$first != $second\n"
fail "$testname"
}
remote_close target
return
}
# Too old GDB
-re "Unhandled dwarf expression|Error in sourced command file" {
unsupported "$testname"
remote_close target
return
}
timeout {
unsupported "$testname"
remote_close target
return
}
}
The first thing to realize is that output can match two cases. One
where we actually have a pass/fail for the test or the second case where
we have too old GDB. When more than one case matches, the first has
priority (ie, the pass/fail case).
Furthermore, depending on buffering issues, we may or may not see the $1
= 8 and $2 = 8 lines at the right time and thus we'd fall match the "too
old gdb" case.
This results in the exact same test sometime passing/failing and other
times being unsupported which makes comparing test runs difficult.
This patch reorders the two clauses so that in the case of a double
match, we'll be consistent with the case where matching occurs before
seeing the $1 = and $2 = lines. Hopefully this brings some more
stability to the guality tests.
OK for trunk?
Jeff
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/
iQEcBAEBAgAGBQJNgnA0AAoJEBRtltQi2kC7RzcIAL1zWdJcXKah8Jz7xhcpu/cb
xlraZl5rdvfBTrLGvseznrLWS71xPOpskFAGAgNYv3OD/8W1AlNNbV2qLNx1LQRL
p3/0X7rkfhNZq1CIixz5CRAim7ryP66W3haLhW5bZ0sfIwrAiFUy+gnyTuiCnO4R
xkWoowIezScKKPX7rTm7OQRX+qf6yNnFl8jqcu1agiwpeL8dk2S4D2T3Q/RhMmBs
m0Ekj9CCl9UJARxv6i0N5+5meoMx6oRg/dzod/XgDYQOQIOhVjukgTGX/I3GZYLZ
Bfie/1RknC86/dQUsVHqAS4Vv0mecGjlgmRyY8kh2Uz9eTZR5pPG2n4NTJJHR9A=
=G1b6
-END PGP SIGNATURE-
* gcc-gdb-test.exp (gdb-test): Reorder matchers to give more
consistent results.
Index: gcc-gdb-test.exp
===
*** gcc-gdb-test.exp(revision 171108)
--- gcc-gdb-test.exp(working copy)
*** proc gdb-test { args } {
*** 60,65
--- 60,71
}
remote_expect target [timeout_value] {
+ # Too old GDB
+ -re "Unhandled dwarf expression|Error in sourced command file" {
+ unsupported "$testname"
+ remote_close target
+ return
+ }
-re {[\n\r]\$1 = ([^\n\r]*)[\n\r]+\$2 = ([^\n\r]*)[\n\r]} {
set first $expect_out(1,string)
set second $expect_out(2,string)
*** proc gdb-test { args } {
*** 72,83
remote_close target
return
}
- # Too old GDB
- -re "Unhandled dwarf expression|Error in sourced command file" {
- unsupported "$testname"
- remote_close target
- return
- }
timeout {
unsupported "$testname"
remote_close target
--- 78,83
RFC: PATCH: PR rtl-optimization/48155: Reload doesn't handle subreg properly
Hi,
Reload tries to handle plus operation such as:
(plus (subreg (plus (reg)
(const_int NNN)))
(const_int NNN))
and nothing good comes out of it. I am not quite happy with this patch.
Any comments?
Thanks.
H.J.
---
commit 17ee20b0bd58b0e5d5bbdd79014eb370ab590001
Author: H.J. Lu
Date: Thu Mar 17 13:57:14 2011 -0700
Add and use reload_plus_ok.
diff --git a/gcc/ChangeLog.x32 b/gcc/ChangeLog.x32
index 52ff01d..6d5eda6 100644
--- a/gcc/ChangeLog.x32
+++ b/gcc/ChangeLog.x32
@@ -1,5 +1,12 @@
2011-03-16 H.J. Lu
+ PR rtl-optimization/48155
+ * reload1.c (reload_plus_ok): New.
+ (gen_reload_chain_without_interm_reg_p): Use it.
+ (gen_reload): Likewise.
+
+2011-03-16 H.J. Lu
+
PR middle-end/48016
* function.c (expand_function_start): Properly store frame
pointer for non-local goto.
diff --git a/gcc/reload1.c b/gcc/reload1.c
index 3d58e58..14537bd 100644
--- a/gcc/reload1.c
+++ b/gcc/reload1.c
@@ -5516,6 +5516,54 @@ substitute (rtx *where, const_rtx what, rtx repl)
}
}
+/* Return TRUE if IN is a valid plus operation. */
+
+static bool
+reload_plus_ok (rtx in)
+{
+ if (GET_CODE (in) == PLUS)
+{
+ rtx op0 = XEXP (in, 0);
+ rtx op1 = XEXP (in, 1);
+ if ((REG_P (op0)
+ || GET_CODE (op0) == SUBREG
+ || MEM_P (op0))
+ && (REG_P (op1)
+ || GET_CODE (op1) == SUBREG
+ || CONSTANT_P (op1)
+ || MEM_P (op1)))
+ {
+ rtx subreg, other;
+ if (GET_CODE (op0) == SUBREG)
+ {
+ subreg = SUBREG_REG (op0);
+ other = op1;
+ }
+ else if (GET_CODE (op1) == SUBREG)
+ {
+ subreg = SUBREG_REG (op1);
+ other = op0;
+ }
+ else
+ return true;
+
+ /* Avoid
+(plus (subreg (plus (reg)
+(const_int NNN)))
+ (const_int NNN))
+ */
+ if (GET_CODE (subreg) == PLUS
+ && (CONSTANT_P (XEXP (subreg, 0))
+ || CONSTANT_P (XEXP (subreg, 1)))
+ && CONSTANT_P (other))
+ return false;
+
+ return true;
+ }
+}
+ return false;
+}
+
/* The function returns TRUE if chain of reload R1 and R2 (in any
order) can be evaluated without usage of intermediate register for
the reload containing another reload. It is important to see
@@ -5572,14 +5620,7 @@ gen_reload_chain_without_interm_reg_p (int r1, int r2)
&& (tem = gen_lowpart_common (GET_MODE (SUBREG_REG (in)), out)) != 0)
in = SUBREG_REG (in), out = tem;
- if (GET_CODE (in) == PLUS
- && (REG_P (XEXP (in, 0))
- || GET_CODE (XEXP (in, 0)) == SUBREG
- || MEM_P (XEXP (in, 0)))
- && (REG_P (XEXP (in, 1))
- || GET_CODE (XEXP (in, 1)) == SUBREG
- || CONSTANT_P (XEXP (in, 1))
- || MEM_P (XEXP (in, 1
+ if (reload_plus_ok (in))
{
insn = emit_insn (gen_rtx_SET (VOIDmode, out, in));
code = recog_memoized (insn);
@@ -8456,14 +8497,7 @@ gen_reload (rtx out, rtx in, int opnum, enum reload_type
type)
??? At some point, this whole thing needs to be rethought. */
- if (GET_CODE (in) == PLUS
- && (REG_P (XEXP (in, 0))
- || GET_CODE (XEXP (in, 0)) == SUBREG
- || MEM_P (XEXP (in, 0)))
- && (REG_P (XEXP (in, 1))
- || GET_CODE (XEXP (in, 1)) == SUBREG
- || CONSTANT_P (XEXP (in, 1))
- || MEM_P (XEXP (in, 1
+ if (reload_plus_ok (in))
{
/* We need to compute the sum of a register or a MEM and another
register, constant, or MEM, and put it into the reload
C++ PATCH for c++/47504 (bogus overflow error with constexpr)
In this testcase, the fix for PR 25125 causes us to rewrite what starts
as char(int(-1) - int(1)) to char((unsigned char)(-1) - (unsigned
char)1) and thus char((unsigned char)254). 254 doesn't fit in char, so
the result has TREE_OVERFLOW set even though the original expression was
all signed and therefore shouldn't.
One issue here is that the rewriting creates this situation where it
didn't exist before, so I think the rewriting is wrong.
But it's also the case that both C and C++ distinguish between
arithmetic overflow (i.e. INT_MAX+1) which has undefined behavior, and
conversion of a value that doesn't fit in the target type (i.e.
char(254)), which has implementation-defined behavior. So we should
allow the latter in constant expressions, even if it was wrong of the
compiler to introduce it.
Tested x86_64-pc-linux-gnu, applied to trunk.
commit de85bc3224ebed6104076ea0e6218e202da1a64e
Author: Jason Merrill
Date: Thu Mar 17 15:33:40 2011 -0400
PR c++/47504
* semantics.c (cxx_eval_constant_expression) [NOP_EXPR]: Don't let
the conversion set TREE_OVERFLOW.
diff --git a/gcc/cp/semantics.c b/gcc/cp/semantics.c
index cafca56..b6d1008 100644
--- a/gcc/cp/semantics.c
+++ b/gcc/cp/semantics.c
@@ -6991,6 +6991,11 @@ cxx_eval_constant_expression (const constexpr_call
*call, tree t,
conversion. */
return fold (t);
r = fold_build1 (TREE_CODE (t), to, op);
+ /* Conversion of an out-of-range value has implementation-defined
+ behavior; the language considers it different from arithmetic
+ overflow, which is undefined. */
+ if (TREE_OVERFLOW_P (r) && !TREE_OVERFLOW_P (op))
+ TREE_OVERFLOW (r) = false;
}
break;
diff --git a/gcc/testsuite/g++.dg/cpp0x/constexpr-data2.C
b/gcc/testsuite/g++.dg/cpp0x/constexpr-data2.C
index 598cae6..2d614ec 100644
--- a/gcc/testsuite/g++.dg/cpp0x/constexpr-data2.C
+++ b/gcc/testsuite/g++.dg/cpp0x/constexpr-data2.C
@@ -44,5 +44,4 @@ extern template struct A3;
// Use.
A3 a31;
-// FIXME should this be an error?
A3 a32;// { dg-warning "overflow" }
diff --git a/gcc/testsuite/g++.dg/cpp0x/constexpr-overflow2.C
b/gcc/testsuite/g++.dg/cpp0x/constexpr-overflow2.C
new file mode 100644
index 000..5d5749c
--- /dev/null
+++ b/gcc/testsuite/g++.dg/cpp0x/constexpr-overflow2.C
@@ -0,0 +1,8 @@
+// PR c++/47504
+// { dg-options -std=c++0x }
+
+char constexpr sub(char arg)
+{ return char(arg - char(1)); }
+
+int main()
+{ static char constexpr m = sub(-1); }
Re: [libgfortran, patch] More than 26 temporary files with weak mktemp()
Thanks for the review! > - Use the type size_t for tempdirlen as that is the return type of > strlen() and argument type for get_mem(). > > - You can use a const size_t variable for the length of the string > "slash" rather than calling strlen() in the do-while loop. Both OK. > - Don't set errno as we anyway loop until we successfully open a file > with O_CREAT|O_EXCL. No, if I don't set errno, the continue statement will not iteration the loop, as the condition (fd == -1 && errno == EEXIST) is false. Unless I don't understand what you mean. FX
Can't use SImode as Pmode for x32
On Wed, Mar 16, 2011 at 4:28 PM, Jakub Jelinek wrote: > On Wed, Mar 16, 2011 at 03:38:25PM -0700, H.J. Lu wrote: > > IMNSHO you really should reconsider using Pmode != ptr_mode for your port. Hi Jakub, I created hjl/x32/Pmode/master branch at http://git.kernel.org/?p=devel/gcc/hjl/x86.git;a=summary It will require very extensive changes to x86 backend since stack pointer and frame pointer are really in DImode for x32 as x32 process runs in 64bit mode. If you can make it to work, please let me know. Thanks. -- H.J.
Re: [PATCH] Fix hppa-* --enable-checking=release bootstrap (PR bootstrap/48161)
On Thu, Mar 17, 2011 at 09:07:43PM +0100, Jakub Jelinek wrote:
> The following fixes the testcase in cross to hppa-* as well.
> I'll bootstrap/regtest it momentarily, ok if it passes?
Now bootstrapped/regtested on x86_64-linux and i686-linux.
> 2011-03-17 Richard Henderson
> Jakub Jelinek
>
> PR bootstrap/48161
> * expr.c (expand_expr_addr_expr_1): Use simplify_gen_binary
> instead of gen_rtx_PLUS if EXPAND_SUM or EXPAND_INITIALIZER.
>
> * gcc.c-torture/compile/pr48161.c: New test.
>
> --- gcc/expr.c.jj 2011-03-14 14:12:15.0 +0100
> +++ gcc/expr.c2011-03-17 16:49:01.0 +0100
> @@ -6971,7 +6971,7 @@ expand_expr_addr_expr_1 (tree exp, rtx t
>tmp = convert_memory_address_addr_space (tmode, tmp, as);
>
>if (modifier == EXPAND_SUM || modifier == EXPAND_INITIALIZER)
> - result = gen_rtx_PLUS (tmode, result, tmp);
> + result = simplify_gen_binary (PLUS, tmode, result, tmp);
>else
> {
> subtarget = bitpos ? NULL_RTX : target;
> --- gcc/testsuite/gcc.c-torture/compile/pr48161.c.jj 2011-03-09
> 16:32:56.85501 +0100
> +++ gcc/testsuite/gcc.c-torture/compile/pr48161.c 2011-03-17
> 17:20:34.0 +0100
Jakub
Re: [x32] PATCH: PR middle-end/47725: [x32] error: unable to find a register to spill in class DIREG
On Tue, Feb 15, 2011 at 2:55 PM, Bernd Schmidt wrote: > On 02/14/2011 08:46 PM, Eric Botcazou wrote: >>> I agree with Jeff that combine would be the correct place to fix this. >>> At least it takes class_likely_spilled_p into account, so it will >>> restrict only those machines where extending the lifetime of hard regs >>> is dangerous. >> >> OK, but I don't see how copying to a new pseudo would interfere with that. > > For one thing, the set no longer matches the REG_EQUIV note we make > here, and that does seem to interfere with the optimization. I've tested > both patches on ARM, -march=armv7-a. The combiner patch produced no code > changes. The function.c patch produced regressions (increased register > pressure). Both results are as expected. > > To put it another way: the combiner change is conservatively correct, > and necessary if we're going to have extends of hard registers in the > RTL. The function.c change is demonstrably incorrect as shown by the ARM > codegen regressions. > I checked in my patch into trunk. Thanks. -- H.J.
Re: PATCH: PR rtl-optimization/47502: Never combine asm statement
Hi Eric,
Is this patch OK for trunk?
Thanks.
H.J.
---
On Thu, Jan 27, 2011 at 6:14 PM, H.J. Lu wrote:
> It is a bad idea to combine asm statement. This patch disallows it.
> Any comments?
>
> Thanks.
>
>
> H.J.
> ---
> commit a11b95180e53d3a0bc3eabad5594859cea7c3334
> Author: H.J. Lu
> Date: Thu Jan 27 18:12:27 2011 -0800
>
> Never combine asm statement.
>
> diff --git a/gcc/ChangeLog.x32 b/gcc/ChangeLog.x32
> index 0ae4761..ef65e7b 100644
> --- a/gcc/ChangeLog.x32
> +++ b/gcc/ChangeLog.x32
> @@ -1,3 +1,8 @@
> +2011-01-27 H.J. Lu
> +
> + PR rtl-optimization/47502
> + * combine.c (cant_combine_insn_p): Never combine asm statement.
> +
> 2011-01-25 H.J. Lu
>
> PR target/47446
> diff --git a/gcc/combine.c b/gcc/combine.c
> index 3ee53e6..d4a8079 100644
> --- a/gcc/combine.c
> +++ b/gcc/combine.c
> @@ -2122,13 +2122,14 @@ cant_combine_insn_p (rtx insn)
> /* Never combine loads and stores involving hard regs that are likely
> to be spilled. The register allocator can usually handle such
> reg-reg moves by tying. If we allow the combiner to make
> - substitutions of likely-spilled regs, reload might die.
> + substitutions of likely-spilled regs, reload might die. Never
> + combine asm statement.
> As an exception, we allow combinations involving fixed regs; these are
> not available to the register allocator so there's no risk involved. */
>
> set = single_set (insn);
> if (! set)
> - return 0;
> + return asm_noperands (PATTERN (insn)) > 0;
> src = SET_SRC (set);
> dest = SET_DEST (set);
> if (GET_CODE (src) == SUBREG)
> @@ -2144,7 +2145,7 @@ cant_combine_insn_p (rtx insn)
> && targetm.class_likely_spilled_p (REGNO_REG_CLASS (REGNO
> (dest))
> return 1;
>
> - return 0;
> + return asm_noperands (src) > 0;
> }
>
> struct likely_spilled_retval_info
> diff --git a/gcc/testsuite/ChangeLog.x32 b/gcc/testsuite/ChangeLog.x32
> index 597294e..8759881 100644
> --- a/gcc/testsuite/ChangeLog.x32
> +++ b/gcc/testsuite/ChangeLog.x32
> @@ -1,3 +1,9 @@
> +2011-01-27 H.J. Lu
> +
> + PR rtl-optimization/47502
> + * gcc.target/i386/pr47502-1.c: New.
> + * gcc.target/i386/pr47502-2.c: Likewise.
> +
> 2011-01-25 H.J. Lu
>
> PR target/47446
> diff --git a/gcc/testsuite/gcc.target/i386/pr47502-1.c
> b/gcc/testsuite/gcc.target/i386/pr47502-1.c
> new file mode 100644
> index 000..727afe9
> --- /dev/null
> +++ b/gcc/testsuite/gcc.target/i386/pr47502-1.c
> @@ -0,0 +1,8 @@
> +/* { dg-do compile } */
> +/* { dg-options "-O" } */
> +
> +void
> +foo (const void *x, void *y, long y)
> +{
> + asm volatile ("" :: "c" ((x)), "d" ((y)), "S" (y));
> +}
> diff --git a/gcc/testsuite/gcc.target/i386/pr47502-2.c
> b/gcc/testsuite/gcc.target/i386/pr47502-2.c
> new file mode 100644
> index 000..1f57ea0
> --- /dev/null
> +++ b/gcc/testsuite/gcc.target/i386/pr47502-2.c
> @@ -0,0 +1,12 @@
> +/* { dg-do compile } */
> +/* { dg-options "-O2" } */
> +
> +int
> +foo (int how, const void *set, void *oset)
> +{
> + int resultvar;
> + asm volatile (""
> + : "=a" (resultvar)
> + : "0" (14) , "b" (how), "c" ((set)), "d" ((oset)), "S" (65 /
> 8) : "memory", "cc");
> + return resultvar;
> +}
>
--
H.J.
Re: PATCH: PR rtl-optimization/47502: Never combine asm statement
On Mar 17, 2011, at 20:35, H.J. Lu wrote: >> - substitutions of likely-spilled regs, reload might die. >> + substitutions of likely-spilled regs, reload might die. Never >> + combine asm statement. > This has to be "statements", a plural. -Geert
Re: PATCH: PR rtl-optimization/47502: Never combine asm statement
On Thu, Mar 17, 2011 at 8:28 PM, Geert Bosch wrote: > > On Mar 17, 2011, at 20:35, H.J. Lu wrote: > >>> - substitutions of likely-spilled regs, reload might die. >>> + substitutions of likely-spilled regs, reload might die. Never >>> + combine asm statement. >> > This has to be "statements", a plural. > I will make the change. Thanks. -- H.J.
Re: [x32] PATCH: PR middle-end/47725: [x32] error: unable to find a register to spill in class DIREG
On Thu, Mar 17, 2011 at 5:30 PM, H.J. Lu wrote: > On Tue, Feb 15, 2011 at 2:55 PM, Bernd Schmidt > wrote: >> On 02/14/2011 08:46 PM, Eric Botcazou wrote: I agree with Jeff that combine would be the correct place to fix this. At least it takes class_likely_spilled_p into account, so it will restrict only those machines where extending the lifetime of hard regs is dangerous. >>> >>> OK, but I don't see how copying to a new pseudo would interfere with that. >> >> For one thing, the set no longer matches the REG_EQUIV note we make >> here, and that does seem to interfere with the optimization. I've tested >> both patches on ARM, -march=armv7-a. The combiner patch produced no code >> changes. The function.c patch produced regressions (increased register >> pressure). Both results are as expected. >> >> To put it another way: the combiner change is conservatively correct, >> and necessary if we're going to have extends of hard registers in the >> RTL. The function.c change is demonstrably incorrect as shown by the ARM >> codegen regressions. >> > > I checked in my patch into trunk. > I noticed that for x32, all pointers passed in registers are zero-extended by caller. If we can fix http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48085 by avoiding zero-extension in callee, this issue won't happen for x32. I will revert the combine change for now and try to implement this approach. Thanks. -- H.J.
