Re: Clobber REG_CC only for some constraint alternatives?
Hans-Peter Nilsson writes: > On Fri, 14 Aug 2020, Senthil Kumar Selvaraj via Gcc wrote: >> As you can deduce from the (set_attr "cc" ..), only constraint >> alternatives 0,2,3 and 6 clobber CC - others leave it unchanged. > > Yes, I recognize that. > >> My first version of the port adds a post-reload splitter that adds a >> (clobber (reg:CC REG_CC)) unconditionally, and it appears to work. > > Ouch, temporarily lying to gcc here. > >> If I >> do want to add the clobber conditionally, would something like the below >> be a good way to do it (get_cc_reg_clobber_rtx returns either const0_rtx >> or cc_reg_rtx based on get_attr_cc (insn))? Or is there a better/cleaner way? > > I suggest having a look at what I did for the CRIS port. > Check the git history. > > In short: > - Add the clobber initially, to *all* patterns. > - Add postreload splitters for the special combinations that > don't clobber CC (ones without clobbering CC). > - Use the old "cc" attribute to control and generate > clobber/useful CC-setting alternatives (for various new CC_ > modes) with use of define_subst. This sounds like a great plan - the idea of always generating insn variants for however many CCmodes are available, and then using cc_enabled to disable them selectively (based on the attribute value corresponding to the alternative chosen) looks really neat. I did not understand the purpose of subst_attr for "ccnz" "ccnzvc" and "" though - wouldn't a (set_attr "cc_enabled", "...") do the same thing? Also, I already have a version that hides REG_CC until reload (based on the suggestion in the wiki page), but I guess this approach will work equally well with that too? Regards Senthil
[PATCH PR96357][GCC][AArch64]: could not split insn UNSPEC_COND_FSUB with AArch64 SVE
Hi, Problem is related to that operand 4 (In original pattern *cond_sub_any_const) is no longer the same as operand 1, and so the pattern doesn't match the split condition. Pattern *cond_sub_any_const is being split by this patch into two separate patterns: * Pattern *cond_sub_relaxed_const now matches const_int SVE_RELAXED_GP operand. * Pattern *cond_sub_strict_const now matches const_int SVE_STRICT_GP operand. * Remove aarch64_sve_pred_dominates_p condition from both patterns. Bootstrapped and tested on aarch64-none-linux-gnu. OK for master? Cheers, Przemyslaw gcc/ChangeLog: PR target/96357 * config/aarch64/aarch64-sve.md (*cond_sub_relaxed_const): Updated and renamed from *cond_sub_any_const pattern. (*cond_sub_strict_const): New pattern. gcc/testsuite/ChangeLog: * gcc.target/aarch64/sve/pr96357.c: New test. rb13393.patch Description: rb13393.patch
Re: [PATCH][testsuite, nvptx] Add effective target sync_int_long_stack
On Aug 12, 2020, at 6:57 AM, Tom de Vries wrote: > > The nvptx target currently doesn't support effective target sync_int_long, > although it has support for 32-bit and 64-bit atomic. > > When enabling sync_int_long for nvptx, we run into a failure in > gcc.dg/pr86314.c: > ... > nvptx-run: error getting kernel result: operation not supported on \ > global/shared address space > ... > due to a ptx restriction: accesses to local memory are illegal, and the > test-case does an atomic operation on a stack address, which is mapped to > local memory. > > Fix this by adding a target sync_int_long_stack, wich returns false for nvptx, > which can be used to mark test-cases that require sync_int_long support for > stack address. > > Build on nvptx and tested with make check-gcc. > > OK for trunk? Ok.
[Bug analyzer/96666] [11 Regression] Analyzer creates too many regions for a particular program
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=9
--- Comment #2 from Arseny Solokha ---
Created attachment 49078
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49078=edit
Testcase 3
Finally, a testcase which is valid C. Note that cc1plus is still necessary to
trigger the ICE.
int
printf (const char *, ...);
union x6 {
int ub;
};
void
c6 (void)
{
union x6 px;
px.ub = 0;
printf ("%d\n", px.ub);
}
% g++-11.0.0 -fanalyzer -c ttgyil32.c
g++-11.0.0: internal compiler error: Segmentation fault signal terminated
program cc1plus
Re: [PATCH] rs6000: Rename instruction xvcvbf16sp to xvcvbf16spn
On 8/18/20 1:34 PM, Segher Boessenkool wrote: > On Tue, Aug 18, 2020 at 01:30:53PM -0500, Peter Bergner wrote: >> The xvcvbf16sp mnemonic, which was just added in ISA 3.1 has been renamed >> to xvcvbf16spn, to make it consistent with the other non-signaling conversion >> instructions which all end with "n". The only use of this instruction is in >> an MMA conversion built-in function, so there is little to no compatibility >> issue. >> >> I just pushed the patch that does the rename to binutils today. >> >> Ok for trunk and the GCC 10 branch after testing is clean? > > Yes, okay everywhere. Thanks! Thanks. Pushed to trunk and GCC 10 branch. Thanks! Peter
Re: [PATCH v2] rs6000: ICE when using an MMA type as a function param or return value [PR96506]
On 8/13/20 4:27 PM, Segher Boessenkool wrote: > Anyway, okay for trunk and backports. Thanks! Ok, I committed this to trunk and waited a few days and then pushed this to GCC 10 release branch too. Thanks! Peter
[Bug target/96506] ICE when using an MMA type as a function param
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96506 Peter Bergner changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #4 from Peter Bergner --- Fixed everywhere.
[Bug target/96506] ICE when using an MMA type as a function param
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96506 --- Comment #3 from CVS Commits --- The releases/gcc-10 branch has been updated by Peter Bergner : https://gcc.gnu.org/g:43edad43b2cee17fb7575c40a9dafac3fe79ba1c commit r10-8641-g43edad43b2cee17fb7575c40a9dafac3fe79ba1c Author: Peter Bergner Date: Thu Aug 13 13:40:39 2020 -0500 rs6000: ICE when using an MMA type as a function param or return value [PR96506] PR96506 shows a problem where we ICE on illegal usage, namely using MMA types for function arguments and return values. The solution is to flag these illegal usages as errors early, before we ICE. 2020-08-13 Peter Bergner gcc/ PR target/96506 * config/rs6000/rs6000-call.c (rs6000_promote_function_mode): Disallow MMA types as return values. (rs6000_function_arg): Disallow MMA types as function arguments. gcc/testsuite/ PR target/96506 * gcc.target/powerpc/pr96506.c: New test. (cherry picked from commit 0ad7e730c142ef6cd0ddc1491a89a7f330caa887)
[Bug analyzer/96699] New: [11 Regression] ICE in fold_convert_const_int_from_real, at fold-const.c:2038
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96699
Bug ID: 96699
Summary: [11 Regression] ICE in
fold_convert_const_int_from_real, at fold-const.c:2038
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: analyzer
Assignee: dmalcolm at gcc dot gnu.org
Reporter: asolokha at gmx dot com
Target Milestone: ---
gcc-11.0.0-alpha20200816 snapshot (g:c99116aeeb9644ebddec653ee8b19de4d38b65bd)
ICEs when compiling the following testcase w/ -fanalyzer:
struct qi {
union {
int hj;
float sl;
};
};
void
i2 (struct qi *la)
{
if (la->hj == 0)
la->sl = 0.0f;
}
% gcc-11.0.0 -fanalyzer -c lnlqkm5b.c
during IPA pass: analyzer
lnlqkm5b.c: In function 'i2':
lnlqkm5b.c:12:12: internal compiler error: in fold_convert_const_int_from_real,
at fold-const.c:2038
12 | la->sl = 0.0f;
| ~~~^~
0x62e70b fold_convert_const_int_from_real
/var/tmp/portage/sys-devel/gcc-11.0.0_alpha20200816/work/gcc-11-20200816/gcc/fold-const.c:2038
0x62e70b fold_convert_const
/var/tmp/portage/sys-devel/gcc-11.0.0_alpha20200816/work/gcc-11-20200816/gcc/fold-const.c:2284
0xa7016d fold_unary_loc(unsigned int, tree_code, tree_node*, tree_node*)
/var/tmp/portage/sys-devel/gcc-11.0.0_alpha20200816/work/gcc-11-20200816/gcc/fold-const.c:8731
0x1123e9c ana::region_model_manager::maybe_fold_unaryop(tree_node*, tree_code,
ana::svalue const*)
/var/tmp/portage/sys-devel/gcc-11.0.0_alpha20200816/work/gcc-11-20200816/gcc/analyzer/region-model-manager.cc:369
0x1123f8a ana::region_model_manager::get_or_create_unaryop(tree_node*,
tree_code, ana::svalue const*)
/var/tmp/portage/sys-devel/gcc-11.0.0_alpha20200816/work/gcc-11-20200816/gcc/analyzer/region-model-manager.cc:382
0x1123f8a ana::region_model_manager::get_or_create_cast(tree_node*, ana::svalue
const*)
/var/tmp/portage/sys-devel/gcc-11.0.0_alpha20200816/work/gcc-11-20200816/gcc/analyzer/region-model-manager.cc:399
0x114a1f3 ana::initial_svalue::implicitly_live_p(hash_set > const&, ana::region_model
const*) const
/var/tmp/portage/sys-devel/gcc-11.0.0_alpha20200816/work/gcc-11-20200816/gcc/analyzer/svalue.cc:529
0x114a1f3 ana::initial_svalue::implicitly_live_p(hash_set > const&, ana::region_model
const*) const
/var/tmp/portage/sys-devel/gcc-11.0.0_alpha20200816/work/gcc-11-20200816/gcc/analyzer/svalue.cc:518
0x184ad0d ana::dead_svalue_purger::should_purge_p(ana::svalue const*) const
/var/tmp/portage/sys-devel/gcc-11.0.0_alpha20200816/work/gcc-11-20200816/gcc/analyzer/constraint-manager.cc:1613
0x184ad0d void
ana::constraint_manager::purge(ana::dead_svalue_purger
const&, ana::purge_stats*)
/var/tmp/portage/sys-devel/gcc-11.0.0_alpha20200816/work/gcc-11-20200816/gcc/analyzer/constraint-manager.cc:1494
0x1849fa6 ana::constraint_manager::on_liveness_change(hash_set > const&,
ana::region_model const*)
/var/tmp/portage/sys-devel/gcc-11.0.0_alpha20200816/work/gcc-11-20200816/gcc/analyzer/constraint-manager.cc:1630
0x1103f5d ana::program_state::detect_leaks(ana::program_state const&,
ana::program_state const&, ana::svalue const*, ana::extrinsic_state const&,
ana::region_model_context*)
/var/tmp/portage/sys-devel/gcc-11.0.0_alpha20200816/work/gcc-11-20200816/gcc/analyzer/program-state.cc:1037
0x10f430a ana::exploded_graph::process_node(ana::exploded_node*)
/var/tmp/portage/sys-devel/gcc-11.0.0_alpha20200816/work/gcc-11-20200816/gcc/analyzer/engine.cc:2538
0x10f4d5a ana::exploded_graph::process_worklist()
/var/tmp/portage/sys-devel/gcc-11.0.0_alpha20200816/work/gcc-11-20200816/gcc/analyzer/engine.cc:2341
0x10f6e8f ana::impl_run_checkers(ana::logger*)
/var/tmp/portage/sys-devel/gcc-11.0.0_alpha20200816/work/gcc-11-20200816/gcc/analyzer/engine.cc:4107
0x10f7aac ana::run_checkers()
/var/tmp/portage/sys-devel/gcc-11.0.0_alpha20200816/work/gcc-11-20200816/gcc/analyzer/engine.cc:4175
0x10ec468 execute
/var/tmp/portage/sys-devel/gcc-11.0.0_alpha20200816/work/gcc-11-20200816/gcc/analyzer/analyzer-pass.cc:84
Re: [PATCH 4/4][PR target/88808]Enable bitwise operator for AVX512 masks.
On Mon, Aug 17, 2020 at 6:08 PM Uros Bizjak wrote: > > On Fri, Aug 14, 2020 at 10:26 AM Hongtao Liu wrote: > > > > Enable operator or/xor/and/andn/not for mask register, kxnor is not > > enabled since there's no corresponding instruction for general > > registers. > > > > gcc/ > > PR target/88808 > > * config/i386/i386.md: (*movsi_internal): Adjust constraints > > for mask registers. > > (*movhi_internal): Ditto. > > (*movqi_internal): Ditto. > > (*anddi_1): Support mask register operations > > (*and_1): Ditto. > > (*andqi_1): Ditto. > > (*andn_1): Ditto. > > (*_1): Ditto. > > (*qi_1): Ditto. > > (*one_cmpl2_1): Ditto. > > (*one_cmplsi2_1_zext): Ditto. > > (*one_cmplqi2_1): Ditto. > > > > gcc/testsuite/ > > * gcc.target/i386/bitwise_mask_op-1.c: New test. > > * gcc.target/i386/bitwise_mask_op-2.c: New test. > > * gcc.target/i386/avx512bw-kunpckwd-1.c: Adjust testcase. > > * gcc.target/i386/avx512bw-kunpckwd-3.c: Ditto. > > * gcc.target/i386/avx512dq-kmovb-5.c: Ditto. > > * gcc.target/i386/avx512f-kmovw-5.c: Ditto. > > index 74d207c3711..e8ad79d1b0a 100644 > --- a/gcc/config/i386/i386.md > +++ b/gcc/config/i386/i386.md > @@ -2294,7 +2294,7 @@ > > (define_insn "*movsi_internal" >[(set (match_operand:SI 0 "nonimmediate_operand" > -"=r,m ,*y,*y,?*y,?m,?r,?*y,*v,*v,*v,m ,?r,?*v,*k,*k ,*rm,*k") > +"=r,m ,*y,*y,?*y,?m,?r,?*y,*v,*v,*v,m ,?r,?*v,*k,*k ,*rm,k") > (match_operand:SI 1 "general_operand" > "g ,re,C ,*y,m ,*y,*y,r ,C ,*v,m ,*v,*v,r ,*r,*km,*k ,CBC"))] >"!(MEM_P (operands[0]) && MEM_P (operands[1]))" > > I'd rather see *k everywhere, also with *movqi_internal and > *movhi_internal patterns. The "*" means that the allocator won't > allocate a mask register by default, but it will be used to optimize > moves. With the above change, you are risking that during integer > register pressure, the register allocator will allocate zero to a mask > register, and later "optimize" the move with a direct maskreg-intreg > move. > > The current strategy is that only general registers get allocated for > integer modes. Let's keep it this way for now. > Yes, though it would fail gcc.target/i386/avx512dq-pr88465.c and gcc.target/i386/avx512f-pr88465.c, i think it's more reasonable not to move zero into mask register directly. > Otherwise, the patchset LGTM, but please test the suggested changes and > repost. > > BTW: Do you plan to remove mask operations from sse.md? ATM, they are > used to distinguish mask operations, generated from builtins from > generic operations, so I'd like to keep them for a while. The drawback > is, that they are not combined with other operations, but at the end > of the day, this is what the programmer asked for by using builtins. Agree, I prefer to keep them. > > Uros. Bootstrap is ok, regression test is ok for i386/x86-64 backend(After adjusting testcase). impact for SPEC2017 on SKL. 500.perlbench_r 0.00% 502.gcc_r 1.59% 505.mcf_r 1.49% 520.omnetpp_r 1.91% 523.xalancbmk_r -1.22% 525.x264_r 0.00% 531.deepsjeng_r 0.00% 541.leela_r -0.22% 548.exchange2_r 2.27% 557.xz_r 0.63% INT geomean 0.64% 503.bwaves_r 3.68% 507.cactuBSSN_r -0.62% 508.namd_r 0.51% 510.parest_r -0.16% 511.povray_r 0.57% 519.lbm_r 0.50% 521.wrf_r 0.00% 526.blender_r 0.00% 527.cam4_r 0.00% 538.imagick_r -0.41% 544.nab_r 0.00% 549.fotonik3d_r -0.20% 554.roms_r 4.19% FP geomean 0.66% -- BR, Hongtao From e546516449ec4ed9301b83a063efdefbf0f7e75a Mon Sep 17 00:00:00 2001 From: liuhongt Date: Thu, 13 Aug 2020 14:20:43 +0800 Subject: [PATCH 4/4] Enable bitwise operation for type mask. Enable operator or/xor/and/andn/not for mask register, kxnor is not enabled since there's no corresponding instruction for general registers. gcc/ PR target/88808 * config/i386/i386.md: (*movsi_internal): Adjust constraints for mask registers. (*movhi_internal): Ditto. (*movqi_internal): Ditto. (*anddi_1): Support mask register operations (*and_1): Ditto. (*andqi_1): Ditto. (*andn_1): Ditto. (*_1): Ditto. (*qi_1): Ditto. (*one_cmpl2_1): Ditto. (*one_cmplsi2_1_zext): Ditto. (*one_cmplqi2_1): Ditto. gcc/testsuite/ * gcc.target/i386/bitwise_mask_op-1.c: New test. * gcc.target/i386/bitwise_mask_op-2.c: New test. * gcc.target/i386/avx512bw-kunpckwd-1.c: Adjust testcase. * gcc.target/i386/avx512bw-kunpckwd-3.c: Ditto. * gcc.target/i386/avx512dq-kmovb-5.c: Ditto. * gcc.target/i386/avx512f-kmovw-5.c: Ditto. * gcc.target/i386/avx512bw-pr88465.c: Ditto. * gcc.target/i386/avx512f-pr88465.c: Ditto. --- gcc/config/i386/i386.md | 260 +- .../gcc.target/i386/avx512bw-kunpckwd-1.c | 2 +- .../gcc.target/i386/avx512bw-kunpckwd-3.c | 2 +- .../gcc.target/i386/avx512dq-kmovb-5.c| 2 +- .../gcc.target/i386/avx512dq-pr88465.c| 4 +- .../gcc.target/i386/avx512f-kmovw-5.c |
Re: [PATCH 2/4][PR target/88808]Enable bitwise operator for AVX512 masks.
On Mon, Aug 17, 2020 at 5:34 PM Uros Bizjak wrote:
>
> On Fri, Aug 14, 2020 at 10:24 AM Hongtao Liu wrote:
> >
> > Enable direct move between masks and gprs in pass_reload with
> > consideration of cost model.
> >
> > Changelog
> > gcc/
> > * config/i386/i386.c (inline_secondary_memory_needed):
> > No memory is needed between mask regs and gpr.
> > (ix86_hard_regno_mode_ok): Add condition TARGET_AVX512F for
> > mask regno.
> > * config/i386/i386.h (enum reg_class): Add INT_MASK_REGS.
> > (REG_CLASS_NAMES): Ditto.
> > (REG_CLASS_CONTENTS): Ditto.
> > * config/i386/i386.md: Exclude mask register in
> > define_peephole2 which is available only for gpr.
> >
> > gcc/testsuites/
> > * gcc.target/i386/pr71453-1.c: New tests.
> > * gcc.target/i386/pr71453-2.c: Ditto.
> > * gcc.target/i386/pr71453-3.c: Ditto.
> > * gcc.target/i386/pr71453-4.c: Ditto.
>
> @@ -18571,9 +18571,7 @@ inline_secondary_memory_needed (machine_mode
> mode, reg_class_t class1,
>|| MAYBE_SSE_CLASS_P (class1) != SSE_CLASS_P (class1)
>|| MAYBE_SSE_CLASS_P (class2) != SSE_CLASS_P (class2)
>|| MAYBE_MMX_CLASS_P (class1) != MMX_CLASS_P (class1)
> - || MAYBE_MMX_CLASS_P (class2) != MMX_CLASS_P (class2)
> - || MAYBE_MASK_CLASS_P (class1) != MASK_CLASS_P (class1)
> - || MAYBE_MASK_CLASS_P (class2) != MASK_CLASS_P (class2))
> + || MAYBE_MMX_CLASS_P (class2) != MMX_CLASS_P (class2))
> {
>gcc_assert (!strict || lra_in_progress);
>return true;
>
> No, this is still needed, the reason is explained in the comment above
Remove my change here.
> inline_secondary_memory_needed:
>
>The function can't work reliably when one of the CLASSES is a class
>containing registers from multiple sets. We avoid this by never combining
>different sets in a single alternative in the machine description.
>Ensure that this constraint holds to avoid unexpected surprises.
>
> diff --git a/gcc/config/i386/i386.md b/gcc/config/i386/i386.md
> index b24a4557871..74d207c3711 100644
> --- a/gcc/config/i386/i386.md
> +++ b/gcc/config/i386/i386.md
> @@ -15051,7 +15051,7 @@
> (parallel [(set (reg:CC FLAGS_REG)
> (unspec:CC [(match_dup 0)] UNSPEC_PARITY))
>(clobber (match_dup 0))])]
> - ""
> + "!MASK_REGNO_P (REGNO (operands[0]))"
>[(set (reg:CC FLAGS_REG)
> (unspec:CC [(match_dup 1)] UNSPEC_PARITY))])
>
> @@ -15072,6 +15072,7 @@
> (label_ref (match_operand 5))
> (pc)))]
>"REGNO (operands[2]) == REGNO (operands[3])
> + && !MASK_REGNO_P (REGNO (operands[1]))
> && peep2_reg_dead_p (3, operands[0])
> && peep2_reg_dead_p (3, operands[2])
> && peep2_regno_dead_p (4, FLAGS_REG)"
>
Changed for upper two define_peepholes.
> Actually, there are several (historic?) peephole2 patterns that assume
I didn't find those patterns.
I looked through i386.md, there are 3 cases
1. Since mask registers are only used for "mov/zero_extend/bitwise"
patterns, peephole2 patterns involving only other patterns are safe to
use general_registers.
2. For those peephole2 patterns containing both
mov/zero_extend/bitwise and other patterns, implicit conditions such
as match_dup used in other patterns will make them the same as case 1.
3. Peephole2 patterns are safe to use mask registers, since they would
be eliminated in output patterns.
> register_operand means only integer registers. Just change
> register_operand to general_reg_operand and eventually
> nonimmediate_operand to nonimmediate_gr_operand. Do not put additional
> predicates into insn predicate.
>
> Uros.
Update patch.
--
BR,
Hongtao
From 5a07403279622447cc6503a8dcc3c0cecb9ffcef Mon Sep 17 00:00:00 2001
From: liuhongt
Date: Thu, 24 Oct 2019 11:13:00 +0800
Subject: [PATCH 3/4] According to instruction_tables.pdf
1. Set cost of movement inside mask registers a bit higher than gpr's.
2. Set cost of movement between mask register and gpr much higher than movement
inside gpr, but still less equal than load/store.
3. Set cost of mask register load/store a bit higher than gpr load/store.
---
gcc/config/i386/x86-tune-costs.h | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/gcc/config/i386/x86-tune-costs.h b/gcc/config/i386/x86-tune-costs.h
index 256c84e364e..a782a9dd9e3 100644
--- a/gcc/config/i386/x86-tune-costs.h
+++ b/gcc/config/i386/x86-tune-costs.h
@@ -1727,12 +1727,12 @@ struct processor_costs skylake_cost = {
{8, 8, 8, 12, 24}, /* cost of storing SSE registers
in 32,64,128,256 and 512-bit */
6, 6, /* SSE->integer and integer->SSE moves */
- 2, 2,/* mask->integer and integer->mask moves */
- {4, 4, 4},/* cost of loading mask register
+ 4, 6,/* mask->integer and integer->mask moves */
+ {6, 6, 6},/* cost of loading mask register
in QImode, HImode, SImode. */
- {6, 6, 6},/* cost if storing
Re: [PATCH 2/4][PR target/88808]Enable bitwise operator for AVX512 masks.
On Wed, Aug 19, 2020 at 10:17 AM Hongtao Liu wrote:
>
> On Mon, Aug 17, 2020 at 5:34 PM Uros Bizjak wrote:
> >
> > On Fri, Aug 14, 2020 at 10:24 AM Hongtao Liu wrote:
> > >
> > > Enable direct move between masks and gprs in pass_reload with
> > > consideration of cost model.
> > >
> > > Changelog
> > > gcc/
> > > * config/i386/i386.c (inline_secondary_memory_needed):
> > > No memory is needed between mask regs and gpr.
> > > (ix86_hard_regno_mode_ok): Add condition TARGET_AVX512F for
> > > mask regno.
> > > * config/i386/i386.h (enum reg_class): Add INT_MASK_REGS.
> > > (REG_CLASS_NAMES): Ditto.
> > > (REG_CLASS_CONTENTS): Ditto.
> > > * config/i386/i386.md: Exclude mask register in
> > > define_peephole2 which is available only for gpr.
> > >
> > > gcc/testsuites/
> > > * gcc.target/i386/pr71453-1.c: New tests.
> > > * gcc.target/i386/pr71453-2.c: Ditto.
> > > * gcc.target/i386/pr71453-3.c: Ditto.
> > > * gcc.target/i386/pr71453-4.c: Ditto.
> >
> > @@ -18571,9 +18571,7 @@ inline_secondary_memory_needed (machine_mode
> > mode, reg_class_t class1,
> >|| MAYBE_SSE_CLASS_P (class1) != SSE_CLASS_P (class1)
> >|| MAYBE_SSE_CLASS_P (class2) != SSE_CLASS_P (class2)
> >|| MAYBE_MMX_CLASS_P (class1) != MMX_CLASS_P (class1)
> > - || MAYBE_MMX_CLASS_P (class2) != MMX_CLASS_P (class2)
> > - || MAYBE_MASK_CLASS_P (class1) != MASK_CLASS_P (class1)
> > - || MAYBE_MASK_CLASS_P (class2) != MASK_CLASS_P (class2))
> > + || MAYBE_MMX_CLASS_P (class2) != MMX_CLASS_P (class2))
> > {
> >gcc_assert (!strict || lra_in_progress);
> >return true;
> >
> > No, this is still needed, the reason is explained in the comment above
>
> Remove my change here.
>
> > inline_secondary_memory_needed:
> >
> >The function can't work reliably when one of the CLASSES is a class
> >containing registers from multiple sets. We avoid this by never
> > combining
> >different sets in a single alternative in the machine description.
> >Ensure that this constraint holds to avoid unexpected surprises.
> >
> > diff --git a/gcc/config/i386/i386.md b/gcc/config/i386/i386.md
> > index b24a4557871..74d207c3711 100644
> > --- a/gcc/config/i386/i386.md
> > +++ b/gcc/config/i386/i386.md
> > @@ -15051,7 +15051,7 @@
> > (parallel [(set (reg:CC FLAGS_REG)
> > (unspec:CC [(match_dup 0)] UNSPEC_PARITY))
> >(clobber (match_dup 0))])]
> > - ""
> > + "!MASK_REGNO_P (REGNO (operands[0]))"
> >[(set (reg:CC FLAGS_REG)
> > (unspec:CC [(match_dup 1)] UNSPEC_PARITY))])
> >
> > @@ -15072,6 +15072,7 @@
> > (label_ref (match_operand 5))
> > (pc)))]
> >"REGNO (operands[2]) == REGNO (operands[3])
> > + && !MASK_REGNO_P (REGNO (operands[1]))
> > && peep2_reg_dead_p (3, operands[0])
> > && peep2_reg_dead_p (3, operands[2])
> > && peep2_regno_dead_p (4, FLAGS_REG)"
> >
>
> Changed for upper two define_peepholes.
>
> > Actually, there are several (historic?) peephole2 patterns that assume
>
> I didn't find those patterns.
>
> I looked through i386.md, there are 3 cases
> 1. Since mask registers are only used for "mov/zero_extend/bitwise"
> patterns, peephole2 patterns involving only other patterns are safe to
> use general_registers.
> 2. For those peephole2 patterns containing both
> mov/zero_extend/bitwise and other patterns, implicit conditions such
> as match_dup used in other patterns will make them the same as case 1.
> 3. Peephole2 patterns are safe to use mask registers, since they would
> be eliminated in output patterns.
>
> > register_operand means only integer registers. Just change
> > register_operand to general_reg_operand and eventually
> > nonimmediate_operand to nonimmediate_gr_operand. Do not put additional
> > predicates into insn predicate.
>
>
>
> >
> > Uros.
>
> Update patch.
>
> --
> BR,
> Hongtao
This patch.
--
BR,
Hongtao
From 388300c90b7b147d088ccc58a39fcec9556979b5 Mon Sep 17 00:00:00 2001
From: liuhongt
Date: Thu, 6 Aug 2020 13:48:38 +0800
Subject: [PATCH 2/4] Enable direct movement between gpr and mask registers in
pass_reload.
Changelog
gcc/
* config/i386/i386.c (inline_secondary_memory_needed):
No memory is needed between mask regs and gpr.
(ix86_hard_regno_mode_ok): Add condition TARGET_AVX512F for
mask regno.
* config/i386/i386.h (enum reg_class): Add INT_MASK_REGS.
(REG_CLASS_NAMES): Ditto.
(REG_CLASS_CONTENTS): Ditto.
* config/i386/i386.md: Exclude mask register in
define_peephole2 which is avaiable only for gpr.
gcc/testsuites/
* gcc.target/i386/pr71453-1.c: New tests.
* gcc.target/i386/pr71453-2.c: Ditto.
* gcc.target/i386/pr71453-3.c: Ditto.
* gcc.target/i386/pr71453-4.c: Ditto.
---
gcc/config/i386/i386.c| 2 +-
gcc/config/i386/i386.h| 3 +
gcc/config/i386/i386.md | 4 +-
Re: [PATCH 1/4][PR target/88808]Enable bitwise operator for AVX512 masks.
On Mon, Aug 17, 2020 at 5:20 PM Uros Bizjak wrote:
>
> On Fri, Aug 14, 2020 at 10:22 AM Hongtao Liu wrote:
> >
> > Hi:
> > First, since avx512 masks involve both vector isa and general part,
> > so i add both maintainers to the maillist.
> >
> > I'm doing this in 4 steps:
> > 1 - Add cost model for operation of mask registers.
> > 2 - Introduce new cover class INT_MASK_REGS, this will enable direct
> > move between gpr and mask registers in pass_reload by consideration of
> > cost model, this is similar as INT_SSE_REGS.
> > 3 - Tune cost model.
> > 4 - Enable operator or/xor/and/andn/not for mask register. kxnor is
> > not enabled since there's no corresponding instruction for general
> > registers, 64bit mask op is not enabled for 32bit target.
> > kadd/kshift/ktest are not merged into general versionsadd/ashl/test
> > since i think it would be odd to use mask register for those
> > operations.
> >
> > Bootstrap is ok, regression test is ok for i386/x86-64 result.
> > There's some improvement for performance of SPEC2017 tested on SKL,
> > i observe there're many spills from integer to mask registers instead
> > of memory which is the reason for the improvement.
>
> + if (MASK_CLASS_P (regclass))
> +{
> + int index;
> + switch (GET_MODE_SIZE (mode))
> +{
> +case 1:
> + index = 0;
> + break;
> +case 2:
> + index = 1;
> + break;
> +default:
> + index = 3;
>
> Max index = 2!
>
Fix typo.
> + break;
> +}
> +
> + if (in == 2)
> +return MAX (ix86_cost->hard_register.mask_load[index],
> +ix86_cost->hard_register.mask_store[index]);
> + return in ? ix86_cost->hard_register.mask_load[2]
> +: ix86_cost->hard_register.mask_store[2];
> +}
>
> Are DImode loads and stores assumed to cost the same as SImode? A
> comment would be nice here.
>
Yes, comment is added.
> Uros.
Update patch.
--
BR,
Hongtao
From 70e9e389d751c79caf957ef336dded34726f0533 Mon Sep 17 00:00:00 2001
From: "H.J. Lu"
Date: Tue, 3 Sep 2019 14:41:02 -0700
Subject: [PATCH 1/4] x86: Add cost model for operation of mask registers.
gcc/
PR target/71453
* config/i386/i386.h (struct processor_costs): Add member
mask_to_integer, integer_to_mask, mask_load[3], mask_store[3],
mask_move.
* config/i386/x86-tune-costs.h (ix86_size_cost, i386_cost,
i386_cost, pentium_cost, lakemont_cost, pentiumpro_cost,
geode_cost, k6_cost, athlon_cost, k8_cost, amdfam10_cost,
bdver_cost, znver1_cost, znver2_cost, skylake_cost,
btver1_cost, btver2_cost, pentium4_cost, nocona_cost,
atom_cost, slm_cost, intel_cost, generic_cost, core_cost):
Initialize mask_load[3], mask_store[3], mask_move,
integer_to_mask, mask_to_integer for all target costs.
* config/i386/i386.c (ix86_register_move_cost): Using cost
model of mask registers.
(inline_memory_move_cost): Ditto.
(ix86_register_move_cost): Ditto.
---
gcc/config/i386/i386.c | 34
gcc/config/i386/i386.h | 7 ++
gcc/config/i386/x86-tune-costs.h | 144 +++
3 files changed, 185 insertions(+)
diff --git a/gcc/config/i386/i386.c b/gcc/config/i386/i386.c
index 8ea6a4d7ea7..f5e824a16ad 100644
--- a/gcc/config/i386/i386.c
+++ b/gcc/config/i386/i386.c
@@ -18769,6 +18769,29 @@ inline_memory_move_cost (machine_mode mode, enum reg_class regclass, int in)
return in ? ix86_cost->hard_register.sse_load [index]
: ix86_cost->hard_register.sse_store [index];
}
+ if (MASK_CLASS_P (regclass))
+{
+ int index;
+ switch (GET_MODE_SIZE (mode))
+ {
+ case 1:
+ index = 0;
+ break;
+ case 2:
+ index = 1;
+ break;
+ /* DImode loads and stores assumed to cost the same as SImode. */
+ default:
+ index = 2;
+ break;
+ }
+
+ if (in == 2)
+ return MAX (ix86_cost->hard_register.mask_load[index],
+ ix86_cost->hard_register.mask_store[index]);
+ return in ? ix86_cost->hard_register.mask_load[2]
+ : ix86_cost->hard_register.mask_store[2];
+}
if (MMX_CLASS_P (regclass))
{
int index;
@@ -18894,6 +18917,17 @@ ix86_register_move_cost (machine_mode mode, reg_class_t class1_i,
? ix86_cost->hard_register.sse_to_integer
: ix86_cost->hard_register.integer_to_sse);
+ /* Moves between mask register and GPR. */
+ if (MASK_CLASS_P (class1) != MASK_CLASS_P (class2))
+{
+ return (MASK_CLASS_P (class1)
+ ? ix86_cost->hard_register.mask_to_integer
+ : ix86_cost->hard_register.integer_to_mask);
+}
+ /* Moving between mask registers. */
+ if (MASK_CLASS_P (class1) && MASK_CLASS_P (class2))
+return ix86_cost->hard_register.mask_move;
+
if (MAYBE_FLOAT_CLASS_P (class1))
return ix86_cost->hard_register.fp_move;
if (MAYBE_SSE_CLASS_P (class1))
diff --git a/gcc/config/i386/i386.h b/gcc/config/i386/i386.h
index 114967e49a3..e0af87450b8 100644
--- a/gcc/config/i386/i386.h
+++ b/gcc/config/i386/i386.h
@@ -279,6 +279,13 @@ struct processor_costs {
in SImode,
[Bug tree-optimization/96698] New: aarch64: ICE during GIMPLE pass:vect
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96698
Bug ID: 96698
Summary: aarch64: ICE during GIMPLE pass:vect
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: yangyang305 at huawei dot com
Target Milestone: ---
Hi, gcc-trunk ICEs when compiling the following testcase with -O3:
void test(int a, int* i) {
for (; a < 5; ++a) {
int b = 0;
int c = 0;
for (; b != -11; b--)
for (int d = 0; d ==0; d++) {
*i += c & a;
c = b;
}
}
}
during GIMPLE pass: vect
/home/yangyang/Testcase/ICE-274/test.c: In function ‘test’:
/home/yangyang/Testcase/ICE-274/test.c:1:6: internal compiler error: in
vect_transform_stmt, at tree-vect-stmts.c:10940
1 | void test(int a, int* i) {
| ^~~~
0xf229ab vect_transform_stmt(vec_info*, _stmt_vec_info*, gimple_stmt_iterator*,
_slp_tree*, _slp_instance*)
../../gcc/tree-vect-stmts.c:10940
0xf3cdcb vect_transform_loop(_loop_vec_info*, gimple*)
../../gcc/tree-vect-loop.c:8972
0xf5aafb try_vectorize_loop_1
../../gcc/tree-vectorizer.c:1093
0xf5b7b7 vectorize_loops()
../../gcc/tree-vectorizer.c:1230
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See
[Bug analyzer/96651] gcc 10 -fanalyzer fail to track (static) global variable in a switch
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96651 David Malcolm changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #3 from David Malcolm --- Should be fixed by the above patch; marking as resolved. That said, does this fix the false positives from curl? In the first example in https://github.com/curl/curl/pull/5815 I see various function calls on the path before the "switch", and if those are in a different source file the analyzer ought to conservatively assume that non-static globals could get written to.
[Bug analyzer/96648] [11 Regression] ICE in get_field_at_bit_offset, at analyzer/region.cc:229
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96648 David Malcolm changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #2 from David Malcolm --- Should be fixed by the above patch.
[committed] analyzer: consider initializers for globals [PR96651]
PR analyzer/96651 reports a false positive in which a global
that can't have been touched yet is checked in "main". The analyzer
fails to reject code paths in which the initial value of the global
makes the path condition impossible.
This patch detects cases where the code path begins at the entrypoint
of "main", and extracts values from initializers for globals that
can't have been touched yet, rather than using a symbolic
"INIT_VAL(REG)", fixing the false positive.
Successfully bootstrapped & regrtested on x86_64-pc-linux-gnu.
Pushed to master as r11-2753-g400abebf48a90d0797718ab7c3864de331e85b70.
gcc/analyzer/ChangeLog:
PR analyzer/96651
* region-model.cc (region_model::called_from_main_p): New.
(region_model::get_store_value): Move handling for globals into...
(region_model::get_initial_value_for_global): ...this new
function, and add logic for extracting values from decl
initializers.
* region-model.h (decl_region::get_svalue_for_constructor): New
decl.
(decl_region::get_svalue_for_initializer): New decl.
(region_model::called_from_main_p): New decl.
(region_model::get_initial_value_for_global): New.
* region.cc (decl_region::maybe_get_constant_value): Move logic
for getting an svalue from a CONSTRUCTOR node to...
(decl_region::get_svalue_for_constructor): ...this new function.
(decl_region::get_svalue_for_initializer): New.
* store.cc (get_svalue_for_ctor_val): Rewrite in terms of
region_model::get_rvalue.
* store.h (binding_cluster::get_map): New accessor.
gcc/testsuite/ChangeLog:
PR analyzer/96651
* gcc.dg/analyzer/pr96651-1.c: New test.
* gcc.dg/analyzer/pr96651-2.c: New test.
---
gcc/analyzer/region-model.cc | 82 ---
gcc/analyzer/region-model.h | 6 ++
gcc/analyzer/region.cc| 57
gcc/analyzer/store.cc | 12 +---
gcc/analyzer/store.h | 2 +
gcc/testsuite/gcc.dg/analyzer/pr96651-1.c | 22 ++
gcc/testsuite/gcc.dg/analyzer/pr96651-2.c | 72
7 files changed, 224 insertions(+), 29 deletions(-)
create mode 100644 gcc/testsuite/gcc.dg/analyzer/pr96651-1.c
create mode 100644 gcc/testsuite/gcc.dg/analyzer/pr96651-2.c
diff --git a/gcc/analyzer/region-model.cc b/gcc/analyzer/region-model.cc
index c3d9ca7f650..5b08e48e6e5 100644
--- a/gcc/analyzer/region-model.cc
+++ b/gcc/analyzer/region-model.cc
@@ -1204,6 +1204,76 @@ region_model::get_rvalue (tree expr,
region_model_context *ctxt)
return get_rvalue (path_var (expr, get_stack_depth () - 1), ctxt);
}
+/* Return true if this model is on a path with "main" as the entrypoint
+ (as opposed to one in which we're merely analyzing a subset of the
+ path through the code). */
+
+bool
+region_model::called_from_main_p () const
+{
+ if (!m_current_frame)
+return false;
+ /* Determine if the oldest stack frame in this model is for "main". */
+ const frame_region *frame0 = get_frame_at_index (0);
+ gcc_assert (frame0);
+ return id_equal (DECL_NAME (frame0->get_function ()->decl), "main");
+}
+
+/* Subroutine of region_model::get_store_value for when REG is (or is within)
+ a global variable that hasn't been touched since the start of this path
+ (or was implicitly touched due to a call to an unknown function). */
+
+const svalue *
+region_model::get_initial_value_for_global (const region *reg) const
+{
+ /* Get the decl that REG is for (or is within). */
+ const decl_region *base_reg
+= reg->get_base_region ()->dyn_cast_decl_region ();
+ gcc_assert (base_reg);
+ tree decl = base_reg->get_decl ();
+
+ /* Special-case: to avoid having to explicitly update all previously
+ untracked globals when calling an unknown fn, they implicitly have
+ an unknown value if an unknown call has occurred, unless this is
+ static to-this-TU and hasn't escaped. Globals that have escaped
+ are explicitly tracked, so we shouldn't hit this case for them. */
+ if (m_store.called_unknown_fn_p () && TREE_PUBLIC (decl))
+return m_mgr->get_or_create_unknown_svalue (reg->get_type ());
+
+ /* If we are on a path from the entrypoint from "main" and we have a
+ global decl defined in this TU that hasn't been touched yet, then
+ the initial value of REG can be taken from the initialization value
+ of the decl. */
+ if (called_from_main_p () && !DECL_EXTERNAL (decl))
+{
+ /* Get the initializer value for base_reg. */
+ const svalue *base_reg_init
+ = base_reg->get_svalue_for_initializer (m_mgr);
+ gcc_assert (base_reg_init);
+ if (reg == base_reg)
+ return base_reg_init;
+ else
+ {
+ /* Get the value for REG within base_reg_init. */
+ binding_cluster c (base_reg);
+ c.bind (m_mgr->get_store_manager (), base_reg, base_reg_init,
+
[committed] analyzer: fix ICE with negative bit offsets [PR96648]
PR analyzer/96648 reports an ICE within get_field_at_bit_offset due
to a negative bit offset, arising due to pointer arithmetic.
This patch replaces an assertion with handling for this case, fixing the
ICE.
Successfully bootstrapped & regrtested on x86_64-pc-linux-gnu.
Pushed to master as r11-2753-g400abebf48a90d0797718ab7c3864de331e85b70.
gcc/analyzer/ChangeLog:
PR analyzer/96648
* region.cc (get_field_at_bit_offset): Gracefully handle negative
values for bit_offset.
gcc/testsuite/ChangeLog:
PR analyzer/96648
* gcc.dg/analyzer/pr96648.c: New test.
---
gcc/analyzer/region.cc | 3 ++-
gcc/testsuite/gcc.dg/analyzer/pr96648.c | 36 +
2 files changed, 38 insertions(+), 1 deletion(-)
create mode 100644 gcc/testsuite/gcc.dg/analyzer/pr96648.c
diff --git a/gcc/analyzer/region.cc b/gcc/analyzer/region.cc
index eab1f2771cf..770e2cb849e 100644
--- a/gcc/analyzer/region.cc
+++ b/gcc/analyzer/region.cc
@@ -226,7 +226,8 @@ static tree
get_field_at_bit_offset (tree record_type, bit_offset_t bit_offset)
{
gcc_assert (TREE_CODE (record_type) == RECORD_TYPE);
- gcc_assert (bit_offset >= 0);
+ if (bit_offset < 0)
+return NULL;
/* Find the first field that has an offset > BIT_OFFSET,
then return the one preceding it.
diff --git a/gcc/testsuite/gcc.dg/analyzer/pr96648.c
b/gcc/testsuite/gcc.dg/analyzer/pr96648.c
new file mode 100644
index 000..a6b0c727287
--- /dev/null
+++ b/gcc/testsuite/gcc.dg/analyzer/pr96648.c
@@ -0,0 +1,36 @@
+/* { dg-additional-options "-O1" } */
+
+struct vd {
+ struct vd *rs;
+};
+
+struct fh {
+ struct vd cl;
+};
+
+struct i3 {
+ struct fh *h4;
+};
+
+struct fh *
+gm (void);
+
+void
+j7 (struct vd *);
+
+inline void
+mb (struct vd *e7)
+{
+ j7 (e7->rs);
+}
+
+void
+po (struct i3 *d2)
+{
+ struct i3 *s2;
+
+ d2->h4 = gm ();
+ mb (>h4->cl);
+ s2 = ({ d2 - 1; });
+ po (s2);
+}
--
2.26.2
[Bug analyzer/96651] gcc 10 -fanalyzer fail to track (static) global variable in a switch
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96651 --- Comment #2 from CVS Commits --- The master branch has been updated by David Malcolm : https://gcc.gnu.org/g:623bc0276849d48ada5a7a2e3e94bd79de42c3db commit r11-2754-g623bc0276849d48ada5a7a2e3e94bd79de42c3db Author: David Malcolm Date: Mon Aug 17 16:35:10 2020 -0400 analyzer: consider initializers for globals [PR96651] PR analyzer/96651 reports a false positive in which a global that can't have been touched yet is checked in "main". The analyzer fails to reject code paths in which the initial value of the global makes the path condition impossible. This patch detects cases where the code path begins at the entrypoint of "main", and extracts values from initializers for globals that can't have been touched yet, rather than using a symbolic "INIT_VAL(REG)", fixing the false positive. gcc/analyzer/ChangeLog: PR analyzer/96651 * region-model.cc (region_model::called_from_main_p): New. (region_model::get_store_value): Move handling for globals into... (region_model::get_initial_value_for_global): ...this new function, and add logic for extracting values from decl initializers. * region-model.h (decl_region::get_svalue_for_constructor): New decl. (decl_region::get_svalue_for_initializer): New decl. (region_model::called_from_main_p): New decl. (region_model::get_initial_value_for_global): New. * region.cc (decl_region::maybe_get_constant_value): Move logic for getting an svalue from a CONSTRUCTOR node to... (decl_region::get_svalue_for_constructor): ...this new function. (decl_region::get_svalue_for_initializer): New. * store.cc (get_svalue_for_ctor_val): Rewrite in terms of region_model::get_rvalue. * store.h (binding_cluster::get_map): New accessor. gcc/testsuite/ChangeLog: PR analyzer/96651 * gcc.dg/analyzer/pr96651-1.c: New test. * gcc.dg/analyzer/pr96651-2.c: New test.
[Bug analyzer/96648] [11 Regression] ICE in get_field_at_bit_offset, at analyzer/region.cc:229
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96648 --- Comment #1 from CVS Commits --- The master branch has been updated by David Malcolm : https://gcc.gnu.org/g:400abebf48a90d0797718ab7c3864de331e85b70 commit r11-2753-g400abebf48a90d0797718ab7c3864de331e85b70 Author: David Malcolm Date: Mon Aug 17 21:12:35 2020 -0400 analyzer: fix ICE with negative bit offsets [PR96648] PR analyzer/96648 reports an ICE within get_field_at_bit_offset due to a negative bit offset, arising due to pointer arithmetic. This patch replaces an assertion with handling for this case, fixing the ICE. gcc/analyzer/ChangeLog: PR analyzer/96648 * region.cc (get_field_at_bit_offset): Gracefully handle negative values for bit_offset. gcc/testsuite/ChangeLog: PR analyzer/96648 * gcc.dg/analyzer/pr96648.c: New test.
[Bug tree-optimization/96697] New: Failure to optimize mod+div to 0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96697
Bug ID: 96697
Summary: Failure to optimize mod+div to 0
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: gabravier at gmail dot com
Target Milestone: ---
int f(int x, int y)
{
return (x % y) / y;
}
This can be optimized to `return 0;`. This transformation is done by LLVM, but
not by GCC.
[Bug tree-optimization/96696] New: Failure to optimize div+mul to mod+sub
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96696
Bug ID: 96696
Summary: Failure to optimize div+mul to mod+sub
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: gabravier at gmail dot com
Target Milestone: ---
int f(int x, int y)
{
return (x / y) * y;
}
This can be optimized to `return x - (x % y);`. This transformation is done by
LLVM, but not by GCC.
Re: [PATCH] rs6000: Add builtins for fegetround, feclearexcept and feraiseexcept [PR94193]
Hi!
On Fri, Aug 14, 2020 at 07:54:23PM -0300, Raoni Fassina Firmino via Gcc-patches
wrote:
> So, this patch adds new rs6000 expand optimizations for fegetround and
> for some calls to feclearexcept and feraiseexcept. All of them C99
> functions from fenv.h
And the fenv.h implementation can then use the builtins.
> To check the FE_* flags used in feclearexcept and feraiseexcept
> expands I decided copy verbatim the definitions from glibc instead of
> using the macros, which would means including fenv.h somewhere to get
> them.
Good plan :-)
> Still on feclearexcept and feraiseexcept I, I am not sure I used
> exact_log2_cint_operand correctly because on my tests it kept
> accepting feclearexcept(0) and it should not.
I am not sure what you mean. If you pass a number not one of the four
allowed ones, the pattern FAILs anyway?
In fact, you could just use const_int_operand with "n"?
> In any case, because I
> decided to test for all valid flags, this is not a problem for correct
> generation, but I thought I should mention it.
Ah gotcha. Yes, see above.
> --- a/gcc/builtins.c
> +++ b/gcc/builtins.c
> @@ -115,6 +115,8 @@ static rtx expand_builtin_mathfn_3 (tree, rtx, rtx);
> static rtx expand_builtin_mathfn_ternary (tree, rtx, rtx);
> static rtx expand_builtin_interclass_mathfn (tree, rtx);
> static rtx expand_builtin_sincos (tree);
> +static rtx expand_builtin_fegetround (tree, rtx, machine_mode);
> +static rtx expand_builtin_feclear_feraise_except (tree, rtx, machine_mode,
> optab);
That last line is too long, please break it?
> +/* Expand call EXP to the fegetround builtin (from C99 venv.h), returning the
"fenv.h"
> + if (target == 0
> + || GET_MODE (target) != target_mode
> + || ! (*insn_data[icode].operand[0].predicate) (target, target_mode))
> +target = gen_reg_rtx (target_mode);
> +
> + rtx pat = GEN_FCN (icode) (target);
> + if (! pat)
> +return NULL_RTX;
> + emit_insn (pat);
No space after unary operators (like !) please (the exception is those
written with alphabetics, like casts and sizeof).
I guess you copied this, so I don't know -- have to stop bad habits
somewhere I guess :-)
> +;; int __builtin_fegetround()
> +(define_expand "fegetroundsi"
> + [(use (match_operand:SI 0 "gpc_reg_operand"))]
> + "TARGET_HARD_FLOAT"
> +{
> +rtx tmp_df = gen_reg_rtx (DFmode);
Indentation should be just two spaces.
> +;; int feclearexcept(int excepts)
> +;;
> +;; This expansion for the C99 function only works when excepts is a
> +;; constant know at compile time and specifying only one of
> +;; FE_INEXACT, FE_DIVBYZERO, FE_UNDERFLOW and FE_OVERFLOW flags.
> +;; It dosen't handle values out of range, and always returns 0.
(doesn't)
> +;; Note that FE_INVALID is unsuported because it maps to more than
(unsupported)
> +;; one bit on FPSCR register.
You cannot set or clear the VX bit directly, yes (you have to twiddle
the component VX* bits you care about). Which we could do later
perhaps, but this is fine now :-)
> +;; Because this restrictions, this only expands on the desired cases.
(Because of these)
> +(define_expand "feclearexceptsi"
> + [(use (match_operand:SI 1 "exact_log2_cint_operand" "N"))
So just "const_int_operand" "n" should work fine here, and make it
more obvious that it won't actually allow all numbers.
> + switch (INTVAL (operands[1]))
> +{
> +case (1 << (31 - 6)): /* FE_INEXACT */
I would just write it as 0x02000 etc.? much clearer, and you have
the comment demagicificating it anyway!
> +case (1 << (31 - 5)): /* FE_DIVBYZERO */
> +case (1 << (31 - 4)): /* FE_UNDERFLOW */
> +case (1 << (31 - 3)): /* FE_OVERFLOW */
> + break;
> +default:
> + FAIL;
> +}
> +
> + rtx tmp = gen_rtx_CONST_INT (SImode, __builtin_clz (INTVAL(operands[1])));
Space after "INTVAL".
> + emit_insn (gen_rs6000_mtfsb0 (tmp));
> + emit_move_insn (operands[0], GEN_INT (0));
> + DONE;
> +})
GEN_INT (0) is just const0_rtx , please use that?
> +(define_expand "feraiseexceptsi"
> + [(use (match_operand:SI 1 "exact_log2_cint_operand" "N"))
> + (set (match_operand:SI 0 "gpc_reg_operand")
> +(const_int 0))]
Indent by 8 spaces should be a tab (here and elsewhere).
> +OPTAB_D (fegetround_optab, "fegetround$a")
> +OPTAB_D (feclearexcept_optab, "feclearexcept$a")
> +OPTAB_D (feraiseexcept_optab, "feraiseexcept$a")
Should those be documented somewhere? (In gcc/doc/ somewhere).
> --- /dev/null
> +++ b/gcc/testsuite/gcc.target/powerpc/builtin-feclearexcept-feraiseexcept-1.c
> @@ -0,0 +1,64 @@
> +/* { dg-do run { target { powerpc*-*-* } } } */
All files in gcc.target/powerpc/ are run for powerpc already; just
/* { dg-do run } */
please.
> +/* { dg-options "-lm -fno-builtin" } */
Does that work everywhere? AIX, Darwin, other non-Linux systems, systems
without OS, etc.
> +#include
That header does not exist everywhere. You can just declare the things
you need (the FE_ constants?)
Or perhaps you want to
[Bug tree-optimization/96695] Failure to optimize combination of pointer comparison to nullptr and another pointer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96695 --- Comment #1 from Gabriel Ravier --- PS: Very similar transformations can be done with alike patterns like `(x == 0) && (x <= y)`, which can be optimized to `x == 0`.
[Bug tree-optimization/96695] New: Failure to optimize combination of pointer comparison to nullptr and another pointer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96695
Bug ID: 96695
Summary: Failure to optimize combination of pointer comparison
to nullptr and another pointer
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: gabravier at gmail dot com
Target Milestone: ---
bool f(char *x, char *y)
{
return (x == 0) && (x > y);
}
This can be optimized to `return false;`. This transformation is done by LLVM,
but not by GCC.
[Bug c++/70462] Unnecessary "base object constructor" for final classes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70462 --- Comment #7 from Fabio Alemagna --- (In reply to Pádraig Brady from comment #6) > This does introduce an ABI incompatibility. > > I'm seeing this with kuduraft-1.8 compiled with GCC 10, giving linker errors > from clang 9.0.20190721 like: > > error: undefined symbol: kudu::consensus::OpId::OpId() > > Reverting this patch fixes the issue here. I second that. A library built with gcc10 is not linking with a program built with clang. Why would clang not call the complete class constructor, though?
[Bug tree-optimization/96694] New: Failure to optimize min/max pattern using two binary nots to min/max pattern using one binary not
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96694
Bug ID: 96694
Summary: Failure to optimize min/max pattern using two binary
nots to min/max pattern using one binary not
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: gabravier at gmail dot com
Target Milestone: ---
int f(int x, int y)
{
return ~((~x > y) ? ~x : y);
}
This can be optimized to `return ((~y <= x) ? ~y : x);`. This transformation is
done by LLVM, but not by GCC.
Re: [PATCH] Fortran : rejected f0.d edit descriptor PR96436
On 8/17/20 12:31 AM, Mark Eggleston wrote: Please find attached a patch for PR96436. OK to commit? Looks good to me. Thanks for fixing this. Regards, Jerry
[Bug tree-optimization/96693] New: GCC produces incorrect code with -O2 for loops
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96693
Bug ID: 96693
Summary: GCC produces incorrect code with -O2 for loops
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: vsevolod.livinskij at frtk dot ru
Target Milestone: ---
Error:
>$ g++ -O2 driver.cpp func.cpp && ./a.out
0
>$ g++ -O0 driver.cpp func.cpp && ./a.out
42
Reproducer:
//func.cpp
extern char var_20;
extern short var_22;
void test(unsigned a,
bool b,
long long p12[23]) {
for (int c = 0; c < 2;) {
if (b) {
for (int d = 0; d < 4082; d += 2)
for (int e = 0; e < a; e = 2)
var_20 = 0;
var_22 = 0;
}
c = p12[c];
}
}
//driver.cpp
#include
unsigned int var_4 = 140810747U;
bool var_7 = (bool)0;
unsigned char var_20 = (unsigned char)82;
unsigned short var_22 = 42;
long long int arr_9 [23] ;
void test(unsigned int var_4, bool var_7, long long int arr_9 [23]);
int main() {
for (size_t i_0 = 0; i_0 < 23; ++i_0)
arr_9 [i_0] = -722784397873599555LL;
test(var_4, var_7, arr_9);
printf("%d\n", var_22);
}
GCC version:
11.0.0 20200816 (23747614cc8fc137c1f2ca64c8e224125a72fae5) + fix proposed in
bug 95396
Re: [PATCH v2] libgcc: Use `-fasynchronous-unwind-tables' for LIB2_DIVMOD_FUNCS
On 06/08/2020 14:04, Maciej W. Rozycki via Gcc-patches wrote:
> Complement commit b932f770f70d ("x86_64 frame unwind info"), SVN r46374,
> , and replace
> `-fexceptions -fnon-call-exceptions' with `-fasynchronous-unwind-tables'
> in LIB2_DIVMOD_FUNCS compilation flags so as to provide unwind tables
> for the affected functions while not pulling the unwinder proper, which
> is not required here.
>
> Remove the ARM overrides accordingly, retaining the hook infrastructure
> however, and make the ARM test case a generic one.
>
> Beyond saving program space it fixes a RISC-V glibc build error due to
> unsatisfied `malloc' and `free' references from the unwinder causing
> link errors with `ld.so' where libgcc has been built at -O0.
>
> gcc/
> * testsuite/gcc.target/arm/div64-unwinding.c: Rename to...
> * testsuite/gcc.dg/div64-unwinding.c: ... this.
>
> libgcc/
> * Makefile.in [!LIB2_DIVMOD_EXCEPTION_FLAGS]
> (LIB2_DIVMOD_EXCEPTION_FLAGS): Replace `-fexceptions
> -fnon-call-exceptions' with `-fasynchronous-unwind-tables'.
> * config/arm/t-bpabi (LIB2_DIVMOD_EXCEPTION_FLAGS): Remove
> variable.
> * config/arm/t-netbsd-eabi (LIB2_DIVMOD_EXCEPTION_FLAGS):
> Likewise.
>From a quick glance, I'm not convinced this is right for Arm, since the
Arm unwind format does not support anything other than call-based
exceptions. How did you test it?
R.
> ---
> Hi,
>
> I realised we still use handwritten ChangeLog entries (I got confused
> with now different policies each of the various pieces of the GNU
> toolchain has), so here's v2 of the change with a fix for that problem
> being the only update.
>
> Also I have since run verification with the `riscv64-linux-gnu' target
> and the ilp32d multilib as more representative for the change being made.
> No problems were observed, although the now enabled test case scored:
>
> UNSUPPORTED: gcc.dg/div64-unwinding.c
>
> of course with the target failing the `! *-*-linux*' condition.
>
> Given that for the `riscv64-linux-gnu' target and the ilp32d multilib
> glibc currently fails to link against libgcc.a built at -O0 I first ran
> reference testing with target libraries built at -O2, but comparing that
> to change-under-test -O2 results revealed another issue with GCC target
> libraries built at -O0 causing link failures across testsuites, namely
> libgcov.a referring atomic primitives where libatomic.a has not been
> linked in. I haven't figured out yet if the issue is in libgcov, the
> testsuite or the specs. Examples of failures:
>
> .../bin/riscv64-linux-gnu-ld:
> .../gcc/testsuite/g++/../../lib32/ilp32d/libgcov.a(_gcov_indirect_call_profiler_v4.o):
> in function `__gcov_topn_values_profiler_body':
> .../libgcc/libgcov-profiler.c:116: undefined reference to
> `__atomic_fetch_add_8'
> .../bin/riscv64-linux-gnu-ld: .../libgcc/libgcov-profiler.c:129: undefined
> reference to `__atomic_fetch_add_8'
> .../bin/riscv64-linux-gnu-ld: .../libgcc/libgcov-profiler.c:150: undefined
> reference to `__atomic_fetch_sub_8'
> collect2: error: ld returned 1 exit status
> compiler exited with status 1
> FAIL: g++.dg/other/pr55650.C -std=gnu++98 (test for excess errors)
>
> There were some odd Fortran failures too, with test cases failing to link,
> making the results difficult to interpret. Therefore I decided to arrange
> for a special build with first stage GCC built with its target libraries
> at -O2, so that first stage glibc builds, and then second stage GCC built
> with its target libraries at -O0 and second stage glibc omitted. That
> removed the extra Fortran failures regardless of whether this change has
> been applied or not, but we may consider looking overall into why a full
> `riscv64-linux-gnu' build at -O0 has regressions against -O2 at least in
> the ilp32d multilib.
>
> Meanwhile, OK to apply?
>
> Maciej
>
> Changes from v1:
>
> - ChangeLog entries added.
> ---
> gcc/testsuite/gcc.dg/div64-unwinding.c | 25
> +
> gcc/testsuite/gcc.target/arm/div64-unwinding.c | 25
> -
> libgcc/Makefile.in |2 +-
> libgcc/config/arm/t-bpabi |5 -
> libgcc/config/arm/t-netbsd-eabi|5 -
> 5 files changed, 26 insertions(+), 36 deletions(-)
>
> gcc-libgcc-divmod-asynchronous-unwind-tables.diff
> Index: gcc/gcc/testsuite/gcc.dg/div64-unwinding.c
> ===
> --- /dev/null
> +++ gcc/gcc/testsuite/gcc.dg/div64-unwinding.c
> @@ -0,0 +1,25 @@
> +/* Performing a 64-bit division should not pull in the unwinder. */
> +
> +/* { dg-do run { target { { ! *-*-linux* } && { ! *-*-uclinux* } } } } */
> +/* { dg-skip-if "load causes weak symbol resolution" { vxworks_kernel } } */
> +/* { dg-options "-O0" } */
> +
> +#include
> +
[PATCH] i386: Add c99 runtime requirement to math optimisation tests
A number of i386 math optimisation tests are looking assembly instructions
that are only emitted when the compiler knows the target has a C99 libm
available. Since targets like *-elf may not have such a libm, a C99 runtime
requirement is added to these tests.
Tested on x86-elf and x86_64-elf hosted on x86_64-linux in addition to
x86_64-pc-linux-gnu
If approved, I'll need a maintainer to kindly commit on my behalf.
Thanks,
Pat Bernardi
Senior Software Engineer, AdaCore
2020-08-18 Pat Bernardi
gcc/testsuite/ChangeLog
* gcc.target/i386/387-7.c: Add dg-require-effective-target c99_runtime.
* gcc.target/i386/387-9.c: Likewise.
* gcc.target/i386/avx512bw-pr96246-1.c: Likewise.
* gcc.target/i386/avx512f-rint-sfix-vec-2.c: Likewise.
* gcc.target/i386/avx512f-rintf-sfix-vec-2.c: Likewise.
* gcc.target/i386/avx512vl-pr96246-1.c: Likewise.
* gcc.target/i386/pr61403.c: Likewise.
* gcc.target/i386/sse4_1-ceil-sfix-vec.c: Likewise.
* gcc.target/i386/sse4_1-ceilf-sfix-vec.c: Likewise.
* gcc.target/i386/sse4_1-floor-sfix-vec.c: Likewise.
* gcc.target/i386/sse4_1-floorf-sfix-vec.c: Likewise.
* gcc.target/i386/sse4_1-rint-sfix-vec.c: Likewise.
* gcc.target/i386/sse4_1-rintf-sfix-vec.c: Likewise.
* gcc.target/i386/sse4_1-round-sfix-vec.c: Likewise.
* gcc.target/i386/sse4_1-roundf-sfix-vec.c: Likewise.
---
gcc/testsuite/gcc.target/i386/387-7.c| 1 +
gcc/testsuite/gcc.target/i386/387-9.c| 1 +
gcc/testsuite/gcc.target/i386/avx512bw-pr96246-1.c | 1 +
gcc/testsuite/gcc.target/i386/avx512f-rint-sfix-vec-2.c | 1 +
gcc/testsuite/gcc.target/i386/avx512f-rintf-sfix-vec-2.c | 1 +
gcc/testsuite/gcc.target/i386/avx512vl-pr96246-1.c | 1 +
gcc/testsuite/gcc.target/i386/pr61403.c | 1 +
gcc/testsuite/gcc.target/i386/sse4_1-ceil-sfix-vec.c | 1 +
gcc/testsuite/gcc.target/i386/sse4_1-ceilf-sfix-vec.c| 1 +
gcc/testsuite/gcc.target/i386/sse4_1-floor-sfix-vec.c| 1 +
gcc/testsuite/gcc.target/i386/sse4_1-floorf-sfix-vec.c | 1 +
gcc/testsuite/gcc.target/i386/sse4_1-rint-sfix-vec.c | 1 +
gcc/testsuite/gcc.target/i386/sse4_1-rintf-sfix-vec.c| 1 +
gcc/testsuite/gcc.target/i386/sse4_1-round-sfix-vec.c| 1 +
gcc/testsuite/gcc.target/i386/sse4_1-roundf-sfix-vec.c | 1 +
15 files changed, 15 insertions(+)
diff --git a/gcc/testsuite/gcc.target/i386/387-7.c
b/gcc/testsuite/gcc.target/i386/387-7.c
index e01ed2e0576..3c1ad606462 100644
--- a/gcc/testsuite/gcc.target/i386/387-7.c
+++ b/gcc/testsuite/gcc.target/i386/387-7.c
@@ -1,6 +1,7 @@
/* Verify that 387 fsincos instruction is generated. */
/* { dg-do compile } */
/* { dg-options "-O -ffast-math -mfpmath=387 -mfancy-math-387" } */
+/* { dg-require-effective-target c99_runtime } */
/* { dg-final { scan-assembler "fsincos" } } */
extern double sin (double);
diff --git a/gcc/testsuite/gcc.target/i386/387-9.c
b/gcc/testsuite/gcc.target/i386/387-9.c
index 2667aa46872..469c635e479 100644
--- a/gcc/testsuite/gcc.target/i386/387-9.c
+++ b/gcc/testsuite/gcc.target/i386/387-9.c
@@ -1,6 +1,7 @@
/* Verify that 387 fsincos instruction is generated. */
/* { dg-do compile } */
/* { dg-options "-O -funsafe-math-optimizations -mfpmath=387 -mfancy-math-387"
} */
+/* { dg-require-effective-target c99_runtime } */
extern double sin (double);
extern double cos (double);
diff --git a/gcc/testsuite/gcc.target/i386/avx512bw-pr96246-1.c
b/gcc/testsuite/gcc.target/i386/avx512bw-pr96246-1.c
index 2bfcc840a91..4aaa28866ca 100644
--- a/gcc/testsuite/gcc.target/i386/avx512bw-pr96246-1.c
+++ b/gcc/testsuite/gcc.target/i386/avx512bw-pr96246-1.c
@@ -1,6 +1,7 @@
/* PR target/96246 */
/* { dg-do compile } */
/* { dg-options "-O2 -ftree-vectorize -mavx512bw" } */
+/* { dg-require-effective-target c99_runtime } */
/* { dg-final { scan-assembler-times "vpblendm\[bwdq\]\[\t ]" 4 } } */
/* { dg-final { scan-assembler-times "vblendmp\[sd\]\[\t ]" 2 } } */
diff --git a/gcc/testsuite/gcc.target/i386/avx512f-rint-sfix-vec-2.c
b/gcc/testsuite/gcc.target/i386/avx512f-rint-sfix-vec-2.c
index c3f78ac3f25..2d2099f77cb 100644
--- a/gcc/testsuite/gcc.target/i386/avx512f-rint-sfix-vec-2.c
+++ b/gcc/testsuite/gcc.target/i386/avx512f-rint-sfix-vec-2.c
@@ -1,5 +1,6 @@
/* { dg-do compile } */
/* { dg-options "-O2 -ffast-math -ftree-vectorize -mavx512f" } */
+/* { dg-require-effective-target c99_runtime } */
#include "avx512f-rint-sfix-vec-1.c"
diff --git a/gcc/testsuite/gcc.target/i386/avx512f-rintf-sfix-vec-2.c
b/gcc/testsuite/gcc.target/i386/avx512f-rintf-sfix-vec-2.c
index c172e61f84a..fe473766c86 100644
--- a/gcc/testsuite/gcc.target/i386/avx512f-rintf-sfix-vec-2.c
+++ b/gcc/testsuite/gcc.target/i386/avx512f-rintf-sfix-vec-2.c
@@ -1,5 +1,6 @@
/* { dg-do compile } */
/* { dg-options "-O2 -ffast-math -ftree-vectorize -mavx512f" } */
+/* { dg-require-effective-target c99_runtime } */
[PATCH] testsuite: require c99 runtime for trigonometric optimisation tests
A number of optimisation that simplify trigonometric expressions are only
performed when the compiler knows the target has a C99 libm available.
Since targets like *-elf may not have such a libm, a C99 runtime requirement
is added to these tests.
Tested on x86-elf and x86_64-elf hosted on x86_64-linux in addition to
x86_64-pc-linux-gnu
If approved, I'll need a maintainer to kindly commit on my behalf.
Thanks,
Pat Bernardi
Senior Software Engineer, AdaCore
2020-08-18 Pat Bernardi
gcc/testsuite/ChangeLog
* gcc.dg/sinatan-2.c: Add dg-require-effective-target c99_runtime.
* gcc.dg/sinhovercosh-1.c: Likewise.
* gcc.dg/tanhbysinh.c: Likewise.
---
gcc/testsuite/gcc.dg/sinatan-2.c | 1 +
gcc/testsuite/gcc.dg/sinhovercosh-1.c | 1 +
gcc/testsuite/gcc.dg/tanhbysinh.c | 3 ++-
3 files changed, 4 insertions(+), 1 deletion(-)
diff --git a/gcc/testsuite/gcc.dg/sinatan-2.c b/gcc/testsuite/gcc.dg/sinatan-2.c
index 8e7ea3c90fc..64d6d301535 100644
--- a/gcc/testsuite/gcc.dg/sinatan-2.c
+++ b/gcc/testsuite/gcc.dg/sinatan-2.c
@@ -1,5 +1,6 @@
/* { dg-do compile } */
/* { dg-options "-Ofast -fdump-tree-optimized" } */
+/* { dg-require-effective-target c99_runtime } */
extern float sinf (float);
extern float cosf (float);
diff --git a/gcc/testsuite/gcc.dg/sinhovercosh-1.c
b/gcc/testsuite/gcc.dg/sinhovercosh-1.c
index d41093fa6de..564d3c51b3e 100644
--- a/gcc/testsuite/gcc.dg/sinhovercosh-1.c
+++ b/gcc/testsuite/gcc.dg/sinhovercosh-1.c
@@ -1,5 +1,6 @@
/* { dg-do compile } */
/* { dg-options "-Ofast -fdump-tree-optimized" } */
+/* { dg-require-effective-target c99_runtime } */
extern float sinhf (float);
extern float coshf (float);
diff --git a/gcc/testsuite/gcc.dg/tanhbysinh.c
b/gcc/testsuite/gcc.dg/tanhbysinh.c
index fde72c2f93b..9dbe133ec74 100644
--- a/gcc/testsuite/gcc.dg/tanhbysinh.c
+++ b/gcc/testsuite/gcc.dg/tanhbysinh.c
@@ -1,5 +1,6 @@
/* { dg-do compile } */
/* { dg-options "-Ofast -fdump-tree-optimized" } */
+/* { dg-require-effective-target c99_runtime } */
extern float sinhf (float);
extern float tanhf (float);
@@ -37,4 +38,4 @@ tanhbysinhl_ (long double x)
/* {dg-final { scan-tree-dump-not "tanhl " "optimized" }} */
/* { dg-final { scan-tree-dump "cosh " "optimized" } } */
/* { dg-final { scan-tree-dump "coshf " "optimized" } } */
-/* { dg-final { scan-tree-dump "coshl " "optimized" } } */
\ No newline at end of file
+/* { dg-final { scan-tree-dump "coshl " "optimized" } } */
--
2.27.0
[Bug rtl-optimization/96692] Failure to optimize xor+or+xor to andnot+xor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96692 Andrew Pinski changed: What|Removed |Added Severity|normal |enhancement Component|tree-optimization |rtl-optimization --- Comment #1 from Andrew Pinski --- This transformation should only happen if there is an andnot instruction. For an example if there is no andnot instruction, there will be 3 dependent instruction while in the first case, there are two independent instructions followed by one dependent ones.
[PATCH] i386: Cleanup i386/i386elf.h and align it's return convention with the SVR4 ABI
As observed a number of years ago in the following thread, i386/i386elf.h has
not been kept up to date:
https://gcc.gnu.org/pipermail/gcc/2013-August/209981.html
This patch does the following cleanup:
1. The return convention now follows the i386 and x86_64 SVR4 ABIs again. As
discussed in the above thread, the current return convention does not match any
other target or existing ABI, which is problematic since the current approach
is inefficient (particularly on x86_64-elf) and confuses other tools like GDB
(unfortunately that thread did not lead to any fix at the time).
2. The default version of ASM_OUTPUT_ASCII from elfos.h is used. As mentioned
in the cleanup of i386/sysv4.h [1] the ASM_OUTPUT_ASCII implementation then
used by sysv4.h, and currently used by i386elf.h, has a significantly higher
computation complexity than the default version provided by elfos.h.
The patch has been tested on i386-elf and x86_64-elf hosted on x86_64-linux,
fixing a number failing tests that were expecting the SVR4 ABI return
convention. It has also been bootstrapped and tested on x86_64-pc-linux-gnu
without regression.
If approved, I'll need a maintainer to kindly commit on my behalf.
Thanks,
Pat Bernardi
Senior Software Engineer, AdaCore
[1] https://gcc.gnu.org/pipermail/gcc-patches/2011-February/305559.html
2020-08-18 Pat Bernardi
gcc/ChangeLog
* config/i386/i386elf.h (SUBTARGET_RETURN_IN_MEMORY): Remove.
(ASM_OUTPUT_ASCII): Likewise.
(DEFAULT_PCC_STRUCT_RETURN): Define.
* config/i386/i386.c (ix86_return_in_memory): Remove
SUBTARGET_RETURN_IN_MEMORY.
From fe617455561a4c8d898b4e231c447b16e5661e10 Mon Sep 17 00:00:00 2001
From: Pat Bernardi
Date: Fri, 14 Aug 2020 17:34:38 -0400
Subject: [PATCH] i386: Cleanup i386/i386elf.h and align it's return convention
with the SVR4 ABI
While i386elf.h was originally derived from sysv4.h it has not been kept
up to date with the development of the compiler. Two changes are made:
* The return convention now follows the i386 and x86_64 SVR4 ABIs again.
* The more efficient default version of ASM_OUTPUT_ASCII in elfos.h is used.
2020-08-18 Pat Bernardi
gcc/ChangeLog
* config/i386/i386elf.h (SUBTARGET_RETURN_IN_MEMORY): Remove.
(ASM_OUTPUT_ASCII): Likewise.
(DEFAULT_PCC_STRUCT_RETURN): Define.
* config/i386/i386.c (ix86_return_in_memory): Remove
SUBTARGET_RETURN_IN_MEMORY.
---
gcc/config/i386/i386.c| 4 ---
gcc/config/i386/i386elf.h | 62 ---
2 files changed, 6 insertions(+), 60 deletions(-)
diff --git a/gcc/config/i386/i386.c b/gcc/config/i386/i386.c
index e9ecb94d174..65e87b41e80 100644
--- a/gcc/config/i386/i386.c
+++ b/gcc/config/i386/i386.c
@@ -3796,9 +3796,6 @@ ix86_libcall_value (machine_mode mode)
static bool
ix86_return_in_memory (const_tree type, const_tree fntype ATTRIBUTE_UNUSED)
{
-#ifdef SUBTARGET_RETURN_IN_MEMORY
- return SUBTARGET_RETURN_IN_MEMORY (type, fntype);
-#else
const machine_mode mode = type_natural_mode (type, NULL, true);
HOST_WIDE_INT size;
@@ -3879,7 +3876,6 @@ ix86_return_in_memory (const_tree type, const_tree fntype
ATTRIBUTE_UNUSED)
return false;
}
-#endif
}
diff --git a/gcc/config/i386/i386elf.h b/gcc/config/i386/i386elf.h
index eb2203cf323..05cee89f795 100644
--- a/gcc/config/i386/i386elf.h
+++ b/gcc/config/i386/i386elf.h
@@ -19,12 +19,12 @@ You should have received a copy of the GNU General Public
License
along with GCC; see the file COPYING3. If not see
c++: alias template template_info setting
During the construction of alias templates we can alter its
template_info. This is really weird, because that's morally immutable
data. In this case it's ok, but let's not create a duplicate
template_info, and add asserts to make sure it is changing in exactly
the way we expect.
Needless to say modules fell over the duplicated template_info and got
very confused.
gcc/cp/
* cp-tree.h (SET_TYPE_TEMPLTE_INFO): Do not deal with ALIAS
templates.
* pt.c (lookup_template_class_1): Special-case alias template
template_info setting.
--
Nathan Sidwell
diff --git i/gcc/cp/cp-tree.h w/gcc/cp/cp-tree.h
index 04758574019..5f2c7e574c4 100644
--- i/gcc/cp/cp-tree.h
+++ w/gcc/cp/cp-tree.h
@@ -3485,13 +3485,12 @@ struct GTY(()) lang_decl {
? TYPE_ALIAS_TEMPLATE_INFO (NODE) \
: TYPE_TEMPLATE_INFO (NODE))
-/* Set the template information for an ENUMERAL_, RECORD_, or
- UNION_TYPE to VAL. */
+/* Set the template information for a non-alias n ENUMERAL_, RECORD_,
+ or UNION_TYPE to VAL. ALIAS's are dealt with separately. */
#define SET_TYPE_TEMPLATE_INFO(NODE, VAL)\
- (TREE_CODE (NODE) == ENUMERAL_TYPE \
- || (CLASS_TYPE_P (NODE) && !TYPE_ALIAS_P (NODE)) \
- ? (TYPE_LANG_SLOT_1 (NODE) = (VAL))\
- : (DECL_TEMPLATE_INFO (TYPE_NAME (NODE)) = (VAL)))
+ (gcc_checking_assert (TREE_CODE (NODE) == ENUMERAL_TYPE \
+ || (CLASS_TYPE_P (NODE) && !TYPE_ALIAS_P (NODE))), \
+ (TYPE_LANG_SLOT_1 (NODE) = (VAL))) \
#define TI_TEMPLATE(NODE) \
((struct tree_template_info*)TEMPLATE_INFO_CHECK (NODE))->tmpl
diff --git i/gcc/cp/pt.c w/gcc/cp/pt.c
index b80fe0a5cc5..ada0438f272 100644
--- i/gcc/cp/pt.c
+++ w/gcc/cp/pt.c
@@ -10088,8 +10088,26 @@ lookup_template_class_1 (tree d1, tree arglist, tree in_decl, tree context,
}
}
- // Build template info for the new specialization.
- SET_TYPE_TEMPLATE_INFO (t, build_template_info (found, arglist));
+ /* Build template info for the new specialization. */
+ if (TYPE_ALIAS_P (t))
+ {
+ /* This is constructed during instantiation of the alias
+ decl. But for member templates of template classes, that
+ is not correct as we need to refer to the partially
+ instantiated template, not the most general template.
+ The incorrect knowledge will not have escaped this
+ instantiation process, so we're good just updating the
+ template_info we made then. */
+ tree ti = DECL_TEMPLATE_INFO (TYPE_NAME (t));
+ gcc_checking_assert (template_args_equal (TI_ARGS (ti), arglist));
+ if (TI_TEMPLATE (ti) != found)
+ {
+ gcc_checking_assert (DECL_TI_TEMPLATE (found) == TI_TEMPLATE (ti));
+ TI_TEMPLATE (ti) = found;
+ }
+ }
+ else
+ SET_TYPE_TEMPLATE_INFO (t, build_template_info (found, arglist));
elt.spec = t;
slot = type_specializations->find_slot_with_hash (, hash, INSERT);
Re: [EXTERNAL] Re: [Patch 1/5] rs6000, Add 128-bit sign extension support
On Thu, Aug 13, 2020 at 06:53:56PM -0500, will schmidt wrote: > On Thu, 2020-08-13 at 17:55 -0500, Segher Boessenkool wrote: > > > As long as there are no issues defining the builtins for 3.0 here. > > > AFAIK they are not documented in ISA 3.0. This is a happy accident > > > that these ISA 3.1 builtins can be implemented with existing > > > support. > > > > There are *no* builtins defined in the ISA! The insns are just ISA > > 3.0 > > instructions. > > Ok. > > So then maybe just "Sign extend builtins" and leave off the ISA > reference all together. Sure. Or you can say "builtins for the instructions introduced in Power ISA 3.1" or such. If we ever get the builtins documentation updated quickly (and updated), it should go on https://gcc.gnu.org/readings.html , and live will be good. Segher
[Bug tree-optimization/96692] New: Failure to optimize xor+or+xor to andnot+xor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96692
Bug ID: 96692
Summary: Failure to optimize xor+or+xor to andnot+xor
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: gabravier at gmail dot com
Target Milestone: ---
int f(int a, int b, int c)
{
return (a ^ b) ^ (a | c);
}
This can be optimized to `return (c & ~a) ^ b;`. This transformation is done by
LLVM, but not by GCC.
Re: [RFC PATCH v1 1/1] PPC64: Implement POWER Architecture Vector Function ABI.
On Tue, Aug 18, 2020 at 07:14:19PM +, GT wrote: > > That sounds like libmvec? > > > > I still don't know what this is. > > Yes, it is libmvec. > > Now look at what GCC does to the code in Examples 1 and 2 at this link: > https://sourceware.org/glibc/wiki/libmvec > > x86_64 added functionality to GCC so such code uses the new functions without > the user > having to re-write the loops and explicitly call the new functions. > > We are aiming to provide that same capability for PPC64 in GCC. Great! Please repost with what I already pointed out fixed, that explanation added, and working links to the documentation? Thanks in advance, Segher
[Bug tree-optimization/96691] Failure to optimize bitwise not+or+xor with constants to and+xor with bitwise not-ed constants
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96691
--- Comment #1 from Gabriel Ravier ---
int f(int x)
{
return (~x & 123) ^ 321;
}
A very similar transformation can be done with this code, transforming it to
`return (x & 123) ^ 314;` (according to LLVM), and a similar transformation
should be possible with other constants, though I can't identify myself the
exact transformation you'd need to generalise this to all constants.
[Bug tree-optimization/96691] New: Failure to optimize not+or+xor with constants to and+xor with bitwise not-ed constants
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96691
Bug ID: 96691
Summary: Failure to optimize not+or+xor with constants to
and+xor with bitwise not-ed constants
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: gabravier at gmail dot com
Target Milestone: ---
int f(int x)
{
return (~x | 123) ^ 321;
}
This can be optimized to `return (x & ~123) ^ ~321;` (and the same
transformation can be applied with any constants replacing 123 and 321). This
transformation is done by LLVM, but not by GCC.
[Bug tree-optimization/96688] Failure to optimize shift-right+not of constant to avoid not
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96688
--- Comment #1 from Gabriel Ravier ---
int f(int x)
{
return ~(x + 123);
}
A very similar optimization can be done with this, by converting this to
`return ~123 - x;` (and the constant can be swapped out with pretty much any
other constant here too).
[Bug c++/96355] [concepts] internal compiler error: in tsubst_pack_expansion, at cp/pt.c:12928
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96355 Robert Douglas changed: What|Removed |Added CC||rwdougla at gmail dot com --- Comment #1 from Robert Douglas --- I've also hit this issue in upgrading from 9.1 to 10.2 I presume it run into the same issue, but if it helps, this more closely matches my use case: https://godbolt.org/z/zb1bP5
[Bug c++/83445] conversion function has too high priority in overload resolution
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83445 --- Comment #4 from Alexander Karzhenkov --- r269667 concerns initializing an object from prvalue. Here we have `Target` being initialized from lvalue if type `Source`. What we can consider as being initialized from prvalue is the argument of copy constructor. It would get the result of `Source::operator Target()`, but this can be optimized out here. Such optimization, however, is not a mandatory copy elision (introduced by C++17). The latter is not applicable to reference initialization. The mandatory copy elision also is not applicable to initialization `Target` from `Source` as they are different types (see [dcl.init], item 17.6.1). In case of direct initialization the candidates are all constructors of `Target`, but not the conversion operator of `Source` (see [over.match.ctor]). One of constructors must be called (but this call can be optimized out). The question here is about implicit conversion for argument of the constructor. Overload resolution matches the argument of each constructor against the initializer (which is lvalue of `Source`). The best match is for `Target(Source const&)` as it doesn't require any user-defined conversion. If compiler prefers `Target(Target const&)`, it has to perform copy initialization of its argument from `Source`. Such copy initialization cannot be performed without user-defined conversion, so it is worse. Invoking the constructor `Target(Source const&)` is user-defined conversion whereas binding `Source const&` to `source` is not. But the constructor is invoked explicitly; overload resolution only takes into account argument/parameter match.
[Bug c++/96199] [10/11 Regression] internal compiler error: in tsubst_copy with CTAD for alias templates
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96199 --- Comment #6 from CVS Commits --- The releases/gcc-10 branch has been updated by Jason Merrill : https://gcc.gnu.org/g:7fc49a5777943aab11e227136d00a836f28f12b2 commit r10-8639-g7fc49a5777943aab11e227136d00a836f28f12b2 Author: Jason Merrill Date: Thu Aug 6 02:40:10 2020 -0400 c++: Handle enumerator in C++20 alias CTAD. [PR96199] To form a deduction guide for an alias template, we substitute the template arguments from the pattern into the deduction guide for the underlying class. In the case of B(A1), that produces B(A1::X>) -> B. But since an enumerator doesn't have its own template info, and B is a dependent scope, trying to look up B::X fails and we crash. So we need to produce a SCOPE_REF instead. And trying to use the members of the template class is wrong for other members, as well, as it gives a nonsensical result if the class is specialized. gcc/cp/ChangeLog: PR c++/96199 * pt.c (maybe_dependent_member_ref): New. (tsubst_copy) [CONST_DECL]: Use it. [VAR_DECL]: Likewise. (tsubst_aggr_type): Handle nested type. gcc/testsuite/ChangeLog: PR c++/96199 * g++.dg/cpp2a/class-deduction-alias4.C: New test.
[Bug c++/96199] [10/11 Regression] internal compiler error: in tsubst_copy with CTAD for alias templates
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96199 --- Comment #4 from CVS Commits --- The master branch has been updated by Jason Merrill : https://gcc.gnu.org/g:9125cf8c33b710c378bfb3c7e67ec2f9f1c523c9 commit r11-2747-g9125cf8c33b710c378bfb3c7e67ec2f9f1c523c9 Author: Jason Merrill Date: Thu Aug 6 02:40:10 2020 -0400 c++: Handle enumerator in C++20 alias CTAD. [PR96199] To form a deduction guide for an alias template, we substitute the template arguments from the pattern into the deduction guide for the underlying class. In the case of B(A1), that produces B(A1::X>) -> B. But since an enumerator doesn't have its own template info, and B is a dependent scope, trying to look up B::X fails and we crash. So we need to produce a SCOPE_REF instead. And trying to use the members of the template class is wrong for other members, as well, as it gives a nonsensical result if the class is specialized. gcc/cp/ChangeLog: PR c++/96199 * pt.c (maybe_dependent_member_ref): New. (tsubst_copy) [CONST_DECL]: Use it. [VAR_DECL]: Likewise. (tsubst_aggr_type): Handle nested type. gcc/testsuite/ChangeLog: PR c++/96199 * g++.dg/cpp2a/class-deduction-alias4.C: New test.
[PATCH 2/2] c++: Rewrite members for all deduction guides. [PR96199]
After the last patch, it occurred to me that we could run into the
specialization issue with non-alias deduction guides as well, so this patch
extends the rewriting to C++17 mode.
Doing this revealed that we weren't properly pushing into class scope for
normalization.
Tested x86_64-pc-linux-gnu, applying to trunk.
gcc/cp/ChangeLog:
PR c++/96199
* pt.c (tsubst_aggr_type): Rewrite in C++17, too.
(maybe_dependent_member_ref): Likewise.
(build_deduction_guide): Re-substitute template parms.
* cp-tree.h (struct push_nested_class_guard): New.
* constraint.cc (get_normalized_constraints_from_decl): Use it.
gcc/testsuite/ChangeLog:
PR c++/96199
* g++.dg/cpp1z/class-deduction-spec1.C: New test.
---
gcc/cp/cp-tree.h | 18 +
gcc/cp/constraint.cc | 2 +
gcc/cp/pt.c | 17 +++--
.../g++.dg/cpp1z/class-deduction-spec1.C | 38 +++
4 files changed, 71 insertions(+), 4 deletions(-)
create mode 100644 gcc/testsuite/g++.dg/cpp1z/class-deduction-spec1.C
diff --git a/gcc/cp/cp-tree.h b/gcc/cp/cp-tree.h
index 04758574019..5ba82ee60db 100644
--- a/gcc/cp/cp-tree.h
+++ b/gcc/cp/cp-tree.h
@@ -8137,6 +8137,24 @@ is_constrained_auto (const_tree t)
return is_auto (t) && PLACEHOLDER_TYPE_CONSTRAINTS (t);
}
+/* RAII class to push/pop class scope T; if T is not a class, do nothing. */
+
+struct push_nested_class_guard
+{
+ bool push;
+ push_nested_class_guard (tree t)
+: push (t && CLASS_TYPE_P (t))
+ {
+if (push)
+ push_nested_class (t);
+ }
+ ~push_nested_class_guard ()
+ {
+if (push)
+ pop_nested_class ();
+ }
+};
+
#if CHECKING_P
namespace selftest {
extern void run_cp_tests (void);
diff --git a/gcc/cp/constraint.cc b/gcc/cp/constraint.cc
index e4aace596e7..48d52ec5b7a 100644
--- a/gcc/cp/constraint.cc
+++ b/gcc/cp/constraint.cc
@@ -840,6 +840,8 @@ get_normalized_constraints_from_decl (tree d, bool diag =
false)
if (tree *p = hash_map_safe_get (normalized_map, tmpl))
return *p;
+ push_nested_class_guard pncs (DECL_CONTEXT (d));
+
tree args = generic_targs_for (tmpl);
tree ci = get_constraints (decl);
tree norm = get_normalized_constraints_from_info (ci, args, tmpl, diag);
diff --git a/gcc/cp/pt.c b/gcc/cp/pt.c
index 585d944542b..8ad91b37297 100644
--- a/gcc/cp/pt.c
+++ b/gcc/cp/pt.c
@@ -13391,7 +13391,7 @@ tsubst_aggr_type (tree t,
complain, in_decl);
if (argvec == error_mark_node)
r = error_mark_node;
- else if (cxx_dialect >= cxx20 && dependent_scope_p (context))
+ else if (cxx_dialect >= cxx17 && dependent_scope_p (context))
{
/* See maybe_dependent_member_ref. */
tree name = TYPE_IDENTIFIER (t);
@@ -16328,14 +16328,13 @@ tsubst_init (tree init, tree decl, tree args,
we are trying to refer to that member in a partial instantiation of C,
return a SCOPE_REF; otherwise, return NULL_TREE.
- This can happen when forming a C++20 alias template deduction guide, as in
- PR96199. */
+ This can happen when forming a C++17 deduction guide, as in PR96199. */
static tree
maybe_dependent_member_ref (tree t, tree args, tsubst_flags_t complain,
tree in_decl)
{
- if (cxx_dialect < cxx20)
+ if (cxx_dialect < cxx17)
return NULL_TREE;
tree ctx = context_for_name_lookup (t);
@@ -28370,6 +28369,16 @@ build_deduction_guide (tree type, tree ctor, tree
outer_args, tsubst_flags_t com
fargs = tsubst (fargs, tsubst_args, complain, ctor);
current_template_parms = save_parms;
}
+ else
+ {
+ /* Substitute in the same arguments to rewrite class members into
+references to members of an unknown specialization. */
+ cp_evaluated ev;
+ fparms = tsubst_arg_types (fparms, targs, NULL_TREE, complain, ctor);
+ fargs = tsubst (fargs, targs, complain, ctor);
+ if (ci)
+ ci = tsubst_constraint_info (ci, targs, complain, ctor);
+ }
--processing_template_decl;
if (!ok)
diff --git a/gcc/testsuite/g++.dg/cpp1z/class-deduction-spec1.C
b/gcc/testsuite/g++.dg/cpp1z/class-deduction-spec1.C
new file mode 100644
index 000..fcdf746134b
--- /dev/null
+++ b/gcc/testsuite/g++.dg/cpp1z/class-deduction-spec1.C
@@ -0,0 +1,38 @@
+// PR c++/96199
+// { dg-do compile { target c++17 } }
+
+template struct A1 { };
+template struct A2 { };
+template struct A3 { };
+
+int i;
+template struct B {
+ enum E { X };
+ B(A1, V) { }
+
+ constexpr static V& ir = i;
+ B(A2, V) { }
+
+ B(A3, V) { }
+};
+
+// template B(A1::X>,T) -> B;
+// template B(A2::ir>,T) -> B;
+// template B(A3::E>,T) -> B;
+
+int j;
+template <> struct B {
+ using V = int;
+
+ enum E { X = 1 };
+ B(A1, V) { }
+
+ constexpr static V& ir = j;
+ B(A2, V) {
[Bug c++/96199] [10/11 Regression] internal compiler error: in tsubst_copy with CTAD for alias templates
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96199 --- Comment #5 from CVS Commits --- The master branch has been updated by Jason Merrill : https://gcc.gnu.org/g:b871301f09be7061904dc87880919d30e6afef8f commit r11-2748-gb871301f09be7061904dc87880919d30e6afef8f Author: Jason Merrill Date: Fri Aug 14 18:01:27 2020 -0400 c++: Rewrite members for all deduction guides. [PR96199] After the last patch, it occurred to me that we could run into the specialization issue with non-alias deduction guides as well, so this patch extends the rewriting to C++17 mode. Doing this revealed that we weren't properly pushing into class scope for normalization. gcc/cp/ChangeLog: PR c++/96199 * pt.c (tsubst_aggr_type): Rewrite in C++17, too. (maybe_dependent_member_ref): Likewise. (build_deduction_guide): Re-substitute template parms. * cp-tree.h (struct push_nested_class_guard): New. * constraint.cc (get_normalized_constraints_from_decl): Use it. gcc/testsuite/ChangeLog: PR c++/96199 * g++.dg/cpp1z/class-deduction-spec1.C: New test.
[PATCH 1/2] c++: Handle enumerator in C++20 alias CTAD. [PR96199]
To form a deduction guide for an alias template, we substitute the template
arguments from the pattern into the deduction guide for the underlying
class. In the case of B(A1), that produces B(A1::X>) -> B.
But since an enumerator doesn't have its own template info, and B is a
dependent scope, trying to look up B::X fails and we crash. So we need
to produce a SCOPE_REF instead.
And trying to use the members of the template class is wrong for other
members, as well, as it gives a nonsensical result if the class is
specialized.
Tested x86_64-pc-linux-gnu, applying to trunk and 10.
gcc/cp/ChangeLog:
PR c++/96199
* pt.c (maybe_dependent_member_ref): New.
(tsubst_copy) [CONST_DECL]: Use it.
[VAR_DECL]: Likewise.
(tsubst_aggr_type): Handle nested type.
gcc/testsuite/ChangeLog:
PR c++/96199
* g++.dg/cpp2a/class-deduction-alias4.C: New test.
---
gcc/cp/pt.c | 43 ++
.../g++.dg/cpp2a/class-deduction-alias4.C | 44 +++
2 files changed, 87 insertions(+)
create mode 100644 gcc/testsuite/g++.dg/cpp2a/class-deduction-alias4.C
diff --git a/gcc/cp/pt.c b/gcc/cp/pt.c
index b80fe0a5cc5..585d944542b 100644
--- a/gcc/cp/pt.c
+++ b/gcc/cp/pt.c
@@ -13391,6 +13391,17 @@ tsubst_aggr_type (tree t,
complain, in_decl);
if (argvec == error_mark_node)
r = error_mark_node;
+ else if (cxx_dialect >= cxx20 && dependent_scope_p (context))
+ {
+ /* See maybe_dependent_member_ref. */
+ tree name = TYPE_IDENTIFIER (t);
+ tree fullname = name;
+ if (instantiates_primary_template_p (t))
+ fullname = build_nt (TEMPLATE_ID_EXPR, name,
+INNERMOST_TEMPLATE_ARGS (argvec));
+ return build_typename_type (context, name, fullname,
+ typename_type);
+ }
else
{
r = lookup_template_class (t, argvec, in_decl, context,
@@ -16313,6 +16324,32 @@ tsubst_init (tree init, tree decl, tree args,
return init;
}
+/* If T is a reference to a dependent member of the current instantiation C and
+ we are trying to refer to that member in a partial instantiation of C,
+ return a SCOPE_REF; otherwise, return NULL_TREE.
+
+ This can happen when forming a C++20 alias template deduction guide, as in
+ PR96199. */
+
+static tree
+maybe_dependent_member_ref (tree t, tree args, tsubst_flags_t complain,
+ tree in_decl)
+{
+ if (cxx_dialect < cxx20)
+return NULL_TREE;
+
+ tree ctx = context_for_name_lookup (t);
+ if (!CLASS_TYPE_P (ctx))
+return NULL_TREE;
+
+ ctx = tsubst (ctx, args, complain, in_decl);
+ if (dependent_scope_p (ctx))
+return build_qualified_name (NULL_TREE, ctx, DECL_NAME (t),
+/*template_p=*/false);
+
+ return NULL_TREE;
+}
+
/* Like tsubst, but deals with expressions. This function just replaces
template parms; to finish processing the resultant expression, use
tsubst_copy_and_build or tsubst_expr. */
@@ -16371,6 +16408,9 @@ tsubst_copy (tree t, tree args, tsubst_flags_t
complain, tree in_decl)
if (args == NULL_TREE)
return scalar_constant_value (t);
+ if (tree ref = maybe_dependent_member_ref (t, args, complain, in_decl))
+ return ref;
+
/* Unfortunately, we cannot just call lookup_name here.
Consider:
@@ -16421,6 +16461,9 @@ tsubst_copy (tree t, tree args, tsubst_flags_t
complain, tree in_decl)
return t;
case VAR_DECL:
+ if (tree ref = maybe_dependent_member_ref (t, args, complain, in_decl))
+ return ref;
+ gcc_fallthrough();
case FUNCTION_DECL:
if (DECL_LANG_SPECIFIC (t) && DECL_TEMPLATE_INFO (t))
r = tsubst (t, args, complain, in_decl);
diff --git a/gcc/testsuite/g++.dg/cpp2a/class-deduction-alias4.C
b/gcc/testsuite/g++.dg/cpp2a/class-deduction-alias4.C
new file mode 100644
index 000..f2c3ffda85a
--- /dev/null
+++ b/gcc/testsuite/g++.dg/cpp2a/class-deduction-alias4.C
@@ -0,0 +1,44 @@
+// PR c++/96199
+// { dg-do compile { target c++2a } }
+
+template struct A1 { };
+template struct A2 { };
+template struct A3 { };
+
+int i;
+template struct B {
+ enum E { X };
+ B(A1, V) { }
+
+ constexpr static V& ir = i;
+ B(A2, V) { }
+
+ B(A3, V);
+};
+
+// template B(A1::X>,T) -> B;
+// template B(A2::ir>,T) -> B;
+// template B(A3::E>,T) -> B;
+
+template using U = B;
+
+// template B(A1::X>,T) -> B;
+// template B(A2::ir>,T) -> B;
+// template B(A3::E>,T) -> B;
+
+int j;
+template <> struct B {
+ using V = int;
+
+ enum E { X = 1 };
+ B(A1, V) { }
+
+ constexpr static V& ir = j;
+ B(A2, V) { }
+
+ B(A3, V);
+};
+
+U u1 { A1<1>(), 42 };
+U u2 { A2(), 42 };
+U u3 { A3::E>(), 42 };
base-commit: 3c04bd60e56da399a441f73ebb687b5039b9cf3f
[Bug c++/93028] internal compiler error: in write_type, at cp/mangle.c:2073
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93028 Marek Polacek changed: What|Removed |Added Resolution|--- |DUPLICATE Status|WAITING |RESOLVED CC||mpolacek at gcc dot gnu.org --- Comment #8 from Marek Polacek --- The write_type ICE is now tracked elsewhere. *** This bug has been marked as a duplicate of bug 96690 ***
[Bug c++/96690] [10/11 Regression] ICE in write_type since r10-6087
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96690 Marek Polacek changed: What|Removed |Added CC||itchka at compuserve dot com --- Comment #3 from Marek Polacek --- *** Bug 93028 has been marked as a duplicate of this bug. ***
[Bug c++/96690] [10/11 Regression] ICE in write_type since r10-6087
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96690 --- Comment #2 from Jakub Jelinek --- Maybe related to or same as PR93028, but that one is missing a test, so hard to say.
[Bug c++/96690] [10/11 Regression] ICE in write_type since r10-6087
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96690 Jakub Jelinek changed: What|Removed |Added Status|UNCONFIRMED |NEW Target Milestone|--- |10.3 Last reconfirmed||2020-08-18 CC||hubicka at gcc dot gnu.org, ||rguenth at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #1 from Jakub Jelinek --- The problem is that free_lang_data marks the const qualified int type, but does not mark the non-qualified int type and we then later try to mangle something and ICE during the mangling, where mangler asserts that TYPE_MAIN_VARIANT of the qualified types it is given are non-qualified (in particular different from the qualified type).
[Bug c++/77841] a new expression of a char array cannot be initialized by a string literal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77841
--- Comment #3 from Marek Polacek ---
The problem is probably that we're not doing the {"str_cst"} -> "str_cst"
unwrapping that reshape_init / cp_complete_array_type does.
[Bug c++/77841] a new expression of a char array cannot be initialized by a string literal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77841 Marek Polacek changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |mpolacek at gcc dot gnu.org
[Bug c++/96687] new char[4]{"foo"} doesn't work
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96687 Marek Polacek changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |DUPLICATE --- Comment #2 from Marek Polacek --- Ah, I *knew* there would be an existing report already, but didn't find it. *** This bug has been marked as a duplicate of bug 77841 ***
[Bug c++/77841] a new expression of a char array cannot be initialized by a string literal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77841 Marek Polacek changed: What|Removed |Added CC||mpolacek at gcc dot gnu.org --- Comment #2 from Marek Polacek --- *** Bug 96687 has been marked as a duplicate of this bug. ***
[Bug fortran/96686] MIN/MAX should reject character arguments of different kind rather than ICE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96686 anlauf at gcc dot gnu.org changed: What|Removed |Added Resolution|--- |FIXED Status|NEW |RESOLVED --- Comment #3 from anlauf at gcc dot gnu.org --- Fixed by r11-2746-g3c04bd60e56da399a441f73ebb687b5039b9cf3f (see PR96613 comment#9).
[Bug fortran/96613] SIGFPE on min1() with -ffpe-trap=invalid switch
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96613 anlauf at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #10 from anlauf at gcc dot gnu.org --- Fixed on master for GCC-11. Thanks for the report!
[PATCH, committed] PR fortran/96613,96686 - Fix type/kind issues, temporaries evaluating MIN/MAX
There was another issue (PR96686) with MIN/MAX for character arguments of
different kind.
Character arguments to MIN/MAX are a Fortran 2003 feature, so there is no
real reason to have a new GNU extension, and no related legacy code.
Instead of ICEing, we now unconditionally generate an error
This was confirmed in PR96686 by Steve, who also approved the patch for PR96613.
Both patches were combined, regtested on x86_64-pc-linux-gnu, and committed.
Thanks,
Harald
Full commit message:
PR fortran/96613,96686 - Fix type/kind issues, temporaries evaluating MIN/MAX
When evaluating functions of the MIN/MAX variety inline, use a temporary
of appropriate type and kind, and convert to the result type at the end.
In the case of allowing for the GNU extensions to MIN/MAX, derive the
result kind consistently during simplificaton.
Furthermore, the Fortran standard requires type and kind of arguments to
the MIN/MAX intrinsics to all have the same type and kind. While a GNU
extension accepts kind differences for integer and real arguments which
seems to have been used in legacy code, there is no reason to allow
different character kinds. We now reject the latter unconditionally.
gcc/fortran/ChangeLog:
* check.c (check_rest): Reject MIN/MAX character arguments of
different kind.
* simplify.c (min_max_choose): The simplification result shall
have the highest kind value of the arguments.
* trans-intrinsic.c (gfc_conv_intrinsic_minmax): Choose type and
kind of intermediate by looking at all arguments, not the result.
gcc/testsuite/ChangeLog:
* gfortran.dg/minmax_char_3.f90: New test.
* gfortran.dg/min_max_kind.f90: New test.
* gfortran.dg/pr96613.f90: New test.
diff --git a/gcc/fortran/check.c b/gcc/fortran/check.c
index 74e5e448760..65b46cd3f85 100644
--- a/gcc/fortran/check.c
+++ b/gcc/fortran/check.c
@@ -3693,6 +3693,11 @@ check_rest (bt type, int kind, gfc_actual_arglist *arglist)
{
if (x->ts.type == type)
{
+ if (x->ts.type == BT_CHARACTER)
+ {
+ gfc_error ("Different character kinds at %L", >where);
+ return false;
+ }
if (!gfc_notify_std (GFC_STD_GNU, "Different type "
"kinds at %L", >where))
return false;
diff --git a/gcc/fortran/simplify.c b/gcc/fortran/simplify.c
index eb8b2afeb29..074b50c2e68 100644
--- a/gcc/fortran/simplify.c
+++ b/gcc/fortran/simplify.c
@@ -4924,6 +4924,8 @@ min_max_choose (gfc_expr *arg, gfc_expr *extremum, int sign, bool back_val)
switch (arg->ts.type)
{
case BT_INTEGER:
+ if (extremum->ts.kind < arg->ts.kind)
+ extremum->ts.kind = arg->ts.kind;
ret = mpz_cmp (arg->value.integer,
extremum->value.integer) * sign;
if (ret > 0)
@@ -4931,6 +4933,8 @@ min_max_choose (gfc_expr *arg, gfc_expr *extremum, int sign, bool back_val)
break;
case BT_REAL:
+ if (extremum->ts.kind < arg->ts.kind)
+ extremum->ts.kind = arg->ts.kind;
if (mpfr_nan_p (extremum->value.real))
{
ret = 1;
diff --git a/gcc/fortran/trans-intrinsic.c b/gcc/fortran/trans-intrinsic.c
index fd8809902b7..2483f016d8e 100644
--- a/gcc/fortran/trans-intrinsic.c
+++ b/gcc/fortran/trans-intrinsic.c
@@ -4073,6 +4073,7 @@ gfc_conv_intrinsic_minmax (gfc_se * se, gfc_expr * expr, enum tree_code op)
tree val;
tree *args;
tree type;
+ tree argtype;
gfc_actual_arglist *argexpr;
unsigned int i, nargs;
@@ -4082,16 +4083,24 @@ gfc_conv_intrinsic_minmax (gfc_se * se, gfc_expr * expr, enum tree_code op)
gfc_conv_intrinsic_function_args (se, expr, args, nargs);
type = gfc_typenode_for_spec (>ts);
- argexpr = expr->value.function.actual;
- if (TREE_TYPE (args[0]) != type)
-args[0] = convert (type, args[0]);
/* Only evaluate the argument once. */
if (!VAR_P (args[0]) && !TREE_CONSTANT (args[0]))
args[0] = gfc_evaluate_now (args[0], >pre);
- mvar = gfc_create_var (type, "M");
- gfc_add_modify (>pre, mvar, args[0]);
+ /* Determine suitable type of temporary, as a GNU extension allows
+ different argument kinds. */
+ argtype = TREE_TYPE (args[0]);
+ argexpr = expr->value.function.actual;
+ for (i = 1, argexpr = argexpr->next; i < nargs; i++, argexpr = argexpr->next)
+{
+ tree tmptype = TREE_TYPE (args[i]);
+ if (TYPE_PRECISION (tmptype) > TYPE_PRECISION (argtype))
+ argtype = tmptype;
+}
+ mvar = gfc_create_var (argtype, "M");
+ gfc_add_modify (>pre, mvar, convert (argtype, args[0]));
+ argexpr = expr->value.function.actual;
for (i = 1, argexpr = argexpr->next; i < nargs; i++, argexpr = argexpr->next)
{
tree cond = NULL_TREE;
@@ -4119,8 +4128,8 @@ gfc_conv_intrinsic_minmax (gfc_se * se, gfc_expr * expr, enum tree_code op)
Also, there is no consensus among other tested compilers. In
short, it's a mess. So lets just do whatever is fastest. */
tree_code code = op == GT_EXPR ? MAX_EXPR : MIN_EXPR;
- calc = fold_build2_loc (input_location, code, type,
- convert (type,
[Bug c++/96687] new char[4]{"foo"} doesn't work
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96687 --- Comment #1 from Jonathan Wakely --- This is PR 77841
[Bug c++/96690] New: [10/11 Regression] ICE in write_type since r10-6087
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96690
Bug ID: 96690
Summary: [10/11 Regression] ICE in write_type since r10-6087
Product: gcc
Version: 10.2.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: jakub at gcc dot gnu.org
Target Milestone: ---
Since r10-6087-g991b91497fd50f6e70e5f2c0cfa96e1b74157bdc
the following testcase (distilled from firefox) ICEs with -flto
-flto-fat-objects -g:
struct A { A (int); };
template class B { T f; };
unsigned char *foo (int *, bool *, const int &);
template struct C {};
struct D { B > d; };
struct E { D e; };
struct F {};
struct G { static int bar (A, F, E, int); };
void
baz ()
{
F f;
G::bar (0, f, E (), 0);
}
[Bug c++/96689] New: Segmentation fault when defaulting operator<=> on enum er enum class
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96689
Bug ID: 96689
Summary: Segmentation fault when defaulting operator<=> on enum
er enum class
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: breyer.marcel at web dot de
Target Milestone: ---
Defaulting the default comparison operator (operator<=>) on an enum or enum
class causes a segmentation fault.
#include
enum class test {
one,
two,
three
};
std::strong_ordering operator<=>(const test, const test) = default;
Causes on GCC trunk (https://godbolt.org/z/KzxPq3):
:9:60: internal compiler error: Segmentation fault
9 | std::strong_ordering operator<=>(const test, const test) = default;
|^~~
Please submit a full bug report,
with preprocessed source if appropriate.
[Bug fortran/96613] SIGFPE on min1() with -ffpe-trap=invalid switch
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96613 --- Comment #9 from CVS Commits --- The master branch has been updated by Harald Anlauf : https://gcc.gnu.org/g:3c04bd60e56da399a441f73ebb687b5039b9cf3f commit r11-2746-g3c04bd60e56da399a441f73ebb687b5039b9cf3f Author: Harald Anlauf Date: Tue Aug 18 21:48:56 2020 +0200 PR fortran/96613,96686 - Fix type/kind issues, temporaries evaluating MIN/MAX When evaluating functions of the MIN/MAX variety inline, use a temporary of appropriate type and kind, and convert to the result type at the end. In the case of allowing for the GNU extensions to MIN/MAX, derive the result kind consistently during simplificaton. Furthermore, the Fortran standard requires type and kind of arguments to the MIN/MAX intrinsics to all have the same type and kind. While a GNU extension accepts kind differences for integer and real arguments which seems to have been used in legacy code, there is no reason to allow different character kinds. We now reject the latter unconditionally. gcc/fortran/ChangeLog: * check.c (check_rest): Reject MIN/MAX character arguments of different kind. * simplify.c (min_max_choose): The simplification result shall have the highest kind value of the arguments. * trans-intrinsic.c (gfc_conv_intrinsic_minmax): Choose type and kind of intermediate by looking at all arguments, not the result. gcc/testsuite/ChangeLog: * gfortran.dg/minmax_char_3.f90: New test. * gfortran.dg/min_max_kind.f90: New test. * gfortran.dg/pr96613.f90: New test.
[Bug fortran/96686] MIN/MAX should reject character arguments of different kind rather than ICE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96686
--- Comment #2 from anlauf at gcc dot gnu.org ---
(In reply to kargl from comment #1)
> Yep, I agree that this should simply be rejected. I looked at your other
> patch for min/max, and think it can be committed. If you want to update
> that patch to include the fix for this PR consider it pre-approved (provided
> regression testing passes).
The addition:
diff --git a/gcc/fortran/check.c b/gcc/fortran/check.c
index 74e5e448760..65b46cd3f85 100644
--- a/gcc/fortran/check.c
+++ b/gcc/fortran/check.c
@@ -3693,6 +3693,11 @@ check_rest (bt type, int kind, gfc_actual_arglist
*arglist)
{
if (x->ts.type == type)
{
+ if (x->ts.type == BT_CHARACTER)
+ {
+ gfc_error ("Different character kinds at %L", >where);
+ return false;
+ }
if (!gfc_notify_std (GFC_STD_GNU, "Different type "
"kinds at %L", >where))
return false;
does the job and regtests fine.
Will commit together with the other PR, and with a new testcase for this one.
[Bug tree-optimization/96688] New: Failure to optimize shift-right+not of constant to avoid not
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96688
Bug ID: 96688
Summary: Failure to optimize shift-right+not of constant to
avoid not
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: gabravier at gmail dot com
Target Milestone: ---
int f(int x)
{
return ~(123 >> x);
}
This return in this code can be optimized to `return ~123 >> x;`, and the same
optimization is possible where 123 is replaced by essentially any constant.
This transformation is done by LLVM, but not by GCC.
[committed] [OG10] Backport OpenMP-related patches
Hello
I have now backported a number of OpenMP-related patches from master to
devel/omp/gcc-10. These are:
- Fortran: Fix character-kind=4 substring resolution (PR95837) (commit
f48bffe70cba310461ec19ffcd07c573a6b86575)
- libgomp.fortran/struct-elem-map-1.f90: Add char kind=4 tests (commit
e0685fadb6aa7c9cc895bc14cbbe2b9026fa3a94)
- OpenMP: Fixes for omp critical + hint (commit
c7c24828cfa4983ebc6744be3f913d0da6ff7163)
- critical-hint-*.{c,f90}: Move from gcc/testsuite to libgomp/testsuite (commit
ade6e7204ce4d179cd9fa4637ddee85ba1fa12d9)
- openmp: Handle clauses with gimple sequences in convert_nonlocal_omp_clauses
properly (commit 676b5525e8333005bdc1c596ed086f1da27a450f)
- Fortran/OpenMP: Fix detecting not perfectly nested loops (commit
57dd9f3bfca8bb752c630431dc033c761e2ad382)
Kwok
From 1e3e1fb54ace591926e80fccbf39d518a9dd7ca6 Mon Sep 17 00:00:00 2001
From: Kwok Cheung Yeung
Date: Tue, 18 Aug 2020 04:35:43 -0700
Subject: [PATCH 1/6] Fortran: Fix character-kind=4 substring resolution
(PR95837)
This is a backport from master of commit
f48bffe70cba310461ec19ffcd07c573a6b86575.
Testing showed that it is always set and its value matches
always ts->kind (if available) or otherwise, if it is a variable,
the sym->ts.kind.
gcc/fortran/ChangeLog:
PR fortran/95837
* resolve.c (gfc_resolve_substring_charlen): Remove
bogus ts.kind setting for the expression.
gcc/testsuite/ChangeLog:
PR fortran/95837
* gfortran.dg/char4-subscript.f90: New test.
---
gcc/fortran/ChangeLog.omp | 9
gcc/fortran/resolve.c | 3 ---
gcc/testsuite/ChangeLog.omp | 8 +++
gcc/testsuite/gfortran.dg/char4-subscript.f90 | 30 +++
4 files changed, 47 insertions(+), 3 deletions(-)
create mode 100644 gcc/testsuite/gfortran.dg/char4-subscript.f90
diff --git a/gcc/fortran/ChangeLog.omp b/gcc/fortran/ChangeLog.omp
index 00c6be0..a6b7452 100644
--- a/gcc/fortran/ChangeLog.omp
+++ b/gcc/fortran/ChangeLog.omp
@@ -1,3 +1,12 @@
+2020-08-18 Kwok Cheung Yeung
+
+ Backport from mainline
+ 2020-06-25 Tobias Burnus
+
+ PR fortran/95837
+ * resolve.c (gfc_resolve_substring_charlen): Remove
+ bogus ts.kind setting for the expression.
+
2020-08-14 Kwok Cheung Yeung
Backport from mainline
diff --git a/gcc/fortran/resolve.c b/gcc/fortran/resolve.c
index 3166cc3..c05be55 100644
--- a/gcc/fortran/resolve.c
+++ b/gcc/fortran/resolve.c
@@ -5140,9 +5140,6 @@ gfc_resolve_substring_charlen (gfc_expr *e)
return;
}
- e->ts.type = BT_CHARACTER;
- e->ts.kind = gfc_default_character_kind;
-
if (!e->ts.u.cl)
e->ts.u.cl = gfc_new_charlen (gfc_current_ns, NULL);
diff --git a/gcc/testsuite/ChangeLog.omp b/gcc/testsuite/ChangeLog.omp
index 8f652f4..e9d589f 100644
--- a/gcc/testsuite/ChangeLog.omp
+++ b/gcc/testsuite/ChangeLog.omp
@@ -1,3 +1,11 @@
+2020-08-18 Kwok Cheung Yeung
+
+ Backport from mainline
+ 2020-06-25 Tobias Burnus
+
+ PR fortran/95837
+ * gfortran.dg/char4-subscript.f90: New test.
+
2020-08-14 Kwok Cheung Yeung
Backport from mainline
diff --git a/gcc/testsuite/gfortran.dg/char4-subscript.f90
b/gcc/testsuite/gfortran.dg/char4-subscript.f90
new file mode 100644
index 000..f1f915c
--- /dev/null
+++ b/gcc/testsuite/gfortran.dg/char4-subscript.f90
@@ -0,0 +1,30 @@
+! { dg-do run }
+! { dg-additional-options "-fdump-tree-original" }
+!
+! PR fortran/95837
+!
+type t
+ character(len=:, kind=4), pointer :: str2
+end type t
+type(t) :: var
+
+allocate(character(len=5, kind=4) :: var%str2)
+
+var%str2(1:1) = 4_"d"
+var%str2(2:3) = 4_"ef"
+var%str2(4:4) = achar(int(Z'1F600'), kind=4)
+var%str2(5:5) = achar(int(Z'1F608'), kind=4)
+
+if (var%str2(1:3) /= 4_"def") stop 1
+if (ichar(var%str2(4:4)) /= int(Z'1F600')) stop 2
+if (ichar(var%str2(5:5)) /= int(Z'1F608')) stop 2
+
+deallocate(var%str2)
+end
+
+! Note: the last '\x00' is regarded as string terminator, hence, the tailing
\0 byte is not in the dump
+
+! { dg-final { scan-tree-dump " \\(\\*var\\.str2\\)\\\[1\\\]{lb: 1 sz: 4} =
.dx00x00.\\\[1\\\]{lb: 1 sz: 4};" "original" } }
+! { dg-final { scan-tree-dump " __builtin_memmove \\(\\(void \\*\\)
&\\(\\*var.str2\\)\\\[2\\\]{lb: 1 sz: 4}, \\(void \\*\\)
&.ex00x00x00fx00x00.\\\[1\\\]{lb: 1 sz: 4}, 8\\);"
"original" } }
+! { dg-final { scan-tree-dump " \\(\\*var.str2\\)\\\[4\\\]{lb: 1 sz: 4} =
.x00xf6x01.\\\[1\\\]{lb: 1 sz: 4};" "original" } }
+! { dg-final { scan-tree-dump " \\(\\*var.str2\\)\\\[5\\\]{lb: 1 sz: 4} =
.bxf6x01.\\\[1\\\]{lb: 1 sz: 4};" "original" } }
--
2.8.1
From 4120e9973c6989ae7787776371aa1b3aff856d03 Mon Sep 17 00:00:00 2001
From: Kwok Cheung Yeung
Date: Tue, 18 Aug 2020 04:39:49 -0700
Subject: [PATCH 2/6] libgomp.fortran/struct-elem-map-1.f90: Add char kind=4
tests
This is a backport from master of commit
[committed] rs6000: unaligned VSX in memcpy/memmove expansion
I've modified slightly per Will & Segher's comments, re-regstrapped and
posting what I've actually committed.
Aaron
This patch adds a few new instructions to inline expansion of
memcpy/memmove. Generation of all these are controlled by
the option -mblock-ops-unaligned-vsx which is set on by default if the
target has TARGET_EFFICIENT_UNALIGNED_VSX.
* unaligned vsx load/store (V2DImode)
* unaligned vsx pair load/store (POImode) which is also controlled
by -mblock-ops-vector-pair in case it is not wanted at some point.
The default for -mblock-ops-vector-pair is for it to be on if the
target has TARGET_MMA and TARGET_EFFICIENT_UNALIGNED_VSX. This is
redundant, but nice for the future to clearly specify what is
required.
* unaligned vsx lxvl/stxvl but generally only to do the remainder
of a copy/move we stated with some vsx loads/stores, and also prefer
to use lb/lh/lw/ld if the remainder is 1/2/4/8 bytes.
Testing of this is actually accomplished by gcc.dg/memcmp-1.c which does
two memcpy() for each memcmp(). If the memcpy() calls don't do the right
thing then the memcmp() will fail unexpectedly.
gcc/ChangeLog:
* config/rs6000/rs6000-string.c (gen_lxvl_stxvl_move):
Helper function.
(expand_block_move): Add lxvl/stxvl, vector pair, and
unaligned VSX.
* config/rs6000/rs6000.c (rs6000_option_override_internal):
Default value for -mblock-ops-vector-pair.
* config/rs6000/rs6000.opt: Add -mblock-ops-vector-pair.
---
gcc/config/rs6000/rs6000-string.c | 103 ++
gcc/config/rs6000/rs6000.c| 14 +++-
gcc/config/rs6000/rs6000.opt | 4 ++
3 files changed, 105 insertions(+), 16 deletions(-)
diff --git a/gcc/config/rs6000/rs6000-string.c
b/gcc/config/rs6000/rs6000-string.c
index c35d93180ca..82cc24ecdda 100644
--- a/gcc/config/rs6000/rs6000-string.c
+++ b/gcc/config/rs6000/rs6000-string.c
@@ -2708,6 +2708,32 @@ gen_lvx_v4si_move (rtx dest, rtx src)
return gen_altivec_lvx_v4si_internal (dest, src);
}
+static rtx
+gen_lxvl_stxvl_move (rtx dest, rtx src, int length)
+{
+ gcc_assert (MEM_P (dest) ^ MEM_P (src));
+ gcc_assert (GET_MODE (dest) == V16QImode && GET_MODE (src) == V16QImode);
+ gcc_assert (length <= 16);
+
+ bool is_store = MEM_P (dest);
+ rtx addr;
+
+ /* If the address form is not a simple register, make it so. */
+ if (is_store)
+addr = XEXP (dest, 0);
+ else
+addr = XEXP (src, 0);
+
+ if (!REG_P (addr))
+addr = force_reg (Pmode, addr);
+
+ rtx len = force_reg (DImode, gen_int_mode (length, DImode));
+ if (is_store)
+return gen_stxvl (src, addr, len);
+ else
+return gen_lxvl (dest, addr, len);
+}
+
/* Expand a block move operation, and return 1 if successful. Return 0
if we should let the compiler generate normal code.
@@ -2750,18 +2776,56 @@ expand_block_move (rtx operands[], bool might_overlap)
if (bytes > rs6000_block_move_inline_limit)
return 0;
+ int orig_bytes = bytes;
for (offset = 0; bytes > 0; offset += move_bytes, bytes -= move_bytes)
{
union {
- rtx (*movmemsi) (rtx, rtx, rtx, rtx);
rtx (*mov) (rtx, rtx);
+ rtx (*movlen) (rtx, rtx, int);
} gen_func;
machine_mode mode = BLKmode;
rtx src, dest;
-
- /* Altivec first, since it will be faster than a string move
-when it applies, and usually not significantly larger. */
- if (TARGET_ALTIVEC && bytes >= 16 && align >= 128)
+ bool move_with_length = false;
+
+ /* Use POImode for paired vsx load/store. Use V2DI for single
+unaligned vsx load/store, for consistency with what other
+expansions (compare) already do, and so we can use lxvd2x on
+p8. Order is VSX pair unaligned, VSX unaligned, Altivec, VSX
+with length < 16 (if allowed), then gpr load/store. */
+
+ if (TARGET_MMA && TARGET_BLOCK_OPS_UNALIGNED_VSX
+ && TARGET_BLOCK_OPS_VECTOR_PAIR
+ && bytes >= 32
+ && (align >= 256 || !STRICT_ALIGNMENT))
+ {
+ move_bytes = 32;
+ mode = POImode;
+ gen_func.mov = gen_movpoi;
+ }
+ else if (TARGET_POWERPC64 && TARGET_BLOCK_OPS_UNALIGNED_VSX
+ && VECTOR_MEM_VSX_P (V2DImode)
+ && bytes >= 16 && (align >= 128 || !STRICT_ALIGNMENT))
+ {
+ move_bytes = 16;
+ mode = V2DImode;
+ gen_func.mov = gen_vsx_movv2di_64bit;
+ }
+ else if (TARGET_BLOCK_OPS_UNALIGNED_VSX
+ && TARGET_POWER10 && bytes < 16
+ && orig_bytes > 16
+ && !(bytes == 1 || bytes == 2
+ || bytes == 4 || bytes == 8)
+ && (align >= 128 || !STRICT_ALIGNMENT))
+ {
+ /* Only use lxvl/stxvl if it could replace multiple ordinary
+loads+stores. Also don't use it unless we likely already
+did one vsx copy so we aren't mixing gpr and vsx. */
+ move_bytes = bytes;
+
Re: [RFC PATCH v1 1/1] PPC64: Implement POWER Architecture Vector Function ABI.
‐‐‐ Original Message ‐‐‐ On Monday, August 17, 2020 5:28 PM, Segher Boessenkool wrote: > On Mon, Aug 17, 2020 at 05:44:46PM +, GT wrote: > > > > This is about the Power binding to some OpenMP API, right? It has > > > nothing to do with "vector" or "ABI" -- we have vectors already, and > > > we have ABIs already, more than enough of each. > > > It is very very VERY hard to review this without being told the proper > > > setting here. > > > > What this is about: > > David Edelsohn wanted to have new library functions, one for each of these > > 6 single-precision functions: > > sinf, cosf, sincosf, expf, logf, powf; and these 6 double-precision > > functions: > > sin, cos, sincos, exp, log, and pow. > > For the single-precision functions, the corresponding new functions would > > compute 4 results > > simulatneously. For the double-precision functions, the new ones would > > compute 2 results > > simultaneously. > > x86_64 has already done something very similar so I thought I would adapt > > as much of their > > documentation and implementation as I could for PPC64. > > Let's start with that. Comments so far? > > That sounds like libmvec? > > I still don't know what this is. > Yes, it is libmvec. Now look at what GCC does to the code in Examples 1 and 2 at this link: https://sourceware.org/glibc/wiki/libmvec x86_64 added functionality to GCC so such code uses the new functions without the user having to re-write the loops and explicitly call the new functions. We are aiming to provide that same capability for PPC64 in GCC. Bert.
[Bug tree-optimization/96665] [11 regression] memcmp of a constant string not folded
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96665 Martin Sebor changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED Summary|[11 regression] new FAILs |[11 regression] memcmp of a |for gcc.dg/strlenopt-55.c |constant string not folded |after r11-2709 | Target Milestone|--- |11.0 --- Comment #4 from Martin Sebor --- Fixed in r11-2743.
[Bug tree-optimization/78257] missing memcmp optimization with constant arrays
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78257 --- Comment #12 from CVS Commits --- The master branch has been updated by Martin Sebor : https://gcc.gnu.org/g:d367f5fcb579d21c3093cf5c464f5787fe584a1d commit r11-2743-gd367f5fcb579d21c3093cf5c464f5787fe584a1d Author: Martin Sebor Date: Tue Aug 18 12:57:18 2020 -0600 PR middle-end/96665 - memcmp of a constant string not folded Related: PR middle-end/78257 - missing memcmp optimization with constant arrays gcc/ChangeLog: PR middle-end/96665 PR middle-end/78257 * expr.c (convert_to_bytes): Replace statically allocated buffer with a dynamically allocated one of sufficient size. gcc/testsuite/ChangeLog: PR middle-end/96665 PR middle-end/78257 * gcc.dg/memcmp-5.c: New test.
[Bug tree-optimization/96665] [11 regression] new FAILs for gcc.dg/strlenopt-55.c after r11-2709
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96665 --- Comment #3 from CVS Commits --- The master branch has been updated by Martin Sebor : https://gcc.gnu.org/g:d367f5fcb579d21c3093cf5c464f5787fe584a1d commit r11-2743-gd367f5fcb579d21c3093cf5c464f5787fe584a1d Author: Martin Sebor Date: Tue Aug 18 12:57:18 2020 -0600 PR middle-end/96665 - memcmp of a constant string not folded Related: PR middle-end/78257 - missing memcmp optimization with constant arrays gcc/ChangeLog: PR middle-end/96665 PR middle-end/78257 * expr.c (convert_to_bytes): Replace statically allocated buffer with a dynamically allocated one of sufficient size. gcc/testsuite/ChangeLog: PR middle-end/96665 PR middle-end/78257 * gcc.dg/memcmp-5.c: New test.
[committed] use byte_representation instead of string_constant (PR 96670)
The recent enhancement to memchr/memcmp folding introduced two bugs
(that I know of). The attached patch fixes the one where a call to
the string_constant function that would previously be guaranteed to
succeed now fails as a result of the function only handling strings
and not other types. The unexpected failure triggers an ICE down
the line. I have committed the bootstrapped/regtested one-line
patch in r11-2742.
Martin
PR tree-optimization/96670 - ICE on memchr with an empty initializer
gcc/ChangeLog:
PR tree-optimization/96670
PR middle-end/78257
* gimple-fold.c (gimple_fold_builtin_memchr): Call byte_representation
to get it, not string_constant.
gcc/testsuite/ChangeLog:
PR tree-optimization/96670
* gcc.dg/memchr-2.c: New test.
* gcc.dg/memcmp-6.c: New test.
diff --git a/gcc/gimple-fold.c b/gcc/gimple-fold.c
index db56cb6aa47..dcc1b56a273 100644
--- a/gcc/gimple-fold.c
+++ b/gcc/gimple-fold.c
@@ -2670,7 +2670,7 @@ gimple_fold_builtin_memchr (gimple_stmt_iterator *gsi)
if (r == NULL)
{
tree mem_size, offset_node;
- string_constant (arg1, _node, _size, NULL);
+ byte_representation (arg1, _node, _size, NULL);
unsigned HOST_WIDE_INT offset = (offset_node == NULL_TREE)
? 0 : tree_to_uhwi (offset_node);
/* MEM_SIZE is the size of the array the string literal
diff --git a/gcc/testsuite/gcc.dg/memchr-2.c b/gcc/testsuite/gcc.dg/memchr-2.c
new file mode 100644
index 000..61357f96d12
--- /dev/null
+++ b/gcc/testsuite/gcc.dg/memchr-2.c
@@ -0,0 +1,41 @@
+/* PR tree-optimization/96670 - ICE on memchr with an empty initializer
+ { dg-do compile }
+ { dg-options "-O -Wall -fdump-tree-optimized" } */
+
+struct {
+ int i, j;
+} const s = { };
+
+void memchr_success_unused (void)
+{
+ int n = (char *) - (char *)
+ char *p = (char *)
+ __builtin_memchr (p, '\0', n);
+}
+
+void memchr_success_used (void)
+{
+ int n = (char *) - (char *)
+ char *p = (char *)
+ if ( != __builtin_memchr (p, '\0', n))
+__builtin_abort ();
+}
+
+void memchr_fail_unused (void)
+{
+ int n = (char *) - (char *)
+ char *p = (char *)
+ __builtin_memchr (p, '\5', n);
+}
+
+void memchr_fail_used (void)
+{
+ int n = (char *) - (char *)
+ char *p = (char *)
+ if (__builtin_memchr (p, '\5', n))
+__builtin_abort ();
+}
+
+/* { dg-prune-output "\\\[-Wunused-value" }
+ { dg-final { scan-tree-dump-not "abort" "optimized" } }
+ { dg-final { scan-tree-dump-not "memcmp \\(" "optimized" } } */
diff --git a/gcc/testsuite/gcc.dg/memcmp-6.c b/gcc/testsuite/gcc.dg/memcmp-6.c
new file mode 100644
index 000..d57352616cf
--- /dev/null
+++ b/gcc/testsuite/gcc.dg/memcmp-6.c
@@ -0,0 +1,47 @@
+/* PR tree-optimization/96670 - ICE on memchr with an empty initializer
+ { dg-do compile }
+ { dg-options "-O -Wall -fdump-tree-optimized" } */
+
+struct {
+ int i, j;
+} const s = { };
+
+const char a[sizeof s] = { };
+
+void memcmp_success_unused (void)
+{
+ int n = (char *) - (char *)
+ char *p = (char *)
+ __builtin_memcmp (p, a, n);
+ __builtin_memcmp (a, p, n);
+}
+
+void memcmp_success_used (void)
+{
+ int n = (char *) - (char *)
+ char *p = (char *)
+ if (__builtin_memcmp (p, a, n)
+ || __builtin_memcmp (a, p, n))
+__builtin_abort ();
+}
+
+void memcmp_fail_unused (void)
+{
+ int n = (char *) - (char *)
+ char *p = (char *)
+ __builtin_memcmp (p, a, n);
+ __builtin_memcmp (a, p, n);
+}
+
+void memcmp_fail_used (void)
+{
+ int n = (char *) - (char *)
+ char *p = (char *)
+ if (__builtin_memcmp (p, a, n)
+ || __builtin_memcmp (a, p, n))
+__builtin_abort ();
+}
+
+/* { dg-prune-output "\\\[-Wunused-value" }
+ { dg-final { scan-tree-dump-not "abort" "optimized" } }
+ { dg-final { scan-tree-dump-not "memcmp \\\(" "optimized" } } */
[Bug tree-optimization/96670] [11 Regression] ICE in tree_to_uhwi, at tree.c:7361 since r11-2709-g866626efd749ed3e
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96670 Martin Sebor changed: What|Removed |Added Status|ASSIGNED|RESOLVED Target Milestone|--- |11.0 Resolution|--- |FIXED --- Comment #3 from Martin Sebor --- Fixed in r11-2742.
[Bug tree-optimization/96670] [11 Regression] ICE in tree_to_uhwi, at tree.c:7361 since r11-2709-g866626efd749ed3e
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96670 Martin Sebor changed: What|Removed |Added Ever confirmed|0 |1 Assignee|unassigned at gcc dot gnu.org |msebor at gcc dot gnu.org Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2020-08-18 --- Comment #2 from Martin Sebor --- Confirmed. Reproducible with just -O alone.
[Bug tree-optimization/78257] missing memcmp optimization with constant arrays
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78257 --- Comment #11 from CVS Commits --- The master branch has been updated by Martin Sebor : https://gcc.gnu.org/g:bb04901d14f7749eb949092fd3dfcb6ca1958701 commit r11-2742-gbb04901d14f7749eb949092fd3dfcb6ca1958701 Author: Martin Sebor Date: Tue Aug 18 12:49:35 2020 -0600 Fix PR tree-optimization/96670 - ICE on memchr with an empty initializer. gcc/ChangeLog: PR tree-optimization/96670 PR middle-end/78257 * gimple-fold.c (gimple_fold_builtin_memchr): Call byte_representation to get it, not string_constant. gcc/testsuite/ChangeLog: PR tree-optimization/96670 * gcc.dg/memchr-2.c: New test. * gcc.dg/memcmp-6.c: New test.
[Bug tree-optimization/96670] [11 Regression] ICE in tree_to_uhwi, at tree.c:7361 since r11-2709-g866626efd749ed3e
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96670 --- Comment #1 from CVS Commits --- The master branch has been updated by Martin Sebor : https://gcc.gnu.org/g:bb04901d14f7749eb949092fd3dfcb6ca1958701 commit r11-2742-gbb04901d14f7749eb949092fd3dfcb6ca1958701 Author: Martin Sebor Date: Tue Aug 18 12:49:35 2020 -0600 Fix PR tree-optimization/96670 - ICE on memchr with an empty initializer. gcc/ChangeLog: PR tree-optimization/96670 PR middle-end/78257 * gimple-fold.c (gimple_fold_builtin_memchr): Call byte_representation to get it, not string_constant. gcc/testsuite/ChangeLog: PR tree-optimization/96670 * gcc.dg/memchr-2.c: New test. * gcc.dg/memcmp-6.c: New test.
kernel+toolchain tracks at plumbers
Hi All,
Between the GNU toolchain track, GNU toolchain MC, LLVM BoF, and LLVM
MC at Plumbers 2020, we may be getting close to having more toolchain
topics than kernel topics at plumbers this year. :^D
https://linuxplumbersconf.org/event/7/timetable/?view=lpc
I'll be spending time between the above 4 for most of the conference.
I wanted to share the word on some of the talks we had lined up that
would be useful to have folks from a bunch of different tooling
backgrounds to help inform the discussion. In particular:
Dependency Ordering in the Linux kernel
https://linuxplumbersconf.org/event/7/contributions/821/
which should have feedback on the Linux kernel's memory model for implementers.
and
asm goto w/ outputs
https://linuxplumbersconf.org/event/7/contributions/801/
which would be useful to help discuss collaboration on designs of
future language extension in the context of the Linux kernel.
I'm particularly interested in
https://linuxplumbersconf.org/event/7/contributions/771/ ("Exploring
Profile Guided Optimization of the Linux Kernel") and the BoF
https://linuxplumbersconf.org/event/7/contributions/726/. If there's
other topics that would be particularly helpful to have LLVM folks in
the room, please let me know and I'll help promote it.
See you at the show!
--
Thanks,
~Nick Desaulniers
[Bug c++/96687] New: new char[4]{"foo"} doesn't work
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96687
Bug ID: 96687
Summary: new char[4]{"foo"} doesn't work
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: mpolacek at gcc dot gnu.org
Target Milestone: ---
We should accept the following:
char *p = new char[4]{"foo"};
but we reject with:
error: invalid conversion from ‘const char*’ to ‘char’ [-fpermissive]
[Bug c++/96687] new char[4]{"foo"} doesn't work
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96687 Marek Polacek changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |mpolacek at gcc dot gnu.org Last reconfirmed||2020-08-18 Keywords||rejects-valid Status|UNCONFIRMED |ASSIGNED Ever confirmed|0 |1
Have a look
Hi, Would you like to check out the contacts of *Ericsson *users? If you are interested please drop me a note so that we can connect and discuss about the opportunity. Thanks in advance! Regards, *Timothy Moss| **Manager Demand Generation|* If you do not wish further mail please reply with “Leave Out” in subject line
Re: [PATCH] rs6000: Rename instruction xvcvbf16sp to xvcvbf16spn
On Tue, Aug 18, 2020 at 01:30:53PM -0500, Peter Bergner wrote: > The xvcvbf16sp mnemonic, which was just added in ISA 3.1 has been renamed > to xvcvbf16spn, to make it consistent with the other non-signaling conversion > instructions which all end with "n". The only use of this instruction is in > an MMA conversion built-in function, so there is little to no compatibility > issue. > > I just pushed the patch that does the rename to binutils today. > > Ok for trunk and the GCC 10 branch after testing is clean? Yes, okay everywhere. Thanks! Segher > gcc/ > * config/rs6000/rs6000-builtin.def (BU_VSX_1): Rename xvcvbf16sp to > xvcvbf16spn. > * config/rs6000/rs6000-call.c (builtin_function_type): Likewise. > * config/rs6000/vsx.md: Likewise. > * doc/extend.texi: Likewise. > > gcc/testsuite/ > * gcc.target/powerpc/mma-builtin-3.c: Rename xvcvbf16sp to xvcvbf16spn.
[PATCH] rs6000: Rename instruction xvcvbf16sp to xvcvbf16spn
The xvcvbf16sp mnemonic, which was just added in ISA 3.1 has been renamed
to xvcvbf16spn, to make it consistent with the other non-signaling conversion
instructions which all end with "n". The only use of this instruction is in
an MMA conversion built-in function, so there is little to no compatibility
issue.
I just pushed the patch that does the rename to binutils today.
Ok for trunk and the GCC 10 branch after testing is clean?
Peter
gcc/
* config/rs6000/rs6000-builtin.def (BU_VSX_1): Rename xvcvbf16sp to
xvcvbf16spn.
* config/rs6000/rs6000-call.c (builtin_function_type): Likewise.
* config/rs6000/vsx.md: Likewise.
* doc/extend.texi: Likewise.
gcc/testsuite/
* gcc.target/powerpc/mma-builtin-3.c: Rename xvcvbf16sp to xvcvbf16spn.
diff --git a/gcc/config/rs6000/rs6000-builtin.def
b/gcc/config/rs6000/rs6000-builtin.def
index f9f0fece549..03c234ffa98 100644
--- a/gcc/config/rs6000/rs6000-builtin.def
+++ b/gcc/config/rs6000/rs6000-builtin.def
@@ -2998,7 +2998,7 @@ BU_SPECIAL_X (RS6000_BUILTIN_CFSTRING,
"__builtin_cfstring", RS6000_BTM_ALWAYS,
RS6000_BTC_MISC)
/* POWER10 MMA builtins. */
-BU_VSX_1 (XVCVBF16SP, "xvcvbf16sp", MISC, vsx_xvcvbf16sp)
+BU_VSX_1 (XVCVBF16SPN, "xvcvbf16spn", MISC, vsx_xvcvbf16spn)
BU_VSX_1 (XVCVSPBF16, "xvcvspbf16", MISC, vsx_xvcvspbf16)
BU_MMA_1 (XXMFACC, "xxmfacc", QUAD, mma_xxmfacc)
diff --git a/gcc/config/rs6000/rs6000-call.c b/gcc/config/rs6000/rs6000-call.c
index e39cfcf672b..3a23f1980ce 100644
--- a/gcc/config/rs6000/rs6000-call.c
+++ b/gcc/config/rs6000/rs6000-call.c
@@ -14037,7 +14037,7 @@ builtin_function_type (machine_mode mode_ret,
machine_mode mode_arg0,
case MISC_BUILTIN_CDTBCD:
case MISC_BUILTIN_CBCDTD:
case VSX_BUILTIN_XVCVSPBF16:
-case VSX_BUILTIN_XVCVBF16SP:
+case VSX_BUILTIN_XVCVBF16SPN:
case P10_BUILTIN_MTVSRBM:
case P10_BUILTIN_MTVSRHM:
case P10_BUILTIN_MTVSRWM:
diff --git a/gcc/config/rs6000/vsx.md b/gcc/config/rs6000/vsx.md
index dd750210758..54da54c43dc 100644
--- a/gcc/config/rs6000/vsx.md
+++ b/gcc/config/rs6000/vsx.md
@@ -300,7 +300,7 @@
UNSPEC_VSX_DIVUD
UNSPEC_VSX_MULSD
UNSPEC_VSX_SIGN_EXTEND
- UNSPEC_VSX_XVCVBF16SP
+ UNSPEC_VSX_XVCVBF16SPN
UNSPEC_VSX_XVCVSPBF16
UNSPEC_VSX_XVCVSPSXDS
UNSPEC_VSX_XVCVSPHP
@@ -364,10 +364,10 @@
])
(define_int_iterator XVCVBF16 [UNSPEC_VSX_XVCVSPBF16
-UNSPEC_VSX_XVCVBF16SP])
+UNSPEC_VSX_XVCVBF16SPN])
(define_int_attr xvcvbf16 [(UNSPEC_VSX_XVCVSPBF16 "xvcvspbf16")
-(UNSPEC_VSX_XVCVBF16SP "xvcvbf16sp")])
+(UNSPEC_VSX_XVCVBF16SPN "xvcvbf16spn")])
;; Like VI, defined in vector.md, but add ISA 2.07 integer vector ops
(define_mode_iterator VI2 [V4SI V8HI V16QI V2DI])
diff --git a/gcc/doc/extend.texi b/gcc/doc/extend.texi
index 79833171c5a..bcc251481ca 100644
--- a/gcc/doc/extend.texi
+++ b/gcc/doc/extend.texi
@@ -21624,7 +21624,7 @@ void __builtin_mma_assemble_pair (__vector_pair *,
vec_t, vec_t);
void __builtin_mma_disassemble_pair (void *, __vector_pair *);
vec_t __builtin_vsx_xvcvspbf16 (vec_t);
-vec_t __builtin_vsx_xvcvbf16sp (vec_t);
+vec_t __builtin_vsx_xvcvbf16spn (vec_t);
@end smallexample
@node RISC-V Built-in Functions
diff --git a/gcc/testsuite/gcc.target/powerpc/mma-builtin-3.c
b/gcc/testsuite/gcc.target/powerpc/mma-builtin-3.c
index 29eb2754999..9bec78d333f 100644
--- a/gcc/testsuite/gcc.target/powerpc/mma-builtin-3.c
+++ b/gcc/testsuite/gcc.target/powerpc/mma-builtin-3.c
@@ -18,7 +18,7 @@ void
foo1 (vec_t *vec)
{
vec[1] = __builtin_vsx_xvcvspbf16 (vec[0]);
- vec[3] = __builtin_vsx_xvcvbf16sp (vec[2]);
+ vec[3] = __builtin_vsx_xvcvbf16spn (vec[2]);
}
/* { dg-final { scan-assembler-times {\mxxmtacc\M} 1 } } */
@@ -28,4 +28,4 @@ foo1 (vec_t *vec)
/* { dg-final { scan-assembler-not {\mlxvp\M} } } */
/* { dg-final { scan-assembler-not {\mstxvp\M} } } */
/* { dg-final { scan-assembler-times {\mxvcvspbf16\M} 1 } } */
-/* { dg-final { scan-assembler-times {\mxvcvbf16sp\M} 1 } } */
+/* { dg-final { scan-assembler-times {\mxvcvbf16spn\M} 1 } } */
Re: [PATCH] libstdc++: testsuite: Address random failure in pthread_create() [PR54185]
On 18/08/20 11:20 -0400, Lewis Hyatt wrote:
On Tue, Aug 18, 2020 at 09:43:31AM +0100, Jonathan Wakely wrote:
On 13/08/20 18:15 -0400, Lewis Hyatt via Libstdc++ wrote:
> Hello-
>
> The attached patch was discussed briefly on PR 54185 here:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54185#c14
> The test case for this PR sometimes fails due to random failures in
> pthread_create() that are not related to the original PR. This patch fixes
> it up by ignoring those failures. The test case was designed to repeat the
> same test 1000 times to attempt to reproduce a race condition, so I think is
> OK if some of those iterations are simply skipped.
>
> Thanks for taking a look at it; I can commit it if it makes sense.
>
> -Lewis
> libstdc++: testsuite: Address random failure in pthread_create() [PR54185]
>
> The test for this PR calls pthread_create() many times in a row, which may
fail
> with EAGAIN sometimes. Avoid generating a test failure in this case.
>
> libstdc++-v3/ChangeLog:
>
>PR libstdc++/54185
>* testsuite/30_threads/condition_variable/54185.cc: Make test robust
>to random pthread_create() failures.
Thanks for the patch. It certainly looks reasonable, but I wonder if
the attached version wouldn't be (very slightly) better. The
difference is that instead of just giving up at the first EAGAIN we
keep trying. This way we might be able to create a few more threads
before the loop finishes. If we still keep failing, it works the same.
I've also added a check that the failures are due to EAGAIN, and we'll
still terminate if there's some other problem. I'm assuming that your
failures are EAGAIN. Do you know why that's happening? Does your
system a low value for RLIMIT_NPROC or something?
Right, good point to check for EAGAIN. Yes, that's the error I get. I don't
understand why it happens. It's not related to libstdc++, I can reproduce it
with the below:
==
#include
void* do_nothing (void*)
{
return nullptr;
}
int main () {
for (int i = 0; i != 1000; ++i)
{
for (int j = 0; j != 10; ++j)
{
pthread_t thread;
const int err = pthread_create (, nullptr, do_nothing,
nullptr);
if (err) return 1;
pthread_join (thread, nullptr);
}
}
}
==
If I run this just once at a time, it never fails. But if I run it twice at
a time, it fails about 30% of the time, like:
root@host:/home/lewis# (./pthread_fail || echo ERR) & \
(./pthread_fail || echo ERR) & wait
[1] 25041
[2] 25042
ERR
ERR
All the rlimits are infinite or as high as possible, but I dug around a bit
and it seems this is a systemd thing, this system had systemd-logind
disabled (perhaps not in the correct way) and something about the
configuration led to the issue. Enabling systemd-logind resolves it for
me. So perhaps this was mostly specific to me. Sorry if I wasted your
time... if you still think it's worth doing something here I am happy to
help.
I don't think it's a waste of time. Adding the 'notified' variable to
the test to prevent spurious wakeups is an improvement if nothing else.
FWIW, regarding your extension to the patch, in case there are some
legitimate thread creation problems, one thing to keep in mind is that the
retrying after failure makes certain things worse. For instance, (with my
system in the previous state), what would happen is the 54185.cc hit the
pthread_create failure, then prior to this patch it just bailed out. With
either of these patches it tries more times, which can worsen issues in
unrelated test cases running in parallel, that may see random failures in
their own forks or thread creations. This test case is trying hard to
reproduce the race condition by running 1000 iterations, which seems
worthwhile given it's still failing on some systems like AIX, but on the
On AIX it fails even with one iteration (not 1000) i.e. you simply
can't destroy a pthread_cond_t while there are threads still waiting
on it. We don't need 1000 iterations to hit that bug, it happens right
away.
other hand it's possible doing 50 instead of 1000 would work too, and be
less prone to unrelated resource issues.
Maybe. I'm a bit concerned that if the test started consistently
breaking out of the inner loop after one or two threads on everybody's
systems it would never actually try to delete a condition_variable
that is being waited on. And so it would never exercise the problem
case, and we'd never know. The test would PASS with no indication of
problems, but wouldn't actually test anything.
So I think I'd like it to keep trying to create threads. The meaning
of EAGAIN is "try again" after all :-)
Thanks for taking a look at this.
[Bug fortran/96686] MIN/MAX should reject character arguments of different kind rather than ICE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96686 kargl at gcc dot gnu.org changed: What|Removed |Added Priority|P3 |P4 Ever confirmed|0 |1 Status|UNCONFIRMED |NEW Last reconfirmed||2020-08-18 CC||kargl at gcc dot gnu.org --- Comment #1 from kargl at gcc dot gnu.org --- Yep, I agree that this should simply be rejected. I looked at your other patch for min/max, and think it can be committed. If you want to update that patch to include the fix for this PR consider it pre-approved (provided regression testing passes).
[Bug fortran/96686] New: MIN/MAX should reject character arguments of different kind rather than ICE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96686 Bug ID: 96686 Summary: MIN/MAX should reject character arguments of different kind rather than ICE Product: gcc Version: 11.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: anlauf at gcc dot gnu.org Target Milestone: --- We current fail on this: program p implicit none character(kind=1) :: c1 = "1" character(kind=4) :: c4 = 4_"4" print *, min (c1, c4) end program p min_max_char.f90:5:16: 5 | print *, min (c1, c4) |1 internal compiler error: Cannot convert 'CHARACTER(1)' to 'CHARACTER(0,4)' at (1) 0x69ee19 gfc_report_diagnostic ../../gcc-trunk/gcc/fortran/error.c:782 0x6a0592 gfc_internal_error(char const*, ...) ../../gcc-trunk/gcc/fortran/error.c:1402 0x6bfb68 gfc_convert_type_warn(gfc_expr*, gfc_typespec*, int, int, bool) ../../gcc-trunk/gcc/fortran/intrinsic.c:5350 0x6c8385 gfc_resolve_minmax ../../gcc-trunk/gcc/fortran/iresolve.c:1621 0x6b4391 resolve_intrinsic ../../gcc-trunk/gcc/fortran/intrinsic.c:4501 0x6b4391 do_simplify ../../gcc-trunk/gcc/fortran/intrinsic.c:4671 0x6bedda gfc_intrinsic_func_interface(gfc_expr*, int) ../../gcc-trunk/gcc/fortran/intrinsic.c:5013 0x70e17b resolve_unknown_f ../../gcc-trunk/gcc/fortran/resolve.c:2919 0x70e17b resolve_function ../../gcc-trunk/gcc/fortran/resolve.c:3277 0x70e17b gfc_resolve_expr(gfc_expr*) ../../gcc-trunk/gcc/fortran/resolve.c:7094 0x714e84 gfc_resolve_expr(gfc_expr*) ../../gcc-trunk/gcc/fortran/resolve.c:7061 0x714e84 gfc_resolve_code(gfc_code*, gfc_namespace*) ../../gcc-trunk/gcc/fortran/resolve.c:11799 0x71e09f gfc_resolve_blocks(gfc_code*, gfc_namespace*) ../../gcc-trunk/gcc/fortran/resolve.c:10826 0x713c58 gfc_resolve_code(gfc_code*, gfc_namespace*) ../../gcc-trunk/gcc/fortran/resolve.c:11789 0x71650d resolve_codes ../../gcc-trunk/gcc/fortran/resolve.c:17334 0x7165de gfc_resolve(gfc_namespace*) ../../gcc-trunk/gcc/fortran/resolve.c:17369 0x6fe4b5 resolve_all_program_units ../../gcc-trunk/gcc/fortran/parse.c:6286 0x6fe4b5 gfc_parse_file() ../../gcc-trunk/gcc/fortran/parse.c:6538 0x74b3af gfc_be_parse_file ../../gcc-trunk/gcc/fortran/f95-lang.c:212 Proposed solution: since MIN/MAX with character arguments are not legacy stuff, there is no good reason to provide a GNU extension. We should simply reject this always, as in: gfc-11 min_max_char.f90 -std=f2018 min_max_char.f90:5:20: 5 | print *, min (c1, c4) |1 Error: GNU Extension: Different type kinds at (1) although it should simply say: Different type kinds. No reference to any GNU Extension.
[PING][PATCH v2] libgcc: Use `-fasynchronous-unwind-tables' for LIB2_DIVMOD_FUNCS
On Thu, 6 Aug 2020, Maciej W. Rozycki wrote:
> Complement commit b932f770f70d ("x86_64 frame unwind info"), SVN r46374,
> , and replace
> `-fexceptions -fnon-call-exceptions' with `-fasynchronous-unwind-tables'
> in LIB2_DIVMOD_FUNCS compilation flags so as to provide unwind tables
> for the affected functions while not pulling the unwinder proper, which
> is not required here.
>
> Remove the ARM overrides accordingly, retaining the hook infrastructure
> however, and make the ARM test case a generic one.
>
> Beyond saving program space it fixes a RISC-V glibc build error due to
> unsatisfied `malloc' and `free' references from the unwinder causing
> link errors with `ld.so' where libgcc has been built at -O0.
Ping for:
Maciej
[Bug target/96536] -fcf-protection code in i386.md:restore_stack_nonlocal uses invalid compare-and-jump rtl
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96536 Uroš Bizjak changed: What|Removed |Added Target Milestone|--- |8.5 Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #12 from Uroš Bizjak --- Fixed everywhere.
[Bug target/96536] -fcf-protection code in i386.md:restore_stack_nonlocal uses invalid compare-and-jump rtl
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96536 --- Comment #11 from CVS Commits --- The releases/gcc-8 branch has been updated by Uros Bizjak : https://gcc.gnu.org/g:bf7b9330982165e051de0962c5bc231e2d1242d9 commit r8-10410-gbf7b9330982165e051de0962c5bc231e2d1242d9 Author: Uros Bizjak Date: Tue Aug 18 19:48:51 2020 +0200 i386: Fix restore_stack_nonlocal expander [PR96536]. -fcf-protection code in restore_stack_nonlocal uses a branch based on a clobber result. The patch adds missing compare. 2020-08-18 Uroš Bizjak gcc/ChangeLog: PR target/96536 * config/i386/i386.md (restore_stack_nonlocal): Add missing compare RTX.
Re: [PATCH] arm: Require MVE memory operand for destination of vst1q intrinsic
On Thu, Aug 13, 2020 at 2:18 PM Joe Ramsay wrote:
>
> From: Joe Ramsay
>
> Hi,
>
> Previously, the machine description patterns for vst1q accepted a generic
> memory
> operand for the destination, which could lead to an unrecognised builtin when
> expanding vst1q* intrinsics. This change fixes the patterns to only accept MVE
> memory operands.
This is OK though I suspect this needs a PR and a backport request for GCC 10.
regards
Ramana
>
> Thanks,
> Joe
>
> gcc/ChangeLog:
>
> 2020-08-13 Joe Ramsay
>
> * config/arm/mve.md (mve_vst1q_f): Require MVE memory operand
> for
> destination.
> (mve_vst1q_): Likewise.
>
> gcc/testsuite/ChangeLog:
>
> 2020-08-13 Joe Ramsay
>
> * gcc.target/arm/mve/intrinsics/vst1q_f16.c: Add test that only MVE
> memory operand is accepted.
> * gcc.target/arm/mve/intrinsics/vst1q_s16.c: Likewise.
> * gcc.target/arm/mve/intrinsics/vst1q_s8.c: Likewise.
> * gcc.target/arm/mve/intrinsics/vst1q_u16.c: Likewise.
> * gcc.target/arm/mve/intrinsics/vst1q_u8.c: Likewise.
> ---
> gcc/config/arm/mve.md | 4 ++--
> gcc/testsuite/gcc.target/arm/mve/intrinsics/vst1q_f16.c | 10 +++---
> gcc/testsuite/gcc.target/arm/mve/intrinsics/vst1q_s16.c | 10 +++---
> gcc/testsuite/gcc.target/arm/mve/intrinsics/vst1q_s8.c | 10 +++---
> gcc/testsuite/gcc.target/arm/mve/intrinsics/vst1q_u16.c | 10 +++---
> gcc/testsuite/gcc.target/arm/mve/intrinsics/vst1q_u8.c | 10 +++---
> 6 files changed, 37 insertions(+), 17 deletions(-)
>
> diff --git a/gcc/config/arm/mve.md b/gcc/config/arm/mve.md
> index 9758862..465b39a 100644
> --- a/gcc/config/arm/mve.md
> +++ b/gcc/config/arm/mve.md
> @@ -9330,7 +9330,7 @@
>[(set_attr "length" "4")])
>
> (define_expand "mve_vst1q_f"
> - [(match_operand: 0 "memory_operand")
> + [(match_operand: 0 "mve_memory_operand")
> (unspec: [(match_operand:MVE_0 1 "s_register_operand")] VST1Q_F)
>]
>"TARGET_HAVE_MVE || TARGET_HAVE_MVE_FLOAT"
> @@ -9340,7 +9340,7 @@
> })
>
> (define_expand "mve_vst1q_"
> - [(match_operand:MVE_2 0 "memory_operand")
> + [(match_operand:MVE_2 0 "mve_memory_operand")
> (unspec:MVE_2 [(match_operand:MVE_2 1 "s_register_operand")] VST1Q)
>]
>"TARGET_HAVE_MVE"
> diff --git a/gcc/testsuite/gcc.target/arm/mve/intrinsics/vst1q_f16.c
> b/gcc/testsuite/gcc.target/arm/mve/intrinsics/vst1q_f16.c
> index 363b4ca..312b746 100644
> --- a/gcc/testsuite/gcc.target/arm/mve/intrinsics/vst1q_f16.c
> +++ b/gcc/testsuite/gcc.target/arm/mve/intrinsics/vst1q_f16.c
> @@ -10,12 +10,16 @@ foo (float16_t * addr, float16x8_t value)
>vst1q_f16 (addr, value);
> }
>
> -/* { dg-final { scan-assembler "vstrh.16" } } */
> -
> void
> foo1 (float16_t * addr, float16x8_t value)
> {
>vst1q (addr, value);
> }
>
> -/* { dg-final { scan-assembler "vstrh.16" } } */
> +/* { dg-final { scan-assembler-times "vstrh.16" 2 } } */
> +
> +void
> +foo2 (float16_t a, float16x8_t x)
> +{
> + vst1q (, x);
> +}
> diff --git a/gcc/testsuite/gcc.target/arm/mve/intrinsics/vst1q_s16.c
> b/gcc/testsuite/gcc.target/arm/mve/intrinsics/vst1q_s16.c
> index 37c4713..cd14e2c 100644
> --- a/gcc/testsuite/gcc.target/arm/mve/intrinsics/vst1q_s16.c
> +++ b/gcc/testsuite/gcc.target/arm/mve/intrinsics/vst1q_s16.c
> @@ -10,12 +10,16 @@ foo (int16_t * addr, int16x8_t value)
>vst1q_s16 (addr, value);
> }
>
> -/* { dg-final { scan-assembler "vstrh.16" } } */
> -
> void
> foo1 (int16_t * addr, int16x8_t value)
> {
>vst1q (addr, value);
> }
>
> -/* { dg-final { scan-assembler "vstrh.16" } } */
> +/* { dg-final { scan-assembler-times "vstrh.16" 2 } } */
> +
> +void
> +foo2 (int16_t a, int16x8_t x)
> +{
> + vst1q (, x);
> +}
> diff --git a/gcc/testsuite/gcc.target/arm/mve/intrinsics/vst1q_s8.c
> b/gcc/testsuite/gcc.target/arm/mve/intrinsics/vst1q_s8.c
> index fe5edea..0004c80 100644
> --- a/gcc/testsuite/gcc.target/arm/mve/intrinsics/vst1q_s8.c
> +++ b/gcc/testsuite/gcc.target/arm/mve/intrinsics/vst1q_s8.c
> @@ -10,12 +10,16 @@ foo (int8_t * addr, int8x16_t value)
>vst1q_s8 (addr, value);
> }
>
> -/* { dg-final { scan-assembler "vstrb.8" } } */
> -
> void
> foo1 (int8_t * addr, int8x16_t value)
> {
>vst1q (addr, value);
> }
>
> -/* { dg-final { scan-assembler "vstrb.8" } } */
> +/* { dg-final { scan-assembler-times "vstrb.8" 2 } } */
> +
> +void
> +foo2 (int8_t a, int8x16_t x)
> +{
> + vst1q (, x);
> +}
> diff --git a/gcc/testsuite/gcc.target/arm/mve/intrinsics/vst1q_u16.c
> b/gcc/testsuite/gcc.target/arm/mve/intrinsics/vst1q_u16.c
> index a4c8c1a..248e7ce 100644
> --- a/gcc/testsuite/gcc.target/arm/mve/intrinsics/vst1q_u16.c
> +++ b/gcc/testsuite/gcc.target/arm/mve/intrinsics/vst1q_u16.c
> @@ -10,12 +10,16 @@ foo (uint16_t * addr, uint16x8_t value)
>vst1q_u16 (addr, value);
> }
>
> -/* { dg-final { scan-assembler "vstrh.16" } } */
> -
> void
> foo1 (uint16_t * addr, uint16x8_t value)
> {
>vst1q
Re: [Patch] Fortran: Add 'device_type' clause to OpenMP's declare target
Hi Tobias,
I am not deep in OMP dev, i.e., not at all, but this does not make sense to me:
@@ -2397,6 +2401,22 @@ mio_symbol_attribute (symbol_attribute *attr)
== OMP_REQ_ATOMIC_MEM_ORDER_RELAXED)
MIO_NAME (ab_attribute) (AB_OMP_REQ_MEM_ORDER_RELAXED, attr_bits);
}
+ switch (attr->omp_device_type)
+ {
+ case OMP_DEVICE_TYPE_UNSET:
+ break;
+ case OMP_DEVICE_TYPE_HOST:
+ MIO_NAME (ab_attribute) (AB_OMP_DEVICE_TYPE_NOHOST, attr_bits);
^
Why also NOHOST here? If this intentional please comment.
+ break;
+ case OMP_DEVICE_TYPE_NOHOST:
+ MIO_NAME (ab_attribute) (AB_OMP_DEVICE_TYPE_NOHOST, attr_bits);
+ break;
diff --git a/gcc/fortran/trans-common.c b/gcc/fortran/trans-common.c
index c6383fc2352..1be5e51b67d 100644
--- a/gcc/fortran/trans-common.c
+++ b/gcc/fortran/trans-common.c
@@ -426,6 +426,8 @@ build_common_decl (gfc_common_head *com, tree union_type,
bool is_init) /* If there is no backend_decl for the common block, build it. */
if (decl == NULL_TREE)
{
+ tree clauses = NULL_TREE;
Would you mind using "omp_clauses" or the like here?
The reminder looks good to my omp-unexperienced eye.
Regards,
Andre
On Fri, 7 Aug 2020 17:03:34 +0200
Tobias Burnus wrote:
> This patch adds the device_type(any|nohost|host)
> clause for 'omp declare target' to Fortran.
>
> In OpenMP 5.0, it has no effect on variables but
> only on procedures – in TR8 (and later), it also
> affects variables.
>
> This patch adds this clause to either – except that
> the middle end does not seem to like 'target link'
> with that clause – for normal variables, common
> blocks are accepted. (In line with OpenMP 5, the
> middle end ignores the clause for variables.)
>
> OK?
>
> Tobias
>
> -
> Mentor Graphics (Deutschland) GmbH, Arnulfstraße 201, 80634 München / Germany
> Registergericht München HRB 106955, Geschäftsführer: Thomas Heurung,
> Alexander Walter
--
Andre Vehreschild * Email: vehre ad gmx dot de
Re: [Patch, fortran, coarray] Fix obvious typo in co_broadcast's argument assembly
Hi Tobias,
On Tue, 18 Aug 2020 19:14:30 +0200
Tobias Burnus wrote:
> On 8/18/20 7:04 PM, Andre Vehreschild wrote:
>
> > attached patch fixes an obvious typo in the routine gathering arguments for
> > co_broadcast(). See pr94958 for a detailed analysis, please.
>
> LGTM – except that I do not like the ChangeLog entry.
>
> It sounds like a mispelling in terms of a comment or
> error message. How about "Using the correct variable."
> – or something like that?
That's a good idea. Will use that.
> You could also consider adding a libcaf_single test case,
> given that you wrote one (see PR)...
Well, the test case in the PR does not test the issue, only with additional
modifications of trans-array one may see an impact in the pseudo code.
Alternatively one has to do a lot more of code generation aggregating the
results of the broadcasts of the different components. Given this is not
defined in the standard, I am not sure what to do here. And therefore just
wanted to correct the "miss-assignment" allowing future correct code generation.
Regards,
Andre
>
> Thanks for the patch!
>
> Tobias
>
> > gcc/fortran/ChangeLog:
> >
> > 2020-08-18 Andre Vehreschild
> >
> > PR fortran/94958
> > * trans-array.c (gfc_bcast_alloc_comp): Fix typo.
> >
> >
> > pr94958.patch
> >
> > diff --git a/gcc/fortran/trans-array.c b/gcc/fortran/trans-array.c
> > index 7a1b2fc74c9..73a45cd2dcf 100644
> > --- a/gcc/fortran/trans-array.c
> > +++ b/gcc/fortran/trans-array.c
> > @@ -9732,7 +9732,7 @@ gfc_bcast_alloc_comp (gfc_symbol *derived, gfc_expr
> > *expr, int rank, args.image_index = image_index;
> > args.stat = stat;
> > args.errmsg = errmsg;
> > - args.errmsg = errmsg_len;
> > + args.errmsg_len = errmsg_len;
> >
> > if (rank == 0)
> > {
> -
> Mentor Graphics (Deutschland) GmbH, Arnulfstraße 201, 80634 München / Germany
> Registergericht München HRB 106955, Geschäftsführer: Thomas Heurung,
> Alexander Walter
--
Andre Vehreschild * Email: vehre ad gmx dot de
[Bug middle-end/88780] [8/9/10/11 Regression] bogus -Wstringop-truncation for copying as many bytes from a string as its length
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88780 --- Comment #7 from Martin Sebor --- (In reply to Marietto from comment #6) ... > In function ‘strncpy’, > inlined from ‘xc_set_cpufreq_gov’ at xc_pm.c:308:5: > /usr/include/x86_64-linux-gnu/bits/string_fortified.h:106:10: error: > ‘__builtin_strncpy’ specified bound 16 equals destination size > [-Werror=stringop-truncation] > 106 | return __builtin___strncpy_chk (__dest, __src, __len, __bos (__dest)); > | ^~ This instance of the warning is most likely unrelated to the one reported in comment #0 (to tell for sure we'd need a test case to reproduce it). It indicates that strncpy is being called with the third argument set to the size of the destination array, which leaves the destination unterminated unless the source string is shorter. The following articles describe the problem and the suggested solutions in detail: https://developers.redhat.com/blog/2018/05/24/detecting-string-truncation-with-gcc-8/ https://us-cert.cisa.gov/bsi/articles/knowledge/coding-practices/strncpy-and-strncat
[Bug tree-optimization/96685] New: Failure to optimize not+sub to add+not
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96685
Bug ID: 96685
Summary: Failure to optimize not+sub to add+not
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: gabravier at gmail dot com
Target Milestone: ---
int f(int x, int y)
{
return ~(x - y);
}
This can be optimized to `~x + y`. While this isn't necessarily faster on most
platforms, it is at least equivalent and on x86 the addition can be optimized
to `lea` whereas the subtraction can't. This transformation is done by LLVM,
but not by GCC.
Re: [Patch, fortran, coarray] Fix obvious typo in co_broadcast's argument assembly
On 8/18/20 7:04 PM, Andre Vehreschild wrote:
attached patch fixes an obvious typo in the routine gathering arguments for
co_broadcast(). See pr94958 for a detailed analysis, please.
LGTM – except that I do not like the ChangeLog entry.
It sounds like a mispelling in terms of a comment or
error message. How about "Using the correct variable."
– or something like that?
You could also consider adding a libcaf_single test case,
given that you wrote one (see PR)...
Thanks for the patch!
Tobias
gcc/fortran/ChangeLog:
2020-08-18 Andre Vehreschild
PR fortran/94958
* trans-array.c (gfc_bcast_alloc_comp): Fix typo.
pr94958.patch
diff --git a/gcc/fortran/trans-array.c b/gcc/fortran/trans-array.c
index 7a1b2fc74c9..73a45cd2dcf 100644
--- a/gcc/fortran/trans-array.c
+++ b/gcc/fortran/trans-array.c
@@ -9732,7 +9732,7 @@ gfc_bcast_alloc_comp (gfc_symbol *derived, gfc_expr
*expr, int rank,
args.image_index = image_index;
args.stat = stat;
args.errmsg = errmsg;
- args.errmsg = errmsg_len;
+ args.errmsg_len = errmsg_len;
if (rank == 0)
{
-
Mentor Graphics (Deutschland) GmbH, Arnulfstraße 201, 80634 München / Germany
Registergericht München HRB 106955, Geschäftsführer: Thomas Heurung, Alexander
Walter
[Bug c++/96593] No "declaration changes meaning" diagnostic for alias templates
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96593 Marek Polacek changed: What|Removed |Added CC||mpolacek at gcc dot gnu.org Status|UNCONFIRMED |NEW Last reconfirmed||2020-08-18 Ever confirmed|0 |1 --- Comment #1 from Marek Polacek --- Like you say, this might be mandatory in C++23: https://wg21.link/p1697r0. So confirmed.
Re: PING: Fwd: [PATCH 2/2] Decouple adjust_range_from_scev from vr_values and value_range_equiv.
On 8/18/20 12:38 PM, Aldy Hernandez wrote:
And here's the patch without the sanity check.
Aldy
That diff was difficult to read.. I had to apply the patch to really
follow it :-P
Anyway, yeah, this looks better. effectively, you have
1) left the input range "vr" range merging in adjust-range_with_scev,
2) adjusted for the fact that the code extracted into
"bounds_of_var_in_loop" now returns a min/max properly set, which
sometimes includes basic symbolic expressions which the ranger can
simply invoke range-ops on.
3) the only functional difference now is that we still fully call
bounds_of_var_in_loop when "vr" is an anti-range whereas before we
bailed early. But you added comments that we may be able to utilize
that under some circumstances
this is OK.
diff --git a/gcc/vr-values.c b/gcc/vr-values.c
index fe51a6faeb8..9b21441dff3 100644
--- a/gcc/vr-values.c
+++ b/gcc/vr-values.c
@@ -1006,7 +1006,7 @@ vr_values::extract_range_from_comparison
(value_range_equiv *vr,
overflow. */
static bool
-check_for_binary_op_overflow (vr_values *store,
+check_for_binary_op_overflow (range_query *store,
enum tree_code subcode, tree type,
tree op0, tree op1, bool *ovf)
{
@@ -1736,42 +1736,40 @@ compare_range_with_value (enum tree_code comp, const
value_range *vr,
gcc_unreachable ();
}
-/* Given a range VR, a LOOP and a variable VAR, determine whether it
- would be profitable to adjust VR using scalar evolution information
- for VAR. If so, update VR with the new limits. */
-void
-vr_values::adjust_range_with_scev (value_range_equiv *vr, class loop *loop,
- gimple *stmt, tree var)
+/* Given a VAR in STMT within LOOP, determine the bounds of the
+ variable and store it in MIN/MAX and return TRUE. If no bounds
+ could be determined, return FALSE. */
+
+bool
+bounds_of_var_in_loop (tree *min, tree *max, range_query *query,
+ class loop *loop, gimple *stmt, tree var)
{
- tree init, step, chrec, tmin, tmax, min, max, type, tem;
+ tree init, step, chrec, tmin, tmax, type = TREE_TYPE (var);
enum ev_direction dir;
- /* TODO. Don't adjust anti-ranges. An anti-range may provide
- better opportunities than a regular range, but I'm not sure. */
- if (vr->kind () == VR_ANTI_RANGE)
-return;
-
chrec = instantiate_parameters (loop, analyze_scalar_evolution (loop, var));
/* Like in PR19590, scev can return a constant function. */
if (is_gimple_min_invariant (chrec))
{
- vr->set (chrec);
- return;
+ *min = *max = chrec;
+ return true;
}
if (TREE_CODE (chrec) != POLYNOMIAL_CHREC)
-return;
+return false;
init = initial_condition_in_loop_num (chrec, loop->num);
- tem = op_with_constant_singleton_value_range (init);
- if (tem)
-init = tem;
step = evolution_part_in_loop_num (chrec, loop->num);
- tem = op_with_constant_singleton_value_range (step);
- if (tem)
-step = tem;
+
+ /* If INIT is an SSA with a singleton range, set INIT to said
+ singleton, otherwise leave INIT alone. */
+ if (TREE_CODE (init) == SSA_NAME)
+query->get_value_range (init, stmt)->singleton_p ();
+ /* Likewise for step. */
+ if (TREE_CODE (step) == SSA_NAME)
+query->get_value_range (step, stmt)->singleton_p ();
/* If STEP is symbolic, we can't know whether INIT will be the
minimum or maximum value in the range. Also, unless INIT is
@@ -1780,7 +1778,7 @@ vr_values::adjust_range_with_scev (value_range_equiv *vr,
class loop *loop,
if (step == NULL_TREE
|| !is_gimple_min_invariant (step)
|| !valid_value_p (init))
-return;
+return false;
dir = scev_direction (chrec);
if (/* Do not adjust ranges if we do not know whether the iv increases
@@ -1789,9 +1787,8 @@ vr_values::adjust_range_with_scev (value_range_equiv *vr,
class loop *loop,
/* ... or if it may wrap. */
|| scev_probably_wraps_p (NULL_TREE, init, step, stmt,
get_chrec_loop (chrec), true))
-return;
+return false;
- type = TREE_TYPE (var);
if (POINTER_TYPE_P (type) || !TYPE_MIN_VALUE (type))
tmin = lower_bound_in_type (type, type);
else
@@ -1806,7 +1803,7 @@ vr_values::adjust_range_with_scev (value_range_equiv *vr,
class loop *loop,
if (TREE_CODE (step) == INTEGER_CST
&& is_gimple_val (init)
&& (TREE_CODE (init) != SSA_NAME
- || get_value_range (init, stmt)->kind () == VR_RANGE))
+ || query->get_value_range (init, stmt)->kind () == VR_RANGE))
{
widest_int nit;
@@ -1829,21 +1826,29 @@ vr_values::adjust_range_with_scev (value_range_equiv *vr, class loop *loop,
&& (sgn == UNSIGNED
|| wi::gts_p (wtmp, 0) == wi::gts_p (wi::to_wide (step), 0)))
{
- value_range_equiv maxvr;
-
[Patch, fortran, coarray] Fix obvious typo in co_broadcast's argument assembly
Hi all,
attached patch fixes an obvious typo in the routine gathering arguments for
co_broadcast(). See pr94958 for a detailed analysis, please.
Regtests ok on FC31/x86_64. Will commit as obvious on Thursday, if no one
objects.
Regards,
Andre
--
Andre Vehreschild * Email: vehre ad gmx dot de
gcc/fortran/ChangeLog:
2020-08-18 Andre Vehreschild
PR fortran/94958
* trans-array.c (gfc_bcast_alloc_comp): Fix typo.
diff --git a/gcc/fortran/trans-array.c b/gcc/fortran/trans-array.c
index 7a1b2fc74c9..73a45cd2dcf 100644
--- a/gcc/fortran/trans-array.c
+++ b/gcc/fortran/trans-array.c
@@ -9732,7 +9732,7 @@ gfc_bcast_alloc_comp (gfc_symbol *derived, gfc_expr *expr, int rank,
args.image_index = image_index;
args.stat = stat;
args.errmsg = errmsg;
- args.errmsg = errmsg_len;
+ args.errmsg_len = errmsg_len;
if (rank == 0)
{
[Bug fortran/94958] gcc/fortran/trans-array.c:9797: possible typo ?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94958
vehre at gcc dot gnu.org changed:
What|Removed |Added
Status|NEW |ASSIGNED
--- Comment #4 from vehre at gcc dot gnu.org ---
Further research showed, that the conseQuences of the mistake are not impacting
gfortran in any kind, because the errmsg and errmsg_len are never used. The
code here is jumped to only when a derived type containing an allocatable
component is broadcasted and then only in caf-lib-mode, e.g.:
! { dg-do compile }
!
! PR fortran/94958
!
implicit none
type struct
integer, allocatable :: comp
end type
type(struct) :: a
character(kind=1, len=20) :: err
integer :: stat
call co_broadcast(a, this_image(), stat, err)
end
gfortran -fcoarray=lib bcast_1.f90 -lcaf_single
During traversal of the derived type for bcast, the function call to
CO_BROADCAST() for the type 'a' and it's allocatable component 'comp' is never
augmented with the nodes for stat, errmsg and errmsg_len. For this small
example the code already has two calls to co_broadcast. Which indicates the
necessity of having some way to aggregate the stat and errmsg over all these
calls. Unfortunately does the Fortran-standard (2015, 2018) not state how to
aggregate the stat and/or errmsg for multiple broadcasts.
I therefore propose a fix:
diff --git a/gcc/fortran/trans-array.c b/gcc/fortran/trans-array.c
index 7a1b2fc74c9..73a45cd2dcf 100644
--- a/gcc/fortran/trans-array.c
+++ b/gcc/fortran/trans-array.c
@@ -9732,7 +9732,7 @@ gfc_bcast_alloc_comp (gfc_symbol *derived, gfc_expr
*expr, int rank,
args.image_index = image_index;
args.stat = stat;
args.errmsg = errmsg;
- args.errmsg = errmsg_len;
+ args.errmsg_len = errmsg_len;
if (rank == 0)
{
as obvious and get done with this pr.
[Bug c++/96602] Partial ordering is ambiguous with default function arguments
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96602 Marek Polacek changed: What|Removed |Added Keywords||rejects-valid Status|UNCONFIRMED |NEW CC||mpolacek at gcc dot gnu.org Ever confirmed|0 |1 Last reconfirmed||2020-08-18 --- Comment #1 from Marek Polacek --- Sounds legit. Not a regression.
[Bug c/96683] Arm: MVE ACLE intrinsics vst1q_{s8|u8|s16|u16} is not supported by GCC.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96683 SRINATH PARVATHANENI changed: What|Removed |Added Last reconfirmed||2020-08-18 Ever confirmed|0 |1 Status|UNCONFIRMED |NEW
