[committed] Fix a typo in translatable string (PR translation/79018)
Hi! Committed as obvious to trunk. 2017-01-07 Jakub Jelinek PR translation/79018 * params.def (PARAM_MAX_STORES_TO_MERGE): Add missing space between the and store. --- gcc/params.def.jj 2017-01-01 12:45:36.0 +0100 +++ gcc/params.def 2017-01-07 09:35:05.371159337 +0100 @@ -1102,7 +1102,7 @@ DEFPARAM (PARAM_STORE_MERGING_ALLOW_UNAL DEFPARAM (PARAM_MAX_STORES_TO_MERGE, "max-stores-to-merge", - "Maximum number of constant stores to merge in the" + "Maximum number of constant stores to merge in the " "store merging pass", 64, 2, 0) Jakub
Re: [PATCH] Fix lto-bootstrap (PR bootstrap/79003).
On January 6, 2017 8:00:21 PM GMT+01:00, Jakub Jelinek wrote: >On Fri, Jan 06, 2017 at 05:58:05PM +0100, Christophe Lyon wrote: >> > Trying now: >> > >> > 2017-01-06 Jakub Jelinek >> > >> > * Makefile.in (CFLAGS, CPPFLAGS, LDFLAGS): Remove -fno-lto. >> > (NOLTO_FLAGS): New variable. >> > (ALL_CFLAGS): Use it. >> > * configure.ac (nolto_flags): New ACX_PROG_CC_WARNING_OPTS, >> > check for whether -fno-lto works. >> > * configure: Regenerated. >> > >> OK thanks for the prompt fix, I'll let you know if it doesn't work. > >The patch passed bootstrap (non- bootstrap-lto) on x86_64-linux and >i686-linux and I see -fno-lto being used everywhere I expected (with >bootstrap compiler that does support -fno-lto). >Ok for trunk, if it works even for Christophe? OK. Richard. > Jakub
Re: [PATCH] Outer vs. inner loop ifcvt (PR tree-optimization/78899)
On January 6, 2017 7:56:10 PM GMT+01:00, Jakub Jelinek wrote:
>Hi!
>
>If-conversion can't easily predict whether outer loop vectorization
>will be
>successful or not. In GCC 6, we'd version and guard with
>LOOP_VECTORIZED
>only the inner loop, which is beneficial if the outer loop
>vectorization
>isn't successful, but inner loop vectorization is.
>This changed last year, and now we sometimes version the outer loop
>instead.
>The problem with that is that it regresses according to the PR some
>important benchmarks where the outer loop can't be really vectorized
>but
>if-conv doesn't know that, but because the inner loop needs masked
>loads/stores, the inner loop isn't vectorized either.
>
>The following patch tweaks tree-if-conv.c so that when it wants to
>version
>an outer loop, it actually transforms:
> loop1
> loop2
>into:
> if (LOOP_VECTORIZED (1, 3))
> {
> loop1
> loop2
> }
> else
> loop3 (copy of loop1)
> if (LOOP_VECTORIZED (4, 5))
> loop4 (copy of loop2)
> else
> loop5 (copy of loop4)
Huh. Why isn't the else case equal to the if case for the vectorizer? That
is, we have the inner loop if-converted And thus for the if case either outer
or inner loop vectorization should be possible.
So - why doesn't it work that way?
Richard.
>and tweaks the vectorizer, so that it attempts to vectorize always the
>outer loop (i.e. loop1) in this case first. If that is successful,
>it marks loop4 as non-vectorizable and folds the latter
>LOOP_VECTORIZED,
>so that in the copies of the scalar loop the inner loop isn't
>vectorized.
>If outer loop vectorization fails, loop1/loop2 are thrown away and we
>get
>loop3 non-vectorized with either loop4 vectorized, or if even that
>fails,
>with loop5 inside of it.
>
>I think vectorization in the scalar loop of the outer loop is code size
>waste, it will be just very small number of iterations of the outer
>loop.
>If you think we should vectorize even there, we'd need other changes
>- handle LOOP_VECTORIZED ifn during copying of loops in
>tree-vect-loop-manip.c and ensure we'd run the vectorizer even on the
>copied loops - right now the vectorizer runs only on the loops created
>before vectorization starts (except for epilogue vectorization).
>
>Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?
>
>2017-01-06 Jakub Jelinek
>
> PR tree-optimization/78899
> * tree-if-conv.c (version_loop_for_if_conversion): Instead of
> returning bool return struct loop *, NULL for failure and the new
> loop on success.
> (versionable_outer_loop_p): Don't version outer loop if it has
> dont_vectorized bit set.
> (tree_if_conversion): When versioning outer loop, ensure
> tree_if_conversion is performed also on the inner loop of the
> non-vectorizable outer loop copy.
> * tree-vectorizer.c (set_uid_loop_bbs): Formatting fix. Fold
> LOOP_VECTORIZED in inner loop of the scalar outer loop and
> prevent vectorization of it.
> (vectorize_loops): For outer + inner LOOP_VECTORIZED, ensure
> the outer loop vectorization of the non-scalar version is attempted
> before vectorization of the inner loop in scalar version.
> * tree-vect-loop-manip.c (rename_variables_in_bb): If outer_loop
> has 2 inner loops, rename also on edges from bb whose single pred
> is outer_loop->header. Fix typo in function comment.
>
> * gcc.target/i386/pr78899.c: New test.
> * gcc.dg/pr71077.c: New test.
> * gcc.dg/gomp/pr68128-1.c: Adjust allowed number of vectorized
> loops.
>
>--- gcc/tree-if-conv.c.jj 2017-01-04 18:12:50.180878924 +0100
>+++ gcc/tree-if-conv.c 2017-01-06 09:24:08.410557481 +0100
>@@ -2535,7 +2535,7 @@ combine_blocks (struct loop *loop)
>loop to execute. The vectorizer pass will fold this
>internal call into either true or false. */
>
>-static bool
>+static struct loop *
> version_loop_for_if_conversion (struct loop *loop)
> {
> basic_block cond_bb;
>@@ -2566,7 +2566,7 @@ version_loop_for_if_conversion (struct l
> ifc_bbs[i]->aux = saved_preds[i];
>
> if (new_loop == NULL)
>-return false;
>+return NULL;
>
> new_loop->dont_vectorize = true;
> new_loop->force_vectorize = false;
>@@ -2574,7 +2574,7 @@ version_loop_for_if_conversion (struct l
>gimple_call_set_arg (g, 1, build_int_cst (integer_type_node,
>new_loop->num));
> gsi_insert_before (&gsi, g, GSI_SAME_STMT);
> update_ssa (TODO_update_ssa);
>- return true;
>+ return new_loop;
> }
>
> /* Return true when LOOP satisfies the follow conditions that will
>@@ -2594,6 +2594,7 @@ static bool
> versionable_outer_loop_p (struct loop *loop)
> {
> if (!loop_outer (loop)
>+ || loop->dont_vectorize
> || !loop->inner
> || loop->inner->next
> || !single_exi
Re: Ping! Re: [PATCH, Fortran, pr78781, v1] [7 Regression] [Coarray] ICE in gfc_deallocate_scalar_with_status, at fortran/trans.c:1588
I have this patch in my working tree and it works as expected. > Also fixes pr78935. Confirmed. Thanks for the patch, Dominique
Re: [PR tree-optimization/71691] Fix unswitching in presence of maybe-undef SSA_NAMEs (take 2)
On 01/04/2017 07:11 AM, Richard Biener wrote:
On Tue, Jan 3, 2017 at 6:36 PM, Aldy Hernandez wrote:
On 12/20/2016 09:16 AM, Richard Biener wrote:
On Fri, Dec 16, 2016 at 3:41 PM, Aldy Hernandez wrote:
Hi folks.
This is a follow-up on Jeff and Richi's interaction on the aforementioned
PR
here:
https://gcc.gnu.org/ml/gcc-patches/2016-08/msg01397.html
I decided to explore the idea of analyzing may-undefness on-demand, which
actually looks rather cheap.
BTW, I don't understand why we don't have auto_bitmap's, as we already
have
auto_sbitmap's. I've implemented the former based on auto_sbitmap's code
we
already have.
The attached patch fixes the bug without introducing any regressions.
I also tested the patch by compiling 242 .ii files with -O3. These were
gathered from a stage1 build with -save-temps. There is a slight time
degradation of 4 seconds within 27 minutes of user time:
tainted:26:52
orig: 26:48
This was the average aggregate time of two runs compiling all 242 .ii
files.
IMO, this looks reasonable. It is after all, -O3.Is it acceptable?
+ while (!worklist.is_empty ())
+{
+ name = worklist.pop ();
+ gcc_assert (TREE_CODE (name) == SSA_NAME);
+
+ if (ssa_undefined_value_p (name, true))
+ return true;
+
+ bitmap_set_bit (visited_ssa, SSA_NAME_VERSION (name));
it should be already set as we use visited_ssa as "was it ever on the
worklist",
so maybe renaming it would be a good thing as well.
I don't understand what you would prefer here.
Set the bit when you put name on the worklist (and do not do that if the
bit is set). Thus simply remove the above and add a bitmap_set_bit
for the initial name you put on the worklist.
+ if (TREE_CODE (name) == SSA_NAME)
+ {
+ /* If an SSA has already been seen, this may be a loop.
+Fail conservatively. */
+ if (bitmap_bit_p (visited_ssa, SSA_NAME_VERSION (name)))
+ return false;
so to me "conservative" is returning true, not false.
OK
+ bitmap_set_bit (visited_ssa, SSA_NAME_VERSION (name));
+ worklist.safe_push (name);
but for loops we can just continue and ignore this use. And
bitmap_set_bit
returns whether it set a bit, thus
if (bitmap_set_bit (visited_ssa, SSA_NAME_VERSION (name)))
worklist.safe_push (name);
should work?
Fixed.
+ /* Check that any SSA names used to define NAME is also fully
+defined. */
+ use_operand_p use_p;
+ ssa_op_iter iter;
+ FOR_EACH_SSA_USE_OPERAND (use_p, def, iter, SSA_OP_USE)
+ {
+ name = USE_FROM_PTR (use_p);
+ if (TREE_CODE (name) == SSA_NAME)
always true.
+ {
+ /* If an SSA has already been seen, this may be a loop.
+Fail conservatively. */
+ if (bitmap_bit_p (visited_ssa, SSA_NAME_VERSION (name)))
+ return false;
+ bitmap_set_bit (visited_ssa, SSA_NAME_VERSION (name));
+ worklist.safe_push (name);
See above.
In principle the thing is sound but I'd like to be able to pass in a
bitmap of
known maybe-undefined/must-defined SSA names to have a cache for
multiple invocations from within a pass (like this unswitching case).
Done, though bitmaps are now calculated as part of the instantiation.
Also once you hit defs that are in a post-dominated region of the loop
entry
you can treat them as not undefined (as their use invokes undefined
behavior). This is also how you treat function parameters (well,
ssa_undefined_value_p does), where the call site invokes undefined
behavior
when passing in undefined values. So we need an extra parameter
specifying
the post-dominance region.
Done.
You do not handle memory or calls conservatively which means the existing
testcase only needs some obfuscation to become a problem again. To fix
that before /* Check that any SSA names used to define NAME is also fully
defined. */ bail out conservatively, like
if (! is_gimple_assign (def)
|| gimple_assign_single_p (def))
return true;
As I asked previously, I understand the !is_gimple_assign, which will skip
over GIMPLE_CALLs setting a value, but the "gimple_assign_single_p(def) ==
true"??
Won't this last one bail on things like e.3_7 = e, or x_77 = y_88? Don't we
want to follow up the def chain precisely on these?
The attached implementation uses a cache, and a pre-computed post-dominance
region. A previous incantation of this patch (sans the post-dominance
stuff) had performance within the noise of the previous implementation.
I am testing again, and will do some performance comparisons in a bit, but
for now-- are we on the same page here? Is this what you wanted?
+ /* DEFs in the post-dominated region of the loop entry invoke
+undefined behavior. Adding any use won't make things any
+
[Patch] PR71017 - libgcc/config/i386/cpuinfo.c:346:17: runtime error: left shift of 1 by 31 places cannot be represented in type 'int'
The following patch fixes errors of the kind libgcc/config/i386/cpuinfo.c:260:17: runtime error: left shift of 1 by 31 places cannot be represented in type ‘int' 2017-01-07 Dominique d'Humieres PR target/71017 * config/i386/cpuid.h: Fix undefined behavior. --- ../_clean/gcc/config/i386/cpuid.h 2017-01-01 17:39:04.0 +0100 +++ gcc/config/i386/cpuid.h 2017-01-05 15:22:31.0 +0100 @@ -91,7 +91,7 @@ #define bit_AVX512CD (1 << 28) #define bit_SHA(1 << 29) #define bit_AVX512BW (1 << 30) -#define bit_AVX512VL (1 << 31) +#define bit_AVX512VL (1u << 31) /* %ecx */ #define bit_PREFETCHWT1 (1 << 0) Is it OK for trunk/branches? TIA Dominique
Re: Ping! Re: [PATCH, Fortran, pr78781, v1] [7 Regression] [Coarray] ICE in gfc_deallocate_scalar_with_status, at fortran/trans.c:1588
Hi Andre and Dominique, Apart from s/allows there allocation/allows their allocation/ this is OK for trunk. Given the scale of the patch, can this really be a regression? Thanks Paul On 7 January 2017 at 13:47, Dominique d'Humières wrote: > I have this patch in my working tree and it works as expected. > >> Also fixes pr78935. > > Confirmed. > > Thanks for the patch, > > Dominique > -- "If you can't explain it simply, you don't understand it well enough" - Albert Einstein
Re: Ping! Re: [PATCH, Fortran, pr78781, v1] [7 Regression] [Coarray] ICE in gfc_deallocate_scalar_with_status, at fortran/trans.c:1588
Hi Paul, you are right. The patch implements the feature of pointer components in derived type coarrays and was motivated by 78781. The "regression" (like so many) is that without the patch the compiler ICEs while it errored before. I have given up to complain everytime when a pr is called a regression instead of a feature request. Regards, Andre On Sat, 7 Jan 2017 15:06:20 +0100 Paul Richard Thomas wrote: > Hi Andre and Dominique, > > Apart from s/allows there allocation/allows their allocation/ this is > OK for trunk. > > Given the scale of the patch, can this really be a regression? > > Thanks > > Paul > > > On 7 January 2017 at 13:47, Dominique d'Humières wrote: > > I have this patch in my working tree and it works as expected. > > > >> Also fixes pr78935. > > > > Confirmed. > > > > Thanks for the patch, > > > > Dominique > > > > > -- Andre Vehreschild * Email: vehre ad gmx dot de
Re: Ping! Re: [PATCH, Fortran, pr78781, v1] [7 Regression] [Coarray] ICE in gfc_deallocate_scalar_with_status, at fortran/trans.c:1588
Hi Paul,
thanks for review. Committed as r244196.
Best regards and happy new year to you,
Andre
On Sat, 7 Jan 2017 15:06:20 +0100
Paul Richard Thomas wrote:
> Hi Andre and Dominique,
>
> Apart from s/allows there allocation/allows their allocation/ this is
> OK for trunk.
>
> Given the scale of the patch, can this really be a regression?
>
> Thanks
>
> Paul
>
>
> On 7 January 2017 at 13:47, Dominique d'Humières wrote:
> > I have this patch in my working tree and it works as expected.
> >
> >> Also fixes pr78935.
> >
> > Confirmed.
> >
> > Thanks for the patch,
> >
> > Dominique
> >
>
>
>
--
Andre Vehreschild * Email: vehre ad gmx dot de
Index: gcc/fortran/ChangeLog
===
--- gcc/fortran/ChangeLog (Revision 244195)
+++ gcc/fortran/ChangeLog (Arbeitskopie)
@@ -1,3 +1,47 @@
+2017-01-07 Andre Vehreschild
+
+ PR fortran/78781
+ PR fortran/78935
+ * expr.c (gfc_check_pointer_assign): Return the same error message for
+ rewritten coarray pointer assignments like for plain ones.
+ * gfortran.h: Change prototype.
+ * primary.c (caf_variable_attr): Set attributes used ones only only
+ ones. Add setting of pointer_comp attribute.
+ (gfc_caf_attr): Add setting of pointer_comp attribute.
+ * trans-array.c (gfc_array_allocate): Add flag that the component to
+ allocate is not an ultimate coarray component. Add allocation of
+ pointer arrays.
+ (structure_alloc_comps): Extend nullify to treat pointer components in
+ coarrays correctly. Restructure nullify to remove redundant code.
+ (gfc_nullify_alloc_comp): Allow setting caf_mode flags.
+ * trans-array.h: Change prototype of gfc_nullify_alloc_comp ().
+ * trans-decl.c (generate_coarray_sym_init): Call nullify_alloc_comp for
+ derived type coarrays with pointer components.
+ * trans-expr.c (gfc_trans_structure_assign): Also treat pointer
+ components.
+ (trans_caf_token_assign): Handle assignment of token of scalar pointer
+ components.
+ (gfc_trans_pointer_assignment): Call above routine.
+ * trans-intrinsic.c (conv_expr_ref_to_caf_ref): Add treating pointer
+ components.
+ (gfc_conv_intrinsic_caf_get): Likewise.
+ (conv_caf_send): Likewise.
+ * trans-stmt.c (gfc_trans_allocate): After allocating a derived type in
+ a coarray pre-register the tokens.
+ (gfc_trans_deallocate): Simply determining the coarray type (scalar or
+ array) and deregistering it correctly.
+ * trans-types.c (gfc_typenode_for_spec): Replace in_coarray flag by the
+ actual codim to allow lookup of array types in the cache.
+ (gfc_build_array_type): Likewise.
+ (gfc_get_array_descriptor_base): Likewise.
+ (gfc_get_array_type_bounds): Likewise.
+ (gfc_get_derived_type): Likewise.
+ * trans-types.h: Likewise.
+ * trans.c (gfc_deallocate_with_status): Enable deregistering of all kind
+ of coarray components.
+ (gfc_deallocate_scalar_with_status): Use free() in fcoarray_single mode
+ instead of caf_deregister.
+
2017-01-06 Jakub Jelinek
* simplify.c (simplify_transformation_to_array): Use
Index: gcc/fortran/expr.c
===
--- gcc/fortran/expr.c (Revision 244195)
+++ gcc/fortran/expr.c (Arbeitskopie)
@@ -3708,9 +3708,20 @@
if (rvalue->expr_type == EXPR_FUNCTION && !attr.pointer)
{
- gfc_error ("Target expression in pointer assignment "
- "at %L must deliver a pointer result",
- &rvalue->where);
+ /* F2008, C725. For PURE also C1283. Sometimes rvalue is a function call
+ to caf_get. Map this to the same error message as below when it is
+ still a variable expression. */
+ if (rvalue->value.function.isym
+ && rvalue->value.function.isym->id == GFC_ISYM_CAF_GET)
+ /* The test above might need to be extend when F08, Note 5.4 has to be
+ interpreted in the way that target and pointer with the same coindex
+ are allowed. */
+ gfc_error ("Data target at %L shall not have a coindex",
+ &rvalue->where);
+ else
+ gfc_error ("Target expression in pointer assignment "
+ "at %L must deliver a pointer result",
+ &rvalue->where);
return false;
}
Index: gcc/fortran/gfortran.h
===
--- gcc/fortran/gfortran.h (Revision 244195)
+++ gcc/fortran/gfortran.h (Arbeitskopie)
@@ -2836,7 +2836,7 @@
int gfc_get_int_kind_from_width_isofortranenv (int size);
int gfc_get_real_kind_from_width_isofortranenv (int size);
tree gfc_get_union_type (gfc_symbol *);
-tree gfc_get_derived_type (gfc_symbol * derived, bool in_coarray = false);
+tree gfc_get_derived_type (gfc_symbol * derived, int codimen = 0);
extern int gfc_index_integer_kind;
extern int gfc_default_integer_kind;
extern int gfc_max_integer_kind;
Index: gcc/fortran/primary.c
===
--- gcc/fortran/primary.c (Revision 244195)
+++ gcc/fortran/primary.c (Arbeitskopie)
@@ -2436,8 +2436,7 @@
static symbol_attribute
ca
Re: [PR tree-optimization/67955] Exploit PTA in DSE
On 01/05/2017 01:34 AM, Richard Biener wrote:
On Wed, Jan 4, 2017 at 8:24 PM, Jeff Law wrote:
The more I think about this the more I'm sure we need to verify pt.null is
not in the points-to set.I've taken the above testcase and added it as a
negative test. Bootstrapped, regression tested and committed to the trunk
along with the other minor cleanups you pointed out.
Note disabling this for pt.null == 1 makes it pretty useless given we compute
that conservatively to always 1 in points-to analysis (and only VRP ever sets
it to zero). See PTAs find_what_p_points_to. This is because PTA does
not conservatively compute whether a pointer may be NULL (all bugs, I have
partly fixed some and have an incomplete patch to fix others -- at the point
I looked into this we had no users of pt.null info and thus I decided the
extra constraints and complexity wasn't worth the compile-time/memory-use).
Without -fnon-call-exceptions removing the *0 = 2 store is IMHO ok, so we
only have to make sure to not break the exception case.
I spent a goodly amount of time thinking about this... I think the key
point is whether or not removing the store is observable in a conforming
program.
Essentially if we get a non-call exception or receive a signal between
the "dead" store and the subsequent store, then we could observe that
the "dead" store was removed if the object being stored escapes.
This seems to have larger implications than just the cases we're looking
at (assume "a" is something in memory, of course).
a = 1;
a = 2;
If "a" escapes such that its value can be queried in the exception
handler, then the exception handler would be able to observe the first
store and thus it should not be removed.
We also have to be cognizant of systems where there is memory mapped at
location 0. When that is true, we must check pt.null and honor it, even
if it pessimizes code.
For
int foo (int *p, int b)
{
int *q;
int i = 1;
if (b)
q = &i;
else
q = (void *)0;
*q = 2;
i = 3;
return *q;
}
So on a system where *0 is a valid memory address, *q = 2 does not make
anything dead, nor does i = 3 unless we were to isolate the THEN/ELSE
blocks.
On a system where *0 traps, there is no way to observe the value of "i"
in the handler. Thus i = 1 is a dead store. I believe we must keep the
*q = 2 store because it can trigger a signal/exception which is itself
an observable side effect? Right?
we remove all stores but the last store to i and the load from q (but we don't
replace q with &i here, a missed optimization if removing the other stores is
valid).
But if we remove the *q = 2 store, we remove an observable side effect,
the trap/exception itself if we reach that statement via the ELSE path.
Jeff
[committed] Fix linemap corruption after very wide source lines (PR c++/72803)
PR c++/72803 describes an issue where a fix-it hint is to be emitted at
column 512 of a 511-column source line, leading to an ICE.
The root cause is a bug in linemap_line_start, when transitioning from
lines >= 512 in width to narrow lines.
The wide line in the reproducer has a line map with:
m_column_and_range_bits = 15, m_range_bits = 5
giving 10 effective bits for representing columns, so that columns <= 1023
can be represented.
When parsing the following line,
linemap_line_start (..., ..., max_column_hint=0);
is called. This leads to the "add_map" logic, due to this condition:
|| (max_column_hint <= 80 && effective_column_bits >= 10)
i.e. the new line is sufficiently narrower than the old one to
potentially use a new linemap (so as to conserve values within the
location_t space).
It then attempts to avoid allocating a new line map. Part of the logic
to determine if we really need a new line map is this condition:
SOURCE_COLUMN (map, highest) >= (1U << column_bits)
The above condition is incorrect: we need to determine if the highest
column we've handed out will fit within the proposed *effective* column
bits, but "column_bits" here is the column plus the range bits, rather
than just the column bits.
Hence in this case linemap_line_start erroneously decides that we don't
need a new line map, and updates the column bits within the existing
line map, so any location_t values we've already handed out within it
that are offset from the start by
>= (1<= 1<<10 to narrower
lines works correctly.
gcc/testsuite/ChangeLog:
PR c++/72803
* g++.dg/diagnostic/pr72803.C: New test case.
libcpp/ChangeLog:
PR c++/72803
* line-map.c (linemap_line_start): When determining if the highest
column given out so far will fit into a proposed change to the
current map, use the effective number of column bits, rather than
the total number of column + range bits.
---
gcc/input.c | 12
gcc/testsuite/g++.dg/diagnostic/pr72803.C | 9 +
libcpp/line-map.c | 2 +-
3 files changed, 22 insertions(+), 1 deletion(-)
create mode 100644 gcc/testsuite/g++.dg/diagnostic/pr72803.C
diff --git a/gcc/input.c b/gcc/input.c
index 22cc74c..4df47f2 100644
--- a/gcc/input.c
+++ b/gcc/input.c
@@ -1688,6 +1688,17 @@ test_accessing_ordinary_linemaps (const line_table_case
&case_)
linemap_line_start (line_table, 3, 2000);
location_t loc_e = linemap_position_for_column (line_table, 700);
+ /* Transitioning back to a short line. */
+ linemap_line_start (line_table, 4, 0);
+ location_t loc_back_to_short = linemap_position_for_column (line_table, 100);
+
+ if (should_have_column_data_p (loc_back_to_short))
+{
+ /* Verify that we switched to short lines in the linemap. */
+ line_map_ordinary *map = LINEMAPS_LAST_ORDINARY_MAP (line_table);
+ ASSERT_EQ (7, map->m_column_and_range_bits - map->m_range_bits);
+}
+
linemap_add (line_table, LC_LEAVE, false, NULL, 0);
/* Multiple files. */
@@ -1702,6 +1713,7 @@ test_accessing_ordinary_linemaps (const line_table_case
&case_)
assert_loceq ("foo.c", 2, 1, loc_c);
assert_loceq ("foo.c", 2, 17, loc_d);
assert_loceq ("foo.c", 3, 700, loc_e);
+ assert_loceq ("foo.c", 4, 100, loc_back_to_short);
assert_loceq ("bar.c", 1, 150, loc_f);
ASSERT_FALSE (is_location_from_builtin_token (loc_a));
diff --git a/gcc/testsuite/g++.dg/diagnostic/pr72803.C
b/gcc/testsuite/g++.dg/diagnostic/pr72803.C
new file mode 100644
index 000..0a9a390
--- /dev/null
+++ b/gcc/testsuite/g++.dg/diagnostic/pr72803.C
@@ -0,0 +1,9 @@
+/* Long line, with a close brace at column 511, hence with the insertion
+ point for the missing semicolon at column 512. */
+class test {
}
+# 1 "" 1
+// The line directive appears to be necessary to trigger the ICE
+// { dg-error "style of line directive is a GCC extension" "" { target *-*-* }
.-2 }
+
+/* Verify that we get the correct line and column for the diagnostic. */
+// { dg-error "512: expected .;. after class definition" "" { target *-*-* } 3
}
diff --git a/libcpp/line-map.c b/libcpp/line-map.c
index 77beaff..b410c00 100644
--- a/libcpp/line-map.c
+++ b/libcpp/line-map.c
@@ -752,7 +752,7 @@ linemap_line_start (struct line_maps *set, linenum_type
to_line,
single line we can sometimes just increase its column_bits instead. */
if (line_delta < 0
|| last_line != OR
[doc, committed] clean up include search path documentation in cpp.texi
I've checked in this patch to modernize the tutorial information about
the preprocessor search path in cpp.texi -- in particular, removing the
discussion of the deprecated -I- option, better integrating information
about the preferred replacement -iquote and -system options into the
flow, and removing some other redundant or obsolete bits.
There's also been PR 13498 open since 2003 to report other inaccurate
information in this section, so I've addressed those problems here as
well. It's kind of bad that we've been providing incorrect
documentation for 13+ years. :-( Since it's clear maintaining this
manual is a low priority, I've generally gone with the approach of not
providing too many details in the tutorial material and instead pointing
people at the relevant command-line options.
-Sandra
2017-01-07 Sandra Loosemore
PR preprocessor/13498
gcc/
* doc/cpp.texi (Search Path): Rewrite to remove obsolete and
redudant material, and reflect new command-line options.
(System Headers): Likewise.
Index: gcc/doc/cpp.texi
===
--- gcc/doc/cpp.texi (revision 244106)
+++ gcc/doc/cpp.texi (working copy)
@@ -837,74 +837,49 @@ final newline.
@node Search Path
@section Search Path
-GCC looks in several different places for headers. On a normal Unix
-system, if you do not instruct it otherwise, it will look for headers
-requested with @code{@w{#include <@var{file}>}} in:
-
-@smallexample
-/usr/local/include
-@var{libdir}/gcc/@var{target}/@var{version}/include
-/usr/@var{target}/include
-/usr/include
-@end smallexample
-
-For C++ programs, it will also look in
-@file{@var{libdir}/../include/c++/@var{version}},
-first. In the above, @var{target} is the canonical name of the system
-GCC was configured to compile code for; often but not always the same as
-the canonical name of the system it runs on. @var{version} is the
-version of GCC in use.
-
-You can add to this list with the @option{-I@var{dir}} command-line
-option. All the directories named by @option{-I} are searched, in
-left-to-right order, @emph{before} the default directories. The only
-exception is when @file{dir} is already searched by default. In
-this case, the option is ignored and the search order for system
-directories remains unchanged.
-
-Duplicate directories are removed from the quote and bracket search
-chains before the two chains are merged to make the final search chain.
-Thus, it is possible for a directory to occur twice in the final search
-chain if it was specified in both the quote and bracket chains.
-
-You can prevent GCC from searching any of the default directories with
-the @option{-nostdinc} option. This is useful when you are compiling an
-operating system kernel or some other program that does not use the
-standard C library facilities, or the standard C library itself.
-@option{-I} options are not ignored as described above when
-@option{-nostdinc} is in effect.
-
-GCC looks for headers requested with @code{@w{#include "@var{file}"}}
-first in the directory containing the current file, then in the
-directories as specified by @option{-iquote} options, then in the same
-places it would have looked for a header requested with angle
-brackets. For example, if @file{/usr/include/sys/stat.h} contains
+By default, the preprocessor looks for header files included by the quote
+form of the directive @code{@w{#include "@var{file}"}} first relative to
+the directory of the current file, and then in a preconfigured list
+of standard system directories.
+For example, if @file{/usr/include/sys/stat.h} contains
@code{@w{#include "types.h"}}, GCC looks for @file{types.h} first in
@file{/usr/include/sys}, then in its usual search path.
-@samp{#line} (@pxref{Line Control}) does not change GCC's idea of the
-directory containing the current file.
+For the angle-bracket form @code{@w{#include <@var{file}>}}, the
+preprocessor's default behavior is to look only in the standard system
+directories. The exact search directory list depends on the target
+system, how GCC is configured, and where it is installed. You can
+find the default search directory list for your version of CPP by
+invoking it with the @option{-v} option. For example,
-You may put @option{-I-} at any point in your list of @option{-I} options.
-This has two effects. First, directories appearing before the
-@option{-I-} in the list are searched only for headers requested with
-quote marks. Directories after @option{-I-} are searched for all
-headers. Second, the directory containing the current file is not
-searched for anything, unless it happens to be one of the directories
-named by an @option{-I} switch. @option{-I-} is deprecated, @option{-iquote}
-should be used instead.
-
-@option{-I. -I-} is not the same as no @option{-I} options at all, and does
-not cause the same behavior for @samp{<>} includes that @samp{""}
-includes get with no special options. @option{-I.
Re: [PATCH] avoid false positives due to signed to unsigned conversion (PR 78973)
On 01/06/2017 01:55 PM, Jeff Law wrote: On 01/05/2017 02:53 PM, Martin Sebor wrote: When the size passed to a call to a function like memcpy is a signed integer whose range has a negative lower bound and a positive upper bound the lower bound of the range of the argument after conversion to size_t may be in excess of the maximum object size (PTRDIFF_MAX by default). This results in -Wstringop-overflow false positives. Is this really a false positive though?ISTM that if the testcase were compiled for a 32 bit target, then all hell would break loose if g::n was 0x (unsigned 32bit). You're right! In the test case I added the warning is indeed correct. And after spending more time going through the submitted translation unit I think it's correct there too because of the unsigned to signed (to unsigned) conversion. I think I was initially looking the ranges before the function got inlined into the caller where the problem occurs. I may have also misread the VRP dump (or looked at the wrong one too). It also doesn't help is that the warning doesn't show the inlining stack. Let me fix that. I'd think to create [INT_MIN, INT_MAX] you'd probably need a meet at a PHI node that wasn't trivially representable and thus would get dropped to [INT_MIN, INT_MAX]. A meet of 3 values with 2 holes for example might do what you wanted. It would be nice to have a helper in the test suite for creating ranges. (Or perhaps a built-in.) Note that the ranges in VRP can be more precise than the ranges seen outside VRP. The warning is being emitted at the gimple->rtl phase, so you may be stumbling over one of the numerous problems with losing good range information. I think I had simply misread the ranges. Thanks for the careful review! Martin
New Vietnamese PO file for 'gcc' (version 7.1-b20170101)
Hello, gentle maintainer. This is a message from the Translation Project robot. A revised PO file for textual domain 'gcc' has been submitted by the Vietnamese team of translators. The file is available at: http://translationproject.org/latest/gcc/vi.po (This file, 'gcc-7.1-b20170101.vi.po', has just now been sent to you in a separate email.) All other PO files for your package are available in: http://translationproject.org/latest/gcc/ Please consider including all of these in your next release, whether official or a pretest. Whenever you have a new distribution with a new version number ready, containing a newer POT file, please send the URL of that distribution tarball to the address below. The tarball may be just a pretest or a snapshot, it does not even have to compile. It is just used by the translators when they need some extra translation context. The following HTML page has been updated: http://translationproject.org/domain/gcc.html If any question arises, please contact the translation coordinator. Thank you for all your work, The Translation Project robot, in the name of your translation coordinator.
Contents of PO file 'cpplib-7.1-b20170101.vi.po'
cpplib-7.1-b20170101.vi.po.gz Description: Binary data The Translation Project robot, in the name of your translation coordinator.
New Vietnamese PO file for 'cpplib' (version 7.1-b20170101)
Hello, gentle maintainer. This is a message from the Translation Project robot. A revised PO file for textual domain 'cpplib' has been submitted by the Vietnamese team of translators. The file is available at: http://translationproject.org/latest/cpplib/vi.po (This file, 'cpplib-7.1-b20170101.vi.po', has just now been sent to you in a separate email.) All other PO files for your package are available in: http://translationproject.org/latest/cpplib/ Please consider including all of these in your next release, whether official or a pretest. Whenever you have a new distribution with a new version number ready, containing a newer POT file, please send the URL of that distribution tarball to the address below. The tarball may be just a pretest or a snapshot, it does not even have to compile. It is just used by the translators when they need some extra translation context. The following HTML page has been updated: http://translationproject.org/domain/cpplib.html If any question arises, please contact the translation coordinator. Thank you for all your work, The Translation Project robot, in the name of your translation coordinator.
[doc, committed] fix preprocessor -d option table formatting
PR 54124 complains that the documentation for preprocessor options like
-dM is hard to find because the string "-dM" doesn't appear explicitly
in the table. Instead, it's documented as @samp{M} in a subtable under
the -dCHARS option. The corresponding documentation of the more general
compiler dump options, in another section, does list the full name of
the options in the subtable. I've fixed the preprocessor -d option
documentation to be consistent with that format, and added
cross-references back and forth too.
-Sandra
2017-01-07 Sandra Loosemore
PR preprocessor/54124
gcc/
* doc/cppopts.texi: Reformat -d subtable to list the full name
of the options. Add cross-reference to the docs for the general
compiler -d options.
* doc/invoke.texi (Developer Options): Add cross-reference to the
preprocessor-specific -d option documentation.
Index: gcc/doc/cppopts.texi
===
--- gcc/doc/cppopts.texi (revision 244200)
+++ gcc/doc/cppopts.texi (working copy)
@@ -458,15 +458,20 @@ activities. Each name is indented to sh
printed, even if they are found to be invalid; an invalid precompiled
header file is printed with @samp{...x} and a valid one with @samp{...!} .
-@item -dCHARS
-@var{CHARS} is a sequence of one or more of the following characters,
-and must not be preceded by a space. Other characters are interpreted
+@item -d@var{letters}
+@opindex d
+Says to make debugging dumps during compilation as specified by
+@var{letters}. The flags documented here are those relevant to the
+preprocessor. Other @var{letters} are interpreted
by the compiler proper, or reserved for future versions of GCC, and so
-are silently ignored. If you specify characters whose behavior
+are silently ignored. If you specify @var{letters} whose behavior
conflicts, the result is undefined.
+@ifclear cppmanual
+@xref{Developer Options}, for more information.
+@end ifclear
-@table @samp
-@item M
+@table @gcctabopt
+@item -dM
@opindex dM
Instead of the normal output, generate a list of @samp{#define}
directives for all the macros defined during the execution of the
@@ -487,25 +492,25 @@ interpreted as a synonym for @option{-fd
@xref{Developer Options, , ,gcc}.
@end ifclear
-@item D
+@item -dD
@opindex dD
-Like @samp{M} except in two respects: it does @emph{not} include the
+Like @option{-dM} except in two respects: it does @emph{not} include the
predefined macros, and it outputs @emph{both} the @samp{#define}
directives and the result of preprocessing. Both kinds of output go to
the standard output file.
-@item N
+@item -dN
@opindex dN
-Like @samp{D}, but emit only the macro names, not their expansions.
+Like @option{-dD}, but emit only the macro names, not their expansions.
-@item I
+@item -dI
@opindex dI
Output @samp{#include} directives in addition to the result of
preprocessing.
-@item U
+@item -dU
@opindex dU
-Like @samp{D} except that only macros that are expanded, or whose
+Like @option{-dD} except that only macros that are expanded, or whose
definedness is tested in preprocessor directives, are output; the
output is delayed until the use or test of the macro; and
@samp{#undef} directives are also output for macros tested but
Index: gcc/doc/invoke.texi
===
--- gcc/doc/invoke.texi (revision 244200)
+++ gcc/doc/invoke.texi (working copy)
@@ -12541,8 +12541,11 @@ passes that are otherwise registered aft
numbered higher than a pass named "final", even if they are executed
earlier. @var{dumpname} is generated from the name of the output
file if explicitly specified and not an executable, otherwise it is
-the basename of the source file. These switches may have different
-effects when @option{-E} is used for preprocessing.
+the basename of the source file.
+
+Some @option{-d@var{letters}} switches have different meaning when
+@option{-E} is used for preprocessing. @xref{Preprocessor Options},
+for information about preprocessor-specific dump options.
Debug dumps can be enabled with a @option{-fdump-rtl} switch or some
@option{-d} option @var{letters}. Here are the possible
New Spanish PO file for 'gcc' (version 7.1-b20170101)
Hello, gentle maintainer. This is a message from the Translation Project robot. A revised PO file for textual domain 'gcc' has been submitted by the Spanish team of translators. The file is available at: http://translationproject.org/latest/gcc/es.po (This file, 'gcc-7.1-b20170101.es.po', has just now been sent to you in a separate email.) All other PO files for your package are available in: http://translationproject.org/latest/gcc/ Please consider including all of these in your next release, whether official or a pretest. Whenever you have a new distribution with a new version number ready, containing a newer POT file, please send the URL of that distribution tarball to the address below. The tarball may be just a pretest or a snapshot, it does not even have to compile. It is just used by the translators when they need some extra translation context. The following HTML page has been updated: http://translationproject.org/domain/gcc.html If any question arises, please contact the translation coordinator. Thank you for all your work, The Translation Project robot, in the name of your translation coordinator.
C++ PATCH for c++/78948 (instantiation from discarded statement)
P0292 defines the notion of "discarded statement" which is almost but
not quite the same as "unevaluated operand". This PR shows a case
where we need to be able to tell that we're in a discarded statement
at a lower level than in the parser, so this patch moves the
information about being in a discarded statement from the parser into
saved_scope. I've also added a test for a couple of cases that
demonstrate why we can't just use cp_unevaluated_context.
Tested x86_64-pc-linux-gnu, applying to trunk.
commit 4d3de5520010cda3bdb47c8a6532e734f09cfc3e
Author: Jason Merrill
Date: Fri Jan 6 09:45:02 2017 -0500
PR c++/78948 - instantiation from discarded statement
* parser.h (struct cp_parser): Remove in_discarded_stmt field.
* cp-tree.h (in_discarded_stmt): Declare it.
(struct saved_scope): Add discarded_stmt bitfield.
(in_discarded_stmt): New macro.
* decl2.c (mark_used): Check it.
* parser.c (cp_parser_selection_statement): Adjust.
(cp_parser_jump_statement): Adjust.
diff --git a/gcc/cp/cp-tree.h b/gcc/cp/cp-tree.h
index 39f5d79..24de346 100644
--- a/gcc/cp/cp-tree.h
+++ b/gcc/cp/cp-tree.h
@@ -1281,6 +1281,10 @@ struct GTY(()) saved_scope {
BOOL_BITFIELD x_processing_explicit_instantiation : 1;
BOOL_BITFIELD need_pop_function_context : 1;
+/* Nonzero if we are parsing the discarded statement of a constexpr
+ if-statement. */
+ BOOL_BITFIELD discarded_stmt : 1;
+
int unevaluated_operand;
int inhibit_evaluation_warnings;
int noexcept_operand;
@@ -1341,6 +1345,8 @@ extern GTY(()) struct saved_scope *scope_chain;
#define processing_specialization scope_chain->x_processing_specialization
#define processing_explicit_instantiation
scope_chain->x_processing_explicit_instantiation
+#define in_discarded_stmt scope_chain->discarded_stmt
+
/* RAII sentinel to handle clearing processing_template_decl and restoring
it when done. */
diff --git a/gcc/cp/decl2.c b/gcc/cp/decl2.c
index a0375ad..435f51f 100644
--- a/gcc/cp/decl2.c
+++ b/gcc/cp/decl2.c
@@ -5112,7 +5112,7 @@ mark_used (tree decl, tsubst_flags_t complain)
}
/* If we don't need a value, then we don't need to synthesize DECL. */
- if (cp_unevaluated_operand != 0)
+ if (cp_unevaluated_operand || in_discarded_stmt)
return true;
DECL_ODR_USED (decl) = 1;
diff --git a/gcc/cp/parser.c b/gcc/cp/parser.c
index 57ae064..e8c0642 100644
--- a/gcc/cp/parser.c
+++ b/gcc/cp/parser.c
@@ -11147,12 +11147,12 @@ cp_parser_selection_statement (cp_parser* parser,
bool *if_p,
/* Outside a template, the non-selected branch of a constexpr
if is a 'discarded statement', i.e. unevaluated. */
- bool was_discarded = parser->in_discarded_stmt;
+ bool was_discarded = in_discarded_stmt;
bool discard_then = (cx && !processing_template_decl
&& integer_zerop (condition));
if (discard_then)
{
- parser->in_discarded_stmt = true;
+ in_discarded_stmt = true;
++c_inhibit_evaluation_warnings;
}
@@ -11166,7 +11166,7 @@ cp_parser_selection_statement (cp_parser* parser, bool
*if_p,
if (discard_then)
{
THEN_CLAUSE (statement) = NULL_TREE;
- parser->in_discarded_stmt = was_discarded;
+ in_discarded_stmt = was_discarded;
--c_inhibit_evaluation_warnings;
}
@@ -11178,7 +11178,7 @@ cp_parser_selection_statement (cp_parser* parser, bool
*if_p,
&& integer_nonzerop (condition));
if (discard_else)
{
- parser->in_discarded_stmt = true;
+ in_discarded_stmt = true;
++c_inhibit_evaluation_warnings;
}
@@ -11235,7 +11235,7 @@ cp_parser_selection_statement (cp_parser* parser, bool
*if_p,
if (discard_else)
{
ELSE_CLAUSE (statement) = NULL_TREE;
- parser->in_discarded_stmt = was_discarded;
+ in_discarded_stmt = was_discarded;
--c_inhibit_evaluation_warnings;
}
}
@@ -12143,7 +12143,7 @@ cp_parser_jump_statement (cp_parser* parser)
expression. */
expr = NULL_TREE;
/* Build the return-statement. */
- if (current_function_auto_return_pattern && parser->in_discarded_stmt)
+ if (current_function_auto_return_pattern && in_discarded_stmt)
/* Don't deduce from a discarded return statement. */;
else
statement = finish_return_stmt (expr);
diff --git a/gcc/cp/parser.h b/gcc/cp/parser.h
index f242f4c..0994e1e 100644
--- a/gcc/cp/parser.h
+++ b/gcc/cp/parser.h
@@ -336,10 +336,6 @@ struct GTY(()) cp_parser {
a local class. */
bool in_fun
