Fix multi-reg regno_reg_rtx entry
The short version:
This patch fixes a case where regno_reg_rtx[HI_REGNUM] included
LO_REGNUM. regno_reg_rtx[X] is supposed to refer only to register X.
The long version:
This patch fixes an ICE in compile/950612-1.c for -mips32r2 -mfp64
-mips16, which is a 4.7 regression. combine.c:distribute_notes was
trying to decompose a (reg:DI hi) REG_DEAD note into individual HI
and LO registers. It used regno_reg_rtx[] to get these individual
registers, but because regno_reg_rtx[HI_REGNUM] was itself (reg:DI hi),
we recursed endlessly.
HI is not allowed to store values independently of LO, so there is
no mode M for which:
HARD_REGNO_MODE_OK (HI_REGNUM, M) && HARD_REGNO_NREGS (HI_REGNUM, M) == 1
This causes init_reg_modes_target to pick the following default:
/* If we couldn't find a valid mode, just use the previous mode.
??? One situation in which we need to do this is on the mips where
HARD_REGNO_NREGS (fpreg, [SD]Fmode) returns 2. Ideally we'd like
to use DF mode for the even registers and VOIDmode for the odd
(for the cpu models where the odd ones are inaccessible). */
if (reg_raw_mode[i] == VOIDmode)
reg_raw_mode[i] = i == 0 ? word_mode : reg_raw_mode[i-1];
The problem is that register i-1 is the last FPR, which for -mips32r2
-mfp64 is a double-word (DImode) value. So we end up using DImode
for HI too.
[ BTw, I think the MIPS comment is wrong. HARD_REGNO_NREGS (fpreg, SFmode)
is (now) 1, even when using paired FPRs. And the suggestion doesn't
seem at all ideal to me. OK to remove? ]
A simple fix, which I've used below, is to make sure that the previous
mode requires only one register. We could drop the new assert if we want
to be even more conservative at this stage. A riskier but perhaps more
logical fix would be to call choose_hard_reg_mode again, this time
telling it to ignore HARD_REGNO_MODE_OK.
Tested on mips-sde-elf and x86_64-linux-gnu. OK to install?
Richard
gcc/
* reginfo.c (init_reg_modes_target): Only use the previous mode
if it fits within one register.
Index: gcc/reginfo.c
===
--- gcc/reginfo.c 2012-01-28 09:38:46.0 +
+++ gcc/reginfo.c 2012-01-28 09:38:46.0 +
@@ -621,7 +621,15 @@ init_reg_modes_target (void)
to use DF mode for the even registers and VOIDmode for the odd
(for the cpu models where the odd ones are inaccessible). */
if (reg_raw_mode[i] == VOIDmode)
- reg_raw_mode[i] = i == 0 ? word_mode : reg_raw_mode[i-1];
+ {
+ if (i > 0 && hard_regno_nregs[i][reg_raw_mode[i - 1]] == 1)
+ reg_raw_mode[i] = reg_raw_mode[i - 1];
+ else
+ {
+ reg_raw_mode[i] = word_mode;
+ gcc_assert (hard_regno_nregs[i][reg_raw_mode[i]] == 1);
+ }
+ }
}
}
Re: [C++ Patch] PR 51327
Hi again,
and sorry about the delay.
On 11/30/2011 06:41 PM, Paolo Carlini wrote:
Ok. The point is, locate_ctor turns an error_mark_node returned by
locate_fn_flags - meaning indeed not callable - into NULL_TREE. In fact,
uses elsewhere of locate_ctor / get_default_ctor always check for it.
Ah, I see. I guess what we want here is the GCC 4.5 version of
locate_ctor instead of the new one; once we've checked that we have a
default ctor and no user-provided default ctor, there must be a unique
defaulted ctor so just walking CLASSTYPE_CONSTRUCTORS is correct. And
then we can call maybe_explain_implicit_delete if it's deleted.
So, is the below a good implementation? Tested x86_64-linux.
Thanks,
Paolo.
/cp
2012-01-28 Paolo Carlini
PR c++/51327
* class.c (explain_non_literal_class): Correctly handle implicitly
deleted constructors.
/testsuite
2012-01-28 Paolo Carlini
PR c++/51327
* g++.dg/cpp0x/constexpr-ice6.C: New.
Index: testsuite/g++.dg/cpp0x/constexpr-ice6.C
===
--- testsuite/g++.dg/cpp0x/constexpr-ice6.C (revision 0)
+++ testsuite/g++.dg/cpp0x/constexpr-ice6.C (revision 0)
@@ -0,0 +1,11 @@
+// PR c++/51327
+// { dg-options -std=c++0x }
+
+struct A
+{
+ A(int);
+};
+
+struct B : A {}; // { dg-error "no matching" }
+
+constexpr int foo(B) { return 0; } // { dg-error "invalid type" }
Index: cp/class.c
===
--- cp/class.c (revision 183666)
+++ cp/class.c (working copy)
@@ -4910,7 +4910,25 @@ explain_non_literal_class (tree t)
"is not a copy or move constructor", t);
if (TYPE_HAS_DEFAULT_CONSTRUCTOR (t)
&& !type_has_user_provided_default_constructor (t))
- explain_invalid_constexpr_fn (locate_ctor (t));
+ {
+ tree fns;
+ for (fns = CLASSTYPE_CONSTRUCTORS (t); fns; fns = OVL_NEXT (fns))
+ {
+ tree fn = OVL_CURRENT (fns);
+ tree parms = TYPE_ARG_TYPES (TREE_TYPE (fn));
+
+ parms = skip_artificial_parms_for (fn, parms);
+
+ if (sufficient_parms_p (parms))
+ {
+ if (DECL_DELETED_FN (fn))
+ maybe_explain_implicit_delete (fn);
+ else
+ explain_invalid_constexpr_fn (fn);
+ break;
+ }
+ }
+ }
}
else
{
[Patch, Fortran] PR 52024 - Fix ambiguity check for type-bound GENERICs
For generics, one needs to distinguish between operators and other generics.
Assume:
function t_equal_i( t, i ) result(res)
function i_equal_t( i, t ) result(res)
For generic operators, those are not ambiguous as type> can not be confused with the reversed order.
For a generic function, those are ambiguous as (t=x, i=5)
will match both functions.
Build and regtested on x86-64-linux.
OK for the trunk?
Tobias
2012-01-28 Tobias Burnus
PR fortran/52024
* gfortran.h (gfc_tbp_generic): Store whether the
generic is an operator.
* decl.c (gfc_match_generic): Set that flag.
* resolve.c (check_generic_tbp_ambiguity): Use it in the
gfc_compare_interfaces check.
2012-01-28 Tobias Burnus
PR fortran/52024
* gfortran.dg/typebound_generic_11.f90: New.
Index: gcc/fortran/gfortran.h
===
--- gcc/fortran/gfortran.h (Revision 183664)
+++ gcc/fortran/gfortran.h (Arbeitskopie)
@@ -1118,2 +1118,3 @@ typedef struct gfc_tbp_generic
struct gfc_tbp_generic* next;
+ bool is_operator;
}
Index: gcc/fortran/resolve.c
===
--- gcc/fortran/resolve.c (Revision 183664)
+++ gcc/fortran/resolve.c (Arbeitskopie)
@@ -10966,2 +10995,3 @@ check_generic_tbp_ambiguity (gfc_tbp_gen
gcc_assert (!t2->specific->is_generic);
+ gcc_assert (t1->is_operator == t2->is_operator);
@@ -10984,3 +11014,4 @@ check_generic_tbp_ambiguity (gfc_tbp_gen
/* Compare the interfaces. */
- if (gfc_compare_interfaces (sym1, sym2, sym2->name, 1, 0, NULL, 0))
+ if (gfc_compare_interfaces (sym1, sym2, sym2->name, !t1->is_operator, 0,
+ NULL, 0))
{
Index: gcc/fortran/decl.c
===
--- gcc/fortran/decl.c (Revision 183664)
+++ gcc/fortran/decl.c (Arbeitskopie)
@@ -8394,2 +8394,4 @@ gfc_match_generic (void)
target->next = tb->u.generic;
+ target->is_operator = ((op_type == INTERFACE_USER_OP)
+ || (op_type == INTERFACE_INTRINSIC_OP));
tb->u.generic = target;
Index: gcc/testsuite/gfortran.dg/typebound_generic_11.f90
===
--- gcc/testsuite/gfortran.dg/typebound_generic_11.f90 (Revision 0)
+++ gcc/testsuite/gfortran.dg/typebound_generic_11.f90 (Arbeitskopie)
@@ -0,0 +1,63 @@
+! { dg-do compile }
+!
+! PR fortran/52024
+!
+! Contributed by Fran Martinez Fadrique
+!
+module m_test
+ type t_test
+integer :: i = 0
+ contains
+generic :: operator(==) => t_equal_i, i_equal_t ! OK
+procedure, private :: t_equal_i
+procedure, private, pass(t) :: i_equal_t
+ end type t_test
+contains
+ function t_equal_i (t, i) result(res)
+class(t_test), intent(in) :: t
+integer, intent(in) :: i
+logical :: res
+
+print *, 't_equal_i', t%i, i
+res = ( t%i == i )
+ end function t_equal_i
+
+ function i_equal_t (i, t) result(res)
+integer, intent(in) :: i
+class(t_test), intent(in) :: t
+logical :: res
+
+print *, 'i_equal_t', i, t%i
+res = ( t%i == i )
+ end function i_equal_t
+end module m_test
+
+module m_test2
+ type t2_test
+integer :: i = 0
+ contains
+generic :: gen => t2_equal_i, i_equal_t2 ! { dg-error "'t2_equal_i' and 'i_equal_t2' for GENERIC 'gen' at .1. are ambiguous" }
+procedure, private :: t2_equal_i
+procedure, private, pass(t) :: i_equal_t2
+ end type t2_test
+contains
+ function t2_equal_i (t, i) result(res)
+class(t2_test), intent(in) :: t
+integer,intent(in) :: i
+logical :: res
+
+print *, 't2_equal_i', t%i, i
+res = ( t%i == i )
+ end function t2_equal_i
+
+ function i_equal_t2 (i, t) result(res)
+integer,intent(in) :: i
+class(t2_test), intent(in) :: t
+logical :: res
+
+print *, 'i_equal_t2', i, t%i
+res = ( t%i == i )
+ end function i_equal_t2
+end module m_test2
+
+! { dg-final { cleanup-modules "m_test m_test2" } }
*ping* - [Patch, Fortran] PR41600 - fix ICE with type conversion in default initializer
* ping * http://gcc.gnu.org/ml/fortran/2012-01/msg00197.html On 22 January 2012, Tobias Burnus wrote: Dear all, the middle end does not like to fold_convert a real number to an integer, but gfortran does not type-convert the expressions of initialization expressions. This patch fixes the issue - and thus part of of the issue of the PR. Build and regtested on x86-64-linux. OK for the trunk? Tobias
Re: *ping* - [Patch, Fortran] PR41600 - fix ICE with type conversion in default initializer
Dear Tobias, I have this patch in my working tree since Jan 22. It works as advertised without regression. Note that it does not fix the ICE for the first test: pr41600.f90:1:0: internal compiler error: in gfc_conv_component_ref, at fortran/trans-expr.c:1131 Thanks, Dominique
Re: [committed] invoke.texi: fix hyphenation of "floating point" and related terms
On 1/27/2012 10:57 PM, Sandra Loosemore wrote: I've checked in this patch as obvious. (Again, if anyone thinks these kinds of edits are not obvious, let me know, and I'll start posting them for review first instead.) Following these dubious hyphenation rules slavishly is not a good idea. It makes searching more erratic. I recommend never hyphenating command line, and always hyphenating floating-point. Sometimes the best idea is to just drop the hyphen completetly. It seems for example (try google) that runtime is becoming much more accepted than run-time or run time. -Sandra 2012-01-28 Sandra Loosemore gcc/ * doc/invoke.texi: Correct hyphenation of "floating point", "double precision", and related terminology throughout the file.
Fix incantation of gcc.dg/torture/pr50444.c
There are existing examples in the directory.
Tested on i586-suse-linux, applied on the mainline as obvious.
2012-01-28 Eric Botcazou
* gcc.dg/torture/pr50444.c: Fix dg directives.
--
Eric Botcazou
Index: gcc.dg/torture/pr50444.c
===
--- gcc.dg/torture/pr50444.c (revision 183666)
+++ gcc.dg/torture/pr50444.c (working copy)
@@ -1,6 +1,6 @@
-/* { dg-require-effective-target sse2_runtime } */
-/* { dg-do run } */
+/* { dg-do run { target i?86-*-* x86_64-*-* } } */
/* { dg-options "-msse2" } */
+/* { dg-require-effective-target sse2_runtime } */
typedef long long __m128i __attribute__ ((__vector_size__ (16),
__may_alias__));
Re: [committed] invoke.texi: fix hyphenation of "floating point" and related terms
On 01/28/2012 08:44 AM, Robert Dewar wrote: On 1/27/2012 10:57 PM, Sandra Loosemore wrote: I've checked in this patch as obvious. (Again, if anyone thinks these kinds of edits are not obvious, let me know, and I'll start posting them for review first instead.) Following these dubious hyphenation rules slavishly is not a good idea. It makes searching more erratic. I recommend never hyphenating command line, and always hyphenating floating-point. "Command-line option" is specified in the GCC Coding Conventions, and I don't feel empowered to change that even if I thought it's a good idea (I don't). I note that the Coding Conventions specify hyphenated "bit-field" as a noun, which grates on me as being contrary to normal usage rules, but since it's in our house style guide, "bit-field" it is. I'd certainly prefer to avoid promulgating more exceptions like "floating-point" as a noun, though, and simply follow the normal recommendations of standard references like the Chicago Manual of Style instead. Sometimes the best idea is to just drop the hyphen completetly. It seems for example (try google) that runtime is becoming much more accepted than run-time or run time. Coincidentally, "runtime" is the subject of my next patch chunk, and I had to make some judgment calls there. I'll post it for review by one of the docs maintainers instead of just checking it in. -Sandra
[Patch, Fortran, committed] PR 51972 fix null-setting of ALLOCATE with polymorphic SOURCE=
I have committed the attached patch as obvious. The problem was: If the
allocate object had allocatable components, one set all those to zero.
Otherwise for polymorphic types one sets the whole allocated memory to zero.
If now the declared type had allocatable components but the effective
type added more such components, the latter never got nullified.
Solution: Checking the type BT_DERIVED on the allocate object
("al->expr") and not on "expr". The latter is "al->expr->_data" and thus
always BT_CLASS.
Build, regtested and committed (Rev. 183667) on x86-64-linux
NOTE: This patch does not solve all issues of the PR as there is also a
bug in _copy, which does only an incomplete deep copy. For details and a
possible solution see PR.
Tobias
2012-01-28 Tobias Burnus
PR fortran/51972
* trans-stmt.c (gfc_trans_allocate): Properly check whether
we have a BT_CLASS which needs to be memset.
2012-01-28 Tobias Burnus
PR fortran/51972
* gfortran.dg/class_allocate_12.f90: New.
Index: gcc/fortran/trans-stmt.c
===
--- gcc/fortran/trans-stmt.c (Revision 183667)
+++ gcc/fortran/trans-stmt.c (Arbeitskopie)
@@ -4950,7 +4950,8 @@ gfc_trans_allocate (gfc_code * code)
else
gfc_allocate_using_malloc (&se.pre, se.expr, memsz, stat);
- if (expr->ts.type == BT_DERIVED && expr->ts.u.derived->attr.alloc_comp)
+ if (al->expr->ts.type == BT_DERIVED
+ && expr->ts.u.derived->attr.alloc_comp)
{
tmp = build_fold_indirect_ref_loc (input_location, se.expr);
tmp = gfc_nullify_alloc_comp (expr->ts.u.derived, tmp, 0);
Index: gcc/testsuite/gfortran.dg/class_allocate_12.f90
===
--- gcc/testsuite/gfortran.dg/class_allocate_12.f90 (Revision 0)
+++ gcc/testsuite/gfortran.dg/class_allocate_12.f90 (Arbeitskopie)
@@ -0,0 +1,97 @@
+! { dg-do run }
+!
+! PR fortran/51972
+!
+! Contributed by Damian Rouson
+!
+! TODO: Remove the STOP line below after fixing
+! The remaining issue of the PR
+!
+
+module surrogate_module
+ type ,abstract :: surrogate
+ end type
+end module
+
+module strategy_module
+ use surrogate_module
+
+ type :: strategy
+ end type
+end module
+
+module integrand_module
+ use surrogate_module
+ use strategy_module
+ implicit none
+
+ type ,abstract, extends(surrogate) :: integrand
+class(strategy), allocatable :: quadrature
+ end type
+end module integrand_module
+
+module lorenz_module
+ use strategy_module
+ use integrand_module
+ implicit none
+
+ type ,extends(integrand) :: lorenz
+real, dimension(:), allocatable :: state
+ contains
+procedure ,public :: assign => assign_lorenz
+ end type
+contains
+ type(lorenz) function constructor(initial_state, this_strategy)
+real ,dimension(:) ,intent(in) :: initial_state
+class(strategy),intent(in) :: this_strategy
+constructor%state=initial_state
+allocate (constructor%quadrature, source=this_strategy)
+ end function
+
+ subroutine assign_lorenz(lhs,rhs)
+class(lorenz),intent(inout) :: lhs
+class(integrand) ,intent(in):: rhs
+select type(rhs)
+ class is (lorenz)
+allocate (lhs%quadrature, source=rhs%quadrature)
+lhs%state=rhs%state
+end select
+ end subroutine
+end module lorenz_module
+
+module runge_kutta_2nd_module
+ use surrogate_module,only : surrogate
+ use strategy_module ,only : strategy
+ use integrand_module,only : integrand
+ implicit none
+
+ type, extends(strategy) ,public :: runge_kutta_2nd
+ contains
+procedure, nopass :: integrate
+ end type
+contains
+ subroutine integrate(this)
+class(surrogate) ,intent(inout) :: this
+class(integrand) ,allocatable :: this_half
+
+select type (this)
+ class is (integrand)
+allocate (this_half, source=this)
+end select
+STOP 'SUCESS!' ! See TODO above
+ end subroutine
+end module
+
+program main
+ use lorenz_module
+ use runge_kutta_2nd_module ,only : runge_kutta_2nd, integrate
+ implicit none
+
+ type(runge_kutta_2nd) :: timed_lorenz_integrator
+ type(lorenz) :: attractor
+
+ attractor = constructor( [1., 1., 1.] , timed_lorenz_integrator)
+ call integrate(attractor)
+end program main
+
+! { dg-final { cleanup-modules "surrogate_module strategy_module integrand_module runge_kutta_2nd_module" } }
[PATCH] invoke.texi: "compile time", "run time" cleanup
I'm specifically asking for review of this patch by one of the docs
maintainers before checking it in, since it seems not everyone agrees
that these copyediting patches qualify as "obvious". In this particular
chunk, I had to make some judgment calls, too.
We usually use "compile time", "link time", and "run time" to refer to
the times at which the program is compiled, linked, and run,
respectively. So, the normal English rules about hyphenation apply
here; it's correct to say "at run time", but "run-time behavior", for
example.
To confuse matters, though, "compile time" can also be used as a noun
meaning "the amount of time it takes to compile". I saw that in some
places invoke.texi was already using "compilation time" for this meaning
instead and decided it made sense to apply that terminology uniformly.
Likewise "execution time" was already being used in some places for "the
amount of time it takes the program to run", so I made that usage
consistent. Confusingly, there were also a couple of places referring
to run time of a compilation pass; I reworded those to refer to
compilation time in that pass.
Finally, "runtime" (without a space or hyphen) is commonly used as a
noun to refer collectively to the startup code, libraries, trap
handlers, bootloader or operating system, etc that are present on the
target at run time. In the Objective-C section of this document there's
a lot of existing discussion of the "GNU runtime" versus the "NeXT
runtime", for example, and other option descriptions refer to the
"simulator runtime". Google shows a lot of variation on usage here (and
Wikipedia, in particular, is quite confused on this topic), but to me it
seems silly to make the adjective form of "runtime" hyphenated when it's
already a single word as a noun. So, I decided to go consistently with
"runtime support", "runtime library", etc when discussing what the
runtime includes.
OK to check in?
-Sandra
2012-01-28 Sandra Loosemore
gcc/
* doc/invoke.texi: Make usage of "compile time" and
"run time"/"runtime" consistent throughout the file.
Index: gcc/doc/invoke.texi
===
--- gcc/doc/invoke.texi (revision 183663)
+++ gcc/doc/invoke.texi (working copy)
@@ -1927,7 +1927,7 @@ exhaustion is signalled by throwing @cod
@item -fconserve-space
@opindex fconserve-space
-Put uninitialized or runtime-initialized global variables into the
+Put uninitialized or run-time-initialized global variables into the
common segment, as C does. This saves space in the executable at the
cost of not diagnosing duplicate definitions. If you compile with this
flag and your program mysteriously crashes after @code{main()} has
@@ -1990,7 +1990,7 @@ call the copy constructor in all cases.
@item -fno-enforce-eh-specs
@opindex fno-enforce-eh-specs
Don't generate code to check for violation of exception specifications
-at runtime. This option violates the C++ standard, but may be useful
+at run time. This option violates the C++ standard, but may be useful
for reducing code size in production builds, much like defining
@samp{NDEBUG}. This does not give user code permission to throw
exceptions in violation of the exception specifications; the compiler
@@ -2100,12 +2100,12 @@ Instantiation}, for more information.
@item -fno-rtti
@opindex fno-rtti
Disable generation of information about every class with virtual
-functions for use by the C++ runtime type identification features
+functions for use by the C++ run-time type identification features
(@samp{dynamic_cast} and @samp{typeid}). If you don't use those parts
of the language, you can save some space by using this flag. Note that
exception handling uses the same information, but it will generate it as
needed. The @samp{dynamic_cast} operator can still be used for casts that
-do not require runtime type information, i.e.@: casts to @code{void *} or to
+do not require run-time type information, i.e.@: casts to @code{void *} or to
unambiguous base classes.
@item -fstats
@@ -3637,7 +3637,7 @@ For an automatic variable, if there exis
entry to a use of the variable that is initialized, but there exist
some other paths the variable is not initialized, the compiler will
emit a warning if it can not prove the uninitialized paths do not
-happen at runtime. These warnings are made optional because GCC is
+happen at run time. These warnings are made optional because GCC is
not smart enough to see all the reasons why the code might be correct
despite appearing to have an error. Here is one example of how
this can happen:
@@ -5066,10 +5066,10 @@ The qualifier @code{dynamic} means that
dynamically: in addition to the static allocation described above, stack
adjustments are made in the body of the function, for example to push/pop
arguments around function calls. If the qualifier @code{bounded} is also
-present, the amount of these adjustmen
Re: [Bug c++/47791] finish function is using literal value instead of a #defined one
Hello Everyone,
Here is a patch to fix this bug. Please let me know if it is OK for
me to commit this into trunk.
Here is the Changelog entry:
===
2012-01-28 Balaji V. Iyer
* optimize.c (maybe_clone_body): Replace '0' in finish_function
parameter with "FF_DEFAULT."
* decl.c (end_cleanup_fn): Likewise.
* method.c (synthesize_method): Likewise.
* pt.c (instantiate_decl): Likewise.
* decl2.c (finish_objects): Likewise.
(finish_static_storage_duration_function): Likewise.
* parser.c (cp_parser_lambda_body): Replaced all occurances of '0', '1',
and '2' in finish_function parameters with "FF_DEFAULT,"
"FF_PRE_PARSED," and "FF_INCLASS_INLINE," respectively.
* semantics.c (maybe_add_lambda_conv_op): Replaced '2' in
finish_function with "FF_INCLASS_INLINE."
* cp-tree.h: Added FF_DEFAULT, FF_PRE_PARSED and FF_INCLASS_INLINE.
Thanks,
Balaji V. Iyer.
On Sat, Jan 28, 2012 at 12:56 AM, pinskia at gcc dot gnu.org
wrote:
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47791
>
> Andrew Pinski changed:
>
> What |Removed |Added
>
> Status|UNCONFIRMED |NEW
> Last reconfirmed| |2012-01-28
> Summary|finish function is using |finish function is using
> |absolute value instead of |literal value instead of a
> |the #defined one |#defined one
> Ever Confirmed|0 |1
>
> --- Comment #2 from Andrew Pinski 2012-01-28
> 05:56:07 UTC ---
> Confirmed,
>
> --
> Configure bugmail: http://gcc.gnu.org/bugzilla/userprefs.cgi?tab=email
> --- You are receiving this mail because: ---
> You reported the bug.
Index: cp/optimize.c
===
--- cp/optimize.c (revision 183668)
+++ cp/optimize.c (working copy)
@@ -415,7 +415,7 @@
cp_function_chain->can_throw = !TREE_NOTHROW (fn);
/* Now, expand this function into RTL, if appropriate. */
- finish_function (0);
+ finish_function (FF_DEFAULT);
BLOCK_ABSTRACT_ORIGIN (DECL_INITIAL (clone)) = DECL_INITIAL (fn);
if (alias)
{
Index: cp/decl.c
===
--- cp/decl.c (revision 183668)
+++ cp/decl.c (working copy)
@@ -6592,7 +6592,7 @@
static void
end_cleanup_fn (void)
{
- expand_or_defer_fn (finish_function (0));
+ expand_or_defer_fn (finish_function (FF_DEFAULT));
pop_from_top_level ();
}
Index: cp/method.c
===
--- cp/method.c (revision 183668)
+++ cp/method.c (working copy)
@@ -771,7 +771,7 @@
}
finish_function_body (stmt);
- expand_or_defer_fn (finish_function (0));
+ expand_or_defer_fn (finish_function (FF_DEFAULT));
input_location = save_input_location;
Index: cp/pt.c
===
--- cp/pt.c (revision 183668)
+++ cp/pt.c (working copy)
@@ -18750,7 +18750,7 @@
local_specializations = saved_local_specializations;
/* Finish the function. */
- d = finish_function (0);
+ d = finish_function (FF_DEFAULT);
expand_or_defer_fn (d);
}
Index: cp/semantics.c
===
--- cp/semantics.c (revision 183668)
+++ cp/semantics.c (working copy)
@@ -9332,7 +9332,7 @@
finish_compound_stmt (compound_stmt);
finish_function_body (body);
- expand_or_defer_fn (finish_function (2));
+ expand_or_defer_fn (finish_function (SF_INCLASS_INLINE));
/* Generate the body of the conversion op. */
@@ -9346,7 +9346,7 @@
finish_compound_stmt (compound_stmt);
finish_function_body (body);
- expand_or_defer_fn (finish_function (2));
+ expand_or_defer_fn (finish_function (FF_INCLASS_INLINE));
if (nested)
pop_function_context ();
Index: cp/decl2.c
===
--- cp/decl2.c (revision 183668)
+++ cp/decl2.c (working copy)
@@ -2833,7 +2833,7 @@
/* Finish up. */
finish_compound_stmt (body);
- fn = finish_function (0);
+ fn = finish_function (FF_DEFAULT);
if (method_type == 'I')
{
@@ -2975,7 +2975,7 @@
{
/* Close out the function. */
finish_compound_stmt (body);
- expand_or_defer_fn (finish_function (0));
+ expand_or_defer_fn (finish_function (FF_DEFAULT));
}
/* Return the information about the indicated PRIORITY level. If no
Index: cp/parser.c
===
--- cp/parser.c (revision 183668)
+++ cp/parser.c (working copy)
@@ -8559,7 +8559,7 @@
[PATCH] [Bug c++/47791] finish function is using literal value instead of a #defined one
Sorry..forgot to put the [PATCH] tag.
-- Forwarded message --
From: Balaji V. Iyer
Date: Sat, Jan 28, 2012 at 12:55 PM
Subject: Re: [Bug c++/47791] finish function is using literal value
instead of a #defined one
To: gcc-patches@gcc.gnu.org
Hello Everyone,
Here is a patch to fix this bug. Please let me know if it is OK for
me to commit this into trunk.
Here is the Changelog entry:
===
2012-01-28 Balaji V. Iyer
* optimize.c (maybe_clone_body): Replace '0' in finish_function
parameter with "FF_DEFAULT."
* decl.c (end_cleanup_fn): Likewise.
* method.c (synthesize_method): Likewise.
* pt.c (instantiate_decl): Likewise.
* decl2.c (finish_objects): Likewise.
(finish_static_storage_duration_function): Likewise.
* parser.c (cp_parser_lambda_body): Replaced all occurances of '0', '1',
and '2' in finish_function parameters with "FF_DEFAULT,"
"FF_PRE_PARSED," and "FF_INCLASS_INLINE," respectively.
* semantics.c (maybe_add_lambda_conv_op): Replaced '2' in
finish_function with "FF_INCLASS_INLINE."
* cp-tree.h: Added FF_DEFAULT, FF_PRE_PARSED and FF_INCLASS_INLINE.
Thanks,
Balaji V. Iyer.
On Sat, Jan 28, 2012 at 12:56 AM, pinskia at gcc dot gnu.org
wrote:
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47791
>
> Andrew Pinski changed:
>
> What |Removed |Added
>
> Status|UNCONFIRMED |NEW
> Last reconfirmed| |2012-01-28
> Summary|finish function is using |finish function is using
> |absolute value instead of |literal value instead of a
> |the #defined one |#defined one
> Ever Confirmed|0 |1
>
> --- Comment #2 from Andrew Pinski 2012-01-28
> 05:56:07 UTC ---
> Confirmed,
>
> --
> Configure bugmail: http://gcc.gnu.org/bugzilla/userprefs.cgi?tab=email
> --- You are receiving this mail because: ---
> You reported the bug.
Index: cp/optimize.c
===
--- cp/optimize.c (revision 183668)
+++ cp/optimize.c (working copy)
@@ -415,7 +415,7 @@
cp_function_chain->can_throw = !TREE_NOTHROW (fn);
/* Now, expand this function into RTL, if appropriate. */
- finish_function (0);
+ finish_function (FF_DEFAULT);
BLOCK_ABSTRACT_ORIGIN (DECL_INITIAL (clone)) = DECL_INITIAL (fn);
if (alias)
{
Index: cp/decl.c
===
--- cp/decl.c (revision 183668)
+++ cp/decl.c (working copy)
@@ -6592,7 +6592,7 @@
static void
end_cleanup_fn (void)
{
- expand_or_defer_fn (finish_function (0));
+ expand_or_defer_fn (finish_function (FF_DEFAULT));
pop_from_top_level ();
}
Index: cp/method.c
===
--- cp/method.c (revision 183668)
+++ cp/method.c (working copy)
@@ -771,7 +771,7 @@
}
finish_function_body (stmt);
- expand_or_defer_fn (finish_function (0));
+ expand_or_defer_fn (finish_function (FF_DEFAULT));
input_location = save_input_location;
Index: cp/pt.c
===
--- cp/pt.c (revision 183668)
+++ cp/pt.c (working copy)
@@ -18750,7 +18750,7 @@
local_specializations = saved_local_specializations;
/* Finish the function. */
- d = finish_function (0);
+ d = finish_function (FF_DEFAULT);
expand_or_defer_fn (d);
}
Index: cp/semantics.c
===
--- cp/semantics.c (revision 183668)
+++ cp/semantics.c (working copy)
@@ -9332,7 +9332,7 @@
finish_compound_stmt (compound_stmt);
finish_function_body (body);
- expand_or_defer_fn (finish_function (2));
+ expand_or_defer_fn (finish_function (SF_INCLASS_INLINE));
/* Generate the body of the conversion op. */
@@ -9346,7 +9346,7 @@
finish_compound_stmt (compound_stmt);
finish_function_body (body);
- expand_or_defer_fn (finish_function (2));
+ expand_or_defer_fn (finish_function (FF_INCLASS_INLINE));
if (nested)
pop_function_context ();
Index: cp/decl2.c
===
--- cp/decl2.c (revision 183668)
+++ cp/decl2.c (working copy)
@@ -2833,7 +2833,7 @@
/* Finish up. */
finish_compound_stmt (body);
- fn = finish_function (0);
+ fn = finish_function (FF_DEFAULT);
if (method_type == 'I')
{
@@ -2975,7 +2975,7 @@
{
/* Close out the function. */
finish_compound_stmt (body);
- expand_or_defer_fn (finish_function (0));
+ expand_or_defer_fn (finish_function (FF_DEFAULT));
[committed] Fix PR target/51871
The following change adds support for PA2.0 export stubs to pa_return_addr_rtx.
32-bit HP-UX is the only PA target to use these stubs. This fixes
PR target/51871.
Committed to trunk. Tested on hppa2.0w-hp-hpux11.11 and hppa64-hp-hpux11.11.
Dave
--
J. David Anglin dave.ang...@nrc-cnrc.gc.ca
National Research Council of Canada (613) 990-0752 (FAX: 952-6602)
2012-01-28 John David Anglin
PR target/51871
* config/pa/pa.c (pa_return_addr_rtx): Add support for PA2.0 export
stubs.
Index: config/pa/pa.c
===
--- config/pa/pa.c (revision 183539)
+++ config/pa/pa.c (working copy)
@@ -4501,7 +4501,7 @@
rtx saved_rp;
rtx ins;
- /* Instruction stream at the normal return address for the export stub:
+ /* The instruction stream at the return address of a PA1.X export stub is:
0x4bc23fd1 | stub+8: ldw -18(sr0,sp),rp
0x004010a1 | stub+12: ldsid (sr0,rp),r1
@@ -4509,11 +4509,17 @@
0xe042 | stub+20: be,n 0(sr0,rp)
0xe042 must be specified as -532676606 so that it won't be
- rejected as an invalid immediate operand on 64-bit hosts. */
+ rejected as an invalid immediate operand on 64-bit hosts.
- HOST_WIDE_INT insns[4] = {0x4bc23fd1, 0x004010a1, 0x00011820, -532676606};
- int i;
+ The instruction stream at the return address of a PA2.0 export stub is:
+ 0x4bc23fd1 | stub+8: ldw -18(sr0,sp),rp
+ 0xe840d002 | stub+12: bve,n (rp)
+ */
+
+ HOST_WIDE_INT insns[4];
+ int i, len;
+
if (count != 0)
return NULL_RTX;
@@ -4535,11 +4541,26 @@
ins = copy_to_reg (gen_rtx_AND (Pmode, rp, MASK_RETURN_ADDR));
label = gen_label_rtx ();
+ if (TARGET_PA_20)
+{
+ insns[0] = 0x4bc23fd1;
+ insns[1] = -398405630;
+ len = 2;
+}
+ else
+{
+ insns[0] = 0x4bc23fd1;
+ insns[1] = 0x004010a1;
+ insns[2] = 0x00011820;
+ insns[3] = -532676606;
+ len = 4;
+}
+
/* Check the instruction stream at the normal return address for the
export stub. If it is an export stub, than our return address is
really in -24[frameaddr]. */
- for (i = 0; i < 3; i++)
+ for (i = 0; i < len; i++)
{
rtx op0 = gen_rtx_MEM (SImode, plus_constant (ins, i * 4));
rtx op1 = GEN_INT (insns[i]);
[PATCH] Prevent frame-related insn from occurring in delay slots of insns that throw
Richard,
[now cc-ing gcc-patches]
this patch fixes PR50283 in a target-independent way.
it asserts on frame-related insns in the delay slot of insns that can throw,
and prevents the assert by testing for the same condition in
eligible_for_{delay,annul_true,annul_false}.
build and reg-tested on mips64el.
I don't know of any tests currently failing on this, so I think it's not
appropriate for stage4. OK for stage1 ?
Thanks,
- Tom
2012-01-27 Andrew Pinski
Tom de Vries
* dwarf2cfi.c (scan_trace): Add assert that frame-related insns should
not occur in delay-slots of insns that can throw.
* genattrtab.c (write_eligible_delay): Prevent frame-related insns from
occurring in delay-slots of insns that can throw.
Index: gcc/genattrtab.c
===
--- gcc/genattrtab.c (revision 183557)
+++ gcc/genattrtab.c (working copy)
@@ -4280,6 +4280,12 @@ write_eligible_delay (const char *kind)
printf (" if (!INSN_P (candidate_insn))\n");
printf ("return 0;\n");
printf ("\n");
+ /* Frame-related instructions should not be put into delay slots of
+ instructions that can throw. */
+ printf (" if (insn_could_throw_p (delay_insn)\n");
+ printf (" && RTX_FRAME_RELATED_P (candidate_insn))\n");
+ printf ("return 0;\n");
+ printf ("\n");
/* If more than one delay type, find out which type the delay insn is. */
Index: gcc/dwarf2cfi.c
===
--- gcc/dwarf2cfi.c (revision 183557)
+++ gcc/dwarf2cfi.c (working copy)
@@ -2474,6 +2474,8 @@ scan_trace (dw_trace_info *trace)
for (i = 1; i < n; ++i)
{
elt = XVECEXP (pat, 0, i);
+ gcc_assert (!(insn_could_throw_p (control)
+ && RTX_FRAME_RELATED_P (elt)));
scan_insn_after (elt);
}
[PATCH] disable __size_t macro on GNU/kFreeBSD
Hi, Please consider this patch to stddef.h. GNU/kFreeBSD has the same problem with __size_t as FreeBSD does, since it inherits many kernel headers from FreeBSD. -- Robert Millan 2012-01-29 Robert Millan * ginclude/stddef.h [__FreeBSD_kernel__] (__size_t): Do not define. Index: ginclude/stddef.h === --- ginclude/stddef.h (revision 183670) +++ ginclude/stddef.h (working copy) @@ -200,7 +200,7 @@ #define ___int_size_t_h #define _GCC_SIZE_T #define _SIZET_ -#if defined (__FreeBSD__) && (__FreeBSD__ >= 5) +#if (defined (__FreeBSD__) && (__FreeBSD__ >= 5)) || defined(__FreeBSD_kernel__) /* __size_t is a typedef on FreeBSD 5!, must not trash it. */ #else #define __size_t
