Re: RFC: Use std::{min,max} instead of MIN/MAX?
On Fri, Jul 10, 2015 at 03:35:57PM -0400, Trevor Saunders wrote: > You can also explicitly pick the specialization you want with e.g. > std::max (x, y); its kind of long, but I can see an argument > for the explicitness so I'm not sure how ugly I think it is. Thanks for pointing this out. Yea, that'd be an option, though I don't think people would be too happy about that. Marek
Re: PATCHes to help with C++11 bootstrap
On Sat, 9 May 2015, Jason Merrill wrote: > On 05/09/2015 05:37 AM, Richard Biener wrote: > > Hmm, I wonder if we want to bootstrap with explicit -std=gnu04, our host > > compiler requirement. Otherwise we'll silently sneak in C++11 features when > > that becomes the default? > > I think just for stage 1. When that happens, can we backport a patch to add -std=gnu04 to the gcc5 branch, so at least that version can be compiled with "newer" compilers where C++11 is the default? (This will be an issue with cross-compilers for *all* older releases.) Maybe it's already in and my grep-fu is failing. brgds, H-P
Re: [RFC, Fortran, (pr66775)] Allocatable function result
Hi, >"On completion of execution of the function, the value returned > is that of its function result. ... If the function result is > not a pointer, its value shall be defined by the function." Now we can argue whether the "shall be defined" is to be interpreted as "has to be" or as "might be". For me - being a non-native English speaker - that "shall" is not an obligation but should be interpreted as "commonly the function result is to be defined, but there can be exceptions". Now I am curious about how native English speakers understand that standard statement. My argument on returning an unallocated object is not to support programatical errors, but rather for circumstances, where one tries to allocate a resource and on failure nothing is returned. Think about a function like try_to_acquire_resource(), when the resource could be reserved (like, for example, a co-processor), then its (private) structure is returned (implementing the OO concept of information hiding). Furthermore one could think about using concepts like memory pools, where a memory fragment is returned by a function as long as the capacity of the pool is no exhausted. This of course is more difficult in Fortran as is lacks the ways of doing C-style pointer arithmetic. This is just an example. So please don't nail me on this one. I just wanted to give you my idea, why I think returning an unallocated "object" should be legal for an allocatable function result. (Note, the result is called allocatable, not allocated function result :-). Meaning, that it can be allocated, but does not have to be.) When someone has other compilers available the test program is attached. Regards, Andre -- Andre Vehreschild * Email: vehre ad gmx dot de test_pr66775.f03 Description: Binary data
Re: [RFC, Fortran, (pr66775)] Allocatable function result
Le 10/07/2015 20:57, Steve Kargl a écrit : > On Fri, Jul 10, 2015 at 06:20:47PM +0200, Mikael Morin wrote: >> >> I'm not completely convinced by the standard excerpts that have been >> quoted about this topic, as they don't have any explicit mention of >> allocatable variables/expressions. > > I did not quote 12.3.3 about "characteristics of function results", > which mentions the allocatable attribute. But, that is not > necessarily relevant. The pieces I quoted explicitly states > >"On completion of execution of the function, the value returned > is that of its function result. ... If the function result is > not a pointer, its value shall be defined by the function." Yeah, well, if the standard committee had allowed unallocated allocatable results, they would have put it here together with pointer, I guess. > > The function not only needs to allocate memory, it needs to > assign it a value. In the following, if i <= 0, the function > result is not defined. > > module foo >contains >function bar(i) > integer, allocatable :: bar > integer, intent(in) :: i > if (i > 0) bar = i >end function bar > end module foo > > program test >use foo >integer j >j = bar( 3); print *, j >j = bar(-3); print *, j >end if > end program test > > Even if Andre developed a patch to allocate memory in > bar() for the i <= 0 case to prevent the segfault, the > function must return a value. What should that value be? Your example is, of course, 100% invalid; a value is needed to put in j. But the case is more debatable to me, if j is allocatable. In that case an unallocated bar() result could just make j unallocated. Mikael
Re: [RFC, Fortran, (pr66775)] Allocatable function result
Hi, > > module foo > >contains > >function bar(i) > > integer, allocatable :: bar > > integer, intent(in) :: i > > if (i > 0) bar = i > >end function bar > > end module foo > > > > program test > >use foo > >integer j > >j = bar( 3); print *, j > >j = bar(-3); print *, j > >end if > > end program test > > > > Even if Andre developed a patch to allocate memory in > > bar() for the i <= 0 case to prevent the segfault, the > > function must return a value. What should that value be? > Your example is, of course, 100% invalid; a value is needed to put in j. > But the case is more debatable to me, if j is allocatable. > In that case an unallocated bar() result could just make j unallocated. Yes, completely right. The example so far is not on the point I try to make. For your example Steve, the result of bar has to be allocated, no argument on that, but what about, when j is allocatable? As stated in a previous mail, that property is not called allocated, but allocatable... - Andre -- Andre Vehreschild * Email: vehre ad gmx dot de
Re: [RFC, Fortran, (pr66775)] Allocatable function result
Le 11/07/2015 12:36, Andre Vehreschild a écrit : > Hi, > > >>"On completion of execution of the function, the value returned >> is that of its function result. ... If the function result is >> not a pointer, its value shall be defined by the function." > > Now we can argue whether the "shall be defined" is to be interpreted as "has > to > be" or as "might be". For me - being a non-native English speaker - that > "shall" > is not an obligation but should be interpreted as "commonly the function > result > is to be defined, but there can be exceptions". Now I am curious about how > native English speakers understand that standard statement. I'm non-native as well, but my interpretation is "has to be". :-( Which (if correct) puts this topic out of the standard territory. Mikael
Re: [patch] fixes -fcilkplus functionality on DragonFly (fixes ~2600 tests)
On 11 July 2015 at 06:46, Jeff Law wrote: > On 07/10/2015 06:34 PM, John Marino wrote: >> >> After posting the first testsuite results for DragonFly, it was clear >> that the -fcilkplus functionality was broken: >> https://gcc.gnu.org/ml/gcc-testresults/2015-07/msg01046.html >> >> The problem was related to the __cpu_model symbol not getting exported. >> >> The solution was to create libgcc/config/i386/t-dragonfly to define an >> additional symbol map (similar to t-freebsd). Simply creating the file >> is enough because there's already a placeholder for t-dragonfly at >> libgcc/config.host. The patch is attached. >> >> The improved results of the patch can be seen on the next posted >> testsuite results: >> https://gcc.gnu.org/ml/gcc-testresults/2015-07/msg01081.html >> >> An additional ~2600 tests now pass. >> Please consider this patch for incorporation into trunk. Only DragonFly >> uses the new t-dragonfly file so there is no impact to other platforms. >> >> suggested entry for libgcc/ChangeLog: >> >> 2015-07-XX John Marino >> >> * config/i386/t-dragonfly: New. > > OK. > jeff > John, If you like I can commit this for you on Monday when I commit your patch to os_defines.h.
Re: [RFC, Fortran, (pr66775)] Allocatable function result
Hi, > On Jul 11, 2015, at 04:36 , Andre Vehreschild wrote: > >> >> "On completion of execution of the function, the value returned >>is that of its function result. ... If the function result is >>not a pointer, its value shall be defined by the function." > > Now we can argue whether the "shall be defined" is to be interpreted as "has > to > be" or as "might be". For me - being a non-native English speaker - that > "shall" > is not an obligation but should be interpreted as "commonly the function > result > is to be defined, but there can be exceptions". Now I am curious about how > native English speakers understand that standard statement. The standard is written in standardese, not English. “Shall” is a requirement. Full stop. -- Cheers! Dan Nagle
Re: [Patch, Fortran, 66035, v2] [5/6 Regression] gfortran ICE segfault
Hi Mikael,
> > @@ -7030,7 +7053,8 @@ gfc_trans_subcomponent_assign (tree dest,
> > gfc_component * cm, gfc_expr * expr, gfc_add_expr_to_block (&block, tmp);
> > }
> >else if (init && (cm->attr.allocatable
> > - || (cm->ts.type == BT_CLASS && CLASS_DATA
> > (cm)->attr.allocatable)))
> > + || (cm->ts.type == BT_CLASS && CLASS_DATA (cm)->attr.allocatable
> > + && expr->ts.type != BT_CLASS)))
> > {
> >/* Take care about non-array allocatable components here. The
> > alloc_* routine below is motivated by the alloc_scalar_allocatable_for_
> > @@ -7074,6 +7098,14 @@ gfc_trans_subcomponent_assign (tree dest,
> > gfc_component * cm, gfc_expr * expr, tmp = gfc_build_memcpy_call (tmp,
> > se.expr, size); gfc_add_expr_to_block (&block, tmp);
> > }
> > + else if (cm->ts.type == BT_CLASS && expr->ts.type == BT_CLASS)
> > + {
> > + tmp = gfc_copy_class_to_class (se.expr, dest, integer_one_node,
> > + CLASS_DATA
> > (cm)->attr.unlimited_polymorphic);
> > + gfc_add_expr_to_block (&block, tmp);
> > + gfc_add_modify (&block, gfc_class_vptr_get (dest),
> > + gfc_class_vptr_get (se.expr));
> > + }
> >else
> > gfc_add_modify (&block, tmp,
> > fold_convert (TREE_TYPE (tmp), se.expr));
> But this hunk is canceled by the one before, isn't it?
> I mean, If the condition here is true, the condition before was false?
You are absolutely right. The second hunk is dead code and removed in the
attached patch. That must have been the first attempt to address the issue and
later on I did not perceive that it was useless. Sorry for that.
Regards,
Andre
--
Andre Vehreschild * Email: vehre ad gmx dot de
diff --git a/gcc/fortran/trans-expr.c b/gcc/fortran/trans-expr.c
index adc5c0a..bab1cce 100644
--- a/gcc/fortran/trans-expr.c
+++ b/gcc/fortran/trans-expr.c
@@ -6902,6 +6902,29 @@ alloc_scalar_allocatable_for_subcomponent_assignment (stmtblock_t *block,
TREE_TYPE (tmp), tmp,
fold_convert (TREE_TYPE (tmp), size));
}
+ else if (cm->ts.type == BT_CLASS)
+{
+ gcc_assert (expr2->ts.type == BT_CLASS || expr2->ts.type == BT_DERIVED);
+ if (expr2->ts.type == BT_DERIVED)
+ {
+ tmp = gfc_get_symbol_decl (expr2->ts.u.derived);
+ size = TYPE_SIZE_UNIT (tmp);
+ }
+ else
+ {
+ gfc_expr *e2vtab;
+ gfc_se se;
+ e2vtab = gfc_find_and_cut_at_last_class_ref (expr2);
+ gfc_add_vptr_component (e2vtab);
+ gfc_add_size_component (e2vtab);
+ gfc_init_se (&se, NULL);
+ gfc_conv_expr (&se, e2vtab);
+ gfc_add_block_to_block (block, &se.pre);
+ size = fold_convert (size_type_node, se.expr);
+ gfc_free_expr (e2vtab);
+ }
+ size_in_bytes = size;
+}
else
{
/* Otherwise use the length in bytes of the rhs. */
@@ -7029,7 +7052,8 @@ gfc_trans_subcomponent_assign (tree dest, gfc_component * cm, gfc_expr * expr,
gfc_add_expr_to_block (&block, tmp);
}
else if (init && (cm->attr.allocatable
- || (cm->ts.type == BT_CLASS && CLASS_DATA (cm)->attr.allocatable)))
+ || (cm->ts.type == BT_CLASS && CLASS_DATA (cm)->attr.allocatable
+ && expr->ts.type != BT_CLASS)))
{
/* Take care about non-array allocatable components here. The alloc_*
routine below is motivated by the alloc_scalar_allocatable_for_
diff --git a/gcc/testsuite/gfortran.dg/structure_constructor_13.f03 b/gcc/testsuite/gfortran.dg/structure_constructor_13.f03
new file mode 100644
index 000..c74e325
--- /dev/null
+++ b/gcc/testsuite/gfortran.dg/structure_constructor_13.f03
@@ -0,0 +1,28 @@
+! { dg-do run }
+!
+! Contributed by Melven Roehrig-Zoellner
+! PR fortran/66035
+
+program test_pr66035
+ type t
+ end type t
+ type w
+class(t), allocatable :: c
+ end type w
+
+ type(t) :: o
+
+ call test(o)
+contains
+ subroutine test(o)
+class(t), intent(inout) :: o
+type(w), dimension(:), allocatable :: list
+
+select type (o)
+ class is (t)
+list = [w(o)] ! This caused an ICE
+ class default
+call abort()
+end select
+ end subroutine
+end program
Re: [patch] fixes -fcilkplus functionality on DragonFly (fixes ~2600 tests)
On 7/11/2015 1:45 PM, Jonathan Wakely wrote: > On 11 July 2015 at 06:46, Jeff Law wrote: >> On 07/10/2015 06:34 PM, John Marino wrote: >>> >>> After posting the first testsuite results for DragonFly, it was clear >>> that the -fcilkplus functionality was broken: >>> https://gcc.gnu.org/ml/gcc-testresults/2015-07/msg01046.html >>> >>> The problem was related to the __cpu_model symbol not getting exported. >>> >>> The solution was to create libgcc/config/i386/t-dragonfly to define an >>> additional symbol map (similar to t-freebsd). Simply creating the file >>> is enough because there's already a placeholder for t-dragonfly at >>> libgcc/config.host. The patch is attached. >>> >>> The improved results of the patch can be seen on the next posted >>> testsuite results: >>> https://gcc.gnu.org/ml/gcc-testresults/2015-07/msg01081.html >>> >>> An additional ~2600 tests now pass. >>> Please consider this patch for incorporation into trunk. Only DragonFly >>> uses the new t-dragonfly file so there is no impact to other platforms. >>> >>> suggested entry for libgcc/ChangeLog: >>> >>> 2015-07-XX John Marino >>> >>> * config/i386/t-dragonfly: New. >> >> OK. >> jeff >> > > John, If you like I can commit this for you on Monday when I commit > your patch to os_defines.h. > That is very kind, Jonathan! thanks, Monday would be great. John P.S. I have a 3rd simple one that you can commit on Monday as well if it gets approved (no reason it shouldn't): https://gcc.gnu.org/ml/gcc-patches/2015-07/msg00897.html
Re: [RFC, Fortran, (pr66775)] Allocatable function result
On Sat, Jul 11, 2015 at 12:54:33PM +0200, Mikael Morin wrote: > Le 10/07/2015 20:57, Steve Kargl a ?crit : > > On Fri, Jul 10, 2015 at 06:20:47PM +0200, Mikael Morin wrote: > >> > >> I'm not completely convinced by the standard excerpts that have been > >> quoted about this topic, as they don't have any explicit mention of > >> allocatable variables/expressions. > > > > I did not quote 12.3.3 about "characteristics of function results", > > which mentions the allocatable attribute. But, that is not > > necessarily relevant. The pieces I quoted explicitly states > > > >"On completion of execution of the function, the value returned > > is that of its function result. ... If the function result is > > not a pointer, its value shall be defined by the function." > Yeah, well, if the standard committee had allowed unallocated > allocatable results, they would have put it here together with pointer, > I guess. > >From F95, 6.3.1.1. "An allocatable array that has been allocated by an ALLOCATE statement and has not been subsequently deallocated (6.3.3) is currently allocated and is definable." Note it is "definable". It is not defined. I cannot find a similar statement in F08 due to the massive rewrite of the standard to accommodate new features (e.g., co-arrays and allocation-on-assignment). F08 6.7.1.3 does say The allocation status of an allocatable entity is one of the following at any time. * The status of an allocatable variable becomes "allocated" if it is allocated by and ALLOCATE statement, if it allocated during assignment, or if it is given that status by the intrinsic subroutine MOVE_ALLOC (13.7.118). An allocatable variable with this status my be referenced, defined, or deallocated; ... * An allocatable variable has a status of "unallocated" if it is not allocated. The status of an allocatable variable becomes unallocated if it is deallocated (6.7.3) or if it is given that status by the allocation transfer procedure. So, change my example to what you want module foo contains function bar(i) integer, allocatable :: bar integer, intent(in) :: i if (i > 0) bar = i end function bar end module foo program test use foo integer, allocatable :: j j = bar( 3); if (allocated(j)) print *, j j = bar(-3); if (allocated(j)) print *, j end program test So, it seems you want the allocation status of j in 'j = bar(-3)' to be unallocated due to the "allocation-on-assignment" feature of f08. I'll simply note that *there is no assignment* as bar(-3) does not return an a value, which is required by If the function result is not a pointer, its value shall be defined by the function. So, you want unallocation-on-nonassignment, which is not in the standard. -- steve
Re: [gomp4.1] depend(sink) and depend(source) parsing for C
It looks like the C++ bits are quite similar to the C ones. AFAICT,
only numbers are allowed for the sink offsets, so no C++ iterators,
which would likely complicate matters. If they are eventually allowed,
we can implement them as a follow up.
The attached patch addresses all your concerns plus includes the C++
implementation. The included test passes for both languages.
I can work on Fortran next if you'd like.
Aldy
diff --git a/gcc/c/c-parser.c b/gcc/c/c-parser.c
index cd3bd5a..50edaf6 100644
--- a/gcc/c/c-parser.c
+++ b/gcc/c/c-parser.c
@@ -11701,6 +11701,95 @@ c_parser_omp_clause_simdlen (c_parser *parser, tree
list)
return c;
}
+/* OpenMP 4.1:
+ vec:
+ identifier [+/- integer]
+ vec , identifier [+/- integer]
+*/
+
+static tree
+c_parser_omp_clause_depend_sink (c_parser *parser, location_t clause_loc,
+tree list)
+{
+ tree vec = NULL;
+ if (c_parser_next_token_is_not (parser, CPP_NAME)
+ || c_parser_peek_token (parser)->id_kind != C_ID_ID)
+{
+ c_parser_error (parser, "expected identifier");
+ return list;
+}
+
+ while (c_parser_next_token_is (parser, CPP_NAME)
+&& c_parser_peek_token (parser)->id_kind == C_ID_ID)
+{
+ tree t = lookup_name (c_parser_peek_token (parser)->value);
+ tree addend = NULL;
+
+ if (t == NULL_TREE)
+ {
+ undeclared_variable (c_parser_peek_token (parser)->location,
+ c_parser_peek_token (parser)->value);
+ t = error_mark_node;
+ }
+
+ c_parser_consume_token (parser);
+
+ if (t != error_mark_node)
+ {
+ bool neg;
+
+ if (c_parser_next_token_is (parser, CPP_MINUS))
+ neg = true;
+ else if (c_parser_next_token_is (parser, CPP_PLUS))
+ neg = false;
+ else
+ {
+ addend = integer_zero_node;
+ goto add_to_vector;
+ }
+ c_parser_consume_token (parser);
+
+ if (c_parser_next_token_is_not (parser, CPP_NUMBER))
+ {
+ c_parser_error (parser, "expected %");
+ return list;
+ }
+
+ addend = c_parser_peek_token (parser)->value;
+ if (TREE_CODE (addend) != INTEGER_CST)
+ {
+ c_parser_error (parser, "expected %");
+ return list;
+ }
+ if (neg)
+ {
+ bool overflow;
+ wide_int offset = wi::neg (addend, &overflow);
+ addend = wide_int_to_tree (TREE_TYPE (addend), offset);
+ if (overflow)
+ warning_at (c_parser_peek_token (parser)->location,
+ OPT_Woverflow,
+ "overflow in implicit constant conversion");
+ }
+ c_parser_consume_token (parser);
+
+ add_to_vector:
+ vec = tree_cons (addend, t, vec);
+
+ if (c_parser_next_token_is_not (parser, CPP_COMMA))
+ break;
+
+ c_parser_consume_token (parser);
+ }
+}
+
+ tree u = build_omp_clause (clause_loc, OMP_CLAUSE_DEPEND);
+ OMP_CLAUSE_DEPEND_KIND (u) = OMP_CLAUSE_DEPEND_SINK;
+ OMP_CLAUSE_DECL (u) = nreverse (vec);
+ OMP_CLAUSE_CHAIN (u) = list;
+ return u;
+}
+
/* OpenMP 4.0:
depend ( depend-kind: variable-list )
@@ -11708,10 +11797,9 @@ c_parser_omp_clause_simdlen (c_parser *parser, tree
list)
in | out | inout
OpenMP 4.1:
- depend ( depend-loop-kind [ : vec ] )
+ depend ( source )
- depend-loop-kind:
- source | sink */
+ depend ( sink : vec ) */
static tree
c_parser_omp_clause_depend (c_parser *parser, tree list)
@@ -11754,16 +11842,19 @@ c_parser_omp_clause_depend (c_parser *parser, tree
list)
return c;
}
- /* FIXME: Handle OMP_CLAUSE_DEPEND_SINK. */
-
if (!c_parser_require (parser, CPP_COLON, "expected %<:%>"))
goto resync_fail;
- nl = c_parser_omp_variable_list (parser, clause_loc,
- OMP_CLAUSE_DEPEND, list);
+ if (kind == OMP_CLAUSE_DEPEND_SINK)
+nl = c_parser_omp_clause_depend_sink (parser, clause_loc, list);
+ else
+{
+ nl = c_parser_omp_variable_list (parser, clause_loc,
+ OMP_CLAUSE_DEPEND, list);
- for (c = nl; c != list; c = OMP_CLAUSE_CHAIN (c))
-OMP_CLAUSE_DEPEND_KIND (c) = kind;
+ for (c = nl; c != list; c = OMP_CLAUSE_CHAIN (c))
+ OMP_CLAUSE_DEPEND_KIND (c) = kind;
+}
c_parser_skip_until_found (parser, CPP_CLOSE_PAREN, "expected %<)%>");
return nl;
diff --git a/gcc/c/c-typeck.c b/gcc/c/c-typeck.c
index 469cd88..0b332e8 100644
--- a/gcc/c/c-typeck.c
+++ b/gcc/c/c-typeck.c
@@ -12489,6 +12489,11 @@ c_finish_omp_clauses (tree clauses, bool declare_simd)
== OMP_CLAUSE_DEPEND_SOURCE);
break;
}
+ if (OMP_CLAUSE_DEPEND_KIND (c) == OMP_CLAUSE_DEPEND_SINK)
+ {
+ gcc_assert (TREE_CODE (t) == T
Re: [gomp4.1] depend(sink) and depend(source) parsing for C
+ c->iter_vars.safe_push(0); + c->iter_vars.pop(); Whoops. Consider this removed. This was left over from some tests I was doing with the vector. Aldy
[PATCH] PR target/66824: Allow software FP SFmode in FP splitter
On Thu, Jul 09, 2015 at 01:58:22PM -0700, H.J. Lu wrote:
> On Thu, Jul 09, 2015 at 12:13:38PM -0700, H.J. Lu wrote:
> > ix86_split_long_move can optimize floating point constant move, which
> > can be used to optimize SFmode move for IA MCU.
> >
> > OK for trunk if there is no regression?
> >
> >
> > H.J.
> > ---
> > gcc/
> >
> > PR target/66824
> > * config/i386/i386.c (ix86_split_to_parts): Allow SFmode move
> > for IA MCU.
> > (ix86_split_long_move): Support single move.
> > * config/i386/i386.md (FP splitter): Allow SFmode for IA MCU.
> >
> > gcc/testsuite/
> >
> > PR target/66824
> > * gcc.target/i386/pr66824.c: New test.
> > ---
>
>
> I missed the testcase. Here is the updated patch.
>
ix86_split_long_move can optimize floating point constant move, which
can be used to optimize SFmode move with software floating point.
OK for trunk if there are no regressions?
H.J.
--
gcc/
PR target/66824
* config/i386/i386.c (ix86_split_to_parts): Allow SFmode move
without 387, MMX nor SSE.
(ix86_split_long_move): Support single move.
* config/i386/i386.md (FP splitter): Allow SFmode without 387,
MMX nor SSE.
gcc/testsuite/
PR target/66824
* gcc.target/i386/pr66824.c: New test.
---
gcc/config/i386/i386.c | 18 +-
gcc/config/i386/i386.md | 6 +-
gcc/testsuite/gcc.target/i386/pr66824.c | 29 +
3 files changed, 51 insertions(+), 2 deletions(-)
create mode 100644 gcc/testsuite/gcc.target/i386/pr66824.c
diff --git a/gcc/config/i386/i386.c b/gcc/config/i386/i386.c
index 6b5af11..108f211 100644
--- a/gcc/config/i386/i386.c
+++ b/gcc/config/i386/i386.c
@@ -22756,7 +22756,13 @@ ix86_split_to_parts (rtx operand, rtx *parts,
machine_mode mode)
size = (GET_MODE_SIZE (mode) + 4) / 8;
gcc_assert (!REG_P (operand) || !MMX_REGNO_P (REGNO (operand)));
- gcc_assert (size >= 2 && size <= 4);
+ /* For software floating point, we also optimize SFmode move. */
+ gcc_assert ((size >= 2
+ || (mode == SFmode
+ && !TARGET_80387
+ && !TARGET_MMX
+ && !TARGET_SSE))
+ && size <= 4);
/* Optimize constant pool reference to immediates. This is used by fp
moves, that force all constants to memory to allow combining. */
@@ -22834,10 +22840,14 @@ ix86_split_to_parts (rtx operand, rtx *parts,
machine_mode mode)
case DFmode:
REAL_VALUE_TO_TARGET_DOUBLE (r, l);
break;
+ case SFmode:
+ REAL_VALUE_TO_TARGET_SINGLE (r, l[0]);
+ goto part0;
default:
gcc_unreachable ();
}
parts[1] = gen_int_mode (l[1], SImode);
+part0:
parts[0] = gen_int_mode (l[0], SImode);
}
else
@@ -22944,6 +22954,12 @@ ix86_split_long_move (rtx operands[])
nparts = ix86_split_to_parts (operands[1], part[1], GET_MODE (operands[0]));
ix86_split_to_parts (operands[0], part[0], GET_MODE (operands[0]));
+ if (nparts == 1)
+{
+ emit_move_insn (part[0][0], part[1][0]);
+ return;
+}
+
/* When emitting push, take care for source operands on the stack. */
if (push && MEM_P (operands[1])
&& reg_overlap_mentioned_p (stack_pointer_rtx, operands[1]))
diff --git a/gcc/config/i386/i386.md b/gcc/config/i386/i386.md
index bc98389..0351c36 100644
--- a/gcc/config/i386/i386.md
+++ b/gcc/config/i386/i386.md
@@ -3507,7 +3507,11 @@
"reload_completed
&& (GET_MODE (operands[0]) == TFmode
|| GET_MODE (operands[0]) == XFmode
- || GET_MODE (operands[0]) == DFmode)
+ || GET_MODE (operands[0]) == DFmode
+ || (GET_MODE (operands[0]) == SFmode
+ && !TARGET_80387
+ && !TARGET_MMX
+ && !TARGET_SSE))
&& !(ANY_FP_REG_P (operands[0]) || ANY_FP_REG_P (operands[1]))"
[(const_int 0)]
"ix86_split_long_move (operands); DONE;")
diff --git a/gcc/testsuite/gcc.target/i386/pr66824.c
b/gcc/testsuite/gcc.target/i386/pr66824.c
new file mode 100644
index 000..3511e4c
--- /dev/null
+++ b/gcc/testsuite/gcc.target/i386/pr66824.c
@@ -0,0 +1,29 @@
+/* { dg-do compile { target ia32 } } */
+/* { dg-options "-O2 -mno-sse -mno-mmx -mno-80387" } */
+/* { dg-final { scan-assembler-not "\.LC\[0-9\]" } } */
+
+double foo (float);
+
+double
+f1 (void)
+{
+ return foo (1.0);
+}
+
+double
+f2 (void)
+{
+ return foo (0.0);
+}
+
+void
+f3 (float *x, float t)
+{
+ *x = 0.0 + t;
+}
+
+float
+f4 (void)
+{
+ return 1.0;
+}
--
2.4.3
[gomp4] Revert "Work around nvptx offloading compiler --enable-checking=yes,df,fold,rtl breakage" (was: fix df verify failure)
Hi! On Fri, 10 Jul 2015 18:04:36 -0400, Nathan Sidwell wrote: > I've committed this patch to fix a df verify crash Thomas pointed me at. Thanks! > Thomas, I think this means you can revert the workaround you just committed? Right. Committed in r225714: commit 687f194e535317024ca67c32b26bb277b6f266ae Author: tschwinge Date: Sat Jul 11 19:21:48 2015 + Revert "Work around nvptx offloading compiler --enable-checking=yes,df,fold,rtl breakage" This reverts r225656; problem get addressed in r225695. gcc/ * df-core.c (df_analyze_1): Don't disable df_verify call. git-svn-id: svn+ssh://gcc.gnu.org/svn/gcc/branches/gomp-4_0-branch@225714 138bc75d-0d04-0410-961f-82ee72b054a4 --- gcc/ChangeLog.gomp | 4 gcc/df-core.c | 2 -- 2 files changed, 4 insertions(+), 2 deletions(-) diff --git gcc/ChangeLog.gomp gcc/ChangeLog.gomp index baff20c..1f57a9d 100644 --- gcc/ChangeLog.gomp +++ gcc/ChangeLog.gomp @@ -1,3 +1,7 @@ +2015-07-11 Thomas Schwinge + + * df-core.c (df_analyze_1): Don't disable df_verify call. + 2015-07-10 Nathan Sidwell * config/nvptx/nvptx.c (nvptx_reorg): Move df problem setting, set diff --git gcc/df-core.c gcc/df-core.c index 52cca8e..67040a1 100644 --- gcc/df-core.c +++ gcc/df-core.c @@ -1235,12 +1235,10 @@ df_analyze_1 (void) if (dump_file) fprintf (dump_file, "df_analyze called\n"); -#if /* TODO */ 0 #ifndef ENABLE_DF_CHECKING if (df->changeable_flags & DF_VERIFY_SCHEDULED) #endif df_verify (); -#endif /* Skip over the DF_SCAN problem. */ for (i = 1; i < df->num_problems_defined; i++) Grüße, Thomas pgpfce56pJi55.pgp Description: PGP signature
Re: [PATCH][C++] PR 65071
Hi, I'm going to ping this on behalf of Andrea: the patch seems almost obvious to me and so small to not immediately require a copyright assignment (not sure whether Andrea already has it on file?!?). I also double checked that it still applies cleanly and passes testing. Thanks, Paolo. On 02/18/2015 09:20 AM, Andrea Azzarone wrote: Ops, forgot the diff. 2015-02-18 9:19 GMT+01:00 Andrea Azzarone : Hi all, this patch try to fix PR c++/65071 (ICE on valid, sizeof...() of template template parameter pack in return type). 2015-2-18 Andrea Azzarone PR c++/65071 * gcc/cp/parser.c (cp_parser_sizeof_pack) Also consider template template parameters. Thanks. -- Andrea Azzarone
Re: [PATCH][C++] Fix PR65091
Hi, I'm going to ping this one too: a tad less trivial than the other one - a little explanation here or in a comment would definitely help - but certainly it looks much simpler than my own tries a while ago... Regression testing information is also missing. Thanks, Paolo. On 02/21/2015 01:12 PM, Andrea Azzarone wrote: Hi all, please find attached a fix for pr 65071 "decltype(~arg) fails for template functions". Basically we need to make sure that ~arg is considered an expression and not a dtor. 2015-02-21 Andrea Azzarone PR c++/65091 * parser.c (cp_parser_decltype_expr): Make sure ~id is treated as an expression.
[gomp4] Resolve bootstrap failure in expand_GOACC_FORK, expand_GOACC_JOIN (was: Move openacc vector& worker single handling to RTL)
Hi!
On Thu, 09 Jul 2015 20:25:22 -0400, Nathan Sidwell wrote:
> This is the patch I committed.
> --- internal-fn.c (revision 225323)
> +++ internal-fn.c (working copy)
> +static void
> +expand_GOACC_FORK (gcall *stmt)
> +{
> + rtx mode = expand_normal (gimple_call_arg (stmt, 0));
> +
> +#ifdef HAVE_oacc_fork
> + emit_insn (gen_oacc_fork (mode));
> +#endif
> +}
> +
> +static void
> +expand_GOACC_JOIN (gcall *stmt)
> +{
> + rtx mode = expand_normal (gimple_call_arg (stmt, 0));
> +
> +#ifdef HAVE_oacc_join
> + emit_insn (gen_oacc_join (mode));
> +#endif
> +}
Committed in r225715:
commit f9d00ca614a8dc28f21ab4a16d7cdbbe16668ca3
Author: tschwinge
Date: Sat Jul 11 21:17:46 2015 +
Resolve bootstrap failure in expand_GOACC_FORK, expand_GOACC_JOIN
[...]/source-gcc/gcc/internal-fn.c: In function 'void
expand_GOACC_FORK(gcall*)':
[...]/source-gcc/gcc/internal-fn.c:1970:7: error: unused variable
'mode' [-Werror=unused-variable]
rtx mode = expand_normal (gimple_call_arg (stmt, 0));
^
[...]/source-gcc/gcc/internal-fn.c: In function 'void
expand_GOACC_JOIN(gcall*)':
[...]/source-gcc/gcc/internal-fn.c:1980:7: error: unused variable
'mode' [-Werror=unused-variable]
rtx mode = expand_normal (gimple_call_arg (stmt, 0));
^
gcc/
* internal-fn.c (expand_GOACC_FORK, expand_GOACC_JOIN)
[!HAVE_oacc_fork]: Keep quiet.
git-svn-id: svn+ssh://gcc.gnu.org/svn/gcc/branches/gomp-4_0-branch@225715
138bc75d-0d04-0410-961f-82ee72b054a4
---
gcc/ChangeLog.gomp |3 +++
gcc/internal-fn.c | 12 ++--
2 files changed, 9 insertions(+), 6 deletions(-)
diff --git gcc/ChangeLog.gomp gcc/ChangeLog.gomp
index 1f57a9d..ea3ea6b 100644
--- gcc/ChangeLog.gomp
+++ gcc/ChangeLog.gomp
@@ -1,5 +1,8 @@
2015-07-11 Thomas Schwinge
+ * internal-fn.c (expand_GOACC_FORK, expand_GOACC_JOIN)
+ [!HAVE_oacc_fork]: Keep quiet.
+
* df-core.c (df_analyze_1): Don't disable df_verify call.
2015-07-10 Nathan Sidwell
diff --git gcc/internal-fn.c gcc/internal-fn.c
index e1c4c9a..b507208 100644
--- gcc/internal-fn.c
+++ gcc/internal-fn.c
@@ -2005,21 +2005,21 @@ expand_GOACC_DATA_END_WITH_ARG (gcall *stmt
ATTRIBUTE_UNUSED)
}
static void
-expand_GOACC_FORK (gcall *stmt)
+expand_GOACC_FORK (gcall *stmt ATTRIBUTE_UNUSED)
{
- rtx mode = expand_normal (gimple_call_arg (stmt, 0));
-
#ifdef HAVE_oacc_fork
+ rtx mode = expand_normal (gimple_call_arg (stmt, 0));
+
emit_insn (gen_oacc_fork (mode));
#endif
}
static void
-expand_GOACC_JOIN (gcall *stmt)
+expand_GOACC_JOIN (gcall *stmt ATTRIBUTE_UNUSED)
{
- rtx mode = expand_normal (gimple_call_arg (stmt, 0));
-
#ifdef HAVE_oacc_join
+ rtx mode = expand_normal (gimple_call_arg (stmt, 0));
+
emit_insn (gen_oacc_join (mode));
#endif
}
Grüße,
Thomas
signature.asc
Description: PGP signature
Re: [PATCH] config/bfin/bfin.c (hwloop_optimize): Use return false instead of gcc_assert for checking jump_insn.
On 7/7/15 06:09, Chen Gang wrote:
> On 7/6/15 20:51, Bernd Schmidt wrote:
>> On 07/03/2015 04:13 AM, Chen Gang wrote:
>>>
>>> I shall continue to analyse why 2nd lsetup optimiation has not happened.
>>> Hope I can finish within next week (2015-07-12).
>>
>> I've committed my patch after testing bfin-elf. There's no great mystery why
>> the second optimization doesn't happen: the point where it thinks it has to
>> insert the LSETUP is after the loop, and the instruction doesn't allow that.
>> Possibly we could change that - when the loop is entered at the top but not
>> through a fallthrough edge, we could make a new block ahead of it and put
>> the LSETUP in there.
>>
After trying, for me, we need notice about the jump insn to loop start
label, and emit lsetup insn to loop head instead of incoming_src end,
the related diff is below:
diff --git a/gcc/config/bfin/bfin.c b/gcc/config/bfin/bfin.c
index a131053..9ef2a9c 100644
--- a/gcc/config/bfin/bfin.c
+++ b/gcc/config/bfin/bfin.c
@@ -3416,6 +3416,7 @@ bfin_hardware_loop (void)
#define MAX_LOOP_LENGTH 2042
/* Maximum distance of the LSETUP instruction from the loop start. */
+/* #define MAX_LSETUP_DISTANCE 30 */
#define MAX_LSETUP_DISTANCE 30
/* Estimate the length of INSN conservatively. */
@@ -3456,7 +3457,7 @@ hwloop_optimize (hwloop_info loop)
rtx seq_end;
rtx_insn *seq;
int length;
- bool clobber0, clobber1;
+ bool clobber0, clobber1, direct_jmp = false;
if (loop->depth > MAX_LOOP_DEPTH)
{
@@ -3519,7 +3520,13 @@ hwloop_optimize (hwloop_info loop)
|| !(loop->incoming->last ()->flags & EDGE_FALLTHRU))
{
gcc_assert (JUMP_P (insn));
- insn = PREV_INSN (insn);
+ if (JUMP_LABEL (insn) != loop->start_label)
+ insn = PREV_INSN (insn);
+ else
+ {
+ direct_jmp = true;
+ insn = loop->start_label;
+ }
}
for (; insn && insn != loop->start_label; insn = NEXT_INSN (insn))
@@ -3783,7 +3790,7 @@ hwloop_optimize (hwloop_info loop)
seq = get_insns ();
end_sequence ();
- if (loop->incoming_src)
+ if (loop->incoming_src && !direct_jmp)
{
rtx_insn *prev = BB_END (loop->incoming_src);
if (vec_safe_length (loop->incoming) > 1
Welcome any additional ideas, suggestions and completions (and I shall
send patch for it, if no additional relply within the next week).
Thanks.
>
> OK, thanks. for me, the fix is enough for this issue. And need we add
> the related .i file to testsuite, too?
>
> And thank you for your information, I shall try to let 2nd times lsetup
> have effect in another patch, hope I can succeed :-).
>
--
Chen Gang
Open, share, and attitude like air, water, and life which God blessed
[PATCH] Fix PR c++/65186 (bound template template parm as valid nontype parm)
In C++11 or later a bound template template parm should be considered a
valid nontype parm type because it could later be instantiated with an
alias template to have a non-aggregate type such as int.
OK to commit after bootstrap + regtest?
gcc/cp/ChangeLog:
PR c++/65186
* pt.c (invalid_nontype_parm_type_p): Accept a bound template
template parm type under C++11 and later.
gcc/testsuite/ChangeLog:
PR c++/65186
* g++.dg/template/pr65186.C: New test.
---
gcc/cp/pt.c | 5 +
gcc/testsuite/g++.dg/template/pr65186.C | 26 ++
2 files changed, 31 insertions(+)
create mode 100644 gcc/testsuite/g++.dg/template/pr65186.C
diff --git a/gcc/cp/pt.c b/gcc/cp/pt.c
index 064cbfd..2097963 100644
--- a/gcc/cp/pt.c
+++ b/gcc/cp/pt.c
@@ -20996,6 +20996,11 @@ invalid_nontype_parm_type_p (tree type, tsubst_flags_t
complain)
return 0;
else if (TREE_CODE (type) == NULLPTR_TYPE)
return 0;
+ /* A bound template template parm could later be instantiated to have a valid
+ nontype parm type via an alias template. */
+ else if (cxx_dialect >= cxx11
+ && TREE_CODE (type) == BOUND_TEMPLATE_TEMPLATE_PARM)
+return 0;
if (complain & tf_error)
{
diff --git a/gcc/testsuite/g++.dg/template/pr65186.C
b/gcc/testsuite/g++.dg/template/pr65186.C
new file mode 100644
index 000..f5e81e3
--- /dev/null
+++ b/gcc/testsuite/g++.dg/template/pr65186.C
@@ -0,0 +1,26 @@
+// { dg-do compile { target c++11 } }
+// PR c++/65186
+
+template
+using Id = int;
+
+template<
+ typename A,
+ A x,
+ A y,
+ Id p,
+ template> class C,
+ C // { dg-bogus "not a valid type" }
+> using J = C;
+
+
+template
+using Z = A;
+
+template<
+ template class A,
+ A B // { dg-bogus "not a valid type" }
+>
+struct C { };
+
+C a;
--
2.5.0.rc1.40.ge088f2b.dirty
