Re: [Patch, gcc-wwdocs] Update to Fortran changes
On Tue, Nov 26, 2019 at 1:12 PM Tobias Burnus wrote: > In particular, currently, the following item does not make clear that it > is about legacy support: "Variables with the AUTOMATIC > attribute can be used in EQUIVALENCE statements." > > I think it can remain as is with the -fdec umbrella item. But without it > really requires the background knowledge that the AUTOMATIC attribute is > only available with -fdec-static (or -fdec). Speaking of which, to avoid confusion maybe we should rename the -f[no-]automatic option to something like -f[no-]save, since the Fortran standard description of an "automatic data object" doesn't really have anything to do with the option, and neither does the option have anything to do specifically with the DEC AUTOMATIC specifier? -- Janne Blomqvist
Re: [PATCH] Fix PR91790 by considering different first_stmt_info for realign
On Wed, 27 Nov 2019, Kewen.Lin wrote: > Hi, > > As PR91790 exposed, when we have one slp node whose first_stmt_info_for_drptr > is different from first_stmt_info, it's possible that the first_stmt DR isn't > initialized yet before stmt SLP_TREE_SCALAR_STMTS[0] of slp node. So we > shouldn't use first_stmt_info for vect_setup_realignment, instead we can use > the one based on first_stmt_info_for_drptr DR with additional adjustment by > bumping the distance from first_stmt DR. > > Bootstrapped and tested on powerpc64le-linux-gnu (P8LE) and > ppc64-redhat-linux (P7BE) which need to use realign_load. > > Is it ok for trunk? and backport to GCC 9 after some burn-in time? OK. Thanks, Richard.
[Bug fortran/92123] [F2018/array-descriptor] Scalar allocatable/pointer with array descriptor (via bind(C)): ICE with select rank or error scalar variable with POINTER or ALLOCATABLE in procedure wit
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92123
--- Comment #19 from Richard Biener ---
There is also tree-core.h:
/* Call argument flags. */
/* Nonzero if the argument is not dereferenced recursively, thus only
directly reachable memory is read or written. */
#define EAF_DIRECT (1 << 0)
/* Nonzero if memory reached by the argument is not clobbered. */
#define EAF_NOCLOBBER (1 << 1)
/* Nonzero if the argument does not escape. */
#define EAF_NOESCAPE(1 << 2)
/* Nonzero if the argument is not used by the function. */
#define EAF_UNUSED (1 << 3)
/* Call return flags. */
/* Mask for the argument number that is returned. Lower two bits of
the return flags, encodes argument slots zero to three. */
#define ERF_RETURN_ARG_MASK (3)
/* Nonzero if the return value is equal to the argument number
flags & ERF_RETURN_ARG_MASK. */
#define ERF_RETURNS_ARG (1 << 2)
but eventually specifying some terminology and then consistently using that
might help... Eventually the documentation bits could go to the internals
manual somewhere ('no vops' is also not documented).
[Bug target/92686] Inefficient mask operation for 128/256-bit vector VCOND_EXPR under avx512f
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92686 Richard Biener changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2019-11-27 Ever confirmed|0 |1 Severity|normal |enhancement --- Comment #2 from Richard Biener --- It would be definitely nice to have this. Maybe add a tunable whether to use mask registers for SSE/AVX2? Is there any boost frequency penalty for using them? Using mask registers also looks like a way to reduce register pressure (in case the register pressure is not on the masks side).
[Bug target/92682] [10 Regression] maxlocval_4.f90 / minlocval_4.f90 failure on POWER9
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92682 Richard Biener changed: What|Removed |Added Version|unknown |10.0 Target Milestone|--- |10.0
[Bug other/92681] PGO bootstrap with --with-build-config=bootstrap-lto-lean is not training non-C++ frontends
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92681 --- Comment #1 from Richard Biener --- Is it actually making it worse from non-PGO or do we at least treat missing profile data as "it wasn't trained"?
[Bug bootstrap/92680] PGO bootstrap is broken with --with-build-config=bootstrap-lto-lean and in-itree mpfr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92680 --- Comment #2 from Richard Biener --- And gmp has a similar issue.
[Bug bootstrap/92680] PGO bootstrap is broken with --with-build-config=bootstrap-lto-lean and in-itree mpfr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92680
Richard Biener changed:
What|Removed |Added
Keywords||build
Status|UNCONFIRMED |NEW
Last reconfirmed||2019-11-27
Ever confirmed|0 |1
--- Comment #1 from Richard Biener ---
I think that's known and was fixed upstream, but the easiest option is to pass
-fno-lto to stage2+ mpfr configure via the host_module config (need to figure
what environment to set exactly and/or invent extra vars honored by bootstrap)
We carry locally in our package
diff --git a/configure b/configure
index 6581c68..a82593c 100755
--- a/configure
+++ b/configure
@@ -16158,7 +16158,7 @@ foo_t foo = {
};
EOF
- mpfr_compile="$CC $CFLAGS $CPPFLAGS -c conftest.c >&5 2>&1"
+ mpfr_compile="$CC $CFLAGS $CPPFLAGS -c conftest.c -fno-lto >&5 2>&1"
if { { eval echo "\"\$as_me\":${as_lineno-$LINENO}: \"$mpfr_compile\""; }
>&5
(eval $mpfr_compile) 2>&5
ac_status=$?
[Bug c++/92675] sign-conversion C++ unsigned int j = -1;
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92675 Richard Biener changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2019-11-27 Ever confirmed|0 |1 --- Comment #3 from Richard Biener --- -1u also works
Re: [PATCH] Fix two potential memory leak
Thanks,
On 2019/11/26 18:15, Jan Hubicka wrote:
>> Hi,
>>
>> On 2019/11/26 16:04, Jan Hubicka wrote:
Summary variables should be deleted at the end of write_summary.
It's first newed in generate_summary, and second newed in read_summary.
Therefore, delete the first in write_summary, delete the second in
execute.
gcc/ChangeLog:
2019-11-26 Luo Xiong Hu
* ipa-pure-const.c (pure_const_write_summary): Fix memory leak.
* ipa-sra.c (ipa_sra_write_summary): Likewise.
>>>
>>> This is not going to work with -ffat-lto-objects because in this case
>>> IPA pass is executed later. So you will need
>>> if (!flag_fat_lto_objects).
>>>
>>> I think most IPA passes just waits for compiler to exit with LTO rather
>>> than free the summary. ipa-fnsummary and ipa-prop allocate optimization
>>> summaries, too. Are those freed?
>>
>> ipa-prop is a bit different, the ipcp_transformation_sum is only created in
>> read_summary, so need only delete once after execute.
>
> It also has ipa_node_params_sum and ipa_edge_args_sum which live from
> ipa-prop analysis until after ipa-inlining.
>>
>> ipa-fnsummary also forgot to free the ipa summaries at the end of
>> write_summary. The pass pass_ipa_free_fn_summary will delete all summaries
>> in execute.
>>
>> For -ffat-lto-objects, I suppose there would be no write_summary and
>> read_summary? so summaries are also newed once and delete once? Thanks.
>>
>> Anyway, lto1 will run after cc1, which means cc1 is finished, the memory is
>> freed theoretically.
>
> With -ffat-lto-object we run full optimization pipieline at compile
> time. This means that we first write summary, then execute the pass
> (which uses the summary and frees it) and proceed by compilation.
> With -fno-fat-lto-object the pipieline is terminated after summary
> writting. By quiting compiler we free all the memory.
>
> We do have a lot of places where memory leaks this way and is freed at
> exit. I see that for jit we added sume explicit free calls, but I think
> jit is not using this path.
>
> I am not against freeing things explicitly since it makes it easier to
> identify real leaks, but we should do it systematically. Thinking of
> this case probably may even lead to some memory savings because after
> summary streaming the global stream is produced which is typically the
> biggest object streamed. So freeing it is OK, but please add check for
> !fat lto objects and also free ipa-fnsummary (there is
> ipa_free_fn_summary, ipa_free_size_summary for that) and ipa-prop
> summaries.
Verified that "if (!flag_fat_lto_objects)" is required for explicitly
deleting the summaries when built with -ffat-lto-objects.
>
> I will also look into your changes for ipa-profile tomorrow (I suppose
> you noticed this while looking into summaries for that patch :)
It's true that I am moving the speculative target summaries from cgraph.h
to ipa-profile.c, code is exploded with hundred of new lines. Simple test
case could work now with write_summary/read_summary/execute, but most spec
test cases ICEd due to ggc_grow() or ggc_collect(), I debugged the code and
found that read_summary is correct streaming in the target summaries, but some
edge's summary was GCed UNEXPECTEDLY by followed ggc_grow() or ggc_collect()
before calling ipa_profile, any clue on this, please?
Great that you take time on this!:)
ipa-profile.c
...
+/* Structure containing speculative target information from profile. */
+
+struct GTY (()) speculative_call_target
+{
+ speculative_call_target (unsigned int id, int prob)
+: target_id (id), target_probability (prob)
+ {
+ }
+
+ /* Profile_id of target obtained from profile. */
+ unsigned int target_id;
+ /* Probability that call will land in function with target_id. */
+ int target_probability;
+};
+
+class speculative_call_summary
+{
+public:
+ speculative_call_summary () : speculative_call_targets () {}
+
+ vec *speculative_call_targets;
+ ~speculative_call_summary ();
+
+ void dump (FILE *f);
+
+ /* Check whether this is a empty summary. */
+ bool is_empty ();
+};
...
Xiong Hu
> Honza
>>
>> Xiong Hu
>>
>>
>>>
>>> Honza
---
gcc/ipa-pure-const.c | 3 +++
gcc/ipa-sra.c| 5 +
2 files changed, 8 insertions(+)
diff --git a/gcc/ipa-pure-const.c b/gcc/ipa-pure-const.c
index a142e0cc8f6..89f334cedac 100644
--- a/gcc/ipa-pure-const.c
+++ b/gcc/ipa-pure-const.c
@@ -1260,6 +1260,9 @@ pure_const_write_summary (void)
}
lto_destroy_simple_output_block (ob);
+
+ delete funct_state_summaries;
+ funct_state_summaries = NULL;
}
diff --git a/gcc/ipa-sra.c b/gcc/ipa-sra.c
index c6ed0f44b87..bbc5e84edfb 100644
--- a/gcc/ipa-sra.c
+++ b/gcc/ipa-sra.c
@@ -2671,6 +2671,11 @@ ipa_sra_write_summary (void)
streamer_write_char_stream (ob->main_stream, 0);
produce_asm (ob, NULL);
Re: [PATCH] [rs6000] Fix PR92098
On 2019/11/27 2:42 PM, Kewen.Lin wrote:
Hi Lijia,
on 2019/11/27 下午2:31, Li Jia He wrote:
Hi,
In order to fix PR92098, we need to define vec_cmp_* and vcond_mask_*. In fact,
PR92132 already fixed the issue on the trunk. We need to backport PR92132 int
part to gcc-9-branch. This patch backport vector_{ungt,unge,unlt,unle}
for vec_{cmp,cmpu} interface and related expand to gcc-9-branch.
Is it a typo here? I didn't see any parts on those FP comparison operators
that is
vector_{ungt,unge,unlt,unle} in this patch, I guess you means to give up that
part?
Hi Kewen,
Yes. I just want to backport int part of PR92132 fix to gcc-9-branch.
Thanks,
Lijia He
since I noticed you just ported two cases on integral type.
BR,
Kewen
Re: [PATCH] [rs6000] Fix PR92098
Hi Lijia,
on 2019/11/27 下午2:31, Li Jia He wrote:
> Hi,
>
> In order to fix PR92098, we need to define vec_cmp_* and vcond_mask_*. In
> fact,
> PR92132 already fixed the issue on the trunk. We need to backport PR92132 int
> part to gcc-9-branch. This patch backport vector_{ungt,unge,unlt,unle}
> for vec_{cmp,cmpu} interface and related expand to gcc-9-branch.
>
Is it a typo here? I didn't see any parts on those FP comparison operators
that is
vector_{ungt,unge,unlt,unle} in this patch, I guess you means to give up that
part?
since I noticed you just ported two cases on integral type.
BR,
Kewen
[PATCH] [rs6000] Fix PR92098
Hi,
In order to fix PR92098, we need to define vec_cmp_* and vcond_mask_*. In fact,
PR92132 already fixed the issue on the trunk. We need to backport PR92132 int
part to gcc-9-branch. This patch backport vector_{ungt,unge,unlt,unle}
for vec_{cmp,cmpu} interface and related expand to gcc-9-branch.
The regression testing for the patch was done on GCC 9 branch on
powerpc64le-unknown-linux-gnu (Power 9 LE)
with no regressions. Is it OK for GCC 9 branch ?
Thanks,
Lijia He
gcc/ChangeLog
2019-11-27 Li Jia He
PR target/92098
* config/rs6000/predicates.md
(signed_or_equality_comparison_operator): New predicate.
(unsigned_or_equality_comparison_operator): Likewise.
* config/rs6000/rs6000.md (one_cmpl2): Remove expand.
(one_cmpl3_internal): Rename to one_cmpl2.
* config/rs6000/vector.md
(vcond_mask_ for VEC_I and VEC_I): New expand.
(vec_cmp for VEC_I and VEC_I): Likewise.
(vec_cmpu for VEC_I and VEC_I): Likewise.
gcc/testsuite/ChangeLog
2019-11-27 Li Jia He
PR target/92098
* gcc.target/powerpc/pr92098-int-1.c: New test.
* gcc.target/powerpc/pr92098-int-2.c: New test.
---
gcc/config/rs6000/predicates.md | 10 ++
gcc/config/rs6000/rs6000.md | 8 +-
gcc/config/rs6000/vector.md | 95 +
.../gcc.target/powerpc/pr92098-int-1.c| 126 ++
.../gcc.target/powerpc/pr92098-int-2.c| 126 ++
5 files changed, 358 insertions(+), 7 deletions(-)
create mode 100644 gcc/testsuite/gcc.target/powerpc/pr92098-int-1.c
create mode 100644 gcc/testsuite/gcc.target/powerpc/pr92098-int-2.c
diff --git a/gcc/config/rs6000/predicates.md b/gcc/config/rs6000/predicates.md
index 5cc80dea66c..e6e81471a02 100644
--- a/gcc/config/rs6000/predicates.md
+++ b/gcc/config/rs6000/predicates.md
@@ -1154,6 +1154,16 @@
(define_predicate "signed_comparison_operator"
(match_code "lt,gt,le,ge"))
+;; Return 1 if OP is a signed comparison or an equality operator.
+(define_predicate "signed_or_equality_comparison_operator"
+ (ior (match_operand 0 "equality_operator")
+ (match_operand 0 "signed_comparison_operator")))
+
+;; Return 1 if OP is an unsigned comparison or an equality operator.
+(define_predicate "unsigned_or_equality_comparison_operator"
+ (ior (match_operand 0 "equality_operator")
+ (match_operand 0 "unsigned_comparison_operator")))
+
;; Return 1 if OP is a comparison operation that is valid for an SCC insn --
;; it must be a positive comparison.
(define_predicate "scc_comparison_operator"
diff --git a/gcc/config/rs6000/rs6000.md b/gcc/config/rs6000/rs6000.md
index 7bfa5eea2ee..32da805a32d 100644
--- a/gcc/config/rs6000/rs6000.md
+++ b/gcc/config/rs6000/rs6000.md
@@ -6430,12 +6430,6 @@
""
"")
-(define_expand "one_cmpl2"
- [(set (match_operand:BOOL_128 0 "vlogical_operand")
-(not:BOOL_128 (match_operand:BOOL_128 1 "vlogical_operand")))]
- ""
- "")
-
(define_expand "nor3"
[(set (match_operand:BOOL_128 0 "vlogical_operand")
(and:BOOL_128
@@ -6730,7 +6724,7 @@
(const_string "16")))])
;; 128-bit one's complement
-(define_insn_and_split "*one_cmpl3_internal"
+(define_insn_and_split "one_cmpl2"
[(set (match_operand:BOOL_128 0 "vlogical_operand" "=")
(not:BOOL_128
(match_operand:BOOL_128 1 "vlogical_operand" "")))]
diff --git a/gcc/config/rs6000/vector.md b/gcc/config/rs6000/vector.md
index 70bcfe02e22..0b62dd04bde 100644
--- a/gcc/config/rs6000/vector.md
+++ b/gcc/config/rs6000/vector.md
@@ -493,6 +493,101 @@
FAIL;
})
+;; To support vector condition vectorization, define vcond_mask and vec_cmp.
+
+;; Same mode for condition true/false values and predicate operand.
+(define_expand "vcond_mask_"
+ [(match_operand:VEC_I 0 "vint_operand")
+ (match_operand:VEC_I 1 "vint_operand")
+ (match_operand:VEC_I 2 "vint_operand")
+ (match_operand:VEC_I 3 "vint_operand")]
+ "VECTOR_UNIT_ALTIVEC_OR_VSX_P (mode)"
+{
+ emit_insn (gen_vector_select_ (operands[0], operands[2], operands[1],
+ operands[3]));
+ DONE;
+})
+
+;; For signed integer vectors comparison.
+(define_expand "vec_cmp"
+ [(set (match_operand:VEC_I 0 "vint_operand")
+(match_operator 1 "signed_or_equality_comparison_operator"
+ [(match_operand:VEC_I 2 "vint_operand")
+ (match_operand:VEC_I 3 "vint_operand")]))]
+ "VECTOR_UNIT_ALTIVEC_OR_VSX_P (mode)"
+{
+ enum rtx_code code = GET_CODE (operands[1]);
+ rtx tmp = gen_reg_rtx (mode);
+ switch (code)
+{
+case NE:
+ emit_insn (gen_vector_eq (operands[0], operands[2], operands[3]));
+ emit_insn (gen_one_cmpl2 (operands[0], operands[0]));
+ break;
+case EQ:
+ emit_insn (gen_vector_eq (operands[0], operands[2], operands[3]));
+ break;
+case GE:
+ emit_insn (gen_vector_nlt (operands[0],operands[2], operands[3],
+
[PATCH] Fix PR91790 by considering different first_stmt_info for realign
Hi,
As PR91790 exposed, when we have one slp node whose first_stmt_info_for_drptr
is different from first_stmt_info, it's possible that the first_stmt DR isn't
initialized yet before stmt SLP_TREE_SCALAR_STMTS[0] of slp node. So we
shouldn't use first_stmt_info for vect_setup_realignment, instead we can use
the one based on first_stmt_info_for_drptr DR with additional adjustment by
bumping the distance from first_stmt DR.
Bootstrapped and tested on powerpc64le-linux-gnu (P8LE) and
ppc64-redhat-linux (P7BE) which need to use realign_load.
Is it ok for trunk? and backport to GCC 9 after some burn-in time?
BR,
Kewen
gcc/ChangeLog
2019-11-27 Kewen Lin
PR tree-optimization/91790
* gcc/tree-vect-stmts.c (vectorizable_load): Use the adjusted DR for
vect_setup_realignment when first_stmt_info is different from
first_stmt_info_for_drptr.
diff --git a/gcc/tree-vect-stmts.c b/gcc/tree-vect-stmts.c
index fb669cd..422947b 100644
--- a/gcc/tree-vect-stmts.c
+++ b/gcc/tree-vect-stmts.c
@@ -9186,18 +9186,27 @@ vectorizable_load (stmt_vec_info stmt_info,
gimple_stmt_iterator *gsi,
compute_in_loop = true;
}
+ bool diff_first_stmt_info
+= first_stmt_info_for_drptr && first_stmt_info !=
first_stmt_info_for_drptr;
+
if ((alignment_support_scheme == dr_explicit_realign_optimized
|| alignment_support_scheme == dr_explicit_realign)
&& !compute_in_loop)
{
- msq = vect_setup_realignment (first_stmt_info, gsi, _token,
- alignment_support_scheme, NULL_TREE,
- _loop);
+ /* If we have different first_stmt_info, we can't set up realignment
+here, since we can't guarantee first_stmt_info DR has been
+initialized yet, use first_stmt_info_for_drptr DR by bumping the
+distance from first_stmt_info DR instead as below. */
+ if (!diff_first_stmt_info)
+ msq = vect_setup_realignment (first_stmt_info, gsi, _token,
+ alignment_support_scheme, NULL_TREE,
+ _loop);
if (alignment_support_scheme == dr_explicit_realign_optimized)
{
phi = as_a (SSA_NAME_DEF_STMT (msq));
byte_offset = size_binop (MINUS_EXPR, TYPE_SIZE_UNIT (vectype),
size_one_node);
+ gcc_assert (!first_stmt_info_for_drptr);
}
}
else
@@ -9253,8 +9262,7 @@ vectorizable_load (stmt_vec_info stmt_info,
gimple_stmt_iterator *gsi,
dataref_ptr = unshare_expr (DR_BASE_ADDRESS (first_dr_info->dr));
dataref_offset = build_int_cst (ref_type, 0);
}
- else if (first_stmt_info_for_drptr
- && first_stmt_info != first_stmt_info_for_drptr)
+ else if (diff_first_stmt_info)
{
dataref_ptr
= vect_create_data_ref_ptr (first_stmt_info_for_drptr,
@@ -9271,6 +9279,14 @@ vectorizable_load (stmt_vec_info stmt_info,
gimple_stmt_iterator *gsi,
DR_INIT (ptrdr)));
dataref_ptr = bump_vector_ptr (dataref_ptr, ptr_incr, gsi,
stmt_info, diff);
+ if (alignment_support_scheme == dr_explicit_realign)
+ {
+ msq = vect_setup_realignment (first_stmt_info_for_drptr, gsi,
+ _token,
+ alignment_support_scheme,
+ dataref_ptr, _loop);
+ gcc_assert (!compute_in_loop);
+ }
}
else if (STMT_VINFO_GATHER_SCATTER_P (stmt_info))
vect_get_gather_scatter_ops (loop, stmt_info, _info,
[PATCH, rs6000] Fix PR92566 by checking VECTOR_UNIT_NONE_P
Hi,
As Segher pointed out in PR92566, we shouldn't offer some vector modes which
aren't supported under current setting. This patch is to make it check by
VECTOR_UNIT_NONE_P which is initialized as current architecture masks.
Bootstrapped and tested on powerpc64le-linux-gnu.
Is it ok for trunk?
BR,
Kewen
gcc/ChangeLog
2019-11-27 Kewen Lin
PR tree-optimization/91790
* gcc/config/rs6000/rs6000.c (rs6000_preferred_simd_mode): Check by
VECTOR_UNIT_NONE_P instead.
diff --git a/gcc/config/rs6000/rs6000.c b/gcc/config/rs6000/rs6000.c
index 5876714..40529e6 100644
--- a/gcc/config/rs6000/rs6000.c
+++ b/gcc/config/rs6000/rs6000.c
@@ -4906,30 +4906,11 @@ rs6000_builtin_vectorization_cost (enum
vect_cost_for_stmt type_of_cost,
static machine_mode
rs6000_preferred_simd_mode (scalar_mode mode)
{
- if (TARGET_VSX)
-switch (mode)
- {
- case E_DFmode:
- return V2DFmode;
- default:;
- }
- if (TARGET_ALTIVEC || TARGET_VSX)
-switch (mode)
- {
- case E_SFmode:
- return V4SFmode;
- case E_TImode:
- return V1TImode;
- case E_DImode:
- return V2DImode;
- case E_SImode:
- return V4SImode;
- case E_HImode:
- return V8HImode;
- case E_QImode:
- return V16QImode;
- default:;
- }
+ opt_machine_mode vmode = mode_for_vector (mode, 16 / GET_MODE_SIZE (mode));
+
+ if (vmode.exists () && !VECTOR_UNIT_NONE_P (vmode.require ()))
+return vmode.require ();
+
return word_mode;
}
Re: [PATCH][_GLIBCXX_DEBUG] Improve valid_range check
On 11/26/19 10:52 PM, Jonathan Wakely wrote: On 26/11/19 20:07 +0100, François Dumont wrote: Sure, I am about to do so. However I wasn't sure about this syntax before the commit so I had run the new 2_neg.cc with: make CXXFLAGS=-std=c++98 check-debug and it worked fine and still is ! The testsuite doesn't use CXXFLAGS. Did you mean CPPFLAGS ? I do see the option added to the compiler call in libstdc++.log file. And I used it to build for instance pretty-printers tests in _GLIBCXX_DEBUG mode with success. I also try -std=gnu++98 and made sure that pch had been updated by re-building libstdc++ first. I just can't get the expected compilation error. Maybe I need to rebuild the whole stuff to get an error... No, you need to pass the right flags so they are used by the testsuite. This will do it: make -C testsuite/ check-debug debug_flags=unix/-D_GLIBCXX_DEBUG/-std=gnu++98/-Wsystem-headers I'll have to keep your mail to remember it ! But since it only shows up with -Wsystem-headers, there's no point trying to test for it. Ok, makes sens. Thanks
[Bug tree-optimization/91790] ICE: verify_ssa failed (error: definition in block 2 follows the use)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91790 Kewen Lin changed: What|Removed |Added Attachment #47357|0 |1 is obsolete|| --- Comment #11 from Kewen Lin --- Created attachment 47371 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47371=edit 47357: Defer vect_setup_realignment for different first_stmt_info Bootstrapped and tested on powerpc64le-linux-gnu (P8LE) and ppc64-redhat-linux (P7BE).
Re: [PATCH/AARCH64] Generate FRINTZ for (double)(long) under -ffast-math on aarch64
On Tue, Nov 26, 2019 at 2:30 PM Richard Sandiford wrote: > > Andrew Pinski writes: > > On Fri, Aug 18, 2017 at 12:17 PM Andrew Pinski wrote: > >> > >> Like https://gcc.gnu.org/ml/gcc-patches/2010-09/msg00060.html for > >> PowerPC, we should do something similar for aarch64. This pattern > >> does show up in SPEC CPU 2006 in astar but I did not look into > >> performance improvement of it though. > >> > >> OK? Bootstrapped and tested on aarch64-linux-gnu with no regressions. > > > > Ping? I has been over 2 years now too. > > I think it'd better to do this in match.pd, folding to IFN_TRUNC. > The rule will then automatically check whether the target supports > IFN_TRUNC/btrunc_optab for the required mode. Yes I agree, it should be done generically. I will look into doing that for stage 1. Thanks, Andrew > > Thanks, > Richard
[Bug c++/92687] New: decltype of a structured binding to a tuple component is a reference type inside a template function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92687
Bug ID: 92687
Summary: decltype of a structured binding to a tuple component
is a reference type inside a template function
Product: gcc
Version: 9.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: vis...@royal-caliber.com
Target Milestone: ---
Created attachment 47370
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47370=edit
preprocessed file
Hello,
The code below shows an inconsistency in the handling of decltype for
structured bindings within template functions vs. non-template functions - the
static_assert in foo() triggers, but not in bar(). I think the handling in
bar() is correct, as per the notes at
https://en.cppreference.com/w/cpp/language/structured_binding.
This may or may not be related to bug 81176. Details of the compilation command
are listed below the source.
Thank you,
Vishal
#include
#include
template
void foo()
{
auto [x, y] = std::tuple{0, 2};
static_assert(!std::is_reference::value);
}
void bar()
{
auto [x, y] = std::tuple{0, 2};
static_assert(!std::is_reference::value);
}
int main()
{
foo<>();
bar();
}
---
g++-9.2.0 -v -save-temps -pedantic -Wall -Wextra -std=c++17 test.cpp
Using built-in specs.
COLLECT_GCC=g++-9.2.0
COLLECT_LTO_WRAPPER=/usr/libexec/gcc/x86_64-pc-linux-gnu/9.2.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: /var/tmp/portage/sys-devel/gcc-9.2.0/work/gcc-9.2.0/configure
--host=x86_64-pc-linux-gnu --build=x86_64-pc-linux-gnu --prefix=/usr
--bindir=/usr/x86_64-pc-linux-gnu/gcc-bin/9.2.0
--includedir=/usr/lib/gcc/x86_64-pc-linux-gnu/9.2.0/include
--datadir=/usr/share/gcc-data/x86_64-pc-linux-gnu/9.2.0
--mandir=/usr/share/gcc-data/x86_64-pc-linux-gnu/9.2.0/man
--infodir=/usr/share/gcc-data/x86_64-pc-linux-gnu/9.2.0/info
--with-gxx-include-dir=/usr/lib/gcc/x86_64-pc-linux-gnu/9.2.0/include/g++-v9
--with-python-dir=/share/gcc-data/x86_64-pc-linux-gnu/9.2.0/python
--enable-languages=c,c++,fortran --enable-obsolete --enable-secureplt
--disable-werror --with-system-zlib --enable-nls --without-included-gettext
--enable-checking=release --with-bugurl=https://bugs.gentoo.org/
--with-pkgversion='Gentoo 9.2.0 p1' --disable-esp --enable-libstdcxx-time
--enable-shared --enable-threads=posix --enable-__cxa_atexit
--enable-clocale=gnu --disable-multilib --with-multilib-list=m64
--disable-altivec --disable-fixed-point --enable-targets=all --enable-libgomp
--disable-libmudflap --disable-libssp --disable-systemtap
--enable-vtable-verify --enable-lto --without-isl --enable-default-pie
--enable-default-ssp
Thread model: posix
gcc version 9.2.0 (Gentoo 9.2.0 p1)
COLLECT_GCC_OPTIONS='-v' '-save-temps' '-Wpedantic' '-Wall' '-Wextra'
'-std=c++17' '-shared-libgcc' '-mtune=generic' '-march=x86-64'
/usr/libexec/gcc/x86_64-pc-linux-gnu/9.2.0/cc1plus -E -quiet -v -D_GNU_SOURCE
test.cpp -mtune=generic -march=x86-64 -std=c++17 -Wpedantic -Wall -Wextra
-fpch-preprocess -o test.ii
ignoring nonexistent directory "/usr/local/include"
ignoring nonexistent directory
"/usr/lib/gcc/x86_64-pc-linux-gnu/9.2.0/../../../../x86_64-pc-linux-gnu/include"
#include "..." search starts here:
#include <...> search starts here:
/usr/lib/gcc/x86_64-pc-linux-gnu/9.2.0/include/g++-v9
/usr/lib/gcc/x86_64-pc-linux-gnu/9.2.0/include/g++-v9/x86_64-pc-linux-gnu
/usr/lib/gcc/x86_64-pc-linux-gnu/9.2.0/include/g++-v9/backward
/usr/lib/gcc/x86_64-pc-linux-gnu/9.2.0/include
/usr/lib/gcc/x86_64-pc-linux-gnu/9.2.0/include-fixed
/usr/include
End of search list.
COLLECT_GCC_OPTIONS='-v' '-save-temps' '-Wpedantic' '-Wall' '-Wextra'
'-std=c++17' '-shared-libgcc' '-mtune=generic' '-march=x86-64'
/usr/libexec/gcc/x86_64-pc-linux-gnu/9.2.0/cc1plus -fpreprocessed test.ii
-quiet -dumpbase test.cpp -mtune=generic -march=x86-64 -auxbase test -Wpedantic
-Wall -Wextra -std=c++17 -version -o test.s
GNU C++17 (Gentoo 9.2.0 p1) version 9.2.0 (x86_64-pc-linux-gnu)
compiled by GNU C version 9.2.0, GMP version 6.1.2, MPFR version 3.1.6,
MPC version 1.0.3, isl version none
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
GNU C++17 (Gentoo 9.2.0 p1) version 9.2.0 (x86_64-pc-linux-gnu)
compiled by GNU C version 9.2.0, GMP version 6.1.2, MPFR version 3.1.6,
MPC version 1.0.3, isl version none
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
Compiler executable checksum: 2f11227cf3606c8ecdab2bd17fc2bf18
test.cpp: In function ‘void foo()’:
test.cpp:9:17: error: static assertion failed
9 | static_assert(!std::is_reference::value);
| ^~
[PATCH] Fix TYPO of avx512f_maskcmp3.
hi jakub:
VF is used for differentiating AVX512F/AVX/SSE, but there's
condition TARGET_AVX512F in avx512f_maskcmp3, it must be a TYPO
and should be VF_AVX512VL instead.
Bootstrap and regression test on i386/x86_64 backend is ok.
OK for trunk?
diff --git a/gcc/config/i386/sse.md b/gcc/config/i386/sse.md
index 62c68053563..fb43cafaad0 100644
--- a/gcc/config/i386/sse.md
+++ b/gcc/config/i386/sse.md
@@ -3129,8 +3129,8 @@
(define_insn "avx512f_maskcmp3"
[(set (match_operand: 0 "register_operand" "=k")
(match_operator: 3 "sse_comparison_operator"
- [(match_operand:VF 1 "register_operand" "v")
- (match_operand:VF 2 "nonimmediate_operand" "vm")]))]
+ [(match_operand:VF_AVX512VL 1 "register_operand" "v")
+ (match_operand:VF_AVX512VL 2 "nonimmediate_operand" "vm")]))]
"TARGET_AVX512F"
"vcmp%D3\t{%2, %1, %0|%0, %1, %2}"
[(set_attr "type" "ssecmp")
--
BR,
Hongtao
Re: Branch and tag deletions
On Tue, 26 Nov 2019, Eric S. Raymond wrote: > Joseph Myers : > > Thanks. We've accumulated a lot of merge requests on the gcc-conversion > > repository, once those are merged I'll test a further change to remove > > those tags. > > I just checked; a rebase button appeared on your MRs and I merged all > three, but no rebase option occurs on Richard Earnshaw's reqyests. Yes, I managed to locate the (not very obvious) "Allow commits from members who can merge to the target branch." checkbox in the MR edit interface to allow that. -- Joseph S. Myers jos...@codesourcery.com
[Bug target/92686] Inefficient mask operation for 128/256-bit vector VCOND_EXPR under avx512f
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92686 --- Comment #1 from Hongtao.liu --- My local patch shows there's no big performance impact on SPEC2017.
[Bug ipa/92685] In IPA's execute stage create_version_clone_with_body fails with non-vNULL callers
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92685 Erick Ochoa changed: What|Removed |Added Attachment #47367|0 |1 is obsolete|| --- Comment #2 from Erick Ochoa --- Created attachment 47369 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47369=edit Hello World IPA pass (corrected)
[Bug target/92686] New: Inefficient mask operation for 128/256-bit vector VCOND_EXPR under avx512f
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92686
Bug ID: 92686
Summary: Inefficient mask operation for 128/256-bit vector
VCOND_EXPR under avx512f
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: crazylht at gmail dot com
CC: hjl.tools at gmail dot com, wwwhhhyyy333 at gmail dot com
Target Milestone: ---
Target: i386, x86-64
Cat test.c
void mc_weight( unsigned int *__restrict dst, unsigned int *__restrict src1,
int *__restrict src2)
{
for( int x = 0; x < 16; x++ )
dst[x] = src1[x] > src2[x] ? src1[x] : dst[x];
}
With option -Ofast -march=skylake-avx512
gcc using xmm register as mask and using vpblendvb for condition vector move
vmovdqu32 (%rsi), %ymm0
vpminud (%rdx), %ymm0, %ymm1
vpcmpeqd%ymm1, %ymm0, %ymm1
vpblendvb %ymm1, (%rdi), %ymm0, %ymm0
vmovdqu32 %ymm0, (%rdi)
vmovdqu32 32(%rsi), %ymm0
vpminud 32(%rdx), %ymm0, %ymm1
vpcmpeqd%ymm1, %ymm0, %ymm1
vpblendvb %ymm1, 32(%rdi), %ymm0, %ymm0
vmovdqu32 %ymm0, 32(%rdi)
vzeroupper
But there is mask register in avx512f, it could be better as:
vmovdqu (%rsi), %ymm0 #5.25
vmovdqu 32(%rsi), %ymm1 #5.25
vpcmpud $6, (%rdx), %ymm0, %k1#5.25
vpcmpud $6, 32(%rdx), %ymm1, %k2 #5.25
vmovdqu32 %ymm0, (%rdi){%k1}#5.6
vmovdqu32 %ymm1, 32(%rdi){%k2} #5.6
vzeroupper #6.1
ret #6.1
That's because currently gcc only hanlde 512-bit vector
=---
3437 /* In AVX512F the result of comparison is an integer mask. */
3438 bool maskcmp = false;
3439 rtx x;
3440
3441 if (GET_MODE_SIZE (cmp_ops_mode) == 64)
3442{
3443 unsigned int nbits = GET_MODE_NUNITS (cmp_ops_mode);
3444 cmp_mode = int_mode_for_size (nbits, 0).require ();
3445 maskcmp = true;
3446}
3447 else
With additional -mprefer-vector-width=512, gcc have
vmovdqu32 (%rsi), %zmm0
vpminud (%rdx), %zmm0, %zmm1
vpcmpeqd%zmm1, %zmm0, %k1
vmovdqu32 (%rdi), %zmm0{%k1}
vmovdqu32 %zmm0, (%rdi)
vzeroupper
ret
Since mask register is related to isa not vector size, under avx512f we can
also have 128/256-bit vector condition move.
[C++ PATCH] Remember the location of a variable template-id.
I noticed that tsubst of a TEMPLATE_ID_EXPR was losing the location
information from its EXPR_LOCATION. Then I noticed that
cxx_eval_constant_expression was also throwing away location information for
variable references.
Tested x86_64-pc-linux-gnu, applying to trunk.
* pt.c (tsubst_copy_and_build) [TEMPLATE_ID_EXPR]: Remember the
location of a variable template-id.
* constexpr.c (cxx_eval_constant_expression): Get expr location
before stripping location wrappers.
(non_const_var_error): Take location argument.
---
gcc/cp/constexpr.c | 44 +++-
gcc/cp/pt.c | 7 +++-
gcc/testsuite/g++.dg/concepts/pr67595.C | 2 +-
gcc/testsuite/g++.dg/cpp1y/var-templ64.C | 14
4 files changed, 41 insertions(+), 26 deletions(-)
create mode 100644 gcc/testsuite/g++.dg/cpp1y/var-templ64.C
diff --git a/gcc/cp/constexpr.c b/gcc/cp/constexpr.c
index 658455cce96..f648b1d8e4c 100644
--- a/gcc/cp/constexpr.c
+++ b/gcc/cp/constexpr.c
@@ -3786,27 +3786,27 @@ cxx_eval_indirect_ref (const constexpr_ctx *ctx, tree t,
cxx_eval_constant_expression. */
static void
-non_const_var_error (tree r)
+non_const_var_error (location_t loc, tree r)
{
auto_diagnostic_group d;
tree type = TREE_TYPE (r);
if (DECL_NAME (r) == heap_uninit_identifier
|| DECL_NAME (r) == heap_identifier)
{
- error ("the content of uninitialized storage is not usable "
-"in a constant expression");
+ error_at (loc, "the content of uninitialized storage is not usable "
+ "in a constant expression");
inform (DECL_SOURCE_LOCATION (r), "allocated here");
return;
}
if (DECL_NAME (r) == heap_deleted_identifier)
{
- error ("use of allocated storage after deallocation in a "
-"constant expression");
+ error_at (loc, "use of allocated storage after deallocation in a "
+ "constant expression");
inform (DECL_SOURCE_LOCATION (r), "allocated here");
return;
}
- error ("the value of %qD is not usable in a constant "
-"expression", r);
+ error_at (loc, "the value of %qD is not usable in a constant "
+ "expression", r);
/* Avoid error cascade. */
if (DECL_INITIAL (r) == error_mark_node)
return;
@@ -4765,6 +4765,8 @@ cxx_eval_constant_expression (const constexpr_ctx *ctx,
tree t,
return t;
}
+ location_t loc = cp_expr_loc_or_input_loc (t);
+
STRIP_ANY_LOCATION_WRAPPER (t);
if (CONSTANT_CLASS_P (t))
@@ -4794,7 +4796,7 @@ cxx_eval_constant_expression (const constexpr_ctx *ctx,
tree t,
if (++ctx->global->constexpr_ops_count >= constexpr_ops_limit)
{
if (!ctx->quiet)
- error_at (cp_expr_loc_or_input_loc (t),
+ error_at (loc,
"% evaluation operation count exceeds limit of "
"%wd (use %<-fconstexpr-ops-limit=%> to increase the limit)",
constexpr_ops_limit);
@@ -4877,7 +4879,7 @@ cxx_eval_constant_expression (const constexpr_ctx *ctx,
tree t,
if (DECL_P (r))
{
if (!ctx->quiet)
- non_const_var_error (r);
+ non_const_var_error (loc, r);
*non_constant_p = true;
}
break;
@@ -5086,9 +5088,7 @@ cxx_eval_constant_expression (const constexpr_ctx *ctx,
tree t,
jump_target);
if (!CLEANUP_EH_ONLY (t) && !*non_constant_p)
{
- location_t loc = input_location;
- if (EXPR_HAS_LOCATION (t))
- input_location = EXPR_LOCATION (t);
+ iloc_sentinel ils (loc);
/* Also evaluate the cleanup. If we weren't skipping at the
start of the CLEANUP_BODY, change jump_target temporarily
to _jump_target, so that even a return or break or
@@ -5097,7 +5097,6 @@ cxx_eval_constant_expression (const constexpr_ctx *ctx,
tree t,
non_constant_p, overflow_p,
jump_target ? _jump_target
: NULL);
- input_location = loc;
}
}
break;
@@ -5365,7 +5364,7 @@ cxx_eval_constant_expression (const constexpr_ctx *ctx,
tree t,
if (REINTERPRET_CAST_P (t))
{
if (!ctx->quiet)
- error_at (cp_expr_loc_or_input_loc (t),
+ error_at (loc,
"% is not a constant expression");
*non_constant_p = true;
return t;
@@ -5405,7 +5404,7 @@ cxx_eval_constant_expression (const constexpr_ctx *ctx,
tree t,
if (TYPE_REF_P (type))
{
if (!ctx->quiet)
- error_at (cp_expr_loc_or_input_loc (t),
+ error_at (loc,
"dereferencing a null pointer");
*non_constant_p = true;
[Bug ipa/92685] In IPA's execute stage create_version_clone_with_body fails with non-vNULL callers
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92685 --- Comment #1 from Erick Ochoa --- Created attachment 47368 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47368=edit Test Cases
Re: Branch and tag deletions
Joseph Myers : > Thanks. We've accumulated a lot of merge requests on the gcc-conversion > repository, once those are merged I'll test a further change to remove > those tags. I just checked; a rebase button appeared on your MRs and I merged all three, but no rebase option occurs on Richard Earnshaw's reqyests. The GitLab interface seems fickle and arbitrary at times. -- http://www.catb.org/~esr/;>Eric S. Raymond
[Bug ipa/92685] New: In IPA's execute stage create_version_clone_with_body fails with non-vNULL callers
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92685 Bug ID: 92685 Summary: In IPA's execute stage create_version_clone_with_body fails with non-vNULL callers Product: gcc Version: 10.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: ipa Assignee: unassigned at gcc dot gnu.org Reporter: erick.oc...@theobroma-systems.com CC: marxin at gcc dot gnu.org Target Milestone: --- Created attachment 47367 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47367=edit Hello World IPA pass with call to create_version_clone_with_body Hello, I am developing a simple ipa pass that versions a single call site to method `bar`. I am using `create_version_clone_with_body` instead of `create_version_clone` because I want to modify `foo`'s body. In my test case I have three functions * main * foo * bar In my simple ipa pass, I have implemented the execute stage to call `create_version_clone_with_body` for method bar. I am compiling my test with -flto-partition=none, which if I understand correctly means the execution stage should have access to the method bodies. You can apply the patch to master (commit id: 17a2c588c29f089d3c2a36df47175bbdf376e399) I also add my test case. After compiling with my patch, to trigger the bug just modify the Makefile to point to the version of gcc with the patch and `make`.
[Bug c/92684] bitfield behavior not matching the declared type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92684 --- Comment #3 from Andrew Pinski --- There is a defect report dealing with this in C and such. Both are correct for C11 but would be incorrect for C90 which defines bit-field types because of the defect report. GCC decided to follow the C90 way because it is easier to implement one way for both.
[Bug c/92684] bitfield behavior not matching the declared type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92684 --- Comment #2 from Andrew Pinski --- bit-fields in C is a type. while in C++, it is not. So: st.v2 << 3 This is not ((long)st.v2) << 3 but rather (long:45)<<3. So it gets truncated. C11: fff8 0xfff8 1ffffff8 1 2 8000 C++14: fff8 0xfff8 fff8 1 2 8000
[Bug c/92684] bitfield behavior not matching the declared type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92684
Andrew Pinski changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|--- |INVALID
--- Comment #1 from Andrew Pinski ---
-W -Wall:
t.c: In function ‘main’:
t.c:40:3: warning: left shift count >= width of type [enabled by default]
printf("%lx %lx %lx\n", b.bit1, b.bit1 << 1, b.bit1 << 63);
^
t.c:40:3: warning: format ‘%lx’ expects argument of type ‘long unsigned int’,
but argument 2 has type ‘int’ [-Wformat=]
t.c:40:3: warning: format ‘%lx’ expects argument of type ‘long unsigned int’,
but argument 3 has type ‘int’ [-Wformat=]
t.c:40:3: warning: format ‘%lx’ expects argument of type ‘long unsigned int’,
but argument 4 has type ‘int’ [-Wformat=]
[Bug c/92684] New: bitfield behavior not matching the declared type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92684
Bug ID: 92684
Summary: bitfield behavior not matching the declared type
Product: gcc
Version: 9.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: wuxb45 at gmail dot com
Target Milestone: ---
found wrong data when compiled by gcc 9.2.0 (x86_64, -std=gnu11). Have not
tried other gcc versions. The results are correct on clang 8.0.1.
Long story short: some bits are missing when using bitfields with uint64_t as
the declared type. Maybe I should use a (u64) cast on every dereference to
those fields. But the results are not always wrong. Maybe I should read some
C11 specs. But consider the different behaviors between gcc and clang, I decide
to report a bug here in hope to get some better help. Thanks.
This reproduces the results: gcc/clang -std=gnu11 main.c
#include
#include
#include
typedef uint64_t u64;
struct st {
union {
struct {
u64 v1:19;
u64 v2:45;
};
void * ptr;
};
};
struct bits {
u64 bit1:1;
u64 bitx:63;
};
int
main(void)
{
char * val = "0xfff8";
// x has 48 valid bits, the three low bits are 0s
volatile u64 x = strtoull(val, NULL, 16);
printf("%lx\n", x);
// st stores that 45 bits
struct st st = {.v1 = 0, .v2 = (x >> 3)};
printf("%p\n", st.ptr);
// y should get the original bits; but the three high bits are gone.
u64 y = st.v2 << 3;
printf("%lx\n", y);
// this is another (minor) related case.
// some are correct and some are wrong.
struct bits b = {.bit1 = 1, .bitx = 0};
// this is more interesting. gcc shows "8000", clang shows "1"
printf("%lx %lx %lx\n", b.bit1, b.bit1 << 1, b.bit1 << 63);
return 0;
}
[analyzer] Don't use shape=record in .dot output
Recent versions of graphviz reject the .dot files emitted by the analyzer, with messages such as: Warning: flat edge between adjacent nodes one of which has a record shape - replace records with HTML-like labels Edge node_9 -> node_8 The above warning seems to have been added to graphviz on 2014-07-25 in: https://gitlab.com/graphviz/graphviz/commit/763f02ef3cb7fbb62336f372b42279bd63266727 This patch reworks the .dot output from the analyzer so that it works with newer graphviz (tested with graphviz-2.40.1-46.fc30.x86_64), and adds DejaGnu test coverage that the .dot files can be parsed by "dot", if installed on the host. Successfully bootstrapped & regrtested on x86_64-pc-linux-gnu. Pushed to branch "dmalcolm/analyzer" on the GCC git mirror. gcc/ChangeLog: * analyzer/engine.cc (exploded_node::dump_dot): Replace 'shape=record' with 'shape=none,margin=0' and eliminate outermost braces. (viz_callgraph_node::dump_dot): Replace 'shape=record' with 'shape=none,margin=0' and use an HTML-like TABLE label. * analyzer/graphviz.cc (graphviz_out::begin_tr): New function. (graphviz_out::end_tr): New function. * analyzer/graphviz.h (graphviz_out::begin_tr): New decl. (graphviz_out::end_tr): New decl. * analyzer/region-model.cc (region::dump_dot_to_pp): Replace 'shape=record' with 'shape=none,margin=0', and switch to non-record escaping. * analyzer/state-purge.cc (state_purge_annotator::add_node_annotations): Pass in a graphviz_out * rather than a pretty_printer *. Replace 'shape=record' with 'shape=none,margin=0' and eliminate outermost braces. (print_vec_of_names): Pass in a graphviz_out * rather than a pretty_printer *. Wrap the output in a . (state_purge_annotator::add_stmt_annotations): Pass in a graphviz_out * rather than a pretty_printer *. * analyzer/state-purge.h (state_purge_annotator::add_node_annotations): Pass in a graphviz_out * rather than a pretty_printer *. (state_purge_annotator::add_stmt_annotations): Likewise. * analyzer/supergraph.cc (supernode::dump_dot): Update for above annotator changes. Replace 'shape=record' with 'shape=none,margin=0' and convert label to an HTML-like TABLE. * analyzer/supergraph.h (dot_annotator::add_node_annotations): Pass in a graphviz_out * rather than a pretty_printer *. (dot_annotator::add_stmt_annotations): Likewise. * pretty-print.c (pp_write_text_as_html_like_dot_to_stream): New function. * pretty-print.h (pp_write_text_as_html_like_dot_to_stream): New decl. gcc/testsuite/ChangeLog: * gcc.dg/analyzer/dot-output.c: New test. * lib/gcc-defs.exp (dg-check-dot): New procedure. * lib/target-supports-dg.exp (dg-require-dot): New procedure. * lib/target-supports.exp (check_dot_available): New procedure. --- gcc/analyzer/engine.cc | 30 +- gcc/analyzer/graphviz.cc | 20 + gcc/analyzer/graphviz.h| 3 ++ gcc/analyzer/region-model.cc | 6 +-- gcc/analyzer/state-purge.cc| 29 +++-- gcc/analyzer/state-purge.h | 4 +- gcc/analyzer/supergraph.cc | 44 +--- gcc/analyzer/supergraph.h | 4 +- gcc/pretty-print.c | 48 ++ gcc/pretty-print.h | 3 ++ gcc/testsuite/gcc.dg/analyzer/dot-output.c | 33 +++ gcc/testsuite/lib/gcc-defs.exp | 21 ++ gcc/testsuite/lib/target-supports-dg.exp | 10 + gcc/testsuite/lib/target-supports.exp | 13 ++ 14 files changed, 224 insertions(+), 44 deletions(-) create mode 100644 gcc/testsuite/gcc.dg/analyzer/dot-output.c diff --git a/gcc/analyzer/engine.cc b/gcc/analyzer/engine.cc index aa4a3590574d..e02ac7de6577 100644 --- a/gcc/analyzer/engine.cc +++ b/gcc/analyzer/engine.cc @@ -702,10 +702,8 @@ exploded_node::dump_dot (graphviz_out *gv, const dump_args_t ) const pretty_printer *pp = gv->get_pp (); dump_dot_id (pp); - pp_printf (pp, " [shape=%s,style=filled,fillcolor=%s,label=\"", -"record", + pp_printf (pp, " [shape=none,margin=0,style=filled,fillcolor=%s,label=\"", get_dot_fillcolor ()); - pp_left_brace (pp); pp_write_text_to_stream (pp); pp_printf (pp, "EN: %i", m_index); @@ -735,7 +733,6 @@ exploded_node::dump_dot (graphviz_out *gv, const dump_args_t ) const pp_write_text_as_dot_label_to_stream (pp, /*for_record=*/true); - pp_right_brace (pp); pp_string (pp, "\"];\n\n"); pp_flush (pp); } @@ -3125,17 +3122,24 @@ public: pretty_printer *pp = gv->get_pp (); dump_dot_id (pp); -pp_printf (pp, " [shape=%s,style=filled,fillcolor=%s,label=\"", - "record",
Re: [C++ PATCH] Fix ICE in build_ctor_subob_ref during replace_placeholders (PR c++/92524, take 2)
On 11/26/19 6:42 PM, Jakub Jelinek wrote:
On Tue, Nov 26, 2019 at 04:58:01PM -0500, Jason Merrill wrote:
Hmm, we shouldn't have any PLACEHOLDER_EXPR under a RANGE_EXPR; if we did,
any references to its address would end up all referring to the first
element of the range, which would be wrong. How about skipping RANGE_EXPR
in replace_placeholders_r?
So like this?
Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?
OK.
2019-11-27 Jakub Jelinek
PR c++/92524
* tree.c (replace_placeholders_r): Don't walk constructor elts with
RANGE_EXPR indexes.
* g++.dg/cpp0x/pr92524.C: New test.
--- gcc/cp/tree.c.jj2019-11-26 23:09:55.904101392 +0100
+++ gcc/cp/tree.c 2019-11-26 23:13:14.308070759 +0100
@@ -3144,6 +3144,11 @@ replace_placeholders_r (tree* t, int* wa
tree type = TREE_TYPE (*valp);
tree subob = obj;
+ /* Elements with RANGE_EXPR index shouldn't have any
+ placeholders in them. */
+ if (ce->index && TREE_CODE (ce->index) == RANGE_EXPR)
+ continue;
+
if (TREE_CODE (*valp) == CONSTRUCTOR
&& AGGREGATE_TYPE_P (type))
{
--- gcc/testsuite/g++.dg/cpp0x/pr92524.C.jj 2019-11-26 23:09:46.810240310
+0100
+++ gcc/testsuite/g++.dg/cpp0x/pr92524.C2019-11-26 23:09:46.810240310
+0100
@@ -0,0 +1,12 @@
+// PR c++/92524
+// { dg-do compile { target c++11 } }
+
+struct A { char a = '*'; };
+struct B { A b[64]; };
+
+void
+foo ()
+{
+ A a;
+ B{a};
+}
Jakub
Re: [PATCH] Support multi-versioning on self-recursive function (ipa/92133)
Hi, Richard,
This patch is a not bugfix, while it is small. Martin and Honza are fine with
it.
But now we are in stage 3, is it ok to commit?
Thanks,
Feng
From: Feng Xue OS
Sent: Monday, November 25, 2019 10:17 PM
To: Martin Jambor; Jan Hubicka
Cc: luoxhu; gcc-patches@gcc.gnu.org
Subject: Re: [PATCH] Support multi-versioning on self-recursive function
(ipa/92133)
Martin,
Thanks for your review. I updated the patch with your comments.
Feng
---
2019-11-15 Feng Xue
PR ipa/92133
* doc/invoke.texi (ipa-cp-max-recursive-depth): Document new option.
(ipa-cp-min-recursive-probability): Likewise.
* params.opt (ipa-cp-max-recursive-depth): New.
(ipa-cp-min-recursive-probability): Likewise.
* ipa-cp.c (ipcp_lattice::add_value): Add two new parameters
val_p and unlimited.
(self_recursively_generated_p): New function.
(get_val_across_arith_op): Likewise.
(propagate_vals_across_arith_jfunc): Add constant propagation for
self-recursive function.
(incorporate_penalties): Do not penalize pure self-recursive function.
(good_cloning_opportunity_p): Dump node_is_self_scc flag.
(propagate_constants_topo): Set node_is_self_scc flag for cgraph node.
(get_info_about_necessary_edges): Relax hotness check for edge to
self-recursive function.
* ipa-prop.h (ipa_node_params): Add new field node_is_self_scc.
---
> The least important comment: Thanks for providing the ChangeLog but
> sending ChangeLog in the patch itself makes it difficult for people to
> apply the patch because the ChangeLog hunks will never apply cleanly.
> That's why people send them in the email body when they email
> gcc-patches. Hopefully we'll be putting ChangeLogs only into the commit
> message soon and all of this will be a non-issue.
Ok.
>> + if (val_pos_p)
>> +{
>> + for (val = values; val && val != *val_pos_p; val = val->next);
> Please put empty statements on a separate line (I think there is one
> more in the patch IIRC).
Done.
>> + if (val_pos_p)
>> +{
>> + val->next = (*val_pos_p)->next;
>> + (*val_pos_p)->next = val;
>> + *val_pos_p = val;
>> +}
> I must say I am not a big fan of the val_pos_p parameter. Would simply
> putting new values always at the end of the list work to reduce the
> iterations? At this point the function has traversed all the values
> already when searching if it is present, so it can remember the last
> one and just add stuff after it.
We need a parameter to record address of the added value, which will be used
in constructing next one. To place new value at the end of list is a good idea,
thus meaning of val_pos_p becomes simpler, it is only an out parameter now.
>> + if (!src->val || cs->caller != cs->callee->function_symbol ()
>> + || src->val == val)
>> + return false;
> I'd suggest putting the condition calling function_symbol last.
Original condition order can reduce unnecessary evaluations on src->val==val,
which is false in most situation, while cs->caller !=
cs->callee->function_symbol ()
is true.
>> + for (src_val = src_lat->values; src_val && src_val != val;
>> +src_val = src_val->next);
> I think that GNU code style dictates that when a for does not fit on a
> single line, the three bits have to be on a separate line each. Plus
> please put the empty statement on its own line too.
Done.
>> +static tree
>> +get_val_across_arith_op (enum tree_code opcode,
>> + tree opnd1_type,
>> + tree opnd2,
>> + ipcp_value *src_val,
>> + tree res_type)
> The function should get at least a brief comment.
Done.
>> + for (ipcp_value_source *s = src_val->sources; s;
>> +s = s->next)
> I'm afraid you'll have to reformat this for loop too.
Done.
>> + if (self_recursively_generated_p (src_val))
>> + continue;
> I think you are missing a necessary call to
> dest_lat->set_contains_variable() here. Either call it or initialize
> cstval to zero and call get_val_across_arith_op only when
> self_recursively_generated_p returns false;
Yes, this is a bug. Fixed.
0001-Enable-recursive-function-versioning.patch
Description: 0001-Enable-recursive-function-versioning.patch
[PATCH] Reformat PowerPC movdi_internal64
As we discussed in the V6 patches #1 and #2, before submitting the patches adding eI support for movdi and movsi, you prefered that I reformat the patches to make them easier in the future to identify the changes. This patch changes just the movdi_internal64 insn. All of the constraints are in the same order as the current sources. I did add setting "num_insns" to this patch, but I left in setting "length". I found otherwise the Spec benchmarks did not generate the same code with the patch. I have bootstrapped the compiler with this change and the movdi_internal64 patch that will be submitted next, and there were no problems with the bootstrap or tests that regressed. I compared Spec 2017 INT benchmarks and the number of each instruction matches the previous version I tested. Can I check this into the GCC trunk? 2019-11-26 Michael Meissner * config/rs6000/rs6000.md (movdi_internal64): Logically align the columns of constraints and attributes to make it easier to add new patterns in the middle. Set the num_insns insn attribute. Index: gcc/config/rs6000/rs6000.md === --- gcc/config/rs6000/rs6000.md (revision 278747) +++ gcc/config/rs6000/rs6000.md (working copy) @@ -8838,24 +8838,35 @@ (define_split DONE; }) -;; GPR store GPR load GPR move GPR li GPR lis GPR # -;; FPR store FPR load FPR move AVX store AVX store AVX load -;; AVX load VSX move P9 0 P9 -1 AVX 0/-1VSX 0 -;; VSX -1 P9 const AVX const From SPR To SPR SPR<->SPR +;; GPR store GPR load GPR move +;; GPR li GPR lisGPR # +;; FPR store FPR load FPR move +;; AVX store AVX store AVX load AVX load VSX move +;; P9 0 P9 -1 AVX 0/-1 VSX 0 VSX -1 +;; P9 const AVX const +;; From SPR To SPR SPR<->SPR ;; VSX->GPR GPR->VSX + (define_insn "*movdi_internal64" [(set (match_operand:DI 0 "nonimmediate_operand" - "=YZ, r, r, r, r, r, -m, ^d,^d,wY,Z, $v, -$v,^wa, wa,wa,v, wa, -wa,v, v, r, *h, *h, + "=YZ, r, r, +r, r, r, +m, ^d,^d, +wY,Z, $v,$v,^wa, +wa,wa,v, wa,wa, +v, v, +r, *h,*h, ?r,?wa") + (match_operand:DI 1 "input_operand" - "r, YZ,r, I, L, nF, -^d,m, ^d,^v,$v, wY, -Z, ^wa, Oj,wM,OjwM, Oj, -wM,wS,wB,*h,r, 0, + "r, YZ,r, +I, L, nF, +^d,m, ^d,^v,$v, +wY,Z, ^wa, Oj,wM, +OjwM, Oj,wM,wS,wB, +*h,r, 0, wa,r"))] + "TARGET_POWERPC64 && (gpc_reg_operand (operands[0], DImode) || gpc_reg_operand (operands[1], DImode))" @@ -8887,23 +8898,41 @@ (define_insn "*movdi_internal64" mfvsrd %0,%x1 mtvsrd %x0,%1" [(set_attr "type" - "store, load, *, *, *, *, -fpstore,fpload, fpsimple, fpstore, fpstore, fpload, -fpload, veclogical, vecsimple, vecsimple, vecsimple, veclogical, -veclogical, vecsimple, vecsimple, mfjmpr,mtjmpr,*, -mftgpr,mffgpr") + "store, load, *, +*, *, *, +fpstore,fpload,fpsimple, +fpstore,fpstore, fpload, fpload, veclogical, +vecsimple, vecsimple, vecsimple, veclogical, veclogical, +vecsimple, vecsimple, +mfjmpr, mtjmpr,*, +mftgpr, mffgpr") (set_attr "size" "64") (set_attr "length" - "*, *, *, *, *, 20, -*, *, *, *, *, *, -*, *, *, *, *, *, -*, 8, *, *, *, *, -*, *") +"*, *, *, +*, *,
[PATCH] Reformat PowerPC movsi_internal
As we discussed in the V6 patches #1 and #2, before submitting the patches adding eI support for movdi and movsi, you prefered that I reformat the patches to make them easier in the future to identify the changes. This patch changes just the movsi_internal insn. All of the constraints are in the same order as the current sources. I did add setting "num_insns" to this patch, but I left in setting "length". I found otherwise the Spec benchmarks did not generate the same code with the patch. I have bootstrapped the compiler with this change and the movdi_internal64 patch that will be submitted next, and there were no problems with the bootstrap or tests that regressed. I compared Spec 2017 INT benchmarks and the number of each instruction matches the previous version I tested. Can I check this into the GCC trunk? 2019-11-26 Michael Meissner * config/rs6000/rs6000.md (movsi_internal): Logically align the columns of constraints and attributes to make it easier to add new patterns in the middle. Set the num_insns insn attribute. Index: gcc/config/rs6000/rs6000.md === --- gcc/config/rs6000/rs6000.md (revision 278746) +++ gcc/config/rs6000/rs6000.md (working copy) @@ -6889,24 +6889,36 @@ (define_split UNSPEC_MOVSI_GOT))] "") -;; MR LA LWZ LFIWZX LXSIWZX -;; STW STFIWX STXSIWX LI LIS -;; #XXLORXXSPLTIB 0 XXSPLTIB -1 VSPLTISW -;; XXLXOR 0 XXLORC -1P9 const MTVSRWZ MFVSRWZ -;; MF%1 MT%0 NOP +;; MR LA +;; LWZ LFIWZX LXSIWZX +;; STW STFIWX STXSIWX +;; LI LIS # +;; XXLORXXSPLTIB 0 XXSPLTIB -1 VSPLTISW +;; XXLXOR 0 XXLORC -1 P9 const +;; MTVSRWZ MFVSRWZ +;; MF%1 MT%0NOP + (define_insn "*movsi_internal1" [(set (match_operand:SI 0 "nonimmediate_operand" - "=r, r, r, d, v, -m, Z, Z, r, r, -r, wa, wa, wa, v, -wa, v, v, wa, r, -r, *h, *h") + "=r, r, +r, d, v, +m, Z, Z, +r, r, r, +wa, wa, wa, v, +wa, v, v, +wa, r, + r, *h, *h") + (match_operand:SI 1 "input_operand" - "r, U, m, Z, Z, -r, d, v, I, L, -n, wa, O, wM, wB, -O, wM, wS, r, wa, -*h, r, 0"))] +"r, U, +m, Z, Z, +r, d, v, +I, L, n, +wa, O, wM, wB, +O, wM, wS, +r, wa, +*h, r, 0"))] + "gpc_reg_operand (operands[0], SImode) || gpc_reg_operand (operands[1], SImode)" "@ @@ -6934,23 +6946,41 @@ (define_insn "*movsi_internal1" mt%0 %1 nop" [(set_attr "type" - "*, *, load,fpload, fpload, -store, fpstore, fpstore, *, *, -*, veclogical, vecsimple, vecsimple, vecsimple, -veclogical, veclogical, vecsimple, mffgpr, mftgpr, -*, *, *") + "*, *, + load, fpload, fpload, + store, fpstore,fpstore, + *, *, *, + veclogical, vecsimple, vecsimple, vecsimple, + veclogical, veclogical, vecsimple, + mffgpr, mftgpr, + *, *, *") (set_attr "length" - "*, *, *, *, *, -*, *, *, *, *, -8, *, *, *, *, -*, *, 8, *, *, -*, *, *") + "*, *, + *, *, *, + *, *,
Re: [PATCH] Fix gen_lowpart_for_combine (PR rtl-optimization/92510)
Hi! On Wed, Nov 27, 2019 at 12:51:35AM +0100, Jakub Jelinek wrote: > As mentioned in the PR, on the following testcase we ICE during combine. > We have (subreg:V1DI (ne:DI (reg:CC flags) (const_int 0)) 0) and A subreg of something that is not a reg (or mem, if your port still does that) is invalid RTL. Where this did come from? Fix that instead? > gen_lowpart_for_combine turns that into (ne:V1DI (reg:CC flags) (const_int 0)) > which looks wrong to me, Why would that be wrong? > transforming > (subreg:V8QI (ne:DI (reg:CC flags) (const_int 0)) 0) > into > (ne:V8QI (reg:CC flags) (const_int 0)) > looks completely broken to me. The original RTL is invalid already. The patch should be harmless, but your bug is elsewhere? Segher
[Bug libfortran/92100] Formatted stream IO irreproducible read with binary data in file
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92100 Jerry DeLisle changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #14 from Jerry DeLisle --- Fixed on 10, 9, and 8.
[Bug libfortran/92100] Formatted stream IO irreproducible read with binary data in file
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92100 --- Comment #13 from Jerry DeLisle --- Author: jvdelisle Date: Wed Nov 27 00:50:51 2019 New Revision: 278753 URL: https://gcc.gnu.org/viewcvs?rev=278753=gcc=rev Log: 2019-11-26 Jerry DeLisle Backport from mainline PR fortran/92100 io/transfer.c (data_transfer_init): Use fbuf_reset instead of fbuf_flush before the seek. Note that fbuf_reset calls fbuf_flush and adjusts fbuf pointers. gfortran.dg/streamio_18.f90: New test. Added: branches/gcc-8-branch/gcc/testsuite/gfortran.dg/streamio_18.f90 Modified: branches/gcc-8-branch/gcc/testsuite/ChangeLog branches/gcc-8-branch/libgfortran/ChangeLog branches/gcc-8-branch/libgfortran/io/transfer.c
[Bug debug/92664] Wrong .debug_line section information when compiling stdin input with -g3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92664 --- Comment #3 from Jakub Jelinek --- Author: jakub Date: Wed Nov 27 00:23:39 2019 New Revision: 278752 URL: https://gcc.gnu.org/viewcvs?rev=278752=gcc=rev Log: PR debug/92664 * dwarf2out.c (lookup_filename): Use "" instead of "". Modified: trunk/gcc/ChangeLog trunk/gcc/dwarf2out.c
Re: Autoinc vs reload and LRA
On 11/25/19 1:22 PM, Bernd Schmidt wrote: > So I was curious what would happen if I turned on LRA for m68k. It turns > out my autoinc patches from the cc0 patch set expose a bug in how LRA > handles autoincrement. While it copies the logic from reload's > inc_for_reload, it appears to be missing the find_reloads_address code > to ensure an autoinc address is reloaded entirely if it is part of a > jump. LRA can reload just the register inside a POST_INC, which leads to > creating an output reload. > > Hence, a new version of the autoinc changes, below. Since reload is > known to work, we allow autoinc in jumps unless targetm.lra_p. One part > of the patch is a fix for the earlier combine patch which was already > checked in, the other part is a new version of the auto-inc-dec patch. > Bootstrapped and tested on the gcc135 machine > (powerpc64le-unknown-linux-gnu). OK? This is OK. jeff
Re: [PATCH] Fix DWARF -g3 with - as source (PR debug/92664)
On 11/26/19 4:45 PM, Jakub Jelinek wrote: > Hi! > > Without this patch, we emit in .debug_macro with -g3 -xc - > a .file N "" directive which makes e.g. readelf unhappy. > Elsewhere, we handle "" filename as "", so this patch does that too > for .debug_macro. > > Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk? > > 2019-11-27 Jakub Jelinek > > PR debug/92664 > * dwarf2out.c (lookup_filename): Use "" instead of "". OK jeff
[Bug tree-optimization/92683] [10 Regression] strncmp incorrect result with equal substrings and non-const bound
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92683 Martin Sebor changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #2 from Martin Sebor --- Fixed in r278742.
[Bug tree-optimization/83819] [meta-bug] missing strlen optimizations
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83819 Bug 83819 depends on bug 92683, which changed state. Bug 92683 Summary: [10 Regression] strncmp incorrect result with equal substrings and non-const bound https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92683 What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED
[committed] restore a test inadvertently removed in r278621 (PR 92683))
In r278621 I accidentally removed a test that prevented
an optimization from taking place when it wasn't supposed to,
causing test failures in Jeff's mass rebuilds of downstream
packages (e.g., snapd). In r278742 I committed the attached
patch, restoring the test.
Martin
PR tree-optimization/92683 - strncmp incorrect result with equal substrings and non-const bound
gcc/testsuite/ChangeLog:
PR tree-optimization/92683
* gcc.dg/strcmpopt_8.c: New test.
* gcc.dg/strcmpopt_9.c: New test.
gcc/ChangeLog:
PR tree-optimization/92683
* gimple-fold.c (gimple_fold_builtin_string_compare): Restore a test
inadvertently removed in a previous change. Rename local variable
for clarity.
Index: gcc/gimple-fold.c
===
--- gcc/gimple-fold.c (revision 278733)
+++ gcc/gimple-fold.c (working copy)
@@ -2346,15 +2346,16 @@ gimple_fold_builtin_string_compare (gimple_stmt_it
tree str1 = gimple_call_arg (stmt, 0);
tree str2 = gimple_call_arg (stmt, 1);
tree lhs = gimple_call_lhs (stmt);
- tree len = NULL_TREE;
+
+ tree bound_node = NULL_TREE;
unsigned HOST_WIDE_INT bound = HOST_WIDE_INT_M1U;
/* Handle strncmp and strncasecmp functions. */
if (gimple_call_num_args (stmt) == 3)
{
- len = gimple_call_arg (stmt, 2);
- if (tree_fits_uhwi_p (len))
- bound = tree_to_uhwi (len);
+ bound_node = gimple_call_arg (stmt, 2);
+ if (tree_fits_uhwi_p (bound_node))
+ bound = tree_to_uhwi (bound_node);
}
/* If the LEN parameter is zero, return zero. */
@@ -2418,6 +2419,9 @@ gimple_fold_builtin_string_compare (gimple_stmt_it
case BUILT_IN_STRNCMP:
case BUILT_IN_STRNCMP_EQ:
{
+ if (bound == HOST_WIDE_INT_M1U)
+ break;
+
/* Reduce the bound to be no more than the length
of the shorter of the two strings, or the sizes
of the unterminated arrays. */
Index: gcc/testsuite/gcc.dg/strcmpopt_8.c
===
--- gcc/testsuite/gcc.dg/strcmpopt_8.c (nonexistent)
+++ gcc/testsuite/gcc.dg/strcmpopt_8.c (working copy)
@@ -0,0 +1,177 @@
+/* PR tree-optimization/92683 - strncmp incorrect result with equal substrings
+ and nonconst bound
+ { dg-do compile }
+ { dg-options "-O1 -Wall -fdump-tree-forwprop1" } */
+
+#define SIZE_MAX __SIZE_MAX__
+
+#define S123 "123"
+#define S1234 "1234"
+
+typedef __SIZE_TYPE__ size_t;
+
+#ifndef ident
+# define ident(n) n
+#endif
+
+extern void failure_on_line (int);
+
+/* Verify that the test in 'if (EQL strncmp (S, T, N))' is folded. */
+#define T(eql, s, t, n) do { \
+max = ident (n);\
+if (!(eql __builtin_strncmp (s, t, max))) \
+ failure_on_line (__LINE__); \
+ } while (0)
+
+void test_literal (void)
+{
+ size_t max;
+
+ T (0 ==, S123, S1234, 0);
+ T (0 ==, S123, S1234, 1);
+ T (0 ==, S123, S1234, 2);
+ T (0 ==, S123, S1234, 3);
+ T (0 >, S123, S1234, 4);
+ T (0 >, S123, S1234, 5);
+ T (0 >, S123, S1234, SIZE_MAX - 2);
+ T (0 >, S123, S1234, SIZE_MAX - 1);
+ T (0 >, S123, S1234, SIZE_MAX);
+
+ T (0 ==, S123 + 1, S1234, 0);
+ T (0 <, S123 + 1, S1234, 1);
+ T (0 <, S123 + 1, S1234, 2);
+ T (0 <, S123 + 1, S1234, 3);
+ T (0 <, S123 + 1, S1234, 4);
+ T (0 <, S123 + 1, S1234, SIZE_MAX - 2);
+ T (0 <, S123 + 1, S1234, SIZE_MAX - 1);
+ T (0 <, S123 + 1, S1234, SIZE_MAX);
+
+ T (0 ==, S123 + 1, S1234 + 1, 0);
+ T (0 ==, S123 + 1, S1234 + 1, 1);
+ T (0 ==, S123 + 1, S1234 + 1, 2);
+ T (0 >, S123 + 1, S1234 + 1, 3);
+ T (0 >, S123 + 1, S1234 + 1, SIZE_MAX - 1);
+ T (0 >, S123 + 1, S1234 + 1, SIZE_MAX);
+
+ T (0 ==, S123 + 3, S1234 + 1, 0);
+ T (0 >, S123 + 3, S1234 + 1, 1);
+ T (0 >, S123 + 3, S1234 + 1, 2);
+ T (0 >, S123 + 3, S1234 + 1, 3);
+ T (0 >, S123 + 3, S1234 + 1, SIZE_MAX - 1);
+ T (0 >, S123 + 3, S1234 + 1, SIZE_MAX);
+
+ int zero = 0;
+
+ T (zero ==, S123, S1234, 0);
+ T (zero ==, S123, S1234, 1);
+ T (zero ==, S123, S1234, 2);
+ T (zero ==, S123, S1234, 3);
+ T (zero >, S123, S1234, 4);
+ T (zero >, S123, S1234, 5);
+ T (zero >, S123, S1234, SIZE_MAX - 2);
+ T (zero >, S123, S1234, SIZE_MAX - 1);
+ T (zero >, S123, S1234, SIZE_MAX);
+
+ T (zero ==, S123 + 1, S1234, 0);
+ T (zero <, S123 + 1, S1234, 1);
+ T (zero <, S123 + 1, S1234, 2);
+ T (zero <, S123 + 1, S1234, 3);
+ T (zero <, S123 + 1, S1234, 4);
+ T (zero <, S123 + 1, S1234, SIZE_MAX - 2);
+ T (zero <, S123 + 1, S1234, SIZE_MAX - 1);
+ T (zero <, S123 + 1, S1234, SIZE_MAX);
+
+ T (zero ==, S123 + 1, S1234 + 1, 0);
+ T (zero ==, S123 + 1, S1234 + 1, 1);
+ T (zero ==, S123 + 1, S1234 + 1, 2);
+ T (zero >, S123 + 1, S1234 + 1, 3);
+ T (zero >, S123 + 1, S1234 + 1, SIZE_MAX - 1);
+ T (zero >, S123 + 1, S1234 + 1, SIZE_MAX);
+
+ T (zero ==, S123 + 3, S1234 + 1, 0);
+ T (zero >, S123 + 3, S1234 + 1, 1);
+ T (zero >, S123 + 3, S1234 + 1, 2);
+ T (zero >, S123 + 3, S1234 + 1, 3);
+ T (zero >, S123 + 3, S1234 + 1,
[PATCH] Fix spread simplification in initializers (PR fortran/91944)
Hi!
The following testcase started ICEing with my r241630 PR78026 fix.
Before we created a new namespace and the check gfc_simplify_spread did
happened to work during that, but it doesn't anymore.
I believe gfc_init_expr_flag is the right flag to use when checking if
something has to be folded at compile time and we can't defer it to runtime
expansion.
Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?
2019-11-27 Jakub Jelinek
PR fortran/91944
* simplify.c (gfc_simplify_spread): Check gfc_init_expr_flag instead
of gfc_current_ns->sym_root->n.sym->attr.flavor == FL_PARAMETER.
* gfortran.dg/spread_size_limit_2.f90: New test.
--- gcc/fortran/simplify.c.jj 2019-11-25 22:44:26.127328111 +0100
+++ gcc/fortran/simplify.c 2019-11-26 17:32:26.963525721 +0100
@@ -7656,7 +7656,7 @@ gfc_simplify_spread (gfc_expr *source, g
nelem = mpz_get_si (size) * ncopies;
if (nelem > flag_max_array_constructor)
{
- if (gfc_current_ns->sym_root->n.sym->attr.flavor == FL_PARAMETER)
+ if (gfc_init_expr_flag)
{
gfc_error ("The number of elements (%d) in the array constructor "
"at %L requires an increase of the allowed %d upper "
--- gcc/testsuite/gfortran.dg/spread_size_limit_2.f90.jj2019-11-26
17:47:25.578719250 +0100
+++ gcc/testsuite/gfortran.dg/spread_size_limit_2.f90 2019-11-26
17:40:48.881815325 +0100
@@ -0,0 +1,11 @@
+! PR fortran/91944
+! { dg-do compile }
+! { dg-options "-fmax-array-constructor=65535" }
+
+program pr91944
+ integer, parameter :: n = 10
+ integer, parameter :: m = 65536
+ integer :: i
+ integer :: x(n,m) = spread([(i,i=1,n)], dim=2, ncopies=m)! { dg-error
"requires an increase of the allowed 65535 upper limit" }
+ print *, x(n,m)
+end
Jakub
[Bug tree-optimization/92683] [10 Regression] strncmp incorrect result with equal substrings and non-const bound
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92683 --- Comment #1 from Martin Sebor --- Author: msebor Date: Tue Nov 26 23:56:22 2019 New Revision: 278742 URL: https://gcc.gnu.org/viewcvs?rev=278742=gcc=rev Log: PR tree-optimization/92683 - strncmp incorrect result with equal substrings and non-const bound gcc/testsuite/ChangeLog: PR tree-optimization/92683 * gcc.dg/strcmpopt_8.c: New test. * gcc.dg/strcmpopt_9.c: New test. gcc/ChangeLog: PR tree-optimization/92683 * gimple-fold.c (gimple_fold_builtin_string_compare): Restore a test inadvertently removed in a previous change. Rename local variable for clarity. Added: trunk/gcc/testsuite/gcc.dg/strcmpopt_8.c trunk/gcc/testsuite/gcc.dg/strcmpopt_9.c Modified: trunk/gcc/ChangeLog trunk/gcc/gimple-fold.c trunk/gcc/testsuite/ChangeLog
[PATCH] Fix gen_lowpart_for_combine (PR rtl-optimization/92510)
Hi!
As mentioned in the PR, on the following testcase we ICE during combine.
We have (subreg:V1DI (ne:DI (reg:CC flags) (const_int 0)) 0) and
gen_lowpart_for_combine turns that into (ne:V1DI (reg:CC flags) (const_int 0))
which looks wrong to me, later on the if_then_else simplifications try to
simplify (subreg:V1DI (const_int 1) 0) with DImode as the inner mode and
native_encode_rtx ICEs.
As gen_lowpart_for_combine exits early for imode == omode, I think the
optimization to change the type of comparison is only useful for scalar
integral modes, for say vector modes we need the element mode to be the same
as well as the number of units to be meaningful, say
transforming
(subreg:V8QI (ne:DI (reg:CC flags) (const_int 0)) 0)
into
(ne:V8QI (reg:CC flags) (const_int 0))
looks completely broken to me.
Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?
2019-11-27 Jakub Jelinek
PR rtl-optimization/92510
* combine.c (gen_lowpart_for_combine): Only transform lowpart subreg
of comparison into a comparison with different mode if both imode and
omode are scalar integral modes.
* gcc.dg/pr92510.c: New test.
--- gcc/combine.c.jj2019-11-25 11:33:41.538074339 +0100
+++ gcc/combine.c 2019-11-26 15:55:35.433676263 +0100
@@ -11808,7 +11808,9 @@ gen_lowpart_for_combine (machine_mode om
/* If X is a comparison operator, rewrite it in a new mode. This
probably won't match, but may allow further simplifications. */
- else if (COMPARISON_P (x))
+ else if (COMPARISON_P (x)
+ && SCALAR_INT_MODE_P (imode)
+ && SCALAR_INT_MODE_P (omode))
return gen_rtx_fmt_ee (GET_CODE (x), omode, XEXP (x, 0), XEXP (x, 1));
/* If we couldn't simplify X any other way, just enclose it in a
--- gcc/testsuite/gcc.dg/pr92510.c.jj 2019-11-26 16:04:17.492688012 +0100
+++ gcc/testsuite/gcc.dg/pr92510.c 2019-11-26 15:52:28.035538275 +0100
@@ -0,0 +1,16 @@
+/* PR rtl-optimization/92510 */
+/* { dg-do compile } */
+/* { dg-options "-O1 -ftree-loop-vectorize -fno-forward-propagate
-fno-tree-scev-cprop" } */
+
+int v;
+
+long int
+foo (long int x)
+{
+ signed char i;
+
+ for (i = 0; i < 8; ++i)
+x |= !!v;
+
+ return x + i;
+}
Jakub
GCC test failures due to GDB session errors?
Every now and then I see test suite failures in my builds that I can't reproduce when I then execute the tests individually via a make check target. In the test log there often (always?) are the following messages around those failures: &"warning: GDB: Failed to set controlling terminal: Operation not permitted\n" FAIL: gcc.dg/torture/pr56488.c -Os (test for excess errors) Excess errors: &"warning: GDB: Failed to set controlling terminal: Operation not permitted\n" I run the tests on the same machine I develop and debug GCC on at the same time, but that's all in separate directories (i.e., separate sources and separate build directory for each). Is it possible that these GDB messages are getting intercepted by the test run somehow and causing these failures? Is there some way to avoid them? Martin PS My GDB is GNU gdb (GDB) Fedora 8.2-7.fc29.
[PATCH] Fix DWARF -g3 with - as source (PR debug/92664)
Hi! Without this patch, we emit in .debug_macro with -g3 -xc - a .file N "" directive which makes e.g. readelf unhappy. Elsewhere, we handle "" filename as "", so this patch does that too for .debug_macro. Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk? 2019-11-27 Jakub Jelinek PR debug/92664 * dwarf2out.c (lookup_filename): Use "" instead of "". --- gcc/dwarf2out.c.jj 2019-10-17 08:44:08.594363833 +0200 +++ gcc/dwarf2out.c 2019-11-26 12:35:46.419184285 +0100 @@ -27118,6 +27118,9 @@ lookup_filename (const char *file_name) if (!file_name) return NULL; + if (!file_name[0]) +file_name = ""; + dwarf_file_data **slot = file_table->find_slot_with_hash (file_name, htab_hash_string (file_name), INSERT); Jakub
[C++ PATCH] Fix ICE in build_ctor_subob_ref during replace_placeholders (PR c++/92524, take 2)
On Tue, Nov 26, 2019 at 04:58:01PM -0500, Jason Merrill wrote:
> Hmm, we shouldn't have any PLACEHOLDER_EXPR under a RANGE_EXPR; if we did,
> any references to its address would end up all referring to the first
> element of the range, which would be wrong. How about skipping RANGE_EXPR
> in replace_placeholders_r?
So like this?
Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?
2019-11-27 Jakub Jelinek
PR c++/92524
* tree.c (replace_placeholders_r): Don't walk constructor elts with
RANGE_EXPR indexes.
* g++.dg/cpp0x/pr92524.C: New test.
--- gcc/cp/tree.c.jj2019-11-26 23:09:55.904101392 +0100
+++ gcc/cp/tree.c 2019-11-26 23:13:14.308070759 +0100
@@ -3144,6 +3144,11 @@ replace_placeholders_r (tree* t, int* wa
tree type = TREE_TYPE (*valp);
tree subob = obj;
+ /* Elements with RANGE_EXPR index shouldn't have any
+ placeholders in them. */
+ if (ce->index && TREE_CODE (ce->index) == RANGE_EXPR)
+ continue;
+
if (TREE_CODE (*valp) == CONSTRUCTOR
&& AGGREGATE_TYPE_P (type))
{
--- gcc/testsuite/g++.dg/cpp0x/pr92524.C.jj 2019-11-26 23:09:46.810240310
+0100
+++ gcc/testsuite/g++.dg/cpp0x/pr92524.C2019-11-26 23:09:46.810240310
+0100
@@ -0,0 +1,12 @@
+// PR c++/92524
+// { dg-do compile { target c++11 } }
+
+struct A { char a = '*'; };
+struct B { A b[64]; };
+
+void
+foo ()
+{
+ A a;
+ B{a};
+}
Jakub
Re: [PATCH], V7, #7 of 7, Turn on -mpcrel for Linux 64-bit, but not for other targets
On Thu, Nov 14, 2019 at 06:14:47PM -0500, Michael Meissner wrote:
> * config/rs6000/linux64.h (TARGET_PREFIXED_ADDR_DEFAULT): Enable
> prefixed addressing by default.
> (TARGET_PCREL_DEFAULT): Enable pc-relative addressing by default.
> * config/rs6000/rs6000-cpus.def (ISA_FUTURE_MASKS_SERVER): Only
> enable -mprefixed-addr and -mpcrel if the OS tm.h says to enable
> it.
> (ADDRESSING_FUTURE_MASKS): New mask macro.
> (OTHER_FUTURE_MASKS): Use ADDRESSING_FUTURE_MASKS.
> * config/rs6000/rs6000.c (TARGET_PREFIXED_ADDR_DEFAULT): Do not
> enable -mprefixed-addr unless the OS tm.h says to.
> (TARGET_PCREL_DEFAULT): Do not enable -mpcrel unless the OS tm.h
> says to.
> (rs6000_option_override_internal): Do not enable -mprefixed-addr
> or -mpcrel unless the OS tm.h says to enable it. Add more checks
> for -mcpu=future.
> +/* Support for a future processor's features. The prefixed and pc-relative
> + addressing bits are not added here. Instead, rs6000.c adds them if the OS
> + tm.h says that it supports the addressing modes. */
This comment could be a lot clearer. It should just say it is about
ADRESSING_FUTURE_MASKS, and not mention rs6000.c at all.
> #define ISA_FUTURE_MASKS_SERVER (ISA_3_0_MASKS_SERVER
> \
> - | OPTION_MASK_FUTURE \
> + | OPTION_MASK_FUTURE)
> +
> +/* Addressing related flags on a future processor. These flags are broken
> out
> + because not all targets will support either pc-relative addressing, or
> even
> + prefixed addressing, and we want to clear all of the addressing bits
> + on targets that cannot support prefixed/pcrel addressing. */
> +#define ADDRESSING_FUTURE_MASKS (OPTION_MASK_PCREL
> \
>| OPTION_MASK_PREFIXED_ADDR)
> --- gcc/config/rs6000/rs6000.c(revision 278181)
> +++ gcc/config/rs6000/rs6000.c(working copy)
> @@ -98,6 +98,16 @@
> #endif
> #endif
>
> +/* Set up the defaults for whether prefixed addressing is used, and if it is
> + used, whether we want to turn on pc-relative support by default. */
> +#ifndef TARGET_PREFIXED_ADDR_DEFAULT
> +#define TARGET_PREFIXED_ADDR_DEFAULT 0
> +#endif
> +
> +#ifndef TARGET_PCREL_DEFAULT
> +#define TARGET_PCREL_DEFAULT 0
> +#endif
"DEFAULT" is a bad name for this? "SUPPORTED"?
We do *not* turn on prefixed or pcrel by default on most linux64 targets
-- most of those are p9 or p8 or p7 or older! So "SUPPORTED" isn't good
either. SUPPORTED_BY_OS?
A name like "XXX_DEFAULT" inevitably means we will later get an
"XXX_REALLY_DEFAULT" macro as well. Not good.
> + /* Enable prefixed addressing and pc-relative addressing on 64-bit ELF v2
> + systems if the OS tm.h file says that it is supported and the user did
> not
> + explicitly use -mprefixed-addr or -mpcrel. At the present time, only
> + 64-bit Linux enables this.
> + /* Enable defaults if desired. */
This comment does not say anything. Please say something like "Enable
PCREL and PREFIXED if [...]"
> + else
> + {
> + if (!explicit_prefixed
> + && (TARGET_PREFIXED_ADDR_DEFAULT
> + || TARGET_PCREL
> + || TARGET_PCREL_DEFAULT))
> + rs6000_isa_flags |= OPTION_MASK_PREFIXED_ADDR;
> +
> + if (!explicit_pcrel && TARGET_PCREL_DEFAULT
> + && TARGET_CMODEL == CMODEL_MEDIUM)
> + rs6000_isa_flags |= OPTION_MASK_PCREL;
> + }
> +}
... and I don't understand this code. If you use -mpcrel but you do not
have the medium model, you _do_ get prefixed but you do _not_ get pcrel?
And this all quietly?
Segher
Re: [PATCH 2/4] The main m68k cc0 conversion
On Tue, 26 Nov 2019, Bernd Schmidt wrote: > On 11/26/19 3:21 AM, Joseph Myers wrote: > > > > The soft-float ColdFire build (--with-arch=cf --with-cpu=54455 > > --disable-multilib) successfully built libgcc and glibc, but ran into an > > ICE building the glibc tests. Again, I've not bisected but this commit > > seems likely to be responsible. Compile the attached preprocessed source > > with -O2. > > Try the following. This seems to be the same (preexisting) problem which > got fixed for the normal 68k compare patterns, where an operand with > nonimmediate_operand predicate allows constants in its constraints. I confirm that this and the previous patch together allow both the ColdFire configurations in build-many-glibcs.py to complete clean builds of GCC, glibc and glibc tests. -- Joseph S. Myers jos...@codesourcery.com
[Bug c/92671] gcc/c/c-parser.c: minor ( and ) tidyup
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92671 --- Comment #1 from joseph at codesourcery dot com --- I don't think this is a confusing case of precedence, i.e. the proposed change is not an improvement.
[Bug libfortran/92100] Formatted stream IO irreproducible read with binary data in file
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92100 --- Comment #12 from Jerry DeLisle --- Author: jvdelisle Date: Tue Nov 26 22:56:24 2019 New Revision: 278740 URL: https://gcc.gnu.org/viewcvs?rev=278740=gcc=rev Log: 2019-11-26 Jerry DeLisle Backport from mainline PR fortran/92100 io/transfer.c (data_transfer_init_worker): Use fbuf_reset instead of fbuf_flush before the seek. Note that fbuf_reset calls fbuf_flush and adjusts fbuf pointers. gfortran.dg/streamio_18.f90: New test. Added: branches/gcc-9-branch/gcc/testsuite/gfortran.dg/streamio_18.f90 Modified: branches/gcc-9-branch/gcc/testsuite/ChangeLog branches/gcc-9-branch/libgfortran/ChangeLog branches/gcc-9-branch/libgfortran/io/transfer.c
[Bug testsuite/92622] FAIL: gcc.dg/Warray-bounds-22.c on ILP32: missing warnings for VLA on lines 67 and 69
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92622
--- Comment #1 from Martin Sebor ---
The failure doesn't seem to be reliably reproducible. Of the three times the
script below runs the test it fails just once.
$ for i in 1 2 3; do nice time make -C /build/gcc-git-svn/gcc check-c
'CFLAGS=-O0 -g3' 'CXXFLAGS=-O0 -g3' 'STAGE1_CFLAGS=-O0 -g3'
'STAGE1_CXXFLAGS=-O0 -g3' RUNTESTFLAGS="dg.exp=Warray-bounds-22.c
--target_board=unix/-m32"; done
make: Entering directory '/ssd/build/gcc-git-svn/gcc'
rm -rf testsuite/gcc-parallel
make[1]: Entering directory '/ssd/build/gcc-git-svn/gcc'
(rootme=`${PWDCMD-pwd}`; export rootme; \
srcdir=`cd /src/gcc/git-svn/gcc; ${PWDCMD-pwd}` ; export srcdir ; \
if [ -n "" ] \
&& [ -n "$GCC_RUNTEST_PARALLELIZE_DIR" ] \
&& [ -f testsuite/gcc-parallel/finished ]; then \
rm -rf testsuite/gcc; \
else \
cd testsuite/gcc; \
rm -f tmp-site.exp; \
sed '/set tmpdir/ s|testsuite$|testsuite/gcc|' \
< ../../site.exp > tmp-site.exp; \
/bin/sh ${srcdir}/../move-if-change tmp-site.exp site.exp; \
EXPECT=`if [ -f ${rootme}/../expect/expect ] ; then echo
${rootme}/../expect/expect ; else echo expect ; fi` ; export EXPECT ; \
if [ -f ${rootme}/../expect/expect ] ; then \
TCL_LIBRARY=`cd .. ; cd ${srcdir}/../tcl/library ; ${PWDCMD-pwd}` ; \
export TCL_LIBRARY ; \
fi ; \
`if [ -f ${srcdir}/../dejagnu/runtest ] ; then echo
${srcdir}/../dejagnu/runtest ; else echo runtest; fi` --tool gcc
dg.exp=Warray-bounds-22.c --target_board=unix/-m32; \
if [ -n "$GCC_RUNTEST_PARALLELIZE_DIR" ] ; then \
touch ${rootme}/testsuite/gcc-parallel/finished; \
fi ; \
fi )
WARNING: Couldn't find the global config file.
Test run by msebor on Tue Nov 26 15:39:30 2019
Native configuration is x86_64-pc-linux-gnu
=== gcc tests ===
Schedule of variations:
unix/-m32
Running target unix/-m32
Using /usr/share/dejagnu/baseboards/unix.exp as board description file for
target.
Using /usr/share/dejagnu/config/unix.exp as generic interface file for target.
Using /src/gcc/git-svn/gcc/testsuite/config/default.exp as
tool-and-target-specific interface file.
Running /src/gcc/git-svn/gcc/testsuite/gcc.dg/dg.exp ...
=== gcc Summary ===
# of expected passes15
# of expected failures 8
/ssd/build/gcc-git-svn/gcc/xgcc version 10.0.0 20191126 (experimental) (GCC)
make[1]: Leaving directory '/ssd/build/gcc-git-svn/gcc'
make: Leaving directory '/ssd/build/gcc-git-svn/gcc'
0.63user 0.14system 0:00.94elapsed 83%CPU (0avgtext+0avgdata 39292maxresident)k
0inputs+128outputs (0major+60721minor)pagefaults 0swaps
make: Entering directory '/ssd/build/gcc-git-svn/gcc'
rm -rf testsuite/gcc-parallel
make[1]: Entering directory '/ssd/build/gcc-git-svn/gcc'
(rootme=`${PWDCMD-pwd}`; export rootme; \
srcdir=`cd /src/gcc/git-svn/gcc; ${PWDCMD-pwd}` ; export srcdir ; \
if [ -n "" ] \
&& [ -n "$GCC_RUNTEST_PARALLELIZE_DIR" ] \
&& [ -f testsuite/gcc-parallel/finished ]; then \
rm -rf testsuite/gcc; \
else \
cd testsuite/gcc; \
rm -f tmp-site.exp; \
sed '/set tmpdir/ s|testsuite$|testsuite/gcc|' \
< ../../site.exp > tmp-site.exp; \
/bin/sh ${srcdir}/../move-if-change tmp-site.exp site.exp; \
EXPECT=`if [ -f ${rootme}/../expect/expect ] ; then echo
${rootme}/../expect/expect ; else echo expect ; fi` ; export EXPECT ; \
if [ -f ${rootme}/../expect/expect ] ; then \
TCL_LIBRARY=`cd .. ; cd ${srcdir}/../tcl/library ; ${PWDCMD-pwd}` ; \
export TCL_LIBRARY ; \
fi ; \
`if [ -f ${srcdir}/../dejagnu/runtest ] ; then echo
${srcdir}/../dejagnu/runtest ; else echo runtest; fi` --tool gcc
dg.exp=Warray-bounds-22.c --target_board=unix/-m32; \
if [ -n "$GCC_RUNTEST_PARALLELIZE_DIR" ] ; then \
touch ${rootme}/testsuite/gcc-parallel/finished; \
fi ; \
fi )
WARNING: Couldn't find the global config file.
Test run by msebor on Tue Nov 26 15:39:31 2019
Native configuration is x86_64-pc-linux-gnu
=== gcc tests ===
Schedule of variations:
unix/-m32
Running target unix/-m32
Using /usr/share/dejagnu/baseboards/unix.exp as board description file for
target.
Using /usr/share/dejagnu/config/unix.exp as generic interface file for target.
Using /src/gcc/git-svn/gcc/testsuite/config/default.exp as
tool-and-target-specific interface file.
Running /src/gcc/git-svn/gcc/testsuite/gcc.dg/dg.exp ...
FAIL: gcc.dg/Warray-bounds-22.c vla (test for warnings, line 67)
FAIL: gcc.dg/Warray-bounds-22.c vla (test for warnings, line 69)
=== gcc Summary ===
# of expected passes13
# of unexpected failures2
# of expected failures 8
/ssd/build/gcc-git-svn/gcc/xgcc version 10.0.0 20191126 (experimental) (GCC)
make[1]: Leaving directory '/ssd/build/gcc-git-svn/gcc'
make: Leaving directory '/ssd/build/gcc-git-svn/gcc'
0.65user 0.13system 0:00.94elapsed 83%CPU (0avgtext+0avgdata 3
Re: [PATCH] Fix libstdc++ compiling for an aarch64 multilib with big-endian.
On 26/11/19 22:22 +, Richard Sandiford wrote: + libstd...@gcc.gnu.org writes: From: Andrew Pinski Hi if we have a aarch64 compiler that has a big-endian multi-lib, it fails to compile libstdc++ because simd_fast_mersenne_twister_engine is only defined for little-endian in ext/random but ext/opt_random.h thinks it is defined always. OK? Built an aarch64-elf toolchain which has a big-endian multi-lib enabled. Looks good to me in the sense that I see the same preprocessor conditions you see. OK if no libstdc++ maintainer tells us it's the wrong fix in the next 24 hrs. Looks right. The #if could even be moved earlier, as the __VEXT macros don't seem to be used anywhere except that file. If most of the file gets skipped for big endian, that macro isn't needed either (and it looks like the __ARM_BIG_ENDIAN version of it is never used at all). No harm leaving the macro though, so as far as I'm concerned the patch is fine.
[Bug tree-optimization/92683] [10 Regression] strncmp incorrect result with equal substrings and non-const bound
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92683 Martin Sebor changed: What|Removed |Added Keywords||wrong-code Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2019-11-26 Blocks||83819 Assignee|unassigned at gcc dot gnu.org |msebor at gcc dot gnu.org Target Milestone|--- |10.0 Ever confirmed|0 |1 Referenced Bugs: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83819 [Bug 83819] [meta-bug] missing strlen optimizations
[Bug tree-optimization/92683] New: [10 Regression] strncmp incorrect result with equal substrings and non-const bound
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92683
Bug ID: 92683
Summary: [10 Regression] strncmp incorrect result with equal
substrings and non-const bound
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: msebor at gcc dot gnu.org
Target Milestone: ---
r278621 introduced a bug where a non-constant bound in calls to strncmp is
treated incorrectly as if it were a constant greater than the length of either
argument.
$ cat t.c && gcc -O1 -S -Wall -Wextra -Wunused
-fdump-tree-forwprop1=/dev/stdout t.c
int f (void)
{
return __builtin_strncmp ("123", "1234", 3); // correctly folded to zero
}
int g (void)
{
int n = 3;
return __builtin_strncmp ("123", "1234", n); // incorrectly folded to -1
}
;; Function f (f, funcdef_no=0, decl_uid=1930, cgraph_uid=1, symbol_order=0)
f ()
{
:
return 0;
}
;; Function g (g, funcdef_no=1, decl_uid=1933, cgraph_uid=2, symbol_order=1)
g ()
{
int n;
:
return -1;
}
Re: [PATCH/AARCH64] Generate FRINTZ for (double)(long) under -ffast-math on aarch64
Andrew Pinski writes: > On Fri, Aug 18, 2017 at 12:17 PM Andrew Pinski wrote: >> >> Like https://gcc.gnu.org/ml/gcc-patches/2010-09/msg00060.html for >> PowerPC, we should do something similar for aarch64. This pattern >> does show up in SPEC CPU 2006 in astar but I did not look into >> performance improvement of it though. >> >> OK? Bootstrapped and tested on aarch64-linux-gnu with no regressions. > > Ping? I has been over 2 years now too. I think it'd better to do this in match.pd, folding to IFN_TRUNC. The rule will then automatically check whether the target supports IFN_TRUNC/btrunc_optab for the required mode. Thanks, Richard
Re: [PATCH] Fix libstdc++ compiling for an aarch64 multilib with big-endian.
+ libstd...@gcc.gnu.org
writes:
> From: Andrew Pinski
>
> Hi if we have a aarch64 compiler that has a big-endian
> multi-lib, it fails to compile libstdc++ because
> simd_fast_mersenne_twister_engine is only defined for little-endian
> in ext/random but ext/opt_random.h thinks it is defined always.
>
> OK? Built an aarch64-elf toolchain which has a big-endian multi-lib enabled.
Looks good to me in the sense that I see the same preprocessor
conditions you see. OK if no libstdc++ maintainer tells us it's
the wrong fix in the next 24 hrs.
Thanks,
Richard
>
> Thanks,
> Andrew Pinski
>
> libstdc++/ChangeLog:
> * config/cpu/aarch64/opt/ext/opt_random.h: Wrap around with check
> for little-endian like ext/random is done.
>
> Signed-off-by: Andrew Pinski
> ---
> libstdc++-v3/config/cpu/aarch64/opt/ext/opt_random.h | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/libstdc++-v3/config/cpu/aarch64/opt/ext/opt_random.h
> b/libstdc++-v3/config/cpu/aarch64/opt/ext/opt_random.h
> index 696a6d18ab4..9eca9b7df74 100644
> --- a/libstdc++-v3/config/cpu/aarch64/opt/ext/opt_random.h
> +++ b/libstdc++-v3/config/cpu/aarch64/opt/ext/opt_random.h
> @@ -44,6 +44,7 @@
> _C+8, _C+9, _C+10, _C+11, _C+12, _C+13, _C+14, _C+15})
> #endif
>
> +#if __BYTE_ORDER__ == __ORDER_LITTLE_ENDIAN__
> namespace __gnu_cxx _GLIBCXX_VISIBILITY (default)
> {
> _GLIBCXX_BEGIN_NAMESPACE_VERSION
> @@ -175,6 +176,7 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
> _GLIBCXX_END_NAMESPACE_VERSION
>} // namespace
>
> +#endif // __BYTE_ORDER__ == __ORDER_LITTLE_ENDIAN__
> #endif // __ARM_NEON
>
> #endif // _EXT_OPT_RANDOM_H
Re: Branch and tag deletions
On Tue, 26 Nov 2019, Eric S. Raymond wrote: > Joseph Myers : > > A further note: in a previous run of the conversion I didn't see any > > emptycommit-* tags. In my most recent conversion run, I see 4070 such > > tags. How do I tell reposurgeon never to create such tags? Or should I > > add a tag deletion command for them in gcc.lift, once tag deletion is > > working reliably? > > That's what tag deletion by regexp is for. Thanks. We've accumulated a lot of merge requests on the gcc-conversion repository, once those are merged I'll test a further change to remove those tags. -- Joseph S. Myers jos...@codesourcery.com
Re: [vect][testsuite] Update vect_char_add target selector to use its own cache
Joel Hutton writes:
> Hi all,
>
> This patch updates the vect_char_add target selector to use its own
> cache instead of the vect_int cache.
>
> This was causing a situation where bb-slp-40.c would fail on sparc when
> run after other tests that use the vect_int target selector, but pass
> when run on its own.
>
> This fixes Bug 92391
>
> Tested on x86 and sparc64.
>
> 2019-11-26 Joel Hutton
>
> * lib/target-supports.exp: Update vect_char_add target selector
> to use its own cache.
Thanks, applied as r278738.
Richard
>
> From 7ed08950f4440f8605b9df1114edcc8ee834 Mon Sep 17 00:00:00 2001
> From: Joel Hutton
> Date: Tue, 26 Nov 2019 17:09:12 +
> Subject: [PATCH] Update vect_char_add target selector to use its own cache
>
> ---
> gcc/testsuite/lib/target-supports.exp | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/gcc/testsuite/lib/target-supports.exp
> b/gcc/testsuite/lib/target-supports.exp
> index
> 5fe1e83492cae97adf82ed53e12d8f5f7ea5a951..a4418a3151677a2a45275463b9828db7e7755b28
> 100644
> --- a/gcc/testsuite/lib/target-supports.exp
> +++ b/gcc/testsuite/lib/target-supports.exp
> @@ -5753,7 +5753,7 @@ proc check_effective_target_vect_bswap { } {
> # one vector length.
>
> proc check_effective_target_vect_char_add { } {
> -return [check_cached_effective_target_indexed vect_int {
> +return [check_cached_effective_target_indexed vect_char_add {
>expr {
> [istarget i?86-*-*] || [istarget x86_64-*-*]
> || ([istarget powerpc*-*-*]
[Bug testsuite/92391] gcc.dg/vect/bb-slp-40.c FAILs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92391 --- Comment #12 from rsandifo at gcc dot gnu.org --- Author: rsandifo Date: Tue Nov 26 22:11:39 2019 New Revision: 278738 URL: https://gcc.gnu.org/viewcvs?rev=278738=gcc=rev Log: Update vect_char_add target selector to use its own cache This patch updates the vect_char_add target selector to use its own cache instead of the vect_int cache. This was causing a situation where bb-slp-40.c would fail on sparc when run after other tests that use the vect_int target selector, but pass when run on its own. 2019-11-26 Joel Hutton gcc/testsuite/ PR testsuite/92391 * lib/target-supports.exp (check_effective_target_vect_char_add): Use a separate cache entry from vect_int. Modified: trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/lib/target-supports.exp
[Bug c++/92648] Handling of unknown attributes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92648 --- Comment #2 from Jakub Jelinek --- Author: jakub Date: Tue Nov 26 21:58:22 2019 New Revision: 278737 URL: https://gcc.gnu.org/viewcvs?rev=278737=gcc=rev Log: PR c++/92648 * parser.c (cp_parser_std_attribute): For unknown attributes, skip balanced token seq instead of trying to parse attribute-argument-clause as expression list. Formatting fix. * g++.dg/cpp0x/gen-attrs-71.C: New test. Added: trunk/gcc/testsuite/g++.dg/cpp0x/gen-attrs-71.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/parser.c trunk/gcc/testsuite/ChangeLog
[Bug c++/61414] enum class bitfield size-checking needs a separate warning flag controlling it
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61414 --- Comment #23 from Jakub Jelinek --- Author: jakub Date: Tue Nov 26 21:57:27 2019 New Revision: 278736 URL: https://gcc.gnu.org/viewcvs?rev=278736=gcc=rev Log: PR c++/61414 * c-attribs.c (handle_mode_attribute): Add mode attribute to ENUMERAL_TYPEs. * class.c (enum_to_min_precision): New hash_map. (enum_min_precision): New function. (check_bitfield_decl): Use it. * g++.dg/cpp0x/enum23.C: Remove xfail. * g++.dg/cpp0x/enum28.C: New test. Added: trunk/gcc/testsuite/g++.dg/cpp0x/enum38.C Modified: trunk/gcc/c-family/ChangeLog trunk/gcc/c-family/c-attribs.c trunk/gcc/cp/ChangeLog trunk/gcc/cp/class.c trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/g++.dg/cpp0x/enum23.C
Re: [C++ PATCH] Fix ICE in build_ctor_subob_ref during replace_placeholders (PR c++/92524)
On 11/22/19 9:19 AM, Jakub Jelinek wrote:
Hi!
On the following testcase, replace_placeholders is called on a CONSTRUCTOR
{ a, [1..63] = NON_LVALUE_EXPR<42> }
and call build_ctor_subob_ref in that case. The problem is that index is
RANGE_EXPR and as it is not INTEGER_CST, we call
build_class_member_access_expr which is not appropriate for array indexes.
cp_build_array_ref will not really work with RANGE_EXPR either, the
following patch just usesthe low bound of the range. At least when trying
to read it, it should be equivalent to any other value in the range.
Hmm, we shouldn't have any PLACEHOLDER_EXPR under a RANGE_EXPR; if we
did, any references to its address would end up all referring to the
first element of the range, which would be wrong. How about skipping
RANGE_EXPR in replace_placeholders_r?
Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?
2019-11-22 Jakub Jelinek
PR c++/92524
* tree.c (build_ctor_subob_ref): For RANGE_EXPR index, build
array reference for the low bound.
* g++.dg/cpp0x/pr92524.C: New test.
--- gcc/cp/tree.c.jj2019-11-16 18:13:28.571821577 +0100
+++ gcc/cp/tree.c 2019-11-21 12:22:27.260660874 +0100
@@ -3064,6 +3064,10 @@ build_ctor_subob_ref (tree index, tree t
obj = NULL_TREE;
else if (TREE_CODE (index) == INTEGER_CST)
obj = cp_build_array_ref (input_location, obj, index, tf_none);
+ else if (TREE_CODE (index) == RANGE_EXPR)
+/* Use low bound for ranges. */
+obj = cp_build_array_ref (input_location, obj, TREE_OPERAND (index, 0),
+ tf_none);
else
obj = build_class_member_access_expr (obj, index, NULL_TREE,
/*reference*/false, tf_none);
--- gcc/testsuite/g++.dg/cpp0x/pr92524.C.jj 2019-11-21 12:34:53.350406680
+0100
+++ gcc/testsuite/g++.dg/cpp0x/pr92524.C2019-11-21 12:34:18.943925681
+0100
@@ -0,0 +1,12 @@
+// PR c++/92524
+// { dg-do compile { target c++11 } }
+
+struct A { char a = '*'; };
+struct B { A b[64]; };
+
+void
+foo ()
+{
+ A a;
+ B{a};
+}
Jakub
Re: [PATCH][_GLIBCXX_DEBUG] Improve valid_range check
On 26/11/19 20:07 +0100, François Dumont wrote:
On 11/26/19 1:21 PM, Jonathan Wakely wrote:
On 26/11/19 12:33 +0100, Stephan Bergmann wrote:
On 22/11/2019 18:59, Jonathan Wakely wrote:
On 22/11/19 18:38 +0100, François Dumont wrote:
I noticed that we are not checking that iterators are not
singular in valid_range. Moreover __check_singular signature
for pointers is not intercepting all kind of pointers in terms
of qualification.
I'd like to commit it next week but considering we are in
stage 3 I need proper acceptance.
* include/debug/functions.h: Remove include.
(__check_singular_aux, __check_singular): Move...
* include/debug/helper_functions.h:
(__check_singular_aux, __check_singular): ...here.
(__valid_range_aux): Adapt to use latter.
* testsuite/25_algorithms/copy/debug/2_neg.cc: New.
Tested under Linux x86_64 normal and debug modes.
OK for trunk, thanks.
The curly braces...
diff --git a/libstdc++-v3/include/debug/helper_functions.h
b/libstdc++-v3/include/debug/helper_functions.h
index c3e7478f649..5a858754875 100644
--- a/libstdc++-v3/include/debug/helper_functions.h
+++ b/libstdc++-v3/include/debug/helper_functions.h
[...]
@@ -138,14 +156,23 @@ namespace __gnu_debug
inline bool
__valid_range_aux(_InputIterator __first, _InputIterator __last,
std::input_iterator_tag)
- { return true; }
+ {
+ if (__first != __last)
+ return !__check_singular(__first) && !__check_singular(__last);
+
+ return true;
+ }
template
_GLIBCXX_CONSTEXPR
inline bool
__valid_range_aux(_InputIterator __first, _InputIterator __last,
std::random_access_iterator_tag)
- { return __first <= __last; }
+ {
+ return
+ __valid_range_aux(__first, __last, std::input_iterator_tag{})
...^^^ here...
+ && __first <= __last;
+ }
/** We have iterators, so figure out what kind of iterators they are
* to see if we can check the range ahead of time.
@@ -167,6 +194,9 @@ namespace __gnu_debug
typename _Distance_traits<_InputIterator>::__type&
__dist,
std::__false_type)
{
+ if (!__valid_range_aux(__first, __last,
std::input_iterator_tag{}))
...and ^^^ here are not allowed pre C++11. Replacing those with
std::input_iterator_tag()
should fix it.
Indeed. We should also have tests that use "-std=gnu++98
-D_GLIBCXX_DEBUG" so they'd catch this.
François, can you take care of the fix please?
Sure, I am about to do so.
However I wasn't sure about this syntax before the commit so I had run
the new 2_neg.cc with:
make CXXFLAGS=-std=c++98 check-debug
and it worked fine and still is !
The testsuite doesn't use CXXFLAGS.
I also try -std=gnu++98 and made sure that pch had been updated by
re-building libstdc++ first. I just can't get the expected compilation
error.
Maybe I need to rebuild the whole stuff to get an error...
No, you need to pass the right flags so they are used by the
testsuite. This will do it:
make -C testsuite/ check-debug
debug_flags=unix/-D_GLIBCXX_DEBUG/-std=gnu++98/-Wsystem-headers
But since it only shows up with -Wsystem-headers, there's no point
trying to test for it.
Re: [C++ PATCH] Fix up parsing of attribute-argument-clause of unknown attributes (PR c++/92648)
On 11/25/19 6:41 PM, Jakub Jelinek wrote:
Hi!
The standard says that argument-attribute-clause is:
attribute-argument-clause:
( balanced-token-seq[opt] )
balanced-token-seq:
balanced-token
balanced-token-seq balanced-token
balanced-token:
( balanced-token-seq[opt] )
[ balanced-token-seq[opt] ]
{ balanced-token-seq[opt] }
any token other than a parenthesis, a bracket, or a brace
but the C++ FE parses the attribute arguments always as an expression list
with the exception of identifier kept as is in certain cases.
That is just fine for all attributes we support right now, but what
arguments can have attributes of other compilers or not yet invented
attributes and how they should be parsed is unknown, so the only option is
IMHO to skip the balanced token set. That is also what the C FE does and
what e.g. clang++ seems to do.
I'm not using cp_parser_skip_to_closing_parenthesis in the patch, because
cp_parser_skip_to_closing_parenthesis_1 has code to handle ?: specially and
I believe given the current grammar and that the argument doesn't have to be
necessarily an expression it is wrong, e.g.
[[whatever::whatever_else(???)]] could in theory be valid.
The primary reason for this change is that OpenMP 5.1 is likely going to
have some form of [[omp::... (arguments)]] attributes and the arguments
being considered there would be rejected by the current parser.
Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?
OK.
2019-11-26 Jakub Jelinek
PR c++/92648
* parser.c (cp_parser_std_attribute): For unknown attributes,
skip balanced token seq instead of trying to parse
attribute-argument-clause as expression list. Formatting fix.
* g++.dg/cpp0x/gen-attrs-71.C: New test.
--- gcc/cp/parser.c.jj 2019-11-22 09:33:08.899909913 +0100
+++ gcc/cp/parser.c 2019-11-25 18:29:06.230699448 +0100
@@ -26629,6 +26629,15 @@ cp_parser_std_attribute (cp_parser *pars
/* A GNU attribute that takes an identifier in parameter. */
attr_flag = id_attr;
+if (as == NULL)
+ {
+ /* For unknown attributes, just skip balanced tokens instead of
+ trying to parse the arguments. */
+ for (size_t n = cp_parser_skip_balanced_tokens (parser, 1) - 1; n; --n)
+ cp_lexer_consume_token (parser->lexer);
+ return attribute;
+ }
+
vec = cp_parser_parenthesized_expression_list
(parser, attr_flag, /*cast_p=*/false,
/*allow_expansion_p=*/true,
@@ -26637,7 +26646,7 @@ cp_parser_std_attribute (cp_parser *pars
arguments = error_mark_node;
else
{
- if (vec->is_empty())
+ if (vec->is_empty ())
/* e.g. [[attr()]]. */
error_at (token->location, "parentheses must be omitted if "
"%qE attribute argument list is empty",
--- gcc/testsuite/g++.dg/cpp0x/gen-attrs-71.C.jj2019-11-25
18:22:09.486082583 +0100
+++ gcc/testsuite/g++.dg/cpp0x/gen-attrs-71.C 2019-11-25 18:31:14.695730765
+0100
@@ -0,0 +1,7 @@
+// PR c++/92648
+// { dg-do compile { target c++11 } }
+
+int a [[gnu::no_such_attribute(![!(!)!]!,;;)]];// { dg-warning
"ignored" }
+int b [[no_such_namespace::nonexisting_attribute(linear(c, d : 2), reduction(*:e),
linear(uval (f)))]];// { dg-warning "ignored" }
+int c [[gnu::nonexisting_attribute()]];// { dg-warning "ignored" }
+int d [[gnu::another_nonexistent_attr(1,"abcd",g+6)]]; // { dg-warning
"ignored" }
Jakub
Re: [C++ PATCH] Fix up is too small to hold all values of enum warning (PR c++/61414)
On 11/25/19 6:32 PM, Jakub Jelinek wrote:
Hi!
On Mon, Nov 25, 2019 at 03:46:23PM +0100, Jakub Jelinek wrote:
On Mon, Nov 25, 2019 at 03:39:32PM +0100, Jakub Jelinek wrote:
I guess the question is, shall we store the minimum precision needed
somewhere by finish_enum_value_list (perhaps only bother if the precision
of the underlying type is not the same) or compute it each time again
(which would mean for each bitfield of enum type walk the list of all the
enum values)? And, if we should store it somewhere, any preferences where?
These days C++ FE has TYPE_LANG_SPECIFIC just for classes, so options are
just use the class TYPE_LANG_SPECIFIC and just stick the min/max values in
some trees in there, restore having different lang specific variants and
store just minimum precision in there, add hash map from tree (hashed using
TYPE_UID) to precision, something else?
Or yet another possibility, only compute it on demand and use a hash map as
cache.
Here is that option implemented, bootstrapped/regtested on x86_64-linux and
i686-linux, ok for trunk?
OK, thanks.
2019-11-26 Jakub Jelinek
PR c++/61414
* c-attribs.c (handle_mode_attribute): Add mode attribute to
ENUMERAL_TYPEs.
* class.c (enum_to_min_precision): New hash_map.
(enum_min_precision): New function.
(check_bitfield_decl): Use it.
* g++.dg/cpp0x/enum23.C: Remove xfail.
* g++.dg/cpp0x/enum28.C: New test.
--- gcc/c-family/c-attribs.c.jj 2019-11-23 11:05:50.813492164 +0100
+++ gcc/c-family/c-attribs.c2019-11-25 16:47:35.317750531 +0100
@@ -1866,6 +1866,7 @@ handle_mode_attribute (tree *node, tree
typefm = make_signed_type (TYPE_PRECISION (typefm));
TREE_TYPE (typefm) = type;
}
+ *no_add_attrs = false;
}
else if (VECTOR_MODE_P (mode)
? TREE_CODE (type) != TREE_CODE (TREE_TYPE (typefm))
--- gcc/cp/class.c.jj 2019-11-16 18:13:42.844606979 +0100
+++ gcc/cp/class.c 2019-11-25 16:42:15.050633229 +0100
@@ -3265,6 +3265,60 @@ add_implicitly_declared_members (tree t,
}
}
+/* Cache of enum_min_precision values. */
+static GTY((deletable)) hash_map *enum_to_min_precision;
+
+/* Return the minimum precision of a bit-field needed to store all
+ enumerators of ENUMERAL_TYPE TYPE. */
+
+static int
+enum_min_precision (tree type)
+{
+ type = TYPE_MAIN_VARIANT (type);
+ /* For unscoped enums without fixed underlying type and without mode
+ attribute we can just use precision of the underlying type. */
+ if (UNSCOPED_ENUM_P (type)
+ && !ENUM_FIXED_UNDERLYING_TYPE_P (type)
+ && !lookup_attribute ("mode", TYPE_ATTRIBUTES (type)))
+return TYPE_PRECISION (ENUM_UNDERLYING_TYPE (type));
+
+ if (enum_to_min_precision == NULL)
+enum_to_min_precision = hash_map::create_ggc (37);
+
+ bool existed;
+ int prec = enum_to_min_precision->get_or_insert (type, );
+ if (existed)
+return prec;
+
+ tree minnode, maxnode;
+ if (TYPE_VALUES (type))
+{
+ minnode = maxnode = NULL_TREE;
+ for (tree values = TYPE_VALUES (type);
+ values; values = TREE_CHAIN (values))
+ {
+ tree decl = TREE_VALUE (values);
+ tree value = DECL_INITIAL (decl);
+ if (value == error_mark_node)
+ value = integer_zero_node;
+ if (!minnode)
+ minnode = maxnode = value;
+ else if (tree_int_cst_lt (maxnode, value))
+ maxnode = value;
+ else if (tree_int_cst_lt (value, minnode))
+ minnode = value;
+ }
+}
+ else
+minnode = maxnode = integer_zero_node;
+
+ signop sgn = tree_int_cst_sgn (minnode) >= 0 ? UNSIGNED : SIGNED;
+ int lowprec = tree_int_cst_min_precision (minnode, sgn);
+ int highprec = tree_int_cst_min_precision (maxnode, sgn);
+ prec = MAX (lowprec, highprec);
+ return prec;
+}
+
/* FIELD is a bit-field. We are finishing the processing for its
enclosing type. Issue any appropriate messages and set appropriate
flags. Returns false if an error has been diagnosed. */
@@ -3326,7 +3380,7 @@ check_bitfield_decl (tree field)
"width of %qD exceeds its type", field);
else if (TREE_CODE (type) == ENUMERAL_TYPE)
{
- int prec = TYPE_PRECISION (ENUM_UNDERLYING_TYPE (type));
+ int prec = enum_min_precision (type);
if (compare_tree_int (w, prec) < 0)
warning_at (DECL_SOURCE_LOCATION (field), 0,
"%qD is too small to hold all values of %q#T",
--- gcc/testsuite/g++.dg/cpp0x/enum23.C.jj 2013-02-16 09:31:06.400506406
+0100
+++ gcc/testsuite/g++.dg/cpp0x/enum23.C 2019-11-25 16:51:19.532332223 +0100
@@ -5,5 +5,5 @@ enum class MyEnum { A = 1 };
struct MyClass
{
- MyEnum Field1 : 3; // { dg-bogus "warning: 'MyClass::Field1' is too small"
"" { xfail *-*-* } }
+ MyEnum Field1 : 3; // { dg-bogus "warning: 'MyClass::Field1' is too small" }
};
---
Re: [C++ Patch] More accurate locations in cp_build_unary_op and cp_build_compound_expr
On 11/25/19 3:34 PM, Paolo Carlini wrote: Hi, a bunch of straightforward tweaks: let's use the available location in some additional places. Tested x86_64-linux, as usual. Thanks, Paolo. /// OK.
Re: [PATCH] Prevent recursive satisfaction (PR c++/88395)
On 11/18/19 10:18 AM, Andrew Sutton wrote:
I forgot to mention a somewhat odd test included in the patch:
concepts-recursive-sat3.C does not recurse. Code follows:
template
concept Fooable = requires(T t) { foo(t); };
template
void foo(T t) { }
void test()
{
foo(0); // { dg-error "unsatisfied constraints" }
}
It doesn't crash, but it doesn't diagnose also doesn't fail as a
result of recursive instantiation. The recursive-sat2.C test is the
same except that it instantiates foo with a class type. This seems
like it might be related to ADL, but entirely certain.
Yes; since 0 has non-class type, we don't do ADL to find a declaration
of foo, and there were no declarations of foo before the call in
Fooable, so the call fails.
Jason
[Patch] PR 92463 - Cleanups due to minimum MPFR version bump to 3.1.0
Recently, Janne bumped the minimal MPFR version from 2.4 to 3.1. As a
follow-up cleanup, the mp_ data types can now be changed to mpfr_ and
GMP_RNDx rounding to MPFR_RNDx (with an additional MPFR_RNDA).
This patch changes the types in the middle end and a left over from
previous patch round in Fortran. However, I have not touched the MPFR
users in GO.
See https://www.mpfr.org/mpfr-3.0.0/#changes for the 2.4 to 3.0 changes.
("mp_rnd_t may be removed in the future").
Bootstrapped and regtested on x86-64-gnu-linux.
OK for the trunk?
Tobias
PR middle-end/92463
* configure.ac: Use MPFR_RNDN instead of GMP's MP_RNDN.
* configure: Regenerate
gcc/
PR middle-end/92463
* builtins.c (do_mpfr_ckconv, do_mpc_ckconv, do_mpfr_remquo,
do_mpfr_lgamma_r, do_mpc_arg2): Use MPFR_RNDx instead of GMP_RNDx,
mpfr_rnd_t instead of mp_rnd_t.
* fold-const-call.c (do_mpfr_ckconv, do_mpfr_arg1, do_mpfr_sincos,
do_mpfr_arg2, do_mpfr_arg3, do_mpc_arg1, do_mpc_arg2): Likewise.
* gimple-ssa-sprintf.c (format_floating_max, format_floating):
Use mpfr_exp_t instead of mp_exp_t.
* real.c (real_from_string, dconst_e_ptr, dconst_sqrt2_ptr): Use
MPFR_RNDx instead of GMP_RNDx.
* realmpfr.c (real_from_mpfr, mpfr_from_real): Use mpfr_rnd_t and
mpfr_exp_t instead mp_rnd_t and mp_exp_t, respectively.
* realmpfr.h (real_from_mpfr, mpfr_from_real): Use mpfr_rnd_t instead
of mp_rnd_t and remove MPFR_RNDx poisoning.
* ubsan.c (ubsan_instrument_float_cast): MPFR_RNDx instead of GMP_RNDx.
fortran/
PR middle-end/92463
* arith.c (gfc_check_real_range): Replace mp_exp_t by mpfr_exp_t.
diff --git a/configure b/configure
index 00f7487e2e9..f6027397ced 100755
--- a/configure
+++ b/configure
@@ -5865,9 +5865,9 @@ main ()
int t;
mpfr_init (n);
mpfr_init (x);
-mpfr_atan2 (n, n, x, GMP_RNDN);
-mpfr_erfc (n, x, GMP_RNDN);
-mpfr_subnormalize (x, t, GMP_RNDN);
+mpfr_atan2 (n, n, x, MPFR_RNDN);
+mpfr_erfc (n, x, MPFR_RNDN);
+mpfr_subnormalize (x, t, MPFR_RNDN);
mpfr_clear(n);
mpfr_clear(x);
mpc_init2 (c, 53);
diff --git a/configure.ac b/configure.ac
index 29e25f13278..50e2fa135b1 100644
--- a/configure.ac
+++ b/configure.ac
@@ -1641,9 +1641,9 @@ if test -d ${srcdir}/gcc && test "x$have_gmp" = xno; then
int t;
mpfr_init (n);
mpfr_init (x);
-mpfr_atan2 (n, n, x, GMP_RNDN);
-mpfr_erfc (n, x, GMP_RNDN);
-mpfr_subnormalize (x, t, GMP_RNDN);
+mpfr_atan2 (n, n, x, MPFR_RNDN);
+mpfr_erfc (n, x, MPFR_RNDN);
+mpfr_subnormalize (x, t, MPFR_RNDN);
mpfr_clear(n);
mpfr_clear(x);
mpc_init2 (c, 53);
diff --git a/gcc/builtins.c b/gcc/builtins.c
index 8296d846171..36319a97b52 100644
--- a/gcc/builtins.c
+++ b/gcc/builtins.c
@@ -11045,7 +11045,7 @@ do_mpfr_ckconv (mpfr_srcptr m, tree type, int inexact)
{
REAL_VALUE_TYPE rr;
- real_from_mpfr (, m, type, GMP_RNDN);
+ real_from_mpfr (, m, type, MPFR_RNDN);
/* Proceed iff GCC's REAL_VALUE_TYPE can hold the MPFR value,
check for overflow/underflow. If the REAL_VALUE_TYPE is zero
but the mpft_t is not, then we underflowed in the
@@ -11085,8 +11085,8 @@ do_mpc_ckconv (mpc_srcptr m, tree type, int inexact, int force_convert)
{
REAL_VALUE_TYPE re, im;
- real_from_mpfr (, mpc_realref (m), TREE_TYPE (type), GMP_RNDN);
- real_from_mpfr (, mpc_imagref (m), TREE_TYPE (type), GMP_RNDN);
+ real_from_mpfr (, mpc_realref (m), TREE_TYPE (type), MPFR_RNDN);
+ real_from_mpfr (, mpc_imagref (m), TREE_TYPE (type), MPFR_RNDN);
/* Proceed iff GCC's REAL_VALUE_TYPE can hold the MPFR values,
check for overflow/underflow. If the REAL_VALUE_TYPE is zero
but the mpft_t is not, then we underflowed in the
@@ -11138,14 +11138,14 @@ do_mpfr_remquo (tree arg0, tree arg1, tree arg_quo)
{
const struct real_format *fmt = REAL_MODE_FORMAT (TYPE_MODE (type));
const int prec = fmt->p;
- const mp_rnd_t rnd = fmt->round_towards_zero? GMP_RNDZ : GMP_RNDN;
+ const mpfr_rnd_t rnd = fmt->round_towards_zero? MPFR_RNDZ : MPFR_RNDN;
tree result_rem;
long integer_quo;
mpfr_t m0, m1;
mpfr_inits2 (prec, m0, m1, NULL);
- mpfr_from_real (m0, ra0, GMP_RNDN);
- mpfr_from_real (m1, ra1, GMP_RNDN);
+ mpfr_from_real (m0, ra0, MPFR_RNDN);
+ mpfr_from_real (m1, ra1, MPFR_RNDN);
mpfr_clear_flags ();
mpfr_remquo (m0, _quo, m0, m1, rnd);
/* Remquo is independent of the rounding mode, so pass
@@ -11218,13 +11218,13 @@ do_mpfr_lgamma_r (tree arg, tree arg_sg, tree type)
{
const struct real_format *fmt = REAL_MODE_FORMAT (TYPE_MODE (type));
const int prec = fmt->p;
- const mp_rnd_t rnd = fmt->round_towards_zero? GMP_RNDZ : GMP_RNDN;
+ const mpfr_rnd_t rnd = fmt->round_towards_zero? MPFR_RNDZ : MPFR_RNDN;
int inexact, sg;
mpfr_t m;
tree result_lg;
mpfr_init2 (m, prec);
- mpfr_from_real (m, ra, GMP_RNDN);
+ mpfr_from_real (m, ra, MPFR_RNDN);
mpfr_clear_flags ();
inexact
Re: [PATCH] Prevent recursive satisfaction (PR c++/88395)
On 11/18/19 10:13 AM, Andrew Sutton wrote: This applies on top of the patch here: https://gcc.gnu.org/ml/gcc-patches/2019-11/msg01034.html Wrap satisfaction with push/pop_tinst_level to force termination on recursion. + if (tmpl) + push_tinst_level (tmpl); Actually, why not pass 't' here? Jason
Re: [PATCH] PR c++/92439: Improve diagnostics for ill-formed requires-clauses
On 11/22/19 10:28 AM, Andrew Sutton wrote: This does a much better job identifying when an expression in a requires-clause needs parentheses. Andrew Sutton OK. Jason
Re: [PATCH] PR c++/92236: Improve static assertions of concepts
On 11/20/19 10:45 AM, Andrew Sutton wrote:
This patch builds on https://gcc.gnu.org/ml/gcc-patches/2019-11/msg01034.html.
Tie static assertion diagnostics into constraint diagnostic. For
example, this program:
template
concept iterator =
requires (I i)
{
++i;
*i;
};
static_assert(iterator);
Yields these errors:
x.cpp:11:15: error: static assertion failed
11 | static_assert(iterator);
| ^
x.cpp:11:15: note: constraints not satisfied
x.cpp:4:9: required by the constraints of ‘template concept iterator’
x.cpp:5:3: in requirements with ‘int i’
x.cpp:8:5: note: the required expression ‘* i’ is invalid
8 | *i;
| ^~
Andrew Sutton
OK.
Jason
Re: [PATCH] Prevent recursive satisfaction (PR c++/88395)
On 11/18/19 10:13 AM, Andrew Sutton wrote: This applies on top of the patch here: https://gcc.gnu.org/ml/gcc-patches/2019-11/msg01034.html Wrap satisfaction with push/pop_tinst_level to force termination on recursion. Andrew Sutton OK.
Re: [PATCH] Diagnose hard errors during constraint satisfaction
On 11/13/19 8:28 AM, Andrew Sutton wrote: This changes the diagnostic of non-boolean constraints and rvalue conversion failures in constraint satisfaction into hard errors. I also cleaned up the satisfaction routines to reduce the number of functions involved. Jason, this is a squashed version of the patches I sent earlier today. This patch also fixes the crash PR92439, which was caused by not building the normalization tree in satisfy_constraint_expression. However, there are some other problems with that example that cause it to not compile (e.g., non-boolean atomic constraints). Andrew Sutton OK.
[Bug libfortran/92100] Formatted stream IO irreproducible read with binary data in file
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92100 --- Comment #11 from Jerry DeLisle --- > Modified: > trunk/gcc/ChangeLog Hi hit the wrong log file for the testsuite entry. It has been fixed.
[Bug target/92682] [10 Regression] maxlocval_4.f90 / minlocval_4.f90 failure on POWER9
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92682 Thomas Koenig changed: What|Removed |Added Status|UNCONFIRMED |WAITING Last reconfirmed||2019-11-26 CC||seurer at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #1 from Thomas Koenig --- Hmmm... seems like a local problem with the test result setup. I can not reproduce this on gcc135.fsffrance.org. Bill, since I based this on your results (possibly prematurely): Could you maybe check your setup what is going on here?
Re: [PATCH][_GLIBCXX_DEBUG] Improve valid_range check
On 11/26/19 9:49 PM, Stephan Bergmann wrote: On 26/11/2019 20:07, François Dumont wrote: However I wasn't sure about this syntax before the commit so I had run the new 2_neg.cc with: make CXXFLAGS=-std=c++98 check-debug and it worked fine and still is ! I also try -std=gnu++98 and made sure that pch had been updated by re-building libstdc++ first. I just can't get the expected compilation error. Maybe I need to rebuild the whole stuff to get an error... I saw the error with recent Clang and -std=gnu++98. Recent GCC indeed seems to give at most a warning. Ok, thanks for the feedback, gcc might be more permissive then. Whatever I committed the fix an hour ago.
Re: [EXTERNAL] Re: How to test aarch64 when building a cross-compiler?
On 11/25/19 2:43 PM, Andrew Dean via gcc wrote: >> I get errors like this: >> >> aarch64-glibc-linux-gnu-gcc: fatal error: cannot read spec file >> 'rdimon.specs': No such file or directory >> >> I can see that the rdimon.specs flag is added based on this line >> in aarch64- > sim.exp: > > Where does aarch64-sim.exp comes from? /usr/share/dejagnu/baseboards/aarch64-sim.exp > >> >> set_board_info ldflags "[libgloss_link_flags] [newlib_link_flags] >> - > specs=rdimon.specs" >> > I think this is for baremetal/newlib targets, ie. aarch64-elf, not > for aarch64- linux-gnu. >> >> Yes -specs=rdimon.specs and other such flags are for use only on bare-metal >> targets. >> Hmm.. build-many-glibcs.py doesn't like either aarch64-elf or aarch64-linux- >> elf... I get a KeyError in build_compilers and build_glibcs when it tries to look up >> the config with either of those values. >>> >>> Unfortunately the build-many-glibcs.py does not have support for >>> baremetal build yet (since it is a tool created to build >>> cross-compiling toolchain using glibc). >> >> And glibc doesn't work bare-metal .. >> >> regards >> Ramana > I guess that means that the dejagnu baseboard "aarch64-sim" is only meant to > do bare-metal testing? How would one build/test GCC hosted on x86_64 and > targeting aarch64 then? Is there a different simulator approach I should be > using? I've used qemu for this kind of testing. In my environment I have root filesystems with native binaries/libraries. I can just chroot into those filesystems and qemu handles everything. In theory one wouldn't even need to chroot into the filesystems if you set the library paths right. jeff
Re: [PATCH][_GLIBCXX_DEBUG] Improve valid_range check
On 26/11/2019 20:07, François Dumont wrote: However I wasn't sure about this syntax before the commit so I had run the new 2_neg.cc with: make CXXFLAGS=-std=c++98 check-debug and it worked fine and still is ! I also try -std=gnu++98 and made sure that pch had been updated by re-building libstdc++ first. I just can't get the expected compilation error. Maybe I need to rebuild the whole stuff to get an error... I saw the error with recent Clang and -std=gnu++98. Recent GCC indeed seems to give at most a warning.
[Bug c++/48078] accepts-invalid: taking address of private member function from template function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=48078
fkostenzer at live dot at changed:
What|Removed |Added
CC||fkostenzer at live dot at
--- Comment #6 from fkostenzer at live dot at ---
This can also be triggered on gcc 9 using
```
class A
{
int foo() const { return 42; }
};
template
struct B : public A
{
static constexpr auto member_fn = ::foo;
};
int main()
{
return (A().*B<>::member_fn)();
}
```
running `g++ -std=c++17 -O2 -Wall -Wextra` produces
main:
mov eax, 42
ret
[Bug target/92682] New: [10 Regression] maxlocval_4.f90 / minlocval_4.f90 failure on POWER9
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92682 Bug ID: 92682 Summary: [10 Regression] maxlocval_4.f90 / minlocval_4.f90 failure on POWER9 Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: tkoenig at gcc dot gnu.org Target Milestone: --- https://gcc.gnu.org/ml/gcc-testresults/2019-10/msg01757.html (r277518) has FAIL: gfortran.dg/maxlocval_4.f90 -O2 execution test FAIL: gfortran.dg/minlocval_4.f90 -O2 execution test while https://gcc.gnu.org/ml/gcc-testresults/2019-10/msg01701.html (r277488) appears clean. It appears to be specific to POWER9, POWER7 and POWER8 do not appear to have that particular failure. I'll look for a bit (this is one of my test cases).
[Bug bootstrap/92661] [10 Regression] Bootstrap failure with builtin-types.def change
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92661 --- Comment #6 from Iain Sandoe --- the patch at comment #5 works for powerpc-darwin9, test output looks "nominal" (given that there's a lot of recent regression/new fails anyway)
[Bug c/92673] OCaml fails to link with recent trunk
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92673 --- Comment #3 from Andrew Pinski --- (In reply to Jürgen Reuter from comment #2) > (In reply to Richard Biener from comment #1) > > Try -fcommon, it's default recently was swapped to -fno-common. > > The default for gcc was changed? Which commit was this? I cannot find any > reference in the ChangeLog. https://gcc.gnu.org/ml/gcc-cvs/2019-11/msg00825.html
[Bug c++/92642] Enhance shift-count-overflow output
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92642 --- Comment #5 from Andrew Pinski --- (In reply to Jonny Grant from comment #4) > This test case for similar does have a nice warning. > > Interestingly, G++ does not indicate that 5147483647 is already 34 bits long: > 100110010110101011101 > which is more than an 'int' (32bit) which as Jonathan has highlighted, to be > the way numbers are treated in C/C++ when they do not have UL suffix. C changed with C99 and C++ changed with C++11 (IIRC) when it comes to literals.
[Bug fortran/81205] Hybrid MPI and OpenMp: Blocking code in loops
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81205 anlauf at gcc dot gnu.org changed: What|Removed |Added Status|WAITING |RESOLVED Resolution|--- |INVALID --- Comment #9 from anlauf at gcc dot gnu.org --- (In reply to Dominique d'Humieres from comment #8) > > I will try and will let you now. > > Any progress? No progress in 2.5 years. Closing as invalid.
Re: [Patch, build] Unbreak objc build
On Tue, Nov 26, 2019 at 10:48 AM Tobias Burnus wrote: > > When I tried to bootstrap with --enable-languages=default, which > includes objc, it failed to build libobj. > > As Rhy0lite on IRC correctly guessed, the issue is that the cet.m4 file > is at a different location. I wonder why no one had the problem before > in the last years – the libobjc/Makefile.in change was r254904 on Nov > 17, 2017 (!). The config/cet.m4 file itself was also added on 2017-11-17 > in r254868. > > Doing some more archeology, the the Makefile.in was changed by the patch > https://gcc.gnu.org/ml/gcc-patches/2017-10/msg02314.html – and one sees > that libobjc/aclocal.m4 has /../config/cet.m4 while libobjc/Makefile.in > uses /../cet.m4.m4. – Actually, that's not the submitted version > (cet.m4.m4) – as the committed version has 'cet.m4'. Approval was: > https://gcc.gnu.org/ml/gcc-patches/2017-11/msg00641.html > > Build on x86-64-gnu-linux. > OK for the trunk? Yes. > > Tobias > > PS: Assuming the build was indeed broken for everyone since 2 years, > maybe one should remove 'objc' from the 'default' languages? – Which > languages is now nowadays supposed to use when bootstrapping? I usually > have 'c,c++,fortran,lto', 'default' seems to be 'c,c++,fortran,objc' > (plus 'lto' which is implied by --enable-lto, which is default). Though as mentioned, the problem only shows up with --enable-maintainer-mode which nobody uses as the requirements for automake/autoconfig is different through out of a combined tree. Thanks, Andrew Pinski >
Re: [Patch, build] Unbreak objc build
On Tue, Nov 26, 2019 at 07:47:44PM +0100, Tobias Burnus wrote: > Build on x86-64-gnu-linux. > OK for the trunk? The patch is obvious. > PS: Assuming the build was indeed broken for everyone since 2 years, maybe > one should remove 'objc' from the 'default' languages? – Which languages is > now nowadays supposed to use when bootstrapping? I usually have > 'c,c++,fortran,lto', 'default' seems to be 'c,c++,fortran,objc' (plus 'lto' > which is implied by --enable-lto, which is default). No, it isn't really broken unless --enable-maintainer-mode. aclocal_deps variable in libobjc/Makefile.in in which this bug is is only used in: $(srcdir)/aclocal.m4: @MAINT@ $(aclocal_deps) cd $(srcdir) && $(ACLOCAL) $(ACLOCAL_AMFLAGS) and when not --enable-maintainer-mode, @MAINT@ is replaced with # (otherwise with nothing). And many people test objc or obj-c++ daily or whenever they are bootstrapping. I do all my x86_64-linux bootstraps with --enable-languages=default,ada,obj-c++,lto,go,brig,d and i686-linux bootstraps with --enable-languages=default,obj-c++,lto,go,brig,d others are using =all etc. > libobjc/ > * Makefile.in (aclocal_deps): Fix path to cet.m4. > > diff --git a/libobjc/Makefile.in b/libobjc/Makefile.in > index d733fb2606b..f029880265e 100644 > --- a/libobjc/Makefile.in > +++ b/libobjc/Makefile.in > @@ -297,7 +297,7 @@ aclocal_deps = \ > $(srcdir)/../ltsugar.m4 \ > $(srcdir)/../ltversion.m4 \ > $(srcdir)/../lt~obsolete.m4 \ > - $(srcdir)/../cet.m4 \ > + $(srcdir)/../config/cet.m4 \ > $(srcdir)/acinclude.m4 > > $(srcdir)/configure: @MAINT@ configure.ac $(srcdir)/aclocal.m4 Jakub
Re: Move -Wmaybe-uninitialized to -Wextra
The problem with false positives is correlated with the degree of optimization; a lot of people have reported problems at only the `-Og' optimization level (even when the code in question is embarrassingly correct). Therefore, the general solution is probably that the implem- entation of `-Wmaybe-uninitialized' be customized for the given level of optimization. However, I get the impression that this is easier said than done. >From what I've read, `-Wmaybe-uninitialized' is essentially customized for `-O2', which means that it will work pretty darn well at that optimization level. So, in the interim, I propose a simple approximation of the general solution: At an optimization level below `-O2' (or other than `-O2'): * `-Wmaybe-uninitialized' is moved to `-Wextra'. If `-Wall' has been specified, then gcc emits an informational note stating that `-Wmaybe-uninitialized' (or any other warning that has similar problems) has been disabled. * Provide a command-line option to disable such a note. * The user may always enable `-Wmaybe-uninitialized' either explicitly or as part of `-Wextra'. * If `-Wmaybe-uninitialized' is enabled by the user, then it implies `-O2' computations. That is to say, when the user specifies: -Og -Wmaybe-uninitialized or: -Og -Wextra then the user is explicitly telling the compiler to do all the optimizations of `-O2', but ONLY for the purpose of implementing `-Wmaybe-uninitialized' (or whichever warning requires those optimizations to function well); all those optimizations are to be thrown out after they have been used to good effect by `-Wmaybe-uninitialized'. The Code generation, etc., shall be performed at the optimization level the user specified (namely, `-Og' in this case). In other words, save the user from gcc's foibles, but let the user pay for the extra computation if so desired! What do you think? Sincerely, Michael Witten PS All of this trouble indicates that C (and other languages) are just not expressive enough with regard to initialization. Initialization semantics are basically a matter of API contract specification; the programmer needs the tools to write it down. Surely, gcc could provide `__builtin_assume_initialized(x);' and parameter attributes to help inform the reader (i.e., to help inform the compiler) about the code; a function parameter attribute could specify whether the given argument can be considered initialized after a call, and maybe specify further constraints, such as whether the guarantee is made only when the function return value is nonzero (or a certain value), etc. We need the language to write our thoughts down!
Re: [Patch, build] Unbreak objc build
Actually, can you both try with my patch applied? If it still builds for you and then builds for me, the problem is also solved. And with proper path it looks better in any case. (Remark: The compilation w/o maintainer mode was the usual Linux path, i.e. all under /usr/bin.) Tobias On 11/26/19 8:27 PM, Tobias Burnus wrote: On 11/26/19 8:13 PM, Iain Sandoe wrote: Right, It’s not been broken at all AFAICT - I build it daily on Darwin (often several times) and frequently on Linux - as does anyone building —enable-languages=all Ideas are welcome. I first did: .../configure --prefix=/home/tburnus/projects/gcc-trunk --enable-maintainer-mode --enable-languages=c,c++,fortran,lto,default --prefix=… make -j12 with PATH=$pathToAutoTools/bin:$HOME with autoconf-2.69 and automake-1.15.1 installed there. And that failed with: *** No rule to make target '…/libobjc/../cet.m4', needed by '…/libobjc/aclocal.m4'. Stop. Note the wrong path – the file is in ../libobjc/../config/cet.m4. Afterwards, I tried without --enable-maintainer-mode – and got exactly the same error. In any case, the directory in libobj/Makefile.in is wrong. Cheers, Tobias see, for example https://gcc.gnu.org/ml/gcc-testresults/2019-11/msg01480.html there must be some other explanation ;) Suggestions? cheers Iain
Re: [Patch, build] Unbreak objc build
On 11/26/19 8:13 PM, Iain Sandoe wrote: Right, It’s not been broken at all AFAICT - I build it daily on Darwin (often several times) and frequently on Linux - as does anyone building —enable-languages=all Ideas are welcome. I first did: .../configure --prefix=/home/tburnus/projects/gcc-trunk --enable-maintainer-mode --enable-languages=c,c++,fortran,lto,default --prefix=… make -j12 with PATH=$pathToAutoTools/bin:$HOME with autoconf-2.69 and automake-1.15.1 installed there. And that failed with: *** No rule to make target '…/libobjc/../cet.m4', needed by '…/libobjc/aclocal.m4'. Stop. Note the wrong path – the file is in ../libobjc/../config/cet.m4. Afterwards, I tried without --enable-maintainer-mode – and got exactly the same error. In any case, the directory in libobj/Makefile.in is wrong. Cheers, Tobias see, for example https://gcc.gnu.org/ml/gcc-testresults/2019-11/msg01480.html there must be some other explanation ;) Suggestions? cheers Iain
Re: [PATCH], V7, #6 of 7, Fix issues with vector extract and prefixed instructions
Hi!
On Thu, Nov 14, 2019 at 06:09:09PM -0500, Michael Meissner wrote:
> In this case, the current code re-uses the temporary for calculating the
> offset
> of the element to load up the address of the vector, losing the offset.
Reusing the same pseudo is *always* a bad idea. You get better
optimisation if most code is "SSA-like": write to every pseudo only
once. Of course you need to violate this where you woule have PHIs in
actual SSA.
> I needed to add a new constraint (em) in addition to new predicate functions.
> I discovered that with the predicate function alone, the register allocator
> would re-create the address. The constraint prevents this combination.
It's a reasonable thing to have as a contraint, too.
Once again, how should things work in inline assembler? Can we allow
prefixed addressing there, or should "m" in inline asm mean "em"?
> I also modified the vector extract code to generate a single PC-relative load
> if the vector has a PC-relative address and the offset is constant.
That should be handled by the RTL optimisers anyway, no? Or is this
for post-reload splitters (a bad idea always).
> * config/rs6000/rs6000.c (rs6000_adjust_vec_address): Add support
> for optimizing extracting a constant vector element from a vector
> that uses a prefixed address. If the element number is variable
> and the address uses a prefixed address, abort.
It doesn't abort. Erm, wait, it *does* ICE. Please make that more
prominent (in the code). It's not clear why you mention it in the
changelog while allt he other details are just "add support"?
I find the control flow very hard to read here.
> + /* Optimize PC-relative addresses with a constant offset. */
> + else if (pcrel_p && CONST_INT_P (element_offset))
> +{
> + rtx addr2 = addr;
addr isn't used after this anyway, so you can clobber it just fine.
> + /* With only one temporary base register, we can't support a PC-relative
> + address added to a variable offset. This is because the PADDI
> instruction
> + requires RA to be 0 when doing a PC-relative add (i.e. no register to
> add
> + to). */
> + else if (pcrel_p)
> +gcc_unreachable ();
That comment suggests we just ICE when we get unwanted input. Such a
comment belongs where we prevent such code from being formed in the
first place (or nowhere, if it is obvious).
Segher
[Bug other/92681] New: PGO bootstrap is broken with --with-build-config=bootstrap-lto-lean is not training non-C++ frontends
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92681 Bug ID: 92681 Summary: PGO bootstrap is broken with --with-build-config=bootstrap-lto-lean is not training non-C++ frontends Product: gcc Version: 10.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: other Assignee: unassigned at gcc dot gnu.org Reporter: hubicka at gcc dot gnu.org Target Milestone: --- This definitly leads to suboptimal compile time experience with Ada, Fortran, go, etc.
[Bug bootstrap/92680] New: PGO bootstrap is broken with --with-build-config=bootstrap-lto-lean and in-itree mpfr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92680 Bug ID: 92680 Summary: PGO bootstrap is broken with --with-build-config=bootstrap-lto-lean and in-itree mpfr Product: gcc Version: 10.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: bootstrap Assignee: unassigned at gcc dot gnu.org Reporter: hubicka at gcc dot gnu.org Target Milestone: --- Build with bootstrap-lto-lean with in-tree mpfr fails in profile mismatch on set_d.o. This is caused by fact that mpfr actually misconfigures itself with LTO. Its configure script scans assembly to detect format of long double and this gives wrong answer with LTO leading to suboptimal configuration.
Re: [Patch, build] Unbreak objc build
Hi Rainer Orth wrote: When I tried to bootstrap with --enable-languages=default, which includes objc, it failed to build libobj. care to describe exactly how the build fails? PS: Assuming the build was indeed broken for everyone since 2 years, maybe one should remove 'objc' from the 'default' languages? – Which languages is now nowadays supposed to use when bootstrapping? I usually have 'c,c++,fortran,lto', 'default' seems to be 'c,c++,fortran,objc' (plus 'lto' which is implied by --enable-lto, which is default). There's certainly more to that failure than just --enable-languages=default: I'm regularly using --enable-languages=all,... (which includes objc) without any issues, on all of Solaris, Linux/x86_64, and Darwin Right, It’s not been broken at all AFAICT - I build it daily on Darwin (often several times) and frequently on Linux - as does anyone building —enable-languages=all see, for example https://gcc.gnu.org/ml/gcc-testresults/2019-11/msg01480.html there must be some other explanation ;) cheers Iain
Re: [Patch, build] Unbreak objc build
Hi Tobias, > When I tried to bootstrap with --enable-languages=default, which includes > objc, it failed to build libobj. care to describe exactly how the build fails? > PS: Assuming the build was indeed broken for everyone since 2 years, maybe > one should remove 'objc' from the 'default' languages? – Which languages is > now nowadays supposed to use when bootstrapping? I usually have > 'c,c++,fortran,lto', 'default' seems to be 'c,c++,fortran,objc' (plus 'lto' > which is implied by --enable-lto, which is default). There's certainly more to that failure than just --enable-languages=default: I'm regularly using --enable-languages=all,... (which includes objc) without any issues, on all of Solaris, Linux/x86_64, and Darwin. Rainer -- - Rainer Orth, Center for Biotechnology, Bielefeld University
