Re: libgo patch committed: Add riscv and js/wasm
On Mon, Jun 11, 2018 at 12:22 PM, Palmer Dabbelt wrote: > On Mon, 11 Jun 2018 12:16:39 PDT (-0700), i...@golang.org wrote: >> >> This libgo patch add riscv and js/wasm as known targets. This >> incorporates cut down versions of https://golang.org/cl/102835 and >> https://golang.org/cl/106256 from the master sources. This will tell >> the go/build to skip files with those tags. Bootstrapped and ran Go >> testsuite on x86_64-pc-linux-gnu. Committed to mainline. > > > [...] > >> --- libgo/goarch.sh (revision 261203) >> +++ libgo/goarch.sh (working copy) >> @@ -153,6 +153,11 @@ case $goarch in >> ;; >> esac >> ;; >> +riscv) >> + family=RISCV >> + pcquantum=2 >> + ptrsize=4 >> + ;; >> riscv64) >> family=RISCV64 >> pcquantum=2 > > > I don't know anything about Go, but we've generally been calling the RISC-V > architectures "riscv32" and "riscv64" as opposed to "riscv" and "riscv64", > with the idea being that it's a bit more explicit. Technically, RISC-V is > the name of a family of ISAs, with "RV32I" and "RV64I" being two base ISAs > so this also matches the ISA's naming scheme. > > Obviously this isn't a big deal, I just saw the patch go by and thought I'd > bring it up. Thanks. This is just copying the master sources for the library, at https://go.googlesource.com/go/+/master/src/go/build/syslist.go . The naming scheme used here--riscv and riscv64--is pretty conventional for Go. Ian
Re: fix libcc1 dependencies in toplevel Makefile
On Jun 3, 2018, Alexandre Oliva wrote: > On Jun 27, 2017, Alexandre Oliva wrote: >> configuration, because the current Makefile would only do that with >> all-host, after bootstrap is complete. > I have extensively studied the dependencies, and I still don't see how > all-libcc1, that is only activated as a target during the post-bootstrap > all-host build, might have been activated concurrently with > staging/unstaging. By the time we get to all-host, we've sequentially > completed bootstrap, compare, and unstage. > The only possibilities I see of something going wrong as described is a > parallel build that has bootstrap and postbootstrap targets in the > command line, or some patch that changes the dependencies so that such > targets are considered in parallel. > I could definitely use the build logs from back then, if still > available, to try to make sense of the problem. I was missing one possibility: that the problem occurred during the post-bootstrap all-host all-target build. As far as I can tell from Nicolas' analysis, this was indeed the case. I still don't see how any staging or unstaging might have taken place, but I can now see that we do reenter the gcc dir before building all-libcc1. If that reentering rebuilds anything, particularly headers, that may be enough to explain the reported symptoms. Now, I do vaguely recall build output within the gcc subdir that possibly recreated the gcc/include subtree, which might explain the observed errors. The good news is that the patch I posted the other day actually addresses this problem: the dep on stage_last is not enough to trigger a rebuild of gcc, so a post-bootstrap all-host all-target build will not reenter the bootstrapped dirs, but that dep does trigger an initial build of gcc if one has not gone through bootstrapping yet. So I see two possible ways to go from now: 1. address the previously-mentioned fragility in the patch I posted, to catch all cases of postbootstrap targets and their deps on non-postbootstrap targets. 2. revamp the bootstrap/non-bootstrap dependencies, using GNU make conditionals rather than configure-time enable/disable-bootstrap, so that we can have a different set of dependencies while running the bootstrap proper, having non-stage dependencies activated by default when any of the all-* targets are named in the command line, and also when building post-bootstrap all-host all-target. This might seem to bring the problem back, but rather by having the full dependency set, we'd avoid the race not by refraining from reentering dirs, but rather by having them entered or reentered according to the full dependencies, without mixing stage and non-stage dependencies. I'm not yet sure this is actually doable, but it seems to me that if it is, it would be more robust than what we have now. -- Alexandre Oliva, freedom fighter https://FSFLA.org/blogs/lxo Be the change, be Free! FSF Latin America board member GNU Toolchain EngineerFree Software Evangelist
Re: [PATCH] ltmain.sh: Sort input file list
On 6/11/18, Jeff Law wrote: > On 06/11/2018 11:06 AM, Joseph Myers wrote: >> If we're not doing a general update from upstream libtool, I think we >> should use the upstream ltmain.sh fix (libtool commit >> 74c8993c178a1386ea5e2363a01d919738402f30, it looks like), or follow it as >> >> close as possible, rather than having our own variant. >> > Agreed. My preference would be to get the various libtool, autoconf and > friends updated from the appropriate upstream projects. > > jeff > Thread from the last time this came up is here: https://gcc.gnu.org/ml/gcc/2017-10/msg00060.html
Re: [PATCH] PR target/85358, v3: Make PowerPC not convert __ibm128 to __float128 if long double is IEEE 128-bit
On Mon, Jun 11, 2018 at 07:31:44PM -0400, Michael Meissner wrote:
> This patch is a complete rework of the previous patch. Previously I used new
> target hooks to provide IFmode (__ibm128) from being widened by default to
> TFmode (long double) on power9 systems when long double is IEEE 128-bit.
>
> This patch reorganizes the 3 128-bit floating point types, so that IFmode is
> numerically higher than TFmode/KFmode. This means IFmode is considered the
> widest type. Since we do not define arithmetic insns for IFmode, other than
> negate/absolute value (that we define for the other types), we will not have
> undesirable widening. I needed to change long double size so that lookup of
> size would get the TFmode type and not the IFmode.
>
> Since I reorganized the modes, the compiler now uses truncif{kf,tf}2 instead
> of
> extend{tf,kf}if2. It turns out I had the argument modes backwards for trunc.
> I have included a fix for this thinko.
>
> I have built this on the following systems, and they bootstrapped and had no
> regressions. Can I check this into the trunk, and after a burn-in period
> check
> it into GCC 8.2, assuming the last build on power6 has no regressions?
>
> 1)Little endian power8 system (64-bit), --with-cpu=power8;
> 2)Big endian power8 system (64/32-bit), --with-cpu=power8;
> 3)Big endian power8 system (64/32-bit), no --with-cpu;
>
> I'm currently building it on:
>
> 4)Big endian power6 system (64/32-bit), no --with-cpu.
Whoops, I forgot I also did the following and it had no regressions:
5)Little endian power9 system (64-bit), --with-cpu=power9
--
Michael Meissner, IBM
IBM, M/S 2506R, 550 King Street, Littleton, MA 01460-6245, USA
email: meiss...@linux.ibm.com, phone: +1 (978) 899-4797
Re: [PATCH] PR target/85358, v3: Make PowerPC not convert __ibm128 to __float128 if long double is IEEE 128-bit
This patch is a complete rework of the previous patch. Previously I used new
target hooks to provide IFmode (__ibm128) from being widened by default to
TFmode (long double) on power9 systems when long double is IEEE 128-bit.
This patch reorganizes the 3 128-bit floating point types, so that IFmode is
numerically higher than TFmode/KFmode. This means IFmode is considered the
widest type. Since we do not define arithmetic insns for IFmode, other than
negate/absolute value (that we define for the other types), we will not have
undesirable widening. I needed to change long double size so that lookup of
size would get the TFmode type and not the IFmode.
Since I reorganized the modes, the compiler now uses truncif{kf,tf}2 instead of
extend{tf,kf}if2. It turns out I had the argument modes backwards for trunc.
I have included a fix for this thinko.
I have built this on the following systems, and they bootstrapped and had no
regressions. Can I check this into the trunk, and after a burn-in period check
it into GCC 8.2, assuming the last build on power6 has no regressions?
1) Little endian power8 system (64-bit), --with-cpu=power8;
2) Big endian power8 system (64/32-bit), --with-cpu=power8;
3) Big endian power8 system (64/32-bit), no --with-cpu;
I'm currently building it on:
4) Big endian power6 system (64/32-bit), no --with-cpu.
2018-06-11 Michael Meissner
PR target/85358
* config/rs6000/rs6000-modes.def (toplevel): Rework the 128-bit
floating point modes, so that IFmode is numerically greater than
TFmode, which is greater than KFmode using FRACTIONAL_FLOAT_MODE
to declare the ordering. This prevents IFmode from being
converted to TFmode when long double is IEEE 128-bit on an ISA 3.0
machine. Include rs6000-modes.h to share the fractional values
between genmodes* and the rest of the compiler.
(IFmode): Likewise.
(KFmode): Likewise.
(TFmode): Likewise.
* config/rs6000/rs6000-modes.h: New file.
* config/rs6000/rs6000.c (rs6000_debug_reg_global): Change the
meaning of rs6000_long_double_size so that 126..128 selects an
appropriate 128-bit floating point type.
(rs6000_option_override_internal): Likewise.
* config/rs6000/rs6000.h (toplevel): Include rs6000-modes.h.
(TARGET_LONG_DOUBLE_128): Change the meaning of
rs6000_long_double_size so that 126..128 selects an appropriate
128-bit floating point type.
(LONG_DOUBLE_TYPE_SIZE): Update comment.
* config/rs6000/rs6000.md (trunciftf2): Correct the modes of the
source and destination to match the standard usage.
(truncifkf2): Likewise.
--
Michael Meissner, IBM
IBM, M/S 2506R, 550 King Street, Littleton, MA 01460-6245, USA
email: meiss...@linux.ibm.com, phone: +1 (978) 899-4797
Index: gcc/config/rs6000/rs6000-modes.def
===
--- gcc/config/rs6000/rs6000-modes.def (revision 261349)
+++ gcc/config/rs6000/rs6000-modes.def (working copy)
@@ -18,16 +18,27 @@
along with GCC; see the file COPYING3. If not see
Re: Tighten LRA test for reloading the inner reg of a paradoxical subreg
On 05/30/2018 06:31 AM, Richard Sandiford wrote:
> Kyrill Tkachov writes:
>> Hi Richard,
>>
>> On 29/05/18 15:26, Richard Sandiford wrote:
>>> Kyrill Tkachov writes:
Hi all,
The recent changes to aarch64_expand_vector_init cause an ICE in the
attached testcase. The register allocator "ICEs with Max. number of
generated reload insns per insn is achieved (90)"
That is because aarch64_expand_vector_init creates a paradoxical
subreg to move a DImode value
into a V2DI vector:
(insn 74 72 76 8 (set (reg:V2DI 287 [ _166 ])
(subreg:V2DI (reg/v/f:DI 112 [ d ]) 0)) 1050
{*aarch64_simd_movv2di}
This is done because we want to express that the whole of the V2DI
vector will be written so that init-regs doesn't try to
zero-initialise it before we overwrite each lane individually anyway.
This can go bad for because if the DImode value is allocated in, say,
x30: the last register in that register class, the V2DI subreg of that
isn't valid or meaningful and that seems to cause the trouble.
It's kinda hard to know what the right solution for this is.
We could emit a duplicate of the value into all the lanes of the
vector, but we have tests that test against that
(we're trying to avoid unnecessary duplicates)
What this patch does is it defines a pattern for moving a scalar into
lane 0 of a vector using a simple FMOV or LDR and represents that as a
merging with a vector of zeroes. That way, the instruction represents
a full write of the destination vector but doesn't "read" more bits
from the source than necessary. The zeroing effect is also a more
accurate representation of the semantics of FMOV.
>>> This feels like a hack. Either the paradoxical subreg of the pseudo
>>> is invalid for some reason (in which case we should ICE when it's formed,
>>> not just in the case of x30 being allocated) or the subreg is valid,
>>> in which case the RA should handle it correctly (and the backend should
>>> give it the information it needs to do that).
>>>
>>> I could see the argument for ignoring the problem for expediency if the
>>> patch was a clean-up in its own right, but I think it's wrong to add so
>>> much code to paper over a bug.
>>
>> I see what you mean. Do you have any thoughts on where in RA we'd go
>> about fixing this? Since I don't know my way around RA I tried in the
>> place I was most comfortable changing :)
>
> Ah, but everyone who's patched the RA had to patch it for the
> first time. :-) And it's not that scary. But anyway...
>
> The original insn was:
>
> (insn 74 72 76 8 (set (reg:V2DI 287 [ _166 ])
> (subreg:V2DI (reg/v/f:DI 112 [ d ]) 0)) 1060 {*aarch64_simd_movv2di}
> (nil))
>
> which IRA converted to:
>
> (insn 74 72 580 8 (set (reg:V2DI 287 [ _166 ])
> (subreg:V2DI (reg/v/f:DI 517 [orig:112 d ] [112]) 0)) 1060
> {*aarch64_simd_movv2di}
> (nil))
>
> after creating loop allocnos. It happens that the ALLOCNO_WMODEs for
> both 112 and 517 were not set to V2DI due to another bug that I'll post
> a separate patch for, but we nevertheless got a valid allocation of
> register 1.
>
> LRA's first try at constraining the instruction gave:
>
> Choosing alt 5 in insn 74: (0) ?w (1) r {*aarch64_simd_movv2di}
>
> at which point all was good. But LRA later decided it needed
> to spill r517:
>
> Spill r517 after risky transformations
>
> so the next constraint attempt gave:
>
> Choosing alt 0 in insn 74: (0) =w (1) m {*aarch64_simd_movv2di}
>
> which was still good. Then during inheritance we had:
>
> Creating newreg=672 from oldreg=517, assigning class GENERAL_REGS to
> inheritance r672
> Original reg change 517->672 (bb8):
>74: r287:V2DI=r672:DI#0
> Add inheritance<-original before:
> 939: r672:DI=r517:DI
>
> Inheritance reuse change 517->672 (bb8):
> 620: r572:DI=r672:DI
> REG_DEAD r672:DI
>
> Use smallest class of POINTER_REGS and GENERAL_REGS
> Creating newreg=673 from oldreg=517, assigning class POINTER_REGS to
> inheritance r673
> Original reg change 517->673 (bb8):
> 936: r669:DI=r673:DI
> Add inheritance<-original before:
> 940: r673:DI=r517:DI
>
> ("Use smallest class of POINTER_REGS and GENERAL_REGS" ought to
> give GENERAL_REGS. That might be a missed optimisation, and probably
> due to both classes having the same number of allocatable registers.
> I'll look at that as a follow-on.)
>
> Thus LRA created two inheritance registers for r517, one (r673)
> that included the unallocatable x31 and another (r672) that didn't.
> The r672 references included the paradoxical subreg in insn 74 but the
> r673 ones didn't. LRA then allocated x30 to r673, which was a valid
> choice.
>
> Later LRA decided to "undo" the inheritance for insn 620, but because
> of the double inheritance, it got confused as to what the
Re: [ping] Use response files from the driver in more cases
On 06/04/2018 01:27 AM, Eric Botcazou wrote: > https://gcc.gnu.org/ml/gcc-patches/2018-04/msg01172.html OK. jeff
Re: [RFC] Add gcc.dg-selftests/dg-final.exp
On 05/30/2018 04:41 AM, Tom de Vries wrote: > Hi, > > this patch tests the error behaviour of dg-final directives when called with > an > incorrect number of arguments. > > The test is lazy, in that it doesn't bother to pass correct arguments, > assuming > that the number of arguments check is done before checking the actual > arguments. > > Using the patch, I managed to find a few things that needed to be fixed: > - [testsuite] Fix error message in scan-hidden/scan-not-hidden > https://gcc.gnu.org/ml/gcc-patches/2018-05/msg01599.html > - [testsuite] Use correct proc names in scanasm.exp > https://gcc.gnu.org/ml/gcc-patches/2018-05/msg01600.html > - [testsuite] Fix "too few/many" error messages in scan-*-times procs > https://gcc.gnu.org/ml/gcc-patches/2018-05/msg01601.html > > The output of the test run is: > ... > Running > /home/vries/gcc_versions/devel/src/gcc/testsuite/gcc.dg-selftests/dg-final.exp > ... > PASS: scan-tree-dump 0 1 2 3: too many arguments > PASS: scan-tree-dump 0: too few arguments > PASS: scan-tree-dump-times 0 1 2 3 4: too many arguments > PASS: scan-tree-dump-times 0 1: too few arguments > PASS: scan-tree-dump-not 0 1 2 3: too many arguments > PASS: scan-tree-dump-not 0: too few arguments > PASS: scan-tree-dump-dem 0 1 2 3: too many arguments > PASS: scan-tree-dump-dem 0: too few arguments > PASS: scan-tree-dump-dem-not 0 1 2 3: too many arguments > PASS: scan-tree-dump-dem-not 0: too few arguments > PASS: scan-rtl-dump 0 1 2 3: too many arguments > PASS: scan-rtl-dump 0: too few arguments > PASS: scan-rtl-dump-times 0 1 2 3 4: too many arguments > PASS: scan-rtl-dump-times 0 1: too few arguments > PASS: scan-rtl-dump-not 0 1 2 3: too many arguments > PASS: scan-rtl-dump-not 0: too few arguments > PASS: scan-rtl-dump-dem 0 1 2 3: too many arguments > PASS: scan-rtl-dump-dem 0: too few arguments > PASS: scan-rtl-dump-dem-not 0 1 2 3: too many arguments > PASS: scan-rtl-dump-dem-not 0: too few arguments > PASS: scan-ipa-dump 0 1 2 3: too many arguments > PASS: scan-ipa-dump 0: too few arguments > PASS: scan-ipa-dump-times 0 1 2 3 4: too many arguments > PASS: scan-ipa-dump-times 0 1: too few arguments > PASS: scan-ipa-dump-not 0 1 2 3: too many arguments > PASS: scan-ipa-dump-not 0: too few arguments > PASS: scan-ipa-dump-dem 0 1 2 3: too many arguments > PASS: scan-ipa-dump-dem 0: too few arguments > PASS: scan-ipa-dump-dem-not 0 1 2 3: too many arguments > PASS: scan-ipa-dump-dem-not 0: too few arguments > PASS: scan-ltrans-tree-dump 0 1 2 3: too many arguments > PASS: scan-ltrans-tree-dump 0: too few arguments > PASS: scan-ltrans-tree-dump-times 0 1 2 3 4: too many arguments > PASS: scan-ltrans-tree-dump-times 0 1: too few arguments > PASS: scan-ltrans-tree-dump-not 0 1 2 3: too many arguments > PASS: scan-ltrans-tree-dump-not 0: too few arguments > PASS: scan-ltrans-tree-dump-dem 0 1 2 3: too many arguments > PASS: scan-ltrans-tree-dump-dem 0: too few arguments > PASS: scan-ltrans-tree-dump-dem-not 0 1 2 3: too many arguments > PASS: scan-ltrans-tree-dump-dem-not 0: too few arguments > PASS: scan-wpa-ipa-dump 0 1 2 3: too many arguments > PASS: scan-wpa-ipa-dump 0: too few arguments > PASS: scan-wpa-ipa-dump-times 0 1 2 3 4: too many arguments > PASS: scan-wpa-ipa-dump-times 0 1: too few arguments > PASS: scan-wpa-ipa-dump-not 0 1 2 3: too many arguments > PASS: scan-wpa-ipa-dump-not 0: too few arguments > PASS: scan-wpa-ipa-dump-dem 0 1 2 3: too many arguments > PASS: scan-wpa-ipa-dump-dem 0: too few arguments > PASS: scan-wpa-ipa-dump-dem-not 0 1 2 3: too many arguments > PASS: scan-wpa-ipa-dump-dem-not 0: too few arguments > PASS: scan-offload-tree-dump 0 1 2 3: too many arguments > PASS: scan-offload-tree-dump 0: too few arguments > PASS: scan-offload-tree-dump-times 0 1 2 3 4: too many arguments > PASS: scan-offload-tree-dump-times 0 1: too few arguments > PASS: scan-offload-tree-dump-not 0 1 2 3: too many arguments > PASS: scan-offload-tree-dump-not 0: too few arguments > PASS: scan-offload-tree-dump-dem 0 1 2 3: too many arguments > PASS: scan-offload-tree-dump-dem 0: too few arguments > PASS: scan-offload-tree-dump-dem-not 0 1 2 3: too many arguments > PASS: scan-offload-tree-dump-dem-not 0: too few arguments > PASS: scan-lang-dump 0 1 2 3: too many arguments > PASS: scan-lang-dump 0: too few arguments > PASS: object-readelf 0 1 2 3: too many arguments > PASS: object-readelf 0: too few arguments > PASS: scan-assembler-times 0 1 2 3: too many arguments > PASS: scan-assembler-times 0: too few arguments > PASS: scan-assembler-dem 0 1 2: too many arguments > PASS: scan-assembler-dem : too few arguments > PASS: scan-assembler-dem-not 0 1 2: too many arguments > PASS: scan-assembler-dem-not : too few arguments > PASS: object-size 0 1 2 3 4: too many arguments > PASS: object-size 0 1: too few arguments > PASS: scan-assembler 0 1 2: too many arguments > PASS: scan-assembler : too few arguments > PASS: scan-assembler-not 0 1 2: too many arguments > PASS:
Re: Use poly_int rtx accessors instead of hwi accessors
On 05/30/2018 12:39 AM, Richard Sandiford wrote: > [ Update of: https://gcc.gnu.org/ml/gcc-patches/2018-01/msg00661.html ] > > This patch generalises various places that used hwi rtx accessors so > that they can handle poly_ints instead. In many cases these changes > are by inspection rather than because something had shown them to be > necessary. > > Tested on aarch64-linux-gnu (with and without SVE), aarch64_be-elf and > x86_64-linux-gnu. OK to install? > > Richard > > > 2018-05-30 Richard Sandiford > > gcc/ > * poly-int.h (can_div_trunc_p): Add new overload in which all values > are poly_ints. > * alias.c (get_addr): Extend CONST_INT handling to poly_int_rtx_p. > (memrefs_conflict_p): Likewise. > (init_alias_analysis): Likewise. > * cfgexpand.c (expand_debug_expr): Likewise. > * combine.c (combine_simplify_rtx, force_int_to_mode): Likewise. > * cse.c (fold_rtx): Likewise. > * explow.c (adjust_stack, anti_adjust_stack): Likewise. > * expr.c (emit_block_move_hints): Likewise. > (clear_storage_hints, push_block, emit_push_insn): Likewise. > (store_expr_with_bounds, reduce_to_bit_field_precision): Likewise. > (emit_group_load_1): Use rtx_to_poly_int64 for group offsets. > (emit_group_store): Likewise. > (find_args_size_adjust): Use strip_offset. Use rtx_to_poly_int64 > to read the PRE/POST_MODIFY increment. > * calls.c (store_one_arg): Use strip_offset. > * rtlanal.c (rtx_addr_can_trap_p_1): Extend CONST_INT handling to > poly_int_rtx_p. > (set_noop_p): Use rtx_to_poly_int64 for the elements selected > by a VEC_SELECT. > * simplify-rtx.c (avoid_constant_pool_reference): Use strip_offset. > (simplify_binary_operation_1): Extend CONST_INT handling to > poly_int_rtx_p. > * var-tracking.c (compute_cfa_pointer): Take a poly_int64 rather > than a HOST_WIDE_INT. > (hard_frame_pointer_adjustment): Change from HOST_WIDE_INT to > poly_int64. > (adjust_mems, add_stores): Update accodingly. > (vt_canonicalize_addr): Track polynomial offsets. > (emit_note_insn_var_location): Likewise. > (vt_add_function_parameter): Likewise. > (vt_initialize): Likewise. OK. jeff >
Re: [PATCH] relax -Wsizeof-pointer-memaccess for strncpy with size of source (PR 85931)
On 05/29/2018 08:57 PM, Martin Sebor wrote: > Warning for a strncpy call whose bound is the same as the size > of the source and suggesting to use the size of the source is > less than helpful when both sizes are the same, as in: > > char a[4], b[4]; > strncpy (a, b, sizeof b); > > The attached patch suppresses the -Wsizeof-pointer-memaccess > warning for these cases. To do that even for VLAs (in some > cases), the patch enhances operand_equal_p() to handle > SAVE_EXPR to detect when VLA in sizeof VLA refers to the size > of a variable-length array. > > Is this okay for trunk and GCC 8? > > Martin > > gcc-85931.diff > > > PR c/85931 - -Wsizeof-pointer-memaccess for strncpy with size of source > > gcc/c-family/ChangeLog: > > PR c/85931 > * c-warn.c (sizeof_pointer_memaccess_warning): Avoid warning when > sizeof source and destination yields the same value. > > gcc/ChangeLog: > > PR c/85931 > * fold-const.c (operand_equal_p): Handle SAVE_EXPR. > > gcc/testsuite/ChangeLog: > > PR c/85931 > * gcc.dg/Wstringop-truncation-3.c: New test. OK for the trunk. Richi and Jakub have the final say for the branch. I'm a bit surprised that you don't just use operand_equal_p for both the INTEGER_CST and !INTEGER_CST cases when testing dstsz == srcsz Jeff
C++ PATCH for c++/85792, -Wctor-dtor-privacy and inherited ctor
-Wctor-dtor-privacy thinks it can see all the constructors in a class
template, but inheriting constructors still look like a USING_DECL
there, so we need to look for that.
Tested x86_64-pc-linux-gnu, applying to trunk and 8.
commit 4b974abbaaaeb214f52824d990d0966b3b80fc36
Author: Jason Merrill
Date: Mon Jun 11 17:26:34 2018 -0400
PR c++/85792 -Wctor-dtor-privacy and inherited constructor.
* class.c (maybe_warn_about_overly_private_class): Handle inherited
constructors.
diff --git a/gcc/cp/class.c b/gcc/cp/class.c
index ab68b9be42a..fbf39035e18 100644
--- a/gcc/cp/class.c
+++ b/gcc/cp/class.c
@@ -2034,6 +2034,7 @@ maybe_warn_about_overly_private_class (tree t)
{
int has_member_fn = 0;
int has_nonprivate_method = 0;
+ bool nonprivate_ctor = false;
if (!warn_ctor_dtor_privacy
/* If the class has friends, those entities might create and
@@ -2064,7 +2065,11 @@ maybe_warn_about_overly_private_class (tree t)
non-private statics, we can't ever call any of the private member
functions.) */
for (tree fn = TYPE_FIELDS (t); fn; fn = DECL_CHAIN (fn))
-if (!DECL_DECLARES_FUNCTION_P (fn))
+if (TREE_CODE (fn) == USING_DECL
+ && DECL_NAME (fn) == ctor_identifier
+ && !TREE_PRIVATE (fn))
+ nonprivate_ctor = true;
+else if (!DECL_DECLARES_FUNCTION_P (fn))
/* Not a function. */;
else if (DECL_ARTIFICIAL (fn))
/* We're not interested in compiler-generated methods; they don't
@@ -2126,7 +2131,6 @@ maybe_warn_about_overly_private_class (tree t)
/* Implicitly generated constructors are always public. */
&& !CLASSTYPE_LAZY_DEFAULT_CTOR (t))
{
- bool nonprivate_ctor = false;
tree copy_or_move = NULL_TREE;
/* If a non-template class does not define a copy
diff --git a/gcc/testsuite/g++.dg/warn/Wctor-dtor2.C b/gcc/testsuite/g++.dg/warn/Wctor-dtor2.C
new file mode 100644
index 000..48137851f05
--- /dev/null
+++ b/gcc/testsuite/g++.dg/warn/Wctor-dtor2.C
@@ -0,0 +1,11 @@
+// PR c++/85792
+// { dg-do compile { target c++11 } }
+// { dg-additional-options -Wctor-dtor-privacy }
+
+template struct A { };
+
+template struct B : A {
+ using A::A;
+
+ B(const B&) { }
+};
C++ PATCH for c++/85963, -Wunused-but-set-variable with ?: in template
In this testcase we were pulling out the constant value of the
variable without ever calling mark_rvalue_use, which is needed for
proper handling of lambda captures. This lack also lead to this false
positive warning.
Tested x86_64-pc-linux-gnu, applying to trunk and 8.
commit e3359de1378a74fd049bcb3e737feefaa359a8f6
Author: Jason Merrill
Date: Mon Jun 11 16:54:24 2018 -0400
PR c++/85963 - -Wunused-but-set with ?: in template.
* pt.c (tsubst_copy_and_build) [COND_EXPR]: Call mark_rvalue_use.
diff --git a/gcc/cp/pt.c b/gcc/cp/pt.c
index d8880eb138d..ba78d2e34a5 100644
--- a/gcc/cp/pt.c
+++ b/gcc/cp/pt.c
@@ -18511,6 +18511,7 @@ tsubst_copy_and_build (tree t,
case COND_EXPR:
{
tree cond = RECUR (TREE_OPERAND (t, 0));
+ cond = mark_rvalue_use (cond);
tree folded_cond = fold_non_dependent_expr (cond);
tree exp1, exp2;
diff --git a/gcc/testsuite/g++.dg/warn/Wunused-var-34.C b/gcc/testsuite/g++.dg/warn/Wunused-var-34.C
new file mode 100644
index 000..52c715121f5
--- /dev/null
+++ b/gcc/testsuite/g++.dg/warn/Wunused-var-34.C
@@ -0,0 +1,27 @@
+// PR c++/85963
+// { dg-additional-options -Wall }
+
+template
+struct foo {
+ T val, alpha;
+ foo() : val(0), alpha(0) {}
+};
+
+template
+inline void bar(const foo& A, const foo& B, foo& C) {
+ const bool use_alpha = true;
+ const Talpha = use_alpha ? (A.alpha * B.alpha) : T(0);
+
+ C.val = A.val * B.val;
+ C.alpha = alpha;
+}
+
+
+int main() {
+ foo A,B,C;
+
+ bar(A,B,C);
+
+ return 0;
+}
+
Re: [PATCH] Fix lower-subreg ICE (PR target/85945)
On 05/29/2018 02:41 AM, Jakub Jelinek wrote: > Hi! > > We ICE on the following testcase, because lower-subreg sees only > SFmode subregs of a multi-word pseudo (V4SFmode) and decides to decompose > it. Decomposition is done through replacing the multi-word pseudo with > a concat of word-sized integer pseudos; unfortunately, we don't allow > SFmode subregs of DImode inner regs (or any other mix of floating and > integral mode where the sizes aren't the same), so we ICE later on during > the lower-subreg pass. > > The following patch punts in that case, unless the size is the same > (i.e. allows SFmode on 32-bit word targets or DFmode on 64-bit word ones). > > Bootstrapped/regtested on x86_64-linux and i686-linux plus tested with a > cross to s390x-linux on the testcase. Ok for trunk? > > BTW, wonder if we also shouldn't punt in case the inner mode is vector mode, > I don't think it is desirable to undo vectorization this way (but would like > to try that as a separate patch and gather some statistics). > > For this patch I've gathered statistics too, on x86_64/i686-linux this patch > changes behavior in a couple of 64-bit gcc.target/i386/ tests where the > modes in all cases were SFmode (outer) and V4SFmode (inner), but it seems at > least on avx5124fmadd-v4fnmaddss-1.c I've looked at we in the end didn't > decide to decompose it anyway (perhaps some other non-subreg use). > > 2018-05-29 Jakub Jelinek > > PR target/85945 > * lower-subreg.c (find_decomposable_subregs): Don't decompose float > subregs of multi-word pseudos unless the float mode has word size. > > * gcc.c-torture/compile/pr85945.c: New test. I thought we had a target macro which told us when it was safe to do this kind of thing. But I can't seem to find it. It probably wouldn't be the solution here since we're trying to avoid an ICE within the lowering pass. But it might point to other concerns in this space. Anyway, the patch is fine. I'm comfortable returning to the question WRT vector modes as a distinct issue in the future after you gather some data. jeff
Re: [PATCH] vx-common.h: add #define USE_TM_CLONE_REGISTRY 0
On 05/25/2018 04:49 PM, Rasmus Villemoes wrote: > 2018-05-26 Rasmus Villemoes > > gcc/ > * config/vx-common.h (USE_TM_CLONE_REGISTRY): #define to 0. Thanks. Installed on the trunk. jeff
Re: [PATCH] Fix PR c++/85400
> Eric, do you plan to backport this to release branches? I don't think so, it isn't a regression and the workaround is trivial. -- Eric Botcazou
Re: [PATCH] restore -Wstringop-overflow for checked strcpy/strcat (PR 85259)
On 05/14/2018 04:41 PM, Martin Sebor wrote: > r256683 committed to GCC 8 to avoiding duplicate instances of > -Wstringop-overflow warnings on some targets has the unintended > side-effect of suppressing even singleton instances of the warning > in cases such as 'strcat (strcpy (buf, "hello "), "world!")' when > _FORTIFY_SOURCE is defined. > > The attached patch restores the warning for the trunk. > > Since this is a regression in a security feature and the warning > isn't prone to false positives (I don't think I've seen any when > _FORTIFY_SOURCE is defined), I'd also like the fix considered for > the 8 branch. > > Thanks > Martin > > gcc-85259.diff > > > PR tree-optimization/85259 - Missing -Wstringop-overflow= since r256683 > > gcc/ChangeLog: > > PR tree-optimization/85259 > * builtins.c (compute_objsize): Handle constant offsets. > * gimple-ssa-warn-restrict.c (maybe_diag_offset_bounds): Return > true iff a warning has been issued. > * gimple.h (gimple_nonartificial_location): New function. > * tree-ssa-strlen.c (maybe_diag_stxncpy_trunc): Call > gimple_nonartificial_location and handle -Wno-system-headers. > (handle_builtin_stxncpy): Same. > > gcc/testsuite/ChangeLog: > > PR tree-optimization/85259 > * gcc.dg/Wstringop-overflow-5.c: New test. > * gcc.dg/Wstringop-overflow-6.c: New test. OK for the trunk. The general guidance we've received is to not try and fix these on the release branches. However, I think this one deserves an exception to the general guidance. So OK for the gcc-8 branch. jeff
Re: [PATCH] spellcheck: support transpositions aka Damerau-Levenshtein (PR other/69968)
On 04/30/2018 06:37 PM, David Malcolm wrote: > This patch updates the edit-distance algorithm in spellcheck.c to > support transpositions as well as additions/deletions/substitutions, > so that a transposition error counts as a distance of 1 rather than 2. > > This leads to saner suggestions for such cases. > > Successfully bootstrapped & regrtested on x86_64-pc-linux-gnu. > > OK for trunk? > > gcc/fortran/ChangeLog: > PR other/69968 > * misc.c (gfc_closest_fuzzy_match): Update for renaming of > levenshtein_distance to get_edit_distance. > > gcc/ChangeLog: > PR other/69968 > * spellcheck-tree.c (levenshtein_distance): Rename to... > (get_edit_distance): ...this, and update for underlying renaming. > * spellcheck-tree.h (levenshtein_distance): Rename to... > (get_edit_distance): ...this. > * spellcheck.c (levenshtein_distance): Rename to... > (get_edit_distance): ...this. Convert from Levenshtein distance > to Damerau-Levenshtein distance by supporting transpositions of > adjacent characters. Rename "v1" to "v_next" and "v0" to > "v_one_ago". > (selftest::levenshtein_distance_unit_test_oneway): Rename to... > (selftest::test_edit_distance_unit_test_oneway): ...this, and > update for underlying renaming. > (selftest::levenshtein_distance_unit_test): Rename to... > (selftest::test_get_edit_distance_unit): ...this, and update for > underlying renaming. > (selftest::test_find_closest_string): Add example from PR 69968 > where transposition helps > (selftest::test_metric_conditions): Update for renaming. > (selftest::test_metric_conditions): Likewise. > (selftest::spellcheck_c_tests): Likewise. > * spellcheck.h (levenshtein_distance): Rename both overloads to... > (get_edit_distance): ...this. > (best_match::consider): Update for renaming. > > gcc/testsuite/ChangeLog: > PR other/69968 > * gcc.dg/spellcheck-transposition.c: New test. Going to trust you've got the algorithm right :-) OK jeff
Re: [PATCH] libbacktrace: Support FreeBSD/DragonFlyBSD/NetBSD without /proc
On 03/01/2018 03:07 PM, Bryan Drewery wrote:
> From: Bryan Drewery
>
> FreeBSD has had this patch against Rust's bundled libbacktrace for a
> while which allows not having /proc mounted to get the process name.
> I am open to refactoring this if there's a better place to handle
> some of this, such as configure.ac or a bsd-compat.c file.
>
> Authored by: Jan Beich
> ---
> libbacktrace/fileline.c | 31 +++
> 1 file changed, 31 insertions(+)
>
> diff --git libbacktrace/fileline.c libbacktrace/fileline.c
> index e5673068379..6d56f89cfa9 100644
> --- libbacktrace/fileline.c
> +++ libbacktrace/fileline.c
> @@ -39,9 +39,40 @@ POSSIBILITY OF SUCH DAMAGE. */
> #include
> #include
>
> +#if defined(__DragonFly__) || defined(__FreeBSD__) || defined(__NetBSD__)
> +#include
> +#include
> +#endif
I would have expected these to be tested for by autoconf and
conditionally included based on a suitable HAVE_ test.
> +
> #include "backtrace.h"
> #include "internal.h"
>
> +#if !defined(HAVE_GETEXECNAME) && defined(KERN_PROC_PATHNAME)
> +/* Return pathname of executable or 0 on failure. */
> +#define HAVE_GETEXECNAME
> +static char execname[PATH_MAX + 1];
> +static const char *
> +getexecname(void)
> +{
> + size_t path_len = sizeof(execname);
> + int mib[] = {
> +CTL_KERN,
> +#if defined(__NetBSD__)
> +KERN_PROC_ARGS,
> +-1,
> +KERN_PROC_PATHNAME,
> +#else
> +KERN_PROC,
> +KERN_PROC_PATHNAME,
> +-1,
> +#endif
> + };
> + u_int miblen = sizeof(mib) / sizeof(mib[0]);
> + int rc = sysctl(mib, miblen, execname, _len, NULL, 0);
> + return rc ? NULL : execname;
> +}
> +#endif /* !HAVE_GETEXECNAME && KERN_PROC_PATHNAME */
So what system are you expecting to be handled in the #else clause?
Is there a cleaner (less #if crap) way to do this?
Ian has the final call here.
jeff
Re: [PATCH] update Zero-length array documentation
On 06/11/2018 02:03 PM, Richard Sandiford wrote:
Martin Sebor writes:
On 06/11/2018 12:08 PM, Richard Sandiford wrote:
Martin Sebor writes:
@@ -1553,12 +1553,28 @@ struct line *thisline = (struct line *)
thisline->length = this_length;
@end smallexample
-In ISO C90, you would have to give @code{contents} a length of 1, which
-means either you waste space or complicate the argument to @code{malloc}.
+Although the size of a zero-length array is zero, an array member of
+this kind may increase the size the enclosing type as a result of tail
+padding. The offset of a zero-length array member from the beginning
+of the enclosing structure is the same as the offset of an array with
+one or more elements of the same type. The alignment of a zero-length
+array is the same as the alignment of its elements.
-In ISO C99, you would use a @dfn{flexible array member}, which is
-slightly different in syntax and semantics:
+Declaring zero-length arrays in other contexts, including as interior
+members of structure objects or as non-member objects is discouraged.
+Accessing elements of zero-length arrays declared in such contexts is
+undefined and may be diagnosed.
+In the absence of the zero-length array extension, in ISO C90 the
+@code{contents} array in the example above would typically be declared
+to have a single element. Although this technique is discouraged, GCC
+handles trailing one-element array members similarly to zero-length
+arrays.
This last sentence seems a bit vague. E.g. GCC should never diagnose
an access to element 0 of a 1-element trailing array, whereas (like you
say above) it might for zero-length trailing arrays.
GCC doesn't diagnose past-the-end accesses to trailing member
arrays regardless of their size. I don't think it should start
diagnosing them for zero-length arrays, and probably not even
for one-element arrays (at least not in C90 mode). I think in
the future it would be worthwhile to consider diagnosing past-
the-end accesses to trailing member arrays of two or more
elements, but this patch isn't meant to suggest it's done yet.
At the same time, I do want to leave the door open to diagnosing
such accesses eventually, so I don't want to go into too much
detail describing exactly what is and what isn't diagnosed today.
Yeah, agree that we shouldn't go into detail about what is
and isn't diagnosed. I just don't think we should claim that
one-element arrays are treated "similarly" to zero-length arrays
without saying what "similarly" means. They're certainly different
at some level, otherwise the extension wouldn't have been added :-)
If we don't want to give much more detail about this then I think it
would be better to keep the original paragraph:
In ISO C90, you would have to give @code{contents} a length of 1, which
means either you waste space or complicate the argument to @code{malloc}.
instead of the last one. (The other changes look good to me FWIW.)
I changed it because the text seemed both vague (why does it waste
space and what complication to the malloc call would avoid wasting
it?) and superfluous (it seems obvious that a one-element array
takes up at least 1 unit worth of space, and that allocating less
would mean changing the malloc argument). But perhaps it would
be helpful to be explicit about the allocation size while still
saying as little as possible about diagnostics. How abut this:
In the absence of the zero-length array extension, in ISO C90
the @code{contents} array in the example above would typically
be declared to have a single element. Unlike a zero-length
array which only contributes to the size of the enclosing
structure for the purposes of alignment, a one-element array
always occupies at least as much space as a single object of
the type. Although using one-element arrays this way is
discouraged, GCC handles accesses to trailing one-element
array members analogously to zero-length arrays.
Noticed later,
+The preferred mechanism to declare variable-length types like
+@code{struct line} above is the ISO C99 @dfn{flexible array member},
+with slightly different in syntax and semantics:
Don't think the s/which is/with/ change is correct here.
Thanks, fixed.
Martin
C++ PATCH for comparison of pointers to union members
At the C++ meeting last week it came up that pointers to different
members of the same union are specified to compare as equal, which we
were getting wrong.
Tested x86_64-pc-linux-gnu, applying to trunk.
commit bdaca661a7dd74d703f089af7b4484e098884510
Author: Jason Merrill
Date: Tue Jun 5 15:57:06 2018 +0200
Fix ptrmem comparison for unions.
* constexpr.c (cxx_eval_binary_expression): Special case comparison
of pointers to members of the same union.
diff --git a/gcc/cp/constexpr.c b/gcc/cp/constexpr.c
index 944c1cdf11e..97a338535db 100644
--- a/gcc/cp/constexpr.c
+++ b/gcc/cp/constexpr.c
@@ -2051,8 +2051,22 @@ cxx_eval_binary_expression (const constexpr_ctx *ctx, tree t,
if (TREE_CODE (lhs) == PTRMEM_CST
&& TREE_CODE (rhs) == PTRMEM_CST)
- r = constant_boolean_node (cp_tree_equal (lhs, rhs) == is_code_eq,
- type);
+ {
+ tree lmem = PTRMEM_CST_MEMBER (lhs);
+ tree rmem = PTRMEM_CST_MEMBER (rhs);
+ bool eq;
+ if (TREE_CODE (lmem) == TREE_CODE (rmem)
+ && TREE_CODE (lmem) == FIELD_DECL
+ && TREE_CODE (DECL_CONTEXT (lmem)) == UNION_TYPE
+ && same_type_p (DECL_CONTEXT (lmem),
+ DECL_CONTEXT (rmem)))
+ /* If both refer to (possibly different) members of the same union
+ (12.3), they compare equal. */
+ eq = true;
+ else
+ eq = cp_tree_equal (lhs, rhs);
+ r = constant_boolean_node (eq == is_code_eq, type);
+ }
else if ((TREE_CODE (lhs) == PTRMEM_CST
|| TREE_CODE (rhs) == PTRMEM_CST)
&& (null_member_pointer_value_p (lhs)
diff --git a/gcc/testsuite/g++.dg/expr/ptrmem10.C b/gcc/testsuite/g++.dg/expr/ptrmem10.C
new file mode 100644
index 000..71d2df85860
--- /dev/null
+++ b/gcc/testsuite/g++.dg/expr/ptrmem10.C
@@ -0,0 +1,28 @@
+/* [expr.eq] If both refer to (possibly different) members of the same union
+ (12.3), they compare equal. */
+// { dg-do run { target c++11 } }
+// { dg-additional-options -O }
+
+union U
+{
+ int i;
+ int j;
+};
+
+#define SA(X) static_assert ((X),#X)
+SA (::i == ::j);
+SA (!(::i != ::j));
+
+#define assert(X) do { if (!(X)) __builtin_abort(); } while(0)
+
+void f (int U::*p, int U::*q)
+{
+ assert (p==q);
+ assert (!(p!=q));
+}
+
+int main()
+{
+ assert (::i == ::j);
+ assert (!(::i != ::j));
+}
Re: [PATCH] add missing @opindex to Warning Options
On 06/11/2018 01:20 PM, Jeff Law wrote: On 06/07/2018 09:21 PM, Eric Gallager wrote: On 6/7/18, Martin Sebor wrote: A bunch of warning options are missing an @opindex entry, usually for the negative form. I went through them all and added them where it made sense. Unless there are objections I will commit the patch to trunk next week. I think the patch is also appropriate for release branches (modulo options that don't exist there), so likewise, unless Jakub or Richard feel differently I will backport it to GCC 6 and 7. Martin There's a 'p' missing in "Wno-openm-simd" which looks like is being propagated by copying and pasting OK with that fixed. jeff Thanks for spotting the missing p! Committed in r261453. Martin
Re: [PATCH] update Zero-length array documentation
Martin Sebor writes:
> On 06/11/2018 12:08 PM, Richard Sandiford wrote:
>> Martin Sebor writes:
>>> @@ -1553,12 +1553,28 @@ struct line *thisline = (struct line *)
>>> thisline->length = this_length;
>>> @end smallexample
>>>
>>> -In ISO C90, you would have to give @code{contents} a length of 1, which
>>> -means either you waste space or complicate the argument to @code{malloc}.
>>> +Although the size of a zero-length array is zero, an array member of
>>> +this kind may increase the size the enclosing type as a result of tail
>>> +padding. The offset of a zero-length array member from the beginning
>>> +of the enclosing structure is the same as the offset of an array with
>>> +one or more elements of the same type. The alignment of a zero-length
>>> +array is the same as the alignment of its elements.
>>>
>>> -In ISO C99, you would use a @dfn{flexible array member}, which is
>>> -slightly different in syntax and semantics:
>>> +Declaring zero-length arrays in other contexts, including as interior
>>> +members of structure objects or as non-member objects is discouraged.
>>> +Accessing elements of zero-length arrays declared in such contexts is
>>> +undefined and may be diagnosed.
>>>
>>> +In the absence of the zero-length array extension, in ISO C90 the
>>> +@code{contents} array in the example above would typically be declared
>>> +to have a single element. Although this technique is discouraged, GCC
>>> +handles trailing one-element array members similarly to zero-length
>>> +arrays.
>>
>> This last sentence seems a bit vague. E.g. GCC should never diagnose
>> an access to element 0 of a 1-element trailing array, whereas (like you
>> say above) it might for zero-length trailing arrays.
>
> GCC doesn't diagnose past-the-end accesses to trailing member
> arrays regardless of their size. I don't think it should start
> diagnosing them for zero-length arrays, and probably not even
> for one-element arrays (at least not in C90 mode). I think in
> the future it would be worthwhile to consider diagnosing past-
> the-end accesses to trailing member arrays of two or more
> elements, but this patch isn't meant to suggest it's done yet.
> At the same time, I do want to leave the door open to diagnosing
> such accesses eventually, so I don't want to go into too much
> detail describing exactly what is and what isn't diagnosed today.
Yeah, agree that we shouldn't go into detail about what is
and isn't diagnosed. I just don't think we should claim that
one-element arrays are treated "similarly" to zero-length arrays
without saying what "similarly" means. They're certainly different
at some level, otherwise the extension wouldn't have been added :-)
If we don't want to give much more detail about this then I think it
would be better to keep the original paragraph:
In ISO C90, you would have to give @code{contents} a length of 1, which
means either you waste space or complicate the argument to @code{malloc}.
instead of the last one. (The other changes look good to me FWIW.)
Noticed later,
> +The preferred mechanism to declare variable-length types like
> +@code{struct line} above is the ISO C99 @dfn{flexible array member},
> +with slightly different in syntax and semantics:
Don't think the s/which is/with/ change is correct here.
Thanks,
Richard
Re: [PATCH] update Zero-length array documentation
On 06/11/2018 12:08 PM, Richard Sandiford wrote:
Martin Sebor writes:
@@ -1553,12 +1553,28 @@ struct line *thisline = (struct line *)
thisline->length = this_length;
@end smallexample
-In ISO C90, you would have to give @code{contents} a length of 1, which
-means either you waste space or complicate the argument to @code{malloc}.
+Although the size of a zero-length array is zero, an array member of
+this kind may increase the size the enclosing type as a result of tail
+padding. The offset of a zero-length array member from the beginning
+of the enclosing structure is the same as the offset of an array with
+one or more elements of the same type. The alignment of a zero-length
+array is the same as the alignment of its elements.
-In ISO C99, you would use a @dfn{flexible array member}, which is
-slightly different in syntax and semantics:
+Declaring zero-length arrays in other contexts, including as interior
+members of structure objects or as non-member objects is discouraged.
+Accessing elements of zero-length arrays declared in such contexts is
+undefined and may be diagnosed.
+In the absence of the zero-length array extension, in ISO C90 the
+@code{contents} array in the example above would typically be declared
+to have a single element. Although this technique is discouraged, GCC
+handles trailing one-element array members similarly to zero-length
+arrays.
This last sentence seems a bit vague. E.g. GCC should never diagnose
an access to element 0 of a 1-element trailing array, whereas (like you
say above) it might for zero-length trailing arrays.
GCC doesn't diagnose past-the-end accesses to trailing member
arrays regardless of their size. I don't think it should start
diagnosing them for zero-length arrays, and probably not even
for one-element arrays (at least not in C90 mode). I think in
the future it would be worthwhile to consider diagnosing past-
the-end accesses to trailing member arrays of two or more
elements, but this patch isn't meant to suggest it's done yet.
At the same time, I do want to leave the door open to diagnosing
such accesses eventually, so I don't want to go into too much
detail describing exactly what is and what isn't diagnosed today.
That said, I'm all for improving the text so if something isn't
clear enough that should be clearer or if there are improvements
you suggest please do let me know.
Thanks
Martin
Re: [C++ Patch] Fix grok_op_properties locations
OK. On Mon, Jun 11, 2018 at 3:29 PM, Paolo Carlini wrote: > Hi, > > this consistently fixes all the locations and at the same time removes the > special casing of POSTINCREMENT_EXPR and POSTDECREMENT_EXPR as agreed a few > days ago. Tested x86_64-linux. > > Thanks, Paolo. > > // >
Re: [PATCH] Come up with Deprecated option flag.
> On Jun 8, 2018, at 7:09 AM, Martin Liška wrote: > > Hi. > > First follow-up MPX removal patch comes up with Deprecated option flag. > That prints warning for options that have no effect: Should this be mentioned in the internals manual (section 8.2)? paul
[C++ Patch] Fix grok_op_properties locations
Hi,
this consistently fixes all the locations and at the same time removes
the special casing of POSTINCREMENT_EXPR and POSTDECREMENT_EXPR as
agreed a few days ago. Tested x86_64-linux.
Thanks, Paolo.
//
/cp
2018-06-11 Paolo Carlini
* decl.c (grok_op_properties): Consistently use the location
of the decl; remove special casing of POSTINCREMENT_EXPR and
POSTDECREMENT_EXPR wrt default arguments.
/testsuite
2018-06-11 Paolo Carlini
* g++.dg/lookup/new2.C: Test locations too.
* g++.dg/other/ellipsis1.C: Likewise.
* g++.dg/other/operator1.C: Likewise.
* g++.dg/other/operator2.C: Likewise.
* g++.dg/overload/operator2.C: Likewise.
* g++.dg/parse/defarg11.C: Likewise.
* g++.dg/parse/operator4.C: Likewise.
* g++.dg/template/error30.C: Likewise.
* g++.dg/template/explicit-args3.C: Likewise.
* g++.dg/warn/effc1.C: Likewise.
* g++.old-deja/g++.brendan/prepost2.C: Likewise.
* g++.old-deja/g++.brendan/prepost3.C: Likewise.
* g++.old-deja/g++.bugs/900215_01.C: Likewise.
* g++.old-deja/g++.jason/conversion5.C: Likewise.
* g++.old-deja/g++.jason/operator.C: Likewise.
Index: cp/decl.c
===
--- cp/decl.c (revision 261431)
+++ cp/decl.c (working copy)
@@ -13078,6 +13078,7 @@ grok_op_properties (tree decl, bool complain)
tree argtypes = TYPE_ARG_TYPES (TREE_TYPE (decl));
bool methodp = TREE_CODE (TREE_TYPE (decl)) == METHOD_TYPE;
tree name = DECL_NAME (decl);
+ location_t loc = DECL_SOURCE_LOCATION (decl);
tree class_type = DECL_CONTEXT (decl);
if (class_type && !CLASS_TYPE_P (class_type))
@@ -13139,13 +13140,14 @@ grok_op_properties (tree decl, bool complain)
{
if (CP_DECL_CONTEXT (decl) != global_namespace)
{
- error ("%qD may not be declared within a namespace", decl);
+ error_at (loc, "%qD may not be declared within a namespace",
+ decl);
return false;
}
if (!TREE_PUBLIC (decl))
{
- error ("%qD may not be declared as static", decl);
+ error_at (loc, "%qD may not be declared as static", decl);
return false;
}
}
@@ -13172,14 +13174,14 @@ grok_op_properties (tree decl, bool complain)
|| operator_code == ARRAY_REF
|| operator_code == NOP_EXPR)
{
- error ("%qD must be a nonstatic member function", decl);
+ error_at (loc, "%qD must be a nonstatic member function", decl);
return false;
}
if (DECL_STATIC_FUNCTION_P (decl))
{
- error ("%qD must be either a non-static member "
-"function or a non-member function", decl);
+ error_at (loc, "%qD must be either a non-static member "
+ "function or a non-member function", decl);
return false;
}
@@ -13188,8 +13190,8 @@ grok_op_properties (tree decl, bool complain)
if (!arg || arg == void_list_node)
{
if (complain)
- error ("%qD must have an argument of class or "
- "enumerated type", decl);
+ error_at(loc, "%qD must have an argument of class or "
+"enumerated type", decl);
return false;
}
@@ -13214,7 +13216,7 @@ grok_op_properties (tree decl, bool complain)
if (operator_code == COND_EXPR)
{
/* 13.4.0.3 */
- error ("ISO C++ prohibits overloading operator ?:");
+ error_at (loc, "ISO C++ prohibits overloading operator ?:");
return false;
}
@@ -13225,7 +13227,8 @@ grok_op_properties (tree decl, bool complain)
if (!arg)
{
/* Variadic. */
- error ("%qD must not have variable number of arguments", decl);
+ error_at (loc, "%qD must not have variable number of arguments",
+ decl);
return false;
}
++arity;
@@ -13248,9 +13251,10 @@ grok_op_properties (tree decl, bool complain)
else if (arity != 2)
{
/* This was an ambiguous operator but is invalid. */
- error (methodp
-? G_("%qD must have either zero or one argument")
-: G_("%qD must have either one or two arguments"), decl);
+ error_at (loc,
+ methodp
+ ? G_("%qD must have either zero or one argument")
+ : G_("%qD must have either one or two arguments"), decl);
return false;
}
else if ((operator_code == POSTINCREMENT_EXPR
@@ -13260,10 +13264,11 @@ grok_op_properties (tree decl, bool complain)
&& ! same_type_p (TREE_VALUE (TREE_CHAIN (argtypes)),
integer_type_node))
{
- error (methodp
-
New can_[in,de]crement_range debug checks
Hi
If not told otherwise I plan to commit attached patch tomorrow evening.
It is adding new Debug checks to find out if an output iterator
will always be reachable while looping on an input range. Note that this
check was already done previously by checking if the iterator was
[in,de]crementable but it will now assert before any operation take
place. I also need it in order to remove debug layer on the output
iterator in a future patch.
I am also adding some tests on the std::equal algorithm because I
plan to apply those macros to this algo too but users can append a
special value at the end of the 2nd range to make sure it will never go
beyond this position. Some tests are doing this and was triggering the
Debug check.
* include/debug/macros.h (__glibcxx_check_can_increment_range): New.
(__glibcxx_check_can_decrement_range): New.
* include/debug/debug.h (__glibcxx_requires_can_increment_range): New.
(__glibcxx_requires_can_decrement_range): New.
* include/bits/stl_algobase.h (std::copy(_II, _II, _OI)): Use
__glibcxx_requires_can_increment_range.
(std::move(_II, _II, _OI)): Likewise.
(std::copy_backward(_BI, _BI, _BI2)): Use
__glibcxx_requires_can_decrement_range.
(std::move_backward(_BI, _BI, _BI2)): Likewise.
* testsuite/25_algorithms/copy_backward/debug/1_neg.cc: New.
* testsuite/25_algorithms/copy_backward/debug/2_neg.cc: New.
* testsuite/25_algorithms/copy_backward/debug/3_neg.cc: New.
* testsuite/25_algorithms/equal/debug/1_neg.cc: New.
* testsuite/25_algorithms/equal/debug/2_neg.cc: New.
* testsuite/25_algorithms/equal/debug/3_neg.cc: New.
Tested under Linux x86_64, normal and debug modes.
François
diff --git a/libstdc++-v3/include/bits/stl_algobase.h b/libstdc++-v3/include/bits/stl_algobase.h
index bbc5774..d429943 100644
--- a/libstdc++-v3/include/bits/stl_algobase.h
+++ b/libstdc++-v3/include/bits/stl_algobase.h
@@ -449,11 +449,10 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
__glibcxx_function_requires(_InputIteratorConcept<_II>)
__glibcxx_function_requires(_OutputIteratorConcept<_OI,
typename iterator_traits<_II>::value_type>)
- __glibcxx_requires_valid_range(__first, __last);
+ __glibcxx_requires_can_increment_range(__first, __last, __result);
- return (std::__copy_move_a2<__is_move_iterator<_II>::__value>
- (std::__miter_base(__first), std::__miter_base(__last),
- __result));
+ return std::__copy_move_a2<__is_move_iterator<_II>::__value>
+ (std::__miter_base(__first), std::__miter_base(__last), __result);
}
#if __cplusplus >= 201103L
@@ -482,7 +481,7 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
__glibcxx_function_requires(_InputIteratorConcept<_II>)
__glibcxx_function_requires(_OutputIteratorConcept<_OI,
typename iterator_traits<_II>::value_type>)
- __glibcxx_requires_valid_range(__first, __last);
+ __glibcxx_requires_can_increment_range(__first, __last, __result);
return std::__copy_move_a2(std::__miter_base(__first),
std::__miter_base(__last), __result);
@@ -627,11 +626,10 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
__glibcxx_function_requires(_ConvertibleConcept<
typename iterator_traits<_BI1>::value_type,
typename iterator_traits<_BI2>::value_type>)
- __glibcxx_requires_valid_range(__first, __last);
+ __glibcxx_requires_can_decrement_range(__first, __last, __result);
- return (std::__copy_move_backward_a2<__is_move_iterator<_BI1>::__value>
- (std::__miter_base(__first), std::__miter_base(__last),
- __result));
+ return std::__copy_move_backward_a2<__is_move_iterator<_BI1>::__value>
+ (std::__miter_base(__first), std::__miter_base(__last), __result);
}
#if __cplusplus >= 201103L
@@ -663,7 +661,7 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
__glibcxx_function_requires(_ConvertibleConcept<
typename iterator_traits<_BI1>::value_type,
typename iterator_traits<_BI2>::value_type>)
- __glibcxx_requires_valid_range(__first, __last);
+ __glibcxx_requires_can_decrement_range(__first, __last, __result);
return std::__copy_move_backward_a2(std::__miter_base(__first),
std::__miter_base(__last),
diff --git a/libstdc++-v3/include/debug/debug.h b/libstdc++-v3/include/debug/debug.h
index bddaa1c..f157a6d 100644
--- a/libstdc++-v3/include/debug/debug.h
+++ b/libstdc++-v3/include/debug/debug.h
@@ -63,6 +63,8 @@ namespace __gnu_debug
# define __glibcxx_requires_cond(_Cond,_Msg)
# define __glibcxx_requires_valid_range(_First,_Last)
# define __glibcxx_requires_can_increment(_First,_Size)
+# define __glibcxx_requires_can_increment_range(_First1,_Last1,_First2)
+# define __glibcxx_requires_can_decrement_range(_First1,_Last1,_First2)
# define __glibcxx_requires_sorted(_First,_Last)
# define __glibcxx_requires_sorted_pred(_First,_Last,_Pred)
# define __glibcxx_requires_sorted_set(_First1,_Last1,_First2)
@@ -89,6 +91,10 @@
Re: [PATCH] Document usage of line number 0 in dg-{warning,error,message,bogus} directives
On 06/06/2018 11:32 AM, Jozef Lawrynowicz wrote:
> For the dg-{warning,error,message,bogus} directives, a value of 0 for the line
>
> argument can be passed to specify that the message is not associated with any
>
> line. This patch documents that in the Directives section of the
> documentation.
>
> Ok for trunk?
>
>
> 0001-Document-usage-of-line-number-0-in-dg-warning-error-.patch
>
>
> From d08160770abef420b6699f6bd2c30a055bd10350 Mon Sep 17 00:00:00 2001
> From: Jozef Lawrynowicz
> Date: Wed, 6 Jun 2018 18:20:56 +0100
> Subject: [PATCH] Document usage of line number 0 in
> dg-{warning,error,message,bogus} directives
>
> 2018-06-06 Jozef Lawrynowicz
>
> * gcc/doc/sourcebuild.texi: Document usage of line number 0 in verify
> compiler messages directives.
OK.
jeff
Re: libgo patch committed: Add riscv and js/wasm
On Mon, 11 Jun 2018 12:16:39 PDT (-0700), i...@golang.org wrote: This libgo patch add riscv and js/wasm as known targets. This incorporates cut down versions of https://golang.org/cl/102835 and https://golang.org/cl/106256 from the master sources. This will tell the go/build to skip files with those tags. Bootstrapped and ran Go testsuite on x86_64-pc-linux-gnu. Committed to mainline. [...] --- libgo/goarch.sh (revision 261203) +++ libgo/goarch.sh (working copy) @@ -153,6 +153,11 @@ case $goarch in ;; esac ;; +riscv) + family=RISCV + pcquantum=2 + ptrsize=4 + ;; riscv64) family=RISCV64 pcquantum=2 I don't know anything about Go, but we've generally been calling the RISC-V architectures "riscv32" and "riscv64" as opposed to "riscv" and "riscv64", with the idea being that it's a bit more explicit. Technically, RISC-V is the name of a family of ISAs, with "RV32I" and "RV64I" being two base ISAs so this also matches the ISA's naming scheme. Obviously this isn't a big deal, I just saw the patch go by and thought I'd bring it up.
[patch, fortran] Handling of .and. and .or. expressions
Hello world,
the attached patch introduces the following changes:
If a logical .and. or .or. expression contains a reference to a function
which is impure and which also does not behave like a pure function
(i.e. does not have the implicit_pure attribute set), it emits a
warning with -Wsurprising that the function might not be evaluated.
(-Wsurprising is enabled by -Wall).
It special cases the idiom if (associated(m) .and. m%t) which
people appear to use.
And, if there is an expression like func() .and. flag , it
reverses the test as an optimization. The middle end should be
capable of doing this, but apparently it doesn't, so the front
end might as well do this.
What it does not do is one part of PR 57160, i.e. warn against
if (a /= 0 .and. 1/a > 5) which people who are used to C might
also like to write.
There is already quite some discussion in the PRs, especially 85599,
where not all people were of the same opinion. Let us see where the
discussion here leads us.
Regression-tested (which found one bug in the testsuite).
OK for trunk?
Regards
Thomas
2018-06-11 Thomas Koenig
PR fortran/57160
PR fortran/85599
* dump-parse-tree (show_attr): Add handling of implicit_pure.
* resolve.c (impure_function_callback): New function.
(resolve_operator): Call it vial gfc_expr_walker. Special-case
if (associated(m) .and. m%t). If an .and. or .or. expression
has a function or a non-function, exchange the operands.
2018-06-11 Thomas Koenig
PR fortran/57160
PR fortran/85599
* gfortran.dg/logical_evaluation_1.f90: New test.
* gfortran.dg/alloc_comp_default_init_2.f90: Fix code which
implicitly depends on short-circuiting.
Index: fortran/dump-parse-tree.c
===
--- fortran/dump-parse-tree.c (Revision 261388)
+++ fortran/dump-parse-tree.c (Arbeitskopie)
@@ -716,6 +716,8 @@ show_attr (symbol_attribute *attr, const char * mo
fputs (" ELEMENTAL", dumpfile);
if (attr->pure)
fputs (" PURE", dumpfile);
+ if (attr->implicit_pure)
+fputs (" IMPLICIT_PURE", dumpfile);
if (attr->recursive)
fputs (" RECURSIVE", dumpfile);
Index: fortran/resolve.c
===
--- fortran/resolve.c (Revision 261388)
+++ fortran/resolve.c (Arbeitskopie)
@@ -3807,7 +3807,43 @@ lookup_uop_fuzzy (const char *op, gfc_symtree *uop
return gfc_closest_fuzzy_match (op, candidates);
}
+/* Callback finding an impure function as an operand to an .and. or
+ .or. expression. Remember the last function warned about to
+ avoid double warnings when recursing. */
+static int
+impure_function_callback (gfc_expr **e, int *walk_subtrees ATTRIBUTE_UNUSED,
+ void *data)
+{
+ gfc_expr *f = *e;
+ const char *name;
+ static gfc_expr *last = NULL;
+ bool *found = (bool *) data;
+
+ if (f->expr_type == EXPR_FUNCTION)
+{
+ *found = 1;
+ if (f != last && !pure_function (f, ))
+ {
+ /* This could still be a function without side effects, i.e.
+ implicit pure. Do not warn for that case. */
+ if (f->symtree == NULL || f->symtree->n.sym == NULL
+ || !gfc_implicit_pure (f->symtree->n.sym))
+ {
+ if (name)
+ gfc_warning (OPT_Wsurprising, "Impure function %qs at %L "
+ "might not be evaluated", name, >where);
+ else
+ gfc_warning (OPT_Wsurprising, "Impure function at %L "
+ "might not be evaluated", >where);
+ }
+ }
+ last = f;
+}
+
+ return 0;
+}
+
/* Resolve an operator expression node. This can involve replacing the
operation with a user defined function call. */
@@ -3910,6 +3946,8 @@ resolve_operator (gfc_expr *e)
case INTRINSIC_NEQV:
if (op1->ts.type == BT_LOGICAL && op2->ts.type == BT_LOGICAL)
{
+ bool dont_move = false;
+
e->ts.type = BT_LOGICAL;
e->ts.kind = gfc_kind_max (op1, op2);
if (op1->ts.kind < e->ts.kind)
@@ -3916,6 +3954,53 @@ resolve_operator (gfc_expr *e)
gfc_convert_type (op1, >ts, 2);
else if (op2->ts.kind < e->ts.kind)
gfc_convert_type (op2, >ts, 2);
+
+ if (e->value.op.op == INTRINSIC_AND || e->value.op.op == INTRINSIC_OR)
+ {
+ bool op1_f, op2_f;
+
+ op1_f = false;
+ op2_f = false;
+ gfc_expr_walker (, impure_function_callback, _f);
+ gfc_expr_walker (, impure_function_callback, _f);
+
+ /* Some people code which depends on the short-circuiting that
+ Fortran does not provide, such as
+
+ if (associated(m) .and. m%t) then
+
+ So, warn about this idiom. However, avoid breaking
+ it on purpose. */
+
+ if (op1->expr_type == EXPR_FUNCTION && op1->value.function.isym
+ && op1->value.function.isym->id == GFC_ISYM_ASSOCIATED)
+ {
+ gfc_expr *e = op1->value.function.actual->expr;
+ gfc_expr *en = op1->value.function.actual->next->expr;
+ if (en == NULL && gfc_check_dependency (e, op2,
Re: [PATCH] add missing @opindex to Warning Options
On 06/07/2018 09:21 PM, Eric Gallager wrote: > On 6/7/18, Martin Sebor wrote: >> A bunch of warning options are missing an @opindex entry, >> usually for the negative form. I went through them all >> and added them where it made sense. >> >> Unless there are objections I will commit the patch to >> trunk next week. >> >> I think the patch is also appropriate for release branches >> (modulo options that don't exist there), so likewise, unless >> Jakub or Richard feel differently I will backport it to GCC >> 6 and 7. >> >> Martin >> > > There's a 'p' missing in "Wno-openm-simd" which looks like is being > propagated by copying and pasting OK with that fixed. jeff
Re: [PATCH] Come up with Deprecated option flag.
On 06/08/2018 05:09 AM, Martin Liška wrote: > Hi. > > First follow-up MPX removal patch comes up with Deprecated option flag. > That prints warning for options that have no effect: > > $ ./xgcc -B. /tmp/main.c -Wchkp -static-libmpxwrappers > xgcc: warning: deprecated command line option ‘-static-libmpxwrappers’ > cc1: warning: deprecated command line option ‘-Wchkp’ > > Is the string OK, or? > > Patch can bootstrap on x86_64-linux-gnu and survives regression tests. > > Ready to be installed? > Martin > > > 0001-Come-up-with-Deprecated-option-flag.patch > > > From 0b1473e517373386e674c6736de5007960138d03 Mon Sep 17 00:00:00 2001 > From: marxin > Date: Fri, 8 Jun 2018 10:52:23 +0200 > Subject: [PATCH] Come up with Deprecated option flag. > > gcc/ChangeLog: > > 2018-06-08 Martin Liska > > * config/i386/i386.opt: Make MPX-related options as Deprecated. > * opt-functions.awk: Handle Deprecated flag. > * opts-common.c (decode_cmdline_option): Handle cl_deprecated > and report error. > (read_cmdline_option): Report warning for a deprecated option. > * opts.h (struct cl_option): Add new field cl_deprecated. > (CL_ERR_DEPRECATED): New. > > gcc/c-family/ChangeLog: > > 2018-06-08 Martin Liska > > * c.opt: Make MPX-related options as Deprecated. > > gcc/testsuite/ChangeLog: > > 2018-06-08 Martin Liska > > * g++.dg/opt/mpx.C: New test. > * gcc.target/i386/mpx.c: New test. OK. jeff
libgo patch committed: Add riscv and js/wasm
This libgo patch add riscv and js/wasm as known targets. This
incorporates cut down versions of https://golang.org/cl/102835 and
https://golang.org/cl/106256 from the master sources. This will tell
the go/build to skip files with those tags. Bootstrapped and ran Go
testsuite on x86_64-pc-linux-gnu. Committed to mainline.
Ian
Index: gcc/go/gofrontend/MERGE
===
--- gcc/go/gofrontend/MERGE (revision 261284)
+++ gcc/go/gofrontend/MERGE (working copy)
@@ -1,4 +1,4 @@
-3ec698690d2a8ecbf115489f17d85e848a2f7293
+bfe3a9b26c8b2e1b9ef34a7232a2d1529e639bbf
The first line of this file holds the git revision number of the last
merge done from the gofrontend repository.
Index: libgo/configure.ac
===
--- libgo/configure.ac (revision 261203)
+++ libgo/configure.ac (working copy)
@@ -224,10 +224,10 @@ AC_SUBST(USE_DEJAGNU)
# - libgo/go/syscall/endian_XX.go
# - possibly others
# - possibly update files in libgo/go/internal/syscall/unix
-ALLGOARCH="386 alpha amd64 amd64p32 arm armbe arm64 arm64be ia64 m68k mips
mipsle mips64 mips64le mips64p32 mips64p32le nios2 ppc ppc64 ppc64le riscv64
s390 s390x sh shbe sparc sparc64"
+ALLGOARCH="386 alpha amd64 amd64p32 arm armbe arm64 arm64be ia64 m68k mips
mipsle mips64 mips64le mips64p32 mips64p32le nios2 ppc ppc64 ppc64le riscv
riscv64 s390 s390x sh shbe sparc sparc64 wasm"
# All known GOARCH family values.
-ALLGOARCHFAMILY="I386 ALPHA AMD64 ARM ARM64 IA64 M68K MIPS MIPS64 NIOS2 PPC
PPC64 RISCV64 S390 S390X SH SPARC SPARC64"
+ALLGOARCHFAMILY="I386 ALPHA AMD64 ARM ARM64 IA64 M68K MIPS MIPS64 NIOS2 PPC
PPC64 RISCV RISCV64 S390 S390X SH SPARC SPARC64 WASM"
GOARCH=unknown
case ${host} in
Index: libgo/go/go/build/syslist.go
===
--- libgo/go/go/build/syslist.go(revision 261203)
+++ libgo/go/go/build/syslist.go(working copy)
@@ -4,5 +4,5 @@
package build
-const goosList = "aix android darwin dragonfly freebsd linux nacl netbsd
openbsd plan9 solaris windows zos "
-const goarchList = "386 amd64 amd64p32 arm armbe arm64 arm64be alpha m68k
ppc64 ppc64le mips mipsle mips64 mips64le mips64p32 mips64p32le nios2 ppc
riscv64 s390 s390x sh shbe sparc sparc64"
+const goosList = "aix android darwin dragonfly freebsd js linux nacl netbsd
openbsd plan9 solaris windows zos "
+const goarchList = "386 amd64 amd64p32 arm armbe arm64 arm64be alpha m68k
ppc64 ppc64le mips mipsle mips64 mips64le mips64p32 mips64p32le nios2 ppc riscv
riscv64 s390 s390x sh shbe sparc sparc64 wasm "
Index: libgo/go/go/types/sizes.go
===
--- libgo/go/go/types/sizes.go (revision 261203)
+++ libgo/go/go/types/sizes.go (working copy)
@@ -167,6 +167,7 @@ var gcArchSizes = map[string]*StdSizes{
"ppc64":{8, 8},
"ppc64le": {8, 8},
"s390x":{8, 8},
+ "wasm": {8, 8},
// When adding more architectures here,
// update the doc string of SizesFor below.
}
@@ -176,7 +177,7 @@ var gcArchSizes = map[string]*StdSizes{
//
// Supported architectures for compiler "gc":
// "386", "arm", "arm64", "amd64", "amd64p32", "mips", "mipsle",
-// "mips64", "mips64le", "ppc64", "ppc64le", "s390x".
+// "mips64", "mips64le", "ppc64", "ppc64le", "s390x", "wasm".
func SizesFor(compiler, arch string) Sizes {
var m map[string]*StdSizes
switch compiler {
Index: libgo/goarch.sh
===
--- libgo/goarch.sh (revision 261203)
+++ libgo/goarch.sh (working copy)
@@ -153,6 +153,11 @@ case $goarch in
;;
esac
;;
+riscv)
+ family=RISCV
+ pcquantum=2
+ ptrsize=4
+ ;;
riscv64)
family=RISCV64
pcquantum=2
@@ -198,6 +203,10 @@ case $goarch in
defaultphyspagesize=8192
pcquantum=4
;;
+wasm)
+ family=WASM
+ defaultphyspagesize=65536
+ ;;
*)
echo 1>&2 "unrecognized goarch value \"$goarch\""
exit 1
Re: [PING] [PATCH] Add a comma to comment in lower_eh_constructs_2
On 06/04/2018 12:56 AM, Zhouyi Zhou wrote: > Hi, >Following patch has not been reviewed for two weeks. I think the > patch is trivial, > it doesn't affect other parts of GCC. > >https://gcc.gnu.org/ml/gcc-patches/2018-05/msg01005.html > >And I don't have write permission to GCC > Thanks > Zhouyi > On Mon, May 21, 2018 at 12:09 PM, Zhouyi Zhou wrote: >> Hi >> >> I think the comment in lower_eh_constructs_2 need a comma. >> >> And I don't have write permission to GCC. >> >> Bootstraped on x86-64 >> >> Thanks, >> Zhouyi >> >> Signed-off-by: Zhouyi Zhou >> >> gcc/ChangeLog: >> >> 2018-05-21 Zhouyi Zhou >> * tree-eh.c (lower_eh_constructs_2): Add a comma to comment. Installed on the trunk. Sorry for the delay. jeff
Re: C++ PATCH for c++/86063, ICE with attribute with pack expansion
On Wed, Jun 6, 2018 at 5:18 PM, Marek Polacek wrote: > We crash on this testcase containing a bogus attribute, because > cp_check_const_attributes accessed TREE_VALUE of a tree that happened to be > expr_pack_expansion. Since here we're merely trying to evaluate constexpr > arguments, I thought we could skip such bogus arguments. Hmm, attributes should always be a TREE_LIST, lots of places assume that. Why isn't the pack expansion wrapped in a TREE_LIST? Jason
Re: RFA (symtab): PATCH to symtab_node::nonzero_address DECL_COMDAT handling for c++/80485
On 06/05/2018 12:56 AM, Jason Merrill wrote: > On Thu, May 24, 2018 at 11:36 PM, Jeff Law wrote: >> On 05/19/2018 07:07 AM, Jason Merrill wrote: >>> A comment earlier in in nonzero_address says, "Important case of WEAK >>> we want to do well are comdats. Those are handled by later check for >>> definition." But in this case we aren't handling this comdat function >>> well, we return false because it is DECL_WEAK and DECL_EXTERNAL >>> (because we aren't at EOF yet) and so we fail to fold the comparison. >>> >>> This patch fixes the testcase by checking DECL_COMDAT directly. >>> >>> Tested x86_64-pc-linux-gnu. OK for trunk? >>> >>> >>> 80485.diff >>> >>> >>> commit a1a0c12db660aa94a625771a9f2fa9db30a552fe >>> Author: Jason Merrill >>> Date: Fri May 18 20:20:05 2018 -0400 >>> >>> PR c++/80485 - inline function non-zero address. >>> >>> * symtab.c (nonzero_address): Check DECL_COMDAT. >> OK > > For GCC 8 as well? Yea. jeff
Re: [PATCH] ltmain.sh: Sort input file list
On 06/11/2018 11:06 AM, Joseph Myers wrote: > If we're not doing a general update from upstream libtool, I think we > should use the upstream ltmain.sh fix (libtool commit > 74c8993c178a1386ea5e2363a01d919738402f30, it looks like), or follow it as > close as possible, rather than having our own variant. > Agreed. My preference would be to get the various libtool, autoconf and friends updated from the appropriate upstream projects. jeff
Re: [Patch, Fortran, F08] PR 45521: GENERIC resolution with ALLOCATABLE/POINTER and PROCEDURE
2018-06-11 19:49 GMT+02:00 Steve Kargl : > On Mon, Jun 11, 2018 at 05:05:17PM +0200, Janus Weil wrote: >> >> the attached patch fixes two remaining problems with the resolution of >> generic functions with POINTER and ALLOCATABLE arguments in F08 >> (coments 16 & 17 in the PR): >> * it deals with an INTENT(IN) condition that was added in an IR >> * it deals with polymorphic arguments, which were mistreated previously. >> >> The patch regtests cleanly on x86_64-linux-gnu. Ok for trunk? >> > > Yes. Thanks for the patch. Thanks for the review, Steve. Committed as r261448. Cheers, Janus
Re: [PATCH] handle non-constant character assignments in strlen (PR 86083)
On 06/11/2018 12:06 PM, Martin Sebor wrote: > On 06/11/2018 01:20 AM, Marc Glisse wrote: >> On Sun, 10 Jun 2018, Martin Sebor wrote: >> >>> The attached patch implements this idea. (I looked for a simple >>> function that returns true/false based on whether a SSA_NAME is >>> or isn't definitely non-zero but couldn't find one so I created >>> one though it seems that extending one of the existing functions >>> might be a better approach?) >> >> tree_expr_nonzero_p (don't know why the comment above talks about >> addresses), expr_not_equal_to. > > Thanks for the pointer! These are just what I was looking for. > (I wonder if either a better naming convention or grouping all > the declarations together in the same header would make them > easier to find.) > > Attached is a simplified (virtually trivial) patch that uses > tree_expr_nonzero_p instead, retested on x86_64-linux. > > Martin > > gcc-86083.diff > > > PR tree-optimization/86083 - handle non-constant assignments in strlen > > gcc/ChangeLog: > > PR tree-optimization/86083 > * tree-ssa-strlen.c (handle_char_store): Use ree_expr_nonzero_p. s/ree/tree/ > > gcc/testsuite/ChangeLog: > > PR tree-optimization/86083 > * gcc.dg/strlenopt-44.c: New test. OK with the ChangeLog nit fixed. jeff
Re: [PATCH][Aarch64] v2: Arithmetic overflow addv patterns [Patch 2/4]
Michael Collison writes:
> +(define_expand "uaddv4"
> + [(match_operand:GPI 0 "register_operand")
> + (match_operand:GPI 1 "register_operand")
> + (match_operand:GPI 2 "register_operand")
> + (label_ref (match_operand 3 "" ""))]
> + ""
> +{
> + emit_insn (gen_add3_compareC (operands[0], operands[1],
> operands[2]));
> + aarch64_gen_unlikely_cbranch (NE, CC_Cmode, operands[3]);
> +
> + DONE;
> +})
> +
> +
Nit: stray extra line.
> (define_expand "addti3"
>[(set (match_operand:TI 0 "register_operand" "")
> (plus:TI (match_operand:TI 1 "register_operand" "")
> - (match_operand:TI 2 "register_operand" "")))]
> + (match_operand:TI 2 "aarch64_reg_or_imm" "")))]
>""
> {
> - rtx low = gen_reg_rtx (DImode);
> - emit_insn (gen_adddi3_compareC (low, gen_lowpart (DImode, operands[1]),
> - gen_lowpart (DImode, operands[2])));
> + rtx low_dest,op1_low,op2_low,high_dest,op1_high,op2_high;
Spaces after commas (sorry)
[...]
> @@ -1837,10 +1946,70 @@
>[(set_attr "type" "alus_sreg")]
> )
>
> +;; Note that since we're sign-extending, match the immediate in GPI
> +;; rather than in DWI. Since CONST_INT is modeless, this works fine.
> +(define_insn "*add3_compareV_cconly_imm"
> + [(set (reg:CC_V CC_REGNUM)
> + (compare:CC_V
> + (plus:
> + (sign_extend: (match_operand:GPI 0 "register_operand" "r,r"))
> + (match_operand:GPI 1 "aarch64_plus_immediate" "I,J"))
> + (sign_extend: (plus:GPI (match_dup 0) (match_dup 1)]
Real reason for replying is: this is a neat trick, but I think it's
only an accident that genrecog doesn't reject the mode on operand 1.
PLUSes can't have mismatched modes since since rtl doesn't have the
sign information to do a conversion.
IMO we should use a similar structure to the zero_extends:
(plus:
(zero_extend: (match_operand:GPI 0 "register_operand" "r,r"))
(match_operand: 1 "const_scalar_int_operand" ""))
(sign_extend:
(plus:GPI
(match_dup 0)
(match_operand:GPI 2 "aarch64_plus_immediate" "I,J")
but with the simpler check:
INTVAL (operands[1]) == INTVAL (operands[2])
Thanks,
Richard
Re: [PATCH] ltmain.sh: Sort input file list
On 2018-06-11 17:06, Joseph Myers wrote: > If we're not doing a general update from upstream libtool, I think we > should use the upstream ltmain.sh fix (libtool commit > 74c8993c178a1386ea5e2363a01d919738402f30, it looks like), or follow it as > close as possible, rather than having our own variant. right. Either variant should be fine. Cherry-picking it, is the safe variant.
C++ PATCH for c++/86094, wrong calling convention for move-only class
The fix for 80178 was broken, because I forgot that copy_fn_p is false
for move constructors. As a result, the calling convention for a
class with a trivial move constructor and deleted copy constructor
changed inappropriately.
Tested x86_64-pc-linux-gnu, applying to trunk and 8.
commit d6cc7705f626778cb7e19fccf90117e7ed47d794
Author: Jason Merrill
Date: Mon Jun 11 12:14:27 2018 -0400
PR c++/86094 - wrong code with defaulted move ctor.
* tree.c (type_has_nontrivial_copy_init): Fix move ctor handling.
diff --git a/gcc/cp/tree.c b/gcc/cp/tree.c
index bbbda7e98b6..156d1e469c6 100644
--- a/gcc/cp/tree.c
+++ b/gcc/cp/tree.c
@@ -4135,7 +4135,7 @@ type_has_nontrivial_copy_init (const_tree type)
for (ovl_iterator iter (CLASSTYPE_CONSTRUCTORS (t)); iter; ++iter)
{
tree fn = *iter;
- if (copy_fn_p (fn))
+ if (copy_fn_p (fn) || move_fn_p (fn))
{
saw_copy = true;
if (!DECL_DELETED_FN (fn))
diff --git a/gcc/testsuite/g++.dg/abi/invisiref2.C b/gcc/testsuite/g++.dg/abi/invisiref2.C
new file mode 100644
index 000..592d212ab11
--- /dev/null
+++ b/gcc/testsuite/g++.dg/abi/invisiref2.C
@@ -0,0 +1,14 @@
+// PR c++/86094
+// { dg-do compile { target c++11 } }
+// { dg-additional-options "-Wabi=11 -fdump-tree-gimple" }
+// { dg-final { scan-tree-dump-not "struct S &" "gimple" } }
+
+struct S {
+ S(S&&) = default;
+ int i;
+};
+
+S foo(S s)
+{
+ return s;
+}
Re: [PATCH] update Zero-length array documentation
Martin Sebor writes:
> @@ -1553,12 +1553,28 @@ struct line *thisline = (struct line *)
> thisline->length = this_length;
> @end smallexample
>
> -In ISO C90, you would have to give @code{contents} a length of 1, which
> -means either you waste space or complicate the argument to @code{malloc}.
> +Although the size of a zero-length array is zero, an array member of
> +this kind may increase the size the enclosing type as a result of tail
> +padding. The offset of a zero-length array member from the beginning
> +of the enclosing structure is the same as the offset of an array with
> +one or more elements of the same type. The alignment of a zero-length
> +array is the same as the alignment of its elements.
>
> -In ISO C99, you would use a @dfn{flexible array member}, which is
> -slightly different in syntax and semantics:
> +Declaring zero-length arrays in other contexts, including as interior
> +members of structure objects or as non-member objects is discouraged.
> +Accessing elements of zero-length arrays declared in such contexts is
> +undefined and may be diagnosed.
>
> +In the absence of the zero-length array extension, in ISO C90 the
> +@code{contents} array in the example above would typically be declared
> +to have a single element. Although this technique is discouraged, GCC
> +handles trailing one-element array members similarly to zero-length
> +arrays.
This last sentence seems a bit vague. E.g. GCC should never diagnose
an access to element 0 of a 1-element trailing array, whereas (like you
say above) it might for zero-length trailing arrays.
Thanks,
Richard
Re: [PATCH] handle non-constant character assignments in strlen (PR 86083)
On 06/11/2018 01:20 AM, Marc Glisse wrote:
On Sun, 10 Jun 2018, Martin Sebor wrote:
The attached patch implements this idea. (I looked for a simple
function that returns true/false based on whether a SSA_NAME is
or isn't definitely non-zero but couldn't find one so I created
one though it seems that extending one of the existing functions
might be a better approach?)
tree_expr_nonzero_p (don't know why the comment above talks about
addresses), expr_not_equal_to.
Thanks for the pointer! These are just what I was looking for.
(I wonder if either a better naming convention or grouping all
the declarations together in the same header would make them
easier to find.)
Attached is a simplified (virtually trivial) patch that uses
tree_expr_nonzero_p instead, retested on x86_64-linux.
Martin
PR tree-optimization/86083 - handle non-constant assignments in strlen
gcc/ChangeLog:
PR tree-optimization/86083
* tree-ssa-strlen.c (handle_char_store): Use ree_expr_nonzero_p.
gcc/testsuite/ChangeLog:
PR tree-optimization/86083
* gcc.dg/strlenopt-44.c: New test.
Index: gcc/tree-ssa-strlen.c
===
--- gcc/tree-ssa-strlen.c (revision 261363)
+++ gcc/tree-ssa-strlen.c (working copy)
@@ -3069,9 +3069,7 @@ handle_char_store (gimple_stmt_iterator *gsi)
}
bool storing_zero_p = initializer_zerop (rhs);
- bool storing_nonzero_p = (!storing_zero_p
- && TREE_CODE (rhs) == INTEGER_CST
- && integer_nonzerop (rhs));
+ bool storing_nonzero_p = !storing_zero_p && tree_expr_nonzero_p (rhs);
/* Set to the length of the string being assigned if known. */
HOST_WIDE_INT rhslen;
Index: gcc/testsuite/gcc.dg/strlenopt-44.c
===
--- gcc/testsuite/gcc.dg/strlenopt-44.c (nonexistent)
+++ gcc/testsuite/gcc.dg/strlenopt-44.c (working copy)
@@ -0,0 +1,92 @@
+/* PR tree-optimization/86083 - handle non-constant assignments in strlen
+ { dg-do compile }
+ { dg-options "-O2 -Wall -fdump-tree-optimized" } */
+
+#include "range.h"
+#include "strlenopt.h"
+
+#define CAT(x, y) x ## y
+#define CONCAT(x, y) CAT (x, y)
+#define FAILNAME(name) CONCAT (call_ ## name ##_on_line_, __LINE__)
+
+#define FAIL(name) do {\
+extern void FAILNAME (name) (void); \
+FAILNAME (name)();\
+ } while (0)
+
+/* Macro to emit a call to funcation named
+ call_in_true_branch_not_eliminated_on_line_NNN()
+ for each call that's expected to be eliminated. The dg-final
+ scan-tree-dump-time directive at the bottom of the test verifies
+ that no such call appears in output. */
+#define ASSERT_ELIM(expr) \
+ if (!(expr)) FAIL (in_true_branch_not_eliminated); else (void)0
+
+/* Macro to emit a call to a function named
+ call_made_in_{true,false}_branch_on_line_NNN()
+ for each call that's expected to be retained. The dg-final
+ scan-tree-dump-time directive at the bottom of the test verifies
+ that the expected number of both kinds of calls appears in output
+ (a pair for each line with the invocation of the KEEP() macro. */
+#define ASSERT_KEEP(expr) \
+ if (expr) \
+FAIL (made_in_true_branch); \
+ else \
+FAIL (made_in_false_branch)
+
+
+#define ELIM(init, i, c, res) \
+ do { \
+char a[] = init;\
+a[i] = c; \
+ASSERT_ELIM (strlen (a) == res); \
+ } while (0)
+
+#define KEEP(init, i, c, res) \
+ do { \
+char a[] = init;\
+a[i] = c; \
+ASSERT_KEEP (strlen (a) == res); \
+ } while (0)
+
+
+void test_elim_range (char c)
+{
+ ELIM ("1", 0, UR (1, 2), 1);
+ ELIM ("1", 0, UR (1, 127), 1);
+ ELIM ("1", 0, UR ('0', '9'), 1);
+
+ ELIM ("12", 0, UR (1, 127), 2);
+ ELIM ("12", 1, UR (1, 127), 2);
+
+ ELIM ("123", 0, UR (1, 9), 3);
+ ELIM ("123", 1, UR (10, 99), 3);
+ ELIM ("123", 2, UR (100, 127), 3);
+}
+
+void test_elim_anti_range (const char *s)
+{
+ char c = *s++;
+ ELIM ("123", 0, c ? c : 'x', 3);
+
+ c = *s++;
+ ELIM ("1234", 1, c ? c : 'y', 4);
+
+ c = *s++;
+ ELIM ("123", 2, c ? c : 'z', 3);
+}
+
+#line 1000
+
+void test_keep (void)
+{
+ size_t uchar_max = (unsigned char)-1;
+
+ KEEP ("1", 0, UR (1, uchar_max + 1), 1);
+ KEEP ("1\0\3", 1, UR (1, 2), 1);
+}
+
+/* { dg-final { scan-tree-dump-times "call_in_true_branch_not_eliminated_" 0 "optimized" } }
+
+ { dg-final { scan-tree-dump-times "call_made_in_true_branch_on_line_1\[0-9\]\[0-9\]\[0-9\]" 2 "optimized" } }
+ { dg-final { scan-tree-dump-times "call_made_in_false_branch_on_line_1\[0-9\]\[0-9\]\[0-9\]" 2 "optimized" } } */
Re: [PATCH] PR fortran/68544 -- Issue error for derived type used as actual arg
Hi Steve, The attach patch fixes an ICE that occurs when a user uses a derived type as an actual argument to subprogram. Regression tested on x86_64-*-freebsd and i586-*-freebsd. OK to commit? OK. Thanks!
Re: [Patch, Fortran, F08] PR 45521: GENERIC resolution with ALLOCATABLE/POINTER and PROCEDURE
On Mon, Jun 11, 2018 at 05:05:17PM +0200, Janus Weil wrote: > > the attached patch fixes two remaining problems with the resolution of > generic functions with POINTER and ALLOCATABLE arguments in F08 > (coments 16 & 17 in the PR): > * it deals with an INTENT(IN) condition that was added in an IR > * it deals with polymorphic arguments, which were mistreated previously. > > The patch regtests cleanly on x86_64-linux-gnu. Ok for trunk? > Yes. Thanks for the patch. -- Steve
Re: [PATCH] Avoid excessive function type casts with splay-trees part 2
On Fri, 2018-06-08 at 20:41 +, Bernd Edlinger wrote: > On 06/08/18 16:28, David Malcolm wrote: > > On Fri, 2018-06-08 at 14:03 +, Bernd Edlinger wrote: > > > Hi! > > > > > > > > > This patch converts the splay-tree internals into a template, and > > > makes > > > the typed_splay_tree template really type-safe. Previously > > > everything > > > would break apart if KEY_TYPE or VALUE_TYPE would not be pointer > > > types. > > > This limitation is now removed. > > > > > > I took the freedom to add a remove function which is only for > > > completeness and test coverage, but not (yet) used in a > > > productive > > > way. > > > > > > > > > Bootstrapped and reg-tested on x86_64-linux-gnu. > > > Is it OK for trunk? > > > > Was this testing done with "jit" enabled? (there's some usage of > > typed_splay_tree there, for jit's equivalent of switch statements) > > > > Note that the jit frontend isn't covered by "all" in --enable- > > languages; it has to be added manually, iirc since it requires -- > > enable-host-shared. > > > > Yes, good point. I repeated the test with --enable-host-shared > and all jit tests did pass. Thanks! Dave
PING 2 [PATCH] restore -Wstringop-overflow for checked strcpy/strcat (PR 85259)
Ping: https://gcc.gnu.org/ml/gcc-patches/2018-05/msg00652.html On 06/05/2018 01:58 PM, Martin Sebor wrote: Ping: https://gcc.gnu.org/ml/gcc-patches/2018-05/msg00652.html On 05/14/2018 04:41 PM, Martin Sebor wrote: r256683 committed to GCC 8 to avoiding duplicate instances of -Wstringop-overflow warnings on some targets has the unintended side-effect of suppressing even singleton instances of the warning in cases such as 'strcat (strcpy (buf, "hello "), "world!")' when _FORTIFY_SOURCE is defined. The attached patch restores the warning for the trunk. Since this is a regression in a security feature and the warning isn't prone to false positives (I don't think I've seen any when _FORTIFY_SOURCE is defined), I'd also like the fix considered for the 8 branch. Thanks Martin
PING 2 [PATCH] relax -Wsizeof-pointer-memaccess for strncpy with size of source (PR 85931)
Ping: https://gcc.gnu.org/ml/gcc-patches/2018-05/msg01698.html On 06/04/2018 05:50 PM, Martin Sebor wrote: Ping: https://gcc.gnu.org/ml/gcc-patches/2018-05/msg01698.html On 05/29/2018 08:57 PM, Martin Sebor wrote: Warning for a strncpy call whose bound is the same as the size of the source and suggesting to use the size of the source is less than helpful when both sizes are the same, as in: char a[4], b[4]; strncpy (a, b, sizeof b); The attached patch suppresses the -Wsizeof-pointer-memaccess warning for these cases. To do that even for VLAs (in some cases), the patch enhances operand_equal_p() to handle SAVE_EXPR to detect when VLA in sizeof VLA refers to the size of a variable-length array. Is this okay for trunk and GCC 8? Martin
PING 3 [PATCH] refine -Wstringop-truncation and -Wsizeof-pointer-memaccess for strncat of nonstrings (PR 85602)
Ping: https://gcc.gnu.org/ml/gcc-patches/2018-05/msg01671.html On 06/04/2018 05:48 PM, Martin Sebor wrote: Ping: https://gcc.gnu.org/ml/gcc-patches/2018-05/msg01671.html (In IRC last week Franz reported successfully testing the patch. Thanks again.) On 05/29/2018 01:21 PM, Martin Sebor wrote: To make review and testing easier (thank you, Franz), attached is an updated patch rebased on top of today's trunk. (Note that the patch intentionally doesn't suppress the warning for the submitted test case without adding the nonstring attribute.) On 05/25/2018 02:59 PM, Martin Sebor wrote: Ping: https://gcc.gnu.org/ml/gcc-patches/2018-05/msg00869.html On 05/17/2018 08:01 PM, Martin Sebor wrote: The -Wstringop-truncation and -Wsizeof-pointer-memaccess warnings I added and enhanced, respectively, in GCC 8 are arguably overly strict for source arguments declared with the nonstring attribute. For example, -Wsizeof-pointer-memaccess triggers for the strncat call below: __attribute__ ((nonstring)) char nonstr[8]; extern char *d; strncat (d, nonstr, sizeof nonstr); even though it's still a fairly common (if unsafe) idiom from the early UNIX days (V7 from 1979 to be exact) where strncat was introduced. (This use case, modulo the attribute, was reduced from coreutils.) Simialrly, -Wstringop-truncation warns for some strcat calls that are actually safe, such as in: strcpy (nonstr, "123"); strncat (d, nonstr, 32); To help with the adoption of the warnings and the attribute and avoid unnecessary churn the attached patch relaxes both warnings to accept code like this without diagnostics. The patch doesn't add any new warnings so I'd like it considered for GCC 8 in addition to trunk. Thanks Martin
PING 3 [PATCH] allow more strncat calls with -Wstringop-truncation (PR 85700)
Ping: https://gcc.gnu.org/ml/gcc-patches/2018-05/msg01189.html On 06/04/2018 05:45 PM, Martin Sebor wrote: Ping: https://gcc.gnu.org/ml/gcc-patches/2018-05/msg01189.html On 05/29/2018 10:19 AM, Martin Sebor wrote: Ping: https://gcc.gnu.org/ml/gcc-patches/2018-05/msg01189.html On 05/22/2018 07:40 PM, Martin Sebor wrote: Here's another small refinement to -Wstringop-truncation to avoid diagnosing more arguably "safe" cases of strncat() that match the expected pattern of strncat (d, s, sizeof d - strlen (d) - 1); such as extern char a[4]; strncat (a, "12", sizeof d - strlen (a) - 1); Since the bound is derived from the length of the destination as GCC documents is the expected use, the call should probably not be diagnosed even though truncation is possible. The trouble with strncat is that it specifies a single count that can be (and has been) used to specify either the remaining space in the destination or the maximum number of characters to append, but not both. It's nearly impossible to tell for certain which the author meant, and if it's safe, hence all this fine-tuning. I suspect this isn't the last tweak, either. In any event, I'd like to commit the patch to both trunk and gcc-8-branch. The bug isn't marked regression but I suppose it could (should) well be considered one. Martin
Re: [PATCH] ltmain.sh: Sort input file list
If we're not doing a general update from upstream libtool, I think we should use the upstream ltmain.sh fix (libtool commit 74c8993c178a1386ea5e2363a01d919738402f30, it looks like), or follow it as close as possible, rather than having our own variant. -- Joseph S. Myers jos...@codesourcery.com
Re: [PATCH] Fix altivec-7 issues on Power 6
On Fri, Jun 08, 2018 at 01:40:02PM -0700, Carl Love wrote:
> diff --git a/gcc/testsuite/gcc.target/powerpc/altivec-37.c
> b/gcc/testsuite/gcc.target/powerpc/altivec-37.c
> new file mode 100644
> index 000..362b6ec
> --- /dev/null
> +++ b/gcc/testsuite/gcc.target/powerpc/altivec-37.c
> @@ -0,0 +1,32 @@
> +/* { dg-do compile { target powerpc*-*-* } } */
> +/* { dg-require-effective-target powerpc_vsx_ok } */
> +/* { dg-options "-mpower8-vector -mvsx" } */
This needs p8vector_ok instead of vsx_ok I think?
Otherwise okay. Thanks!
Segher
Re: [Patch, Fortran] PR25829: Asynchronous I/O
On 2018-06-11 11:24 AM, Rainer Orth wrote: Hi John, On 2018-06-03 2:59 PM, Nicolas Koenig wrote: Since the implementation relies on pthreads, it would be great if somebody could try the patch on non-linux targets, to see whether it causes any problems there. I tried it on hppa64-hp-hpux11.11. The gomp support mostly works on this target. I didn't see any regressions but asynchronous_9 fails: FAIL: libgomp.fortran/asynchronous_9.f90 -O execution test on Solaris, this is due to the test's stack usage, which exeeds the 8 MB default. Maybe the same problem on HP-UX? Yes. Program received signal SIGSEGV, Segmentation fault. 0x40002c7c in MAIN__ () (gdb) disass Dump of assembler code for function MAIN__: 0x40002c70 <+0>: std rp,-10(sp) 0x40002c74 <+4>: addil L%7271000,sp,r1 0x40002c78 <+8>: ldo 160(r1),sp => 0x40002c7c <+12>: std r18,-f8(sp) Store fails after creating 12 MB frame. Dave -- John David Anglin dave.ang...@bell.net
[PATCH] ^d thing (PR85755)
Some of the mov* patterns use ^ and $ constraint modifiers, which mean
give a penalty to this alternative if this operand needs a reload. They
are meant here to give a penalty if a register operand needs reloading
(because it needs to be in a different kind of register), not when a
memory operand needs reloading (which is easy and cheap to do).
This patch fixes the movdi patterns. This fixes PR85755.
The following are changed (name, old constraints, new constraints):
FPR store ^m := d m := ^d
FPR move^d := d ^d := ^d
AVX store ^wY := wb wY := ^wb
AVX store $Z := wvZ := $wv
VSX move^wi := wi ^wi := ^wi
Tested on powerpc64-linux {-m32,-m64}; committing.
Segher
2018-06-11 Segher Boessenkool
* config/rs6000/rs6000.md (*movdi_internal32): Put constraint modifiers
on the correct operand.
(*movdi_internal64): Ditto.
---
gcc/config/rs6000/rs6000.md | 24
1 file changed, 12 insertions(+), 12 deletions(-)
diff --git a/gcc/config/rs6000/rs6000.md b/gcc/config/rs6000/rs6000.md
index a2605a0..f06591f 100644
--- a/gcc/config/rs6000/rs6000.md
+++ b/gcc/config/rs6000/rs6000.md
@@ -8567,16 +8567,16 @@ (define_insn_and_split "reload_gpr_from_vsxsf"
(define_insn "*movdi_internal32"
[(set (match_operand:DI 0 "nonimmediate_operand"
- "=Y,r, r, ^m,^d, ^d,
- r, ^wY, $Z,^wb, $wv,^wi,
+ "=Y,r, r, m, ^d, ^d,
+ r, wY,Z, ^wb, $wv,^wi,
*wo, *wo, *wv, *wi, *wi,*wv,
*wv")
(match_operand:DI 1 "input_operand"
- "r,Y, r, d, m, d,
- IJKnGHF, wb,wv,wY,Z, wi,
- Oj, wM,OjwM, Oj,wM, wS,
- wB"))]
+ "r, Y, r, ^d,m, ^d,
+ IJKnGHF, ^wb, $wv, wY,Z, ^wi,
+ Oj,wM,OjwM, Oj,wM, wS,
+ wB"))]
"! TARGET_POWERPC64
&& (gpc_reg_operand (operands[0], DImode)
@@ -8643,17 +8643,17 @@ (define_split
(define_insn "*movdi_internal64"
[(set (match_operand:DI 0 "nonimmediate_operand"
"=YZ, r, r, r, r, r,
-^m,^d,^d,^wY, $Z, $wb,
+m, ^d,^d,wY,Z, $wb,
$wv, ^wi, *wo, *wo, *wv,*wi,
*wi, *wv, *wv, r, *h, *h,
?*r, ?*wg, ?*r, ?*wj")
(match_operand:DI 1 "input_operand"
-"r,YZ,r, I, L, nF,
- d,m, d, wb,wv, wY,
- Z,wi,Oj,wM,OjwM, Oj,
- wM, wS,wB,*h,r, 0,
- wg, r, wj,r"))]
+ "r, YZ,r, I, L, nF,
+^d,m, ^d,^wb, $wv,wY,
+Z, ^wi, Oj,wM,OjwM, Oj,
+wM,wS,wB,*h,r, 0,
+wg,r, wj,r"))]
"TARGET_POWERPC64
&& (gpc_reg_operand (operands[0], DImode)
--
1.8.3.1
Re: [Patch, Fortran] PR25829: Asynchronous I/O
Hi John, > On 2018-06-03 2:59 PM, Nicolas Koenig wrote: >> Since the implementation relies on pthreads, it would be great if >> somebody could try the patch on non-linux targets, to see whether it >> causes any problems there. > I tried it on hppa64-hp-hpux11.11. The gomp support mostly works on this > target. > > I didn't see any regressions but asynchronous_9 fails: > FAIL: libgomp.fortran/asynchronous_9.f90 -O execution test on Solaris, this is due to the test's stack usage, which exeeds the 8 MB default. Maybe the same problem on HP-UX? Rainer -- - Rainer Orth, Center for Biotechnology, Bielefeld University
Re: [Patch, Fortran] PR25829: Asynchronous I/O
On 2018-06-03 2:59 PM, Nicolas Koenig wrote: Since the implementation relies on pthreads, it would be great if somebody could try the patch on non-linux targets, to see whether it causes any problems there. I tried it on hppa64-hp-hpux11.11. The gomp support mostly works on this target. I didn't see any regressions but asynchronous_9 fails: FAIL: libgomp.fortran/asynchronous_9.f90 -O execution test Dave -- John David Anglin dave.ang...@bell.net
[Patch, Fortran, F08] PR 45521: GENERIC resolution with ALLOCATABLE/POINTER and PROCEDURE
Hi all,
the attached patch fixes two remaining problems with the resolution of
generic functions with POINTER and ALLOCATABLE arguments in F08
(coments 16 & 17 in the PR):
* it deals with an INTENT(IN) condition that was added in an IR
* it deals with polymorphic arguments, which were mistreated previously.
The patch regtests cleanly on x86_64-linux-gnu. Ok for trunk?
Cheers,
Janus
2018-06-11 Janus Weil
PR fortran/45521
* interface.c (compare_ptr_alloc): New function.
(compare_ptr_alloc): Call it.
2018-06-11 Janus Weil
PR fortran/45521
* gfortran.dg/generic_32.f90: New test.
* gfortran.dg/generic_33.f90: New test.
Index: gcc/fortran/interface.c
===
--- gcc/fortran/interface.c (revision 261393)
+++ gcc/fortran/interface.c (working copy)
@@ -1190,6 +1190,24 @@
}
+/* Returns true if two dummy arguments are distinguishable due to their POINTER
+ and ALLOCATABLE attributes according to F2018 section 15.4.3.4.5 (3).
+ The function is asymmetric wrt to the arguments s1 and s2 and should always
+ be called twice (with flipped arguments in the second call). */
+
+static bool
+compare_ptr_alloc(gfc_symbol *s1, gfc_symbol *s2)
+{
+ /* Is s1 allocatable? */
+ const bool a1 = s1->ts.type == BT_CLASS ?
+ CLASS_DATA(s1)->attr.allocatable : s1->attr.allocatable;
+ /* Is s2 a pointer? */
+ const bool p2 = s2->ts.type == BT_CLASS ?
+ CLASS_DATA(s2)->attr.class_pointer : s2->attr.pointer;
+ return a1 && p2 && (s2->attr.intent != INTENT_IN);
+}
+
+
/* Perform the correspondence test in rule (3) of F08:C1215.
Returns zero if no argument is found that satisfies this rule,
nonzero otherwise. 'p1' and 'p2' are the PASS arguments of both procedures
@@ -1233,8 +1251,8 @@
if (f2 != NULL && (compare_type_rank (f1->sym, f2->sym)
|| compare_type_rank (f2->sym, f1->sym))
&& !((gfc_option.allow_std & GFC_STD_F2008)
- && ((f1->sym->attr.allocatable && f2->sym->attr.pointer)
- || (f2->sym->attr.allocatable && f1->sym->attr.pointer
+ && (compare_ptr_alloc(f1->sym, f2->sym)
+ || compare_ptr_alloc(f2->sym, f1->sym
goto next;
/* Now search for a disambiguating keyword argument starting at
@@ -1247,8 +1265,8 @@
sym = find_keyword_arg (g->sym->name, f2_save);
if (sym == NULL || !compare_type_rank (g->sym, sym)
|| ((gfc_option.allow_std & GFC_STD_F2008)
- && ((sym->attr.allocatable && g->sym->attr.pointer)
- || (sym->attr.pointer && g->sym->attr.allocatable
+ && (compare_ptr_alloc(sym, g->sym)
+ || compare_ptr_alloc(g->sym, sym
return true;
}
! { dg-do compile }
!
! PR 45521: [F08] GENERIC resolution with ALLOCATABLE/POINTER and PROCEDURE
!
! Contributed by Janus Weil
INTERFACE gen
SUBROUTINE suba(a) ! { dg-error "Ambiguous interfaces" }
REAL,ALLOCATABLE :: a(:)
END SUBROUTINE
SUBROUTINE subp(p) ! { dg-error "Ambiguous interfaces" }
REAL,POINTER,INTENT(IN) :: p(:)
END SUBROUTINE
END INTERFACE
end
! { dg-do compile }
!
! PR 45521: [F08] GENERIC resolution with ALLOCATABLE/POINTER and PROCEDURE
!
! Contributed by Janus Weil
type :: t
end type
interface test
procedure testAlloc
procedure testPtr
end interface
contains
logical function testAlloc(obj)
class(t), allocatable :: obj
testAlloc = .true.
end function
logical function testPtr(obj)
class(t), pointer :: obj
testPtr = .false.
end function
end
Re: [PATCH] Fix PR c++/85400
On Wed, May 09, 2018 at 12:05:34PM +0200, Eric Botcazou wrote:
> > So it isn't clear to me if a cxx_make_decl_one_only is the way to go. Maybe
> > doing the recalculation in comdat_linkage and maybe_make_one_only only
> > would be sufficient.
>
> Patch to that effect attached, tested on x86-64/Linux, OK for mainline?
>
>
> 2018-05-09 Eric Botcazou
>
> cp/
> PR c++/85400
> * decl2.c (adjust_var_decl_tls_model): New static function.
> (comdat_linkage): Call it on a variable.
> (maybe_make_one_only): Likewise.
>
> c-family/
> * c-attribs.c (handle_visibility_attribute): Do not set no_add_attrs.
Eric, do you plan to backport this to release branches?
> Index: cp/decl2.c
> ===
> --- cp/decl2.c(revision 259642)
> +++ cp/decl2.c(working copy)
> @@ -1838,6 +1838,17 @@ mark_vtable_entries (tree decl)
> }
> }
>
> +/* Adjust the TLS model on variable DECL if need be, typically after
> + the linkage of DECL has been modified. */
> +
> +static void
> +adjust_var_decl_tls_model (tree decl)
> +{
> + if (CP_DECL_THREAD_LOCAL_P (decl)
> + && !lookup_attribute ("tls_model", DECL_ATTRIBUTES (decl)))
> +set_decl_tls_model (decl, decl_default_tls_model (decl));
> +}
> +
> /* Set DECL up to have the closest approximation of "initialized common"
> linkage available. */
>
> @@ -1888,6 +1899,9 @@ comdat_linkage (tree decl)
>
>if (TREE_PUBLIC (decl))
> DECL_COMDAT (decl) = 1;
> +
> + if (VAR_P (decl))
> +adjust_var_decl_tls_model (decl);
> }
>
> /* For win32 we also want to put explicit instantiations in
> @@ -1926,6 +1940,8 @@ maybe_make_one_only (tree decl)
> /* Mark it needed so we don't forget to emit it. */
>node->forced_by_abi = true;
> TREE_USED (decl) = 1;
> +
> + adjust_var_decl_tls_model (decl);
> }
> }
> }
> Index: c-family/c-attribs.c
> ===
> --- c-family/c-attribs.c (revision 259642)
> +++ c-family/c-attribs.c (working copy)
> @@ -2299,14 +2299,13 @@ handle_visibility_attribute (tree *node,
>
> static tree
> handle_tls_model_attribute (tree *node, tree name, tree args,
> - int ARG_UNUSED (flags), bool *no_add_attrs)
> + int ARG_UNUSED (flags),
> + bool *ARG_UNUSED (no_add_attrs))
> {
>tree id;
>tree decl = *node;
>enum tls_model kind;
>
> - *no_add_attrs = true;
> -
>if (!VAR_P (decl) || !DECL_THREAD_LOCAL_P (decl))
> {
>warning (OPT_Wattributes, "%qE attribute ignored", name);
Jakub
Re: [Patch, Fortran] PR25829: Asynchronous I/O (v2)
>>> FAIL: gfortran.dg/f2003_inquire_1.f03 -O1 execution test
>
> This seems to be a bug in the test suite. It tries to find out whether an id
> is pending that is never initialized.
>
>>> FAIL: gfortran.dg/f2003_io_1.f03 -O*
>
> And another bug in the test suite. This time the wait after the read is
> missing.
Do you have any fix for them ?
> asynchronous_7.f90 is a test for an error, but dg-shouldfail is not working
> in libgomp. Dominique is looking into this.
I have this in my working tree
! { dg-do run }
program main
integer :: i
open (10,file="tst.dat")
write (10,'(A4)') 'asdf'
close(10)
i = 234
open(10,file="tst.dat", asynchronous="yes")
read (10,'(I4)',asynchronous="yes") i
wait(10)
end program main
! { dg-output "Fortran runtime error: Bad value during integer read" }
! { dg-final { remote_file build delete "tst.dat" } }
>
>> Besides, I see
>> +FAIL: libgomp.fortran/asynchronous_6.f90 -O1 execution test
>> STOP 2
>> 32-bit i386 only.
>
> I have trouble replicating this bug even with -m32. Could you get some more
> debugging info for the test on your machine?
I have copied the asynchronous tests from libgomp.fortran to gfortran.dg and
ran both
make -k check-gfortran RUNTESTFLAGS="dg.exp=asynchronous_*
--target_board=unix'{-m32,-m64}’"
in gcc and
make -k check RUNTESTFLAGS="fortran.exp=asynchronous_*.f90
--target_board=unix'{-m32,-m64}’"
in x86_64-apple-darwin17.6.0/libgomp/testsuite 10 times and I see ~10 failures
in each cases (mostly STOP 2, but also STOP 4). I some cases I had to kill the
process.
Note that these tests should probably protected by something such as
! { dg-require-effective-target pthread }
or
! { dg-require-effective-target tls }
Dominique
PING^2: [PATCH] libitm/x86: Correct offsets of __private_tm and pointer_guard
On Mon, Jun 4, 2018 at 6:10 AM, H.J. Lu wrote:
> On Wed, May 30, 2018 at 7:54 AM, H.J. Lu wrote:
>> In glibc, sysdeps/i386/nptl/tls.h has
>>
>> typedef struct
>> {
>> void *tcb;/* Pointer to the TCB. Not necessarily the
>>thread descriptor used by libpthread. */
>> dtv_t *dtv;
>> void *self; /* Pointer to the thread descriptor. */
>> int multiple_threads;
>> uintptr_t sysinfo;
>> uintptr_t stack_guard;
>> uintptr_t pointer_guard;
>> int gscope_flag;
>> int __glibc_reserved1;
>> /* Reservation of some values for the TM ABI. */
>> void *__private_tm[4];
>> /* GCC split stack support. */
>> void *__private_ss;
>> } tcbhead_t;
>>
>> and sysdeps/x86_64/nptl/tls.h has
>>
>> typedef struct
>> {
>> void *tcb;/* Pointer to the TCB. Not necessarily the
>>thread descriptor used by libpthread. */
>> dtv_t *dtv;
>> void *self; /* Pointer to the thread descriptor. */
>> int multiple_threads;
>> int gscope_flag;
>> uintptr_t sysinfo;
>> uintptr_t stack_guard;
>> uintptr_t pointer_guard;
>> unsigned long int vgetcpu_cache[2];
>> int __glibc_reserved1;
>> int __glibc_unused1;
>> /* Reservation of some values for the TM ABI. */
>> void *__private_tm[4];
>> /* GCC split stack support. */
>> void *__private_ss;
>> long int __glibc_reserved2;
>> /* Must be kept even if it is no longer used by glibc since programs,
>> like AddressSanitizer, depend on the size of tcbhead_t. */
>> __128bits __glibc_unused2[8][4] __attribute__ ((aligned (32)));
>>
>> void *__padding[8];
>> } tcbhead_t;
>>
>> The offsets of __private_tm are
>>
>> i386: 36 bytes
>> x32:48 bytes
>> x86_64: 80 bytes
>>
>> and the offsets of pointer_guard are:
>>
>> i386: 24 bytes
>> x32:28 bytes
>> x86_64: 48 bytes
>>
>> Update SEG_READ and SEG_WRITE to use the offset of __private_tm as base
>> and correct the offset of pointer_guard for x32.
>>
>> Tested on i686, x86-64 and x32. OK for trunk and release branches?
>>
>
> Any comments, objections?
>
> BTW, this patch doesn't change ABI of libitm.
>
PING:
https://gcc.gnu.org/ml/gcc-patches/2018-05/msg01733.html
--
H.J.
RE: [PATCH] MIPS: Add support for P6600
Robert Suchanek writes:
> The below adds support for -march=p6600. It includes
> a new scheduler plus performance tweaks.
>
> gcc/ChangeLog:
>
> 2018-06-01 Matthew Fortune
> Prachi Godbole
> * config/mips/mips-cpus.def: Define P6600.
> * config/mips/mips-tables.opt: Regenerate.
> * config/mips/mips.c (mips_multipass_dfa_lookahead): Add P6600.
> * config/mips/mips.h (TUNE_P6600): New define.
> (MIPS_ISA_LEVEL_SPEC): Infer mips64r6 from p6600.
> * doc/invoke.texi: Add p6600 to supported architectures.
It seems that mips.com has no longer got any architecture specific
documents available for either i6400/i6500 (which did exist until
recently) nor p6600. There isn't anything particularly unusual
about i6400/i6500 support but this patch for p6600 attempts to deal
with some undocumented micro-architecture details that are not
sufficiently described in the patch to maintain over time nor is
there reference material available.
Despite the fact that I am one of the original authors of the
work, I can't accept this upstream without further information.
Some notes on the patch are below:
> diff --git a/gcc/config/mips/mips.c b/gcc/config/mips/mips.c
> index bfe64bb..9c77c13 100644
> --- a/gcc/config/mips/mips.c
> +++ b/gcc/config/mips/mips.c
> @@ -198,6 +198,15 @@ enum mips_address_type {
>ADDRESS_SYMBOLIC
> };
>
> +/* Classifies an unconditional branch of interest for the P6600. */
> +
> +enum mips_ucbranch_type {
Newline for brace.
> + /* May not even be a branch. */
> + UC_UNDEFINED,
> + UC_BALC,
> + UC_OTHER
> +};
> +
> /* Macros to create an enumeration identifier for a function
> prototype. */
> #define MIPS_FTYPE_NAME1(A, B) MIPS_##A##_FTYPE_##B
> #define MIPS_FTYPE_NAME2(A, B, C) MIPS_##A##_FTYPE_##B##_##C
> @@ -1127,6 +1136,19 @@ static const struct mips_rtx_cost_data
> COSTS_N_INSNS (36), /* int_div_di */
> 2,/* branch_cost */
> 4 /* memory_latency */
> + },
> + { /* P6600 */
> +COSTS_N_INSNS (4),/* fp_add */
> +COSTS_N_INSNS (5),/* fp_mult_sf */
> +COSTS_N_INSNS (5),/* fp_mult_df */
> +COSTS_N_INSNS (17), /* fp_div_sf */
> +COSTS_N_INSNS (17), /* fp_div_df */
> +COSTS_N_INSNS (5),/* int_mult_si */
> +COSTS_N_INSNS (5),/* int_mult_di */
> +COSTS_N_INSNS (8),/* int_div_si */
> +COSTS_N_INSNS (8),/* int_div_di */
> + 2,/* branch_cost */
> + 4 /* memory_latency */
>}
> };
>
>
> @@ -14592,6 +14614,7 @@ mips_issue_rate (void)
> case PROCESSOR_LOONGSON_2F:
> case PROCESSOR_LOONGSON_3A:
> case PROCESSOR_P5600:
> +case PROCESSOR_P6600:
>return 4;
>
> case PROCESSOR_XLP:
> @@ -14727,7 +14750,7 @@ mips_multipass_dfa_lookahead (void)
>if (TUNE_OCTEON)
> return 2;
>
> - if (TUNE_P5600 || TUNE_I6400)
> + if (TUNE_P5600 || TUNE_P6600 || TUNE_I6400)
> return 4;
>
>return 0;
> @@ -18647,6 +18670,28 @@ mips_orphaned_high_part_p (mips_offset_table
> *htab, rtx_insn *insn)
>return false;
> }
>
> +/* Subroutine of mips_avoid_hazard. We classify unconditional
> branches
> + of interest for the P6600 for performance reasons. We're
> interested
> + in differentiating BALC from JIC, JIALC and BC. */
> +
> +static enum mips_ucbranch_type
> +mips_classify_branch_p6600 (rtx_insn *insn)
> +{
> + if (!(insn
> + && USEFUL_INSN_P (insn)
> + && GET_CODE (PATTERN (insn)) != SEQUENCE))
> +return UC_UNDEFINED;
Let's switch this around to the following with a comment to say
ignore sequences because they represent a filled delay slot
branch (which presumably is not affected by the uArch issue).
if (insn
|| !USEFUL_INSN_P (insn)
|| GET_CODE (PATTERN (insn)) == SEQUENCE))
return UC_UNDEFINED;
> +
> + if (get_attr_jal (insn) == JAL_INDIRECT /* JIC and JIALC. */
> + || get_attr_type (insn) == TYPE_JUMP) /* BC as it is a loose
> jump. */
> +return UC_OTHER;
I don't recall what a loose jump was supposed to refer to, presumably
'direct jump'.
> /* Subroutine of mips_reorg_process_insns. If there is a hazard
> between
> INSN and a previous instruction, avoid it by inserting nops after
> instruction AFTER.
> @@ -18699,14 +18744,36 @@ mips_avoid_hazard (rtx_insn *after, rtx_insn
> *insn, int *hilo_delay,
> && GET_CODE (pattern) != ASM_INPUT
> && asm_noperands (pattern) < 0)
> nops = 1;
> + /* The P6600's branch predictor does not handle certain static
> + sequences of back-to-back jumps well. Inserting a no-op only
> + costs space as the dispatch unit will disregard the nop.
> + Here we handle the cases of back to back unconditional branches
> + that are inefficent. */
> + else if (TUNE_P6600 && TARGET_CB_MAYBE && !optimize_size
>
Re: [patch] Remove redundant intrinsics
Hello Julia! On 04 июн 10:27, Koval, Julia wrote: > Hi, > > Since pre-Icelake ISA already had 128bit version vpclmul and vaes, we already > have intrinsics for them(_mm_aesdec_si128, _mm_aesdeclast_si128, > _mm_aesenc_si128, _mm_aesenclast_si128, _mm_clmulepi64_si128). Therefore > intrinsics for them, introduced with Icelake instructions are redundant. This > patch removes them. Ok for trunk? > > gcc/ > * config/i386/vaesintrin.h (_mm_aesdec_epi128, _mm_aesdeclast_epi128, > _mm_aesenc_epi128, _mm_aesenclast_epi128): Remove. > * config/i386/vpclmulqdqintrin.h (_mm_clmulepi64_epi128): Remove. > > gcc/testsuite/ > * gcc.target/i386/avx512fvl-vaes-1.c: Remove 128bit versions from test. > * gcc.target/i386/vpclmulqdq.c: Ditto. Your patch is OK. I've checked it into main trunk. > > Thanks, > Julia -- Thanks, K
Re: [PATCH] Fix typo done in MPX removal (PR tree-optimization/86089).
On Mon, Jun 11, 2018 at 09:05:26AM +0200, Martin Liška wrote: > Hi. > > This is typo I did when MPX was removed. I'm moving back hunk with > BUILT_IN_STPCPY_CHK. > > Ready after testing? > Martin > > gcc/ChangeLog: > > 2018-06-11 Martin Liska > > PR tree-optimization/86089 > * tree-ssa-strlen.c (get_string_length): Move back removed hunk. > > gcc/testsuite/ChangeLog: > > 2018-06-11 Martin Liska > > PR tree-optimization/86089 > * gcc.dg/tree-ssa/pr86089.c: New test. Ok, thanks. Jakub
RE: [PATCH] MIPS: Add i6500 processor as an alias for i6400
Robert Suchanek writes: > This patch adds i6500 CPU as an alias for i6400. > > Regards, > Robert > > gcc/ChangeLog: > > 2018-06-01 Matthew Fortune > > * config/mips/mips-cpus.def: New MIPS_CPU for i6500. > * config/mips/mips-tables.opt: Regenerate. > * config/mips/mips.h (MIPS_ISA_LEVEL_SPEC): Mark i6500 as > mips64r6. > * doc/invoke.texi: Document -march=i6500. Looks good, OK to commit. Thanks, Matthew
RE: [PATCH] MIPS: Update I6400 scheduler
Robert Suchanek writes: > Update to i6400 scheduler. > > Regards, > Robert > > gcc/ChangeLog: > > 2018-06-01 Prachi Godbole > > * config/mips/i6400.md (i6400_gpmuldiv): Remove cpu_unit. > (i6400_gpmul): Add cpu_unit. > (i6400_gpdiv): Likewise. > (i6400_msa_add_d): Update reservations. > (i6400_msa_int_add) Likewise. > (i6400_msa_short_logic3) Likewise. > (i6400_msa_short_logic2) Likewise. > (i6400_msa_short_logic) Likewise. > (i6400_msa_move) Likewise. > (i6400_msa_cmp) Likewise. > (i6400_msa_short_float2) Likewise. > (i6400_msa_div_d) Likewise. > (i6400_msa_long_logic1) Likewise. > (i6400_msa_long_logic2) Likewise. > (i6400_msa_mult) Likewise. > (i6400_msa_long_float2) Likewise. > (i6400_msa_long_float4) Likewise. > (i6400_msa_long_float5) Likewise. > (i6400_msa_long_float8) Likewise. > (i6400_fpu_minmax): New define_insn_reservation. > (i6400_fpu_fadd): Include frint type. > (i6400_fpu_store): New define_insn_reservation. > (i6400_fpu_load): Likewise. > (i6400_fpu_move): Likewise. > (i6400_fpu_fcmp): Likewise. > (i6400_fpu_fmadd): Likewise. > (i6400_int_mult): Include imul3nc type and update reservation. > (i6400_int_div): Include idiv3 type and update reservation. > (i6400_int_load): Update to check type not move_type. > (i6400_int_store): Likewise. > (i6400_int_prefetch): Set zero latency. Hi Robert, Just to fill in the blanks on the submission history for this. The patch here was written by Prachi while MIPS was a part of IMG and was then transferred to MIPS Tech LLC when the business split. Both IMG and MIPS Tech LLC have copyright assignment in place so it does not matter that it is authored by someone from IMG and submitted by a MIPS Tech LLC employee. There is no public platform available to demonstrate the improvement of this patch but it was tested, when written, to meet or exceed existing performance on i6400. It is also included in the reference tools for the i6400 produced by MIPS Tech LLC. There does seem to be a temporal issue in submission for this as the i6400_fpu_minmax reservation refers to fminmax and fclass types that do not exist in trunk. Can you drop that reservation please? Otherwise, OK to commit. Thanks, Matthew > --- > gcc/config/mips/i6400.md | 86 ++-- > > 1 file changed, 61 insertions(+), 25 deletions(-) > > diff --git a/gcc/config/mips/i6400.md b/gcc/config/mips/i6400.md > index 413e9e8..a985401 100644 > --- a/gcc/config/mips/i6400.md > +++ b/gcc/config/mips/i6400.md > @@ -21,7 +21,7 @@ > (define_automaton "i6400_int_pipe, i6400_mdu_pipe, > i6400_fpu_short_pipe, > i6400_fpu_long_pipe") > > -(define_cpu_unit "i6400_gpmuldiv" "i6400_mdu_pipe") > +(define_cpu_unit "i6400_gpmul, i6400_gpdiv" "i6400_mdu_pipe") > (define_cpu_unit "i6400_agen, i6400_alu1, i6400_lsu" "i6400_int_pipe") > (define_cpu_unit "i6400_control, i6400_ctu, i6400_alu0" > "i6400_int_pipe") > > @@ -50,49 +50,49 @@ (define_insn_reservation "i6400_msa_add_d" 1 >(and (eq_attr "cpu" "i6400") > (and (eq_attr "mode" "!V2DI") > (eq_attr "alu_type" "simd_add"))) > - "i6400_fpu_short, i6400_fpu_intadd") > + "i6400_fpu_short+i6400_fpu_intadd*2") > > ;; add, hadd, sub, hsub, average, min, max, compare > (define_insn_reservation "i6400_msa_int_add" 2 >(and (eq_attr "cpu" "i6400") > (eq_attr "type" "simd_int_arith")) > - "i6400_fpu_short, i6400_fpu_intadd") > + "i6400_fpu_short+i6400_fpu_intadd*2") > > ;; sat, pcnt > (define_insn_reservation "i6400_msa_short_logic3" 3 >(and (eq_attr "cpu" "i6400") > (eq_attr "type" "simd_sat,simd_pcnt")) > - "i6400_fpu_short, i6400_fpu_logic") > + "i6400_fpu_short+i6400_fpu_logic*2") > > ;; shifts, nloc, nlzc, bneg, bclr, shf > (define_insn_reservation "i6400_msa_short_logic2" 2 >(and (eq_attr "cpu" "i6400") > (eq_attr "type" "simd_shift,simd_shf,simd_bit")) > - "i6400_fpu_short, i6400_fpu_logic") > + "i6400_fpu_short+i6400_fpu_logic*2") > > ;; and, or, xor, ilv, pck, fill, splat > (define_insn_reservation "i6400_msa_short_logic" 1 >(and (eq_attr "cpu" "i6400") > (eq_attr "type" > "simd_permute,simd_logic,simd_splat,simd_fill")) > - "i6400_fpu_short, i6400_fpu_logic") > + "i6400_fpu_short+i6400_fpu_logic*2") > > ;; move.v, ldi > (define_insn_reservation "i6400_msa_move" 1 >(and (eq_attr "cpu" "i6400") > (eq_attr "type" "simd_move")) > - "i6400_fpu_short, i6400_fpu_logic") > + "i6400_fpu_short+i6400_fpu_logic*2") > > ;; Float compare New: CMP.cond.fmt > (define_insn_reservation "i6400_msa_cmp" 2 >(and (eq_attr "cpu" "i6400") > (eq_attr "type" "simd_fcmp")) > - "i6400_fpu_short, i6400_fpu_cmp") > + "i6400_fpu_short+i6400_fpu_cmp*2") > > ;; Float min, max, class > (define_insn_reservation
RE: [PATCH] MIPS: Add support for -mcrc and -mginv options
Robert Suchanek writes: > This patch adds -mcrc and -mginv options to pass through them > to the assembler. > > Regards, > Robert > > gcc/ChangeLog: > > 2018-06-01 Matthew Fortune > > * config/mips/mips.h (ASM_SPEC): Pass through -mcrc, -mno-crc, > -mginv and -mno-ginv to the assembler. > * config/mips/mips.opt (-mcrc): New option. > (-mginv): Likewise. > * doc/invoke.text (-mcrc): Document. > (-mginv): Likewise. The patch is OK but should probably wait until the binutils support is committed. I see CRC ASE support in discussion up until: https://sourceware.org/ml/binutils/2017-12/msg00069.html And GINV support up to: https://sourceware.org/ml/binutils/2018-01/msg00125.html Thanks, Matthew
Re: [patch] dwarf2out don't discriminate on dwarf version for advertising Ada
> On 11 Jun 2018, at 11:24, Jakub Jelinek wrote:
>
> On Mon, Jun 11, 2018 at 08:50:31AM +0200, Olivier Hainque wrote:
>> FWIW, I was surprised by a gotcha while writing tests for this,
>> where both
>>
>> { dg-final { scan-assembler "0x3.*DW_AT_language" } }
>> and { dg-final { scan-assembler "0xd.*DW_AT_language" } }
>>
>> matched for Ada95 (0xd) with -gdwarf-3.
>
> Sure, you need to use something like \[^\n\r]* instead.
>> scan-assembler uses "regexp" without --line, and 0x3 happened
>> to match from a much earlier line in the output, with an assembly
>> output like
>>
>> bla 0x3 blo
>>
>> 0xd # DW_AT_language
>>
>> I adjusted the regex not to match newline characters and the
>> test is now more accurate, then I noticed that other language tests
>> use '.*' so might be affected as well, unless I'm missing something.
>
> In some tests using .* is intentional, in lots of others probably a bug.
I see, thanks for confirming :)
Regards,
Olivier
Re: [patch] dwarf2out don't discriminate on dwarf version for advertising Ada
On Mon, Jun 11, 2018 at 08:50:31AM +0200, Olivier Hainque wrote:
> FWIW, I was surprised by a gotcha while writing tests for this,
> where both
>
> { dg-final { scan-assembler "0x3.*DW_AT_language" } }
> and { dg-final { scan-assembler "0xd.*DW_AT_language" } }
>
> matched for Ada95 (0xd) with -gdwarf-3.
Sure, you need to use something like \[^\n\r]* instead.
> scan-assembler uses "regexp" without --line, and 0x3 happened
> to match from a much earlier line in the output, with an assembly
> output like
>
> bla 0x3 blo
>
> 0xd # DW_AT_language
>
> I adjusted the regex not to match newline characters and the
> test is now more accurate, then I noticed that other language tests
> use '.*' so might be affected as well, unless I'm missing something.
In some tests using .* is intentional, in lots of others probably a bug.
Jakub
[Ada] Double finalization of limited controlled result
This patch disables a build-in-place optimization when a function returns a
limited controlled result because the optimization may violate the semantics of
finalizable types by performing illegal calls to Finalize.
In general, the optimization causes the result object of a build-in-place
function to be allocated at the caller site, with a pointer to the object
passed to the function. The function then simply initializes the caller-
allocated object.
This mode of operation however violates semantics of finalizable types when
the context of the call is allocation. The act of allocating the controlled
object at the caller site will place it on the associated access type's
finalization master. If the function fails the initialization of the object,
the malformed object will still be finalized when the finalization master
goes out of scope. This is dangerous, and must not happen.
-- Source --
-- pack.ads
with Ada.Finalization; use Ada.Finalization;
package Pack is
type Lim_Ctrl is new Limited_Controlled with null record;
procedure Finalize (Obj : in out Lim_Ctrl);
type Lim_Ctrl_Ptr is access all Lim_Ctrl;
function Make_Lim_Ctrl_Bad_Init return Lim_Ctrl;
function Make_Lim_Ctrl_OK_Init return Lim_Ctrl;
end Pack;
-- pack.adb
with Ada.Text_IO; use Ada.Text_IO;
package body Pack is
procedure Finalize (Obj : in out Lim_Ctrl) is
begin
Put_Line (" Finalize");
end Finalize;
function Make_Lim_Ctrl_Bad_Init return Lim_Ctrl is
begin
return Result : Lim_Ctrl := raise Program_Error do
null;
end return;
end Make_Lim_Ctrl_Bad_Init;
function Make_Lim_Ctrl_OK_Init return Lim_Ctrl is
begin
return Result : Lim_Ctrl do
raise Program_Error;
end return;
end Make_Lim_Ctrl_OK_Init;
end Pack;
-- main.adb
with Ada.Text_IO; use Ada.Text_IO;
with Pack;use Pack;
procedure Main is
begin
begin
Put_Line ("1) Heap-allocated bad init");
declare
Obj : Lim_Ctrl_Ptr := new Lim_Ctrl'(Make_Lim_Ctrl_Bad_Init);
begin
Put_Line ("1) ERROR: Heap-allocated bad init: exception not raised");
end;
exception
when Program_Error =>
Put_Line ("1) Heap-allocated bad init: Program_Error raised");
when others =>
Put_Line ("1) ERROR: Heap-allocatd bad init: unexpected exception");
end;
begin
Put_Line ("2) Stack-allocated bad init");
declare
Obj : Lim_Ctrl := Make_Lim_Ctrl_Bad_Init;
begin
Put_Line ("2) ERROR: Stack-allocated bad init: exception not raised");
end;
exception
when Program_Error =>
Put_Line ("2) Stack-allocated bad init: Program_Error raised");
when others =>
Put_Line ("2) ERROR: Stack-allocated bad init: unexpected exception");
end;
begin
Put_Line ("3) Heap-allocated OK init");
declare
Obj : Lim_Ctrl_Ptr := new Lim_Ctrl'(Make_Lim_Ctrl_OK_Init);
begin
Put_Line ("3) ERROR: Heap-allocated OK init: exception not raised");
end;
exception
when Program_Error =>
Put_Line ("3) Heap-allocated OK init: Program_Error raised");
when others =>
Put_Line ("3) ERROR: Heap-allocatd OK init: unexpected exception");
end;
begin
Put_Line ("4) Stack-allocated OK init");
declare
Obj : Lim_Ctrl := Make_Lim_Ctrl_OK_Init;
begin
Put_Line ("4) ERROR: Stack-allocated OK init: exception not raised");
end;
exception
when Program_Error =>
Put_Line ("4) Stack-allocated OK init: Program_Error raised");
when others =>
Put_Line ("4) ERROR: Stack-allocated OK init: unexpected exception");
end;
end Main;
-- Compilation and output --
$ gnatmake -q main.adb
$ ./main
1) Heap-allocated bad init
1) Heap-allocated bad init: Program_Error raised
2) Stack-allocated bad init
2) Stack-allocated bad init: Program_Error raised
3) Heap-allocated OK init
Finalize
3) Heap-allocated OK init: Program_Error raised
4) Stack-allocated OK init
Finalize
4) Stack-allocated OK init: Program_Error raised
Tested on x86_64-pc-linux-gnu, committed on trunk
2018-06-11 Hristian Kirtchev
gcc/ada/
* exp_ch6.adb (Add_Unconstrained_Actuals_To_Build_In_Place_Call): Do
not add any actuals when the size of the object is known, and the
caller will allocate it.
(Build_Heap_Allocator): Rename to Build_Heap_Or_Pool_Allocator to
better illustrate its functionality. Update the comment on the
generated code. Generate a branch for the heap and pool cases where
the object is not necessarity controlled.
(Expand_N_Extended_Return_Statement): Expand the extended return
statement into four branches depending the requested mode if the caller
will not allocate the object on its side.
[Ada] Suppress the expansion of ignored assertion pragmas
This patch suppresses the expansion of ignored assertion pragmas. Tested on x86_64-pc-linux-gnu, committed on trunk 2018-06-11 Hristian Kirtchev gcc/ada/ * contracts.adb (Process_Body_Postconditions): Expand only checked postconditions. (Process_Contract_Cases_For): Expand only checked contract cases. (Process_Inherited_Preconditions): Ignored class-wide preconditions are partially expanded because some of their semantic checks are tied to the expansion. (Process_Preconditions_For): Expand only checked preconditions. (Process_Spec_Postconditions): Expand only checked preconditions. Ignored class-wide preconditions are partially expanded because some of their semantic checks are tied to the expansion. * exp_prag.adb (Expand_N_Pragma): Suppress the expansion of ignored assertion pragmas. * exp_util.adb (Add_Inherited_Invariants): Code clean up. * sem_util.adb (Propagate_Invariant_Attributes): Code clean up. gcc/testsuite/ * gnat.dg/assertion_policy1.adb, gnat.dg/assertion_policy1_pkg.adb, gnat.dg/assertion_policy1_pkg.ads: New testcase.--- gcc/ada/contracts.adb +++ gcc/ada/contracts.adb @@ -2284,7 +2284,9 @@ package body Contracts is if Present (Items) then Prag := Contract_Test_Cases (Items); while Present (Prag) loop - if Pragma_Name (Prag) = Name_Contract_Cases then + if Pragma_Name (Prag) = Name_Contract_Cases +and then Is_Checked (Prag) + then Expand_Pragma_Contract_Cases (CCs => Prag, Subp_Id => Subp_Id, @@ -2342,7 +2344,9 @@ package body Contracts is if Present (Items) then Prag := Pre_Post_Conditions (Items); while Present (Prag) loop - if Pragma_Name (Prag) = Post_Nam then + if Pragma_Name (Prag) = Post_Nam +and then Is_Checked (Prag) + then Append_Enabled_Item (Item => Build_Pragma_Check_Equivalent (Prag), List => Stmts); @@ -2364,7 +2368,9 @@ package body Contracts is -- Note that non-matching pragmas are skipped if Nkind (Decl) = N_Pragma then - if Pragma_Name (Decl) = Post_Nam then + if Pragma_Name (Decl) = Post_Nam + and then Is_Checked (Decl) + then Append_Enabled_Item (Item => Build_Pragma_Check_Equivalent (Decl), List => Stmts); @@ -2394,6 +2400,7 @@ package body Contracts is procedure Process_Spec_Postconditions is Subps : constant Subprogram_List := Inherited_Subprograms (Spec_Id); +Item: Node_Id; Items : Node_Id; Prag: Node_Id; Subp_Id : Entity_Id; @@ -2406,7 +2413,9 @@ package body Contracts is if Present (Items) then Prag := Pre_Post_Conditions (Items); while Present (Prag) loop - if Pragma_Name (Prag) = Name_Postcondition then + if Pragma_Name (Prag) = Name_Postcondition +and then Is_Checked (Prag) + then Append_Enabled_Item (Item => Build_Pragma_Check_Equivalent (Prag), List => Stmts); @@ -2429,13 +2438,20 @@ package body Contracts is if Pragma_Name (Prag) = Name_Postcondition and then Class_Present (Prag) then -Append_Enabled_Item - (Item => - Build_Pragma_Check_Equivalent - (Prag => Prag, -Subp_Id => Spec_Id, -Inher_Id => Subp_Id), - List => Stmts); +Item := + Build_Pragma_Check_Equivalent +(Prag => Prag, + Subp_Id => Spec_Id, + Inher_Id => Subp_Id); + +-- The pragma Check equivalent of the class-wide +-- postcondition is still created even though the +-- pragma may be ignored because the equivalent +-- performs semantic checks. + +if Is_Checked (Prag) then + Append_Enabled_Item (Item, Stmts); +end if; end if; Prag := Next_Pragma (Prag); @@ -2630,9 +2646,11 @@ package
[Ada] Improve last exception info availability from C++ handlers
The Most_Recent_Exception service failed to provide accurate information on an
Ada exception caught by a C++ handler for foreign exceptions. The service
relies on updates of a "current exception buffer" from live exception objects
at various points of the propagation process and this update was not performed
early enough for the case of foreign exception handlers in non-Ada handlers.
The correction applied here consists in moving one of the updates earlier in
the raise process, just before unwinding starts, then refine the update API to
prevent a redundant copy during the unwinding search phase for the same
exception.
The example below, compiled with
gcc -c b.cc
gnatmake -g main.adb -largs b.o --LINK=g++
is expected to run and display
ada info:
Checking Most_Recent_Exception for CONSTRAINT_ERROR ... OK!
// b.cc
extern "C" {
void foo ();
extern void _ada_trigger ();
extern void _ada_occurrence_info ();
}
void foo ()
{
try {
_ada_trigger ();
} catch (const abi::__foreign_exception ) {
printf ("ada info:\n");
_ada_occurrence_info();
}
}
-- main.adb
with EH;
procedure Main is
begin
EH.Foo;
end;
-- eh.adb
with Gnat.Most_Recent_Exception;
with Ada.Text_IO; use Ada.Text_IO;
package body EH is
procedure Ada_Trigger is
begin
raise Constraint_Error;
end;
procedure Ada_Occurrence_Info is
begin
Check_MRE ("CONSTRAINT_ERROR");
end;
function Pre_Check_MRE (Ename : String) return Exception_Id is
MROA : Exception_Occurrence_Access :=
GNAT.Most_Recent_Exception.Occurrence_Access;
begin
Put ("Checking Most_Recent_Exception for " & Ename & " ... ");
if MROA = null then
Put_Line ("Most recent exception occurrence access is NULL");
return Null_Id;
else
return Exception_Identity (MROA.all);
end if;
end;
procedure Diagnose_MRE (MRID : Exception_Id; Ok : Boolean) is
begin
if Ok then
Put_Line ("OK!");
else
Put_Line ("Err, Most_Recent_Exception was " & Exception_Name (MRID));
end if;
end;
procedure Check_MRE (Eid : Exception_Id) is
MRID : Exception_Id := Pre_Check_MRE (Ename => Exception_Name (Eid));
begin
Diagnose_MRE (MRID, Ok => Eid = MRID);
end;
procedure Check_MRE (Ename : String) is
MRID : Exception_Id := Pre_Check_MRE (Ename => Ename);
begin
Diagnose_MRE (MRID, Ok => Ename = Exception_Name (MRID));
end;
end;
-- eh.ads
with Ada.Exceptions; use Ada.Exceptions;
package EH is
procedure Ada_Trigger with
Export, Convention => C, External_Name => "_ada_trigger";
procedure Ada_Occurrence_Info with
Export, Convention => C, External_Name => "_ada_occurrence_info";
procedure Foo with Import, Convention => C, External_Name => "foo";
procedure Check_MRE (Eid : Exception_Id);
procedure Check_MRE (Ename : String);
end;
Tested on x86_64-pc-linux-gnu, committed on trunk
2018-06-11 Olivier Hainque
gcc/ada/
* libgnat/s-excmac*.ads: Factorize Unwind_Action definitions ...
* libgnat/a-exexpr.adb: ... Here, then add comments describing the
major datastructures associated with the current exception raised.
(Setup_Current_Excep): Accept a "Phase" argument conveying the
unwinding phase during which this subprogram is called. For an Ada
exception, don't update the current exception buffer from the raised
exception object during SEARCH_PHASE, as this is redundant with the
call now issued just before propagation starts.
(Propagate_GCC_Exception): Move call to Setup_Current_Excep ahead of
the unwinding start, conveying Phase 0.
(Unhandled_Except_Handler): Pass UA_CLEANUP_PHASE as the Phase value on
the call to Setup_Current_Excep.
* raise-gcc.c (personality_body): Pass uw_phases as the Phase argument
on calls to Setup_Current_Excep.--- gcc/ada/libgnat/a-exexpr.adb
+++ gcc/ada/libgnat/a-exexpr.adb
@@ -29,7 +29,56 @@
-- --
--
--- This is the version using the GCC EH mechanism
+-- This is the version using the GCC EH mechanism, which could rely on
+-- different underlying unwinding engines, for example DWARF or ARM unwind
+-- info based. Here is a sketch of the most prominent data structures
+-- involved:
+
+-- (s-excmac.ads)
+-- GNAT_GCC_Exception:
+-- *---*
+-- o-->| (s-excmac.ads) |
+-- | | Header : |
+-- | | - Class |
+-- | | ... |Constraint_Error:
+-- | |---*Program_Error:
+-- | | (a-except.ads) |Foreign_Exception:
+-- | | Occurrence : Exception_Occurrence |
+-- | | |(s-stalib. ads)
+-- | | - Id : Exception_Id
[Ada] Dangling cursor checks in Element function
In Ada.Containers.Ordered_Maps, if a dangling cursor is passed to the Element function, execution is erroneous. Therefore, the compiler is not obligated to detect this error. However, this patch inserts code that will detect this error in some cases, and raise Program_Error. The same applies to Ordered_Sets, Ordered_Multisets, Indefinite_Ordered_Maps, Indefinite_Ordered_Sets, and Indefinite_Ordered_Multisets. No test available for erroneous execution. Tested on x86_64-pc-linux-gnu, committed on trunk 2018-06-11 Bob Duff gcc/ada/ * libgnat/a-ciorma.adb, libgnat/a-ciormu.adb, libgnat/a-ciorse.adb, libgnat/a-coorma.adb, libgnat/a-coormu.adb, libgnat/a-coorse.adb: (Element): Add code to detect dangling cursors in some cases.--- gcc/ada/libgnat/a-ciorma.adb +++ gcc/ada/libgnat/a-ciorma.adb @@ -541,6 +541,13 @@ package body Ada.Containers.Indefinite_Ordered_Maps is "Position cursor of function Element is bad"; end if; + if Checks and then +(Left (Position.Node) = Position.Node + or else Right (Position.Node) = Position.Node) + then + raise Program_Error with "dangling cursor"; + end if; + pragma Assert (Vet (Position.Container.Tree, Position.Node), "Position cursor of function Element is bad"); --- gcc/ada/libgnat/a-ciormu.adb +++ gcc/ada/libgnat/a-ciormu.adb @@ -545,6 +545,13 @@ package body Ada.Containers.Indefinite_Ordered_Multisets is raise Program_Error with "Position cursor is bad"; end if; + if Checks and then +(Left (Position.Node) = Position.Node + or else Right (Position.Node) = Position.Node) + then + raise Program_Error with "dangling cursor"; + end if; + pragma Assert (Vet (Position.Container.Tree, Position.Node), "bad cursor in Element"); --- gcc/ada/libgnat/a-ciorse.adb +++ gcc/ada/libgnat/a-ciorse.adb @@ -534,6 +534,13 @@ package body Ada.Containers.Indefinite_Ordered_Sets is raise Program_Error with "Position cursor is bad"; end if; + if Checks and then +(Left (Position.Node) = Position.Node + or else Right (Position.Node) = Position.Node) + then + raise Program_Error with "dangling cursor"; + end if; + pragma Assert (Vet (Position.Container.Tree, Position.Node), "bad cursor in Element"); --- gcc/ada/libgnat/a-coorma.adb +++ gcc/ada/libgnat/a-coorma.adb @@ -481,6 +481,13 @@ package body Ada.Containers.Ordered_Maps is "Position cursor of function Element equals No_Element"; end if; + if Checks and then +(Left (Position.Node) = Position.Node + or else Right (Position.Node) = Position.Node) + then + raise Program_Error with "dangling cursor"; + end if; + pragma Assert (Vet (Position.Container.Tree, Position.Node), "Position cursor of function Element is bad"); --- gcc/ada/libgnat/a-coormu.adb +++ gcc/ada/libgnat/a-coormu.adb @@ -502,6 +502,13 @@ package body Ada.Containers.Ordered_Multisets is raise Constraint_Error with "Position cursor equals No_Element"; end if; + if Checks and then +(Left (Position.Node) = Position.Node + or else Right (Position.Node) = Position.Node) + then + raise Program_Error with "dangling cursor"; + end if; + pragma Assert (Vet (Position.Container.Tree, Position.Node), "bad cursor in Element"); --- gcc/ada/libgnat/a-coorse.adb +++ gcc/ada/libgnat/a-coorse.adb @@ -480,6 +480,13 @@ package body Ada.Containers.Ordered_Sets is raise Constraint_Error with "Position cursor equals No_Element"; end if; + if Checks and then +(Left (Position.Node) = Position.Node + or else Right (Position.Node) = Position.Node) + then + raise Program_Error with "dangling cursor"; + end if; + pragma Assert (Vet (Position.Container.Tree, Position.Node), "bad cursor in Element");
[Ada] Mark parameters as coming from source for GNATprove
When building a separate subprogram declaration for possible inlining of local subprograms in GNATprove mode, correctly mark subprogram parameters as coming from source. This has no impact on compilation. Tested on x86_64-pc-linux-gnu, committed on trunk 2018-06-11 Yannick Moy gcc/ada/ * sem_ch6.adb (Build_Subprogram_Declaration): Mark parameters as coming from source.--- gcc/ada/sem_ch6.adb +++ gcc/ada/sem_ch6.adb @@ -2712,6 +2712,22 @@ package body Sem_Ch6 is Specification => Copy_Subprogram_Spec (Body_Spec)); Set_Comes_From_Source (Subp_Decl, True); + -- Also mark parameters as coming from source + + if Present (Parameter_Specifications (Specification (Subp_Decl))) then +declare + Form : Entity_Id; +begin + Form := + First (Parameter_Specifications (Specification (Subp_Decl))); + + while Present (Form) loop + Set_Comes_From_Source (Defining_Identifier (Form), True); + Next (Form); + end loop; +end; + end if; + -- Relocate the aspects and relevant pragmas from the subprogram body -- to the generated spec because it acts as the initial declaration.
[Ada] Missing predicate function body for derived type in nested package
This patch fixes a bug in the construction of predicate functions. For a
derived type, we must ensure that the parent type is already frozen so that its
predicate function has been constructed already. This is necessary if the
parent is declared in a nested package and its own freeze point has not been
reached when the derived type is frozen by a local object declaration.
Tested on x86_64-pc-linux-gnu, committed on trunk
2018-06-11 Ed Schonberg
gcc/ada/
* sem_ch13.adb (Build_Predicate_Functions): For a derived type, ensure
that its parent is already frozen so that its predicate function, if
any, has already been constructed.
gcc/testsuite/
* gnat.dg/predicate1.adb: New testcase.--- gcc/ada/sem_ch13.adb
+++ gcc/ada/sem_ch13.adb
@@ -4,13 +4,27 @@ package body Sem_Ch13 is
-- If we have a type with predicates, build predicate function. This is
-- not needed in the generic case, nor within TSS subprograms and other
- -- predefined primitives.
+ -- predefined primitives. For a derived type, ensure that the parent
+ -- type is already frozen so that its predicate function has been
+ -- constructed already. This is necessary if the parent is declared
+ -- in a nested package and its own freeze point has not been reached.
if Is_Type (E)
and then Nongeneric_Case
and then not Within_Internal_Subprogram
and then Has_Predicates (E)
then
+ declare
+Atyp : constant Entity_Id := Nearest_Ancestor (E);
+ begin
+if Present (Atyp)
+ and then Has_Predicates (Atyp)
+ and then not Is_Frozen (Atyp)
+then
+ Freeze_Before (N, Atyp);
+end if;
+ end;
+
Build_Predicate_Functions (E, N);
end if;
--- /dev/null
new file mode 100644
+++ gcc/testsuite/gnat.dg/predicate1.adb
@@ -0,0 +1,40 @@
+-- { dg-do run }
+-- { dg-options "-gnata" }
+
+procedure Predicate1 with SPARK_Mode is
+type R is record
+ F : Integer;
+end record;
+
+package Nested is
+ subtype S is R with Predicate => S.F = 42;
+ procedure P (X : in out S) is null;
+
+ type T is private;
+ procedure P (X : in out T) is null;
+private
+ type T is new S;
+end Nested;
+
+X : Nested.T;
+Y : Nested.S;
+
+X_Uninitialized : Boolean := False;
+Y_Uninitialized : Boolean := False;
+begin
+ begin
+ Nested.P (X);
+ exception
+ when others => X_Uninitialized := True;
+ end;
+
+ begin
+ Nested.P (Y);
+ exception
+ when others => Y_Uninitialized := True;
+ end;
+
+ if not X_Uninitialized or else not Y_Uninitialized then
+ raise Program_Error;
+ end if;
+end Predicate1;
[Ada] Reject violation of SPARK 6.1.4(12) with enclosing task unit
SPARK 6.1.4(12) applies both to enclosing subprograms and enclosing task
units, but the latter was not correctly rejected.
Tested on x86_64-pc-linux-gnu, committed on trunk
2018-06-11 Yannick Moy
gcc/ada/
* sem_prag.adb (Check_Mode_Restriction_In_Enclosing_Context): Adapt for
possible task unit as the enclosing context.
gcc/testsuite/
* gnat.dg/spark1.adb, gnat.dg/spark1.ads: New testcase.--- gcc/ada/sem_prag.adb
+++ gcc/ada/sem_prag.adb
@@ -2128,10 +2128,10 @@ package body Sem_Prag is
procedure Check_Mode_Restriction_In_Enclosing_Context
(Item: Node_Id;
Item_Id : Entity_Id);
- -- Verify that an item of mode In_Out or Output does not appear as an
- -- input in the Global aspect of an enclosing subprogram. If this is
- -- the case, emit an error. Item and Item_Id are respectively the
- -- item and its entity.
+ -- Verify that an item of mode In_Out or Output does not appear as
+ -- an input in the Global aspect of an enclosing subprogram or task
+ -- unit. If this is the case, emit an error. Item and Item_Id are
+ -- respectively the item and its entity.
procedure Check_Mode_Restriction_In_Function (Mode : Node_Id);
-- Mode denotes either In_Out or Output. Depending on the kind of the
@@ -2483,12 +2483,24 @@ package body Sem_Prag is
Outputs : Elist_Id := No_Elist;
begin
--- Traverse the scope stack looking for enclosing subprograms
--- subject to pragma [Refined_]Global.
+-- Traverse the scope stack looking for enclosing subprograms or
+-- tasks subject to pragma [Refined_]Global.
Context := Scope (Subp_Id);
while Present (Context) and then Context /= Standard_Standard loop
- if Is_Subprogram (Context)
+
+ -- For a single task type, retrieve the corresponding object to
+ -- which pragma [Refined_]Global is attached.
+
+ if Ekind (Context) = E_Task_Type
+ and then Is_Single_Concurrent_Type (Context)
+ then
+ Context := Anonymous_Object (Context);
+ end if;
+
+ if (Is_Subprogram (Context)
+ or else Ekind (Context) = E_Task_Type
+ or else Is_Single_Task_Object (Context))
and then
(Present (Get_Pragma (Context, Pragma_Global))
or else
@@ -2501,7 +2513,8 @@ package body Sem_Prag is
Global_Seen => Dummy);
-- The item is classified as In_Out or Output but appears as
- -- an Input in an enclosing subprogram (SPARK RM 6.1.4(12)).
+ -- an Input in an enclosing subprogram or task unit (SPARK
+ -- RM 6.1.4(12)).
if Appears_In (Inputs, Item_Id)
and then not Appears_In (Outputs, Item_Id)
@@ -2510,9 +2523,15 @@ package body Sem_Prag is
("global item & cannot have mode In_Out or Output",
Item, Item_Id);
- SPARK_Msg_NE
- (Fix_Msg (Subp_Id, "\item already appears as input of "
-& "subprogram &"), Item, Context);
+ if Is_Subprogram (Context) then
+SPARK_Msg_NE
+ (Fix_Msg (Subp_Id, "\item already appears as input "
+ & "of subprogram &"), Item, Context);
+ else
+SPARK_Msg_NE
+ (Fix_Msg (Subp_Id, "\item already appears as input "
+ & "of task &"), Item, Context);
+ end if;
-- Stop the traversal once an error has been detected
--- /dev/null
new file mode 100644
+++ gcc/testsuite/gnat.dg/spark1.adb
@@ -0,0 +1,22 @@
+-- { dg-do compile }
+
+package body Spark1 is
+
+ task body Worker is
+
+ procedure Update with
+Global => (In_Out => Mailbox) -- { dg-error "global item \"Mailbox\" cannot have mode In_Out or Output|item already appears as input of task \"Worker\"" }
+ is
+ Tmp : Integer := Mailbox;
+ begin
+ Mailbox := Tmp + 1;
+ end Update;
+
+ X : Integer := Mailbox;
+ begin
+ loop
+ Update;
+ end loop;
+ end;
+
+end;
--- /dev/null
new file mode 100644
+++ gcc/testsuite/gnat.dg/spark1.ads
@@ -0,0 +1,8 @@
+package Spark1 is
+
+ Mailbox : Integer with Atomic, Async_Writers, Async_Readers;
+
+ task Worker
+ with Global => (Input => Mailbox);
+
+end;
[Ada] Do not query the representation information in CodePeer/GNATprove
Representation information generated when user calls the compiler with -gnatR switch is not available when running the frontend inside CodePeer or GNATprove. Do not query such information in that case, as this leads to spurious messages that it is not available. There is no impact on compilation. Tested on x86_64-pc-linux-gnu, committed on trunk 2018-06-11 Yannick Moy gcc/ada/ * gnat1drv.adb: Do not check representation information in CodePeer and GNATprove modes, as these modes call a special backend instead of gigi, so do not have the information.--- gcc/ada/gnat1drv.adb +++ gcc/ada/gnat1drv.adb @@ -1455,6 +1455,9 @@ begin -- representation information will be provided by the GNSA back end, not -- gigi. + -- A special back end is always called in CodePeer and GNATprove modes, + -- unless this is a subunit. + if Back_End_Mode = Declarations_Only and then (not (Back_Annotate_Rep_Info or Generate_SCIL or GNATprove_Mode) @@ -1468,7 +1471,11 @@ begin Tree_Dump; Tree_Gen; Namet.Finalize; - Check_Rep_Info; + + if not (Generate_SCIL or GNATprove_Mode) then +Check_Rep_Info; + end if; + return; end if;
[Ada] Make GNAT.Array_Split a preelaborable unit
This patch makes GNAT.Array_Split a preelaborable unit. As a result, it can be
withed by other preelaborated untis.
Tested on x86_64-pc-linux-gnu, committed on trunk
2018-06-11 Hristian Kirtchev
gcc/ada/
* libgnat/g-arrspl.ads: Add pragma Preelaborate.
gcc/testsuite/
* gnat.dg/gnat_array_split1.adb, gnat.dg/gnat_array_split1.ads: New
testcase.--- gcc/ada/libgnat/g-arrspl.ads
+++ gcc/ada/libgnat/g-arrspl.ads
@@ -56,6 +56,7 @@ generic
-- Returns True if Item is found in Set, False otherwise
package GNAT.Array_Split is
+ pragma Preelaborate;
Index_Error : exception;
-- Raised by all operations below if Index > Field_Count (S)
--- /dev/null
new file mode 100644
+++ gcc/testsuite/gnat.dg/gnat_array_split1.adb
@@ -0,0 +1,5 @@
+-- { dg-do compile }
+
+package body GNAT_Array_Split1 is
+ procedure Dummy is null;
+end GNAT_Array_Split1;
--- /dev/null
new file mode 100644
+++ gcc/testsuite/gnat.dg/gnat_array_split1.ads
@@ -0,0 +1,6 @@
+with GNAT.Array_Split;
+
+package GNAT_Array_Split1 is
+ pragma Preelaborate;
+ procedure Dummy;
+end GNAT_Array_Split1;
[Ada] Crash on protected type entry family
The compiler may blow up compiling the body of a protected type that has a
family entry whose entry index specification contains a call to a function.
Tested on x86_64-pc-linux-gnu, committed on trunk
2018-06-11 Javier Miranda
gcc/ada/
* exp_ch9.adb (Expand_N_Protected_Body): Add missing handling of
N_Call_Marker nodes.
gcc/testsuite/
* gnat.dg/prot4.adb: New testcase.
--- gcc/ada/exp_ch9.adb
+++ gcc/ada/exp_ch9.adb
@@ -8653,8 +8653,11 @@ package body Exp_Ch9 is
when N_Implicit_Label_Declaration =>
null;
-when N_Itype_Reference =>
- Insert_After (Current_Node, New_Copy (Op_Body));
+when N_Call_Marker |
+ N_Itype_Reference =>
+ New_Op_Body := New_Copy (Op_Body);
+ Insert_After (Current_Node, New_Op_Body);
+ Current_Node := New_Op_Body;
when N_Freeze_Entity =>
New_Op_Body := New_Copy (Op_Body);
--- /dev/null
new file mode 100644
+++ gcc/testsuite/gnat.dg/prot4.adb
@@ -0,0 +1,28 @@
+-- { dg-do compile }
+
+procedure Prot4 is
+ type App_Priority is (Low, Medium, High);
+
+ function Alpha return App_Priority is
+ begin
+ return Low;
+ end Alpha;
+
+ function Beta return App_Priority is
+ begin
+ return High;
+ end Beta;
+
+ protected Hold is
+ entry D7 (App_Priority range Alpha .. Beta);
+ end Hold;
+
+ protected body Hold is
+ entry D7 (for AP in App_Priority range Alpha .. Beta) when True is
+ begin
+ null;
+ end D7;
+ end Hold;
+begin
+ null;
+end;
[Ada] Mark extended return of unconstrained type as never inlined
Calls to subprograms whose body was an extended return of an unconstrained
type were marked as not inlined, while the subprogram itself was marked as
always inlined. This was inconsistent and could lead to crash in GNATprove.
Now such subprograms are marked as not candidates for inlining.
This mostly impacts GNATprove, as it relates to frontend inlining which is
not used anymore in normal compilation.
Tested on x86_64-pc-linux-gnu, committed on trunk
2018-06-11 Yannick Moy
gcc/ada/
* inline.adb (Build_Body_To_Inline): Consider case of extended return
of unconstrained type as one case where inlining is not supported.
(Expand_Inlined_Call): Remove special case for body as extended return
of unconstrained type.--- gcc/ada/inline.adb
+++ gcc/ada/inline.adb
@@ -879,6 +879,10 @@ package body Inline is
Body_To_Analyze : Node_Id;
Max_Size: constant := 10;
+ function Has_Extended_Return return Boolean;
+ -- This function returns True if the subprogram has an extended return
+ -- statement.
+
function Has_Pending_Instantiation return Boolean;
-- If some enclosing body contains instantiations that appear before
-- the corresponding generic body, the enclosing body has a freeze node
@@ -899,6 +903,49 @@ package body Inline is
-- unconstrained type, the secondary stack is involved, and it
-- is not worth inlining.
+ -
+ -- Has_Extended_Return --
+ -
+
+ function Has_Extended_Return return Boolean is
+ Body_To_Inline : constant Node_Id := N;
+
+ function Check_Return (N : Node_Id) return Traverse_Result;
+ -- Returns OK on node N if this is not an extended return statement
+
+ --
+ -- Check_Return --
+ --
+
+ function Check_Return (N : Node_Id) return Traverse_Result is
+ begin
+case Nkind (N) is
+ when N_Extended_Return_Statement =>
+ return Abandon;
+
+ -- Skip locally declared subprogram bodies inside the body to
+ -- inline, as the return statements inside those do not count.
+
+ when N_Subprogram_Body =>
+ if N = Body_To_Inline then
+ return OK;
+ else
+ return Skip;
+ end if;
+
+ when others =>
+ return OK;
+end case;
+ end Check_Return;
+
+ function Check_All_Returns is new Traverse_Func (Check_Return);
+
+ -- Start of processing for Has_Extended_Return
+
+ begin
+ return Check_All_Returns (N) /= OK;
+ end Has_Extended_Return;
+
---
-- Has_Pending_Instantiation --
---
@@ -1048,7 +1095,16 @@ package body Inline is
and then not Is_Access_Type (Etype (Spec_Id))
and then not Is_Constrained (Etype (Spec_Id))
then
- if not Has_Single_Return (N) then
+ if not Has_Single_Return (N)
+
+ -- Skip inlining if the function returns an unconstrained type
+ -- using an extended return statement since this part of the
+ -- new inlining model which is not yet supported by the current
+ -- implementation. ???
+
+ or else (Returns_Unconstrained_Type (Spec_Id)
+ and then Has_Extended_Return)
+ then
Cannot_Inline
("cannot inline & (unconstrained return type)?", N, Spec_Id);
return;
@@ -2873,18 +2929,6 @@ package body Inline is
elsif Nkind (Orig_Bod) in N_Entity then
return;
-
- -- Skip inlining if the function returns an unconstrained type using
- -- an extended return statement since this part of the new inlining
- -- model which is not yet supported by the current implementation. ???
-
- elsif Is_Unc
-and then
- Nkind (First (Statements (Handled_Statement_Sequence (Orig_Bod =
-N_Extended_Return_Statement
-and then not Back_End_Inlining
- then
- return;
end if;
if Nkind (Orig_Bod) = N_Defining_Identifier
[Ada] Do not force Part_Of on generic units
This fixes the code checking SPARK RM 7.2.6(3) so that generic child units
are not forced to use Part_Of to relate their abstract state to the state
of their parent.
Tested on x86_64-pc-linux-gnu, committed on trunk
2018-06-11 Yannick Moy
gcc/ada/
* sem_prag.adb (Analyze_Part_Of): Only allow Part_Of on non-generic
unit.
(Check_Missing_Part_Of): Do not force Part_Of on generic unit.
gcc/testsuite/
* gnat.dg/part_of1-instantiation.adb,
gnat.dg/part_of1-instantiation.ads,
gnat.dg/part_of1-private_generic.adb,
gnat.dg/part_of1-private_generic.ads, gnat.dg/part_of1.ads: New
testcase.--- gcc/ada/sem_prag.adb
+++ gcc/ada/sem_prag.adb
@@ -3200,20 +3200,21 @@ package body Sem_Prag is
-- The item appears in the visible state space of some package. In
-- general this scenario does not warrant Part_Of except when the
- -- package is a private child unit and the encapsulating state is
- -- declared in a parent unit or a public descendant of that parent
- -- unit.
+ -- package is a non-generic private child unit and the encapsulating
+ -- state is declared in a parent unit or a public descendant of that
+ -- parent unit.
elsif Placement = Visible_State_Space then
if Is_Child_Unit (Pack_Id)
+ and then not Is_Generic_Unit (Pack_Id)
and then Is_Private_Descendant (Pack_Id)
then
-- A variable or state abstraction which is part of the visible
- -- state of a private child unit or its public descendants must
- -- have its Part_Of indicator specified. The Part_Of indicator
- -- must denote a state declared by either the parent unit of
- -- the private unit or by a public descendant of that parent
- -- unit.
+ -- state of a non-generic private child unit or its public
+ -- descendants must have its Part_Of indicator specified. The
+ -- Part_Of indicator must denote a state declared by either the
+ -- parent unit of the private unit or by a public descendant of
+ -- that parent unit.
-- Find the nearest private ancestor (which can be the current
-- unit itself).
@@ -3250,8 +3251,9 @@ package body Sem_Prag is
return;
end if;
--- Indicator Part_Of is not needed when the related package is not
--- a private child unit or a public descendant thereof.
+-- Indicator Part_Of is not needed when the related package is
+-- not a non-generic private child unit or a public descendant
+-- thereof.
else
SPARK_Msg_N
@@ -28831,11 +28833,13 @@ package body Sem_Prag is
-- In general an item declared in the visible state space of a package
-- does not require a Part_Of indicator. The only exception is when the
- -- related package is a private child unit in which case Part_Of must
- -- denote a state in the parent unit or in one of its descendants.
+ -- related package is a non-generic private child unit in which case
+ -- Part_Of must denote a state in the parent unit or in one of its
+ -- descendants.
elsif Placement = Visible_State_Space then
if Is_Child_Unit (Pack_Id)
+ and then not Is_Generic_Unit (Pack_Id)
and then Is_Private_Descendant (Pack_Id)
then
-- A package instantiation does not need a Part_Of indicator when
--- /dev/null
new file mode 100644
+++ gcc/testsuite/gnat.dg/part_of1-instantiation.adb
@@ -0,0 +1,10 @@
+-- { dg-do compile }
+
+with Part_Of1.Private_Generic;
+
+package body Part_Of1.Instantiation
+with
+ Refined_State => (State => Inst.State)
+is
+ package Inst is new Part_Of1.Private_Generic;
+end Part_Of1.Instantiation;
--- /dev/null
new file mode 100644
+++ gcc/testsuite/gnat.dg/part_of1-instantiation.ads
@@ -0,0 +1,6 @@
+package Part_Of1.Instantiation
+with
+ Abstract_State => State
+is
+ pragma Elaborate_Body;
+end Part_Of1.Instantiation;
--- /dev/null
new file mode 100644
+++ gcc/testsuite/gnat.dg/part_of1-private_generic.adb
@@ -0,0 +1,13 @@
+package body Part_Of1.Private_Generic
+with
+ Refined_State => (State => Numbers)
+is
+ Numbers : array (Range_Type) of Integer := (others => 0);
+
+ function Get (I : Range_Type) return Integer
+ is
+ begin
+ return Numbers (I);
+ end Get;
+
+end Part_Of1.Private_Generic;
--- /dev/null
new file mode 100644
+++ gcc/testsuite/gnat.dg/part_of1-private_generic.ads
@@ -0,0 +1,12 @@
+private generic
+ Count : Integer := 4;
+package Part_Of1.Private_Generic
+with
+ Abstract_State => State
+is
+
+ subtype Range_Type is Integer range 1 .. Count;
+
+ function Get (I : Range_Type) return Integer;
+
[Ada] Don't split AND THEN expressions in GNATprove_Mode
Splitting AND THEN expressions in contracts into separate pragma Check is only useful for compilation when the error message points to a failed conjunct. For proof it is of no use; for flow analysis it is annoying. Also, it makes debugging harder. Now it is disabled in GNATprove_Mode. Compilation is not affected, so no test provided. Tested on x86_64-pc-linux-gnu, committed on trunk 2018-06-11 Piotr Trojanek gcc/ada/ * sem_ch13.adb (Analyze_Aspect_Specifications): Don't split AND THEN expressions in Pre/Post contracts while in GNATprove_Mode.--- gcc/ada/sem_ch13.adb +++ gcc/ada/sem_ch13.adb @@ -3443,9 +3443,13 @@ package body Sem_Ch13 is -- We do not do this in ASIS mode, as ASIS relies on the -- original node representing the complete expression, when - -- retrieving it through the source aspect table. + -- retrieving it through the source aspect table. Also, we + -- don't do this in GNATprove mode, because it brings no + -- benefit for proof and causes annoynace for flow analysis, + -- which prefers to be as close to the original source code + -- as possible. - if not ASIS_Mode + if not (ASIS_Mode or GNATprove_Mode) and then (Pname = Name_Postcondition or else not Class_Present (Aspect)) then
[Ada] Fix handling of Pre/Post contracts with AND THEN expressions
Pre- and postconditions with top-level AND THEN expressions are broken down
into checks of indivudial conjuncts for more precise error reporting. This
rewrite interfers with detection of potentially unevaluadted use of 'Old,
e.g. a contract like "Pre => Foo and then Bar" is rewritten into a two
pragmas Check, for expressions "Foo" and "Bar", but the latter remains
potentially unevaluted. This patch fixes detection of the AND THEN rewrite.
This fixes inlining in the GNATprove mode, i.e. the following testc case must
not emit a warning like:
contract1.adb:14:07: info:
no contextual analysis of "Foo" (in potentially unevaluated context)
Tested on x86_64-pc-linux-gnu, committed on trunk
2018-06-11 Piotr Trojanek
gcc/ada/
* sem_util.adb (Is_Potentially_Unevaluated): Fix detection of contracts
with AND THEN expressions broken down into individual conjuncts.
gcc/testsuite/
* gnat.dg/contract1.adb: New testcase.--- gcc/ada/sem_util.adb
+++ gcc/ada/sem_util.adb
@@ -16453,7 +16453,9 @@ package body Sem_Util is
while Present (Par)
and then Nkind (Par) /= N_Pragma_Argument_Association
loop
- if Nkind (Original_Node (Par)) = N_And_Then then
+ if Is_Rewrite_Substitution (Par)
+ and then Nkind (Original_Node (Par)) = N_And_Then
+ then
return True;
end if;
--- /dev/null
new file mode 100644
+++ gcc/testsuite/gnat.dg/contract1.adb
@@ -0,0 +1,20 @@
+-- { dg-do compile }
+-- { dg-options "-gnatd.F -gnatwa" }
+
+with Ada.Dispatching;
+
+procedure Contract1 with SPARK_Mode is
+
+ function Foo return Boolean is
+ begin
+ Ada.Dispatching.Yield;
+ return True;
+ end Foo;
+
+ Dummy : constant Integer := 0;
+
+begin
+ if Foo and then True then
+ raise Program_Error;
+ end if;
+end Contract1;
[Ada] Wrong code in array aggregates of Ada coextensions
The compiler generates wrong code when an array aggregate with an others choice
whose expression has nested object allocations (ie. others => new R (new S)) is
used to initialize an array of access to discriminated types whose discriminant
is an access type.
Tested on x86_64-pc-linux-gnu, committed on trunk
2018-06-11 Javier Miranda
gcc/ada/
* sinfo.ads (Is_Dynamic_Coextension): Adding documentation.
(Is_Static_Coextension): Adding documentation.
* sinfo.adb (Is_Dynamic_Coextension): Extending the assertion.
(Is_Static_Coextension): Extending the assertion.
* sem_util.adb (Mark_Allocator): Clear Is_Static_Coextension when
setting flag Is_Dynamic_Coextension (and vice versa).
gcc/testsuite/
* gnat.dg/aggr23.adb, gnat.dg/aggr23_q.adb, gnat.dg/aggr23_tt.ads: New
testcase.--- gcc/ada/sem_util.adb
+++ gcc/ada/sem_util.adb
@@ -18472,6 +18472,7 @@ package body Sem_Util is
begin
if Nkind (N) = N_Allocator then
if Is_Dynamic then
+ Set_Is_Static_Coextension (N, False);
Set_Is_Dynamic_Coextension (N);
-- If the allocator expression is potentially dynamic, it may
@@ -18482,8 +18483,10 @@ package body Sem_Util is
elsif Nkind (Expression (N)) = N_Qualified_Expression
and then Nkind (Expression (Expression (N))) = N_Op_Concat
then
+ Set_Is_Static_Coextension (N, False);
Set_Is_Dynamic_Coextension (N);
else
+ Set_Is_Dynamic_Coextension (N, False);
Set_Is_Static_Coextension (N);
end if;
end if;
--- gcc/ada/sinfo.adb
+++ gcc/ada/sinfo.adb
@@ -5350,6 +5350,8 @@ package body Sinfo is
begin
pragma Assert (False
or else NT (N).Nkind = N_Allocator);
+ pragma Assert (not Val
+or else not Is_Static_Coextension (N));
Set_Flag18 (N, Val);
end Set_Is_Dynamic_Coextension;
@@ -5613,6 +5615,8 @@ package body Sinfo is
begin
pragma Assert (False
or else NT (N).Nkind = N_Allocator);
+ pragma Assert (not Val
+or else not Is_Dynamic_Coextension (N));
Set_Flag14 (N, Val);
end Set_Is_Static_Coextension;
--- gcc/ada/sinfo.ads
+++ gcc/ada/sinfo.ads
@@ -1738,7 +1738,8 @@ package Sinfo is
--Present in allocator nodes, to indicate that this is an allocator
--for an access discriminant of a dynamically allocated object. The
--coextension must be deallocated and finalized at the same time as
- --the enclosing object.
+ --the enclosing object. The partner flag Is_Static_Coextension must
+ --be cleared before setting this flag to True.
-- Is_Effective_Use_Clause (Flag1-Sem)
--Present in both N_Use_Type_Clause and N_Use_Package_Clause to indicate
@@ -1949,7 +1950,9 @@ package Sinfo is
-- Is_Static_Coextension (Flag14-Sem)
--Present in N_Allocator nodes. Set if the allocator is a coextension
- --of an object allocated on the stack rather than the heap.
+ --of an object allocated on the stack rather than the heap. The partner
+ --flag Is_Dynamic_Coextension must be cleared before setting this flag
+ --to True.
-- Is_Static_Expression (Flag6-Sem)
--Indicates that an expression is a static expression according to the
--- /dev/null
new file mode 100644
+++ gcc/testsuite/gnat.dg/aggr23.adb
@@ -0,0 +1,9 @@
+-- { dg-options "-gnatws" }
+-- { dg-do run }
+
+with Aggr23_Q;
+
+procedure Aggr23 is
+begin
+ Aggr23_Q (2);
+end;
--- /dev/null
new file mode 100644
+++ gcc/testsuite/gnat.dg/aggr23_q.adb
@@ -0,0 +1,14 @@
+-- { dg-options "-gnatws" }
+
+with Ada.Text_IO; use Ada.Text_IO;
+
+with Aggr23_TT; use Aggr23_TT;
+
+procedure Aggr23_Q (Count : Natural) is
+ Ts : array (1 .. Count) of TA
+ := (others => new T (new Integer)); -- Test
+begin
+ if Ts (1).D = Ts (2).D then
+ Put ("ERROR");
+ end if;
+end;
--- /dev/null
new file mode 100644
+++ gcc/testsuite/gnat.dg/aggr23_tt.ads
@@ -0,0 +1,4 @@
+package Aggr23_TT is
+ type T (D : not null access Integer) is null record;
+ type TA is access T;
+end;
[Ada] Crash with Inline_Always on a function with an extended return
This patch fixes a crash on a unit with a function with the GNAT-specific
Inline_Always pragma whose body is an extended return statement, when compiling
with no optimization level specified.
Tested on x86_64-pc-linux-gnu, committed on trunk
2018-06-11 Ed Schonberg
gcc/ada/
* inline.adb (Expand_Inlined_Call): If no optimization level is
specified, the expansion of a call to an Inline_Always function is
fully performed in the front-end even on a target that support back-end
inlining.
gcc/testsuite/
* gnat.dg/inline_always1.adb: New testcase.--- gcc/ada/inline.adb
+++ gcc/ada/inline.adb
@@ -2269,11 +2269,16 @@ package body Inline is
Subp : Entity_Id;
Orig_Subp : Entity_Id)
is
- Loc : constant Source_Ptr := Sloc (N);
- Is_Predef : constant Boolean :=
-Is_Predefined_Unit (Get_Source_Unit (Subp));
- Orig_Bod : constant Node_Id :=
+ Loc : constant Source_Ptr := Sloc (N);
+ Is_Predef : constant Boolean :=
+Is_Predefined_Unit (Get_Source_Unit (Subp));
+ Orig_Bod : constant Node_Id :=
Body_To_Inline (Unit_Declaration_Node (Subp));
+ Uses_Back_End : constant Boolean :=
+ Back_End_Inlining and then Optimization_Level > 0;
+ -- The back-end expansion is used if the target supports back-end
+ -- inlining and some level of optimixation is required; otherwise
+ -- the inlining takes place fully as a tree expansion.
Blk : Node_Id;
Decl : Node_Id;
@@ -2840,7 +2845,7 @@ package body Inline is
begin
-- Initializations for old/new semantics
- if not Back_End_Inlining then
+ if not Uses_Back_End then
Is_Unc := Is_Array_Type (Etype (Subp))
and then not Is_Constrained (Etype (Subp));
Is_Unc_Decl := False;
@@ -2914,7 +2919,7 @@ package body Inline is
-- Old semantics
- if not Back_End_Inlining then
+ if not Uses_Back_End then
declare
Bod : Node_Id;
@@ -2958,8 +2963,20 @@ package body Inline is
begin
First_Decl := First (Declarations (Blk));
+ -- If the body is a single extended return statement,
+ -- the resulting block is a nested block.
+
+ if No (First_Decl) then
+First_Decl := First
+ (Statements (Handled_Statement_Sequence (Blk)));
+
+ if Nkind (First_Decl) = N_Block_Statement then
+First_Decl := First (Declarations (First_Decl));
+ end if;
+ end if;
+
if Nkind (First_Decl) /= N_Object_Declaration then
- return;
+ return; -- No front-end inlining possible,
end if;
if Nkind (Parent (N)) /= N_Assignment_Statement then
@@ -3288,7 +3305,7 @@ package body Inline is
-- of the result of a call to an inlined function that returns
-- an unconstrained type
- elsif Back_End_Inlining
+ elsif Uses_Back_End
and then Nkind (Parent (N)) = N_Object_Declaration
and then Is_Unc
then
--- /dev/null
new file mode 100644
+++ gcc/testsuite/gnat.dg/inline_always1.adb
@@ -0,0 +1,57 @@
+-- { dg-do compile }
+
+with Ada.Text_IO;
+
+procedure Inline_Always1 is
+
+ function S(N : Integer ) return String is
+ begin
+ return "hello world";
+ end S;
+
+ type String_Access is access all String;
+ type R is record
+ SA : String_Access;
+ end record;
+
+ Data : aliased String := "hello world";
+ My_SA : constant String_Access := Data'Access;
+ function Make_R( S : String ) return R is
+ My_R : R;
+ begin
+ My_R.SA := My_SA;
+ return My_R;
+ end Make_R;
+
+ function Get_String( My_R : R ) return String
+ is
+ begin
+ return S : String(My_R.SA.all'Range) do
+ S := My_R.SA.all;
+ end return;
+ end Get_String;
+ pragma Inline_Always( Get_String);
+
+ My_R : constant R := Make_R( "hello world");
+begin
+ for I in 1..1 loop
+ declare
+ Res : constant String := S( 4 );
+ begin
+ Ada.Text_IO.Put_Line(Res);
+ end;
+ declare
+ Res : constant String := S( 4 );
+ begin
+ Ada.Text_IO.Put_Line(Res);
+ end;
+
+ declare
+ S : constant String := Get_String( My_R );
+ begin
+ Ada.Text_IO.Put_Line(S);
+ Ada.Text_IO.Put_Line(My_R.SA.all);
+ end;
+ end loop;
+
+end Inline_Always1;
[Ada] Crash on instantiation of nested generic in private part
This patch fixes a compiler abort on an instantiation of a generic nested
within another instance, when the outer instance is declared in the visible
part of a package and the inner intance is in the private part of the same
package.
Tested on x86_64-pc-linux-gnu, committed on trunk
2018-06-11 Ed Schonberg
gcc/ada/
* sem_ch12.adb (Install_Body): In order to determine the placement of
the freeze node for an instance of a generic nested within another
instance, take into account that the outer instance may be declared in
the visible part of a package and the inner intance may be in the
private part of the same package.
gcc/testsuite/
* gnat.dg/nested_generic2.adb, gnat.dg/nested_generic2.ads,
gnat.dg/nested_generic2_g1.adb, gnat.dg/nested_generic2_g1.ads,
gnat.dg/nested_generic2_g2.ads: New testcase.--- gcc/ada/sem_ch12.adb
+++ gcc/ada/sem_ch12.adb
@@ -9527,9 +9527,13 @@ package body Sem_Ch12 is
-- the freeze node for Inst must be inserted after that of
-- Parent_Inst. This relation is established by comparing
-- the Slocs of Parent_Inst freeze node and Inst.
+ -- We examine the parents of the enclosing lists to handle
+ -- the case where the parent instance is in the visible part
+ -- of a package declaration, and the inner instance is in
+ -- the corresponding private part.
- if List_Containing (Get_Unit_Instantiation_Node (Par)) =
- List_Containing (N)
+ if Parent (List_Containing (Get_Unit_Instantiation_Node (Par)))
+ = Parent (List_Containing (N))
and then Sloc (Freeze_Node (Par)) < Sloc (N)
then
Insert_Freeze_Node_For_Instance (N, F_Node);
--- /dev/null
new file mode 100644
+++ gcc/testsuite/gnat.dg/nested_generic2.adb
@@ -0,0 +1,5 @@
+-- { dg-do compile }
+
+package body Nested_Generic2 is
+ procedure Dummy is null;
+end Nested_Generic2;
--- /dev/null
new file mode 100644
+++ gcc/testsuite/gnat.dg/nested_generic2.ads
@@ -0,0 +1,13 @@
+with Nested_Generic2_G1;
+with Nested_Generic2_G2;
+
+package Nested_Generic2 is
+
+ package My_G1 is new Nested_Generic2_G1 ("Lewis");
+ package My_G2 is new Nested_Generic2_G2 (T => Integer, P => My_G1);
+
+ procedure Dummy;
+
+private
+ package My_Nested is new My_G1.Nested ("Clark");
+end Nested_Generic2;
--- /dev/null
new file mode 100644
+++ gcc/testsuite/gnat.dg/nested_generic2_g1.adb
@@ -0,0 +1,15 @@
+package body Nested_Generic2_G1 is
+
+ procedure Debug (Msg : String; Prefix : String) is
+ begin
+ null;
+ end;
+
+ package body Nested is
+ procedure Debug (Msg : String) is
+ begin
+ Debug (Msg, Prefix);
+ end;
+ end Nested;
+
+end Nested_Generic2_G1;
--- /dev/null
new file mode 100644
+++ gcc/testsuite/gnat.dg/nested_generic2_g1.ads
@@ -0,0 +1,13 @@
+generic
+ S : String;
+package Nested_Generic2_G1 is
+
+ procedure Debug (Msg : String; Prefix : String);
+
+ generic
+ Prefix : String;
+ package Nested is
+ procedure Debug (Msg : String);
+ end Nested;
+
+end Nested_Generic2_G1;
--- /dev/null
new file mode 100644
+++ gcc/testsuite/gnat.dg/nested_generic2_g2.ads
@@ -0,0 +1,7 @@
+with Nested_Generic2_G1;
+
+generic
+ type T is private;
+ with package P is new Nested_Generic2_G1 (<>);
+package Nested_Generic2_G2 is
+end Nested_Generic2_G2;
[Ada] Performance degradation with references
This patch modifies the creation of markers for variable references in the context of SPARK elaboration checks. Previously, prior to checking whether a reference requires such a marker, the compiler performed a logarithmic look up to determine whether the reference appears within a call. This action caused the compiler to degrade when a source program contains multiple (100,000s) references. Now, the compiler no longer performs the look up immediately. Tested on x86_64-pc-linux-gnu, committed on trunk 2018-06-11 Hristian Kirtchev gcc/ada/ * sem_ch8.adb (Find_Direct_Name): Mode the declaration of Is_Assignment_LHS further in. Use predicate Needs_Variable_Reference_Marker to determine whether to create a variable marker. (Find_Expanded_Name): Mode the declaration of Is_Assignment_LHS further in. Use predicate Needs_Variable_Reference_Marker to determine whether to create a variable marker. * sem_elab.adb (Build_Variable_Reference_Marker): Remove the various checks that determine whether the identifier or expanded name is a suitable variable reference. The checks are now performed by Needs_Variable_Reference_Marker. * sem_res.adb (Resolve_Actuals): Use predicate Needs_Variable_Reference_Marker to determine whether to create a variable marker. * sem_util.adb (Needs_Variable_Reference_Marker): New routine. * sem_util.ads (Needs_Variable_Reference_Marker): New routine.--- gcc/ada/sem_ch8.adb +++ gcc/ada/sem_ch8.adb @@ -5423,8 +5423,6 @@ package body Sem_Ch8 is -- Local variables - Is_Assignment_LHS : constant Boolean := Is_LHS (N) = Yes; - Nested_Inst : Entity_Id := Empty; -- The entity of a nested instance which appears within Inst (if any) @@ -5970,11 +5968,19 @@ package body Sem_Ch8 is -- reference is a write when it appears on the left hand side of an -- assignment. - if not Within_Subprogram_Call (N) then - Build_Variable_Reference_Marker - (N => N, -Read => not Is_Assignment_LHS, -Write => Is_Assignment_LHS); + if Needs_Variable_Reference_Marker + (N=> N, +Calls_OK => False) + then + declare +Is_Assignment_LHS : constant Boolean := Is_LHS (N) = Yes; + + begin +Build_Variable_Reference_Marker + (N => N, + Read => not Is_Assignment_LHS, + Write => Is_Assignment_LHS); + end; end if; end Find_Direct_Name; @@ -6047,8 +6053,7 @@ package body Sem_Ch8 is -- Local variables - Is_Assignment_LHS : constant Boolean := Is_LHS (N) = Yes; - Selector : constant Node_Id := Selector_Name (N); + Selector : constant Node_Id := Selector_Name (N); Candidate : Entity_Id := Empty; P_Name: Entity_Id; @@ -6621,11 +6626,19 @@ package body Sem_Ch8 is -- reference is a write when it appears on the left hand side of an -- assignment. - if not Within_Subprogram_Call (N) then - Build_Variable_Reference_Marker - (N => N, -Read => not Is_Assignment_LHS, -Write => Is_Assignment_LHS); + if Needs_Variable_Reference_Marker + (N=> N, +Calls_OK => False) + then + declare +Is_Assignment_LHS : constant Boolean := Is_LHS (N) = Yes; + + begin +Build_Variable_Reference_Marker + (N => N, + Read => not Is_Assignment_LHS, + Write => Is_Assignment_LHS); + end; end if; end Find_Expanded_Name; @@ -8301,7 +8314,6 @@ package body Sem_Ch8 is -- procedure Mark_Use_Clauses (Id : Node_Or_Entity_Id) is - procedure Mark_Parameters (Call : Entity_Id); -- Perform use_type_clause marking for all parameters in a subprogram -- or operator call. --- gcc/ada/sem_elab.adb +++ gcc/ada/sem_elab.adb @@ -2072,8 +2072,8 @@ package body Sem_Elab is if Legacy_Elaboration_Checks then return; - -- Nothing to do for ASIS. As a result, ABE checks and diagnostics are - -- not performed in this mode. + -- Nothing to do for ASIS because ABE checks and diagnostics are not + -- performed in this mode. elsif ASIS_Mode then return; @@ -2274,166 +2274,16 @@ package body Sem_Elab is Read : Boolean; Write : Boolean) is - function In_Compilation_Instance_Formal_Part -(Nod : Node_Id) return Boolean; - -- Determine whether arbitrary node Nod appears within the formal part - -- of an instantiation which acts as a compilation unit. - - function In_Pragma (Nod : Node_Id) return Boolean; - -- Determine whether arbitrary node Nod appears within a pragma - -
[PATCH,MIPS] Fix pr86067 ICE: scal-to-vec1.c:86:1: error: unrecognizable insn with -march=loongson3a
Hi:
The gcc.c-torture/execute/scal-to-vec1.c trigger a gcc ICE bug.
It's a mistake in define_expand vec_setv4hi in loongson.md file.
375 (define_expand "vec_setv4hi"
376 [(set (match_operand:V4HI 0 "register_operand" "=f")
377 (unspec:V4HI [(match_operand:V4HI 1 "register_operand" "f")
378 (match_operand:HI 2 "register_operand" "f")
379 (match_operand:SI 3 "const_0_to_3_operand" "")]
380 UNSPEC_LOONGSON_PINSRH))]
381 "TARGET_HARD_FLOAT && TARGET_LOONGSON_VECTORS"
382 {
383 rtx ext = gen_reg_rtx (SImode);
384 emit_move_insn (ext, gen_lowpart (SImode, operands[1]));
385 operands[1] = ext;
386 })
The line 384 gen_lowpart the operands[1], should be gen_lowpart
operands[2], cause the operands[2] are HImode.
The attached patch fixed this bug.
Bootstrapped and reg-tested on mips64el-unknown-linux-gnu.
Ok for commit ?
---
2018-03-24 Chenghua Xu
PR c/target 86076
* gcc/config/mips/loongson.md (vec_setv4hi): Gen_lowpart for operands[2]
instead of operands[1].
diff --git a/gcc/config/mips/loongson.md b/gcc/config/mips/loongson.md
index 38912ac..14794d3 100644
--- a/gcc/config/mips/loongson.md
+++ b/gcc/config/mips/loongson.md
@@ -381,8 +381,8 @@
"TARGET_HARD_FLOAT && TARGET_LOONGSON_VECTORS"
{
rtx ext = gen_reg_rtx (SImode);
- emit_move_insn (ext, gen_lowpart (SImode, operands[1]));
- operands[1] = ext;
+ emit_move_insn (ext, gen_lowpart (SImode, operands[2]));
+ operands[2] = ext;
})
;; Multiply and add packed integers.
Re: [RFC][PR64946] "abs" vectorization fails for char/short types
Hi Richard,
Thanks for the review and sorry for getting back to you late.
On 4 June 2018 at 18:38, Richard Biener wrote:
> On Mon, Jun 4, 2018 at 10:18 AM Kugan Vivekanandarajah
> wrote:
>>
>> Hi Richard,
>>
>> Thanks for the review.
>>
>> On 1 June 2018 at 22:20, Richard Biener wrote:
>> > On Fri, Jun 1, 2018 at 4:12 AM Kugan Vivekanandarajah
>> > wrote:
>> >>
>> >> Hi Richard,
>> >>
>> >> This is the revised patch based on the review and the discussion in
>> >> https://gcc.gnu.org/ml/gcc/2018-05/msg00179.html.
>> >>
>> >> In summary:
>> >> - I skipped (element_precision (type) < element_precision (TREE_TYPE
>> >> (@0))) in the match.pd pattern as this would prevent transformation
>> >> for the case in PR.
>> >> that is, I am interested in is something like:
>> >> char t = (char) ABS_EXPR <(int) x>
>> >> and I want to generate
>> >> char t = (char) ABSU_EXPR
>> >>
>> >> - I also haven't added all the necessary match.pd changes for
>> >> ABSU_EXPR. I have a patch for that but will submit separately based on
>> >> this reveiw.
>> >>
>> >> - I also tried to add ABSU_EXPRsupport in the places as necessary by
>> >> grepping for ABS_EXPR.
>> >>
>> >> - I also had to add special casing in vectorizer for ABSU_EXP as its
>> >> result is unsigned type.
>> >>
>> >> Is this OK. Patch bootstraps and the regression test is ongoing.
>> >
>> > The c/c-typeck.c:build_unary_op change looks unnecessary - the
>> > C FE should never generate this directly (the c-common one might
>> > be triggered by early folding I guess).
>>
>> The Gimple FE testcase is running into this.
>
> Ah, OK then.
>
>> >
>> > @@ -1761,6 +1762,9 @@ const_unop (enum tree_code code, tree type, tree
>> > arg0)
>> >if (TREE_CODE (arg0) == INTEGER_CST || TREE_CODE (arg0) == REAL_CST)
>> > return fold_abs_const (arg0, type);
>> >break;
>> > +case ABSU_EXPR:
>> > + return fold_convert (type, fold_abs_const (arg0,
>> > + signed_type_for
>> > (type)));
>> >
>> > case CONJ_EXPR:
>> >
>> > I think this will get you bogus TREE_OVERFLOW flags set on ABSU (-INT_MIN).
>> >
>> > I think you want to change fold_abs_const to properly deal with arg0 being
>> > signed and type unsigned. That is, sth like
>> >
>> > diff --git a/gcc/fold-const.c b/gcc/fold-const.c
>> > index 6f80f1b1d69..f60f9c77e91 100644
>> > --- a/gcc/fold-const.c
>> > +++ b/gcc/fold-const.c
>> > @@ -13843,18 +13843,19 @@ fold_abs_const (tree arg0, tree type)
>> >{
>> > /* If the value is unsigned or non-negative, then the absolute
>> > value
>> >is the same as the ordinary value. */
>> > - if (!wi::neg_p (wi::to_wide (arg0), TYPE_SIGN (type)))
>> > - t = arg0;
>> > + wide_int val = wi::to_wide (arg0);
>> > + bool overflow = false;
>> > + if (!wi::neg_p (val, TYPE_SIGN (TREE_TYPE (arg0
>> > + ;
>> >
>> > /* If the value is negative, then the absolute value is
>> >its negation. */
>> > else
>> > - {
>> > - bool overflow;
>> > - wide_int val = wi::neg (wi::to_wide (arg0), );
>> > - t = force_fit_type (type, val, -1,
>> > - overflow | TREE_OVERFLOW (arg0));
>> > - }
>> > + wide_int val = wi::neg (val, );
>> > +
>> > + /* Force to the destination type, set TREE_OVERFLOW for signed
>> > + TYPE only. */
>> > + t = force_fit_type (type, val, 1, overflow | TREE_OVERFLOW (arg0));
>> >}
>> >break;
>> >
>> > and then simply share the const_unop code with ABS_EXPR.
>>
>> Done.
>>
>> > diff --git a/gcc/match.pd b/gcc/match.pd
>> > index 14386da..7d7c132 100644
>> > --- a/gcc/match.pd
>> > +++ b/gcc/match.pd
>> > @@ -102,6 +102,14 @@ DEFINE_INT_AND_FLOAT_ROUND_FN (RINT)
>> > (match (nop_convert @0)
>> > @0)
>> >
>> > +(simplify (abs (convert @0))
>> > + (if (ANY_INTEGRAL_TYPE_P (TREE_TYPE (@0))
>> > + && !TYPE_UNSIGNED (TREE_TYPE (@0))
>> > + && !TYPE_UNSIGNED (type))
>> > + (with { tree utype = unsigned_type_for (TREE_TYPE (@0)); }
>> > + (convert (absu:utype @0)
>> > +
>> > +
>> >
>> > please put a comment before the pattern. I believe there's no
>> > need to check for !TYPE_UNSIGNED (type). Note this
>> > also converts abs ((char)int-var) to (char)absu(int-var) which
>> > doesn't make sense. The original issue you want to address
>> > here is the case where TYPE_PRECISION of @0 is less than
>> > the precision of type. That is, you want to remove language
>> > introduced integer promotion of @0 which only is possible
>> > with ABSU. So please do add such precision check
>> > (I simply suggested the bogus direction of the test).
>>
>> Done.
>> >
>> > diff --git a/gcc/tree-cfg.c b/gcc/tree-cfg.c
>> > index 68f4fd3..9b62583 100644
>> > --- a/gcc/tree-cfg.c
>> > +++ b/gcc/tree-cfg.c
>> > @@ -3685,6 +3685,12 @@ verify_gimple_assign_unary (gassign *stmt)
>> > case
[PATCH v3] add support for --disable-gcov
For some targets (in my case VxWorks 5.5), libgcov does not compile due
to missing functions and macros such as getpid() and F_OK.
Incidentally, gcc/Makefile.in already contains comments such as
# Install gcov if it was compiled.
but there is no logic in place to actually allow gcov to not be
compiled.
So add an option for disabling build and install of libgcov and the
related host tools.
2018-06-10 Rasmus Villemoes
gcc/
* configure.ac: Add --disable-gcov option.
* configure: Regenerate.
* Makefile.in: Honour @enable_gcov@.
* doc/install.texi: Document --disable-gcov.
libgcc/
* configure.ac: Add --disable-gcov option.
* configure: Regenerate.
* Makefile.in: Honour @enable_gcov@.
---
gcc/Makefile.in | 6 --
gcc/configure.ac | 5 +
gcc/doc/install.texi | 4
libgcc/Makefile.in | 8 +++-
libgcc/configure.ac | 5 +
5 files changed, 25 insertions(+), 3 deletions(-)
diff --git a/gcc/Makefile.in b/gcc/Makefile.in
index d8f3e886118..1f38cacde7a 100644
--- a/gcc/Makefile.in
+++ b/gcc/Makefile.in
@@ -137,8 +137,10 @@ SUBDIRS =@subdirs@ build
# Selection of languages to be made.
CONFIG_LANGUAGES = @all_selected_languages@
-LANGUAGES = c gcov$(exeext) gcov-dump$(exeext) gcov-tool$(exeext) \
-$(CONFIG_LANGUAGES)
+LANGUAGES = c $(CONFIG_LANGUAGES)
+ifeq (@enable_gcov@,yes)
+LANGUAGES += gcov$(exeext) gcov-dump$(exeext) gcov-tool$(exeext)
+endif
# Default values for variables overridden in Makefile fragments.
# CFLAGS is for the user to override to, e.g., do a cross build with -O2.
diff --git a/gcc/configure.ac b/gcc/configure.ac
index 010ecd2ccf6..4fc851c644e 100644
--- a/gcc/configure.ac
+++ b/gcc/configure.ac
@@ -921,6 +921,11 @@ AC_ARG_ENABLE(shared,
], [enable_shared=yes])
AC_SUBST(enable_shared)
+AC_ARG_ENABLE(gcov,
+[ --disable-gcov don't provide libgcov and related host tools],
+[], [enable_gcov=yes])
+AC_SUBST(enable_gcov)
+
AC_ARG_WITH(specs,
[AS_HELP_STRING([--with-specs=SPECS],
[add SPECS to driver command-line processing])],
diff --git a/gcc/doc/install.texi b/gcc/doc/install.texi
index 7c5cdc762d3..03eaeed4e87 100644
--- a/gcc/doc/install.texi
+++ b/gcc/doc/install.texi
@@ -1044,6 +1044,10 @@ virtual calls in verifiable mode at all. However the
libvtv library will
still be built (see @option{--disable-libvtv} to turn off building libvtv).
@option{--disable-vtable-verify} is the default.
+@item --disable-gcov
+Specify that the run-time library used for coverage analysis
+and associated host tools should not be built.
+
@item --disable-multilib
Specify that multiple target
libraries to support different target variants, calling
diff --git a/libgcc/Makefile.in b/libgcc/Makefile.in
index dd8cee99fd3..b7f20557214 100644
--- a/libgcc/Makefile.in
+++ b/libgcc/Makefile.in
@@ -36,6 +36,7 @@ SHELL = @SHELL@
cpu_type = @cpu_type@
enable_shared = @enable_shared@
+enable_gcov = @enable_gcov@
double_type_size = @double_type_size@
long_double_type_size = @long_double_type_size@
decimal_float = @decimal_float@
@@ -941,7 +942,10 @@ libgcc.a libgcov.a libunwind.a libgcc_eh.a:
$(RANLIB) $@
-all: libgcc.a libgcov.a
+all: libgcc.a
+ifeq ($(enable_gcov),yes)
+all: libgcov.a
+endif
ifneq ($(LIBUNWIND),)
all: libunwind.a
@@ -1164,9 +1168,11 @@ install-leaf: $(install-shared) $(install-libunwind)
$(INSTALL_DATA) libgcc.a $(DESTDIR)$(inst_libdir)/
chmod 644 $(DESTDIR)$(inst_libdir)/libgcc.a
$(RANLIB) $(DESTDIR)$(inst_libdir)/libgcc.a
+ifeq ($(enable_libgcov),yes)
$(INSTALL_DATA) libgcov.a $(DESTDIR)$(inst_libdir)/
chmod 644 $(DESTDIR)$(inst_libdir)/libgcov.a
$(RANLIB) $(DESTDIR)$(inst_libdir)/libgcov.a
+endif
parts="$(INSTALL_PARTS)"; \
for file in $$parts; do \
diff --git a/libgcc/configure.ac b/libgcc/configure.ac
index b59aa746afc..9d0bbcaba86 100644
--- a/libgcc/configure.ac
+++ b/libgcc/configure.ac
@@ -68,6 +68,11 @@ AC_ARG_ENABLE(shared,
], [enable_shared=yes])
AC_SUBST(enable_shared)
+AC_ARG_ENABLE(gcov,
+[ --disable-gcov don't provide libgcov and related host tools],
+[], [enable_gcov=yes])
+AC_SUBST(enable_gcov)
+
AC_ARG_ENABLE(vtable-verify,
[ --enable-vtable-verifyEnable vtable verification feature ],
[case "$enableval" in
--
2.16.4
Re: [PATCH] handle non-constant character assignments in strlen (PR 86083)
On Sun, 10 Jun 2018, Martin Sebor wrote: The attached patch implements this idea. (I looked for a simple function that returns true/false based on whether a SSA_NAME is or isn't definitely non-zero but couldn't find one so I created one though it seems that extending one of the existing functions might be a better approach?) tree_expr_nonzero_p (don't know why the comment above talks about addresses), expr_not_equal_to. -- Marc Glisse
Re: [patch] dwarf2out don't discriminate on dwarf version for advertising Ada
> On 10 Jun 2018, at 21:26, Jakub Jelinek wrote:
>> http://wiki.dwarfstd.org/index.php?title=DWARF_Language_Support
>
> Well, you should better be looking at the pdfs of the standards, that is
> more precise.
Ok
> And there it says:
> Names marked with † and their associated values are reserved,
> but the languages they represent are not supported in DWARF Version 2.
> ...
> DW_LANG_Ada83†0x0003
>
> so, using DW_LANG_Ada83 is fine for dwarf-2.
Good,
>> 2018-06-10 Olivier Hainque
>>
>> * dwarf2out.c (gen_compile_unit_die): fallout to DW_LANG_Ada83
>> for Ada with strict dwarf2.
>
> Use uppercase Fallout.
> Otherwise ok for trunk.
Great, thanks!
FWIW, I was surprised by a gotcha while writing tests for this,
where both
{ dg-final { scan-assembler "0x3.*DW_AT_language" } }
and { dg-final { scan-assembler "0xd.*DW_AT_language" } }
matched for Ada95 (0xd) with -gdwarf-3.
scan-assembler uses "regexp" without --line, and 0x3 happened
to match from a much earlier line in the output, with an assembly
output like
bla 0x3 blo
0xd # DW_AT_language
I adjusted the regex not to match newline characters and the
test is now more accurate, then I noticed that other language tests
use '.*' so might be affected as well, unless I'm missing something.
Regards,
Olivier
[PATCH] Fix typo done in MPX removal (PR tree-optimization/86089).
Hi.
This is typo I did when MPX was removed. I'm moving back hunk with
BUILT_IN_STPCPY_CHK.
Ready after testing?
Martin
gcc/ChangeLog:
2018-06-11 Martin Liska
PR tree-optimization/86089
* tree-ssa-strlen.c (get_string_length): Move back removed hunk.
gcc/testsuite/ChangeLog:
2018-06-11 Martin Liska
PR tree-optimization/86089
* gcc.dg/tree-ssa/pr86089.c: New test.
---
gcc/testsuite/gcc.dg/tree-ssa/pr86089.c | 13 +
gcc/tree-ssa-strlen.c | 6 +-
2 files changed, 18 insertions(+), 1 deletion(-)
create mode 100644 gcc/testsuite/gcc.dg/tree-ssa/pr86089.c
diff --git a/gcc/testsuite/gcc.dg/tree-ssa/pr86089.c b/gcc/testsuite/gcc.dg/tree-ssa/pr86089.c
new file mode 100644
index 000..58d542949cb
--- /dev/null
+++ b/gcc/testsuite/gcc.dg/tree-ssa/pr86089.c
@@ -0,0 +1,13 @@
+/* { dg-do compile } */
+/* { dg-options "-O2 -Wall" } */
+
+extern char* stpcpy (char*, const char*);
+
+int f (char* s)
+{
+ char a[32];
+
+ __builtin___strcpy_chk (a, s, __builtin_object_size (a, 1));
+
+ return __builtin_strlen (a);
+}
diff --git a/gcc/tree-ssa-strlen.c b/gcc/tree-ssa-strlen.c
index 804905d09a2..50562144078 100644
--- a/gcc/tree-ssa-strlen.c
+++ b/gcc/tree-ssa-strlen.c
@@ -617,8 +617,12 @@ get_string_length (strinfo *si)
lhs = NULL_TREE;
/* FALLTHRU */
case BUILT_IN_STRCPY:
+ case BUILT_IN_STRCPY_CHK:
gcc_assert (builtin_decl_implicit_p (BUILT_IN_STPCPY));
- fn = builtin_decl_implicit (BUILT_IN_STPCPY);
+ if (gimple_call_num_args (stmt) == 2)
+ fn = builtin_decl_implicit (BUILT_IN_STPCPY);
+ else
+ fn = builtin_decl_explicit (BUILT_IN_STPCPY_CHK);
gcc_assert (lhs == NULL_TREE);
if (dump_file && (dump_flags & TDF_DETAILS) != 0)
{
Re: [ARM/FDPIC 13/21] [ARM] FDPIC: Support unwinding across thumb2 signal trampoline
On 8 June 2018 at 13:01, Kyrill Tkachov wrote:
> Hi Christophe,
>
> Similar comments to patch 11/21
>
>
> On 25/05/18 09:03, Christophe Lyon wrote:
>>
>> 2018-XX-XX Christophe Lyon
>> Mickaël Guêné
>>
>> libgcc/
>> * unwind-arm-common.inc (FDPIC_T2_LDR_R12_WITH_FUNCDESC)
>> (FDPIC_T2_LDR_R9_WITH_GOT, FDPIC_T2_LDR_PC_WITH_RESTORER): New.
>> (__gnu_personality_sigframe_fdpic): Support Thumb address.
>> (get_eit_entry): Support Thumb code.
>>
>> Change-Id: I2bb8994e733e48a89c6f4e0682921186c086f8bc
>>
>> diff --git a/libgcc/unwind-arm-common.inc b/libgcc/unwind-arm-common.inc
>> index 80d1e88..7de4033 100644
>> --- a/libgcc/unwind-arm-common.inc
>> +++ b/libgcc/unwind-arm-common.inc
>> @@ -38,6 +38,9 @@
>> #define FDPIC_LDR_R12_WITH_FUNCDESC 0xe59fc004
>> #define FDPIC_LDR_R9_WITH_GOT 0xe59c9004
>> #define FDPIC_LDR_PC_WITH_RESTORER 0xe59cf000
>> +#define FDPIC_T2_LDR_R12_WITH_FUNCDESC 0xc008f8df
>> +#define FDPIC_T2_LDR_R9_WITH_GOT 0x9004f8dc
>> +#define FDPIC_T2_LDR_PC_WITH_RESTORER 0xf000f8dc
>> #define FDPIC_FUNCDESC_OFFSET 12
>> /* Signal frame offsets. */
>> #define ARM_NEW_RT_SIGFRAME_UCONTEXT0x80
>> @@ -228,7 +231,7 @@ __gnu_personality_sigframe_fdpic (_Unwind_State state,
>> _Unwind_VRS_Get (context, _UVRSC_CORE, R_SP, _UVRSD_UINT32, );
>> _Unwind_VRS_Get (context, _UVRSC_CORE, R_PC, _UVRSD_UINT32, );
>>
>> -funcdesc = *(unsigned int *)(pc + FDPIC_FUNCDESC_OFFSET);
>> +funcdesc = *(unsigned int *)((pc & ~1) + FDPIC_FUNCDESC_OFFSET);
>> handler = *(unsigned int *)(funcdesc);
>> first_handler_instruction = *(unsigned int *)(handler & ~1);
>>
>> @@ -277,10 +280,13 @@ get_eit_entry (_Unwind_Control_Block *ucbp, _uw
>> return_address)
>>/* If we are unwinding a signal handler then perhaps we have
>> reached a trampoline. Try to detect jump to restorer
>> sequence. */
>> - _uw *pc = (_uw *)((return_address+2) & ~3);
>> - if (pc[0] == FDPIC_LDR_R12_WITH_FUNCDESC
>> - && pc[1] == FDPIC_LDR_R9_WITH_GOT
>> - && pc[2] == FDPIC_LDR_PC_WITH_RESTORER)
>> + _uw *pc = (_uw *)((return_address+2) & ~1);
>> + if ((pc[0] == FDPIC_LDR_R12_WITH_FUNCDESC
>> + && pc[1] == FDPIC_LDR_R9_WITH_GOT
>> + && pc[2] == FDPIC_LDR_PC_WITH_RESTORER)
>> + || (pc[0] == FDPIC_T2_LDR_R12_WITH_FUNCDESC
>> + && pc[1] == FDPIC_T2_LDR_R9_WITH_GOT
>> + && pc[2] == FDPIC_T2_LDR_PC_WITH_RESTORER))
>> {
>
>
> This largely overwrites and extends code added in patch 11/21. Can't we just
> merge the two
> patches into a final sane one?
>
Sure. It was developed in two steps, and I thought it was easier to
review in small pieces, but I can merge them.
> Thanks,
> Kyrill
>
>
>>struct funcdesc_t *funcdesc = (struct funcdesc_t *)
>> &__gnu_personality_sigframe_fdpic;
>> @@ -309,13 +315,16 @@ get_eit_entry (_Unwind_Control_Block *ucbp, _uw
>> return_address)
>>/* If we are unwinding a signal handler then perhaps we have
>> reached a trampoline. Try to detect jump to restorer
>> sequence. */
>> - _uw *pc = (_uw *)((return_address+2) & ~3);
>> - if (pc[0] == FDPIC_LDR_R12_WITH_FUNCDESC
>> - && pc[1] == FDPIC_LDR_R9_WITH_GOT
>> - && pc[2] == FDPIC_LDR_PC_WITH_RESTORER)
>> + _uw *pc = (_uw *)((return_address+2) & ~1);
>> + if ((pc[0] == FDPIC_LDR_R12_WITH_FUNCDESC
>> + && pc[1] == FDPIC_LDR_R9_WITH_GOT
>> + && pc[2] == FDPIC_LDR_PC_WITH_RESTORER)
>> + || (pc[0] == FDPIC_T2_LDR_R12_WITH_FUNCDESC
>> + && pc[1] == FDPIC_T2_LDR_R9_WITH_GOT
>> + && pc[2] == FDPIC_T2_LDR_PC_WITH_RESTORER))
>> {
>> - struct funcdesc_t *funcdesc = (struct funcdesc_t *)
>> - &__gnu_personality_sigframe_fdpic;
>> + struct funcdesc_t *funcdesc
>> + = (struct funcdesc_t *) &__gnu_personality_sigframe_fdpic;
>>
>>UCB_PR_ADDR (ucbp) = funcdesc->ptr;
>>UCB_PR_GOT (ucbp) = funcdesc->got;
>> @@ -335,13 +344,16 @@ get_eit_entry (_Unwind_Control_Block *ucbp, _uw
>> return_address)
>>/* If we are unwinding a signal handler then perhaps we have
>> reached a trampoline. Try to detect jump to restorer
>> sequence. */
>> - _uw *pc = (_uw *)((return_address+2) & ~3);
>> - if (pc[0] == FDPIC_LDR_R12_WITH_FUNCDESC
>> - && pc[1] == FDPIC_LDR_R9_WITH_GOT
>> - && pc[2] == FDPIC_LDR_PC_WITH_RESTORER)
>> + _uw *pc = (_uw *)((return_address+2) & ~1);
>> + if ((pc[0] == FDPIC_LDR_R12_WITH_FUNCDESC
>> + && pc[1] == FDPIC_LDR_R9_WITH_GOT
>> + && pc[2] == FDPIC_LDR_PC_WITH_RESTORER)
>> + || (pc[0] == FDPIC_T2_LDR_R12_WITH_FUNCDESC
>> + && pc[1] == FDPIC_T2_LDR_R9_WITH_GOT
>> +
Re: [ARM/FDPIC 10/21] [ARM] FDPIC: Implement legitimize_tls_address_fdpic
On 8 June 2018 at 12:41, Kyrill Tkachov wrote:
> Hi Christophe,
>
>
> On 25/05/18 09:03, Christophe Lyon wrote:
>>
>> Support additional relocations: TLS_GD32_FDPIC, TLS_LDM32_FDPIC, and
>> TLS_IE32_FDPIC.
>>
>> We do not support the GNU2 TLS dialect.
>>
>> 2018-XX-XX Christophe Lyon
>> Mickaël Guêné
>>
>> gcc/
>> * config/arm/arm.c (tls_reloc): Add TLS_GD32_FDPIC,
>> TLS_LDM32_FDPIC and TLS_IE32_FDPIC.
>> (arm_call_tls_get_addr_fdpic): New.
>> (legitimize_tls_address_fdpic): New.
>> (legitimize_tls_address_not_fdpic): New.
>> (legitimize_tls_address): Add FDPIC support.
>> (arm_emit_tls_decoration): Likewise.
>>
>> Change-Id: I4ea5034ff654540c4658d0a79fb92f70550cdf4a
>>
>> diff --git a/gcc/config/arm/arm.c b/gcc/config/arm/arm.c
>> index 2434602..20b8f66 100644
>> --- a/gcc/config/arm/arm.c
>> +++ b/gcc/config/arm/arm.c
>> @@ -2373,9 +2373,12 @@ char arm_arch_name[] = "__ARM_ARCH_PROFILE__";
>>
>> enum tls_reloc {
>>TLS_GD32,
>> + TLS_GD32_FDPIC,
>>TLS_LDM32,
>> + TLS_LDM32_FDPIC,
>>TLS_LDO32,
>>TLS_IE32,
>> + TLS_IE32_FDPIC,
>>TLS_LE32,
>>TLS_DESCSEQ /* GNU scheme */
>> };
>> @@ -8681,6 +8684,30 @@ load_tls_operand (rtx x, rtx reg)
>> }
>>
>> static rtx_insn *
>> +arm_call_tls_get_addr_fdpic (rtx x, rtx reg, rtx *valuep, int reloc)
>> +{
>
>
> Please add a function comment
>
>> + rtx sum;
>> +
>> + gcc_assert (reloc != TLS_DESCSEQ);
>> + start_sequence ();
>> +
>> + sum = gen_rtx_UNSPEC (Pmode,
>> + gen_rtvec (2, x, GEN_INT (reloc)),
>> + UNSPEC_TLS);
>> + reg = load_tls_operand (sum, reg);
>> + emit_insn (gen_addsi3 (reg, reg, gen_rtx_REG (Pmode, 9)));
>> +
>> + *valuep = emit_library_call_value (get_tls_get_addr (), NULL_RTX,
>> +LCT_PURE, /* LCT_CONST? */
>> +Pmode, reg, Pmode);
>
>
> I prefer to avoid comments with such question marks. Is there some ambiguity
> on which should be used?
>
>> +
>> + rtx_insn *insns = get_insns ();
>> + end_sequence ();
>> +
>> + return insns;
>> +}
>> +
>> +static rtx_insn *
>> arm_call_tls_get_addr (rtx x, rtx reg, rtx *valuep, int reloc)
>> {
>>rtx label, labelno, sum;
>> @@ -8736,8 +8763,84 @@ arm_tls_descseq_addr (rtx x, rtx reg)
>>return reg;
>> }
>>
>> -rtx
>> -legitimize_tls_address (rtx x, rtx reg)
>> +static rtx
>> +legitimize_tls_address_fdpic (rtx x, rtx reg)
>> +{
>
>
> Please add a function comment, even if it's just a simple one.
>
>> +rtx dest, ret, eqv, addend, sum, tp;
>> +rtx_insn *insns;
>> +unsigned int model = SYMBOL_REF_TLS_MODEL (x);
>> +
>> +switch (model)
>> + {
>> + case TLS_MODEL_GLOBAL_DYNAMIC:
>> + if (TARGET_GNU2_TLS)
>> + {
>> + abort ();
>> + }
>
>
> Use gcc_unreachable ().
>
>> + else
>> + {
>> + /* Original scheme. */
>> + insns = arm_call_tls_get_addr_fdpic (x, reg, ,
>> TLS_GD32_FDPIC);
>> + dest = gen_reg_rtx (Pmode);
>> + emit_libcall_block (insns, dest, ret, x);
>> + }
>> + return dest;
>> + break;
>> +
>> + case TLS_MODEL_LOCAL_DYNAMIC:
>> + if (TARGET_GNU2_TLS)
>> + {
>> + abort ();
>> + }
>
>
> Likewise.
>
>> + else
>> + {
>> + insns = arm_call_tls_get_addr_fdpic (x, reg, ,
>> TLS_LDM32_FDPIC);
>> + /* Attach a unique REG_EQUIV, to allow the RTL optimizers to
>> + share the LDM result with other LD model accesses. */
>> + eqv = gen_rtx_UNSPEC (Pmode, gen_rtvec (1, const1_rtx),
>> + UNSPEC_TLS);
>> + dest = gen_reg_rtx (Pmode);
>> + emit_libcall_block (insns, dest, ret, eqv);
>> +
>> + /* Load the addend. */
>> + addend = gen_rtx_UNSPEC (Pmode,
>> +gen_rtvec (2, x, GEN_INT
>> (TLS_LDO32)),
>> +UNSPEC_TLS);
>> + addend = force_reg (SImode, gen_rtx_CONST (SImode, addend));
>
>
> Nit I'm guessing, but I think this SImode should be Pmode.
>
>> + dest = gen_rtx_PLUS (Pmode, dest, addend);
>> + }
>> + return dest;
>> + break;
>> +
>> + case TLS_MODEL_INITIAL_EXEC:
>> + sum = gen_rtx_UNSPEC (Pmode,
>> + gen_rtvec (2, x, GEN_INT (TLS_IE32_FDPIC)),
>> + UNSPEC_TLS);
>> + reg = load_tls_operand (sum, reg);
>> + /* FIXME: optimize below? */
>
>
> Not a fan of such FIXMEs. Let's either optimise it now or leave the comment
> out.
>
>> + emit_insn (gen_addsi3 (reg, reg, gen_rtx_REG (Pmode, 9)));
>> + emit_insn (gen_movsi (reg, gen_rtx_MEM (Pmode, reg)));
>
>
> You can use the shorter emit_move_insn (). I think there are other places in
> the series
> where you can do that as well.
>
>> + tp =
Re: [ARM/FDPIC 09/21] [ARM] FDPIC: Add support for taking address of nested function
On 8 June 2018 at 12:33, Kyrill Tkachov wrote:
> Hi Chrishophe,
>
> Could you please provide a description of what this patch does and how it
> achieves that?
>
OK, I'l try to do some archaeology and formulate a description.
>
> On 25/05/18 09:03, Christophe Lyon wrote:
>>
>> 2018-XX-XX Christophe Lyon
>> Mickaël Guêné
>>
>> gcc/
>> * config/arm/arm.c (arm_asm_trampoline_template): Add FDPIC
>> support.
>> (arm_trampoline_init): Likewise.
>> (arm_trampoline_init): Likewise.
>> * config/arm/arm.h (TRAMPOLINE_SIZE): Likewise.
>>
>> Change-Id: I4b5127261a9aefa0f0318f110574ec07a856aeb1
>>
>> diff --git a/gcc/config/arm/arm.c b/gcc/config/arm/arm.c
>> index 025485d..2434602 100644
>> --- a/gcc/config/arm/arm.c
>> +++ b/gcc/config/arm/arm.c
>> @@ -3967,7 +3967,27 @@ arm_asm_trampoline_template (FILE *f)
>> {
>>fprintf (f, "\t.syntax unified\n");
>>
>> - if (TARGET_ARM)
>> + if (TARGET_FDPIC)
>> +{
>> + /* The first two words are a function descriptor to jump into
>> +the trampoline code just below. */
>> + if (TARGET_ARM) fprintf (f, "\t.arm\n");
>> + else if (TARGET_THUMB2) fprintf (f, "\t.thumb\n");
>> + else fprintf (f, "\t.code\t16\n");
>> +
>
>
> Please format this in GNU style.
Sorry for missing that. I did visually inspect all the patches and ran
check_GNU_style (both .sh and .py, none complained).
>
>> + assemble_aligned_integer (UNITS_PER_WORD, const0_rtx);
>> + assemble_aligned_integer (UNITS_PER_WORD, const0_rtx);
>> + /* Trampoline code which sets the static chain register but also
>> +PIC register before jumping into real code. */
>> + asm_fprintf (f, "\tldr\t%r, [%r, #%d]\n",
>> + STATIC_CHAIN_REGNUM, PC_REGNUM, TARGET_THUMB2?8:4);
>> + asm_fprintf (f, "\tldr\t%r, [%r, #%d]\n",
>> + PIC_OFFSET_TABLE_REGNUM, PC_REGNUM, TARGET_THUMB2?8:4);
>> + asm_fprintf (f, "\tldr\t%r, [%r, #%d]\n",
>> + PC_REGNUM, PC_REGNUM, TARGET_THUMB2?8:4);
>
>
> Likewise.
> Also, this will use offset 4 for TARGET_THUMB1. Given that you handle
> TARGET_THUMB1
> in the if statement above you expect this code can be entered for
> TARGET_THUMB1?
>
I'll check that,
Thanks
> Thanks,
> Kyrill
>
>
>> + assemble_aligned_integer (UNITS_PER_WORD, const0_rtx);
>> +}
>> + else if (TARGET_ARM)
>> {
>>fprintf (f, "\t.arm\n");
>>asm_fprintf (f, "\tldr\t%r, [%r, #0]\n", STATIC_CHAIN_REGNUM,
>> PC_REGNUM);
>> @@ -4008,12 +4028,37 @@ arm_trampoline_init (rtx m_tramp, tree fndecl, rtx
>> chain_value)
>>emit_block_move (m_tramp, assemble_trampoline_template (),
>> GEN_INT (TRAMPOLINE_SIZE), BLOCK_OP_NORMAL);
>>
>> - mem = adjust_address (m_tramp, SImode, TARGET_32BIT ? 8 : 12);
>> - emit_move_insn (mem, chain_value);
>> + if (TARGET_FDPIC)
>> +{
>> + rtx funcdesc = XEXP (DECL_RTL (fndecl), 0);
>> + rtx fnaddr = gen_rtx_MEM (Pmode, funcdesc);
>> + rtx gotaddr = gen_rtx_MEM (Pmode, plus_constant (Pmode, funcdesc,
>> 4));
>> + rtx trampolineCodeStart
>> + = plus_constant (Pmode, XEXP (m_tramp, 0), TARGET_THUMB2 ? 9 : 8);
>> +
>> + /* Write initial funcdesc which will jump into trampoline. */
>> + mem = adjust_address (m_tramp, SImode, 0);
>> + emit_move_insn (mem, trampolineCodeStart);
>> + mem = adjust_address (m_tramp, SImode, 4);
>> + emit_move_insn (mem, gen_rtx_REG (Pmode, PIC_OFFSET_TABLE_REGNUM));
>> + /* Setup static chain. */
>> + mem = adjust_address (m_tramp, SImode, 20);
>> + emit_move_insn (mem, chain_value);
>> + /* GOT + real function entry point. */
>> + mem = adjust_address (m_tramp, SImode, 24);
>> + emit_move_insn (mem, gotaddr);
>> + mem = adjust_address (m_tramp, SImode, 28);
>> + emit_move_insn (mem, fnaddr);
>> +}
>> + else
>> +{
>> + mem = adjust_address (m_tramp, SImode, TARGET_32BIT ? 8 : 12);
>> + emit_move_insn (mem, chain_value);
>>
>> - mem = adjust_address (m_tramp, SImode, TARGET_32BIT ? 12 : 16);
>> - fnaddr = XEXP (DECL_RTL (fndecl), 0);
>> - emit_move_insn (mem, fnaddr);
>> + mem = adjust_address (m_tramp, SImode, TARGET_32BIT ? 12 : 16);
>> + fnaddr = XEXP (DECL_RTL (fndecl), 0);
>> + emit_move_insn (mem, fnaddr);
>> +}
>>
>>a_tramp = XEXP (m_tramp, 0);
>>emit_library_call (gen_rtx_SYMBOL_REF (Pmode, "__clear_cache"),
>> @@ -4027,7 +4072,9 @@ arm_trampoline_init (rtx m_tramp, tree fndecl, rtx
>> chain_value)
>> static rtx
>> arm_trampoline_adjust_address (rtx addr)
>> {
>> - if (TARGET_THUMB)
>> + /* For FDPIC don't fix trampoline address since it's a function
>> + descriptor and not a function address. */
>> + if (TARGET_THUMB && !TARGET_FDPIC)
>> addr = expand_simple_binop (Pmode, IOR, addr, const1_rtx,
>> NULL, 0, OPTAB_LIB_WIDEN);
>>return addr;
>> diff --git
Re: [ARM/FDPIC 04/21] [ARM] FDPIC: Add support for FDPIC for arm architecture
On 8 June 2018 at 12:31, Kyrill Tkachov wrote:
> Hi Christophe,
>
>
> On 25/05/18 09:03, Christophe Lyon wrote:
>>
>> The FDPIC register is hard-coded to r9, as defined in the ABI.
>>
>> We have to disable tailcall optimizations if we don't know if the
>> target function is in the same module. If not, we have to set r9 to
>> the value associated with the target module.
>>
>> When generating a symbol address, we have to take into account whether
>> it is a pointer to data or to a function, because different
>> relocations are needed.
>>
>> 2018-XX-XX Christophe Lyon
>> Mickaël Guêné
>>
>> * config/arm/arm-c.c (__FDPIC__): Define new pre-processor macro
>> in FDPIC mode.
>> * config/arm/arm-protos.h (arm_load_function_descriptor): Declare
>> new function.
>> * config/arm/arm.c (arm_option_override): Define pic register to
>> r9.
>> (arm_function_ok_for_sibcall) Disable sibcall optimization if we
>> have no decl or go through PLT.
>> (arm_load_pic_register): Handle TARGET_FDPIC.
>> (arm_is_segment_info_known): New function.
>> (arm_pic_static_addr): Add support for FDPIC.
>> (arm_load_function_descriptor): New function.
>> (arm_assemble_integer): Add support for FDPIC.
>> * config/arm/arm.h (PIC_OFFSET_TABLE_REG_CALL_CLOBBERED): Define.
>> * config/arm/arm.md (call): Add support for FDPIC.
>> (call_value): Likewise.
>> (*restore_pic_register_after_call): New pattern.
>> (untyped_call): Disable if FDPIC.
>> (untyped_return): Likewise.
>> * config/arm/unspecs.md (UNSPEC_PIC_RESTORE): New.
>>
>> Change-Id: Icee8484772f97ac6f3a9574df4aa4f25a8196786
>>
>> diff --git a/gcc/config/arm/arm-c.c b/gcc/config/arm/arm-c.c
>> index 4471f79..90733cc 100644
>> --- a/gcc/config/arm/arm-c.c
>> +++ b/gcc/config/arm/arm-c.c
>> @@ -202,6 +202,8 @@ arm_cpu_builtins (struct cpp_reader* pfile)
>>builtin_define ("__ARM_EABI__");
>> }
>>
>> + def_or_undef_macro (pfile, "__FDPIC__", TARGET_FDPIC);
>> +
>>def_or_undef_macro (pfile, "__ARM_ARCH_EXT_IDIV__", TARGET_IDIV);
>>def_or_undef_macro (pfile, "__ARM_FEATURE_IDIV", TARGET_IDIV);
>>
>> diff --git a/gcc/config/arm/arm-protos.h b/gcc/config/arm/arm-protos.h
>> index 8537262..edebeb7 100644
>> --- a/gcc/config/arm/arm-protos.h
>> +++ b/gcc/config/arm/arm-protos.h
>> @@ -134,6 +134,7 @@ extern int arm_max_const_double_inline_cost (void);
>> extern int arm_const_double_inline_cost (rtx);
>> extern bool arm_const_double_by_parts (rtx);
>> extern bool arm_const_double_by_immediates (rtx);
>> +extern rtx arm_load_function_descriptor (rtx funcdesc);
>> extern void arm_emit_call_insn (rtx, rtx, bool);
>> bool detect_cmse_nonsecure_call (tree);
>> extern const char *output_call (rtx *);
>> diff --git a/gcc/config/arm/arm.c b/gcc/config/arm/arm.c
>> index 4a5da7e..56670e3 100644
>> --- a/gcc/config/arm/arm.c
>> +++ b/gcc/config/arm/arm.c
>> @@ -3475,6 +3475,12 @@ arm_option_override (void)
>>if (flag_pic && TARGET_VXWORKS_RTP)
>> arm_pic_register = 9;
>>
>> + /* If in FDPIC mode then force arm_pic_register to be r9. */
>> + if (TARGET_FDPIC)
>> +{
>> + arm_pic_register = 9;
>> +}
>> +
>
>
> Leave out the braces.
> Also, I believe you'll want to add option checking for TARGET_FDPIC.
> Your cover letter says that this series supports Armv7. So you should add
> checks in arm_override to error out on unsupported configurations
> appropriately
> (pre-Armv7? TARGET_THUMB1? float-abi configurations?)
>
Indeed, it will be cleaner.
Thanks
> Thanks,
> Kyrill
>
>
>>if (arm_pic_register_string != NULL)
>> {
>>int pic_register = decode_reg_name (arm_pic_register_string);
>> @@ -7256,6 +7262,21 @@ arm_function_ok_for_sibcall (tree decl, tree exp)
>>if (cfun->machine->sibcall_blocked)
>> return false;
>>
>> + if (TARGET_FDPIC)
>> +{
>> + /* In FDPIC, never tailcall something for which we have no decl:
>> +the target function could be in a different module, requiring
>> +a different r9 value. */
>> + if (decl == NULL)
>> + return false;
>> +
>> + /* Don't tailcall if we go through the PLT since r9 is then
>> +corrupted and we don't restore it for static function
>> +call. */
>> + if (!targetm.binds_local_p (decl))
>> + return false;
>> +}
>> +
>>/* Never tailcall something if we are generating code for Thumb-1. */
>>if (TARGET_THUMB1)
>> return false;
>> @@ -7634,7 +7655,9 @@ arm_load_pic_register (unsigned long saved_regs
>> ATTRIBUTE_UNUSED)
>> {
>>rtx l1, labelno, pic_tmp, pic_rtx, pic_reg;
>>
>> - if (crtl->uses_pic_offset_table == 0 || TARGET_SINGLE_PIC_BASE)
>> + if (crtl->uses_pic_offset_table == 0
>> + || TARGET_SINGLE_PIC_BASE
>> + || TARGET_FDPIC)
>> return;
>>
>>gcc_assert (flag_pic);
>> @@ -7702,28 +7725,167 @@ arm_load_pic_register
Re: [ARM/FDPIC 06/21] [ARM] FDPIC: Add support for c++ exceptions
On 8 June 2018 at 12:51, Richard Earnshaw (lists)
wrote:
> On 08/06/18 11:15, Kyrill Tkachov wrote:
>> Hi Christophe,
>>
>> On 25/05/18 09:03, Christophe Lyon wrote:
>>> When restoring a function address, we also have to restore the FDPIC
>>> register value (r9).
>>>
>>> 2018-XX-XX Christophe Lyon
>>> Mickaël Guêné
>>>
>>> gcc/
>>> * ginclude/unwind-arm-common.h (unwinder_cache): Add reserved5
>>> field.
>>>
>>> libgcc/
>>> * config/arm/linux-atomic.c (__ARM_ARCH__): Define.
>>> (__kernel_cmpxchg): Add FDPIC support.
>>> (__kernel_dmb): Likewise.
>>> (__fdpic_cmpxchg): New function.
>>> (__fdpic_dmb): New function.
>>> * config/arm/unwind-arm.h (gnu_Unwind_Find_got): New function.
>>> (_Unwind_decode_typeinfo_ptr): Add FDPIC support.
>>> * unwindo-arm-common.inc (UCB_PR_GOT): New.
>>> (funcdesc_t): New struct.
>>> (get_eit_entry): Add FDPIC support.
>>> (unwind_phase2): Likewise.
>>> (unwind_phase2_forced): Likewise.
>>> (__gnu_Unwind_RaiseException): Likewise.
>>> (__gnu_Unwind_Resume): Likewise.
>>> (__gnu_Unwind_Backtrace): Likewise.
>>> * unwind-pe.h (read_encoded_value_with_base): Likewise.
>>>
>>> libstdc++/
>>> * libsupc++/eh_personality.cc (get_ttype_entry): Add FDPIC
>>> support.
>>>
>>> Change-Id: Ic0841eb3d7bfb0b3f6d187cd52a660b8fd394d85
>>>
>>> diff --git a/gcc/ginclude/unwind-arm-common.h
>>> b/gcc/ginclude/unwind-arm-common.h
>>> index 8a1a919..150bd0f 100644
>>> --- a/gcc/ginclude/unwind-arm-common.h
>>> +++ b/gcc/ginclude/unwind-arm-common.h
>>> @@ -91,7 +91,7 @@ extern "C" {
>>>_uw reserved2; /* Personality routine address */
>>>_uw reserved3; /* Saved callsite address */
>>>_uw reserved4; /* Forced unwind stop arg */
>>> - _uw reserved5;
>>> + _uw reserved5; /* Personality routine GOT value in FDPIC
>>> mode. */
>>> }
>>>unwinder_cache;
>>>/* Propagation barrier cache (valid after phase 1): */
>>> diff --git a/libgcc/config/arm/linux-atomic.c
>>> b/libgcc/config/arm/linux-atomic.c
>>> index d334c58..a20ad94 100644
>>> --- a/libgcc/config/arm/linux-atomic.c
>>> +++ b/libgcc/config/arm/linux-atomic.c
>>> @@ -23,13 +23,99 @@ a copy of the GCC Runtime Library Exception along
>>> with this program;
>>> see the files COPYING3 and COPYING.RUNTIME respectively. If not, see
>>>
