Re: [PATCH v7] PR middle-end/60281
On Tue, Mar 04, 2014 at 11:11:45AM +0800, lin zuojian wrote:
> Without aligning the asan stack base,this base will only 64-bit aligned in
> ARM machines.
> But asan require 256-bit aligned base because of this:
> 1.right shift take ASAN_SHADOW_SHIFT(which is 3) bits are zeros
> 2.store multiple/load multiple instructions require the other 2 bits are zeros
>
> that add up lowest 5 bits should be zeros.That means 32 bytes or 256 bits
> aligned.
>
> * asan.c (asan_emit_stack_protection): Force the base to align to
> appropriate bits if STRICT_ALIGNMENT. Set shadow_mem align to
> appropriate bits if STRICT_ALIGNMENT.
> * cfgexpand.c (expand_stack_vars): Set base_align appropriately
> when asan is on.
> (expand_used_vars): Leave a space in the stack frame for alignment if
> STRICT_ALIGNMENT.
There were still a couple of formatting issues, I've fixed them below.
Now, do you have a GCC copyright assignment or are under copyright
assignment of some company working on GCC (ARM?)?
2014-03-03 Lin Zuojian
PR middle-end/60281
* asan.c (asan_emit_stack_protection): Force the base to align to
appropriate bits if STRICT_ALIGNMENT. Set shadow_mem align to
appropriate bits if STRICT_ALIGNMENT.
* cfgexpand.c (expand_stack_vars): Set base_align appropriately
when asan is on.
(expand_used_vars): Leave a space in the stack frame for alignment
if STRICT_ALIGNMENT.
--- gcc/asan.c.jj 2014-01-09 19:09:45.981593894 +0100
+++ gcc/asan.c 2014-03-04 08:55:22.239816211 +0100
@@ -1017,8 +1017,17 @@ asan_emit_stack_protection (rtx base, rt
base_align_bias = ((asan_frame_size + alignb - 1)
& ~(alignb - HOST_WIDE_INT_1)) - asan_frame_size;
}
+ /* Align base if target is STRICT_ALIGNMENT. */
+ if (STRICT_ALIGNMENT)
+base = expand_binop (Pmode, and_optab, base,
+gen_int_mode (-((GET_MODE_ALIGNMENT (SImode)
+ << ASAN_SHADOW_SHIFT)
+/ BITS_PER_UNIT), Pmode), NULL_RTX,
+1, OPTAB_DIRECT);
+
if (use_after_return_class == -1 && pbase)
emit_move_insn (pbase, base);
+
base = expand_binop (Pmode, add_optab, base,
gen_int_mode (base_offset - base_align_bias, Pmode),
NULL_RTX, 1, OPTAB_DIRECT);
@@ -1097,6 +1106,8 @@ asan_emit_stack_protection (rtx base, rt
&& (ASAN_RED_ZONE_SIZE >> ASAN_SHADOW_SHIFT) == 4);
shadow_mem = gen_rtx_MEM (SImode, shadow_base);
set_mem_alias_set (shadow_mem, asan_shadow_set);
+ if (STRICT_ALIGNMENT)
+set_mem_align (shadow_mem, (GET_MODE_ALIGNMENT (SImode)));
prev_offset = base_offset;
for (l = length; l; l -= 2)
{
@@ -1186,6 +1197,10 @@ asan_emit_stack_protection (rtx base, rt
shadow_mem = gen_rtx_MEM (BLKmode, shadow_base);
set_mem_alias_set (shadow_mem, asan_shadow_set);
+
+ if (STRICT_ALIGNMENT)
+set_mem_align (shadow_mem, (GET_MODE_ALIGNMENT (SImode)));
+
prev_offset = base_offset;
last_offset = base_offset;
last_size = 0;
--- gcc/cfgexpand.c.jj 2014-03-03 08:25:17.164537912 +0100
+++ gcc/cfgexpand.c 2014-03-04 08:57:53.860949703 +0100
@@ -1013,10 +1013,19 @@ expand_stack_vars (bool (*pred) (size_t)
if (data->asan_base == NULL)
data->asan_base = gen_reg_rtx (Pmode);
base = data->asan_base;
+
+ if (!STRICT_ALIGNMENT)
+ base_align = crtl->max_used_stack_slot_alignment;
+ else
+ base_align = MAX (crtl->max_used_stack_slot_alignment,
+ GET_MODE_ALIGNMENT (SImode)
+ << ASAN_SHADOW_SHIFT);
}
else
- offset = alloc_stack_frame_space (stack_vars[i].size, alignb);
- base_align = crtl->max_used_stack_slot_alignment;
+ {
+ offset = alloc_stack_frame_space (stack_vars[i].size, alignb);
+ base_align = crtl->max_used_stack_slot_alignment;
+ }
}
else
{
@@ -1843,6 +1852,11 @@ expand_used_vars (void)
= alloc_stack_frame_space (redzonesz, ASAN_RED_ZONE_SIZE);
data.asan_vec.safe_push (prev_offset);
data.asan_vec.safe_push (offset);
+ /* Leave space for alignment if STRICT_ALIGNMENT. */
+ if (STRICT_ALIGNMENT)
+ alloc_stack_frame_space ((GET_MODE_ALIGNMENT (SImode)
+ << ASAN_SHADOW_SHIFT)
+/ BITS_PER_UNIT, 1);
var_end_seq
= asan_emit_stack_protection (virtual_stack_vars_rtx,
Jakub
[PATCH] Fix up var-tracking regression (PR middle-end/60381)
Hi!
This patch attempts to fix a regression caused by the
http://gcc.gnu.org/r208220 change.
In particular, because cselib_reset_table called immediately after
cselib_preserve_only_values removes VALUEs with zero locs and thus clears
n_useless_values, if we don't remove_useless_values right away (as was done
before the patch), we might not call discard_useless_locs at all).
The problem with that is var-tracking relies on preserved values not
referencing non-preserved values without any locs.
The patch ensures we discard_useless_locs at least sometimes during
vt_initialize (if the cumulative number of dropped and useless VALUEs goes
over certain amount) and ensures we do it at least once at the end of
vt_initialize.
Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?
2014-03-04 Jakub Jelinek
PR middle-end/60381
* cselib.h (cselib_remove_useless_values): New prototype.
* var-tracking.c (vt_initialize): Call it at the end.
* cselib.c (n_dropped_useless_values): New counter.
(cselib_reset_table): Accumulate n_useless_values
into n_dropped_useless_values.
(remove_useless_values): Revert 2014-02-28 change.
Clear n_dropped_useless_values.
(cselib_preserve_only_values): Don't call remove_useless_values,
just do traversal with discard_useless_locs conditionally
on n_dropped_useless_values + n_useless_values being big enough.
(cselib_remove_useless_values): New function.
(cselib_process_insn): Revert 2014-02-28 change.
(cselib_finish): Clear n_dropped_useless_values.
--- gcc/cselib.h.jj 2014-01-03 11:40:57.0 +0100
+++ gcc/cselib.h2014-03-03 19:23:48.65911 +0100
@@ -95,6 +95,7 @@ extern unsigned int cselib_get_next_uid
extern void cselib_preserve_value (cselib_val *);
extern bool cselib_preserved_value_p (cselib_val *);
extern void cselib_preserve_only_values (void);
+extern void cselib_remove_useless_values (vec);
extern void cselib_preserve_cfa_base_value (cselib_val *, unsigned int);
extern void cselib_add_permanent_equiv (cselib_val *, rtx, rtx);
extern bool cselib_have_permanent_equivalences (void);
--- gcc/var-tracking.c.jj 2014-03-03 18:28:18.0 +0100
+++ gcc/var-tracking.c 2014-03-03 19:27:07.518208397 +0100
@@ -10149,6 +10149,8 @@ vt_initialize (void)
}
}
+ if (MAY_HAVE_DEBUG_INSNS)
+cselib_remove_useless_values (preserved_values);
hard_frame_pointer_adjustment = -1;
VTI (ENTRY_BLOCK_PTR_FOR_FN (cfun))->flooded = true;
cfa_base_rtx = NULL_RTX;
--- gcc/cselib.c.jj 2014-03-03 18:28:18.0 +0100
+++ gcc/cselib.c2014-03-03 19:28:19.832782951 +0100
@@ -200,6 +200,7 @@ static unsigned int cselib_nregs;
values. */
static int n_useless_values;
static int n_useless_debug_values;
+static int n_dropped_useless_values;
/* Count values whose locs have been taken exclusively from debug
insns for the entire life of the value. */
@@ -546,7 +547,11 @@ cselib_reset_table (unsigned int num)
}
if (cselib_preserve_constants)
-cselib_hash_table.traverse (NULL);
+{
+ n_dropped_useless_values += n_useless_values;
+ cselib_hash_table.traverse (NULL);
+}
else
{
cselib_hash_table.empty ();
@@ -681,14 +686,6 @@ remove_useless_values (void)
{
cselib_val **p, *v;
- if (n_useless_values <= MAX_USELESS_VALUES
- /* remove_useless_values is linear in the hash table size. Avoid
- quadratic behavior for very large hashtables with very few
-useless elements. */
- || ((unsigned int)n_useless_values
- <= (cselib_hash_table.elements () - n_debug_values) / 4))
-return;
-
/* First pass: eliminate locations that reference the value. That in
turn can make more values useless. */
do
@@ -712,6 +709,7 @@ remove_useless_values (void)
n_useless_values += n_useless_debug_values;
n_debug_values -= n_useless_debug_values;
n_useless_debug_values = 0;
+ n_dropped_useless_values = 0;
cselib_hash_table.traverse (NULL);
@@ -763,11 +761,43 @@ cselib_preserve_only_values (void)
cselib_invalidate_mem (callmem);
- remove_useless_values ();
+ if ((n_dropped_useless_values + n_useless_values) > MAX_USELESS_VALUES
+ /* Traversal with discard_useless_locs is linear in the hash table
+size. Avoid quadratic behavior for very large hashtables with
+very few useless elements. */
+ && ((unsigned int) (n_dropped_useless_values + n_useless_values)
+ > (cselib_hash_table.elements () - n_debug_values) / 4))
+{
+ /* Eliminate locations that reference the value. That in
+turn can make more values useless. */
+ do
+ {
+ values_became_useless = 0;
+ cselib_hash_table.traverse (NULL);
+ }
+ while (values_became_useless);
+ n_dropped_useless_values = 0;
+}
gcc_assert (first_containing_mem == &dummy_val);
}
[PATCH] Fix PR60382
This fixes PR60382 where the vectorizer identified a double-reduction
it cannot later re-identify properly. The only reasonable fix at this
point is to not identify that as a double-reduction.
Bootstrapped and tested on x86_64-unknown-linux-gnu, applied to trunk,
will apply to branch after testing there.
Richard.
2014-03-04 Richard Biener
PR tree-optimization/60382
* tree-vect-loop.c (vect_is_simple_reduction_1): Do not consider
dead PHIs a reduction.
* gcc.dg/vect/pr60382.c: New testcase.
Index: gcc/tree-vect-loop.c
===
--- gcc/tree-vect-loop.c(revision 208269)
+++ gcc/tree-vect-loop.c(working copy)
@@ -2193,6 +2193,12 @@ vect_is_simple_reduction_1 (loop_vec_inf
|| (!check_reduction && flow_loop_nested_p (vect_loop, loop)));
name = PHI_RESULT (phi);
+ /* ??? If there are no uses of the PHI result the inner loop reduction
+ won't be detected as possibly double-reduction by vectorizable_reduction
+ because that tries to walk the PHI arg from the preheader edge which
+ can be constant. See PR60382. */
+ if (has_zero_uses (name))
+return NULL;
nloop_uses = 0;
FOR_EACH_IMM_USE_FAST (use_p, imm_iter, name)
{
Index: gcc/testsuite/gcc.dg/vect/pr60382.c
===
--- gcc/testsuite/gcc.dg/vect/pr60382.c (revision 0)
+++ gcc/testsuite/gcc.dg/vect/pr60382.c (working copy)
@@ -0,0 +1,32 @@
+#include "tree-vect.h"
+
+int a, b, c, e, f;
+
+void
+foo ()
+{
+ for (b = 0; b < 3; b++)
+if (e)
+ {
+ for (c = 0; c < 4; c++)
+ {
+ if (b)
+ continue;
+ f = 1;
+ for (a = 0; a < 2; a++)
+ f |= 1;
+ }
+ for (;;)
+ ;
+ }
+}
+
+int
+main ()
+{
+ check_vect ();
+ foo ();
+ return 0;
+}
+
+/* { dg-final { cleanup-tree-dump "vect" } } */
Re: [PATCH v7] PR middle-end/60281
On Tue, Mar 04, 2014 at 09:04:56AM +0100, Jakub Jelinek wrote: > On Tue, Mar 04, 2014 at 11:11:45AM +0800, lin zuojian wrote: > > Without aligning the asan stack base,this base will only 64-bit aligned in > > ARM machines. > > But asan require 256-bit aligned base because of this: > > 1.right shift take ASAN_SHADOW_SHIFT(which is 3) bits are zeros > > 2.store multiple/load multiple instructions require the other 2 bits are > > zeros > > > > that add up lowest 5 bits should be zeros.That means 32 bytes or 256 bits > > aligned. > > > > * asan.c (asan_emit_stack_protection): Force the base to align to > > appropriate bits if STRICT_ALIGNMENT. Set shadow_mem align to > > appropriate bits if STRICT_ALIGNMENT. > > * cfgexpand.c (expand_stack_vars): Set base_align appropriately > > when asan is on. > > (expand_used_vars): Leave a space in the stack frame for alignment if > > STRICT_ALIGNMENT. > > There were still a couple of formatting issues, I've fixed them below. > Now, do you have a GCC copyright assignment or are under copyright > assignment of some company working on GCC (ARM?)? Thanks for the fixing!. I have none of them.I have read the website,but don't know what exactly I am expecting to do.
Re: [PATCH, i386] Fix emitting of prefetch instructions
Hello Uroš,
On 04 Mar 01:13, Uros Bizjak wrote:
> On Tue, Mar 4, 2014 at 12:31 AM, Uros Bizjak wrote:
> > They are all:
> >
> > FAIL: gcc.target/i386/avx512pf-vscatterpf0dpd-1.c (test for excess errors)
> > Excess errors:
> > /ssd/uros/gcc-build/gcc/include/avx512pfintrin.h:108:3: error: the
> > last argument must be hint 0 or 1
> >
> > They are due to _MM_HINT_ET0 fix, and probably show that the pattern
> > was not updated when hint constants were adjusted to 2 and 3.
> >
> > Kirill, can you please look at this inconsistency?
>
> Attached patch fixes these failures, and also fixes and improves error
> message.
>
> Uros.
> Index: i386.c
> ===
> --- i386.c(revision 208296)
> +++ i386.c(working copy)
> @@ -36022,7 +36022,7 @@ addcarryx:
>
>if (!insn_data[icode].operand[4].predicate (op4, mode4))
> {
> - error ("the last argument must be hint 0 or 1");
> + error ("incorrect hint operand");
> return const0_rtx;
> }
>
> Index: predicates.md
> ===
> --- predicates.md (revision 208295)
> +++ predicates.md (working copy)
> @@ -660,12 +660,12 @@
>return i == 2 || i == 4 || i == 8;
> })
>
> -;; Match 2, 3, 5, or 6
> -(define_predicate "const2356_operand"
> +;; Match 2, 3, 6, or 7
> +(define_predicate "const2367_operand"
>(match_code "const_int")
> {
>HOST_WIDE_INT i = INTVAL (op);
> - return i == 2 || i == 3 || i == 5 || i == 6;
> + return i == 2 || i == 3 || i == 6 || i == 7;
> })
This will break `immediate' compatibility w/ ICC, since
ICC using ET0=5.
But as far as IMHO using immediates instead of literals
is ugly, I think this is minor issue.
--
Thanks, K
Re: [PATCH v7] PR middle-end/60281
On Tue, Mar 04, 2014 at 04:44:57PM +0800, lin zuojian wrote: > On Tue, Mar 04, 2014 at 09:04:56AM +0100, Jakub Jelinek wrote: > > On Tue, Mar 04, 2014 at 11:11:45AM +0800, lin zuojian wrote: > > > Without aligning the asan stack base,this base will only 64-bit aligned > > > in ARM machines. > > > But asan require 256-bit aligned base because of this: > > > 1.right shift take ASAN_SHADOW_SHIFT(which is 3) bits are zeros > > > 2.store multiple/load multiple instructions require the other 2 bits are > > > zeros > > > > > > that add up lowest 5 bits should be zeros.That means 32 bytes or 256 bits > > > aligned. > > > > > > * asan.c (asan_emit_stack_protection): Force the base to align to > > > appropriate bits if STRICT_ALIGNMENT. Set shadow_mem align to > > > appropriate bits if STRICT_ALIGNMENT. > > > * cfgexpand.c (expand_stack_vars): Set base_align appropriately > > > when asan is on. > > > (expand_used_vars): Leave a space in the stack frame for alignment if > > > STRICT_ALIGNMENT. > > > > There were still a couple of formatting issues, I've fixed them below. > > Now, do you have a GCC copyright assignment or are under copyright > > assignment of some company working on GCC (ARM?)? > Thanks for the fixing!. > I have none of them.I have read the website,but don't know what exactly > I am expecting to do. Please follow http://git.savannah.gnu.org/cgit/gnulib.git/plain/doc/Copyright/request-assign.future Jakub
Re: [PATCH v7] PR middle-end/60281
Thanks Jakub -- Regards lin zuojian On Tue, Mar 04, 2014 at 10:15:31AM +0100, Jakub Jelinek wrote: > On Tue, Mar 04, 2014 at 04:44:57PM +0800, lin zuojian wrote: > > On Tue, Mar 04, 2014 at 09:04:56AM +0100, Jakub Jelinek wrote: > > > On Tue, Mar 04, 2014 at 11:11:45AM +0800, lin zuojian wrote: > > > > Without aligning the asan stack base,this base will only 64-bit aligned > > > > in ARM machines. > > > > But asan require 256-bit aligned base because of this: > > > > 1.right shift take ASAN_SHADOW_SHIFT(which is 3) bits are zeros > > > > 2.store multiple/load multiple instructions require the other 2 bits > > > > are zeros > > > > > > > > that add up lowest 5 bits should be zeros.That means 32 bytes or 256 > > > > bits aligned. > > > > > > > > * asan.c (asan_emit_stack_protection): Force the base to align to > > > > appropriate bits if STRICT_ALIGNMENT. Set shadow_mem align to > > > > appropriate bits if STRICT_ALIGNMENT. > > > > * cfgexpand.c (expand_stack_vars): Set base_align appropriately > > > > when asan is on. > > > > (expand_used_vars): Leave a space in the stack frame for alignment > > > > if > > > > STRICT_ALIGNMENT. > > > > > > There were still a couple of formatting issues, I've fixed them below. > > > Now, do you have a GCC copyright assignment or are under copyright > > > assignment of some company working on GCC (ARM?)? > > Thanks for the fixing!. > > I have none of them.I have read the website,but don't know what exactly > > I am expecting to do. > > Please follow > http://git.savannah.gnu.org/cgit/gnulib.git/plain/doc/Copyright/request-assign.future > > Jakub
Re: [RFC] Do not consider volatile asms as optimization barriers #1
On Mon, Mar 3, 2014 at 11:01 PM, Richard Sandiford
wrote:
> AIUI:
>
> (1) The main point of http://gcc.gnu.org/ml/gcc-patches/2012-10/msg01172.html
> was that we had:
>
> emit_move_insn (virtual_stack_vars_rtx, hard_frame_pointer_rtx);
> /* This might change the hard frame pointer in ways that aren't
> apparent to early optimization passes, so force a clobber. */
> emit_clobber (hard_frame_pointer_rtx);
>
> and, after elimination, the clobber killed the assignment to the
> hard frame pointer. Which it could. :-)
>
> (2) Aassuming for simplicity that STARTING_FRAME_OFFSET == 0, we end up
> with an assignment like:
>
> (set frame_pointer_rtx hard_frame_pointer_rtx)
>
> And the problem is that frame_pointer_rtx often isn't a real register:
> it gets eliminated to hard_frame_pointer_rtx+X, where X isn't known
> until RA time. I.e. the assignment is really:
>
> (set (plus hard_frame_pointer_rtx X) hard_frame_pointer_rtx)
>
> which becomes:
>
> (set hard_frame_pointer_rtx (plus hard_frame_pointer_rtx -X))
>
> Before RA it isn't obvious that the assignment clobbers
> hard_frame_pointer_rtx, so it would seem to most passes that
> frame_pointer_rtx and hard_frame_pointer_rtx are equivalent
> after the set. That was why the clobber was there.
>
> (3) We chose to fix this by deleting the explicit clobber and relying on
> the magicness of unspec_volatile to imply the clobber instead.
>
> But I don't think (3) is a good idea. We should instead fix the dataflow
> so that it's accurate.
>
> Long term it would be good to have a different representation for (2),
An UNSPEC that sets frame_pointer_rtx, uses and clobbers hard_frame_pointer_rtx.
In fact the plain move_insn is a lie and the clobber should have been
at least in a parallel with the set of frame_pointer_rtx ...
?
> but I don't have any bright ideas what that might be. Until then I think
> we can model the dataflow accurately by having a use as well as a clobber
> of hard_frame_pointer_rtx. I went back to r192682:
Indeed.
> http://gcc.gnu.org/ml/gcc-testresults/2012-10/msg02350.html
>
> and saw the -m32 tests fail without the builtins.c part of the patch.
> They passed after it. I then went to r200643:
>
> 2013-07-03 Hans-Peter Nilsson
>
> PR middle-end/55030
> * stmt.c (expand_nl_goto_receiver): Remove almost-copy of
> expand_builtin_setjmp_receiver.
> (expand_label): Adjust, call expand_builtin_setjmp_receiver
> with NULL for the label parameter.
> * builtins.c (expand_builtin_setjmp_receiver): Don't clobber
> the frame-pointer. Adjust comments.
> [HAVE_builtin_setjmp_receiver]: Emit builtin_setjmp_receiver
> only if LABEL is non-NULL.
>
> and applied the full patch. The tests still passed, despite the removal
> of the volatile checks. (To recap, the volatile checks touched here
> were the same ones touched by:
>
> http://gcc.gnu.org/ml/gcc-patches/2012-11/msg00868.html
>
> Rather than reverting that part I'm removing the check entirely,
> since we seem to agree that the original asm handling wasn't necessary.)
>
> I'll run a full test overnight, but does this look like it might be
> a way out, at least for 4.9?
Shouldn't the use and clobber be part of the "move" and thus wrapped
inside a parallel? Or am I misunderstanding how parallel works?
What keeps those three insns adjacent otherwise?
Thansk,
Richard.
> Thanks,
> Richard
>
>
> gcc/
> * builtins.c (expand_builtin_setjmp_receiver): Use and clobber
> hard_frame_pointer_rtx.
> * cse.c (cse_insn): Remove volatile check.
> * cselib.c (cselib_process_insn): Likewise.
> * dse.c (scan_insn): Likewise.
>
> Index: gcc/builtins.c
> ===
> --- gcc/builtins.c 2014-03-03 21:47:59.749026019 +
> +++ gcc/builtins.c 2014-03-03 21:48:00.550030853 +
> @@ -910,18 +910,27 @@ expand_builtin_setjmp_receiver (rtx rece
> #ifdef HAVE_nonlocal_goto
>if (! HAVE_nonlocal_goto)
> #endif
> -/* First adjust our frame pointer to its actual value. It was
> - previously set to the start of the virtual area corresponding to
> - the stacked variables when we branched here and now needs to be
> - adjusted to the actual hardware fp value.
> -
> - Assignments to virtual registers are converted by
> - instantiate_virtual_regs into the corresponding assignment
> - to the underlying register (fp in this case) that makes
> - the original assignment true.
> - So the following insn will actually be decrementing fp by
> - STARTING_FRAME_OFFSET. */
> -emit_move_insn (virtual_stack_vars_rtx, hard_frame_pointer_rtx);
> +{
> + /* First adjust our frame pointer to its actual value. It was
> +previously set to the start of the virtual area corresponding to
> +
Re: [RFC] Do not consider volatile asms as optimization barriers #1
Richard Biener writes: > On Mon, Mar 3, 2014 at 11:01 PM, Richard Sandiford > wrote: >> AIUI: >> >> (1) The main point of http://gcc.gnu.org/ml/gcc-patches/2012-10/msg01172.html >> was that we had: >> >> emit_move_insn (virtual_stack_vars_rtx, hard_frame_pointer_rtx); >> /* This might change the hard frame pointer in ways that aren't >> apparent to early optimization passes, so force a clobber. */ >> emit_clobber (hard_frame_pointer_rtx); >> >> and, after elimination, the clobber killed the assignment to the >> hard frame pointer. Which it could. :-) >> >> (2) Aassuming for simplicity that STARTING_FRAME_OFFSET == 0, we end up >> with an assignment like: >> >> (set frame_pointer_rtx hard_frame_pointer_rtx) >> >> And the problem is that frame_pointer_rtx often isn't a real register: >> it gets eliminated to hard_frame_pointer_rtx+X, where X isn't known >> until RA time. I.e. the assignment is really: >> >> (set (plus hard_frame_pointer_rtx X) hard_frame_pointer_rtx) >> >> which becomes: >> >> (set hard_frame_pointer_rtx (plus hard_frame_pointer_rtx -X)) >> >> Before RA it isn't obvious that the assignment clobbers >> hard_frame_pointer_rtx, so it would seem to most passes that >> frame_pointer_rtx and hard_frame_pointer_rtx are equivalent >> after the set. That was why the clobber was there. >> >> (3) We chose to fix this by deleting the explicit clobber and relying on >> the magicness of unspec_volatile to imply the clobber instead. >> >> But I don't think (3) is a good idea. We should instead fix the dataflow >> so that it's accurate. >> >> Long term it would be good to have a different representation for (2), > > An UNSPEC that sets frame_pointer_rtx, uses and clobbers > hard_frame_pointer_rtx. > > In fact the plain move_insn is a lie and the clobber should have been > at least in a parallel with the set of frame_pointer_rtx ... > > ? Yeah, the plain move is lie, which is why ideally I'd like to change it. But the problem is that the elimination code specifically expects this kind of pattern to be used. It eliminates the target of the move to reg+offset and treats the new insn as being an assignment to reg with offset subtracted from the source. It needs to be something simple like a plain move or a: (set (reg) (plus (reg) (const_int))) for subtracting offset to work correctly. So changing the representation of the move would mean changing the way that those eliminations are handled too. Not 4.9 material :-) >> but I don't have any bright ideas what that might be. Until then I think >> we can model the dataflow accurately by having a use as well as a clobber >> of hard_frame_pointer_rtx. I went back to r192682: > > Indeed. > >> http://gcc.gnu.org/ml/gcc-testresults/2012-10/msg02350.html >> >> and saw the -m32 tests fail without the builtins.c part of the patch. >> They passed after it. I then went to r200643: >> >> 2013-07-03 Hans-Peter Nilsson >> >> PR middle-end/55030 >> * stmt.c (expand_nl_goto_receiver): Remove almost-copy of >> expand_builtin_setjmp_receiver. >> (expand_label): Adjust, call expand_builtin_setjmp_receiver >> with NULL for the label parameter. >> * builtins.c (expand_builtin_setjmp_receiver): Don't clobber >> the frame-pointer. Adjust comments. >> [HAVE_builtin_setjmp_receiver]: Emit builtin_setjmp_receiver >> only if LABEL is non-NULL. >> >> and applied the full patch. The tests still passed, despite the removal >> of the volatile checks. (To recap, the volatile checks touched here >> were the same ones touched by: >> >> http://gcc.gnu.org/ml/gcc-patches/2012-11/msg00868.html >> >> Rather than reverting that part I'm removing the check entirely, >> since we seem to agree that the original asm handling wasn't necessary.) >> >> I'll run a full test overnight, but does this look like it might be >> a way out, at least for 4.9? > > Shouldn't the use and clobber be part of the "move" and thus wrapped > inside a parallel? Or am I misunderstanding how parallel works? > What keeps those three insns adjacent otherwise? Strict adjacency doesn't really matter. We just need to kill the equivalence between the soft and hard frame pointers for anything after the clobber. I did wonder about using an empty asm that takes the old hard frame pointer as input and produces a new hard frame pointer as output, but normal asms aren't allowed to change the frame pointer. Thanks, Richard
[PATCH][RFC] Merge LTO -O options from compile-time
This merges -O options given at compile-time into a single
optimization level to be used for LTO link time (but
overridden with whatever is specified at LTO link time - unless
no optimization level is specified there). That is, it
determines a "default" optimization level used at LTO link time
(as opposed to the default optimization level zero).
Currently the code merges exact same options as-is and
mismatching optimization levels based on the maximum value of
'optimize' they cause and merging it as -Ooptimize.
Thus -Og and -Os get merged as -O2, -O and -Ofast get merged as -O3
and -O and -O1 get merged as -O1.
Specifying any optimization level explicitely at link time
will override what we came up with above (including explicitely
specifying -O0).
Comments?
I've tested that it works as expected. Do we want something like
this for 4.9?
Thanks,
Richard.
2014-03-04 Richard Biener
* lto-wrapper.c (merge_and_complain): Merge compile-time
optimization levels.
(run_gcc): And pass it through to the link options.
Index: gcc/lto-wrapper.c
===
*** gcc/lto-wrapper.c (revision 208305)
--- gcc/lto-wrapper.c (working copy)
*** merge_and_complain (struct cl_decoded_op
*** 459,464
--- 459,535
fatal ("Option %s not used consistently in all LTO input files",
foption->orig_option_with_args_text);
break;
+
+ case OPT_O:
+ case OPT_Ofast:
+ case OPT_Og:
+ case OPT_Os:
+ for (j = 0; j < *decoded_options_count; ++j)
+ if ((*decoded_options)[j].opt_index == OPT_O
+ || (*decoded_options)[j].opt_index == OPT_Ofast
+ || (*decoded_options)[j].opt_index == OPT_Og
+ || (*decoded_options)[j].opt_index == OPT_Os)
+ break;
+ if (j == *decoded_options_count)
+ append_option (decoded_options, decoded_options_count, foption);
+ else if ((*decoded_options)[j].opt_index == foption->opt_index
+ && foption->opt_index != OPT_O)
+ /* Exact same options get merged. */
+ ;
+ else
+ {
+ /* For mismatched option kinds preserve the optimization
+level only, thus merge it as -On. This also handles
+merging of same optimization level -On. */
+ int level = 0;
+ switch (foption->opt_index)
+ {
+ case OPT_O:
+ if (foption->arg[0] == '\0')
+ level = MAX (level, 1);
+ else
+ level = MAX (level, atoi (foption->arg));
+ break;
+ case OPT_Ofast:
+ level = MAX (level, 3);
+ break;
+ case OPT_Og:
+ level = MAX (level, 1);
+ break;
+ case OPT_Os:
+ level = MAX (level, 2);
+ break;
+ default:
+ gcc_unreachable ();
+ }
+ switch ((*decoded_options)[j].opt_index)
+ {
+ case OPT_O:
+ if ((*decoded_options)[j].arg[0] == '\0')
+ level = MAX (level, 1);
+ else
+ level = MAX (level, atoi ((*decoded_options)[j].arg));
+ break;
+ case OPT_Ofast:
+ level = MAX (level, 3);
+ break;
+ case OPT_Og:
+ level = MAX (level, 1);
+ break;
+ case OPT_Os:
+ level = MAX (level, 2);
+ break;
+ default:
+ gcc_unreachable ();
+ }
+ (*decoded_options)[j].opt_index = OPT_O;
+ char *tem;
+ asprintf (&tem, "-O%d", level);
+ (*decoded_options)[j].arg = &tem[2];
+ (*decoded_options)[j].canonical_option[0] = tem;
+ (*decoded_options)[j].value = 1;
+ }
+ break;
}
}
}
*** run_gcc (unsigned argc, char *argv[])
*** 610,615
--- 681,690
case OPT_fwrapv:
case OPT_ftrapv:
case OPT_fstrict_overflow:
+ case OPT_O:
+ case OPT_Ofast:
+ case OPT_Og:
+ case OPT_Os:
break;
default:
Re: [PATCH] [lto/55113] Fix use of -fshort-double with -flto for powerpc
On 03/03/14 09:56, Richard Biener wrote:
Index: gcc/c-family/c.opt
===
--- gcc/c-family/c.opt (revision 208249)
+++ gcc/c-family/c.opt (working copy)
@@ -1141,7 +1141,7 @@ C++ ObjC++ Optimization Var(flag_rtti) I
Generate run time type descriptor information
fshort-double
-C ObjC C++ ObjC++ Optimization Var(flag_short_double)
+C ObjC C++ ObjC++ LTO Optimization Var(flag_short_double)
Use the same size for double as for float
This hunk isn't needed.
Index: gcc/testsuite/gcc.target/powerpc/pr55113.c
===
--- gcc/testsuite/gcc.target/powerpc/pr55113.c (revision 0)
+++ gcc/testsuite/gcc.target/powerpc/pr55113.c (working copy)
@@ -0,0 +1,11 @@
+#include
+
+int main()
+{
+ static float f;
+ float a = 1.0;
+ float b = 2.0;
+ f = a + b * 1e-12;
+ printf("%f\n", f);
+ return 0;
+}
that doesn't seem to be run with -flto nor -fshort-double. The proper
place for a testcase is gcc.dg/lto/ with sth like
{ dg-lto-do link }
{ dg-lto-options { { -O2 -fshort-double -flto } } }
and naming the testcase pr55113_0.c. Your testcase doens't use
doubles at all ... (well, ok, a + b * 1e-12 uses them implicitely, but
for that we have fsingle-precision-constant)
Richard.
--
PMatos
Thanks for all your comments. I have updated the patch to reflect your
comments and concerns.
2014-03-04 Paulo Matos
* tree-streamer.c (record_common_node): Assert we don't record
nodes with type double.
(preload_common_node): Skip type double, complex double and
double pointer since it is now frontend dependent due to
fshort-double option.
2014-03-04 Paulo Matos
* gcc.dg/lto/pr55113_0.c: New testcase.
There is an issue opened by this bug. i386 fails the test but not due to
lto. It fails due to short-double:
$ top-trunk/toolchain/install-native/bin/gcc -O2 -o test pr55113_0.c
-fshort-double
: internal compiler error: in layout_type, at stor-layout.c:2116
0xb36233 layout_type(tree_node*)
../../../src/gcc/gcc/stor-layout.c:2115
0xdf8998 make_vector_type
../../../src/gcc/gcc/tree.c:9431
0xdfbb87 build_vector_type_for_mode(tree_node*, machine_mode)
../../../src/gcc/gcc/tree.c:10205
0xe8dd57 ix86_get_builtin_type
../../../src/gcc/gcc/config/i386/i386.c:27021
0xe8de95 ix86_get_builtin_func_type
../../../src/gcc/gcc/config/i386/i386.c:27071
0xe8dfa1 def_builtin
../../../src/gcc/gcc/config/i386/i386.c:28787
0xe8e662 ix86_init_mmx_sse_builtins
../../../src/gcc/gcc/config/i386/i386.c:30724
0xe92e8f ix86_init_builtins
../../../src/gcc/gcc/config/i386/i386.c:32677
0x62c692 c_define_builtins
../../../src/gcc/gcc/c-family/c-common.c:5268
0x62e09c c_common_nodes_and_builtins()
../../../src/gcc/gcc/c-family/c-common.c:5712
0x57b859 c_init_decl_processing()
../../../src/gcc/gcc/c/c-decl.c:3550
0x5d260f c_objc_common_init()
../../../src/gcc/gcc/c/c-objc-common.c:63
0xb4333c lang_dependent_init
../../../src/gcc/gcc/toplev.c:1712
0xb4374a do_compile
../../../src/gcc/gcc/toplev.c:1900
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See for instructions.
I think we can close PR55113 and open a new bug for i386 and
fshort-double usage if there isn't one open already?
OK to commit and close bug?
--
PMatos
Index: gcc/tree-streamer.c
===
--- gcc/tree-streamer.c (revision 208249)
+++ gcc/tree-streamer.c (working copy)
@@ -264,7 +264,8 @@ record_common_node (struct streamer_tree
gcc_checking_assert (node != boolean_type_node
&& node != boolean_true_node
- && node != boolean_false_node);
+ && node != boolean_false_node
+ && node != double_type_node);
/* We have to make sure to fill exactly the same number of
elements for all frontends. That can include NULL trees.
@@ -315,10 +316,14 @@ preload_common_nodes (struct streamer_tr
record_common_node (cache, sizetype_tab[i]);
for (i = 0; i < TI_MAX; i++)
-/* Skip boolean type and constants, they are frontend dependent. */
+/* Skip boolean type and constants. They are frontend dependent.
+ Skip double type, frontend dependent due to -fshort-double. */
if (i != TI_BOOLEAN_TYPE
&& i != TI_BOOLEAN_FALSE
- && i != TI_BOOLEAN_TRUE)
+ && i != TI_BOOLEAN_TRUE
+ && i != TI_DOUBLE_TYPE
+ && i != TI_COMPLEX_DOUBLE_TYPE
+ && i != TI_DOUBLE_PTR_TYPE)
record_common_node (cache, global_trees[i]);
}
Index: gcc/testsuite/gcc.dg/lto/pr55113_0.c
===
--- gcc/testsuite/gcc.dg/lto/pr55113_0.c (revision 0)
+++ gcc/testsuite/gcc.dg/lto/pr55113_0.c (working copy)
@@ -0,
Re: [PATCH] [lto/55113] Fix use of -fshort-double with -flto for powerpc
On Tue, Mar 4, 2014 at 12:02 PM, Paulo J. Matos wrote:
> On 03/03/14 09:56, Richard Biener wrote:
>>
>> Index: gcc/c-family/c.opt
>> ===
>> --- gcc/c-family/c.opt (revision 208249)
>> +++ gcc/c-family/c.opt (working copy)
>> @@ -1141,7 +1141,7 @@ C++ ObjC++ Optimization Var(flag_rtti) I
>> Generate run time type descriptor information
>>
>> fshort-double
>> -C ObjC C++ ObjC++ Optimization Var(flag_short_double)
>> +C ObjC C++ ObjC++ LTO Optimization Var(flag_short_double)
>> Use the same size for double as for float
>>
>> This hunk isn't needed.
>>
>> Index: gcc/testsuite/gcc.target/powerpc/pr55113.c
>> ===
>> --- gcc/testsuite/gcc.target/powerpc/pr55113.c (revision 0)
>> +++ gcc/testsuite/gcc.target/powerpc/pr55113.c (working copy)
>> @@ -0,0 +1,11 @@
>> +#include
>> +
>> +int main()
>> +{
>> + static float f;
>> + float a = 1.0;
>> + float b = 2.0;
>> + f = a + b * 1e-12;
>> + printf("%f\n", f);
>> + return 0;
>> +}
>>
>> that doesn't seem to be run with -flto nor -fshort-double. The proper
>> place for a testcase is gcc.dg/lto/ with sth like
>>
>> { dg-lto-do link }
>> { dg-lto-options { { -O2 -fshort-double -flto } } }
>>
>> and naming the testcase pr55113_0.c. Your testcase doens't use
>> doubles at all ... (well, ok, a + b * 1e-12 uses them implicitely, but
>> for that we have fsingle-precision-constant)
>>
>> Richard.
>>
>>> --
>>> PMatos
>>
>>
>
> Thanks for all your comments. I have updated the patch to reflect your
> comments and concerns.
>
> 2014-03-04 Paulo Matos
>
>
> * tree-streamer.c (record_common_node): Assert we don't record
> nodes with type double.
> (preload_common_node): Skip type double, complex double and
> double pointer since it is now frontend dependent due to
> fshort-double option.
>
> 2014-03-04 Paulo Matos
>
> * gcc.dg/lto/pr55113_0.c: New testcase.
>
> There is an issue opened by this bug. i386 fails the test but not due to
> lto. It fails due to short-double:
> $ top-trunk/toolchain/install-native/bin/gcc -O2 -o test pr55113_0.c
> -fshort-double
> : internal compiler error: in layout_type, at stor-layout.c:2116
> 0xb36233 layout_type(tree_node*)
> ../../../src/gcc/gcc/stor-layout.c:2115
> 0xdf8998 make_vector_type
> ../../../src/gcc/gcc/tree.c:9431
> 0xdfbb87 build_vector_type_for_mode(tree_node*, machine_mode)
> ../../../src/gcc/gcc/tree.c:10205
> 0xe8dd57 ix86_get_builtin_type
> ../../../src/gcc/gcc/config/i386/i386.c:27021
> 0xe8de95 ix86_get_builtin_func_type
> ../../../src/gcc/gcc/config/i386/i386.c:27071
> 0xe8dfa1 def_builtin
> ../../../src/gcc/gcc/config/i386/i386.c:28787
> 0xe8e662 ix86_init_mmx_sse_builtins
> ../../../src/gcc/gcc/config/i386/i386.c:30724
> 0xe92e8f ix86_init_builtins
> ../../../src/gcc/gcc/config/i386/i386.c:32677
> 0x62c692 c_define_builtins
> ../../../src/gcc/gcc/c-family/c-common.c:5268
> 0x62e09c c_common_nodes_and_builtins()
> ../../../src/gcc/gcc/c-family/c-common.c:5712
> 0x57b859 c_init_decl_processing()
> ../../../src/gcc/gcc/c/c-decl.c:3550
> 0x5d260f c_objc_common_init()
> ../../../src/gcc/gcc/c/c-objc-common.c:63
> 0xb4333c lang_dependent_init
> ../../../src/gcc/gcc/toplev.c:1712
> 0xb4374a do_compile
> ../../../src/gcc/gcc/toplev.c:1900
> Please submit a full bug report,
> with preprocessed source if appropriate.
> Please include the complete backtrace with any bug report.
> See for instructions.
>
>
> I think we can close PR55113 and open a new bug for i386 and fshort-double
> usage if there isn't one open already?
>
> OK to commit and close bug?
It works fine on i386 for me but fails on x86_64. Please add a
/* { dg-skip-if "PR-you-open" { { x86_64-*-* i?86-*-* } && lp64 } {
"*" } { "" } } */
to the testcase to avoid the regression in the testsuite.
-fshort-double doesn't seem to work at all on 64bit x86.
Ok with that change.
Thanks,
Richard.
> --
> PMatos
Re: [PATCH] [lto/55113] Fix use of -fshort-double with -flto for powerpc
On 04/03/14 11:16, Richard Biener wrote:
It works fine on i386 for me but fails on x86_64. Please add a
/* { dg-skip-if "PR-you-open" { { x86_64-*-* i?86-*-* } && lp64 } {
"*" } { "" } } */
to the testcase to avoid the regression in the testsuite.
Apologies, you're right. I meant x86_64 fails here as well.
Will commit with suggested skip line.
--
PMatos
Re: [PATCH] [lto/55113] Fix use of -fshort-double with -flto for powerpc
"Paulo J. Matos" writes:
> On 04/03/14 11:16, Richard Biener wrote:
>> It works fine on i386 for me but fails on x86_64. Please add a
>>
>> /* { dg-skip-if "PR-you-open" { { x86_64-*-* i?86-*-* } && lp64 } {
>> "*" } { "" } } */
>>
>> to the testcase to avoid the regression in the testsuite.
>>
>
> Apologies, you're right. I meant x86_64 fails here as well.
> Will commit with suggested skip line.
Please omit the { "*" } { "" } part. That's the default and superfluous.
Thanks.
Rainer
--
-
Rainer Orth, Center for Biotechnology, Bielefeld University
[PATCH] Properly do the LTO bytecode version check
We're doing the LTO bytecode version check only for two section
types at the moment - specifically _not_ for the first section
we read. Which causes us to crash instead of reporting a
version mismatch ...
Fixed by doing the version check in the most appropriate place.
LTO bootstrapped on x86_64-unknown-linux-gnu, applied.
Richard.
2014-03-04 Richard Biener
PR lto/60405
* lto-streamer-in.c (lto_read_body): Remove LTO bytecode version
check.
(lto_input_toplevel_asms): Likewise.
* lto-section-in.c (lto_get_section_data): Instead do it here
for every section.
Index: gcc/lto-streamer-in.c
===
*** gcc/lto-streamer-in.c (revision 208305)
--- gcc/lto-streamer-in.c (working copy)
*** lto_read_body (struct lto_file_decl_data
*** 1059,1068
data_in = lto_data_in_create (file_data, data + string_offset,
header->string_size, vNULL);
- /* Make sure the file was generated by the exact same compiler. */
- lto_check_version (header->lto_header.major_version,
-header->lto_header.minor_version);
-
if (section_type == LTO_section_function_body)
{
struct lto_in_decl_state *decl_state;
--- 1059,1064
*** lto_input_toplevel_asms (struct lto_file
*** 1331,1340
data_in = lto_data_in_create (file_data, data + string_offset,
header->string_size, vNULL);
- /* Make sure the file was generated by the exact same compiler. */
- lto_check_version (header->lto_header.major_version,
-header->lto_header.minor_version);
-
while ((str = streamer_read_string_cst (data_in, &ib)))
{
struct asm_node *node = add_asm_node (str);
--- 1327,1332
Index: gcc/lto-section-in.c
===
*** gcc/lto-section-in.c(revision 208305)
--- gcc/lto-section-in.c(working copy)
*** lto_get_section_data (struct lto_file_de
*** 153,178
/* FIXME lto: WPA mode does not write compressed sections, so for now
suppress uncompression if flag_ltrans. */
! if (flag_ltrans)
! return data;
!
! /* Create a mapping header containing the underlying data and length,
! and prepend this to the uncompression buffer. The uncompressed data
! then follows, and a pointer to the start of the uncompressed data is
! returned. */
! header = (struct lto_data_header *) xmalloc (header_length);
! header->data = data;
! header->len = *len;
!
! buffer.data = (char *) header;
! buffer.length = header_length;
!
! stream = lto_start_uncompression (lto_append_data, &buffer);
! lto_uncompress_block (stream, data, *len);
! lto_end_uncompression (stream);
!
! *len = buffer.length - header_length;
! return buffer.data + header_length;
}
--- 153,182
/* FIXME lto: WPA mode does not write compressed sections, so for now
suppress uncompression if flag_ltrans. */
! if (!flag_ltrans)
! {
! /* Create a mapping header containing the underlying data and length,
!and prepend this to the uncompression buffer. The uncompressed data
!then follows, and a pointer to the start of the uncompressed data is
!returned. */
! header = (struct lto_data_header *) xmalloc (header_length);
! header->data = data;
! header->len = *len;
!
! buffer.data = (char *) header;
! buffer.length = header_length;
!
! stream = lto_start_uncompression (lto_append_data, &buffer);
! lto_uncompress_block (stream, data, *len);
! lto_end_uncompression (stream);
!
! *len = buffer.length - header_length;
! data = buffer.data + header_length;
! }
!
! lto_check_version (((lto_header *)data)->major_version,
!((lto_header *)data)->minor_version);
! return data;
}
Re: [RFC] Do not consider volatile asms as optimization barriers #1
On 03/03/2014 11:01 PM, Richard Sandiford wrote: I'll run a full test overnight, but does this look like it might be a way out, at least for 4.9? Pretty much agree with everything you've written in this thread. I think this patch is fine. gcc/ * builtins.c (expand_builtin_setjmp_receiver): Use and clobber hard_frame_pointer_rtx. * cse.c (cse_insn): Remove volatile check. * cselib.c (cselib_process_insn): Likewise. * dse.c (scan_insn): Likewise. Bernd
[PATCH] Use the LTO linker plugin by default
The following patch addresses the common (?) issue of people
omitting -flto from the linker command-line which gets more
severe with GCC 4.9 where slim LTO objects are emitted by
default. The patch simply _always_ arranges for the linker
plugin to be used, so if there are any (slim) LTO objects
on the link LTO will be done on them. Similarly the
non-linker-plugin path in collect2 is adjusted.
You can still disable this by specifying -fno-lto on the
linker command-line.
One side-effect of enabling the linker-plugin by default
(for HAVE_LTO_PLUGIN == 2) is that collect2 will then
use the configured plugin ld rather than the default ld.
Not sure if that is desired.
Comments?
Thanks,
Richard.
2014-03-04 Richard Biener
* gcc.c (PLUGIN_COND): Always enable unless -fno-use-linker-plugin
or -fno-lto is specified and the linker has full plugin support.
* collect2.c (lto_mode): Default to LTO_MODE_WHOPR if LTO is
enabled.
(main): Remove -flto processing, adjust lto_mode using
use_plugin late.
Index: gcc/gcc.c
===
--- gcc/gcc.c (revision 208310)
+++ gcc/gcc.c (working copy)
@@ -695,7 +695,7 @@ proper position among the other output f
#if HAVE_LTO_PLUGIN > 0
/* The linker used has full plugin support, use LTO plugin by default. */
#if HAVE_LTO_PLUGIN == 2
-#define PLUGIN_COND "!fno-use-linker-plugin:%{flto|flto=*|fuse-linker-plugin"
+#define PLUGIN_COND "!fno-use-linker-plugin:%{!fno-lto"
#define PLUGIN_COND_CLOSE "}"
#else
/* The linker used has limited plugin support, use LTO plugin with explicit
Index: gcc/collect2.c
===
--- gcc/collect2.c (revision 208310)
+++ gcc/collect2.c (working copy)
@@ -192,7 +192,11 @@ enum lto_mode_d {
};
/* Current LTO mode. */
+#ifdef ENABLE_LTO
+static enum lto_mode_d lto_mode = LTO_MODE_WHOPR;
+#else
static enum lto_mode_d lto_mode = LTO_MODE_NONE;
+#endif
bool debug;/* true if -debug */
bool helpflag; /* true if --help */
@@ -1018,15 +1022,11 @@ main (int argc, char **argv)
debug = true;
else if (! strcmp (argv[i], "-flto-partition=none"))
no_partition = true;
-else if ((! strncmp (argv[i], "-flto=", 6)
- || ! strcmp (argv[i], "-flto")) && ! use_plugin)
- lto_mode = LTO_MODE_WHOPR;
else if (!strncmp (argv[i], "-fno-lto", 8))
lto_mode = LTO_MODE_NONE;
else if (! strcmp (argv[i], "-plugin"))
{
use_plugin = true;
- lto_mode = LTO_MODE_NONE;
if (selected_linker == USE_DEFAULT_LD)
selected_linker = USE_PLUGIN_LD;
}
@@ -1056,6 +1056,8 @@ main (int argc, char **argv)
}
vflag = debug;
find_file_set_debug (debug);
+if (use_plugin)
+ lto_mode = LTO_MODE_NONE;
if (no_partition && lto_mode == LTO_MODE_WHOPR)
lto_mode = LTO_MODE_LTO;
}
Re: [PATCH] Use the LTO linker plugin by default
On 2014.03.04 at 13:00 +0100, Richard Biener wrote: > > The following patch addresses the common (?) issue of people > omitting -flto from the linker command-line which gets more > severe with GCC 4.9 where slim LTO objects are emitted by > default. The patch simply _always_ arranges for the linker > plugin to be used, so if there are any (slim) LTO objects > on the link LTO will be done on them. Similarly the > non-linker-plugin path in collect2 is adjusted. > > You can still disable this by specifying -fno-lto on the > linker command-line. > > One side-effect of enabling the linker-plugin by default > (for HAVE_LTO_PLUGIN == 2) is that collect2 will then > use the configured plugin ld rather than the default ld. > Not sure if that is desired. > > Comments? I've been using a similar patch (without the collect2.c hunks) locally for the past few month without any problems. What is missing is a big fat warning in http://gcc.gnu.org/gcc-4.9/changes.html that one should use the gcc binutils wrappers (gcc-ar, etc.) when building projects with LTO. -- Markus
Re: [PATCH] Properly do the LTO bytecode version check
On Tue, 2014-03-04 12:22:12 +0100, Richard Biener wrote: > > We're doing the LTO bytecode version check only for two section > types at the moment - specifically _not_ for the first section > we read. Which causes us to crash instead of reporting a > version mismatch ... > > Fixed by doing the version check in the most appropriate place. > > LTO bootstrapped on x86_64-unknown-linux-gnu, applied. > > Richard. > > 2014-03-04 Richard Biener > > PR lto/60405 > * lto-streamer-in.c (lto_read_body): Remove LTO bytecode version > check. > (lto_input_toplevel_asms): Likewise. > * lto-section-in.c (lto_get_section_data): Instead do it here > for every section. Breaks for the Build Robot with g++ (GCC) 4.9.0 20131121 like this: g++ -c -g -O2 -DIN_GCC -DCROSS_DIRECTORY_STRUCTURE -fno-exceptions -fno-rtti -fasynchronous-unwind-tables -W -Wall -Wno-narrowing -Wwrite-strings -Wcast-qual -Wmissing-format-attribute -pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -Werror -fno-common -DHAVE_CONFIG_H -I. -I. -I../../../gcc/gcc -I../../../gcc/gcc/. -I../../../gcc/gcc/../include -I../../../gcc/gcc/../libcpp/include -I/opt/cfarm/mpc/include -I../../../gcc/gcc/../libdecnumber -I../../../gcc/gcc/../libdecnumber/dpd -I../libdecnumber -I../../../gcc/gcc/../libbacktrace-o lto-section-in.o -MT lto-section-in.o -MMD -MP -MF ./.deps/lto-section-in.TPo ../../../gcc/gcc/lto-section-in.c ../../../gcc/gcc/lto-section-in.c: In function ‘const char* lto_get_section_data(lto_file_decl_data*, lto_section_type, const char*, size_t*)’: ../../../gcc/gcc/lto-section-in.c:177:37: error: cast from type ‘const char*’ to type ‘lto_header*’ casts away qualifiers [-Werror=cast-qual] lto_check_version (((lto_header *)data)->major_version, ^ ../../../gcc/gcc/lto-section-in.c:178:23: error: cast from type ‘const char*’ to type ‘lto_header*’ casts away qualifiers [-Werror=cast-qual] ((lto_header *)data)->minor_version); ^ cc1plus: all warnings being treated as errors make[2]: *** [lto-section-in.o] Error 1 See eg. http://toolchain.lug-owl.de/buildbot/show_build_details.php?id=156703 --> http://toolchain.lug-owl.de/buildbot/deliver_artifact.php?mode=view&id=1152984 MfG, JBG -- Jan-Benedict Glaw jbg...@lug-owl.de +49-172-7608481 Signature of: http://www.eyrie.org/~eagle/faqs/questions.html the second : signature.asc Description: Digital signature
RFC LeakSanitizer tests
Hi all! We would like to test LeakSanitizer during our working process, but there is no any testcase to do it in gcc at this moment . Do you think it would make sense to add support for LeakSanitizer testing? If the answer is positive, we can work on dg infrastructure (lsan-dg.exp, lsan.exp) and initial set of tests (export some tests from llvm upstream). -Maxim
Re: [PATCH] Properly do the LTO bytecode version check
On Tue, 4 Mar 2014, Jan-Benedict Glaw wrote: > On Tue, 2014-03-04 12:22:12 +0100, Richard Biener wrote: > > > > We're doing the LTO bytecode version check only for two section > > types at the moment - specifically _not_ for the first section > > we read. Which causes us to crash instead of reporting a > > version mismatch ... > > > > Fixed by doing the version check in the most appropriate place. > > > > LTO bootstrapped on x86_64-unknown-linux-gnu, applied. > > > > Richard. > > > > 2014-03-04 Richard Biener > > > > PR lto/60405 > > * lto-streamer-in.c (lto_read_body): Remove LTO bytecode version > > check. > > (lto_input_toplevel_asms): Likewise. > > * lto-section-in.c (lto_get_section_data): Instead do it here > > for every section. > > Breaks for the Build Robot with g++ (GCC) 4.9.0 20131121 like this: > > g++ -c -g -O2 -DIN_GCC -DCROSS_DIRECTORY_STRUCTURE -fno-exceptions > -fno-rtti -fasynchronous-unwind-tables -W -Wall -Wno-narrowing > -Wwrite-strings -Wcast-qual -Wmissing-format-attribute -pedantic > -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -Werror > -fno-common -DHAVE_CONFIG_H -I. -I. -I../../../gcc/gcc -I../../../gcc/gcc/. > -I../../../gcc/gcc/../include -I../../../gcc/gcc/../libcpp/include > -I/opt/cfarm/mpc/include -I../../../gcc/gcc/../libdecnumber > -I../../../gcc/gcc/../libdecnumber/dpd -I../libdecnumber > -I../../../gcc/gcc/../libbacktrace-o lto-section-in.o -MT > lto-section-in.o -MMD -MP -MF ./.deps/lto-section-in.TPo > ../../../gcc/gcc/lto-section-in.c > ../../../gcc/gcc/lto-section-in.c: In function ‘const char* > lto_get_section_data(lto_file_decl_data*, lto_section_type, const char*, > size_t*)’: > ../../../gcc/gcc/lto-section-in.c:177:37: error: cast from type ‘const char*’ > to type ‘lto_header*’ casts away qualifiers [-Werror=cast-qual] >lto_check_version (((lto_header *)data)->major_version, > ^ > ../../../gcc/gcc/lto-section-in.c:178:23: error: cast from type ‘const char*’ > to type ‘lto_header*’ casts away qualifiers [-Werror=cast-qual] > ((lto_header *)data)->minor_version); >^ > cc1plus: all warnings being treated as errors > make[2]: *** [lto-section-in.o] Error 1 > > > See eg. > http://toolchain.lug-owl.de/buildbot/show_build_details.php?id=156703 > --> > http://toolchain.lug-owl.de/buildbot/deliver_artifact.php?mode=view&id=1152984 > > MfG, JBG Bah - I committed the wrong version ... Richard.
Re: [PATCH] Properly do the LTO bytecode version check
On Tue, 4 Mar 2014, Richard Biener wrote: > On Tue, 4 Mar 2014, Jan-Benedict Glaw wrote: > > > On Tue, 2014-03-04 12:22:12 +0100, Richard Biener wrote: > > > > > > We're doing the LTO bytecode version check only for two section > > > types at the moment - specifically _not_ for the first section > > > we read. Which causes us to crash instead of reporting a > > > version mismatch ... > > > > > > Fixed by doing the version check in the most appropriate place. > > > > > > LTO bootstrapped on x86_64-unknown-linux-gnu, applied. > > > > > > Richard. > > > > > > 2014-03-04 Richard Biener > > > > > > PR lto/60405 > > > * lto-streamer-in.c (lto_read_body): Remove LTO bytecode version > > > check. > > > (lto_input_toplevel_asms): Likewise. > > > * lto-section-in.c (lto_get_section_data): Instead do it here > > > for every section. > > > > Breaks for the Build Robot with g++ (GCC) 4.9.0 20131121 like this: > > > > g++ -c -g -O2 -DIN_GCC -DCROSS_DIRECTORY_STRUCTURE -fno-exceptions > > -fno-rtti -fasynchronous-unwind-tables -W -Wall -Wno-narrowing > > -Wwrite-strings -Wcast-qual -Wmissing-format-attribute -pedantic > > -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -Werror > > -fno-common -DHAVE_CONFIG_H -I. -I. -I../../../gcc/gcc > > -I../../../gcc/gcc/. -I../../../gcc/gcc/../include > > -I../../../gcc/gcc/../libcpp/include -I/opt/cfarm/mpc/include > > -I../../../gcc/gcc/../libdecnumber -I../../../gcc/gcc/../libdecnumber/dpd > > -I../libdecnumber -I../../../gcc/gcc/../libbacktrace-o lto-section-in.o > > -MT lto-section-in.o -MMD -MP -MF ./.deps/lto-section-in.TPo > > ../../../gcc/gcc/lto-section-in.c > > ../../../gcc/gcc/lto-section-in.c: In function ‘const char* > > lto_get_section_data(lto_file_decl_data*, lto_section_type, const char*, > > size_t*)’: > > ../../../gcc/gcc/lto-section-in.c:177:37: error: cast from type ‘const > > char*’ to type ‘lto_header*’ casts away qualifiers [-Werror=cast-qual] > >lto_check_version (((lto_header *)data)->major_version, > > ^ > > ../../../gcc/gcc/lto-section-in.c:178:23: error: cast from type ‘const > > char*’ to type ‘lto_header*’ casts away qualifiers [-Werror=cast-qual] > > ((lto_header *)data)->minor_version); > >^ > > cc1plus: all warnings being treated as errors > > make[2]: *** [lto-section-in.o] Error 1 > > > > > > See eg. > > http://toolchain.lug-owl.de/buildbot/show_build_details.php?id=156703 > > --> > > http://toolchain.lug-owl.de/buildbot/deliver_artifact.php?mode=view&id=1152984 > > > > MfG, JBG > > Bah - I committed the wrong version ... Fixed like so (what was actually tested). Richard. 2014-03-04 Richard Biener * lto-section-in.c (lto_get_section_data): Fix const cast. Index: gcc/lto-section-in.c === --- gcc/lto-section-in.c(revision 208314) +++ gcc/lto-section-in.c(working copy) @@ -174,8 +174,8 @@ lto_get_section_data (struct lto_file_de data = buffer.data + header_length; } - lto_check_version (((lto_header *)data)->major_version, -((lto_header *)data)->minor_version); + lto_check_version (((const lto_header *)data)->major_version, +((const lto_header *)data)->minor_version); return data; }
[patch] Update my email address in MAINTAINERS
Committed. commit b4039fa151c772e0994407d4dc69b0ac9cff567a Author: Jonathan Wakely Date: Tue Mar 4 12:53:35 2014 + * MAINTAINERS: Update my email address. diff --git a/MAINTAINERS b/MAINTAINERS index 70c10d4..834052e 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -198,7 +198,7 @@ dwarf debugging codeCary Coutant ccout...@google.com c++ runtime libs Paolo Carlini paolo.carl...@oracle.com c++ runtime libs Ulrich Drepper drep...@gmail.com c++ runtime libs Benjamin De Kosnik b...@gnu.org -c++ runtime libs Jonathan Wakely r...@gcc.gnu.org +c++ runtime libs Jonathan Wakely jwak...@redhat.com *synthetic multiplyTorbjorn Granlund t...@swox.com *c-torture Torbjorn Granlund t...@swox.com fixincludesBruce Korb bk...@gnu.org
Re: [PATCH] Properly do the LTO bytecode version check
On Tue, 4 Mar 2014, Richard Biener wrote: We're doing the LTO bytecode version check only for two section types at the moment - specifically _not_ for the first section we read. Which causes us to crash instead of reporting a version mismatch ... Not for 4.9, but when the object is fat, could we downgrade this version mismatch error to a warning and use the non-LTO code? (Or does that need to be done in ld?) The current workaround is to strip the objects involved I think. -- Marc Glisse
Re: [PATCH] Properly do the LTO bytecode version check
On Tue, 4 Mar 2014, Marc Glisse wrote: > On Tue, 4 Mar 2014, Richard Biener wrote: > > > We're doing the LTO bytecode version check only for two section > > types at the moment - specifically _not_ for the first section > > we read. Which causes us to crash instead of reporting a > > version mismatch ... > > Not for 4.9, but when the object is fat, could we downgrade this version > mismatch error to a warning and use the non-LTO code? (Or does that need to be > done in ld?) The current workaround is to strip the objects involved I think. Yes, that needs to be done in the linker plugin - it simply should not claim the object (or issue it to a proper GCC version ...). For this reason the check is still in the wrong place ... but how we identify LTO objects in the linker-plugin is simply gross. Richard.
Re: [PATCH, i386] Fix emitting of prefetch instructions
On Tue, Mar 4, 2014 at 10:04 AM, Kirill Yukhin wrote:
> Hello Uroš,
> On 04 Mar 01:13, Uros Bizjak wrote:
>> On Tue, Mar 4, 2014 at 12:31 AM, Uros Bizjak wrote:
>> > They are all:
>> >
>> > FAIL: gcc.target/i386/avx512pf-vscatterpf0dpd-1.c (test for excess errors)
>> > Excess errors:
>> > /ssd/uros/gcc-build/gcc/include/avx512pfintrin.h:108:3: error: the
>> > last argument must be hint 0 or 1
>> >
>> > They are due to _MM_HINT_ET0 fix, and probably show that the pattern
>> > was not updated when hint constants were adjusted to 2 and 3.
>> >
>> > Kirill, can you please look at this inconsistency?
>>
>> Attached patch fixes these failures, and also fixes and improves error
>> message.
>>
>> Uros.
>
>> Index: i386.c
>> ===
>> --- i386.c(revision 208296)
>> +++ i386.c(working copy)
>> @@ -36022,7 +36022,7 @@ addcarryx:
>>
>>if (!insn_data[icode].operand[4].predicate (op4, mode4))
>> {
>> - error ("the last argument must be hint 0 or 1");
>> + error ("incorrect hint operand");
>> return const0_rtx;
>> }
>>
>> Index: predicates.md
>> ===
>> --- predicates.md (revision 208295)
>> +++ predicates.md (working copy)
>> @@ -660,12 +660,12 @@
>>return i == 2 || i == 4 || i == 8;
>> })
>>
>> -;; Match 2, 3, 5, or 6
>> -(define_predicate "const2356_operand"
>> +;; Match 2, 3, 6, or 7
>> +(define_predicate "const2367_operand"
>>(match_code "const_int")
>> {
>>HOST_WIDE_INT i = INTVAL (op);
>> - return i == 2 || i == 3 || i == 5 || i == 6;
>> + return i == 2 || i == 3 || i == 6 || i == 7;
>> })
> This will break `immediate' compatibility w/ ICC, since
> ICC using ET0=5.
> But as far as IMHO using immediates instead of literals
> is ugly, I think this is minor issue.
I don't think this is an issue at all, as said earlier - builtins are
considered internal implementation detail, published interface is in
relevant *.h files (this is also why wrong error message was fixed).
Uros.
Re: [PATCH] Change HONOR_REG_ALLOC_ORDER to a marco for C expression
Ping.
On Thu, Feb 27, 2014 at 12:32 PM, Kito Cheng wrote:
> Hi all:
>
> Sorry for repeat patch content in last mail, here is the clean version
> for this patch.
>
> diff --git a/gcc/config/arm/arm.h b/gcc/config/arm/arm.h
> index 7ca47a7..1638332 100644
> --- a/gcc/config/arm/arm.h
> +++ b/gcc/config/arm/arm.h
> @@ -1152,7 +1152,7 @@ extern int arm_regs_in_sequence[];
>
> /* Tell IRA to use the order we define rather than messing it up with its
> own cost calculations. */
> -#define HONOR_REG_ALLOC_ORDER
> +#define HONOR_REG_ALLOC_ORDER 1
>
> /* Interrupt functions can only use registers that have already been
> saved by the prologue, even if they would normally be
> diff --git a/gcc/config/nds32/nds32.h b/gcc/config/nds32/nds32.h
> index 38847e5..8f966ec 100644
> --- a/gcc/config/nds32/nds32.h
> +++ b/gcc/config/nds32/nds32.h
> @@ -553,7 +553,7 @@ enum nds32_builtins
>
> /* Tell IRA to use the order we define rather than messing it up with its
> own cost calculations. */
> -#define HONOR_REG_ALLOC_ORDER
> +#define HONOR_REG_ALLOC_ORDER 1
>
> /* The number of consecutive hard regs needed starting at
> reg "regno" for holding a value of mode "mode". */
> diff --git a/gcc/defaults.h b/gcc/defaults.h
> index f94ae17..1c48759 100644
> --- a/gcc/defaults.h
> +++ b/gcc/defaults.h
> @@ -1085,6 +1085,10 @@ see the files COPYING3 and COPYING.RUNTIME
> respectively. If not, see
> #define LOCAL_REGNO(REGNO) 0
> #endif
>
> +#ifndef HONOR_REG_ALLOC_ORDER
> +#define HONOR_REG_ALLOC_ORDER 0
> +#endif
> +
> /* EXIT_IGNORE_STACK should be nonzero if, when returning from a function,
> the stack pointer does not matter. The value is tested only in
> functions that have frame pointers. */
> diff --git a/gcc/doc/tm.texi b/gcc/doc/tm.texi
> index f204936..c0de478 100644
> --- a/gcc/doc/tm.texi
> +++ b/gcc/doc/tm.texi
> @@ -2044,8 +2044,8 @@ Normally, IRA tries to estimate the costs for
> saving a register in the
> prologue and restoring it in the epilogue. This discourages it from
> using call-saved registers. If a machine wants to ensure that IRA
> allocates registers in the order given by REG_ALLOC_ORDER even if some
> -call-saved registers appear earlier than call-used ones, this macro
> -should be defined.
> +call-saved registers appear earlier than call-used ones, then define this
> + macro as a C expression to nonzero. Default is 0.
> @end defmac
>
> @defmac IRA_HARD_REGNO_ADD_COST_MULTIPLIER (@var{regno})
> diff --git a/gcc/doc/tm.texi.in b/gcc/doc/tm.texi.in
> index 50f412c..d7ae6a7 100644
> --- a/gcc/doc/tm.texi.in
> +++ b/gcc/doc/tm.texi.in
> @@ -1849,8 +1849,8 @@ Normally, IRA tries to estimate the costs for
> saving a register in the
> prologue and restoring it in the epilogue. This discourages it from
> using call-saved registers. If a machine wants to ensure that IRA
> allocates registers in the order given by REG_ALLOC_ORDER even if some
> -call-saved registers appear earlier than call-used ones, this macro
> -should be defined.
> +call-saved registers appear earlier than call-used ones, then define this
> + macro as a C expression to nonzero. Default is 0.
> @end defmac
>
> @defmac IRA_HARD_REGNO_ADD_COST_MULTIPLIER (@var{regno})
> diff --git a/gcc/ira-color.c b/gcc/ira-color.c
> index c20aaf7..773c86e 100644
> --- a/gcc/ira-color.c
> +++ b/gcc/ira-color.c
> @@ -1599,7 +1599,6 @@ check_hard_reg_p (ira_allocno_t a, int hard_regno,
> }
>return j == nregs;
> }
> -#ifndef HONOR_REG_ALLOC_ORDER
>
> /* Return number of registers needed to be saved and restored at
> function prologue/epilogue if we allocate HARD_REGNO to hold value
> @@ -1618,7 +1617,6 @@ calculate_saved_nregs (int hard_regno, enum
> machine_mode mode)
>nregs++;
>return nregs;
> }
> -#endif
>
> /* Choose a hard register for allocno A. If RETRY_P is TRUE, it means
> that the function called from function
> @@ -1653,11 +1651,9 @@ assign_hard_reg (ira_allocno_t a, bool retry_p)
>enum reg_class aclass;
>enum machine_mode mode;
>static int costs[FIRST_PSEUDO_REGISTER], full_costs[FIRST_PSEUDO_REGISTER];
> -#ifndef HONOR_REG_ALLOC_ORDER
>int saved_nregs;
>enum reg_class rclass;
>int add_cost;
> -#endif
> #ifdef STACK_REGS
>bool no_stack_reg_p;
> #endif
> @@ -1823,19 +1819,21 @@ assign_hard_reg (ira_allocno_t a, bool retry_p)
> continue;
>cost = costs[i];
>full_cost = full_costs[i];
> -#ifndef HONOR_REG_ALLOC_ORDER
> - if ((saved_nregs = calculate_saved_nregs (hard_regno, mode)) != 0)
> - /* We need to save/restore the hard register in
> - epilogue/prologue. Therefore we increase the cost. */
> - {
> - rclass = REGNO_REG_CLASS (hard_regno);
> - add_cost = ((ira_memory_move_cost[mode][rclass][0]
> - + ira_memory_move_cost[mode][rclass][1])
> - * saved_nregs / hard_regno_nregs[hard_regno][mode] - 1);
> - cost += add_cost;
> - full_cost += add_cost;
> - }
> -#endif
> +
> + if (!HONOR_REG_ALLOC_ORDER)
[C++ Patch/RFC] PR 60389
Hi,
this regression is just an ICE on invalid, but I'm finding it somewhat
tricky. Let's see if I can explain clearly enough what I figured out so far.
The problem manifests itself when is_valid_constexpr_fn is called by
explain_invalid_constexpr_fn with a TEMPLATE_DECL (the inherited
template constructor) as the fun argument and FUNCTION_FIRST_USER_PARM
cannot be used on it. This happens because explain_invalid_constexpr_fn
(called from the second half of explain_non_literal_class) doesn't early
return via:
/* Only diagnose defaulted functions or instantiations. */
if (!DECL_DEFAULTED_FN (fun)
&& !is_instantiation_of_constexpr (fun))
return;
because we internally represent inherited *template* constructors too as
defaulted. Thus, the idea of handling those specially per the first
draft I'm attaching. In fact, note that if we try to fix up
is_valid_constexpr_fn (like in the second draft I'm attaching below), we
get a final error message of the form
60389.C:13:12: note: ‘template B::B(T ...)’ is not usable
as a constexpr function because:
using A::A;
^
60389.C:13:12: error: invalid type for parameter 1 of constexpr function
‘template B::B(T ...)’
which I find quite confusing, because that parameter is a
TYPE_PACK_EXPANSION (for which the literal_type_p check in
is_valid_constexpr_fn returns false) but in fact a B::B() is needed...
Note, moreover, that if the user tries to "force" the compilation by
simply declaring the A::A(T...) constructor explicitly constexpr, the
compilation in fact succeeds (at least, with GCC ;) and that doesn't
appear to make much sense vs the latter error message. So, what shall we
do? Just patch 1 (with a comment explaining the early return)? Or Patch
2 and reconsider these issues later? Or something else?
Thanks!
Paolo.
/
Index: cp/semantics.c
===
--- cp/semantics.c (revision 208317)
+++ cp/semantics.c (working copy)
@@ -8002,7 +8002,9 @@ explain_invalid_constexpr_fn (tree fun)
tree body;
location_t save_loc;
/* Only diagnose defaulted functions or instantiations. */
- if (!DECL_DEFAULTED_FN (fun)
+ if ((!DECL_DEFAULTED_FN (fun)
+ || (DECL_INHERITED_CTOR_BASE (fun)
+ && TREE_CODE (fun) == TEMPLATE_DECL))
&& !is_instantiation_of_constexpr (fun))
return;
if (diagnosed == NULL)
Index: testsuite/g++.dg/cpp0x/inh-ctor19.C
===
--- testsuite/g++.dg/cpp0x/inh-ctor19.C (revision 0)
+++ testsuite/g++.dg/cpp0x/inh-ctor19.C (working copy)
@@ -0,0 +1,14 @@
+// PR c++/60389
+// { dg-do compile { target c++11 } }
+
+struct A
+{
+ template A(T...) {}
+};
+
+struct B : A
+{
+ using A::A;
+};
+
+constexpr B b; // { dg-error "literal" }
Index: cp/semantics.c
===
--- cp/semantics.c (revision 208317)
+++ cp/semantics.c (working copy)
@@ -7430,7 +7430,7 @@ retrieve_constexpr_fundef (tree fun)
static bool
is_valid_constexpr_fn (tree fun, bool complain)
{
- tree parm = FUNCTION_FIRST_USER_PARM (fun);
+ tree parm = FUNCTION_FIRST_USER_PARM (STRIP_TEMPLATE (fun));
bool ret = true;
for (; parm != NULL; parm = TREE_CHAIN (parm))
if (!literal_type_p (TREE_TYPE (parm)))
Index: testsuite/g++.dg/cpp0x/inh-ctor19.C
===
--- testsuite/g++.dg/cpp0x/inh-ctor19.C (revision 0)
+++ testsuite/g++.dg/cpp0x/inh-ctor19.C (working copy)
@@ -0,0 +1,14 @@
+// PR c++/60389
+// { dg-do compile { target c++11 } }
+
+struct A
+{
+ template A(T...) {}
+};
+
+struct B : A
+{
+ using A::A; // { dg-error "invalid type" }
+};
+
+constexpr B b; // { dg-error "literal" }
[PATCH] Fix up -O1 -> -O0 -flto expansion (PR lto/60404)
Hi!
As discussed in the PR, the assumption that in !optimize functions
all SSA_NAMEs for a particular PARM_DECL or RESULT_DECL can be coalesced
together is wrong for -flto, if you compile with optimizations the object
file and then link with -O0 -flto, because the SSA_NAMEs can already
overlap.
As we don't have info right now if a particular function has always been
compiled with !optimize during the LTO pipeline, this patch fixes the
wrong-code by always assuming it might be optimized at some point if
in_lto_p.
Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?
2014-03-04 Jakub Jelinek
PR lto/60404
* cfgexpand.c (expand_used_vars): Do not assume all SSA_NAMEs
of PARM/RESULT_DECLs must be coalesced with optimize && in_lto_p.
* tree-ssa-coalesce.c (coalesce_ssa_name): Use MUST_COALESCE_COST - 1
cost for in_lto_p.
* gcc.dg/lto/pr60404_0.c: New test.
* gcc.dg/lto/pr60404_1.c: New file.
* gcc.dg/lto/pr60404_2.c: New file.
--- gcc/cfgexpand.c.jj 2014-03-04 10:57:18.0 +0100
+++ gcc/cfgexpand.c 2014-03-04 11:12:12.684524383 +0100
@@ -1652,10 +1652,12 @@ expand_used_vars (void)
debug info, there is no need to do so if optimization is disabled
because all the SSA_NAMEs based on these DECLs have been coalesced
into a single partition, which is thus assigned the canonical RTL
-location of the DECLs. */
+location of the DECLs. If in_lto_p, we can't rely on optimize,
+a function could be compiled with -O1 -flto first and only the
+link performed at -O0. */
if (TREE_CODE (SSA_NAME_VAR (var)) == VAR_DECL)
expand_one_var (var, true, true);
- else if (DECL_IGNORED_P (SSA_NAME_VAR (var)) || optimize)
+ else if (DECL_IGNORED_P (SSA_NAME_VAR (var)) || optimize || in_lto_p)
{
/* This is a PARM_DECL or RESULT_DECL. For those partitions that
contain the default def (representing the parm or result itself)
--- gcc/tree-ssa-coalesce.c.jj 2014-01-03 11:40:57.0 +0100
+++ gcc/tree-ssa-coalesce.c 2014-03-04 11:15:46.955296026 +0100
@@ -1289,9 +1289,12 @@ coalesce_ssa_name (void)
_require_ that all the names originating from it be
coalesced, because there must be a single partition
containing all the names so that it can be assigned
-the canonical RTL location of the DECL safely. */
+the canonical RTL location of the DECL safely.
+If in_lto_p, a function could have been compiled
+originally with optimizations and only the link
+performed at -O0, so we can't actually require it. */
const int cost
- = TREE_CODE (SSA_NAME_VAR (a)) == VAR_DECL
+ = (TREE_CODE (SSA_NAME_VAR (a)) == VAR_DECL || in_lto_p)
? MUST_COALESCE_COST - 1 : MUST_COALESCE_COST;
add_coalesce (cl, SSA_NAME_VERSION (a),
SSA_NAME_VERSION (*slot), cost);
--- gcc/testsuite/gcc.dg/lto/pr60404_0.c.jj 2014-03-04 11:19:48.503909557
+0100
+++ gcc/testsuite/gcc.dg/lto/pr60404_0.c2014-03-04 11:09:51.590333222
+0100
@@ -0,0 +1,15 @@
+/* { dg-lto-do run } */
+/* { dg-lto-options { { -O1 -flto } } } */
+/* { dg-extra-ld-options { -O0 } } */
+
+extern void fn2 (int);
+int a[1], b;
+
+int
+main ()
+{
+ fn2 (0);
+ if (b != 0 || a[b] != 0)
+__builtin_abort ();
+ return 0;
+}
--- gcc/testsuite/gcc.dg/lto/pr60404_1.c.jj 2014-03-04 11:19:51.057894910
+0100
+++ gcc/testsuite/gcc.dg/lto/pr60404_1.c2014-03-04 09:32:35.0
+0100
@@ -0,0 +1,4 @@
+void
+fn1 (int p)
+{
+}
--- gcc/testsuite/gcc.dg/lto/pr60404_2.c.jj 2014-03-04 11:19:54.578874717
+0100
+++ gcc/testsuite/gcc.dg/lto/pr60404_2.c2014-03-04 09:33:18.0
+0100
@@ -0,0 +1,9 @@
+extern int b;
+extern void fn1 (int);
+
+void
+fn2 (int p)
+{
+ b = p++;
+ fn1 (p);
+}
Jakub
[PATCH] Don't ICE with huge alignment (PR middle-end/60226)
This should fix ICE on insane alignment. Normally, check_user_alignment
detects e.g. alignment 1 << 32, but not 1 << 28. However, record_align
is in bits, so it's actually 8 * (1 << 28) and that's greater than
INT_MAX. This patch rejects such code.
In the middle hunk, we should give up when an error occurs, we don't
want to call finalize_type_size in that case -- we'd ICE in there.
Regtested/bootstrapped on x86_64-linux, ok for trunk?
2014-03-04 Marek Polacek
PR middle-end/60226
* stor-layout.c (layout_type): Return if alignment of array elements
is greater than element size. Error out if requested alignment is too
large.
cp/
* class.c (layout_class_type): Error out if requested alignment is too
large.
testsuite/
* c-c++-common/pr60226.c: New test.
diff --git gcc/cp/class.c gcc/cp/class.c
index b46391b..e6325b3 100644
--- gcc/cp/class.c
+++ gcc/cp/class.c
@@ -6378,6 +6378,14 @@ layout_class_type (tree t, tree *virtuals_p)
if (TYPE_PACKED (t) && !layout_pod_type_p (t))
rli->packed_maybe_necessary = true;
+ if (rli->record_align >= (1U << (HOST_BITS_PER_INT - 1)))
+{
+ TYPE_SIZE (rli->t) = integer_zero_node;
+ TYPE_SIZE_UNIT (rli->t) = integer_zero_node;
+ error ("requested alignment is too large");
+ return;
+}
+
/* Let the back end lay out the type. */
finish_record_layout (rli, /*free_p=*/true);
diff --git gcc/stor-layout.c gcc/stor-layout.c
index 084d195..445f0d5 100644
--- gcc/stor-layout.c
+++ gcc/stor-layout.c
@@ -2266,8 +2266,11 @@ layout_type (tree type)
&& !TREE_OVERFLOW (TYPE_SIZE_UNIT (element))
&& !integer_zerop (TYPE_SIZE_UNIT (element))
&& compare_tree_int (TYPE_SIZE_UNIT (element),
-TYPE_ALIGN_UNIT (element)) < 0)
- error ("alignment of array elements is greater than element size");
+TYPE_ALIGN_UNIT (element)) < 0)
+ {
+ error ("alignment of array elements is greater than element size");
+ return;
+ }
break;
}
@@ -2294,6 +2297,14 @@ layout_type (tree type)
if (TREE_CODE (type) == QUAL_UNION_TYPE)
TYPE_FIELDS (type) = nreverse (TYPE_FIELDS (type));
+ if (rli->record_align >= (1U << (HOST_BITS_PER_INT - 1)))
+ {
+ TYPE_SIZE (rli->t) = integer_zero_node;
+ TYPE_SIZE_UNIT (rli->t) = integer_zero_node;
+ error ("requested alignment is too large");
+ return;
+ }
+
/* Finish laying out the record. */
finish_record_layout (rli, /*free_p=*/true);
}
diff --git gcc/testsuite/c-c++-common/pr60226.c
gcc/testsuite/c-c++-common/pr60226.c
index e69de29..0d7d74d 100644
--- gcc/testsuite/c-c++-common/pr60226.c
+++ gcc/testsuite/c-c++-common/pr60226.c
@@ -0,0 +1,12 @@
+/* PR c/60226 */
+/* { dg-do compile } */
+/* { dg-options "-Wno-c++-compat" { target c } } */
+
+typedef int __attribute__ ((aligned (1 << 28))) int28;
+int28 foo[4] = {}; /* { dg-error "alignment of array elements is greater than
element size" } */
+
+void
+f (void)
+{
+ struct { __attribute__((aligned (1 << 28))) double a; } x; /* { dg-error
"requested alignment is too large" } */
+}
Marek
[testsuite] Further logical_op_short_circuit changes (PR testsuite/59308)
Hi!
With some -march=/-mtune= flags even i?86/x86_64 has BRANCH_COST 1 and
various tests fail, furthermore ssa-ifcombine-ccmp* apparently fail on e.g.
s390* or some arm variants.
This patch tries to fix that up.
Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?
2014-03-04 Jakub Jelinek
PR testsuite/59308
* gcc.dg/pr46309.c: Don't compile on logical_op_short_circuit targets
other than mips/avr. Use -mbranch-cost=2 even for i?86/x86_64.
* gcc.dg/tree-ssa/reassoc-32.c: Use -mbranch-cost=2 even for
s390*/i?86/x86_64.
* gcc.dg/tree-ssa/reassoc-33.c: Likewise.
* gcc.dg/tree-ssa/reassoc-34.c: Likewise.
* gcc.dg/tree-ssa/reassoc-35.c: Likewise.
* gcc.dg/tree-ssa/reassoc-36.c: Likewise.
* gcc.dg/tree-ssa/ssa-ifcombine-ccmp-1.c: Don't compile on
logical_op_short_circuit targets other than avr. Use -mbranch-cost=2
even for mips*/s390*/i?86/x86_64.
* gcc.dg/tree-ssa/ssa-ifcombine-ccmp-2.c: Likewise.
* gcc.dg/tree-ssa/ssa-ifcombine-ccmp-3.c: Likewise.
* gcc.dg/tree-ssa/ssa-ifcombine-ccmp-4.c: Likewise.
* gcc.dg/tree-ssa/ssa-ifcombine-ccmp-5.c: Likewise.
* gcc.dg/tree-ssa/ssa-ifcombine-ccmp-6.c: Likewise.
--- gcc/testsuite/gcc.dg/pr46309.c.jj 2014-01-10 21:24:11.0 +0100
+++ gcc/testsuite/gcc.dg/pr46309.c 2014-03-04 12:02:00.258512491 +0100
@@ -1,10 +1,10 @@
/* PR tree-optimization/46309 */
-/* { dg-do compile { target { ! { cris*-*-* } } } } */
+/* { dg-do compile { target { { ! logical_op_short_circuit } || { mips*-*-*
avr*-*-* } } } } */
/* { dg-options "-O2 -fdump-tree-reassoc-details" } */
/* The transformation depends on BRANCH_COST being greater than 1
(see the notes in the PR), so try to force that. */
/* { dg-additional-options "-mtune=octeon2" { target mips*-*-* } } */
-/* { dg-additional-options "-mbranch-cost=2" { target avr*-*-* s390*-*-* } } */
+/* { dg-additional-options "-mbranch-cost=2" { target avr*-*-* s390*-*-*
i?86-*-* x86_64-*-* } } */
int
f1 (int a)
--- gcc/testsuite/gcc.dg/tree-ssa/reassoc-32.c.jj 2014-01-08
23:32:20.0 +0100
+++ gcc/testsuite/gcc.dg/tree-ssa/reassoc-32.c 2014-03-04 11:47:17.010524086
+0100
@@ -1,7 +1,7 @@
/* { dg-do run { target { ! "m68k*-*-* mmix*-*-* mep*-*-* bfin*-*-* v850*-*-*
picochip*-*-* moxie*-*-* cris*-*-* m32c*-*-* fr30*-*-* mcore*-*-* powerpc*-*-*
xtensa*-*-*"} } } */
/* { dg-options "-O2 -fno-inline -fdump-tree-reassoc1-details" } */
-/* { dg-additional-options "-mbranch-cost=2" { target mips*-*-* avr-*-* } } */
+/* { dg-additional-options "-mbranch-cost=2" { target mips*-*-* avr-*-*
s390*-*-* i?86-*-* x86_64-*-* } } */
int test (int a, int b, int c)
--- gcc/testsuite/gcc.dg/tree-ssa/reassoc-33.c.jj 2014-01-08
23:32:20.0 +0100
+++ gcc/testsuite/gcc.dg/tree-ssa/reassoc-33.c 2014-03-04 11:47:22.440492832
+0100
@@ -1,7 +1,7 @@
/* { dg-do run { target { ! "m68k*-*-* mmix*-*-* mep*-*-* bfin*-*-* v850*-*-*
picochip*-*-* moxie*-*-* cris*-*-* m32c*-*-* fr30*-*-* mcore*-*-* powerpc*-*-*
xtensa*-*-* hppa*-*-*"} } } */
/* { dg-options "-O2 -fno-inline -fdump-tree-reassoc1-details" } */
-/* { dg-additional-options "-mbranch-cost=2" { target mips*-*-* avr-*-* } } */
+/* { dg-additional-options "-mbranch-cost=2" { target mips*-*-* avr-*-*
s390*-*-* i?86-*-* x86_64-*-* } } */
int test (int a, int b, int c)
{
--- gcc/testsuite/gcc.dg/tree-ssa/reassoc-34.c.jj 2014-01-08
23:32:20.0 +0100
+++ gcc/testsuite/gcc.dg/tree-ssa/reassoc-34.c 2014-03-04 11:47:32.345438791
+0100
@@ -1,7 +1,7 @@
/* { dg-do run { target { ! "m68k*-*-* mmix*-*-* mep*-*-* bfin*-*-* v850*-*-*
picochip*-*-* moxie*-*-* cris*-*-* m32c*-*-* fr30*-*-* mcore*-*-* powerpc*-*-*
xtensa*-*-* hppa*-*-*"} } } */
/* { dg-options "-O2 -fno-inline -fdump-tree-reassoc1-details" } */
-/* { dg-additional-options "-mbranch-cost=2" { target mips*-*-* avr-*-* } } */
+/* { dg-additional-options "-mbranch-cost=2" { target mips*-*-* avr-*-*
s390*-*-* i?86-*-* x86_64-*-* } } */
int test (int a, int b, int c)
{
--- gcc/testsuite/gcc.dg/tree-ssa/reassoc-35.c.jj 2014-01-08
23:32:20.0 +0100
+++ gcc/testsuite/gcc.dg/tree-ssa/reassoc-35.c 2014-03-04 11:47:37.155409295
+0100
@@ -1,7 +1,7 @@
/* { dg-do run { target { ! "m68k*-*-* mmix*-*-* mep*-*-* bfin*-*-* v850*-*-*
picochip*-*-* moxie*-*-* cris*-*-* m32c*-*-* fr30*-*-* mcore*-*-* powerpc*-*-*
xtensa*-*-* hppa*-*-*"} } } */
/* { dg-options "-O2 -fno-inline -fdump-tree-reassoc1-details" } */
-/* { dg-additional-options "-mbranch-cost=2" { target mips*-*-* avr-*-* } } */
+/* { dg-additional-options "-mbranch-cost=2" { target mips*-*-* avr-*-*
s390*-*-* i?86-*-* x86_64-*-* } } */
int test (unsigned int a, int b, int c)
{
--- gcc/testsuite/gcc.dg/tree-ssa/reassoc-36.c.jj 2014-01-08
23:32:20.0 +0100
+++ gcc/testsuite/gcc.dg/tree-ssa/reassoc-36.c 2014-03-04 11:47:43.193374228
+0100
@
[PATCH, rs6000, committed] Change "vector long" to "vector long long" in recently added tests
Hi,
I have been accidentally not testing -m32 for the last few weeks, so I
missed some compatibility issues with recent tests. "vector long"
produces 2x64 vectors for -m64, but 4x32 vectors for -m32. This caused
some of the tests to fail on the AIX tester. For compatibility across
both, I need to use "vector long long" instead. I've made this change
throughout the recently added vector API tests.
Tested on powerpc64le-unknown-linux-gnu with -m64, on
powerpc64-unknown-linux-gnu with -m32/-m64, and on gcc111.fsffrance.org
running AIX 7.1. The tests now pass in all environments (except for a
handful that are failing on AIX for another reason). Committed as
obvious (in retrospect :).
Thanks,
Bill
2014-03-04 Bill Schmidt
* gcc.dg/vmx/extract-vsx.c: Replace "vector long" with "vector
long long" throughout.
* gcc.dg/vmx/extract-vsx-be-order.c: Likewise.
* gcc.dg/vmx/insert-vsx.c: Likewise.
* gcc.dg/vmx/insert-vsx-be-order.c: Likewise.
* gcc.dg/vmx/ld-vsx.c: Likewise.
* gcc.dg/vmx/ld-vsx-be-order.c: Likewise.
* gcc.dg/vmx/ldl-vsx.c: Likewise.
* gcc.dg/vmx/ldl-vsx-be-order.c: Likewise.
* gcc.dg/vmx/merge-vsx.c: Likewise.
* gcc.dg/vmx/merge-vsx-be-order.c: Likewise.
* gcc.dg/vmx/st-vsx.c: Likewise.
* gcc.dg/vmx/st-vsx-be-order.c: Likewise.
* gcc.dg/vmx/stl-vsx.c: Likewise.
* gcc.dg/vmx/stl-vsx-be-order.c: Likewise.
Index: gcc/testsuite/gcc.dg/vmx/extract-vsx-be-order.c
===
--- gcc/testsuite/gcc.dg/vmx/extract-vsx-be-order.c (revision 208287)
+++ gcc/testsuite/gcc.dg/vmx/extract-vsx-be-order.c (working copy)
@@ -6,7 +6,7 @@
static void test()
{
- vector long vl = {0, 1};
+ vector long long vl = {0, 1};
vector double vd = {0.0, 1.0};
#if __BYTE_ORDER__ == __ORDER_LITTLE_ENDIAN__
Index: gcc/testsuite/gcc.dg/vmx/extract-vsx.c
===
--- gcc/testsuite/gcc.dg/vmx/extract-vsx.c (revision 208287)
+++ gcc/testsuite/gcc.dg/vmx/extract-vsx.c (working copy)
@@ -6,7 +6,7 @@
static void test()
{
- vector long vl = {0, 1};
+ vector long long vl = {0, 1};
vector double vd = {0.0, 1.0};
check (vec_extract (vl, 0) == 0, "vec_extract, vl, 0");
Index: gcc/testsuite/gcc.dg/vmx/insert-vsx-be-order.c
===
--- gcc/testsuite/gcc.dg/vmx/insert-vsx-be-order.c (revision 208287)
+++ gcc/testsuite/gcc.dg/vmx/insert-vsx-be-order.c (working copy)
@@ -4,7 +4,7 @@
#include "harness.h"
-static int vec_long_eq (vector long x, vector long y)
+static int vec_long_long_eq (vector long long x, vector long long y)
{
return (x[0] == y[0] && x[1] == y[1]);
}
@@ -16,19 +16,19 @@ static int vec_dbl_eq (vector double x, vector dou
static void test()
{
- vector long vl = {0, 1};
+ vector long long vl = {0, 1};
vector double vd = {0.0, 1.0};
- vector long vlr = vec_insert (2, vl, 0);
+ vector long long vlr = vec_insert (2, vl, 0);
vector double vdr = vec_insert (2.0, vd, 1);
#if __BYTE_ORDER__ == __ORDER_LITTLE_ENDIAN__
- vector long vler = {0, 2};
+ vector long long vler = {0, 2};
vector double vder = {2.0, 1.0};
#else
- vector long vler = {2, 1};
+ vector long long vler = {2, 1};
vector double vder = {0.0, 2.0};
#endif
- check (vec_long_eq (vlr, vler), "vl");
+ check (vec_long_long_eq (vlr, vler), "vl");
check (vec_dbl_eq (vdr, vder), "vd");
}
Index: gcc/testsuite/gcc.dg/vmx/insert-vsx.c
===
--- gcc/testsuite/gcc.dg/vmx/insert-vsx.c (revision 208287)
+++ gcc/testsuite/gcc.dg/vmx/insert-vsx.c (working copy)
@@ -4,7 +4,7 @@
#include "harness.h"
-static int vec_long_eq (vector long x, vector long y)
+static int vec_long_long_eq (vector long long x, vector long long y)
{
return (x[0] == y[0] && x[1] == y[1]);
}
@@ -16,13 +16,13 @@ static int vec_dbl_eq (vector double x, vector dou
static void test()
{
- vector long vl = {0, 1};
+ vector long long vl = {0, 1};
vector double vd = {0.0, 1.0};
- vector long vlr = vec_insert (2, vl, 0);
+ vector long long vlr = vec_insert (2, vl, 0);
vector double vdr = vec_insert (2.0, vd, 1);
- vector long vler = {2, 1};
+ vector long long vler = {2, 1};
vector double vder = {0.0, 2.0};
- check (vec_long_eq (vlr, vler), "vl");
+ check (vec_long_long_eq (vlr, vler), "vl");
check (vec_dbl_eq (vdr, vder), "vd");
}
Index: gcc/testsuite/gcc.dg/vmx/ld-vsx-be-order.c
===
--- gcc/testsuite/gcc.dg/vmx/ld-vsx-be-order.c (revision 208287)
+++ gcc/testsuite/gcc.dg/vmx/ld-vsx-be-order.c (working copy)
@@ -4,7 +4,7 @@
#include "harness.h"
-static unsigned long svul[2] __attribute__ ((aligned (16)));
+static unsigned long long svul[2] __attribute__ ((
Re: [PATCH 1/4] [GOMP4] [Fortran] OpenACC 1.0+ support in fortran front-end
Hi Ilmir,
thanks for the update.
Ilmir Usmanov wrote:
I'd use "integer" instead of "INTEGER" as it is not a 'reserved' word
OpenMP implementation uses capital letters, so, perhaps, we also
should do this, for consistency?
Fine with me - I don't feel strong about it.
OpenACC 1.0 support to fortran FE -- core.
--- a/gcc/fortran/match.c
+++ b/gcc/fortran/match.c
@@ -2595,6 +2595,33 @@ match_exit_cycle (gfc_statement st, gfc_exec_op op)
if (cnt > 0
&& o != NULL
&& o->state == COMP_OMP_STRUCTURED_BLOCK
+ && (o->head->op == EXEC_OACC_LOOP
+ || o->head->op == EXEC_OACC_PARALLEL_LOOP))
+{
+ int collapse = 1;
+ gcc_assert (o->head->next != NULL
+ && (o->head->next->op == EXEC_DO
+ || o->head->next->op == EXEC_DO_WHILE)
+ && o->previous != NULL
+ && o->previous->tail->op == o->head->op);
+ if (o->previous->tail->ext.omp_clauses != NULL
+ && o->previous->tail->ext.omp_clauses->collapse > 1)
+collapse = o->previous->tail->ext.omp_clauses->collapse;
+ if (st == ST_EXIT && cnt <= collapse)
+{
+ gfc_error ("EXIT statement at %C terminating !$ACC LOOP loop");
+ return MATCH_ERROR;
+}
+ if (st == ST_CYCLE && cnt < collapse)
+{
+ gfc_error ("CYCLE statement at %C to non-innermost collapsed"
+ " !$ACC LOOP loop");
+ return MATCH_ERROR;
+}
+}
Can you - if you want as follow up patch - also handle the following
for both your OpenACC code and for the existing OpenMP code:
!$acc loop
outer_loop: do i = 1, n
inner_loop: do j = 1,m
! ...
cycle outer_loop
exit outer_loop
end do inner_loop
end do outer_loop
That's a new Fortran 2008 feature that CYCLE and EXIT can leave the
inner DO loop.
For DO CONCURRENT, that's already handled via the code in
"match_exit_cycle". If you want to try the do-concurrent code, replace
"inner_loop: do j = 1,m" by "inner_loop: do_concurrent(j=1:m)".
Otherwise, it looks good do me. I don't know whether Thomas has
additional comments.
Tobias
RE: [PATCH] Properly check for _Cilk_spawn in return stmt (PR c/60197)
> -Original Message-
> From: gcc-patches-ow...@gcc.gnu.org [mailto:gcc-patches-
> ow...@gcc.gnu.org] On Behalf Of Marek Polacek
> Sent: Wednesday, February 19, 2014 8:39 AM
> To: Iyer, Balaji V
> Cc: gcc-patches@gcc.gnu.org
> Subject: Re: [PATCH] Properly check for _Cilk_spawn in return stmt (PR
> c/60197)
>
> On Tue, Feb 18, 2014 at 10:06:14PM +, Iyer, Balaji V wrote:
> > This is invalid.
>
> Thanks. In that case, this patch should error out on such invalid uses as
> well,
> instead of ICEing.
>
> Regtested/bootstrapped on x86_64-linux.
>
> 2014-02-19 Marek Polacek
>
> PR c/60197
> c-family/
> * cilk.c (contains_cilk_spawn_stmt): New function.
> (contains_cilk_spawn_stmt_walker): Likewise.
> (recognize_spawn): Give error on invalid use of _Cilk_spawn.
> * c-common.h (contains_cilk_spawn_stmt): Add declaration.
> c/
> * c-typeck.c (c_finish_return): Call contains_cilk_spawn_stmt instead
> of checking tree code.
> cp/
> * typeck.c (check_return_expr): Call contains_cilk_spawn_stmt
> instead
> of checking tree code.
> testsuite/
> * c-c++-common/cilk-plus/CK/pr60197.c: New test.
> * c-c++-common/cilk-plus/CK/pr60197-2.c: New test.
>
> diff --git gcc/c-family/c-common.h gcc/c-family/c-common.h index
> f074ab1..1099b10 100644
> --- gcc/c-family/c-common.h
> +++ gcc/c-family/c-common.h
> @@ -1389,4 +1389,5 @@ extern tree make_cilk_frame (tree); extern tree
> create_cilk_function_exit (tree, bool, bool); extern tree
> cilk_install_body_pedigree_operations (tree); extern void cilk_outline (tree,
> tree *, void *);
> +extern bool contains_cilk_spawn_stmt (tree);
> #endif /* ! GCC_C_COMMON_H */
> diff --git gcc/c-family/cilk.c gcc/c-family/cilk.c index f2179dfc..6a7bf4f
> 100644
> --- gcc/c-family/cilk.c
> +++ gcc/c-family/cilk.c
> @@ -235,6 +235,9 @@ recognize_spawn (tree exp, tree *exp0)
>walk_tree (exp0, unwrap_cilk_spawn_stmt, NULL, NULL);
>spawn_found = true;
> }
> + /* _Cilk_spawn can't be wrapped in expression such as PLUS_EXPR. */
> + else if (contains_cilk_spawn_stmt (exp))
> +error ("invalid use of %<_Cilk_spawn%>");
>return spawn_found;
> }
>
> @@ -1292,3 +1295,25 @@ build_cilk_sync (void)
>TREE_SIDE_EFFECTS (sync) = 1;
>return sync;
> }
> +
> +/* Helper for contains_cilk_spawn_stmt, callback for walk_tree. Return
> + non-null tree if TP contains CILK_SPAWN_STMT. */
> +
> +static tree
> +contains_cilk_spawn_stmt_walker (tree *tp, int *, void *) {
> + if (TREE_CODE (*tp) == CILK_SPAWN_STMT)
> +return *tp;
> + else
> +return NULL_TREE;
> +}
> +
> +/* Returns true if EXPR or any of its subtrees contain CILK_SPAWN_STMT
> + node. */
> +
> +bool
> +contains_cilk_spawn_stmt (tree expr)
> +{
> + return walk_tree (&expr, contains_cilk_spawn_stmt_walker, NULL, NULL)
> + != NULL_TREE;
> +}
> diff --git gcc/c/c-typeck.c gcc/c/c-typeck.c index 2b54290..7c4ba0e 100644
> --- gcc/c/c-typeck.c
> +++ gcc/c/c-typeck.c
> @@ -9140,7 +9140,7 @@ c_finish_return (location_t loc, tree retval, tree
> origtype)
> return error_mark_node;
> }
> }
> - if (flag_cilkplus && retval && TREE_CODE (retval) == CILK_SPAWN_STMT)
> + if (flag_cilkplus && retval && contains_cilk_spawn_stmt (retval))
> {
>error_at (loc, "use of %<_Cilk_spawn%> in a return statement is not "
> "allowed");
> diff --git gcc/cp/typeck.c gcc/cp/typeck.c index 5fc0e6b..566411f 100644
> --- gcc/cp/typeck.c
> +++ gcc/cp/typeck.c
> @@ -8328,7 +8328,7 @@ check_return_expr (tree retval, bool *no_warning)
>
>*no_warning = false;
>
> - if (flag_cilkplus && retval && TREE_CODE (retval) == CILK_SPAWN_STMT)
> + if (flag_cilkplus && retval && contains_cilk_spawn_stmt (retval))
> {
>error_at (EXPR_LOCATION (retval), "use of %<_Cilk_spawn%> in a return
> "
> "statement is not allowed");
> diff --git gcc/testsuite/c-c++-common/cilk-plus/CK/pr60197-2.c
> gcc/testsuite/c-c++-common/cilk-plus/CK/pr60197-2.c
> index e69de29..1e5ca00 100644
> --- gcc/testsuite/c-c++-common/cilk-plus/CK/pr60197-2.c
> +++ gcc/testsuite/c-c++-common/cilk-plus/CK/pr60197-2.c
> @@ -0,0 +1,35 @@
> +/* PR c/60197 */
> +/* { dg-do compile } */
> +/* { dg-options "-fcilkplus" } */
> +
> +extern int foo (void);
> +
> +int
> +fn1 (void)
> +{
> + int i;
> + i = (_Cilk_spawn foo ()) + 1; /* { dg-error "invalid use of" } */
> + return i;
> +}
> +
> +int
> +fn2 (void)
> +{
> + int i = (_Cilk_spawn foo ()) + 1; /* { dg-error "invalid use of" } */
> + return i;
> +}
> +
> +int
> +fn3 (int j, int k, int l)
> +{
> + int i = (_Cilk_spawn foo ()) + 1) - l) * k) / j); /* { dg-error
> +"invalid use of" } */
> + return i;
> +}
> +
> +int
> +fn4 (int j, int k, int l)
> +{
> + int i;
> + i = (_Cilk_spawn foo ()) + 1) - l) * k) / j); /* { dg-error
> +"invalid use of" } */
> + return i;
> +}
> diff --git gcc/testsuite/c-c++-common/cilk-plus/CK/pr60197.c gcc/testsuite/c-
> c
Re: [PATCH 1/4] [GOMP4] [Fortran] OpenACC 1.0+ support in fortran front-end
Ilmir Usmanov:
OpenACC 1.0 support to fortran FE -- core.
+ case OMP_LIST_USE_DEVICE:
+ if (n->sym->attr.allocatable)
+ gfc_error ("ALLOCATABLE object '%s' of polymorphic type "
+ "in %s clause at %L", n->sym->name, name,
&code->loc);
That check is wrong (copy & paste bug): Either you only want to check
for allocatable - then it might be nonpolymorphic. Or you want to check
for polymorphism - then the check needs to be extended.
+ if ((sym->ts.type == BT_CLASS || sym->ts.type == BT_ASSUMED)
+ && sym->attr.allocatable)
+gfc_error ("ALLOCATABLE object '%s' of polymorphic type "
+ "in %s clause at %L", sym->name, name, &loc);
Due to the idiosyncratic way BT_CLASS is implemented, this allocatable
check won't work. You have to use:
(sym->ts.type == BT_ASSUMED && sym->attr.allocatable)
|| (sym->ts.type == BT_ASSUMED && CLASS_DATA (sym)
&& CLASS_DATA (sym)->attr.allocatable)
You may need to add a similar check also in place of
sym->attr.allocatable and sym->attr.pointer (there:
CLASS_DATA(sym)->attr.class_pointer - instead of attr.pointer) for the
other checks, if a BT_CLASS can occur. (Thus: if(ts.type != BT_CLASS &&
...) || (ts.type == BT_CLASS && ...)
The extra CLASS_DATA(sym) ensures that one doesn't deref a NULL pointer,
which can happen if an error has occurred. That shouldn't be required in
trans*.c, but at least in resolve.c it can happen that the code is
reached, even though an error has been printed before.
+static void
+resolve_oacc_cache (gfc_code *)
+{
+ // Nothing to do yet
+}
Shouldn't you use:
sorry("OpenACC cache not yet implemented");
or something like that?
Otherwise, it looks good to me.
Tobias
Re: [PATCH, i386] Fix emitting of prefetch instructions
On Tue, Mar 4, 2014 at 1:13 AM, Uros Bizjak wrote:
> On Tue, Mar 4, 2014 at 12:31 AM, Uros Bizjak wrote:
>
The new gcc.target/i386/prefetchwt1-1.c test currently FAILs on Solaris
9/x86:
FAIL: gcc.target/i386/prefetchwt1-1.c (test for excess errors)
Excess errors:
/var/gcc/regression/trunk/9-gcc-gas/build/gcc/include/xmmintrin.h:1195:1:
error:
inlining failed in call to always_inline '_mm_prefetch': target specific
option
mismatch
/vol/gcc/src/hg/trunk/local/gcc/testsuite/gcc.target/i386/prefetchwt1-1.c:12:5:
error: called from here
gcc.target/i386/prefetchwt1-1.c: output file does not exist
UNRESOLVED: gcc.target/i386/prefetchwt1-1.c scan-assembler [
\\t]+prefetchwt1[ \
\t]+
This can be fixed by compiling with -msse2.
>>>
>>> Actually, we should take prefetch instructions out of various GCC
>>> target pragmas. Patterns that emit these instructions are designed to
>>> (depending on selected ISA) always emit the most optimal prefetch
>>> instruction.
>>>
>>> The patch also changes the compiler to emit prefetchwt1 only for
>>> _MM_HINT_T1, while for _MM_HINT_T0, it still emits prefetchw. In
>>> addition, the patch corrects wrong MM_HINT_T0 value.
>>>
>>> Patch was bootstrapped and tested on x86_64-pc-linux-gnu {,-m32} and
>>> committed to mainline SVN.
>>>
>>> 2014-03-03 Uros Bizjak
>>>
>>> * config/i386/xmmintrin.h (enum _mm_hint) <_MM_HINT_ET0>: Correct
>>> hint value.
>>> (_mm_prefetch): Move out of GCC target("sse") pragma.
>>> * config/i386/prfchwintrin.h (_m_prefetchw): Move out of
>>> GCC target("prfchw") pragma.
>>> * config/i386/i386.md (prefetch): Emit prefetchwt1 only
>>> for locality <= 2.
>>> * config/i386/i386.c (ix86_option_override_internal): Enable
>>> -mprfchw with -mprefetchwt1.
>>
>> BTW: There are a couple of new testsuite failures:
>>
>> FAIL: gcc.target/i386/avx512pf-vscatterpf0dpd-1.c (test for excess errors)
>> UNRESOLVED: gcc.target/i386/avx512pf-vscatterpf0dpd-1.c
>> scan-assembler-times vscatterpf0dpd[ t]+[^\\n]*%ymm[0-9] 2
>> UNRESOLVED: gcc.target/i386/avx512pf-vscatterpf0dpd-1.c
>> scan-assembler-times vscatterpf0dpd[ t]+[^\\n]*{%k[1-7] 1
>> FAIL: gcc.target/i386/avx512pf-vscatterpf0dps-1.c (test for excess errors)
>> UNRESOLVED: gcc.target/i386/avx512pf-vscatterpf0dps-1.c
>> scan-assembler-times vscatterpf0dps[ t]+[^\\n]*%zmm[0-9] 2
>> UNRESOLVED: gcc.target/i386/avx512pf-vscatterpf0dps-1.c
>> scan-assembler-times vscatterpf0dps[ t]+[^\\n]*{%k[1-7] 1
>> FAIL: gcc.target/i386/avx512pf-vscatterpf0qpd-1.c (test for excess errors)
>> UNRESOLVED: gcc.target/i386/avx512pf-vscatterpf0qpd-1.c
>> scan-assembler-times vscatterpf0qpd[ t]+[^\\n]*%zmm[0-9] 2
>> UNRESOLVED: gcc.target/i386/avx512pf-vscatterpf0qpd-1.c
>> scan-assembler-times vscatterpf0qpd[ t]+[^\\n]*{%k[1-7] 1
>> FAIL: gcc.target/i386/avx512pf-vscatterpf0qps-1.c (test for excess errors)
>> UNRESOLVED: gcc.target/i386/avx512pf-vscatterpf0qps-1.c
>> scan-assembler-times vscatterpf0qps[ t]+[^\\n]*%zmm[0-9] 2
>> UNRESOLVED: gcc.target/i386/avx512pf-vscatterpf0qps-1.c
>> scan-assembler-times vscatterpf0qps[ t]+[^\\n]*{%k[1-7] 1
>>
>> They are all:
>>
>> FAIL: gcc.target/i386/avx512pf-vscatterpf0dpd-1.c (test for excess errors)
>> Excess errors:
>> /ssd/uros/gcc-build/gcc/include/avx512pfintrin.h:108:3: error: the
>> last argument must be hint 0 or 1
>>
>> They are due to _MM_HINT_ET0 fix, and probably show that the pattern
>> was not updated when hint constants were adjusted to 2 and 3.
>>
>> Kirill, can you please look at this inconsistency?
>
> Attached patch fixes these failures, and also fixes and improves error
> message.
2014-03-04 Uros Bizjak
* config/i386/predicates.md (const2356_operand): Change to ...
(const2367_operand): ... this.
* config/i386/sse.md (avx512pf_scatterpfsf): Use
const2367_operand.
(*avx512pf_scatterpfsf_mask): Ditto.
(*avx512pf_scatterpfsf): Ditto.
(avx512pf_scatterpfdf): Ditto.
(*avx512pf_scatterpfdf_mask): Ditto.
(*avx512pf_scatterpfdf): Ditto.
* config/i386/i386.c (ix86_expand_builtin): Update
incorrect hint operand error message.
Bootstrapped and regression tested on x86_64-pc-linux-gnu {,-m32} and
committed to mainline SVN.
Uros.
Re: [PATCH] Use the LTO linker plugin by default
>
> The following patch addresses the common (?) issue of people
> omitting -flto from the linker command-line which gets more
> severe with GCC 4.9 where slim LTO objects are emitted by
> default. The patch simply _always_ arranges for the linker
> plugin to be used, so if there are any (slim) LTO objects
> on the link LTO will be done on them. Similarly the
> non-linker-plugin path in collect2 is adjusted.
>
> You can still disable this by specifying -fno-lto on the
> linker command-line.
>
> One side-effect of enabling the linker-plugin by default
> (for HAVE_LTO_PLUGIN == 2) is that collect2 will then
> use the configured plugin ld rather than the default ld.
> Not sure if that is desired.
>
> Comments?
I like it; it was on my TODO list, but I was only worried about
--with-plugin-ld and did not find time, yet, to look into the consequences.
These days, I do not think we need to worry much aboud --with-plugin-ld.
Honza
>
> Thanks,
> Richard.
>
> 2014-03-04 Richard Biener
>
> * gcc.c (PLUGIN_COND): Always enable unless -fno-use-linker-plugin
> or -fno-lto is specified and the linker has full plugin support.
> * collect2.c (lto_mode): Default to LTO_MODE_WHOPR if LTO is
> enabled.
> (main): Remove -flto processing, adjust lto_mode using
> use_plugin late.
>
> Index: gcc/gcc.c
> ===
> --- gcc/gcc.c (revision 208310)
> +++ gcc/gcc.c (working copy)
> @@ -695,7 +695,7 @@ proper position among the other output f
> #if HAVE_LTO_PLUGIN > 0
> /* The linker used has full plugin support, use LTO plugin by default. */
> #if HAVE_LTO_PLUGIN == 2
> -#define PLUGIN_COND "!fno-use-linker-plugin:%{flto|flto=*|fuse-linker-plugin"
> +#define PLUGIN_COND "!fno-use-linker-plugin:%{!fno-lto"
> #define PLUGIN_COND_CLOSE "}"
> #else
> /* The linker used has limited plugin support, use LTO plugin with explicit
> Index: gcc/collect2.c
> ===
> --- gcc/collect2.c(revision 208310)
> +++ gcc/collect2.c(working copy)
> @@ -192,7 +192,11 @@ enum lto_mode_d {
> };
>
> /* Current LTO mode. */
> +#ifdef ENABLE_LTO
> +static enum lto_mode_d lto_mode = LTO_MODE_WHOPR;
> +#else
> static enum lto_mode_d lto_mode = LTO_MODE_NONE;
> +#endif
>
> bool debug; /* true if -debug */
> bool helpflag; /* true if --help */
> @@ -1018,15 +1022,11 @@ main (int argc, char **argv)
> debug = true;
> else if (! strcmp (argv[i], "-flto-partition=none"))
> no_partition = true;
> -else if ((! strncmp (argv[i], "-flto=", 6)
> - || ! strcmp (argv[i], "-flto")) && ! use_plugin)
> - lto_mode = LTO_MODE_WHOPR;
> else if (!strncmp (argv[i], "-fno-lto", 8))
> lto_mode = LTO_MODE_NONE;
> else if (! strcmp (argv[i], "-plugin"))
> {
> use_plugin = true;
> - lto_mode = LTO_MODE_NONE;
> if (selected_linker == USE_DEFAULT_LD)
> selected_linker = USE_PLUGIN_LD;
> }
> @@ -1056,6 +1056,8 @@ main (int argc, char **argv)
>}
> vflag = debug;
> find_file_set_debug (debug);
> +if (use_plugin)
> + lto_mode = LTO_MODE_NONE;
> if (no_partition && lto_mode == LTO_MODE_WHOPR)
>lto_mode = LTO_MODE_LTO;
>}
Re: [PATCH] Use the LTO linker plugin by default
> On 2014.03.04 at 13:00 +0100, Richard Biener wrote: > > > > The following patch addresses the common (?) issue of people > > omitting -flto from the linker command-line which gets more > > severe with GCC 4.9 where slim LTO objects are emitted by > > default. The patch simply _always_ arranges for the linker > > plugin to be used, so if there are any (slim) LTO objects > > on the link LTO will be done on them. Similarly the > > non-linker-plugin path in collect2 is adjusted. > > > > You can still disable this by specifying -fno-lto on the > > linker command-line. > > > > One side-effect of enabling the linker-plugin by default > > (for HAVE_LTO_PLUGIN == 2) is that collect2 will then > > use the configured plugin ld rather than the default ld. > > Not sure if that is desired. > > > > Comments? > > I've been using a similar patch (without the collect2.c hunks) locally > for the past few month without any problems. > > What is missing is a big fat warning in > http://gcc.gnu.org/gcc-4.9/changes.html that one should use the gcc > binutils wrappers (gcc-ar, etc.) when building projects with LTO. I have a patch for that somewhere I think even approved by Gerald. I will dig it out. Honza > > -- > Markus
Re: [PATCH][RFC] Merge LTO -O options from compile-time
>
> This merges -O options given at compile-time into a single
> optimization level to be used for LTO link time (but
> overridden with whatever is specified at LTO link time - unless
> no optimization level is specified there). That is, it
> determines a "default" optimization level used at LTO link time
> (as opposed to the default optimization level zero).
>
> Currently the code merges exact same options as-is and
> mismatching optimization levels based on the maximum value of
> 'optimize' they cause and merging it as -Ooptimize.
> Thus -Og and -Os get merged as -O2, -O and -Ofast get merged as -O3
> and -O and -O1 get merged as -O1.
>
> Specifying any optimization level explicitely at link time
> will override what we came up with above (including explicitely
> specifying -O0).
>
> Comments?
>
> I've tested that it works as expected. Do we want something like
> this for 4.9?
Yes, I do not see much down-sides. Of course I have the grand plans
to make compiler flags to be preserved thorough LTO, but i think you
patch improves things over what we have now.
Honza
>
> Thanks,
> Richard.
>
> 2014-03-04 Richard Biener
>
> * lto-wrapper.c (merge_and_complain): Merge compile-time
> optimization levels.
> (run_gcc): And pass it through to the link options.
>
> Index: gcc/lto-wrapper.c
> ===
> *** gcc/lto-wrapper.c (revision 208305)
> --- gcc/lto-wrapper.c (working copy)
> *** merge_and_complain (struct cl_decoded_op
> *** 459,464
> --- 459,535
> fatal ("Option %s not used consistently in all LTO input files",
> foption->orig_option_with_args_text);
> break;
> +
> + case OPT_O:
> + case OPT_Ofast:
> + case OPT_Og:
> + case OPT_Os:
> + for (j = 0; j < *decoded_options_count; ++j)
> + if ((*decoded_options)[j].opt_index == OPT_O
> + || (*decoded_options)[j].opt_index == OPT_Ofast
> + || (*decoded_options)[j].opt_index == OPT_Og
> + || (*decoded_options)[j].opt_index == OPT_Os)
> + break;
> + if (j == *decoded_options_count)
> + append_option (decoded_options, decoded_options_count, foption);
> + else if ((*decoded_options)[j].opt_index == foption->opt_index
> +&& foption->opt_index != OPT_O)
> + /* Exact same options get merged. */
> + ;
> + else
> + {
> + /* For mismatched option kinds preserve the optimization
> + level only, thus merge it as -On. This also handles
> + merging of same optimization level -On. */
> + int level = 0;
> + switch (foption->opt_index)
> + {
> + case OPT_O:
> + if (foption->arg[0] == '\0')
> + level = MAX (level, 1);
> + else
> + level = MAX (level, atoi (foption->arg));
> + break;
> + case OPT_Ofast:
> + level = MAX (level, 3);
> + break;
> + case OPT_Og:
> + level = MAX (level, 1);
> + break;
> + case OPT_Os:
> + level = MAX (level, 2);
> + break;
> + default:
> + gcc_unreachable ();
> + }
> + switch ((*decoded_options)[j].opt_index)
> + {
> + case OPT_O:
> + if ((*decoded_options)[j].arg[0] == '\0')
> + level = MAX (level, 1);
> + else
> + level = MAX (level, atoi ((*decoded_options)[j].arg));
> + break;
> + case OPT_Ofast:
> + level = MAX (level, 3);
> + break;
> + case OPT_Og:
> + level = MAX (level, 1);
> + break;
> + case OPT_Os:
> + level = MAX (level, 2);
> + break;
> + default:
> + gcc_unreachable ();
> + }
> + (*decoded_options)[j].opt_index = OPT_O;
> + char *tem;
> + asprintf (&tem, "-O%d", level);
> + (*decoded_options)[j].arg = &tem[2];
> + (*decoded_options)[j].canonical_option[0] = tem;
> + (*decoded_options)[j].value = 1;
> + }
> + break;
> }
> }
> }
> *** run_gcc (unsigned argc, char *argv[])
> *** 610,615
> --- 681,690
> case OPT_fwrapv:
> case OPT_ftrapv:
> case OPT_fstrict_overflow:
> + case OPT_O:
> + case OPT_Ofast:
> + case OPT_Og:
> + case OPT_Os:
> break;
>
> default:
[PATCH] Fix PR c++/60033
PR c++/60033
* pt.c (retrieve_specialization): When retrieving a capture pack from a
generic lambda, remove the lambda's own template argument list prior to
fetching the specialization.
PR c++/60033
* g++.dg/cpp1y/pr60033.C: New testcase.
---
gcc/cp/pt.c | 11 +++
gcc/testsuite/g++.dg/cpp1y/pr60033.C | 20
2 files changed, 31 insertions(+)
create mode 100644 gcc/testsuite/g++.dg/cpp1y/pr60033.C
diff --git a/gcc/cp/pt.c b/gcc/cp/pt.c
index 8126905..0d0b1dc 100644
--- a/gcc/cp/pt.c
+++ b/gcc/cp/pt.c
@@ -1031,6 +1031,17 @@ retrieve_specialization (tree tmpl, tree args, hashval_t
hash)
gcc_assert (TREE_CODE (tmpl) == TEMPLATE_DECL
|| TREE_CODE (tmpl) == FIELD_DECL);
+ /* When retrieving a capture pack from a generic lambda, remove the lambda
+ call op's own template argument list from ARGS. Only the template
+ arguments active for the closure type should be used to retrieve the pack
+ specialization.
+ XXX: It may be that this situation can be avoided by manipulating the
field
+ XXX: type earlier. */
+ if (TREE_CODE (tmpl) == FIELD_DECL
+ && LAMBDA_FUNCTION_P (current_function_decl)
+ && template_class_depth (DECL_CONTEXT (tmpl)) != TMPL_ARGS_DEPTH (args))
+args = strip_innermost_template_args (args, 1);
+
/* There should be as many levels of arguments as there are
levels of parameters. */
gcc_assert (TMPL_ARGS_DEPTH (args)
diff --git a/gcc/testsuite/g++.dg/cpp1y/pr60033.C
b/gcc/testsuite/g++.dg/cpp1y/pr60033.C
new file mode 100644
index 000..8194bec
--- /dev/null
+++ b/gcc/testsuite/g++.dg/cpp1y/pr60033.C
@@ -0,0 +1,20 @@
+// PR c++/60033
+// { dg-options -std=c++1y }
+
+template
+auto f(T&&... ts)
+{
+ return sizeof...(ts);
+}
+
+template
+auto g(T&&... ts) {
+ return [&] (auto v) {
+return f(ts...);
+ };
+}
+
+int main()
+{
+ return g(1,2,3,4)(5) == 4 ? 0 : 1;
+}
--
1.9.0
[jit] New API entrypoint: gcc_jit_type_get_volatile
Committed to branch dmalcolm/jit:
gcc/jit/
* libgccjit.h (gcc_jit_type_get_volatile): New.
* libgccjit.map (gcc_jit_type_get_volatile): New.
* libgccjit.c (gcc_jit_type_get_volatile): New.
* libgccjit++.h (gccjit::type::get_volatile): New.
* internal-api.c (gcc::jit::recording::type::get_volatile): New.
(gcc::jit::recording::memento_of_get_volatile::replay_into): New.
(gcc::jit::recording::memento_of_get_volatile::make_debug_string): New.
* internal-api.h (gcc::jit::recording::type::get_volatile): New.
(gcc::jit::recording::type::accepts_writes_from): Strip off
qualifiers such as "const" and "volatile" from the source type.
(gcc::jit::recording::memento_of_get_volatile): New class.
(gcc::jit::playback::type::get_volatile): New.
* TODO.rst: Update.
gcc/testsuite/
* jit.dg/test-volatile.c: New testcase, to exercise
gcc_jit_type_get_volatile, and show a way to work with pre-existing
global variables.
---
gcc/jit/ChangeLog.jit| 16 +
gcc/jit/TODO.rst | 2 --
gcc/jit/internal-api.c | 23 +
gcc/jit/internal-api.h | 30 +++-
gcc/jit/libgccjit++.h| 7
gcc/jit/libgccjit.c | 8 +
gcc/jit/libgccjit.h | 4 +++
gcc/jit/libgccjit.map| 1 +
gcc/testsuite/ChangeLog.jit | 6
gcc/testsuite/jit.dg/test-volatile.c | 66
10 files changed, 160 insertions(+), 3 deletions(-)
create mode 100644 gcc/testsuite/jit.dg/test-volatile.c
diff --git a/gcc/jit/ChangeLog.jit b/gcc/jit/ChangeLog.jit
index dd4bf84..56f7b85 100644
--- a/gcc/jit/ChangeLog.jit
+++ b/gcc/jit/ChangeLog.jit
@@ -1,3 +1,19 @@
+2014-03-04 David Malcolm
+
+ * libgccjit.h (gcc_jit_type_get_volatile): New.
+ * libgccjit.map (gcc_jit_type_get_volatile): New.
+ * libgccjit.c (gcc_jit_type_get_volatile): New.
+ * libgccjit++.h (gccjit::type::get_volatile): New.
+ * internal-api.c (gcc::jit::recording::type::get_volatile): New.
+ (gcc::jit::recording::memento_of_get_volatile::replay_into): New.
+ (gcc::jit::recording::memento_of_get_volatile::make_debug_string): New.
+ * internal-api.h (gcc::jit::recording::type::get_volatile): New.
+ (gcc::jit::recording::type::accepts_writes_from): Strip off
+ qualifiers such as "const" and "volatile" from the source type.
+ (gcc::jit::recording::memento_of_get_volatile): New class.
+ (gcc::jit::playback::type::get_volatile): New.
+ * TODO.rst: Update.
+
2014-03-03 David Malcolm
* libgccjit++.h (gccjit::function::operator()): Add overload for
diff --git a/gcc/jit/TODO.rst b/gcc/jit/TODO.rst
index 8a2308e..ea09e45 100644
--- a/gcc/jit/TODO.rst
+++ b/gcc/jit/TODO.rst
@@ -19,8 +19,6 @@ Initial Release
* unions
* function ptrs
- * ability to bind a pre-existing global variable
-
* expose the statements in the API? (mostly so they can be stringified?)
* support more arithmetic ops and comparison modes
diff --git a/gcc/jit/internal-api.c b/gcc/jit/internal-api.c
index 573dc67..539ba5e 100644
--- a/gcc/jit/internal-api.c
+++ b/gcc/jit/internal-api.c
@@ -789,6 +789,14 @@ recording::type::get_const ()
}
recording::type *
+recording::type::get_volatile ()
+{
+ recording::type *result = new memento_of_get_volatile (this);
+ m_ctxt->record (result);
+ return result;
+}
+
+recording::type *
recording::memento_of_get_type::dereference ()
{
switch (m_kind)
@@ -916,6 +924,21 @@ recording::memento_of_get_const::make_debug_string ()
"const %s", m_other_type->get_debug_string ());
}
+/* gcc::jit::recording::memento_of_get_volatile:: */
+
+void
+recording::memento_of_get_volatile::replay_into (replayer *)
+{
+ set_playback_obj (m_other_type->playback_type ()->get_volatile ());
+}
+
+recording::string *
+recording::memento_of_get_volatile::make_debug_string ()
+{
+ return string::from_printf (m_ctxt,
+ "volatile %s", m_other_type->get_debug_string ());
+}
+
/* gcc::jit::recording::array_type */
recording::type *
diff --git a/gcc/jit/internal-api.h b/gcc/jit/internal-api.h
index 7114094a..dd760c7 100644
--- a/gcc/jit/internal-api.h
+++ b/gcc/jit/internal-api.h
@@ -466,6 +466,7 @@ class type : public memento
public:
type *get_pointer ();
type *get_const ();
+ type *get_volatile ();
/* Get the type obtained when dereferencing this type.
@@ -479,7 +480,7 @@ public:
/* Is it typesafe to copy to this type from rtype? */
virtual bool accepts_writes_from (type *rtype)
{
-return this == rtype;
+return this == rtype->unqualified ();
}
/* Strip off "const" etc */
@@ -588,6 +589,28 @@ private:
type *m_other_type;
};
+/* Result of "gcc_jit_type_get_volatile". */
+class memento_of_get_
Re: Changing the MIPS ISA for the Loongson 3A from MIPS64 to MIPS64r2
Richard Sandiford writes:
> Andrew Bennett writes:
>> Hi,
>>
>> I have noticed that a patch was placed in bugzilla to do this change, but it
>> does not appear to have been pushed. I was wondering if anyone could comment
>> why this is the case?
>>
>> The bugzilla URL is the following:
>>
>> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57754
>
> Looks OK if it passes testing. We'll need a name and email address for
> the commit though.
Following the discussion on binutils@ I committed the patch as follows.
I slightly tweaked it so that the MIPS64r2 processors stayed in
alphabetical order (which also means that mips-tables.opt doesn't
need to be regenerated).
Sorry again for the delay.
Thanks,
Richard
gcc/
2014-03-04 Heiher
* config/mips/mips-cpus.def (loongson3a): Mark as a MIPS64r2 processor.
* config/mips/mips.h (MIPS_ISA_LEVEL_SPEC): Adjust accordingly.
Index: gcc/config/mips/mips-cpus.def
===
--- gcc/config/mips/mips-cpus.def 2014-01-02 22:16:09.524330756 +
+++ gcc/config/mips/mips-cpus.def 2014-03-04 21:22:32.970580383 +
@@ -145,9 +145,9 @@ MIPS_CPU ("sb1", PROCESSOR_SB1, 64, PTF_
MIPS_CPU ("sb1a", PROCESSOR_SB1A, 64, PTF_AVOID_BRANCHLIKELY)
MIPS_CPU ("sr71000", PROCESSOR_SR71000, 64, PTF_AVOID_BRANCHLIKELY)
MIPS_CPU ("xlr", PROCESSOR_XLR, 64, PTF_AVOID_BRANCHLIKELY)
-MIPS_CPU ("loongson3a", PROCESSOR_LOONGSON_3A, 64, PTF_AVOID_BRANCHLIKELY)
/* MIPS64 Release 2 processors. */
+MIPS_CPU ("loongson3a", PROCESSOR_LOONGSON_3A, 65, PTF_AVOID_BRANCHLIKELY)
MIPS_CPU ("octeon", PROCESSOR_OCTEON, 65, PTF_AVOID_BRANCHLIKELY)
MIPS_CPU ("octeon+", PROCESSOR_OCTEON, 65, PTF_AVOID_BRANCHLIKELY)
MIPS_CPU ("octeon2", PROCESSOR_OCTEON2, 65, PTF_AVOID_BRANCHLIKELY)
Index: gcc/config/mips/mips.h
===
--- gcc/config/mips/mips.h 2014-03-04 21:21:34.930071765 +
+++ gcc/config/mips/mips.h 2014-03-04 21:22:32.972580400 +
@@ -701,8 +701,8 @@ #define MIPS_ISA_LEVEL_SPEC \
%{march=mips32r2|march=m4k|march=4ke*|march=4ksd|march=24k* \
|march=34k*|march=74k*|march=m14k*|march=1004k*: -mips32r2} \
%{march=mips64|march=5k*|march=20k*|march=sb1*|march=sr71000 \
- |march=xlr|march=loongson3a: -mips64} \
- %{march=mips64r2|march=octeon|march=xlp: -mips64r2} \
+ |march=xlr: -mips64} \
+ %{march=mips64r2|march=loongson3a|march=octeon|march=xlp: -mips64r2} \
%{!march=*: -" MULTILIB_ISA_DEFAULT "}}"
/* A spec that infers a -mhard-float or -msoft-float setting from an
[PATCH] Fix PR c++/60393
PR c++/60393
* parser.c (cp_parser_parameter_declaration_clause): Move generic
function template unwinding on error into a move general location, ...
(cp_parser_error): ... here.
PR c++/60393
* g++.dg/cpp1y/pr60393.C: New testcase.
---
gcc/cp/parser.c | 11 +--
gcc/testsuite/g++.dg/cpp1y/pr60393.C | 9 +
2 files changed, 14 insertions(+), 6 deletions(-)
create mode 100644 gcc/testsuite/g++.dg/cpp1y/pr60393.C
diff --git a/gcc/cp/parser.c b/gcc/cp/parser.c
index 8c78262..7feae3d 100644
--- a/gcc/cp/parser.c
+++ b/gcc/cp/parser.c
@@ -2524,6 +2524,10 @@ cp_parser_error (cp_parser* parser, const char* gmsgid)
of the token we just peeked at. */
cp_lexer_set_source_position_from_token (token);
+ /* Unwind generic function template scope if necessary. */
+ if (parser->fully_implicit_function_template_p)
+ finish_fully_implicit_template (parser, /*member_decl_opt=*/0);
+
if (token->type == CPP_PRAGMA)
{
error_at (token->location,
@@ -18208,12 +18212,7 @@ cp_parser_parameter_declaration_clause (cp_parser*
parser)
parameter-declaration-list, then the entire
parameter-declaration-clause is erroneous. */
if (is_error)
-{
- /* Unwind generic function template scope if necessary. */
- if (parser->fully_implicit_function_template_p)
- finish_fully_implicit_template (parser, /*member_decl_opt=*/0);
- return NULL;
-}
+return NULL;
/* Peek at the next token. */
token = cp_lexer_peek_token (parser->lexer);
diff --git a/gcc/testsuite/g++.dg/cpp1y/pr60393.C
b/gcc/testsuite/g++.dg/cpp1y/pr60393.C
new file mode 100644
index 000..38b8b91
--- /dev/null
+++ b/gcc/testsuite/g++.dg/cpp1y/pr60393.C
@@ -0,0 +1,9 @@
+// PR c++/60393
+// { dg-options -std=c++1y }
+
+void (*f)(auto) + 0; // { dg-error "expected" }
+
+struct A
+{
+ int i;
+};
--
1.9.0
[jit] Fixes to type-checking
Committed to branch dmalcolm/jit:
gcc/jit/
* internal-api.c (gcc::jit::recording::memento_of_get_pointer::
accepts_writes_from): Avoid segfaulting when the argument is not
of pointer type.
* internal-api.h (gcc::jit::recording::accepts_writes_from): Add
an assertion.
* libgccjit.c (gcc_jit_context_new_comparison): Strip away const
and volatile when comparing input types.
gcc/testsuite/
* jit.dg/test-error-mismatching-types-in-call.c: New test case,
to ensure that a (struct foo *) vs (struct foo) type error is
gracefully handled.
---
gcc/jit/ChangeLog.jit | 10 +++
gcc/jit/internal-api.c | 7 +-
gcc/jit/internal-api.h | 1 +
gcc/jit/libgccjit.c| 2 +-
gcc/testsuite/ChangeLog.jit| 6 ++
.../jit.dg/test-error-mismatching-types-in-call.c | 80 ++
6 files changed, 104 insertions(+), 2 deletions(-)
create mode 100644 gcc/testsuite/jit.dg/test-error-mismatching-types-in-call.c
diff --git a/gcc/jit/ChangeLog.jit b/gcc/jit/ChangeLog.jit
index 56f7b85..b9172a1 100644
--- a/gcc/jit/ChangeLog.jit
+++ b/gcc/jit/ChangeLog.jit
@@ -1,5 +1,15 @@
2014-03-04 David Malcolm
+ * internal-api.c (gcc::jit::recording::memento_of_get_pointer::
+ accepts_writes_from): Avoid segfaulting when the argument is not
+ of pointer type.
+ * internal-api.h (gcc::jit::recording::accepts_writes_from): Add
+ an assertion.
+ * libgccjit.c (gcc_jit_context_new_comparison): Strip away const
+ and volatile when comparing input types.
+
+2014-03-04 David Malcolm
+
* libgccjit.h (gcc_jit_type_get_volatile): New.
* libgccjit.map (gcc_jit_type_get_volatile): New.
* libgccjit.c (gcc_jit_type_get_volatile): New.
diff --git a/gcc/jit/internal-api.c b/gcc/jit/internal-api.c
index 539ba5e..835aa7f 100644
--- a/gcc/jit/internal-api.c
+++ b/gcc/jit/internal-api.c
@@ -891,9 +891,14 @@ recording::memento_of_get_type::make_debug_string ()
bool
recording::memento_of_get_pointer::accepts_writes_from (type *rtype)
{
+ /* Must be a pointer type: */
+ type *rtype_points_to = rtype->dereference ();
+ if (!rtype_points_to)
+return false;
+
/* It's OK to assign to a (const T *) from a (T *). */
return m_other_type->unqualified ()
-->accepts_writes_from (rtype->dereference ());
+->accepts_writes_from (rtype_points_to);
}
void
diff --git a/gcc/jit/internal-api.h b/gcc/jit/internal-api.h
index dd760c7..5c11085 100644
--- a/gcc/jit/internal-api.h
+++ b/gcc/jit/internal-api.h
@@ -480,6 +480,7 @@ public:
/* Is it typesafe to copy to this type from rtype? */
virtual bool accepts_writes_from (type *rtype)
{
+gcc_assert (rtype);
return this == rtype->unqualified ();
}
diff --git a/gcc/jit/libgccjit.c b/gcc/jit/libgccjit.c
index b4c7d44..75fdfeb 100644
--- a/gcc/jit/libgccjit.c
+++ b/gcc/jit/libgccjit.c
@@ -784,7 +784,7 @@ gcc_jit_context_new_comparison (gcc_jit_context *ctxt,
RETURN_NULL_IF_FAIL (a, ctxt, "NULL a");
RETURN_NULL_IF_FAIL (b, ctxt, "NULL b");
RETURN_NULL_IF_FAIL_PRINTF4 (
-a->get_type () == b->get_type (),
+a->get_type ()->unqualified () == b->get_type ()->unqualified (),
ctxt,
"mismatching types for comparison:"
" a: %s (type: %s) b: %s (type: %s)",
diff --git a/gcc/testsuite/ChangeLog.jit b/gcc/testsuite/ChangeLog.jit
index f0548f4..f66a844 100644
--- a/gcc/testsuite/ChangeLog.jit
+++ b/gcc/testsuite/ChangeLog.jit
@@ -1,5 +1,11 @@
2014-03-04 David Malcolm
+ * jit.dg/test-error-mismatching-types-in-call.c: New test case,
+ to ensure that a (struct foo *) vs (struct foo) type error is
+ gracefully handled.
+
+2014-03-04 David Malcolm
+
* jit.dg/test-volatile.c: New testcase, to exercise
gcc_jit_type_get_volatile, and show a way to work with pre-existing
global variables.
diff --git a/gcc/testsuite/jit.dg/test-error-mismatching-types-in-call.c
b/gcc/testsuite/jit.dg/test-error-mismatching-types-in-call.c
new file mode 100644
index 000..203c4ca
--- /dev/null
+++ b/gcc/testsuite/jit.dg/test-error-mismatching-types-in-call.c
@@ -0,0 +1,80 @@
+#include
+#include
+
+#include "libgccjit.h"
+
+#include "harness.h"
+
+void
+create_code (gcc_jit_context *ctxt, void *user_data)
+{
+ /* Let's try to inject the equivalent of:
+
+ struct foo;
+
+ extern void called_function (struct foo *ptr);
+
+ void
+ test_fn ()
+ {
+ struct foo f;
+called_function (f);
+ }
+
+ and verify that we get a type error (foo * vs foo).
+ */
+ gcc_jit_type *void_type =
+gcc_jit_context_get_type (ctxt, GCC_JIT_TYPE_VOID);
+ gcc_jit_struct *struct_foo =
+gcc_jit_context_new_opaque_struct (ctxt, NULL, "foo");
+ gcc_jit_type *foo_ptr =
+gcc_jit_type_get_pointer (gcc_jit_struc
C++ PATCH for c++/60415 (bogus qualified-id error)
We shouldn't give a hard error about a qualified-id in a function-local
declarator when we're parsing tentatively. Easy enough to fix by
marking the declarator as erroneous when we see the problem.
Tested x86_64-pc-linux-gnu, applying to trunk.
commit a758d04379a1bd0752bdcee9695a6d0d953a59ac
Author: Jason Merrill
Date: Tue Mar 4 11:54:21 2014 -0500
PR c++/60415
PR c++/54359
* parser.c (cp_parser_direct_declarator): Set declarator to
cp_error_declarator on invalid qualified-id.
diff --git a/gcc/cp/parser.c b/gcc/cp/parser.c
index 413ada6..bb7d268 100644
--- a/gcc/cp/parser.c
+++ b/gcc/cp/parser.c
@@ -17456,6 +17456,7 @@ cp_parser_direct_declarator (cp_parser* parser,
/* But declarations with qualified-ids can't appear in a
function. */
cp_parser_error (parser, "qualified-id in declaration");
+ declarator = cp_error_declarator;
break;
}
pushed_scope = push_scope (scope);
diff --git a/gcc/testsuite/g++.dg/parse/ambig8.C b/gcc/testsuite/g++.dg/parse/ambig8.C
new file mode 100644
index 000..016df8a
--- /dev/null
+++ b/gcc/testsuite/g++.dg/parse/ambig8.C
@@ -0,0 +1,15 @@
+// PR c++/60415
+
+namespace b {
+ enum type_t { warning };
+}
+
+struct d {
+ d(b::type_t) { }
+ int operator()() { return 0; }
+};
+
+int main()
+{
+ d(b::warning)() + 1;
+}
C++ PATCH for c++/60417 (explicit ctor vs aggregate init)
In C++11, copy-list-initialization by explicit constructor is an error,
even for the default constructor. But this combined with the change of
aggregate initialization to use {} for any missing initializers means
that well-formed C++03 code becomes ill-formed in C++11. Until the
committee decides what to do about this, let's call the implicit
initializers direct-initialization.
Tested x86_64-pc-linux-gnu, applying to trunk.
commit ea0a530e2164b029909934a1cd4985f8c2bc3b00
Author: Jason Merrill
Date: Tue Mar 4 16:16:36 2014 -0500
PR c++/60417
* typeck2.c (process_init_constructor_record): Set
CONSTRUCTOR_IS_DIRECT_INIT on {} for omitted initializers.
diff --git a/gcc/cp/typeck2.c b/gcc/cp/typeck2.c
index 8877286..3a4caa0 100644
--- a/gcc/cp/typeck2.c
+++ b/gcc/cp/typeck2.c
@@ -1312,6 +1312,9 @@ process_init_constructor_record (tree type, tree init,
for us, so build up TARGET_EXPRs. If the type in question is
a class, just build one up; if it's an array, recurse. */
next = build_constructor (init_list_type_node, NULL);
+ /* Call this direct-initialization pending DR 1518 resolution so
+ that explicit default ctors don't break valid C++03 code. */
+ CONSTRUCTOR_IS_DIRECT_INIT (next) = true;
next = massage_init_elt (TREE_TYPE (field), next, complain);
/* Warn when some struct elements are implicitly initialized. */
diff --git a/gcc/testsuite/g++.dg/init/explicit1.C b/gcc/testsuite/g++.dg/init/explicit1.C
new file mode 100644
index 000..f376df2
--- /dev/null
+++ b/gcc/testsuite/g++.dg/init/explicit1.C
@@ -0,0 +1,9 @@
+// PR c++/60417
+
+struct A { explicit A(int = 0); };
+struct B { A a; };
+
+int main()
+{
+ B b = {};
+}
[wwwdocs] Add "Porting to GCC 4.9" document
I've added an initial "Porting to GCC 4.9" page at
http://gcc.gnu.org/gcc-4.9/porting_to.html
So far it only contains a couple of C++ changes that caused some
failures during mass rebuilds, other additions are welcome.
--- /dev/null 2014-02-20 09:50:47.841935984 +
+++ porting_to.html 2014-03-04 22:25:55.001566175 +
@@ -0,0 +1,114 @@
+
+
+
+Porting to GCC 4.9
+
+
+
+Porting to GCC 4.9
+
+
+The GCC 4.9 release series differs from previous GCC releases in more
+than the usual list of
+http://gcc.gnu.org/gcc-4.9/changes.html";>changes. Some of
+these are a result of bug fixing, and some old behaviors have been
+intentionally changed in order to support new standards, or relaxed
+in standards-conforming ways to facilitate compilation or runtime
+performance. Some of these changes are not visible to the naked eye
+and will not cause problems when updating from older versions.
+
+
+
+However, some of these changes are visible, and can cause grief to
+users porting to GCC 4.9. This document is an effort to identify major
+issues and provide clear solutions in a quick and easily searched
+manner. Additions and suggestions for improvement are welcome.
+
+
+
+
+
+
+
+
+C++ language issues
+
+Shadowing name of exception in catch clause now rejected
+
+ GCC by default no longer accepts code such as:
+
+
+ try {
+// ...
+ } catch (const E& e) {
+int e = 0;
+ }
+
+
+This example now gives the following diagnostic:
+
+
+e.cc:8:9: error: redeclaration of ‘int e’ [-fpermissive]
+ int e = 0;
+ ^
+e.cc:7:21: note: ‘const E& e’ previously declared here
+ } catch (const E& e) {
+ ^
+
+
+
+The standard says the example is ill-formed, so GCC was changed to reject it
+for http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31952";>PR 31952.
+
+To fix the error either rename one of the variables or use an additional
+nested scope for the second one.
+
+
+Default arguments on redeclaration of member function of class template no
rejected
+
+ GCC by default no longer accepts code such as:
+
+
+ template
+ struct A
+ {
+void f(int);
+ };
+
+ template
+ void A::f(int i=0) { }
+
+
+This example now gives the following diagnostic:
+
+
+r.cc:8:21: error: redeclaration of ‘void A::f(int)’ may not have default
arguments [-fpermissive]
+
+
+
+The standard says the example is ill-formed, so GCC was changed to reject it.
+
+To fix the error the default argument must appear when the member function
+is first declared.
+
+
+
+
+Links
+
+
+Matthias Klose,
+ http://gcc.gnu.org/ml/gcc/2014-01/msg00237.html";>Debian test rebuild
on x86_64-linux-gnu with trunk 20140118
+
+
+
+
+
Re: [PATCH] [libgomp] make it possible to use OMP on both sides of a fork
On Tue, Feb 18, 2014 at 8:58 PM, Richard Henderson wrote:
> On 02/16/2014 03:59 PM, Nathaniel Smith wrote:
>> Yes, but the problem is that depending on what the user intends to do
>> after forking, our pthread_atfork handler might help or it might hurt,
>> and we don't know which. Consider these two cases:
>> - fork+exec
>> - fork+continue to use OMP in child
>> The former case is totally POSIX-legal, even when performed at
>> arbitrary places, even when another thread is, say, in the middle of
>> calling malloc().
>
> Point well taken.
Hi all,
I guess this patch has gotten all the feedback that it's getting. Any
interest in committing it? :-) I don't have commit access.
2014-02-12 Nathaniel J. Smith
* team.c (gomp_free_pool_helper): Move per-thread cleanup to main
thread.
(gomp_free_thread): Delegate implementation to...
(gomp_free_thread_pool): ...this new function. Like old
gomp_free_thread, but does per-thread cleanup, and has option to
skip everything that involves interacting with actual threads,
which is useful when called after fork.
(gomp_after_fork_callback): New function.
(gomp_team_start): Register atfork handler, and check for fork on
entry.
Cheers,
-n
--
Nathaniel J. Smith
Postdoctoral researcher - Informatics - University of Edinburgh
http://vorpus.org
Index: team.c
===
--- team.c (revision 207398)
+++ team.c (working copy)
@@ -28,6 +28,7 @@
#include "libgomp.h"
#include
#include
+#include
/* This attribute contains PTHREAD_CREATE_DETACHED. */
pthread_attr_t gomp_thread_attr;
@@ -43,6 +44,8 @@ __thread struct gomp_thread gomp_tls_data;
pthread_key_t gomp_tls_key;
#endif
+/* This is to enable best-effort cleanup after fork. */
+static bool gomp_we_are_forked;
/* This structure is used to communicate across pthread_create. */
@@ -204,42 +207,41 @@ static struct gomp_thread_pool *gomp_new_thread_po
return pool;
}
+/* Free a thread pool and release its threads. */
+
static void
gomp_free_pool_helper (void *thread_pool)
{
- struct gomp_thread *thr = gomp_thread ();
struct gomp_thread_pool *pool
= (struct gomp_thread_pool *) thread_pool;
gomp_barrier_wait_last (&pool->threads_dock);
- gomp_sem_destroy (&thr->release);
- thr->thread_pool = NULL;
- thr->task = NULL;
pthread_exit (NULL);
}
-/* Free a thread pool and release its threads. */
-
-void
-gomp_free_thread (void *arg __attribute__((unused)))
+static void
+gomp_free_thread_pool (bool threads_are_running)
{
struct gomp_thread *thr = gomp_thread ();
struct gomp_thread_pool *pool = thr->thread_pool;
if (pool)
{
+ int i;
if (pool->threads_used > 0)
{
- int i;
- for (i = 1; i < pool->threads_used; i++)
+ if (threads_are_running)
{
- struct gomp_thread *nthr = pool->threads[i];
- nthr->fn = gomp_free_pool_helper;
- nthr->data = pool;
+ for (i = 1; i < pool->threads_used; i++)
+ {
+ struct gomp_thread *nthr = pool->threads[i];
+ nthr->fn = gomp_free_pool_helper;
+ nthr->data = pool;
+ }
+ /* This barrier undocks threads docked on pool->threads_dock. */
+ gomp_barrier_wait (&pool->threads_dock);
+ /* And this waits till all threads have called
+gomp_barrier_wait_last in gomp_free_pool_helper. */
+ gomp_barrier_wait (&pool->threads_dock);
}
- /* This barrier undocks threads docked on pool->threads_dock. */
- gomp_barrier_wait (&pool->threads_dock);
- /* And this waits till all threads have called gomp_barrier_wait_last
-in gomp_free_pool_helper. */
- gomp_barrier_wait (&pool->threads_dock);
/* Now it is safe to destroy the barrier and free the pool. */
gomp_barrier_destroy (&pool->threads_dock);
@@ -251,6 +253,14 @@ gomp_free_pool_helper (void *thread_pool)
gomp_managed_threads -= pool->threads_used - 1L;
gomp_mutex_unlock (&gomp_managed_threads_lock);
#endif
+ /* Clean up thread objects */
+ for (i = 1; i < pool->threads_used; i++)
+ {
+ struct gomp_thread *nthr = pool->threads[i];
+ gomp_sem_destroy (&nthr->release);
+ nthr->thread_pool = NULL;
+ nthr->task = NULL;
+ }
}
free (pool->threads);
if (pool->last_team)
@@ -266,6 +276,58 @@ gomp_free_pool_helper (void *thread_pool)
}
}
+/* This is called whenever a thread exits which has a non-NULL value for
+ gomp_thread_destructor. In practice, the only thread for which this occurs
+ is the one which created the thread pool.
+*/
+void
+gomp_free_thread (void *arg __attribute__((unused)))
+{
+ gomp_free_thread_pool
Re: [PATCH 3/4] [GOMP4] [Fortran] OpenACC 1.0+ support in fortran front-end
Ilmir Usmanov wrote: OpenACC 1.0 fortran FE support -- translation to GENERIC. --- a/gcc/fortran/trans.c +++ b/gcc/fortran/trans.c @@ -1850,6 +1850,21 @@ trans_code (gfc_code * code, tree cond) ... + case EXEC_OACC_PARALLEL: + case EXEC_OACC_PARALLEL_LOOP: +case EXEC_OACC_ENTER_DATA: +case EXEC_OACC_EXIT_DATA: + res = gfc_trans_oacc_directive (code); + break; There is something wrong with the indention. Otherwise, it looks good to me. Tobias
Re: [PATCH 4/4] [GOMP4] [Fortran] OpenACC 1.0+ support in fortran front-end
Ilmir Usmanov wrote: OpenACC 1.0 fortran FE support -- tests. I have browsed through those patches and haven't spotted anything; however, I have not carefully checked against the OpenACC spec nor really checked every patch. But at a glance, it looks okay. Tobias gcc/testsuite/gfortran.dg/goacc/ * assumed.f95: New test * branch.f95: Likewise * coarray.f95: Likewise * continuation-free-form.f95: Likewise * cray.f95: Likewise * critical.f95: Likewise * data-clauses.f95: Likewise * data-tree.f95: Likewise * declare-1.f95: Likewise * enter-exit-data.f95: Likewise * goacc.exp: Likewise * host_data-tree.f95: Likewise * if.f95: Likewise * kernels-tree.f95: Likewise * list.f95: Likewise * literal.f95: Likewise * loop-1.f95: Likewise * loop-2.f95: Likewise * loop-3.f95: Likewise * omp.f95: Likewise * parallel-kernels-clauses.f95: Likewise * parallel-kernels-regions.f95: Likewise * parallel-tree.f95: Likewise * parameter.f95: Likewise * pure-elemental-procedures.f95: Likewise * reduction.f95: Likewise * sentinel-free-form.f95: Likewise * several-directives.f95: Likewise * sie.f95: Likewise
Re: [PATCH GCC]Allow cfgcleanup to remove forwarder loop preheaders and latches
On Sat, Mar 1, 2014 at 2:19 AM, Richard Biener
wrote:
> On Fri, Feb 28, 2014 at 7:23 PM, H.J. Lu wrote:
>> On Fri, Feb 28, 2014 at 9:42 AM, H.J. Lu wrote:
>>> On Fri, Feb 28, 2014 at 9:25 AM, H.J. Lu wrote:
On Fri, Feb 28, 2014 at 8:11 AM, H.J. Lu wrote:
> On Fri, Feb 28, 2014 at 2:09 AM, Richard Biener
> wrote:
>> On Fri, Feb 28, 2014 at 10:09 AM, Richard Biener
>> wrote:
>>> On Fri, Feb 28, 2014 at 1:52 AM, H.J. Lu wrote:
On Mon, Feb 24, 2014 at 9:12 PM, bin.cheng wrote:
> Hi,
> This patch is to fix regression reported in PR60280 by removing
> forward loop
> headers/latches in cfg cleanup if possible. Several tests are broken
> by
> this change since cfg cleanup is shared by all optimizers. Some
> tests has
> already been fixed by recent patches, I went through and fixed the
> others.
> One case needs to be clarified is "gcc.dg/tree-prof/update-loopch.c".
> When
> GCC removing a basic block, it checks profile information by calling
> check_bb_profile after redirecting incoming edges of the bb. This
> certainly
> results in warnings about invalid profile information and causes the
> case to
> fail. I will send a patch to skip checking profile information for a
> removing basic block in stage 1 if it sounds reasonable. For now I
> just
> twisted the case itself.
>
> Bootstrap and tested on x86_64 and arm_a15.
>
> Is it OK?
>
>
> 2014-02-25 Bin Cheng
>
> PR target/60280
> * tree-cfgcleanup.c (tree_forwarder_block_p): Protect loop
> preheaders and latches only if requested. Fix latch if it
> is removed.
> * tree-ssa-dom.c (tree_ssa_dominator_optimize): Set
> LOOPS_HAVE_PREHEADERS.
>
This change:
if (dest->loop_father->header == dest)
- return false;
+ {
+if (loops_state_satisfies_p (LOOPS_HAVE_PREHEADERS)
+&& bb->loop_father->header != dest)
+ return false;
+
+if (loops_state_satisfies_p (LOOPS_HAVE_SIMPLE_LATCHES)
+&& bb->loop_father->header == dest)
+ return false;
+ }
}
miscompiled 435.gromacs in SPEC CPU 2006 on x32 with
-O3 -funroll-loops -ffast-math -fwhole-program -flto=jobserver
-fuse-linker-plugin
This patch changes loops without LOOPS_HAVE_PREHEADERS
nor LOOPS_HAVE_SIMPLE_LATCHES from returning false to returning
true. I don't have a small testcase. But this patch:
diff --git a/gcc/tree-cfgcleanup.c b/gcc/tree-cfgcleanup.c
index b5c384b..2ba673c 100644
--- a/gcc/tree-cfgcleanup.c
+++ b/gcc/tree-cfgcleanup.c
@@ -323,6 +323,10 @@ tree_forwarder_block_p (basic_block bb, bool
phi_wanted)
if (loops_state_satisfies_p (LOOPS_HAVE_SIMPLE_LATCHES)
&& bb->loop_father->header == dest)
return false;
+
+if (!loops_state_satisfies_p (LOOPS_HAVE_PREHEADERS)
+&& !loops_state_satisfies_p (LOOPS_HAVE_SIMPLE_LATCHES))
+ return false;
}
}
fixes the regression. Does it make any senses?
>>>
>>> I think the preheader test isn't fully correct (bb may be in an inner
>>> loop
>>> for example). So a more conservative variant would be
>>>
>>> Index: gcc/tree-cfgcleanup.c
>>> ===
>>> --- gcc/tree-cfgcleanup.c (revision 208169)
>>> +++ gcc/tree-cfgcleanup.c (working copy)
>>> @@ -316,13 +316,13 @@ tree_forwarder_block_p (basic_block bb,
>>>/* Protect loop preheaders and latches if requested. */
>>>if (dest->loop_father->header == dest)
>>> {
>>> - if (loops_state_satisfies_p (LOOPS_HAVE_PREHEADERS)
>>> - && bb->loop_father->header != dest)
>>> - return false;
>>> -
>>> - if (loops_state_satisfies_p (LOOPS_HAVE_SIMPLE_LATCHES)
>>> - && bb->loop_father->header == dest)
>>> - return false;
>>> + if (bb->loop_father == dest->loop_father)
>>> + return !loops_state_satisfies_p (LOOPS_HAVE_SIMPLE_LATCHES);
>>> + else if (bb->loop_father == loop_outer (dest->loop_father))
>>> + return !loops_state_satisfies_p (LOOPS_HAVE_PREHEADERS);
>>> + /* Always preserve other edges into loop headers that are
>>> +not simple latches or preheaders. */
>>> + return false
How my codes comply with gcc code formatting?
Hi, I have summited a patch in this ml.But the difficult part may be the code formatting.I am using vim as my editor. -- Regards lin zuojian.
Patch RFC: Use internal qsort function in libbacktrace
The GNU glibc qsort function will call malloc in some cases. That makes it unsuitable for libbacktrace, which is intended to work when called from a signal handler. This patch changes libbacktrace to use an internal qsort function. I'm posting this for comments in case anybody sees anything wrong with the implementation. I'll commit it in a day or two if I don't hear anything. Bootstrapped and ran libbacktrace and Go tests on x86_64-unknown-linux-gnu. Ian 2014-03-04 Ian Lance Taylor * sort.c: New file. * stest.c: New file. * internal.h (backtrace_qsort): Declare. * dwarf.c (read_abbrevs): Call backtrace_qsort instead of qsort. (read_line_info, read_function_entry): Likewise. (read_function_info, build_dwarf_data): Likewise. * elf.c (elf_initialize_syminfo): Likewise. * Makefile.am (libbacktrace_la_SOURCES): Add sort.c. (stest_SOURCES, stest_LDADD): Define. (check_PROGRAMS): Add stest. Index: dwarf.c === --- dwarf.c (revision 208327) +++ dwarf.c (working copy) @@ -1134,8 +1134,8 @@ read_abbrevs (struct backtrace_state *st ++num_abbrevs; } - qsort (abbrevs->abbrevs, abbrevs->num_abbrevs, sizeof (struct abbrev), - abbrev_compare); + backtrace_qsort (abbrevs->abbrevs, abbrevs->num_abbrevs, + sizeof (struct abbrev), abbrev_compare); return 1; @@ -2016,7 +2016,7 @@ read_line_info (struct backtrace_state * goto fail; ln = (struct line *) vec.vec.base; - qsort (ln, vec.count, sizeof (struct line), line_compare); + backtrace_qsort (ln, vec.count, sizeof (struct line), line_compare); *lines = ln; *lines_count = vec.count; @@ -2476,9 +2476,9 @@ read_function_entry (struct backtrace_st return 0; faddrs = (struct function_addrs *) fvec.vec.base; - qsort (faddrs, fvec.count, - sizeof (struct function_addrs), - function_addrs_compare); + backtrace_qsort (faddrs, fvec.count, + sizeof (struct function_addrs), + function_addrs_compare); function->function_addrs = faddrs; function->function_addrs_count = fvec.count; @@ -2555,8 +2555,8 @@ read_function_info (struct backtrace_sta fvec->count = 0; } - qsort (addrs, addrs_count, sizeof (struct function_addrs), - function_addrs_compare); + backtrace_qsort (addrs, addrs_count, sizeof (struct function_addrs), + function_addrs_compare); *ret_addrs = addrs; *ret_addrs_count = addrs_count; @@ -2923,7 +2923,8 @@ build_dwarf_data (struct backtrace_state return NULL; addrs = (struct unit_addrs *) addrs_vec.vec.base; addrs_count = addrs_vec.count; - qsort (addrs, addrs_count, sizeof (struct unit_addrs), unit_addrs_compare); + backtrace_qsort (addrs, addrs_count, sizeof (struct unit_addrs), + unit_addrs_compare); fdata = ((struct dwarf_data *) backtrace_alloc (state, sizeof (struct dwarf_data), Index: elf.c === --- elf.c (revision 208327) +++ elf.c (working copy) @@ -407,8 +407,8 @@ elf_initialize_syminfo (struct backtrace ++j; } - qsort (elf_symbols, elf_symbol_count, sizeof (struct elf_symbol), - elf_symbol_compare); + backtrace_qsort (elf_symbols, elf_symbol_count, sizeof (struct elf_symbol), + elf_symbol_compare); sdata->next = NULL; sdata->symbols = elf_symbols; Index: internal.h === --- internal.h (revision 208327) +++ internal.h (working copy) @@ -196,6 +196,11 @@ extern int backtrace_close (int descript backtrace_error_callback error_callback, void *data); +/* Sort without using memory. */ + +extern void backtrace_qsort (void *base, size_t count, size_t size, + int (*compar) (const void *, const void *)); + /* Allocate memory. This is like malloc. */ extern void *backtrace_alloc (struct backtrace_state *state, size_t size, Index: sort.c === --- sort.c (revision 0) +++ sort.c (revision 0) @@ -0,0 +1,87 @@ +/* sort.c -- Sort without allocating memory + Copyright (C) 2012-2014 Free Software Foundation, Inc. + Written by Ian Lance Taylor, Google. + +Redistribution and use in source and binary forms, with or without +modification, are permitted provided that the following conditions are +met: + +(1) Redistributions of source code must retain the above copyright +notice, this list of conditions and the following disclaimer. + +(2) Redistributions in binary form must reproduce the above copyright +notice, this list of conditions and the following disclaimer in +the documentation and/or other materials provided with the +distribution. + +(3) The name of the author may not be used to +endorse or promote products derived from this software without +specific prior written permission. + +THIS
Re: Patch RFC: Use internal qsort function in libbacktrace
On Tue, Mar 4, 2014 at 10:34 PM, Ian Lance Taylor wrote: > The GNU glibc qsort function will call malloc in some cases. That makes > it unsuitable for libbacktrace, which is intended to work when called > from a signal handler. This patch changes libbacktrace to use an > internal qsort function. > > I'm posting this for comments in case anybody sees anything wrong with > the implementation. I'll commit it in a day or two if I don't hear > anything. The first line of stest.c mentions "btest.c" instead of "stest.c": /* btest.c -- Test for libbacktrace library
Re: Patch RFC: Use internal qsort function in libbacktrace
On Tue, Mar 4, 2014 at 8:03 PM, Patrick Palka wrote: > On Tue, Mar 4, 2014 at 10:34 PM, Ian Lance Taylor wrote: >> The GNU glibc qsort function will call malloc in some cases. That makes >> it unsuitable for libbacktrace, which is intended to work when called >> from a signal handler. This patch changes libbacktrace to use an >> internal qsort function. >> >> I'm posting this for comments in case anybody sees anything wrong with >> the implementation. I'll commit it in a day or two if I don't hear >> anything. > > The first line of stest.c mentions "btest.c" instead of "stest.c": > > /* btest.c -- Test for libbacktrace library Thanks, fixed to read /* stest.c -- Test for libbacktrace internal sort function Ian
Re: How my codes comply with gcc code formatting?
On Wed, Mar 05, 2014 at 11:31:59AM +0800, lin zuojian wrote: > Hi, > I have summited a patch in this ml.But the difficult part may be the > code formatting.I am using vim as my editor. I'm not sure what you asking for here. But to learn how to format your code, I think just look at the GCC source code and model your code after that. Marek
Re: [PATCH] Use the LTO linker plugin by default
Am 04.03.2014 13:30, schrieb Markus Trippelsdorf: > What is missing is a big fat warning in > http://gcc.gnu.org/gcc-4.9/changes.html that one should use the gcc > binutils wrappers (gcc-ar, etc.) when building projects with LTO. Is this enough? Or should the autoconf macros changed to look for these binaries if they exist? AC_PROG_AR, etc, Matthias
Re: How my codes comply with gcc code formatting?
On Wed, Mar 05, 2014 at 07:28:35AM +0100, Marek Polacek wrote: > On Wed, Mar 05, 2014 at 11:31:59AM +0800, lin zuojian wrote: > > Hi, > > I have summited a patch in this ml.But the difficult part may be the > > code formatting.I am using vim as my editor. > > I'm not sure what you asking for here. But to learn how to format > your code, I think just look at the GCC source code and model your > code after that. > > Marek Hi Marek, I am not understanding the standard.For example,should I use \t instead of space?Should I use 4 spaces as indent or 2? -- Regards lin zuojian
Re: How my codes comply with gcc code formatting?
I'm not sure what you asking for here. But to learn how to format your code, I think just look at the GCC source code and model your code after that. I am not understanding the standard.For example,should I use \t instead of space?Should I use 4 spaces as indent or 2? My understanding is that GCC coding guidelines (http://gcc.gnu.org/contribute.html#standards) don't require particular indentation style so you should probably stick to a style used in particular file (or even particular function). That said GCC's lack of indentation standard is IMHO rather unfortunate. -Y
Re: [PATCH] Use the LTO linker plugin by default
> Am 04.03.2014 13:30, schrieb Markus Trippelsdorf: > > What is missing is a big fat warning in > > http://gcc.gnu.org/gcc-4.9/changes.html that one should use the gcc > > binutils wrappers (gcc-ar, etc.) when building projects with LTO. > > Is this enough? Or should the autoconf macros changed to look for these > binaries > if they exist? AC_PROG_AR, etc, Help from autoconf side would be good (it needs to know that gcc is used for compilation) I am not big fan of those wrappers, I think binutils should be able to auto-load the plugin of system installed compilers http://gcc.gnu.org/ml/gcc/2014-02/msg00128.html But osmeone needs to implement it, too... Also binutils can certainly be modified to output sane warning/error message when they see slim GCC files (those are easily detectable) and have no plugin. Honza > > Matthias
Re: How my codes comply with gcc code formatting?
On Wed, Mar 05, 2014 at 10:56:39AM +0400, Yury Gribov wrote: > >I'm not sure what you asking for here. But to learn how to format > >your code, I think just look at the GCC source code and model your > >code after that. > > > >I am not understanding the standard.For example,should I use \t > >instead of space?Should I use 4 spaces as indent or 2? > > My understanding is that GCC coding guidelines > (http://gcc.gnu.org/contribute.html#standards) > don't require particular indentation style so you should probably > stick to a style > used in particular file (or even particular function). > > That said GCC's lack of indentation standard is IMHO rather unfortunate. That is not true. The indentation style is: http://www.gnu.org/prep/standards/standards.html#Formatting (though, some parts of gcc, e.g. libstdc++, use slightly different indentation/formatting style). The above also mentions particular options for GNU indent which set various rules. -i2 means indentation is by 2 spaces, and the lack of -nut and -tsN options means that tab size is 8 columns and that in the indentation every 8 spaces should be replaced by a tab. Jakub
Re: How my codes comply with gcc code formatting?
That is not true. The indentation style is: http://www.gnu.org/prep/standards/standards.html#Formatting ... The above also mentions particular options for GNU indent which set various rules. Ah, good to know. So, are contributors expected to run indent on their changes before sending patches? Or maybe add some checks to check_GNU_style.sh? -Y
Re: How my codes comply with gcc code formatting?
On Wed, Mar 05, 2014 at 11:29:07AM +0400, Yury Gribov wrote: > >That is not true. The indentation style is: > >http://www.gnu.org/prep/standards/standards.html#Formatting > >... > >The above also mentions particular options > >for GNU indent which set various rules. > > Ah, good to know. So, are contributors expected to run indent on > their changes before sending patches? Or maybe add some checks to > check_GNU_style.sh? > > -Y Yeah.Very good if there is such a script.
