Re: [PATCH] Build i386's crti.o and crtn.o for x86_64-*-rtems*
Hey!
Just thought I'd bump this patch and see if anyone had a chance to look at
it! Let me know if you have any questions or would like anything to be
different (for eg. to split "x86_64-*-elf*" and "x86_64-*-rtems*" into
their own case statements, instead of what I have here.
On Tue, May 1, 2018 at 3:24 PM Amaan Cheval wrote:
> Hi!
> The x86_64 RTEMS target doesn't currently have gcc build crti.o and
crtn.o. This
> surfaces as undefined references to "_fini", which RTEMS references in its
> kernel:
> https://git.rtems.org/rtems/tree/cpukit/libcsupport/src/newlibc_exit.c#n39
> Most other architectures deal with this by adding crti.o to the startfile
in
> bsp_specs:
> https://git.rtems.org/rtems/tree/bsps/i386/pc386/start/bsp_specs#n6
> This patch uses GCC's i386's crti.S and crtn.S (since x86_64-*-* targets
use
> "cpu_type=i386") as the source for the object files:
https://gcc.gnu.org/git/?p=gcc.git;a=blob;f=libgcc/config/i386/crti.S;h=c25e8f9e3ab45e935f6287d5ed3a8437a289e059;hb=HEAD
> The patch is as follows:
> libgcc/ChangeLog:
> 2018-05-01 Amaan Cheval
> * config.host: Build i386's crti.o and crtn.o for x86_64-*-rtems*
> Index: libgcc/config.host
> ===
> --- libgcc/config.host (revision 259789)
> +++ libgcc/config.host (working copy)
> @@ -611,6 +611,11 @@ i[34567]86-*-elf*)
> ;;
> x86_64-*-elf* | x86_64-*-rtems*)
> tmake_file="$tmake_file i386/t-crtstuff t-crtstuff-pic
t-libgcc-pic"
> + case ${host} in
> + x86_64-*-rtems*)
> + extra_parts="$extra_parts crti.o crtn.o"
> + ;;
> + esac
> ;;
> x86_64-*-fuchsia*)
> tmake_file="$tmake_file t-libgcc-pic"
Re: [testsuite] Add scan-offload-tree-dump
On Wed, 2 May 2018, Tom de Vries wrote: > [ was: [PATCH, 0/2] Add scan-ltrans-tree-dump and scan-wpa-ipa-dump ] > > Likewise, this patch adds scan-offload-tree-dump, and uses it in > testsuite/libgomp.oacc-c/vec.c, fixing the todo there. > > > [ The discussion on how to address to todo started here ( > https://gcc.gnu.org/ml/gcc-patches/2017-06/msg00319.html ). ] > > OK for trunk? OK. Richard.
Re: [RFC] Improve tree DSE
On Wed, May 2, 2018 at 7:39 PM, Jeff Law wrote: > On 05/02/2018 11:36 AM, Richard Biener wrote: >> On May 2, 2018 6:17:50 PM GMT+02:00, Jeff Law wrote: >>> On 05/02/2018 03:27 AM, Richard Biener wrote: On Tue, Apr 10, 2018 at 2:52 AM, Kugan Vivekanandarajah wrote: > I would like to queue this patch for stage1 review. > > In DSE, while in dse_classify_store, as soon as we see a PHI use > statement that is part of the loop, we are immediately giving up. > > As far as I understand, this can be improved. Attached patch is >>> trying > to walk the uses of the PHI statement (by recursively calling > dse_classify_store) and then making sure the obtained store is >>> indeed > redundant. > > This is partly as reported in one of the testcase from PR44612. But > this PR is about other issues that is not handled in this patch. > > Bootstrapped and regression tested on aarch64-linux-gnu with no new >>> regressions. > > Is this OK for next stage1? if (temp /* Make sure we are not in a loop latch block. */ || gimple_bb (stmt) == gimple_bb (use_stmt) - || dominated_by_p (CDI_DOMINATORS, -gimple_bb (stmt), gimple_bb >>> (use_stmt)) /* We can look through PHIs to regions >>> post-dominating you are removing part of the latch-block check but not the other. + /* If stmt dominates PHI stmt, follow the PHI stmt. >>> */ + if (!temp) well, just do this check earlier. Or rather, it's already done in >>> the test above. + /* Makesure the use stmt found is post >>> dominated. */ + && dominated_by_p (CDI_POST_DOMINATORS, +gimple_bb (stmt_outer), gimple_bb (inner_use_stmt)) I think that this check also covers gimple_bb (stmt_outer) == gimple_bb (inner_use_stmt) so for that case you'd need to check stmt dominance. But better just >>> give up? Given the simple testcases you add I wonder if you want a cheaper implementation, namely check that when reaching a loop PHI the only aliasing stmt in its use-chain is the use_stmt you reached the PHI from. That would avoid this and >>> the tests for the store being redundant and simplify the patch considerably. >>> Yea, but the ideas in the patch might be useful for some of the other >>> DSE missed optimizations :-) >> >> Note that what we want in the end is some kind of general partial dead code >> elimination pass that also handles stores. There was a SSU PRE >> implementation as part of a gsoc project many years ago. I believe building >> on top of the ad-hoc DSE pass we have right now is not the very best thing >> to do long term. SSU PRE also performs store/code sinking thus merging with >> the also ad-hoc sinking pass... > If we did good store sinking I think partial dead store elimination just > falls out with the existing tree-ssa-dse.c implementation. The cases I > was thinking about are already fully redundant, but the structure of > tree-ssa-dse isn't great for discovering them. Yeah. As a side-note - Kugan, you rely on post-dominance checks for correctness but post-dominance isn't what you expect when dealing with inifinite loops (with blocks not reverse reachable from exit). So relying on post-dominance for correctness is very fragile - we've been bitten by this before. Richard. > > jeff
Re: [PATCH 1/2, expr.c] Optimize switch with sign-extended index.
On Thu, May 3, 2018 at 12:05 AM, Jim Wilson wrote:
> This improves the code for a switch statement on targets that sign-extend
> function arguments, such as RISC-V. Given a simple testcase
>
> extern void asdf(int);
> void foo(int x) {
> switch (x) {
> case 0: asdf(10); break;
> case 1: asdf(11); break;
> case 2: asdf(12); break;
> case 3: asdf(13); break;
> case 4: asdf(14); break;
> }
> }
>
> Compiled for a 64-bit target, we get for the tablejump
>
> li a5,4
> bgtua0,a5,.L1
> sllia0,a0,32
> lui a5,%hi(.L4)
> addia5,a5,%lo(.L4)
> srlia0,a0,30
> add a0,a0,a5
> lw a5,0(a0)
> jr a5
>
> There is some unnecessary shifting here. a0 (x) gets shifted left by 32 then
> shifted right by 30 to zero-extend it and multiply by 4 for the table index.
> However, after the unsigned greater than branch, we know the value is between
> 0 and 4. We also know that a 32-bit int is passed as a 64-bit sign-extended
> long for this target. Thus we get the same exact value if we sign-extend
> instead of zero-extend, and the code is one instruction shorter. We get a
> slli
> by 2 instead of the slli 32/srli 30.
>
> The following patch implements this optimization. It checks for a range that
> does not have the sign-bit set, and an index value that is already sign
> extended, and then does a sign extend instead of an zero extend.
>
> This has been tested with a riscv{32,64}-{elf,linux} builds and testsuite
> runs.
> There were no regressions. It was also tested with an x86_64-linux build and
> testsuite run.
>
> Ok?
Just as a note, IIRC all the SUBREG_PROMOTED_* stuff is quite fragile
- I remember
Eric fixing things up a bit but some verification would be nice to
have (instrumentation
at RTL level that for SUBREG_PROMOTED_* the bits are as expected).
Richard.
> Jim
>
> gcc/
> * expr.c (do_tablejump): When converting index to Pmode, if we have a
> sign extended promoted subreg, and the range does not have the sign
> bit
> set, then do a sign extend.
> ---
> gcc/expr.c | 19 +--
> 1 file changed, 17 insertions(+), 2 deletions(-)
>
> diff --git a/gcc/expr.c b/gcc/expr.c
> index 9dd0e60d24d..919e20a22f7 100644
> --- a/gcc/expr.c
> +++ b/gcc/expr.c
> @@ -11782,11 +11782,26 @@ do_tablejump (rtx index, machine_mode mode, rtx
> range, rtx table_label,
> emit_cmp_and_jump_insns (index, range, GTU, NULL_RTX, mode, 1,
> default_label, default_probability);
>
> -
>/* If index is in range, it must fit in Pmode.
> Convert to Pmode so we can index with it. */
>if (mode != Pmode)
> -index = convert_to_mode (Pmode, index, 1);
> +{
> + unsigned int width;
> +
> + /* We know the value of INDEX is between 0 and RANGE. If we have a
> +sign-extended subreg, and RANGE does not have the sign bit set, then
> +we have a value that is valid for both sign and zero extension. In
> +this case, we get better code if we sign extend. */
> + if (GET_CODE (index) == SUBREG
> + && SUBREG_PROMOTED_VAR_P (index)
> + && SUBREG_PROMOTED_SIGNED_P (index)
> + && ((width = GET_MODE_PRECISION (as_a (mode)))
> + <= HOST_BITS_PER_WIDE_INT)
> + && ! (INTVAL (range) & (HOST_WIDE_INT_1U << (width - 1
> + index = convert_to_mode (Pmode, index, 0);
> + else
> + index = convert_to_mode (Pmode, index, 1);
> +}
>
>/* Don't let a MEM slip through, because then INDEX that comes
> out of PIC_CASE_VECTOR_ADDRESS won't be a valid address,
> --
> 2.14.1
>
[PATCH] Fix gfortran.dg/pr51434.f90 testcase
As noted in the bug the testcase is bogus. The following should
hopefully fix the observed runtime failures on powerpc and arm.
I've changed the bug to a FE accepts-invalid one.
Committed.
Richard.
2018-05-03 Richard Biener
PR testsuite/85579
* fortran.dg/pr51434.f90: Truncate transfer argument.
Index: gcc/testsuite/gfortran.dg/pr51434.f90
===
--- gcc/testsuite/gfortran.dg/pr51434.f90 (revision 259879)
+++ gcc/testsuite/gfortran.dg/pr51434.f90 (working copy)
@@ -6,7 +6,7 @@ module foo
character(len=1), parameter :: s(n) = 'a'
type :: a
integer :: m = n
- character(len=1):: t(n) = transfer('abcde ', s)
+ character(len=1):: t(n) = transfer('abcde', s)
end type a
end module foo
New template for 'gcc' made available
Hello, gentle maintainer. This is a message from the Translation Project robot. (If you have any questions, send them to .) A new POT file for textual domain 'gcc' has been made available to the language teams for translation. It is archived as: http://translationproject.org/POT-files/gcc-8.1.0.pot Whenever you have a new distribution with a new version number ready, containing a newer POT file, please send the URL of that distribution tarball to the address below. The tarball may be just a pretest or a snapshot, it does not even have to compile. It is just used by the translators when they need some extra translation context. Below is the URL which has been provided to the translators of your package. Please inform the translation coordinator, at the address at the bottom, if this information is not current: https://gcc.gnu.org/pub/gcc/snapshots/8-20180401/gcc-8-20180401.tar.xz Translated PO files will later be automatically e-mailed to you. Thank you for all your work, The Translation Project robot, in the name of your translation coordinator.
Re: [PATCH][tree-complex.c] PR tree-optimization/70291: Inline floating-point complex multiplication more aggressively
On 02/05/18 17:45, Wilco Dijkstra wrote: Richard Biener wrote: why use BUILT_IN_ISUNORDERED but not a GIMPLE_COND with UNORDERED_EXPR? Note again that might trap/throw with -fsignalling-nans so better avoid this transform for flag_signalling_nans as well... Both currently trap on signalling NaNs due to the implementation of the C99 builtins being buggy (PR66462). However since the inputs are results of FP operations, they are guaranteed to be quiet NaNs in this case, so no extra test for signalling NaNs is required. I'm happy to remove the check on flag_signaling_nans from the patch. Kyrill Which also means that we can dispatch to this simple variant not only for flag_complex_method != 2 but for !HONOR_NANS && !HONOR_INFINITIES? Maybe that should be done as followup. With -ffinite-math-only the isunordered will be optimized anyway. So it's just to avoid generating unnecessary dead code. Wilco
Re: [patch, i386] false dependencies fix
> This patch fixes false dependencies for vmovss, vmovsd, vrcpss, vrsqrtss,
> vsqrtss and vsqrtsd
> instructions.
>
> Tested on x86-64/Linux, no new test fails, some SPEC 2006/2017 performance
> gains.
> Please let me know if something is wrong here and should be changed.
Your submission needs a ChangeLog entry. Please see [1]
case MODE_DF:
if (TARGET_AVX && REG_P (operands[0]) && REG_P (operands[1]))
-return "vmovsd\t{%1, %0, %0|%0, %0, %1}";
+return "%vmovsd\t{%d1, %0|%0, %d1}";
return "%vmovsd\t{%1, %0|%0, %1}";
No need to change "v" to "%v". We are always in AVX domain here.
Otherwise OK. Please resubmit the patch with the ChangeLog entry.
[1] https://gcc.gnu.org/contribute.html
Thanks,
Uros.
[PATCH] Verify early releasing.html steps in gcc_release -f (PR other/85622)
Hi!
The following is an attempt to verify two steps from releasing.html
which are needed before the gcc_release is run, but we sometimes forget to
do it before that, so either NEWS in the tarballs doesn't contain info
about the new major release at all, or doesn't contain info about the
current release in those pages.
This will complain before tagging the release.
Tested with a dry run with exit 0 after the second hunk, ok for trunk?
2018-05-03 Jakub Jelinek
PR other/85622
* gcc_release: For -f, verify contrib/gennews has the major version
pages listed and both index.html and changes.html have been updated
for the new release.
--- maintainer-scripts/gcc_release.jj 2018-01-25 12:13:11.204328565 +0100
+++ maintainer-scripts/gcc_release 2018-05-03 10:59:10.597852827 +0200
@@ -9,7 +9,7 @@
# Contents:
# Script to create a GCC release.
#
-# Copyright (c) 2001-2015 Free Software Foundation.
+# Copyright (c) 2001-2018 Free Software Foundation.
#
# This file is part of GCC.
#
@@ -109,6 +109,36 @@ build_sources() {
${SVN} -q co "${SVNROOT}/${SVNBRANCH}" "`basename ${SOURCE_DIRECTORY}`" ||\
error "Could not check out release sources"
+
+grep -q "gcc-${RELEASE_MAJOR}/index.html
gcc-${RELEASE_MAJOR}/changes.html" \
+${SOURCE_DIRECTORY}/contrib/gennews ||\
+ error "New release not listed in contrib/gennews"
+
+${SOURCE_DIRECTORY}/contrib/gennews > NEWS ||\
+ error "Could not regenerate NEWS files"
+
+grep -q "no releases of GCC ${RELEASE_MAJOR} have yet been made" NEWS &&\
+ error "gcc-${RELEASE_MAJOR}/index.html has not been updated yet"
+
+grep -q "GCC ${RELEASE_MAJOR} has not been released yet" NEWS &&\
+ error "gcc-${RELEASE_MAJOR}/changes.html has not been updated yet"
+
+thisindex="http:\/\/gcc.gnu.org\/gcc-${RELEASE_MAJOR}\/index.html"
+thischanges="http:\/\/gcc.gnu.org\/gcc-${RELEASE_MAJOR}\/changes.html"
+previndex="http:\/\/gcc.gnu.org\/gcc-`expr ${RELEASE_MAJOR} -
1`\/index.html"
+sed -n -e "/^${thisindex}/,/^${thischanges}/p" NEWS |\
+ sed -n -e "/Release History/,/References and Acknowledgments/p" |\
+ grep -q "GCC ${RELEASE_MAJOR}.${RELEASE_MINOR}" ||\
+ error "GCC ${RELEASE_MAJOR}.${RELEASE_MINOR} not mentioned "\
+"in gcc-${RELEASE_MAJOR}/index.html"
+
+sed -n -e "/^${thischanges}/,/^${previndex}/p" NEWS |\
+ grep -q "^GCC ${RELEASE_MAJOR}.${RELEASE_MINOR}" ||\
+ error "GCC ${RELEASE_MAJOR}.${RELEASE_MINOR} not mentioned "\
+"in gcc-${RELEASE_MAJOR}/changes.html"
+
+rm -f NEWS
+
svnciargs=""
for x in `changedir ${SOURCE_DIRECTORY} && \
find . -name ChangeLog`; do
Jakub
Re: [PATCH][tree-complex.c] PR tree-optimization/70291: Inline floating-point complex multiplication more aggressively
On Thu, May 3, 2018 at 10:39 AM, Kyrill Tkachov
wrote:
>
> On 02/05/18 17:45, Wilco Dijkstra wrote:
>>
>> Richard Biener wrote:
>>
>>> why use BUILT_IN_ISUNORDERED but not a GIMPLE_COND with
>>> UNORDERED_EXPR? Note again that might trap/throw with -fsignalling-nans
>>> so better avoid this transform for flag_signalling_nans as well...
>>
>> Both currently trap on signalling NaNs due to the implementation of the
>> C99
>> builtins being buggy (PR66462).
>>
>> However since the inputs are results of FP operations, they are guaranteed
>> to be quiet NaNs in this case, so no extra test for signalling NaNs is
>> required.
>
>
> I'm happy to remove the check on flag_signaling_nans from the patch.
The issue is not actual runtime behavior but GIMPLE IL sanity. We force
possibly trapping compares out of conditions:
double x;
int main()
{
try {
if (__builtin_isunordered (x, x))
__builtin_abort ();
} catch (...) {
}
}
with -fsignaling-nans -fnon-call-exceptions you get
_3 = x.1_1 unord x.2_2;
if (_3 != 0) goto ; else goto ;
while without either it is
if (x.1_1 unord x.2_2) goto ; else goto ;
I'm not sure it actually matters here - at least on GIMPLE there's no
later sanity-checking on this. So maybe you can remove the condition
(but please quickly try a testcase with -fnon-call-exceptions and
-fsignaling-nans
and an EH tree - I suppose you hit the stmt_can_throw_internal case once you
have some EH handlers here).
+ rr = create_tmp_var (inner_type);
+ rr = make_ssa_name (rr);
+ ri = create_tmp_var (inner_type);
+ ri = make_ssa_name (ri);
just use
rr = make_ssa_name (inner_type);
ri = make_ssa_name (inner_type);
Otherwise OK.
Thanks,
Richard.
> Kyrill
>
>
>>> Which also means that we can dispatch to this simple variant not only for
>>> flag_complex_method != 2 but for !HONOR_NANS && !HONOR_INFINITIES?
>>> Maybe that should be done as followup.
>>
>> With -ffinite-math-only the isunordered will be optimized anyway. So it's
>> just
>> to avoid generating unnecessary dead code.
>>
>> Wilco
>
>
Re: [PATCH] Verify early releasing.html steps in gcc_release -f (PR other/85622)
On Thu, 3 May 2018, Jakub Jelinek wrote:
> Hi!
>
> The following is an attempt to verify two steps from releasing.html
> which are needed before the gcc_release is run, but we sometimes forget to
> do it before that, so either NEWS in the tarballs doesn't contain info
> about the new major release at all, or doesn't contain info about the
> current release in those pages.
>
> This will complain before tagging the release.
>
> Tested with a dry run with exit 0 after the second hunk, ok for trunk?
LGTM.
Richard.
> 2018-05-03 Jakub Jelinek
>
> PR other/85622
> * gcc_release: For -f, verify contrib/gennews has the major version
> pages listed and both index.html and changes.html have been updated
> for the new release.
>
> --- maintainer-scripts/gcc_release.jj 2018-01-25 12:13:11.204328565 +0100
> +++ maintainer-scripts/gcc_release2018-05-03 10:59:10.597852827 +0200
> @@ -9,7 +9,7 @@
> # Contents:
> # Script to create a GCC release.
> #
> -# Copyright (c) 2001-2015 Free Software Foundation.
> +# Copyright (c) 2001-2018 Free Software Foundation.
> #
> # This file is part of GCC.
> #
> @@ -109,6 +109,36 @@ build_sources() {
>
> ${SVN} -q co "${SVNROOT}/${SVNBRANCH}" "`basename ${SOURCE_DIRECTORY}`"
> ||\
> error "Could not check out release sources"
> +
> +grep -q "gcc-${RELEASE_MAJOR}/index.html
> gcc-${RELEASE_MAJOR}/changes.html" \
> + ${SOURCE_DIRECTORY}/contrib/gennews ||\
> +error "New release not listed in contrib/gennews"
> +
> +${SOURCE_DIRECTORY}/contrib/gennews > NEWS ||\
> +error "Could not regenerate NEWS files"
> +
> +grep -q "no releases of GCC ${RELEASE_MAJOR} have yet been made" NEWS &&\
> +error "gcc-${RELEASE_MAJOR}/index.html has not been updated yet"
> +
> +grep -q "GCC ${RELEASE_MAJOR} has not been released yet" NEWS &&\
> +error "gcc-${RELEASE_MAJOR}/changes.html has not been updated yet"
> +
> +thisindex="http:\/\/gcc.gnu.org\/gcc-${RELEASE_MAJOR}\/index.html"
> +thischanges="http:\/\/gcc.gnu.org\/gcc-${RELEASE_MAJOR}\/changes.html"
> +previndex="http:\/\/gcc.gnu.org\/gcc-`expr ${RELEASE_MAJOR} -
> 1`\/index.html"
> +sed -n -e "/^${thisindex}/,/^${thischanges}/p" NEWS |\
> +sed -n -e "/Release History/,/References and Acknowledgments/p" |\
> +grep -q "GCC ${RELEASE_MAJOR}.${RELEASE_MINOR}" ||\
> +error "GCC ${RELEASE_MAJOR}.${RELEASE_MINOR} not mentioned "\
> + "in gcc-${RELEASE_MAJOR}/index.html"
> +
> +sed -n -e "/^${thischanges}/,/^${previndex}/p" NEWS |\
> +grep -q "^GCC ${RELEASE_MAJOR}.${RELEASE_MINOR}" ||\
> +error "GCC ${RELEASE_MAJOR}.${RELEASE_MINOR} not mentioned "\
> + "in gcc-${RELEASE_MAJOR}/changes.html"
> +
> +rm -f NEWS
> +
> svnciargs=""
> for x in `changedir ${SOURCE_DIRECTORY} && \
> find . -name ChangeLog`; do
>
> Jakub
>
>
--
Richard Biener
SUSE LINUX GmbH, GF: Felix Imendoerffer, Jane Smithard, Graham Norton, HRB
21284 (AG Nuernberg)
Patch ping (Re: [PATCH] Add _mm512_{,mask_}mullox_epi64 intrinsics (PR target/85530))
On Thu, Apr 26, 2018 at 10:09:48PM +0200, Jakub Jelinek wrote:
> ICC apparently has these two intrinsics (why it doesn't have a maskz_ one
> is unclear to me) which are like _mm512_{,mask_}mullo_epi64, except they are
> available in AVX512F rather than just AVX512DQ and if AVX512DQ is not
> enabled they expand to 3 vpmuludq instructions + 3 shifts + 2 adds; for
> AVX512DQ they are the same as mullo without x.
>
> Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?
>
> 2018-04-26 Jakub Jelinek
>
> PR target/85530
> * config/i386/avx512fintrin.h (_mm512_mullox_epi64,
> _mm512_mask_mullox_epi64): New intrinsics.
>
> * gcc.target/i386/avx512f-vpmullq-1.c: New test.
> * gcc.target/i386/avx512f-vpmullq-2.c: New test.
> * gcc.target/i386/avx512dq-vpmullq-3.c: New test.
> * gcc.target/i386/avx512dq-vpmullq-4.c: New test.
I'd like to ping this patch, ok for trunk?
Jakub
Re: [PATCH] Add constant folding support for next{after,toward}{,f,l} (PR libstdc++/85466)
On Sat, 21 Apr 2018, Jakub Jelinek wrote:
> Hi!
>
> This patch adds constant folding for next{after,toward}{,f,l}.
> It doesn't handle decimal (we don't have a builtins that would need it),
> nor composite modes (IBM double double; nextafter/nexttoward for variable
> precision types isn't really well defined; we handle nexttoward where long
> double is IBM double double) and for now punts also on formats without
> denormals or infinities (don't really know what the library nextafter does
> for those).
>
> Bootstrapped/regtested on x86_64-linux and i686-linux, ok for stage1?
>
> 2018-04-21 Jakub Jelinek
>
> PR libstdc++/85466
> * real.h (real_nextafter): Declare.
> * real.c (real_nextafter): New function.
> * fold-const-call.c (fold_const_nextafter): New function.
> (fold_const_call_sss): Call it for CASE_CFN_NEXTAFTER and
> CASE_CFN_NEXTTOWARD.
> (fold_const_call_1): For CASE_CFN_NEXTTOWARD call fold_const_call_sss
> even when arg1_mode is different from arg0_mode.
>
> * gcc.dg/nextafter-1.c: New test.
> * gcc.dg/nextafter-2.c: New test.
> * gcc.dg/nextafter-3.c: New test.
> * gcc.dg/nextafter-4.c: New test.
>
> --- gcc/real.h.jj 2018-01-03 10:19:54.349533828 +0100
> +++ gcc/real.h2018-04-20 12:44:30.707350855 +0200
> @@ -507,6 +507,10 @@ extern void real_copysign (REAL_VALUE_TY
> extern bool real_isinteger (const REAL_VALUE_TYPE *, format_helper);
> extern bool real_isinteger (const REAL_VALUE_TYPE *, HOST_WIDE_INT *);
>
> +/* Calculate nextafter (X, Y) in format FMT. */
> +extern bool real_nextafter (REAL_VALUE_TYPE *, format_helper,
> + const REAL_VALUE_TYPE *, const REAL_VALUE_TYPE *);
> +
> /* Write into BUF the maximum representable finite floating-point
> number, (1 - b**-p) * b**emax for a given FP format FMT as a hex
> float string. BUF must be large enough to contain the result. */
> --- gcc/real.c.jj 2018-01-03 10:19:55.003533933 +0100
> +++ gcc/real.c2018-04-21 19:29:09.103584254 +0200
> @@ -5048,6 +5048,102 @@ real_isinteger (const REAL_VALUE_TYPE *c
>return false;
> }
>
> +/* Calculate nextafter (X, Y) or nexttoward (X, Y). Return true if
> + underflow or overflow needs to be raised. */
> +
> +bool
> +real_nextafter (REAL_VALUE_TYPE *r, format_helper fmt,
> + const REAL_VALUE_TYPE *x, const REAL_VALUE_TYPE *y)
> +{
> + int cmp = do_compare (x, y, 2);
> + /* If either operand is NaN, return qNaN. */
> + if (cmp == 2)
> +{
> + get_canonical_qnan (r, 0);
> + return false;
> +}
> + /* If x == y, return y cast to target type. */
> + if (cmp == 0)
> +{
> + real_convert (r, fmt, y);
> + return false;
> +}
> +
> + if (x->cl == rvc_zero)
> +{
> + get_zero (r, y->sign);
> + r->cl = rvc_normal;
> + SET_REAL_EXP (r, fmt->emin - fmt->p + 1);
> + r->sig[SIGSZ - 1] = SIG_MSB;
> + return false;
> +}
> +
> + int np2 = SIGNIFICAND_BITS - fmt->p;
> + /* For denormals adjust np2 correspondingly. */
> + if (x->cl == rvc_normal && REAL_EXP (x) < fmt->emin)
> +np2 += fmt->emin - REAL_EXP (x);
> +
> + REAL_VALUE_TYPE u;
> + get_zero (r, x->sign);
> + get_zero (&u, 0);
> + set_significand_bit (&u, np2);
> + r->cl = rvc_normal;
> + SET_REAL_EXP (r, REAL_EXP (x));
> +
> + if (x->cl == rvc_inf)
> +{
> + bool borrow = sub_significands (r, r, &u, 0);
> + gcc_assert (borrow);
> + SET_REAL_EXP (r, fmt->emax);
> +}
> + else if (cmp == (x->sign ? 1 : -1))
> +{
> + if (add_significands (r, x, &u))
> + {
> + /* Overflow. Means the significand had been all ones, and
> + is now all zeros. Need to increase the exponent, and
> + possibly re-normalize it. */
> + SET_REAL_EXP (r, REAL_EXP (r) + 1);
> + if (REAL_EXP (r) > fmt->emax)
> + {
> + get_inf (r, x->sign);
> + return true;
> + }
> + r->sig[SIGSZ - 1] = SIG_MSB;
> + }
> +}
> + else
> +{
> + if (REAL_EXP (x) > fmt->emin && x->sig[SIGSZ - 1] == SIG_MSB)
> + {
> + int i;
> + for (i = SIGSZ - 2; i >= 0; i--)
> + if (x->sig[i])
> + break;
> + if (i < 0)
> + {
> + /* When mantissa is 1.0, we need to subtract only
> + half of u: nextafter (1.0, 0.0) is 1.0 - __DBL_EPSILON__ / 2
> + rather than 1.0 - __DBL_EPSILON__. */
> + clear_significand_bit (&u, np2);
> + np2--;
> + set_significand_bit (&u, np2);
> + }
> + }
> + sub_significands (r, x, &u, 0);
> +}
> +
> + /* Clear out trailing garbage. */
> + clear_significand_below (r, np2);
> + normalize (r);
> + if (REAL_EXP (r) <= fmt->emin - fmt->p)
> +{
> + get_zero (r, x->sign);
> + return true;
> +}
> + return r->cl == rvc_zero;
> +}
> +
> /* Write into BUF the maximum representable finite f
Re: RFA: Sanitize deprecation messages (PR 84195)
Hi Jeff, Thanks for the review. > The docs still say "Control characters in the string will be replaced > with spaces", but they're being escaped now. That needs to be fixed. Done. > I note you overload the cast operator in your new class. Why not just > use an accessor? Was this style something someone else suggested? Yup. My C++ foo is very weak, so I asked Martin for help, and that was he suggested. Is this method wrong ? > Onward to the nits :-) :-) > + char *m_str; > + bool m_owned; > > I don't think we try to line up variable definitions like that. OK. Fixed. > + escaped = (char *) xmalloc (len * 2 + 1); > I believe that generally we want a slower growth pattern. You'll find > that we regularly do something like len * 3 / 2 + 1. Seems wise here too. Also done. > +void > +escaped_string::escape (const char * unescaped) > No need for the space between the * and unescaped. Et tu Jeff ? Then fall Nick. :-) [Fixed] > + case '\v': escaped[new_i++] = 'v'; break; > + default: escaped[new_i++] = '?'; break; > + } > I believe our coding standards would have the statements on new lines > rather than on the line with the case label. Sorted. > So I think the biggest question here is the cast overload vs just using > an accessor. OK, so demonstrating my ignorance: what is the accessor solution to this problem ? Cheers Nick PS. Revised patch attached in case the current solution of casting the operators is OK. pr84195.patch.6 Description: Unix manual page
Re: [PATCH] Fix the GNU Stack markings on libgcc.a
torsdag 3 maj 2018 kl. 06:19:20 CEST skrev du: > On 05/02/2018 07:05 PM, Magnus Granberg wrote: > > torsdag 3 maj 2018 kl. 01:48:16 CEST skrev du: > >> On 05/02/2018 06:17 PM, Magnus Granberg wrote: > >>> torsdag 3 maj 2018 kl. 01:07:51 CEST skrev Daniel Santos: > Hello > > On 05/01/2018 06:32 AM, Magnus Granberg wrote: > > New patch > > libgcc/ChangeLog: > > > > 2018-05-01 Magnus Granberg > > > > * config/i386/resms64.h: Add .note.GNU-stack section > > * config/i386/resms64f.h: Likewise. > > * config/i386/resms64fx.h: Likewise. > > * config/i386/resms64x.h: Likewise. > > * config/i386/savms64.h: Likewise. > > * config/i386/savms64f.h: Likewise. > > > > --- > > Well this isn't correct either because you are outside of the inclusion > guard. Can you please move this up a line? > > Thanks, > Daniel > >>> > >>> /libgcc/ChangeLog: > >>> 2018-05-01 Magnus Granberg > >>> > >>> * config/i386/resms64.h: Add .note.GNU-stack section > >>> * config/i386/resms64f.h: Likewise. > >>> * config/i386/resms64fx.h: Likewise. > >>> * config/i386/resms64x.h: Likewise. > >>> * config/i386/savms64.h: Likewise. > >>> * config/i386/savms64f.h: Likewise. > >>> > >>> --- > >> > >> No, I meant to move the changes up a line so that, if for some reason > >> the header was included twice, that it wouldn't output the section > >> > >> twice. Example: > >> MS2SYSV_STUB_END(savms64_18) > >> > >> +#if·defined(__linux__)·&&·defined(__ELF__) > >> +.section·.note.GNU-stack,"",%progbits > >> +#endif > >> > >> #endif·/*·__x86_64__·*/ > > > > Don't work on multilib > > What do you mean? The functions do not exist on anything other than > x86_64. Emitting the .section when the function is not going to be > subsequently emitted will apply it the .section to whatever happens to > be next in the assembler output, so no, that's wrong. > For you have the executable stack in 32bit and 64bit libs Look at the bug. > >> But upon further reflection, I think it can be cleanly added to > >> i386-asm.h. Does that look sane Jakub? (I haven't tried it) > > > > Don't work on multilib > > > >> Also, for the sake of my education, I don't exactly understand what the > >> problem is as I haven't been keeping up with pax and hardening. I just > >> want to clarify that the stack shouldn't be executable. These are not > >> actual "functions" per-se (i.e., they do not adhere to any ABI), they > >> operate on the stack of the calling function. > >> > >> Thanks, > >> Daniel > > > > /Magnus
Re: [PATCH, PR82428] Add __builtin_goacc_{gang,worker,vector}_{id,size}
On 01/18/2018 09:55 AM, Tom de Vries wrote:
diff --git a/libgomp/testsuite/libgomp.oacc-c-c++-common/gang-static-2.c
b/libgomp/testsuite/libgomp.oacc-c-c++-common/gang-static-2.c
index 6de739a..e273a79 100644
--- a/libgomp/testsuite/libgomp.oacc-c-c++-common/gang-static-2.c
+++ b/libgomp/testsuite/libgomp.oacc-c-c++-common/gang-static-2.c
@@ -1,25 +1,23 @@
-/* { dg-do run { target openacc_nvidia_accel_selected } } */
-/* This code uses nvptx inline assembly guarded with acc_on_device, which is
- not optimized away at -O0, and then confuses the target assembler.
- { dg-skip-if "" { *-*-* } { "-O0" } { "" } } */
-
#include
#include
+#include
Hi,
it seems I've broken installed testing of libgomp with this patch. The
compiler cannot find gomp-constants.h.
In the build-area testing setup, the compiler can find gomp-constants.h
because in libgomp.exp we find:
...
if { $blddir != "" } {
...
# The top-level include directory, for gomp-constants.h.
lappend ALWAYS_CFLAGS "additional_flags=-I${srcdir}/../../include"
}
...
but this line is not active for installed testing.
Patch below fixes this.
Is this approach ok for trunk?
Thanks,
- Tom
Index: libgomp/testsuite/lib/libgomp.exp
===
--- libgomp/testsuite/lib/libgomp.exp (revision 259880)
+++ libgomp/testsuite/lib/libgomp.exp (working copy)
@@ -186,9 +186,9 @@ proc libgomp_init { args } {
lappend ALWAYS_CFLAGS "additional_flags=-B${blddir}/.libs"
lappend ALWAYS_CFLAGS "additional_flags=-I${blddir}"
lappend ALWAYS_CFLAGS "ldflags=-L${blddir}/.libs"
- # The top-level include directory, for gomp-constants.h.
- lappend ALWAYS_CFLAGS "additional_flags=-I${srcdir}/../../include"
}
+# The top-level include directory, for gomp-constants.h.
+lappend ALWAYS_CFLAGS "additional_flags=-I${srcdir}/../../include"
lappend ALWAYS_CFLAGS "additional_flags=-I${srcdir}/.."
# For build-tree testing, also consider the library paths used for
builing.
[PATCH] Fix PR85627 (and more)
The following fixes PR85627 and more generally complex lowering not
preserving EH information with -fnon-call-exceptions when replacing
complex multiplication or division with a libcall.
This requires changing BUILT_IN_COMPLEX_{MUL,DIV} to be no longer
declared nothrow - complex lowering (which looks like the only consumer)
properly will set the nothrow flag on the individual call based on
the context.
Test coverage of -fnon-call-exceptions is notoriously bad and I'm not
sure whether Ada uses GCCs complex types. Eric?
Otherwise does this look sane? I'm waiting for Kyrylos patch to come
in and then will refresh and re-test.
Bootstrap / regtest running on x86_64-unknown-linux-gnu.
Richard.
2018-05-03 Richard Biener
PR middle-end/85627
* tree-complex.c (update_complex_assignment): We are always in SSA form.
(expand_complex_div_wide): Likewise.
(expand_complex_operations_1): Likewise.
(expand_complex_libcall): Preserve EH info of the original stmt.
(tree_lower_complex): Handle removed blocks.
* tree.c (build_common_builtin_nodes): Do not set ECF_NOTRHOW
on complex multiplication and division libcall builtins.
* g++.dg/torture/pr85627.C: New testcase.
Index: gcc/tree-complex.c
===
--- gcc/tree-complex.c (revision 259879)
+++ gcc/tree-complex.c (working copy)
@@ -703,8 +703,7 @@ update_complex_assignment (gimple_stmt_i
if (maybe_clean_eh_stmt (stmt))
gimple_purge_dead_eh_edges (gimple_bb (stmt));
- if (gimple_in_ssa_p (cfun))
-update_complex_components (gsi, gsi_stmt (*gsi), r, i);
+ update_complex_components (gsi, gsi_stmt (*gsi), r, i);
}
@@ -1009,20 +1008,29 @@ expand_complex_libcall (gimple_stmt_iter
stmt = gimple_build_call (fn, 4, ar, ai, br, bi);
gimple_call_set_lhs (stmt, lhs);
+ gimple_call_set_nothrow (stmt, !stmt_could_throw_p (old_stmt));
update_stmt (stmt);
- gsi_replace (gsi, stmt, false);
+ gsi_replace (gsi, stmt, true);
- if (maybe_clean_or_replace_eh_stmt (old_stmt, stmt))
-gimple_purge_dead_eh_edges (gsi_bb (*gsi));
-
- if (gimple_in_ssa_p (cfun))
+ type = TREE_TYPE (type);
+ if (stmt_can_throw_internal (stmt))
{
- type = TREE_TYPE (type);
- update_complex_components (gsi, stmt,
+ edge_iterator ei;
+ edge e;
+ FOR_EACH_EDGE (e, ei, gimple_bb (stmt)->succs)
+ if (!(e->flags & EDGE_EH))
+ break;
+ basic_block bb = split_edge (e);
+ gimple_stmt_iterator gsi2 = gsi_start_bb (bb);
+ update_complex_components (&gsi2, stmt,
build1 (REALPART_EXPR, type, lhs),
build1 (IMAGPART_EXPR, type, lhs));
- SSA_NAME_DEF_STMT (lhs) = stmt;
}
+ else
+update_complex_components (gsi, stmt,
+ build1 (REALPART_EXPR, type, lhs),
+ build1 (IMAGPART_EXPR, type, lhs));
+ SSA_NAME_DEF_STMT (lhs) = stmt;
}
/* Expand complex multiplication to scalars:
@@ -1170,14 +1178,8 @@ expand_complex_div_wide (gimple_stmt_ite
gimple *stmt;
tree cond, tmp;
- tmp = create_tmp_var (boolean_type_node);
+ tmp = make_ssa_name (boolean_type_node);
stmt = gimple_build_assign (tmp, compare);
- if (gimple_in_ssa_p (cfun))
- {
- tmp = make_ssa_name (tmp, stmt);
- gimple_assign_set_lhs (stmt, tmp);
- }
-
gsi_insert_before (gsi, stmt, GSI_SAME_STMT);
cond = fold_build2_loc (gimple_location (stmt),
@@ -1602,25 +1604,20 @@ expand_complex_operations_1 (gimple_stmt
else
br = bi = NULL_TREE;
- if (gimple_in_ssa_p (cfun))
+ al = find_lattice_value (ac);
+ if (al == UNINITIALIZED)
+al = VARYING;
+
+ if (TREE_CODE_CLASS (code) == tcc_unary)
+bl = UNINITIALIZED;
+ else if (ac == bc)
+bl = al;
+ else
{
- al = find_lattice_value (ac);
- if (al == UNINITIALIZED)
- al = VARYING;
-
- if (TREE_CODE_CLASS (code) == tcc_unary)
- bl = UNINITIALIZED;
- else if (ac == bc)
- bl = al;
- else
- {
- bl = find_lattice_value (bc);
- if (bl == UNINITIALIZED)
- bl = VARYING;
- }
+ bl = find_lattice_value (bc);
+ if (bl == UNINITIALIZED)
+ bl = VARYING;
}
- else
-al = bl = VARYING;
switch (code)
{
@@ -1692,6 +1689,8 @@ tree_lower_complex (void)
for (i = 0; i < n_bbs; i++)
{
bb = BASIC_BLOCK_FOR_FN (cfun, rpo[i]);
+ if (!bb)
+ continue;
update_phi_components (bb);
for (gsi = gsi_start_bb (bb); !gsi_end_p (gsi); gsi_next (&gsi))
expand_complex_operations_1 (&gsi);
Index: gcc/tree.c
===
--- gcc/tree.c (revision 259879)
+++ gcc/tree.c (working copy)
@@ -10386,17 +10386,19 @@ build_common_builtin_nodes (void)
*q = TOLOWER (*p);
*q =
[PATCH] Define std::remove_cvref and std::remove_cvref_t for C++2a
Also define __remove_cvref_t for internal use before C++2a.
* include/std/any (any_cast): Use __remove_cvref_t.
* include/std/tuple (__make_tuple): Likewise.
* include/std/type_traits (__remove_cvref_t): Define.
(__result_of_memobj, __result_of_memfun): Use __remove_cvref_t.
[__cplusplus > 201703L] (remove_cvref, remove_cvref_t): Define.
* include/std/variant (__erased_hash): Use __remove_cvref_t.
Tested powerpc64le-linux, committed to trunk.
commit 03ac1d02135a920114e4f6241fbc85689400b867
Author: Jonathan Wakely
Date: Thu May 3 12:22:59 2018 +0100
Define std::remove_cvref and std::remove_cvref_t for C++2a
Also define __remove_cvref_t for internal use before C++2a.
* include/std/any (any_cast): Use __remove_cvref_t.
* include/std/tuple (__make_tuple): Likewise.
* include/std/type_traits (__remove_cvref_t): Define.
(__result_of_memobj, __result_of_memfun): Use __remove_cvref_t.
[__cplusplus > 201703L] (remove_cvref, remove_cvref_t): Define.
* include/std/variant (__erased_hash): Use __remove_cvref_t.
diff --git a/libstdc++-v3/include/std/any b/libstdc++-v3/include/std/any
index a37eb38d665..11b59d6d575 100644
--- a/libstdc++-v3/include/std/any
+++ b/libstdc++-v3/include/std/any
@@ -451,7 +451,7 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
template
inline _ValueType any_cast(const any& __any)
{
- using _Up = remove_cv_t>;
+ using _Up = __remove_cvref_t<_ValueType>;
static_assert(any::__is_valid_cast<_ValueType>(),
"Template argument must be a reference or CopyConstructible type");
static_assert(is_constructible_v<_ValueType, const _Up&>,
@@ -477,7 +477,7 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
template
inline _ValueType any_cast(any& __any)
{
- using _Up = remove_cv_t>;
+ using _Up = __remove_cvref_t<_ValueType>;
static_assert(any::__is_valid_cast<_ValueType>(),
"Template argument must be a reference or CopyConstructible type");
static_assert(is_constructible_v<_ValueType, _Up&>,
@@ -491,7 +491,7 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
template
inline _ValueType any_cast(any&& __any)
{
- using _Up = remove_cv_t>;
+ using _Up = __remove_cvref_t<_ValueType>;
static_assert(any::__is_valid_cast<_ValueType>(),
"Template argument must be a reference or CopyConstructible type");
static_assert(is_constructible_v<_ValueType, _Up>,
diff --git a/libstdc++-v3/include/std/tuple b/libstdc++-v3/include/std/tuple
index 1d0074129b1..16f69220abb 100644
--- a/libstdc++-v3/include/std/tuple
+++ b/libstdc++-v3/include/std/tuple
@@ -1499,8 +1499,7 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
// Returns the std::tuple equivalent of a tuple-like type.
template
struct __make_tuple
-: public __do_make_tuple::type>::type>
+: public __do_make_tuple<__remove_cvref_t<_Tuple>>
{ };
// Combines several std::tuple's into a single one.
diff --git a/libstdc++-v3/include/std/type_traits
b/libstdc++-v3/include/std/type_traits
index 711d6c50dd1..7c0ba727511 100644
--- a/libstdc++-v3/include/std/type_traits
+++ b/libstdc++-v3/include/std/type_traits
@@ -2092,6 +2092,11 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
return __declval<_Tp>(0);
}
+ // __remove_cvref_t (std::remove_cvref_t for C++11).
+ template
+using __remove_cvref_t
+ = typename remove_cv::type>::type;
+
/// result_of
template
class result_of;
@@ -2193,8 +2198,7 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
template
struct __result_of_memobj<_Res _Class::*, _Arg>
{
- typedef typename remove_cv::type>::type _Argval;
+ typedef __remove_cvref_t<_Arg> _Argval;
typedef _Res _Class::* _MemPtr;
typedef typename conditional<__or_,
is_base_of<_Class, _Argval>>::value,
@@ -2209,8 +2213,7 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
template
struct __result_of_memfun<_Res _Class::*, _Arg, _Args...>
{
- typedef typename remove_cv::type>::type _Argval;
+ typedef __remove_cvref_t<_Arg> _Argval;
typedef _Res _Class::* _MemPtr;
typedef typename conditional<__or_,
is_base_of<_Class, _Argval>>::value,
@@ -2399,8 +2402,7 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
// Internal type trait that allows us to sfinae-protect tuple_cat.
template
struct __is_tuple_like
-: public __is_tuple_like_impl::type>::type>::type
+: public __is_tuple_like_impl<__remove_cvref_t<_Tp>>::type
{ };
template
@@ -2942,6 +2944,17 @@ template
big= __ORDER_BIG_ENDIAN__,
native = __BYTE_ORDER__
};
+
+ /// Remove references and cv-qualifiers.
+ template
+struct remove_cvref
+{
+ using type = __remove_cvref_t<_Tp>;
+};
+
+ template
+using remove_cvref_t = __remove_cvref_t<_Tp>;
+
#endif // C++2a
_GLIBCXX_END_NAMESPACE_VERSION
diff --git a/libstdc++-v3/include/std/variant b/libstdc++-v
[PATCH] Use std::invoke_result in std::async instead of std::result_of
* include/std/future (__async_result_of): Use __invoke_result instead of result_of. Tested powerpc64le-linux, committed to trunk. commit b5db9a5482919074071cf9ae7922ad4b8b34549d Author: Jonathan Wakely Date: Wed May 2 20:56:28 2018 +0100 Use std::invoke_result in std::async instead of std::result_of * include/std/future (__async_result_of): Use __invoke_result instead of result_of. diff --git a/libstdc++-v3/include/std/future b/libstdc++-v3/include/std/future index f9ad5666f52..c17a253d26e 100644 --- a/libstdc++-v3/include/std/future +++ b/libstdc++-v3/include/std/future @@ -181,8 +181,8 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION // _GLIBCXX_RESOLVE_LIB_DEFECTS // 2021. Further incorrect usages of result_of template -using __async_result_of = typename result_of< - typename decay<_Fn>::type(typename decay<_Args>::type...)>::type; +using __async_result_of = typename __invoke_result< + typename decay<_Fn>::type, typename decay<_Args>::type...>::type; template future<__async_result_of<_Fn, _Args...>>
Re: [PATCH][tree-complex.c] PR tree-optimization/70291: Inline floating-point complex multiplication more aggressively
On 03/05/18 10:20, Richard Biener wrote:
> On Thu, May 3, 2018 at 10:39 AM, Kyrill Tkachov
> wrote:
>>
>> On 02/05/18 17:45, Wilco Dijkstra wrote:
>>>
>>> Richard Biener wrote:
>>>
why use BUILT_IN_ISUNORDERED but not a GIMPLE_COND with
UNORDERED_EXPR? Note again that might trap/throw with -fsignalling-nans
so better avoid this transform for flag_signalling_nans as well...
>>>
>>> Both currently trap on signalling NaNs due to the implementation of the
>>> C99
>>> builtins being buggy (PR66462).
>>>
>>> However since the inputs are results of FP operations, they are guaranteed
>>> to be quiet NaNs in this case, so no extra test for signalling NaNs is
>>> required.
>>
>>
>> I'm happy to remove the check on flag_signaling_nans from the patch.
>
> The issue is not actual runtime behavior but GIMPLE IL sanity. We force
> possibly trapping compares out of conditions:
>
> double x;
> int main()
> {
> try {
> if (__builtin_isunordered (x, x))
> __builtin_abort ();
> } catch (...) {
> }
> }
>
> with -fsignaling-nans -fnon-call-exceptions you get
>
> _3 = x.1_1 unord x.2_2;
> if (_3 != 0) goto ; else goto ;
>
> while without either it is
>
> if (x.1_1 unord x.2_2) goto ; else goto ;
>
> I'm not sure it actually matters here - at least on GIMPLE there's no
> later sanity-checking on this. So maybe you can remove the condition
> (but please quickly try a testcase with -fnon-call-exceptions and
> -fsignaling-nans
> and an EH tree - I suppose you hit the stmt_can_throw_internal case once you
> have some EH handlers here).
>
> + rr = create_tmp_var (inner_type);
> + rr = make_ssa_name (rr);
> + ri = create_tmp_var (inner_type);
> + ri = make_ssa_name (ri);
>
> just use
>
>rr = make_ssa_name (inner_type);
>ri = make_ssa_name (inner_type);
>
> Otherwise OK.
>
As discussed in PR 85627 and on IRC I've committed this with the above change
as r259889.
Thanks for the guidance!
Kyrill
diff --git a/gcc/testsuite/gcc.dg/complex-6.c b/gcc/testsuite/gcc.dg/complex-6.c
new file mode 100644
index ..e70322bf6f378d1d6947de4c10f671bc0a7ded49
--- /dev/null
+++ b/gcc/testsuite/gcc.dg/complex-6.c
@@ -0,0 +1,13 @@
+/* PR tree-optimization/70291. */
+
+/* { dg-do compile } */
+/* { dg-options "-O2 -fdump-tree-cplxlower" } */
+
+__complex float
+foo (__complex float a, __complex float b)
+{
+ return a * b;
+}
+
+/* { dg-final { scan-tree-dump-times "unord" 1 "cplxlower1" } } */
+/* { dg-final { scan-tree-dump-times "__mulsc3" 1 "cplxlower1" } } */
diff --git a/gcc/testsuite/gcc.dg/complex-7.c b/gcc/testsuite/gcc.dg/complex-7.c
new file mode 100644
index ..78f1a290e34af0c092a00639d979bc32b332b1da
--- /dev/null
+++ b/gcc/testsuite/gcc.dg/complex-7.c
@@ -0,0 +1,13 @@
+/* PR tree-optimization/70291. */
+
+/* { dg-do compile } */
+/* { dg-options "-O2 -fdump-tree-cplxlower" } */
+
+__complex double
+foo (__complex double a, __complex double b)
+{
+ return a * b;
+}
+
+/* { dg-final { scan-tree-dump-times "unord" 1 "cplxlower1" } } */
+/* { dg-final { scan-tree-dump-times "__muldc3" 1 "cplxlower1" } } */
diff --git a/gcc/tree-complex.c b/gcc/tree-complex.c
index 622b8696399b9e9d8bddcc6340d2f8d8ca852637..87e27aacb517c52924edafb8fd0916a08b1589fd 100644
--- a/gcc/tree-complex.c
+++ b/gcc/tree-complex.c
@@ -978,22 +978,22 @@ expand_complex_addition (gimple_stmt_iterator *gsi, tree inner_type,
}
/* Expand a complex multiplication or division to a libcall to the c99
- compliant routines. */
+ compliant routines. TYPE is the complex type of the operation.
+ If INPLACE_P replace the statement at GSI with
+ the libcall and return NULL_TREE. Else insert the call, assign its
+ result to an output variable and return that variable. If INPLACE_P
+ is true then the statement being replaced should be an assignment
+ statement. */
-static void
-expand_complex_libcall (gimple_stmt_iterator *gsi, tree ar, tree ai,
- tree br, tree bi, enum tree_code code)
+static tree
+expand_complex_libcall (gimple_stmt_iterator *gsi, tree type, tree ar, tree ai,
+ tree br, tree bi, enum tree_code code, bool inplace_p)
{
machine_mode mode;
enum built_in_function bcode;
- tree fn, type, lhs;
- gimple *old_stmt;
+ tree fn, lhs;
gcall *stmt;
- old_stmt = gsi_stmt (*gsi);
- lhs = gimple_assign_lhs (old_stmt);
- type = TREE_TYPE (lhs);
-
mode = TYPE_MODE (type);
gcc_assert (GET_MODE_CLASS (mode) == MODE_COMPLEX_FLOAT);
@@ -1008,21 +1008,65 @@ expand_complex_libcall (gimple_stmt_iterator *gsi, tree ar, tree ai,
fn = builtin_decl_explicit (bcode);
stmt = gimple_build_call (fn, 4, ar, ai, br, bi);
- gimple_call_set_lhs (stmt, lhs);
- update_stmt (stmt);
- gsi_replace (gsi, stmt, false);
- if (maybe_clean_or_replace_eh_stmt (old_stmt, stmt))
-gimple_purge_dead_eh_edges (gsi_bb (*gsi));
- if (gimple_in_ssa_p (cfun))
+ if (inplace_p)
[PATCH] PR libstdc++/84535 constrain std::thread constructor
The standard requires that the std::thread constructor is constrained so
it can't be called with a first argument of type std::thread. The
current implementation only meets that requirement if the constructor is
called with one argument, by using deleted overloads. This uses an
enable_if constraint to enforce the requirement for any number of
arguments.
Also add a static assertion to give a more readable error for invalid
arguments that cannot be invoked. Also simplify _Invoker to reduce the
error cascade for ill-formed instantiations with non-invocable
arguments.
PR libstdc++/84535
* include/std/thread (thread::__not_same): New SFINAE helper.
(thread::thread(_Callable&&, _Args&&...)): Add SFINAE constraint that
first argument is not a std::thread. Add static assertion to check
INVOKE expression is valid.
(thread::thread(thread&), thread::thread(const thread&&)): Remove.
(thread::_Invoke::_M_invoke, thread::_Invoke::operator()): Use
__invoke_result for return types and remove exception specifications.
* testsuite/30_threads/thread/cons/84535.cc: New.
Tested powerpc64le-linux, committed to trunk.
commit d883c22939e8945eb09ec0fb65171f8f161bf142
Author: Jonathan Wakely
Date: Fri Feb 23 21:26:08 2018 +
PR libstdc++/84535 constrain std::thread constructor
The standard requires that the std::thread constructor is constrained so
it can't be called with a first argument of type std::thread. The
current implementation only meets that requirement if the constructor is
called with one argument, by using deleted overloads. This uses an
enable_if constraint to enforce the requirement for any number of
arguments.
Also add a static assertion to give a more readable error for invalid
arguments that cannot be invoked. Also simplify _Invoker to reduce the
error cascade for ill-formed instantiations with non-invocable
arguments.
PR libstdc++/84535
* include/std/thread (thread::__not_same): New SFINAE helper.
(thread::thread(_Callable&&, _Args&&...)): Add SFINAE constraint
that
first argument is not a std::thread. Add static assertion to check
INVOKE expression is valid.
(thread::thread(thread&), thread::thread(const thread&&)): Remove.
(thread::_Invoke::_M_invoke, thread::_Invoke::operator()): Use
__invoke_result for return types and remove exception
specifications.
* testsuite/30_threads/thread/cons/84535.cc: New.
diff --git a/libstdc++-v3/include/std/thread b/libstdc++-v3/include/std/thread
index 1cabd6ae0e6..61861b58520 100644
--- a/libstdc++-v3/include/std/thread
+++ b/libstdc++-v3/include/std/thread
@@ -102,21 +102,24 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
private:
id _M_id;
- public:
-thread() noexcept = default;
// _GLIBCXX_RESOLVE_LIB_DEFECTS
// 2097. packaged_task constructors should be constrained
-thread(thread&) = delete;
-thread(const thread&) = delete;
-thread(const thread&&) = delete;
+template
+ using __not_same = __not_, thread>>;
-thread(thread&& __t) noexcept
-{ swap(__t); }
+ public:
+thread() noexcept = default;
-template
+template>>
explicit
thread(_Callable&& __f, _Args&&... __args)
{
+ static_assert( __is_invocable::type,
+ typename decay<_Args>::type...>::value,
+ "std::thread arguments must be invocable after conversion to rvalues"
+ );
+
#ifdef GTHR_ACTIVE_PROXY
// Create a reference to pthread_create, not just the gthr weak symbol.
auto __depend = reinterpret_cast(&pthread_create);
@@ -135,6 +138,11 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
std::terminate();
}
+thread(const thread&) = delete;
+
+thread(thread&& __t) noexcept
+{ swap(__t); }
+
thread& operator=(const thread&) = delete;
thread& operator=(thread&& __t) noexcept
@@ -222,29 +230,29 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
{
_Tuple _M_t;
- template
- static __tuple_element_t<_Index, _Tuple>&&
- _S_declval();
+ template
+ struct __result;
+ template
+ struct __result>
+ : __invoke_result<_Fn, _Args...>
+ { };
template
- auto
+ typename __result<_Tuple>::type
_M_invoke(_Index_tuple<_Ind...>)
- noexcept(noexcept(std::__invoke(_S_declval<_Ind>()...)))
- -> decltype(std::__invoke(_S_declval<_Ind>()...))
{ return std::__invoke(std::get<_Ind>(std::move(_M_t))...); }
- using _Indices
- = typename _Build_index_tuple::value>::__type;
-
- auto
+ typename __result<_Tuple>::type
operator()()
- noexcept(noexcept(std::declval<_Invoker&>()._M_invoke(_Indices(
- -> decltype(std::declval<_Invoker&>
[PATCH] Fix PR85615
We're threading into a loop across an inner exit.
Bootstrapped and tested on x86_64-unknown-linux-gnu, applied.
Richard.
2018-05-03 Richard Biener
PR tree-optimization/85615
* tree-ssa-threadupdate.c (thread_block_1): Only allow exits
to loops not nested in BBs loop father to avoid creating multi-entry
loops.
* gcc.dg/torture/pr85615.c: New testcase.
Index: gcc/tree-ssa-threadupdate.c
===
--- gcc/tree-ssa-threadupdate.c (revision 259879)
+++ gcc/tree-ssa-threadupdate.c (working copy)
@@ -1309,7 +1309,9 @@ thread_block_1 (basic_block bb, bool nol
and thread this elsewhere, so just cancel the jump threading
request by clearing the AUX field now. */
if (bb->loop_father != e2->src->loop_father
- && !loop_exit_edge_p (e2->src->loop_father, e2))
+ && (!loop_exit_edge_p (e2->src->loop_father, e2)
+ || flow_loop_nested_p (bb->loop_father,
+e2->dest->loop_father)))
{
/* Since this case is not handled by our special code
to thread through a loop header, we must explicitly
Index: gcc/testsuite/gcc.dg/torture/pr85615.c
===
--- gcc/testsuite/gcc.dg/torture/pr85615.c (nonexistent)
+++ gcc/testsuite/gcc.dg/torture/pr85615.c (working copy)
@@ -0,0 +1,28 @@
+/* { dg-do compile } */
+
+long a, d;
+int b, c;
+void fn1()
+{
+ int e = -1L, f = 2, g = 8;
+ for (;;)
+{
+ for (; b; g++)
+ ;
+ int i;
+ for (; c;)
+ {
+ i = 5;
+ for (; e >= 1; i--)
+ ;
+ }
+ d = f ?: a;
+ if (d)
+ {
+ e = 0;
+ for (; i;)
+ for (; g < 3; f++)
+ ;
+ }
+}
+}
[testsuite] Add scan-offload-rtl-dump
Hi,
I'm posting this patch for the record.
I wrote it but haven't found a use for it yet. I find it easier to write
asm scans for nvptx than rtl ones.
Thanks,
- Tom
[testsuite] Add scan-offload-rtl-dump
2018-03-28 Tom de Vries
* lib/scanoffloadrtl.exp: New file.
* doc/sourcebuild.texi (Commands for use in dg-final, Scan optimization
dump files): Add offload-rtl.
---
gcc/doc/sourcebuild.texi | 3 +-
gcc/testsuite/lib/scanoffloadrtl.exp | 147 +++
2 files changed, 149 insertions(+), 1 deletion(-)
diff --git a/gcc/doc/sourcebuild.texi b/gcc/doc/sourcebuild.texi
index 4605a49..d748f8e 100644
--- a/gcc/doc/sourcebuild.texi
+++ b/gcc/doc/sourcebuild.texi
@@ -2589,7 +2589,8 @@ assembly output.
@subsubsection Scan optimization dump files
These commands are available for @var{kind} of @code{tree}, @code{ltrans-tree},
-@code{offload-tree}, @code{rtl}, @code{ipa}, and @code{wpa-ipa}.
+@code{offload-tree}, @code{rtl}, @code{offload-rtl}, @code{ipa}, and
+@code{wpa-ipa}.
@table @code
@item scan-@var{kind}-dump @var{regex} @var{suffix} [@{ target/xfail @var{selector} @}]
diff --git a/gcc/testsuite/lib/scanoffloadrtl.exp b/gcc/testsuite/lib/scanoffloadrtl.exp
new file mode 100644
index 000..e836f6d
--- /dev/null
+++ b/gcc/testsuite/lib/scanoffloadrtl.exp
@@ -0,0 +1,147 @@
+# Copyright (C) 2018 Free Software Foundation, Inc.
+
+# This program is free software; you can redistribute it and/or modify
+# it under the terms of the GNU General Public License as published by
+# the Free Software Foundation; either version 3 of the License, or
+# (at your option) any later version.
+#
+# This program is distributed in the hope that it will be useful,
+# but WITHOUT ANY WARRANTY; without even the implied warranty of
+# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+# GNU General Public License for more details.
+#
+# You should have received a copy of the GNU General Public License
+# along with GCC; see the file COPYING3. If not see
+#
[Aarch64] PR target/83009: Relax strict address checking for store pair lanes
Hi,
See below a patch to address PR 83009.
Tested with aarch64-linux-gnu bootstrap and regtests for c, c++ and fortran.
Ran the adjusted testcase for -mabi=ilp32.
Is this OK for gcc-9?
Cheers,
Andre
PR target/83009: Relax strict address checking for store pair lanes
The operand constraint for the memory address of store/load pair lanes
was enforcing strictly hardware registers be allowed as memory
addresses. We want to relax that such that these patterns can be used
by combine. During register allocation the register constraint will
enforce the correct register is chosen.
gcc
2018-05-xx Andre Vieira
PR target/83009
* config/aarch64/predicates.md (aarch64_mem_pair_lanes_operand):
Make
address check not strict.
gcc/testsuite
2018-05-xx Andre Vieira
PR target/83009
* gcc/target/aarch64/store_v2vec_lanes.c: Add extra tests.
diff --git a/gcc/config/aarch64/predicates.md b/gcc/config/aarch64/predicates.md
index
5d41d4350402b2a9e5941f160c6ab6f933bfff90..f29bc8e74f0070589014ac87fd22a95723ba9be8
100644
--- a/gcc/config/aarch64/predicates.md
+++ b/gcc/config/aarch64/predicates.md
@@ -222,7 +222,7 @@
;; as a 128-bit vec_concat.
(define_predicate "aarch64_mem_pair_lanes_operand"
(and (match_code "mem")
- (match_test "aarch64_legitimate_address_p (DFmode, XEXP (op, 0), 1,
+ (match_test "aarch64_legitimate_address_p (DFmode, XEXP (op, 0), 0,
ADDR_QUERY_LDP_STP)")))
(define_predicate "aarch64_prefetch_operand"
diff --git a/gcc/testsuite/gcc.target/aarch64/store_v2vec_lanes.c
b/gcc/testsuite/gcc.target/aarch64/store_v2vec_lanes.c
index
990aea32de6f8239effa95a081950684c6e11386..3296d04da14149d26d19da785663b87bd5ad8994
100644
--- a/gcc/testsuite/gcc.target/aarch64/store_v2vec_lanes.c
+++ b/gcc/testsuite/gcc.target/aarch64/store_v2vec_lanes.c
@@ -22,10 +22,32 @@ construct_lane_2 (long long *y, v2di *z)
z[2] = x;
}
+void
+construct_lane_3 (double **py, v2df **pz)
+{
+ double *y = *py;
+ v2df *z = *pz;
+ double y0 = y[0] + 1;
+ double y1 = y[1] + 2;
+ v2df x = {y0, y1};
+ z[2] = x;
+}
+
+void
+construct_lane_4 (long long **py, v2di **pz)
+{
+ long long *y = *py;
+ v2di *z = *pz;
+ long long y0 = y[0] + 1;
+ long long y1 = y[1] + 2;
+ v2di x = {y0, y1};
+ z[2] = x;
+}
+
/* We can use the load_pair_lanes pattern to vec_concat two DI/DF
values from consecutive memory into a 2-element vector by using
a Q-reg LDR. */
-/* { dg-final { scan-assembler-times "stp\td\[0-9\]+, d\[0-9\]+" 1 { xfail
ilp32 } } } */
-/* { dg-final { scan-assembler-times "stp\tx\[0-9\]+, x\[0-9\]+" 1 { xfail
ilp32 } } } */
-/* { dg-final { scan-assembler-not "ins\t" { xfail ilp32 } } } */
+/* { dg-final { scan-assembler-times "stp\td\[0-9\]+, d\[0-9\]+" 2 } } */
+/* { dg-final { scan-assembler-times "stp\tx\[0-9\]+, x\[0-9\]+" 2 } } */
+/* { dg-final { scan-assembler-not "ins\t" } } */
Re: [PATCH] PR libstdc++/84087 add default arguments to basic_string members (LWG 2268)
On 29/01/18 13:23 +, Jonathan Wakely wrote:
This implements LWG DR 2268, which is part of C++14 and so we should
have implemented it some time ago.
The change should be safe, but I think it's best to wait for Stage 1
rather than changing it now (even though I'll also backport it to the
branches once it's on trunk).
PR libstdc++/84087
* include/bits/basic_string.h [_GLIBCXX_USE_CXX11_ABI=1]
(append(const basic_string&, size_type, size_type)
(assign(const basic_string&, size_type, size_type)
(insert(size_type, const basic_string&, size_type, size_type)
(replace(size_type,size_type,const basic_string&,size_type,size_type)
(compare(size_type,size_type,constbasic_string&,size_type,size_type)):
Add default arguments (LWG 2268).
[_GLIBCXX_USE_CXX11_ABI=0]
(append(const basic_string&, size_type, size_type)
(assign(const basic_string&, size_type, size_type)
(insert(size_type, const basic_string&, size_type, size_type)
(replace(size_type,size_type,const basic_string&,size_type,size_type)
(compare(size_type,size_type,constbasic_string&,size_type,size_type)):
Likewise.
* testsuite/21_strings/basic_string/dr2268.cc: New test.
This is now on trunk.
commit 2de3cf506790b7dcc483821e5c5bc78e63516367
Author: Jonathan Wakely
Date: Mon Jan 29 12:53:24 2018 +
PR libstdc++/84087 add default arguments to basic_string members (LWG 2268)
This change was a DR against C++11 and so should have been implemented
years ago.
PR libstdc++/84087 LWG DR 2268 basic_string default arguments
* include/bits/basic_string.h [_GLIBCXX_USE_CXX11_ABI=1]
(append(const basic_string&, size_type, size_type)
(assign(const basic_string&, size_type, size_type)
(insert(size_type, const basic_string&, size_type, size_type)
(replace(size_type,size_type,const basic_string&,size_type,size_type)
(compare(size_type,size_type,constbasic_string&,size_type,size_type)):
Add default arguments (LWG 2268).
[_GLIBCXX_USE_CXX11_ABI=0]
(append(const basic_string&, size_type, size_type)
(assign(const basic_string&, size_type, size_type)
(insert(size_type, const basic_string&, size_type, size_type)
(replace(size_type,size_type,const basic_string&,size_type,size_type)
(compare(size_type,size_type,constbasic_string&,size_type,size_type)):
Likewise.
* testsuite/21_strings/basic_string/dr2268.cc: New test.
diff --git a/libstdc++-v3/include/bits/basic_string.h b/libstdc++-v3/include/bits/basic_string.h
index 3e8310e762c..5bffa1c72a1 100644
--- a/libstdc++-v3/include/bits/basic_string.h
+++ b/libstdc++-v3/include/bits/basic_string.h
@@ -1216,7 +1216,7 @@ _GLIBCXX_BEGIN_NAMESPACE_CXX11
* remainder of @a __str is appended.
*/
basic_string&
- append(const basic_string& __str, size_type __pos, size_type __n)
+ append(const basic_string& __str, size_type __pos, size_type __n = npos)
{ return _M_append(__str._M_data()
+ __str._M_check(__pos, "basic_string::append"),
__str._M_limit(__pos, __n)); }
@@ -1381,7 +1381,7 @@ _GLIBCXX_BEGIN_NAMESPACE_CXX11
* __str, the remainder of @a __str is used.
*/
basic_string&
- assign(const basic_string& __str, size_type __pos, size_type __n)
+ assign(const basic_string& __str, size_type __pos, size_type __n = npos)
{ return _M_replace(size_type(0), this->size(), __str._M_data()
+ __str._M_check(__pos, "basic_string::assign"),
__str._M_limit(__pos, __n)); }
@@ -1633,7 +1633,7 @@ _GLIBCXX_BEGIN_NAMESPACE_CXX11
*/
basic_string&
insert(size_type __pos1, const basic_string& __str,
- size_type __pos2, size_type __n)
+ size_type __pos2, size_type __n = npos)
{ return this->replace(__pos1, size_type(0), __str._M_data()
+ __str._M_check(__pos2, "basic_string::insert"),
__str._M_limit(__pos2, __n)); }
@@ -1881,7 +1881,7 @@ _GLIBCXX_BEGIN_NAMESPACE_CXX11
*/
basic_string&
replace(size_type __pos1, size_type __n1, const basic_string& __str,
- size_type __pos2, size_type __n2)
+ size_type __pos2, size_type __n2 = npos)
{ return this->replace(__pos1, __n1, __str._M_data()
+ __str._M_check(__pos2, "basic_string::replace"),
__str._M_limit(__pos2, __n2)); }
@@ -2941,7 +2941,7 @@ _GLIBCXX_BEGIN_NAMESPACE_CXX11
*/
int
compare(size_type __pos1, size_type __n1, const basic_string& __str,
- size_type __pos2, size_type __n2) const;
+ size_type __pos2, size_type __n2 = npos) const;
/**
* @brief Compare to a C string.
@@ -4135,7 +4135,7 @@ _GLIBCXX_END_NAMESPACE_CXX11
* remainder of @a __str is appended.
*/
basic_string&
- append(
Re: [PATCH] Add constant folding support for next{after,toward}{,f,l} (PR libstdc++/85466)
On Thu, May 03, 2018 at 11:44:09AM +0200, Richard Biener wrote:
> > + *RESULT = nextafter (*ARG0, *ARG1)
> > +
> > + or
> > +
> > + *RESULT = nexttoward (*ARG0, *ARG1)
> > +
> > + in format FORMAT. Return true on success. */
> > +
> > +static bool
> > +fold_const_nextafter (real_value *result, const real_value *arg0,
> > + const real_value *arg1, const real_format *format)
> > +{
> > + if (flag_signaling_nans
>
> HONOR_SNANS ()?
That requires a machine_mode or tree, but I don't have either of those,
nor the caller (fold_const_call_sss) has those.
I could change it to:
if (flag_signalling_nans
&& !flag_finite_math_only
&& format->has_nans
so that it would better duplicate what HONOR_SNANS actually tests.
Though, I think it is ok to punt if one of the operands is a signalling nan
even if flag_signalling_nans.
> > + && (REAL_VALUE_ISSIGNALING_NAN (*arg0)
> > + || REAL_VALUE_ISSIGNALING_NAN (*arg1)))
> > +return false;
> > +
> > + /* Don't handle composite modes, nor decimal, nor modes without
> > + inf or denorm at least for now. */
> > + if (format->pnan < format->p
> > + || format->b == 10
> > + || !format->has_inf
> > + || !format->has_denorm)
> > +return false;
>
> I wonder if we should assert in real_nextafter that we can actually
> handle the input? It likely returns garbage if fed with decimal float
> stuff?
Yes, but nobody would call it even if we removed the || format->b == 10
condition, the only builtins we fold this for have non-decimal
float/double/long double arguments.
I can surely add an assert with the same set of checks as the above ones.
Jakub
Re: [PATCH, rs6000] Add missing vec_max tests
Hi Carl, On Mon, Apr 30, 2018 at 09:52:27AM -0700, Carl Love wrote: > gcc/testsuite/ChangeLog: > > 2018-04-30 Carl Love > * gcc.target/powerpc/vsx-vector-6.h (foo): Add test for vec_max, > vec_trunc. > * gcc.target/powerpc/vsx-vector-6-le.c (dg-final): Update xvcmpeqdp, > xvcmpgtdp, xvcmpgedp counts. > @@ -65,8 +70,6 @@ void foo (vector double *out, vector double *in, vector > long *p_l, vector bool l >*out++ = vec_or (inb, in0); >*out++ = vec_perm (in0, in1, uc); >*out++ = vec_rint (in0); > - *out++ = vec_sel (in0, in1, inl); > - *out++ = vec_sel (in0, in1, inb); >*out++ = vec_sub (in0, in1); >*out++ = vec_sqrt (in0); >*out++ = vec_trunc (in0); Why does the patch remove these two vec_sel? If that is wanted, the changelog should mention this. Looks fine otherwise. Segher
Re: [PATCH] Add constant folding support for next{after,toward}{,f,l} (PR libstdc++/85466)
On Thu, May 03, 2018 at 06:35:50PM +0200, Jakub Jelinek wrote: > That requires a machine_mode or tree, but I don't have either of those, > nor the caller (fold_const_call_sss) has those. > > I could change it to: > if (flag_signalling_nans > && !flag_finite_math_only > && format->has_nans > so that it would better duplicate what HONOR_SNANS actually tests. > Though, I think it is ok to punt if one of the operands is a signalling nan > even if flag_signalling_nans. Though in theory the arg0's mode for which we have format pointer could not have nans, but arg1's mode (for which we only have the REAL_VALUE_TYPE) could have nans (or vice versa). Jakub
Re: [ARM] Fix PR85434: spill of stack protector's guard address
Hi!
On Wed, May 02, 2018 at 07:57:55AM +0100, Thomas Preudhomme wrote:
> As mentionned in the ticket this was my first thought but this means
> making the pattern aware of all the possible way the address could be
> access (PIC Vs non-PIC, Arm Vs Thumb-2 Vs Thumb-1) to decide how many
> scratch registers are needed. I'd rather reuse the existing pattern as
> much as possible to make sure they are well tested. Ideally I wanted a
> way to mark a REG RTX so that it is never spilled and such that the
> mark is propagated when the register is moved to another register or
> propagated. But that is a bigger change so decided it should be an
> improvement for later but needed another solution right now.
How would that work, esp. for pseudos? If too many regs have such a
mark then the compiler will have to sorry() or similar, not a good
thing at all.
> By the way about making sure the address is not left in a register, I
> have a question regarding the current stack_protect_set and
> stack_protect_check pattern and their requirements to have register
> cleared afterwards: why is that necessary? Currently not all registers
> are cleared and the guard is available in the canari before it is
> overwritten anyway so I don't see how clearing the register adds any
> extra security. What sort of attack is it protecting against?
>From md.texi:
@item @samp{stack_protect_set}
This pattern, if defined, moves a @code{ptr_mode} value from the memory
in operand 1 to the memory in operand 0 without leaving the value in
a register afterward. This is to avoid leaking the value some place
that an attacker might use to rewrite the stack guard slot after
having clobbered it.
(etc.)
Having the canary in a global variable makes it a lot easier for exploit
code to access it then if it is e.g. in TLS data. Actually leaking a
pointer to it would make it extra easy...
Segher
Re: [PATCH] Define std::remove_cvref and std::remove_cvref_t for C++2a
On 03/05/18 12:59 +0100, Jonathan Wakely wrote:
Also define __remove_cvref_t for internal use before C++2a.
* include/std/any (any_cast): Use __remove_cvref_t.
* include/std/tuple (__make_tuple): Likewise.
* include/std/type_traits (__remove_cvref_t): Define.
(__result_of_memobj, __result_of_memfun): Use __remove_cvref_t.
[__cplusplus > 201703L] (remove_cvref, remove_cvref_t): Define.
* include/std/variant (__erased_hash): Use __remove_cvref_t.
I forgot to add the tests, here they are.
Tested powerpc64le-linux, committed to trunk.
commit d559efa0a4605f54e72ce016668921b57fc6438b
Author: Jonathan Wakely
Date: Thu May 3 14:36:28 2018 +0100
Add tests for std::remove_cvref
* testsuite/20_util/remove_cvref/requirements/alias_decl.cc: New.
* testsuite/20_util/remove_cvref/requirements/explicit_instantiation.cc:
New.
* testsuite/20_util/remove_cvref/value.cc: New.
* testsuite/20_util/remove_cvref/value_ext.cc: New.
diff --git a/libstdc++-v3/testsuite/20_util/remove_cvref/requirements/alias_decl.cc b/libstdc++-v3/testsuite/20_util/remove_cvref/requirements/alias_decl.cc
new file mode 100644
index 000..1b2f67f75f6
--- /dev/null
+++ b/libstdc++-v3/testsuite/20_util/remove_cvref/requirements/alias_decl.cc
@@ -0,0 +1,37 @@
+// { dg-options "-std=gnu++2a" }
+// { dg-do compile { target c++2a } }
+
+// Copyright (C) 2018 Free Software Foundation, Inc.
+//
+// This file is part of the GNU ISO C++ Library. This library is free
+// software; you can redistribute it and/or modify it under the
+// terms of the GNU General Public License as published by the
+// Free Software Foundation; either version 3, or (at your option)
+// any later version.
+
+// This library is distributed in the hope that it will be useful,
+// but WITHOUT ANY WARRANTY; without even the implied warranty of
+// MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+// GNU General Public License for more details.
+
+// You should have received a copy of the GNU General Public License along
+// with this library; see the file COPYING3. If not see
+//
Re: [ARM] Fix PR85434: spill of stack protector's guard address
On 05/03/2018 10:55 AM, Segher Boessenkool wrote:
> Hi!
>
> On Wed, May 02, 2018 at 07:57:55AM +0100, Thomas Preudhomme wrote:
>> As mentionned in the ticket this was my first thought but this means
>> making the pattern aware of all the possible way the address could be
>> access (PIC Vs non-PIC, Arm Vs Thumb-2 Vs Thumb-1) to decide how many
>> scratch registers are needed. I'd rather reuse the existing pattern as
>> much as possible to make sure they are well tested. Ideally I wanted a
>> way to mark a REG RTX so that it is never spilled and such that the
>> mark is propagated when the register is moved to another register or
>> propagated. But that is a bigger change so decided it should be an
>> improvement for later but needed another solution right now.
>
> How would that work, esp. for pseudos? If too many regs have such a
> mark then the compiler will have to sorry() or similar, not a good
> thing at all.
>
>> By the way about making sure the address is not left in a register, I
>> have a question regarding the current stack_protect_set and
>> stack_protect_check pattern and their requirements to have register
>> cleared afterwards: why is that necessary? Currently not all registers
>> are cleared and the guard is available in the canari before it is
>> overwritten anyway so I don't see how clearing the register adds any
>> extra security. What sort of attack is it protecting against?
>
> From md.texi:
>
> @item @samp{stack_protect_set}
> This pattern, if defined, moves a @code{ptr_mode} value from the memory
> in operand 1 to the memory in operand 0 without leaving the value in
> a register afterward. This is to avoid leaking the value some place
> that an attacker might use to rewrite the stack guard slot after
> having clobbered it.
>
> (etc.)
>
> Having the canary in a global variable makes it a lot easier for exploit
> code to access it then if it is e.g. in TLS data. Actually leaking a
> pointer to it would make it extra easy...
Yup. And at least one guard (not the stack guard) has that properly.
It's stuffed into static storage. Not good.
Though I must admit it was awful convenient when tracking down a bug in
how the guard was used.
jeff
[gomp5] Extend defaultmap clause
Hi!
OpenMP 5.0 will extend the defaultmap clause from always just the
default(tofrom:scalar) form to have various default behaviors before the
: and various categories after the : (plus no : category to cover all
categories).
There are some issues I've raised on omp-lang, this patch implements what I
think is the general intent.
Tested on x86_64-linux, committed to gomp-5_0-branch.
2018-05-03 Jakub Jelinek
* tree-core.h (enum omp_clause_defaultmap_kind): New.
(struct tree_omp_clause): Add subcode.defaultmap_kind.
* tree.h (OMP_CLAUSE_DEFAULTMAP_KIND, OMP_CLAUSE_DEFAULTMAP_CATEGORY,
OMP_CLAUSE_DEFAULTMAP_BEHAVIOR, OMP_CLAUSE_DEFAULTMAP_SET_KIND):
Define.
* tree-pretty-print.c (dump_omp_clause): Handle new kinds of
OMP_CLAUSE_DEFAULTMAP.
* gimplify.c (enum gimplify_omp_var_data): Add GOVD_MAP_ALLOC_ONLY
and GOVD_MAP_FROM_ONLY.
(enum gimplify_defaultmap_kind): New.
(struct gimplify_omp_ctx): Remove target_map_scalars_firstprivate and
target_map_pointers_as_0len_arrays members, add defaultmap.
(new_omp_context): Initialize defaultmap member.
(omp_firstprivatize_variable): Test ctx->defaultmap[GDMK_SCALAR]
instead of ctx->omp_firstprivatize_variable.
(computable_teams_clause): Likewise.
(omp_notice_variable): Handle new defaultmap clause kinds.
(gimplify_scan_omp_clauses): Likewise.
(gimplify_adjust_omp_clauses_1): Handle GOVD_MAP_ALLOC_ONLY
and GOVD_MAP_FROM_ONLY.
c/
* c-parser.c (c_parser_omp_clause_defaultmap): Parse new kinds of
defaultmap clause.
cp/
* parser.c (cp_parser_omp_clause_defaultmap): Parse new kinds of
defaultmap clause.
fortran/
* trans-openmp.c (gfc_trans_omp_clauses): Use
OMP_CLAUSE_DEFAULTMAP_SET_KIND.
testsuite/
* c-c++-common/gomp/defaultmap-1.c: New test.
* c-c++-common/gomp/defaultmap-2.c: New test.
* c-c++-common/gomp/defaultmap-3.c: New test.
--- gcc/tree-core.h.jj 2018-04-30 14:21:18.317028050 +0200
+++ gcc/tree-core.h 2018-05-02 17:29:55.902260817 +0200
@@ -507,6 +507,25 @@ enum omp_clause_default_kind {
OMP_CLAUSE_DEFAULT_LAST
};
+enum omp_clause_defaultmap_kind {
+ OMP_CLAUSE_DEFAULTMAP_CATEGORY_UNSPECIFIED,
+ OMP_CLAUSE_DEFAULTMAP_CATEGORY_SCALAR,
+ OMP_CLAUSE_DEFAULTMAP_CATEGORY_AGGREGATE,
+ OMP_CLAUSE_DEFAULTMAP_CATEGORY_ALLOCATABLE,
+ OMP_CLAUSE_DEFAULTMAP_CATEGORY_POINTER,
+ OMP_CLAUSE_DEFAULTMAP_CATEGORY_MASK = 7,
+ OMP_CLAUSE_DEFAULTMAP_ALLOC = 1 * (OMP_CLAUSE_DEFAULTMAP_CATEGORY_MASK + 1),
+ OMP_CLAUSE_DEFAULTMAP_TO = 2 * (OMP_CLAUSE_DEFAULTMAP_CATEGORY_MASK + 1),
+ OMP_CLAUSE_DEFAULTMAP_FROM = 3 * (OMP_CLAUSE_DEFAULTMAP_CATEGORY_MASK + 1),
+ OMP_CLAUSE_DEFAULTMAP_TOFROM = 4 * (OMP_CLAUSE_DEFAULTMAP_CATEGORY_MASK + 1),
+ OMP_CLAUSE_DEFAULTMAP_FIRSTPRIVATE
+= 5 * (OMP_CLAUSE_DEFAULTMAP_CATEGORY_MASK + 1),
+ OMP_CLAUSE_DEFAULTMAP_NONE = 6 * (OMP_CLAUSE_DEFAULTMAP_CATEGORY_MASK + 1),
+ OMP_CLAUSE_DEFAULTMAP_DEFAULT
+= 7 * (OMP_CLAUSE_DEFAULTMAP_CATEGORY_MASK + 1),
+ OMP_CLAUSE_DEFAULTMAP_MASK = 7 * (OMP_CLAUSE_DEFAULTMAP_CATEGORY_MASK + 1)
+};
+
/* There is a TYPE_QUAL value for each type qualifier. They can be
combined by bitwise-or to form the complete set of qualifiers for a
type. */
@@ -1476,6 +1495,7 @@ struct GTY(()) tree_omp_clause {
enum tree_code reduction_code;
enum omp_clause_linear_kindlinear_kind;
enum tree_code if_modifier;
+enum omp_clause_defaultmap_kind defaultmap_kind;
/* The dimension a OMP_CLAUSE__GRIDDIM_ clause of a gridified target
construct describes. */
unsigned int dimension;
--- gcc/tree.h.jj 2018-04-30 13:49:45.209825769 +0200
+++ gcc/tree.h 2018-05-02 17:51:03.371341293 +0200
@@ -1695,6 +1695,18 @@ extern tree maybe_wrap_with_location (tr
#define OMP_CLAUSE_DEFAULT_KIND(NODE) \
(OMP_CLAUSE_SUBCODE_CHECK (NODE,
OMP_CLAUSE_DEFAULT)->omp_clause.subcode.default_kind)
+#define OMP_CLAUSE_DEFAULTMAP_KIND(NODE) \
+ (OMP_CLAUSE_SUBCODE_CHECK (NODE,
OMP_CLAUSE_DEFAULTMAP)->omp_clause.subcode.defaultmap_kind)
+#define OMP_CLAUSE_DEFAULTMAP_CATEGORY(NODE) \
+ ((enum omp_clause_defaultmap_kind) \
+ (OMP_CLAUSE_DEFAULTMAP_KIND (NODE) & OMP_CLAUSE_DEFAULTMAP_CATEGORY_MASK))
+#define OMP_CLAUSE_DEFAULTMAP_BEHAVIOR(NODE) \
+ ((enum omp_clause_defaultmap_kind) \
+ (OMP_CLAUSE_DEFAULTMAP_KIND (NODE) & OMP_CLAUSE_DEFAULTMAP_MASK))
+#define OMP_CLAUSE_DEFAULTMAP_SET_KIND(NODE, BEHAVIOR, CATEGORY) \
+ (OMP_CLAUSE_DEFAULTMAP_KIND (NODE) \
+ = (enum omp_clause_defaultmap_kind) (CATEGORY | BEHAVIOR))
+
#define OMP_CLAUSE_TILE_LIST(NODE) \
OMP_CLAUSE_OPERAND (OMP_CLAUSE_SUBCODE_CHECK (NODE, OMP_CLAUSE_TILE), 0)
#define OMP_CLAUSE_TILE_ITERVAR(NODE) \
--- gcc/tree-pretty-print.c.jj 2018-04-30 13:49:23.109778102 +0200
+++ gcc/tree-pretty-print.c 2018-05-02 17:35:03.11153
Re: [PATCH] [Microblaze]: PIC Data Text Relative
--resend Michael's reply On Mon, Apr 30, 2018 at 1:19 PM, Michael Eager wrote: > > Applied -- Committed revision 259758. > > Andrew -- Please re-run GCC regression test to verify that nothing > was lost in the editing. > > > > -- > Michael Eagerea...@eagerm.com > 1960 Park Blvd., Palo Alto, CA 94306 > -- Andrew
[PATCH] PowerPC address support clean, patch 1 of 4
These patches were previously posted in March as a RFC, and I would like to
check them into the trunk. These patches make the mode_supports* functions use
similar names for the functions that return if a mode supports D-FORM, DS-FORM,
and/or DQ-FORM instructions, and add the ability to ask whether a particular
reload register class supports a particular D*-form instruction.
This is patch #1 of 4 and it renames the mode_supports_vsx_dform_quad function
to be mode_supports_dq_form.
I have done a bootstrap and make check comparison on a little endian power8
system, and there were no regressions. Can I check it in?
2018-05-03 Michael Meissner
* config/rs6000/rs6000.c (mode_supports_dq_form): Rename
mode_supports_vsx_dform_quad to mode_supports_dq_form.
(mode_supports_vsx_dform_quad): Likewise.
(quad_address_p): Likewise.
(reg_offset_addressing_ok_p): Likewise.
(offsettable_ok_by_alignment): Likewise.
(rs6000_legitimate_offset_address_p): Likewise.
(legitimate_lo_sum_address_p): Likewise.
(rs6000_legitimize_address): Likewise.
(rs6000_legitimize_reload_address): Likewise.
(rs6000_secondary_reload_inner): Likewise.
(rs6000_preferred_reload_class): Likewise.
(rs6000_output_move_128bit): 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.c
===
--- gcc/config/rs6000/rs6000.c (revision 259864)
+++ gcc/config/rs6000/rs6000.c (working copy)
@@ -649,7 +649,7 @@ mode_supports_vmx_dform (machine_mode mo
is more limited than normal d-form addressing in that the offset must be
aligned on a 16-byte boundary. */
static inline bool
-mode_supports_vsx_dform_quad (machine_mode mode)
+mode_supports_dq_form (machine_mode mode)
{
return ((reg_addr[mode].addr_mask[RELOAD_REG_ANY] & RELOAD_REG_QUAD_OFFSET)
!= 0);
@@ -7922,7 +7922,7 @@ quad_address_p (rtx addr, machine_mode m
if (legitimate_indirect_address_p (addr, strict))
return true;
- if (VECTOR_MODE_P (mode) && !mode_supports_vsx_dform_quad (mode))
+ if (VECTOR_MODE_P (mode) && !mode_supports_dq_form (mode))
return false;
if (GET_CODE (addr) != PLUS)
@@ -8104,7 +8104,7 @@ reg_offset_addressing_ok_p (machine_mode
IEEE 128-bit floating point that is passed in a single vector
register. */
if (VECTOR_MEM_ALTIVEC_OR_VSX_P (mode))
- return mode_supports_vsx_dform_quad (mode);
+ return mode_supports_dq_form (mode);
break;
case E_SDmode:
@@ -8164,7 +8164,7 @@ offsettable_ok_by_alignment (rtx op, HOS
/* ISA 3.0 vector d-form addressing is restricted, don't allow
SYMBOL_REF. */
- if (mode_supports_vsx_dform_quad (mode))
+ if (mode_supports_dq_form (mode))
return false;
dsize = GET_MODE_SIZE (mode);
@@ -8335,7 +8335,7 @@ rs6000_legitimate_offset_address_p (mach
return false;
if (!INT_REG_OK_FOR_BASE_P (XEXP (x, 0), strict))
return false;
- if (mode_supports_vsx_dform_quad (mode))
+ if (mode_supports_dq_form (mode))
return quad_address_p (x, mode, strict);
if (!reg_offset_addressing_ok_p (mode))
return virtual_stack_registers_memory_p (x);
@@ -8448,7 +8448,7 @@ legitimate_lo_sum_address_p (machine_mod
if (!INT_REG_OK_FOR_BASE_P (XEXP (x, 0), strict))
return false;
/* quad word addresses are restricted, and we can't use LO_SUM. */
- if (mode_supports_vsx_dform_quad (mode))
+ if (mode_supports_dq_form (mode))
return false;
x = XEXP (x, 1);
@@ -8513,7 +8513,7 @@ rs6000_legitimize_address (rtx x, rtx ol
unsigned int extra;
if (!reg_offset_addressing_ok_p (mode)
- || mode_supports_vsx_dform_quad (mode))
+ || mode_supports_dq_form (mode))
{
if (virtual_stack_registers_memory_p (x))
return x;
@@ -9229,7 +9229,7 @@ rs6000_legitimize_reload_address (rtx x,
int ind_levels ATTRIBUTE_UNUSED, int *win)
{
bool reg_offset_p = reg_offset_addressing_ok_p (mode);
- bool quad_offset_p = mode_supports_vsx_dform_quad (mode);
+ bool quad_offset_p = mode_supports_dq_form (mode);
/* Nasty hack for vsx_splat_v2df/v2di load from mem, which takes a
DFmode/DImode MEM. Ditto for ISA 3.0 vsx_splat_v4sf/v4si. */
@@ -9515,7 +9515,7 @@ static bool
rs6000_legitimate_address_p (machine_mode mode, rtx x, bool reg_ok_strict)
{
bool reg_offset_p = reg_offset_addressing_ok_p (mode);
- bool quad_offset_p = mode_supports_vsx_dform_quad (mode);
+ bool quad_offset_p = mode_supports_dq_form (mode);
/* If this is an unaligned stvx/ldvx type address, discard the outer AND. */
if (VECTOR_MEM_ALTIVEC_P (mode)
@@ -19743,7 +19743,7 @@ rs6000_secondary_reload_inner (rtx reg,
}
}
- else if (mode_supports_vsx_dform_quad (mode) &&
[PATCH] PowerPC address support clean, patch 2 of 4
These patches were previously posted in March as a RFC, and I would like to
check them into the trunk. These patches make the mode_supports* functions use
similar names for the functions that return if a mode supports D-FORM, DS-FORM,
and/or DQ-FORM instructions, and add the ability to ask whether a particular
reload register class supports a particular D*-form instruction.
This is patch #2 of 4 and it moves some of the mode support functions to be
next to each other in the source.
I have done a bootstrap with patches 1-4 and did a make check comparison on a
little endian power8 system, and there were no regressions. Can I check it in?
2018-05-03 Michael Meissner
* config/rs6000/rs6000.c (mode_supports_vmx_dform): Move these
functions to be next to the other mode_supports functions.
(mode_supports_dq_form): 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.c
===
--- gcc/config/rs6000/rs6000.c (revision 259876)
+++ gcc/config/rs6000/rs6000.c (working copy)
@@ -553,6 +553,23 @@ mode_supports_pre_modify_p (machine_mode
!= 0);
}
+/* Return true if we have D-form addressing in altivec registers. */
+static inline bool
+mode_supports_vmx_dform (machine_mode mode)
+{
+ return ((reg_addr[mode].addr_mask[RELOAD_REG_VMX] & RELOAD_REG_OFFSET) != 0);
+}
+
+/* Return true if we have D-form addressing in VSX registers. This addressing
+ is more limited than normal d-form addressing in that the offset must be
+ aligned on a 16-byte boundary. */
+static inline bool
+mode_supports_dq_form (machine_mode mode)
+{
+ return ((reg_addr[mode].addr_mask[RELOAD_REG_ANY] & RELOAD_REG_QUAD_OFFSET)
+ != 0);
+}
+
/* Given that there exists at least one variable that is set (produced)
by OUT_INSN and read (consumed) by IN_INSN, return true iff
IN_INSN represents one or more memory store operations and none of
@@ -638,23 +655,6 @@ rs6000_store_data_bypass_p (rtx_insn *ou
return store_data_bypass_p (out_insn, in_insn);
}
-/* Return true if we have D-form addressing in altivec registers. */
-static inline bool
-mode_supports_vmx_dform (machine_mode mode)
-{
- return ((reg_addr[mode].addr_mask[RELOAD_REG_VMX] & RELOAD_REG_OFFSET) != 0);
-}
-
-/* Return true if we have D-form addressing in VSX registers. This addressing
- is more limited than normal d-form addressing in that the offset must be
- aligned on a 16-byte boundary. */
-static inline bool
-mode_supports_dq_form (machine_mode mode)
-{
- return ((reg_addr[mode].addr_mask[RELOAD_REG_ANY] & RELOAD_REG_QUAD_OFFSET)
- != 0);
-}
-
/* Processor costs (relative to an add) */
Go patch committed: Avoid crashing on invalid non-integer array length
This patch to the Go frontend by Than McIntosh tweaks the array type
checking code to avoid crashing on array types whose length
expressions are explicit non-integer types (for example,
"float64(10)"). If such constructs are seen, issue an "invalid array
bound" error. This fixes https://golang.org/issue/13486.
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 259875)
+++ gcc/go/gofrontend/MERGE (working copy)
@@ -1,4 +1,4 @@
-e367bffce3d2c49b456fdf41ab097bded2bcbc3b
+85ca682349af2cb1aa6b1eecac794aeb73d24f15
The first line of this file holds the git revision number of the last
merge done from the gofrontend repository.
Index: gcc/go/gofrontend/types.cc
===
--- gcc/go/gofrontend/types.cc (revision 259805)
+++ gcc/go/gofrontend/types.cc (working copy)
@@ -7016,6 +7016,16 @@ Array_type::verify_length()
return false;
}
+ // For array types, the length expression can be an untyped constant
+ // representable as an int, but we don't allow explicitly non-integer
+ // values such as "float64(10)". See issues #13485 and #13486.
+ if (this->length_->type()->integer_type() == NULL
+ && !this->length_->type()->is_error_type())
+{
+ go_error_at(this->length_->location(), "invalid array bound");
+ return false;
+}
+
Numeric_constant nc;
if (!this->length_->numeric_constant_value(&nc))
{
Re: [PATCH] PowerPC address support clean, patch 3 of 4
These patches were previously posted in March as a RFC, and I would like to
check them into the trunk. These patches make the mode_supports* functions use
similar names for the functions that return if a mode supports D-FORM, DS-FORM,
and/or DQ-FORM instructions, and add the ability to ask whether a particular
reload register class supports a particular D*-form instruction.
This is patch #3 of 4.
I have done a bootstrap with patches 1-4 and did a make check comparison on a
little endian power8 system, and there were no regressions. Can I check it in?
2018-05-03 Michael Meissner
* config/rs6000/rs6000.c (mode_supports_d_form): Rename
mode_supports_vmx_dform to mode_supports_d_form. Add an optional
argument to say which reload register class to use. Change all
callers to pass in the RELOAD_REG_VMX class explicitly.
(rs6000_secondary_reload): Likewise.
(rs6000_preferred_reload_class): Likewise.
(rs6000_secondary_reload_class): 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.c
===
--- gcc/config/rs6000/rs6000.c (revision 259877)
+++ gcc/config/rs6000/rs6000.c (working copy)
@@ -553,11 +553,14 @@ mode_supports_pre_modify_p (machine_mode
!= 0);
}
-/* Return true if we have D-form addressing in altivec registers. */
+/* Return true if we have D-form addressing (register+offset) in either a
+ specific reload register class or whether some reload register class
+ supports d-form addressing. */
static inline bool
-mode_supports_vmx_dform (machine_mode mode)
+mode_supports_d_form (machine_mode mode,
+ enum rs6000_reload_reg_type rt = RELOAD_REG_ANY)
{
- return ((reg_addr[mode].addr_mask[RELOAD_REG_VMX] & RELOAD_REG_OFFSET) != 0);
+ return ((reg_addr[mode].addr_mask[rt] & RELOAD_REG_OFFSET) != 0);
}
/* Return true if we have D-form addressing in VSX registers. This addressing
@@ -19415,7 +19418,7 @@ rs6000_secondary_reload (bool in_p,
point register, unless we have D-form addressing. Also make sure that
non-zero constants use a FPR. */
if (!done_p && reg_addr[mode].scalar_in_vmx_p
- && !mode_supports_vmx_dform (mode)
+ && !mode_supports_d_form (mode, RELOAD_REG_VMX)
&& (rclass == VSX_REGS || rclass == ALTIVEC_REGS)
&& (memory_p || (GET_CODE (x) == CONST_DOUBLE)))
{
@@ -19978,7 +19981,7 @@ rs6000_preferred_reload_class (rtx x, en
}
/* D-form addressing can easily reload the value. */
- if (mode_supports_vmx_dform (mode)
+ if (mode_supports_d_form (mode, RELOAD_REG_VMX)
|| mode_supports_dq_form (mode))
return rclass;
@@ -20135,7 +20138,7 @@ rs6000_secondary_reload_class (enum reg_
instead of reloading the secondary memory address for Altivec moves. */
if (TARGET_VSX
&& GET_MODE_SIZE (mode) < 16
- && !mode_supports_vmx_dform (mode)
+ && !mode_supports_d_form (mode, RELOAD_REG_VMX)
&& (((rclass == GENERAL_REGS || rclass == BASE_REGS)
&& (regno >= 0 && ALTIVEC_REGNO_P (regno)))
|| ((rclass == VSX_REGS || rclass == ALTIVEC_REGS)
Re: [PATCH] PowerPC address support clean, patch 4 of 4
These patches were previously posted in March as a RFC, and I would like to
check them into the trunk. These patches make the mode_supports* functions use
similar names for the functions that return if a mode supports D-FORM, DS-FORM,
and/or DQ-FORM instructions, and add the ability to ask whether a particular
reload register class supports a particular D*-form instruction.
This is patch #4 of 4.
I have done a bootstrap with patches 1-4 and did a make check comparison on a
little endian power8 system, and there were no regressions. Can I check it in?
2018-05-03 Michael Meissner
* config/rs6000/rs6000.c (mode_supports_pre_incdec_p): Add
additional argument to specify the reload register class to use,
defaulting to RELOAD_REG_ANY.
(mode_supports_pre_modify_p): Likewise.
(mode_supports_dq_form): 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.c
===
--- gcc/config/rs6000/rs6000.c (revision 259878)
+++ gcc/config/rs6000/rs6000.c (revision 259879)
@@ -537,20 +537,22 @@ struct rs6000_reg_addr {
static struct rs6000_reg_addr reg_addr[NUM_MACHINE_MODES];
-/* Helper function to say whether a mode supports PRE_INC or PRE_DEC. */
+/* Helper function to say whether a mode supports PRE_INC or PRE_DEC in a given
+ reload register class or if some reload register class supports it. */
static inline bool
-mode_supports_pre_incdec_p (machine_mode mode)
+mode_supports_pre_incdec_p (machine_mode mode,
+ enum rs6000_reload_reg_type rt = RELOAD_REG_ANY)
{
- return ((reg_addr[mode].addr_mask[RELOAD_REG_ANY] & RELOAD_REG_PRE_INCDEC)
- != 0);
+ return ((reg_addr[mode].addr_mask[rt] & RELOAD_REG_PRE_INCDEC) != 0);
}
-/* Helper function to say whether a mode supports PRE_MODIFY. */
+/* Helper function to say whether a mode supports PRE_MODIFY in a given
+ reload register class or if some reload register class supports it.. */
static inline bool
-mode_supports_pre_modify_p (machine_mode mode)
+mode_supports_pre_modify_p (machine_mode mode,
+ enum rs6000_reload_reg_type rt = RELOAD_REG_ANY)
{
- return ((reg_addr[mode].addr_mask[RELOAD_REG_ANY] & RELOAD_REG_PRE_MODIFY)
- != 0);
+ return ((reg_addr[mode].addr_mask[rt] & RELOAD_REG_PRE_MODIFY) != 0);
}
/* Return true if we have D-form addressing (register+offset) in either a
@@ -563,14 +565,14 @@ mode_supports_d_form (machine_mode mode,
return ((reg_addr[mode].addr_mask[rt] & RELOAD_REG_OFFSET) != 0);
}
-/* Return true if we have D-form addressing in VSX registers. This addressing
- is more limited than normal d-form addressing in that the offset must be
- aligned on a 16-byte boundary. */
+/* Return true if we have DQ-form addressing in a given reload register class
+ or if some reload register class supports it. DQ-form addressing must have
+ the bottom 4 bits set to 0. */
static inline bool
-mode_supports_dq_form (machine_mode mode)
+mode_supports_dq_form (machine_mode mode,
+ enum rs6000_reload_reg_type rt = RELOAD_REG_ANY)
{
- return ((reg_addr[mode].addr_mask[RELOAD_REG_ANY] & RELOAD_REG_QUAD_OFFSET)
- != 0);
+ return ((reg_addr[mode].addr_mask[rt] & RELOAD_REG_QUAD_OFFSET) != 0);
}
/* Given that there exists at least one variable that is set (produced)
Re: [PATCH] Fix PR85627 (and more)
> Test coverage of -fnon-call-exceptions is notoriously bad and I'm not > sure whether Ada uses GCCs complex types. Eric? It does, but only with a GNAT-specific pragma: https://gcc.gnu.org/onlinedocs/gcc-8.1.0/gnat_rm/Pragma-Complex_005fRepresentation.html#Pragma-Complex_005fRepresentation whose usage is probably very limited (and inexistent in ACATS of course). -- Eric Botcazou
Re: Patch ping (Re: [PATCH] Add _mm512_{,mask_}mullox_epi64 intrinsics (PR target/85530))
Hi Jakub,
> On 3 May 2018, at 12:28, Jakub Jelinek wrote:
>
> On Thu, Apr 26, 2018 at 10:09:48PM +0200, Jakub Jelinek wrote:
>> ICC apparently has these two intrinsics (why it doesn't have a maskz_ one
>> is unclear to me) which are like _mm512_{,mask_}mullo_epi64, except they are
>> available in AVX512F rather than just AVX512DQ and if AVX512DQ is not
>> enabled they expand to 3 vpmuludq instructions + 3 shifts + 2 adds; for
>> AVX512DQ they are the same as mullo without x.
>>
>> Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?
>>
>> 2018-04-26 Jakub Jelinek
>>
>> PR target/85530
>> * config/i386/avx512fintrin.h (_mm512_mullox_epi64,
>> _mm512_mask_mullox_epi64): New intrinsics.
>>
>> * gcc.target/i386/avx512f-vpmullq-1.c: New test.
>> * gcc.target/i386/avx512f-vpmullq-2.c: New test.
>> * gcc.target/i386/avx512dq-vpmullq-3.c: New test.
>> * gcc.target/i386/avx512dq-vpmullq-4.c: New test.
>
> I'd like to ping this patch, ok for trunk?
Your patch is ok for trunk.
>
> Jakub
--
Thanks, K
[PATCH] PowerPC: Reformat move insns to make them clearing, patch #1 of 5
These patches were previously posted in March as RFC's. These patches just reformat the floating point move insns to make it easier to figure out which constraints and attributes are used for particular alternatives. I have built the compiler on a little endian power8 system with all 5 patches applied and it bootstraps without error. There were no regressions in make check output. Can I check these patches in? This is patch #1 of 5. 2018-05-03 Michael Meissner * config/rs6000/rs6000.md (mov_hardfloat32, FMOVE64): Reformat alternatives and attributes so it is easier to identify which constraints/attributes go with which instruction. -- 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.md === --- gcc/config/rs6000/rs6000.md (revision 259864) +++ gcc/config/rs6000/rs6000.md (working copy) @@ -7388,9 +7388,21 @@ (define_split ;; If we have FPR registers, rs6000_emit_move has moved all constants to memory, ;; except for 0.0 which can be created on VSX with an xor instruction. +;; STFD LFD FMR LXSDSTXSD +;; LXSD STXSD XXLOR XXLXOR GPR<-0 +;; LWZ STW MR + (define_insn "*mov_hardfloat32" - [(set (match_operand:FMOVE64 0 "nonimmediate_operand" "=m,d,d,,wY,,Z,,,!r,Y,r,!r") - (match_operand:FMOVE64 1 "input_operand" "d,m,d,wY,,Z,r,Y,r"))] + [(set (match_operand:FMOVE64 0 "nonimmediate_operand" +"=m, d, d, , wY, + , Z, , , !r, + Y, r, !r") + + (match_operand:FMOVE64 1 "input_operand" + "d, m, d, wY, , + Z, , , , , + r, Y, r"))] + "! TARGET_POWERPC64 && TARGET_HARD_FLOAT && TARGET_DOUBLE_FLOAT && (gpc_reg_operand (operands[0], mode) || gpc_reg_operand (operands[1], mode))" @@ -7408,9 +7420,16 @@ (define_insn "*mov_hardfloat32" # # #" - [(set_attr "type" "fpstore,fpload,fpsimple,fpload,fpstore,fpload,fpstore,veclogical,veclogical,two,store,load,two") + [(set_attr "type" +"fpstore, fpload, fpsimple, fpload, fpstore, + fpload, fpstore,veclogical, veclogical, two, + store, load, two") + (set_attr "size" "64") - (set_attr "length" "4,4,4,4,4,4,4,4,4,8,8,8,8")]) + (set_attr "length" +"4, 4, 4, 4, 4, + 4, 4, 4, 4, 8, + 8, 8, 8")]) (define_insn "*mov_softfloat32" [(set (match_operand:FMOVE64 0 "nonimmediate_operand" "=Y,r,r,r,r,r")
[PATCH] PowerPC: Reformat move insns to make them clearing, patch #2 of 5
These patches were previously posted in March as RFC's. These patches just reformat the floating point move insns to make it easier to figure out which constraints and attributes are used for particular alternatives. I have built the compiler on a little endian power8 system with all 5 patches applied and it bootstraps without error. There were no regressions in make check output. Can I check these patches in? This is patch #2 of 5. 2018-05-03 Michael Meissner * config/rs6000/rs6000.md (mov_softfloat32, FMOVE64): Reformat alternatives and attributes so it is easier to identify which constraints/attributes go with which instruction. -- 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.md === --- gcc/config/rs6000/rs6000.md (revision 259882) +++ gcc/config/rs6000/rs6000.md (working copy) @@ -7431,16 +7431,25 @@ (define_insn "*mov_hardfloat32" 4, 4, 4, 4, 8, 8, 8, 8")]) +;; STW LWZ MR G-const H-const F-const + (define_insn "*mov_softfloat32" - [(set (match_operand:FMOVE64 0 "nonimmediate_operand" "=Y,r,r,r,r,r") - (match_operand:FMOVE64 1 "input_operand" "r,Y,r,G,H,F"))] + [(set (match_operand:FMOVE64 0 "nonimmediate_operand" + "=Y, r, r, r, r, r") + + (match_operand:FMOVE64 1 "input_operand" +"r, Y, r, G, H, F"))] + "! TARGET_POWERPC64 && (TARGET_SINGLE_FLOAT || TARGET_SOFT_FLOAT) && (gpc_reg_operand (operands[0], mode) || gpc_reg_operand (operands[1], mode))" "#" - [(set_attr "type" "store,load,two,*,*,*") - (set_attr "length" "8,8,8,8,12,16")]) + [(set_attr "type" +"store, load, two,*, *, *") + + (set_attr "length" + "8, 8, 8, 8, 12, 16")]) ; ld/std require word-aligned displacements -> 'Y' constraint. ; List Y->r and r->Y before r->r for reload.
[PATCH] PowerPC: Reformat move insns to make them clearing, patch #4 of 5
These patches were previously posted in March as RFC's. These patches just reformat the floating point move insns to make it easier to figure out which constraints and attributes are used for particular alternatives. I have built the compiler on a little endian power8 system with all 5 patches applied and it bootstraps without error. There were no regressions in make check output. Can I check these patches in? This is patch #4 of 5. 2018-05-03 Michael Meissner * config/rs6000/rs6000.md (mov_softfloat64, FMOVE64): Reformat alternatives and attributes so it is easier to identify which constraints/attributes go with which instruction. -- 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.md === --- gcc/config/rs6000/rs6000.md (revision 259884) +++ gcc/config/rs6000/rs6000.md (working copy) @@ -7505,9 +7505,18 @@ (define_insn "*mov_hardfloat64" (set_attr "size" "64") (set_attr "length" "4")]) +;; STD LD MR MT MF G-const +;; H-const F-const Special + (define_insn "*mov_softfloat64" - [(set (match_operand:FMOVE64 0 "nonimmediate_operand" "=Y,r,r,cl,r,r,r,r,*h") - (match_operand:FMOVE64 1 "input_operand" "r,Y,r,r,h,G,H,F,0"))] + [(set (match_operand:FMOVE64 0 "nonimmediate_operand" + "=Y, r, r, cl, r, r, + r, r, *h") + + (match_operand:FMOVE64 1 "input_operand" +"r, Y, r, r, h, G, + H, F, 0"))] + "TARGET_POWERPC64 && TARGET_SOFT_FLOAT && (gpc_reg_operand (operands[0], mode) || gpc_reg_operand (operands[1], mode))" @@ -7521,8 +7530,13 @@ (define_insn "*mov_softfloat64" # # nop" - [(set_attr "type" "store,load,*,mtjmpr,mfjmpr,*,*,*,*") - (set_attr "length" "4,4,4,4,4,8,12,16,4")]) + [(set_attr "type" +"store, load, *, mtjmpr, mfjmpr, *, + *, *, *") + + (set_attr "length" +"4, 4, 4, 4, 4, 8, + 12, 16, 4")]) (define_expand "mov" [(set (match_operand:FMOVE128 0 "general_operand")
[PATCH] PowerPC: Reformat move insns to make them clearing, patch #3 of 5
These patches were previously posted in March as RFC's. These patches just reformat the floating point move insns to make it easier to figure out which constraints and attributes are used for particular alternatives. I have built the compiler on a little endian power8 system with all 5 patches applied and it bootstraps without error. There were no regressions in make check output. Can I check these patches in? This is patch #3 of 5. 2018-05-03 Michael Meissner * config/rs6000/rs6000.md (mov_hardfloat64, FMOVE64): Reformat alternatives and attributes so it is easier to identify which constraints/attributes go with which instruction. -- 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.md === --- gcc/config/rs6000/rs6000.md (revision 259883) +++ gcc/config/rs6000/rs6000.md (working copy) @@ -7453,9 +7453,25 @@ (define_insn "*mov_softfloat32" ; ld/std require word-aligned displacements -> 'Y' constraint. ; List Y->r and r->Y before r->r for reload. + +;; STFD LFD FMR LXSDSTXSD +;; LXSDXSTXSDX XXLOR XXLXOR LI 0 +;; STD LD MR MT MF +;; NOP MFTGPR MFFGPR MTVSRD MFVSRD + (define_insn "*mov_hardfloat64" - [(set (match_operand:FMOVE64 0 "nonimmediate_operand" "=m,d,d,,wY,,Z,,,!r,Y,r,!r,*c*l,!r,*h,r,wg,r,") - (match_operand:FMOVE64 1 "input_operand" "d,m,d,wY,,Z,r,Y,r,r,h,0,wg,r,,r"))] + [(set (match_operand:FMOVE64 0 "nonimmediate_operand" + "=m, d, d, , wY, + ,Z, , , !r, + Y, r, !r, *c*l, !r, +*h, r, wg, r, ") + + (match_operand:FMOVE64 1 "input_operand" +"d, m, d, wY, , + Z, , , , , + r, Y, r, r, h, + 0, wg, r, , r"))] + "TARGET_POWERPC64 && TARGET_HARD_FLOAT && TARGET_DOUBLE_FLOAT && (gpc_reg_operand (operands[0], mode) || gpc_reg_operand (operands[1], mode))" @@ -7480,7 +7496,12 @@ (define_insn "*mov_hardfloat64" mffgpr %0,%1 mfvsrd %0,%x1 mtvsrd %x0,%1" - [(set_attr "type" "fpstore,fpload,fpsimple,fpload,fpstore,fpload,fpstore,veclogical,veclogical,integer,store,load,*,mtjmpr,mfjmpr,*,mftgpr,mffgpr,mftgpr,mffgpr") + [(set_attr "type" +"fpstore, fpload, fpsimple, fpload, fpstore, + fpload, fpstore,veclogical, veclogical, integer, + store, load, *, mtjmpr, mfjmpr, + *, mftgpr, mffgpr, mftgpr,mffgpr") + (set_attr "size" "64") (set_attr "length" "4")])
[PATCH] PowerPC: Reformat move insns to make them clearing, patch #5 of 5
These patches were previously posted in March as RFC's. These patches just reformat the floating point move insns to make it easier to figure out which constraints and attributes are used for particular alternatives. I have built the compiler on a little endian power8 system with all 5 patches applied and it bootstraps without error. There were no regressions in make check output. Can I check these patches in? This is patch #5 of 5. 2018-05-03 Michael Meissner * config/rs6000/rs6000.md (mov_softfloat, FMOVE32): Reformat alternatives and attributes so it is easier to identify which constraints/attributes go with which instruction. -- 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.md === --- gcc/config/rs6000/rs6000.md (revision 259885) +++ gcc/config/rs6000/rs6000.md (working copy) @@ -7207,9 +7207,17 @@ (define_insn "movsd_hardfloat" "load, fpload,store, fpstore, mffgpr,mftgpr, fpsimple, *, mtjmpr,mfjmpr,*")]) +;; MR MT%0 MF%0 LWZSTWLI +;; LIS G-const. F/n-const NOP (define_insn "*mov_softfloat" - [(set (match_operand:FMOVE32 0 "nonimmediate_operand" "=r,cl,r,r,m,r,r,r,r,*h") - (match_operand:FMOVE32 1 "input_operand" "r,r,h,m,r,I,L,G,Fn,0"))] + [(set (match_operand:FMOVE32 0 "nonimmediate_operand" + "=r, cl,r, r, m, r, + r, r, r, *h") + + (match_operand:FMOVE32 1 "input_operand" +"r, r, h, m, r, I, + L, G, Fn,0"))] + "(gpc_reg_operand (operands[0], mode) || gpc_reg_operand (operands[1], mode)) && TARGET_SOFT_FLOAT" @@ -7224,8 +7232,13 @@ (define_insn "*mov_softfloat" # # nop" - [(set_attr "type" "*,mtjmpr,mfjmpr,load,store,*,*,*,*,*") - (set_attr "length" "4,4,4,4,4,4,4,4,8,4")]) + [(set_attr "type" + "*, mtjmpr,mfjmpr,load, store, *, + *, *, *, *") + + (set_attr "length" + "4, 4, 4, 4, 4, 4, + 4, 4, 8, 4")]) ;; Like movsf, but adjust a SI value to be used in a SF context, i.e. ;; (set (reg:SF ...) (subreg:SF (reg:SI ...) 0))
[PATCH v1] PR libstdc++/84769 qualify std::get to avoid ADL
PR libstdc++/84769 * include/std/variant (visit<_Visitor, _Variants...>): Qualify call to std::get<_Np, _Types...>. Signed-off-by: Duarte Nunes --- ChangeLog| 6 ++ libstdc++-v3/include/std/variant | 2 +- 2 files changed, 7 insertions(+), 1 deletion(-) diff --git a/ChangeLog b/ChangeLog index ec03a5bcdad..bf2c58aee2b 100644 --- a/ChangeLog +++ b/ChangeLog @@ -1,3 +1,9 @@ +2018-05-03 Duarte Nunes + +PR libstdc++/84769 + * include/std/variant (visit<_Visitor, _Variants...>): + Qualify call to std::get<_Np, _Types...>. + 2018-05-01 Francois H. Theron * configure.ac: Added "nfp" target. diff --git a/libstdc++-v3/include/std/variant b/libstdc++-v3/include/std/variant index f64c037a514..40b3b566938 100644 --- a/libstdc++-v3/include/std/variant +++ b/libstdc++-v3/include/std/variant @@ -1389,7 +1389,7 @@ namespace __variant using _Result_type = decltype(std::forward<_Visitor>(__visitor)( - get<0>(std::forward<_Variants>(__variants))...)); + std::get<0>(std::forward<_Variants>(__variants))...)); constexpr auto& __vtable = __detail::__variant::__gen_vtable< _Result_type, _Visitor&&, _Variants&&...>::_S_vtable; -- 2.17.0
[PATCH] PR libstdc++/85632 fix wraparound in filesystem::space
On 32-bit targets any values over 4GB would wrap and produce the wrong
result.
PR libstdc++/85632 use uintmax_t for arithmetic
* src/filesystem/ops.cc (experimental::filesystem::space): Perform
arithmetic in result type.
* src/filesystem/std-ops.cc (filesystem::space): Likewise.
* testsuite/27_io/filesystem/operations/space.cc: Check total capacity
is greater than free space.
* testsuite/experimental/filesystem/operations/space.cc: New.
Tested x86_64-linux -m32/-m64, committed to trunk. Backports for all
branches to follow.
commit b17dd757565b65580a74d0a81e69ba51473be8f2
Author: Jonathan Wakely
Date: Thu May 3 19:04:05 2018 +0100
PR libstdc++/85632 fix wraparound in filesystem::space
On 32-bit targets any values over 4GB would wrap and produce the wrong
result.
PR libstdc++/85632 use uintmax_t for arithmetic
* src/filesystem/ops.cc (experimental::filesystem::space): Perform
arithmetic in result type.
* src/filesystem/std-ops.cc (filesystem::space): Likewise.
* testsuite/27_io/filesystem/operations/space.cc: Check total
capacity
is greater than free space.
* testsuite/experimental/filesystem/operations/space.cc: New.
diff --git a/libstdc++-v3/src/filesystem/ops.cc
b/libstdc++-v3/src/filesystem/ops.cc
index 328332a8a82..4a9e265d1d6 100644
--- a/libstdc++-v3/src/filesystem/ops.cc
+++ b/libstdc++-v3/src/filesystem/ops.cc
@@ -1132,10 +1132,11 @@ fs::space(const path& p, error_code& ec) noexcept
ec.assign(errno, std::generic_category());
else
{
+ uintmax_t fragment_size = f.f_frsize;
info = space_info{
- f.f_blocks * f.f_frsize,
- f.f_bfree * f.f_frsize,
- f.f_bavail * f.f_frsize
+ f.f_blocks * fragment_size,
+ f.f_bfree * fragment_size,
+ f.f_bavail * fragment_size
};
ec.clear();
}
diff --git a/libstdc++-v3/src/filesystem/std-ops.cc
b/libstdc++-v3/src/filesystem/std-ops.cc
index 930b186e88c..74868cd48e6 100644
--- a/libstdc++-v3/src/filesystem/std-ops.cc
+++ b/libstdc++-v3/src/filesystem/std-ops.cc
@@ -1378,10 +1378,11 @@ fs::space(const path& p, error_code& ec) noexcept
ec.assign(errno, std::generic_category());
else
{
+ uintmax_t fragment_size = f.f_frsize;
info = space_info{
- f.f_blocks * f.f_frsize,
- f.f_bfree * f.f_frsize,
- f.f_bavail * f.f_frsize
+ f.f_blocks * fragment_size,
+ f.f_bfree * fragment_size,
+ f.f_bavail * fragment_size
};
ec.clear();
}
diff --git a/libstdc++-v3/testsuite/27_io/filesystem/operations/space.cc
b/libstdc++-v3/testsuite/27_io/filesystem/operations/space.cc
index bdda24183bc..3d64342fb8f 100644
--- a/libstdc++-v3/testsuite/27_io/filesystem/operations/space.cc
+++ b/libstdc++-v3/testsuite/27_io/filesystem/operations/space.cc
@@ -32,6 +32,7 @@ test01()
std::error_code ec = make_error_code(std::errc::invalid_argument);
s = std::filesystem::space("/", ec);
VERIFY( !ec );
+
s = std::filesystem::space(__gnu_test::nonexistent_path(), ec);
VERIFY( ec );
VERIFY( s.capacity == static_cast(-1) );
@@ -39,8 +40,16 @@ test01()
VERIFY( s.available == static_cast(-1) );
}
+void
+test02()
+{
+ std::filesystem::space_info s = std::filesystem::space(".");
+ VERIFY( s.capacity >= s.free );
+}
+
int
main()
{
test01();
+ test02();
}
diff --git a/libstdc++-v3/testsuite/experimental/filesystem/operations/space.cc
b/libstdc++-v3/testsuite/experimental/filesystem/operations/space.cc
new file mode 100644
index 000..aa6a6aeaa60
--- /dev/null
+++ b/libstdc++-v3/testsuite/experimental/filesystem/operations/space.cc
@@ -0,0 +1,57 @@
+// Copyright (C) 2017-2018 Free Software Foundation, Inc.
+//
+// This file is part of the GNU ISO C++ Library. This library is free
+// software; you can redistribute it and/or modify it under the
+// terms of the GNU General Public License as published by the
+// Free Software Foundation; either version 3, or (at your option)
+// any later version.
+
+// This library is distributed in the hope that it will be useful,
+// but WITHOUT ANY WARRANTY; without even the implied warranty of
+// MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+// GNU General Public License for more details.
+
+// You should have received a copy of the GNU General Public License along
+// with this library; see the file COPYING3. If not see
+//
Re: [PATCH v1] PR libstdc++/84769 qualify std::get to avoid ADL
On 03/05/18 20:55 +0200, Duarte Nunes wrote: PR libstdc++/84769 * include/std/variant (visit<_Visitor, _Variants...>): Qualify call to std::get<_Np, _Types...>. Thanks for the patch, I was already testing the same change and just committed the attached patch to trunk. Backports for other branches to follow shortly. --- ChangeLog| 6 ++ libstdc++-v3/include/std/variant | 2 +- 2 files changed, 7 insertions(+), 1 deletion(-) diff --git a/ChangeLog b/ChangeLog index ec03a5bcdad..bf2c58aee2b 100644 --- a/ChangeLog +++ b/ChangeLog N.B. libstdc++ has its own ChangeLog file, in libstdc++-v3/ChangeLog @@ -1,3 +1,9 @@ +2018-05-03 Duarte Nunes + +PR libstdc++/84769 + * include/std/variant (visit<_Visitor, _Variants...>): + Qualify call to std::get<_Np, _Types...>. + 2018-05-01 Francois H. Theron * configure.ac: Added "nfp" target. diff --git a/libstdc++-v3/include/std/variant b/libstdc++-v3/include/std/variant index f64c037a514..40b3b566938 100644 --- a/libstdc++-v3/include/std/variant +++ b/libstdc++-v3/include/std/variant @@ -1389,7 +1389,7 @@ namespace __variant using _Result_type = decltype(std::forward<_Visitor>(__visitor)( - get<0>(std::forward<_Variants>(__variants))...)); + std::get<0>(std::forward<_Variants>(__variants))...)); constexpr auto& __vtable = __detail::__variant::__gen_vtable< _Result_type, _Visitor&&, _Variants&&...>::_S_vtable; -- 2.17.0 commit e5fb1ad534a0a7323008c65838a6b131cd80e6d4 Author: Jonathan Wakely Date: Thu May 3 19:36:25 2018 +0100 PR libstdc++/84769 qualify call to std::get<0> PR libstdc++/84769 * include/std/variant (visit): Qualify std::get call. diff --git a/libstdc++-v3/include/std/variant b/libstdc++-v3/include/std/variant index f64c037a514..40b3b566938 100644 --- a/libstdc++-v3/include/std/variant +++ b/libstdc++-v3/include/std/variant @@ -1389,7 +1389,7 @@ namespace __variant using _Result_type = decltype(std::forward<_Visitor>(__visitor)( - get<0>(std::forward<_Variants>(__variants))...)); + std::get<0>(std::forward<_Variants>(__variants))...)); constexpr auto& __vtable = __detail::__variant::__gen_vtable< _Result_type, _Visitor&&, _Variants&&...>::_S_vtable;
Re: libgo patch committed: break dependence on unwind-pe.h
Hi Ian, > This patch by Than McIntosh breaks the dependence of go-unwind.c on > unwind-pe.h, by adding the required definitions and code directly to > go-unwind.c. go-unwind.c still depends on the public unwind.h API. > This makes it easier to build libgo separately. Bootstrapped and ran > Go testsuite on x86_64-pc-linux-gnu. Committed to mainline. I strongly suspect that this patch severely broke Go on Solaris/SPARC: between 20180502 (r259840) and 20180503 (r259897) there appeared tons of new execution failures, both 32 and 64-bit: +FAIL: go.go-torture/execute/printnil.go execution, -O0 +FAIL: go.go-torture/execute/printnil.go execution, -O1 +FAIL: go.go-torture/execute/printnil.go execution, -O2 +FAIL: go.go-torture/execute/printnil.go execution, -O2 -fbounds-check +FAIL: go.go-torture/execute/printnil.go execution, -O2 -fomit-frame-pointer -finline-functions +FAIL: go.go-torture/execute/printnil.go execution, -O2 -fomit-frame-pointer -finline-functions -funroll-loops +FAIL: go.go-torture/execute/printnil.go execution, -O3 -g +FAIL: go.go-torture/execute/printnil.go execution, -Os and many more, also in libgo and gotools tests. One example is printnil.x: Thread 9 received signal SIGSEGV, Segmentation fault. [Switching to Thread 4 (LWP 4)] read_encoded_value (val=, p=0xfebcb953 "", encoding=3 '\003', context=0x0) at /vol/gcc/src/hg/trunk/local/libgo/runtime/go-unwind.c:250 250 decoded = (_Unwind_Internal_Ptr)(*(const void *const *)p); (gdb) where #0 read_encoded_value (val=, p=0xfebcb953 "", encoding=3 '\003', context=0x0) at /vol/gcc/src/hg/trunk/local/libgo/runtime/go-unwind.c:250 #1 __gccgo_personality_v0 (version=, actions=1, exception_class=, ue_header=0x1cc44000, context=0x105810ec) at /vol/gcc/src/hg/trunk/local/libgo/runtime/go-unwind.c:472 #2 0xfefbd450 in _Unwind_RaiseException (exc=0x1cc44000) at /builds2/ulhg/workspace/Solaris_Trunk/Userland/full-build/02b-build-sparc/components/gcc7/gcc-7.3.0/libgcc/unwind.inc:113 #3 0xfe59fb00 in runtime.throwException () at /vol/gcc/src/hg/trunk/local/libgo/runtime/go-unwind.c:124 #4 0xfe9e5a90 in runtime.unwindStack () at /vol/gcc/src/hg/trunk/local/libgo/go/runtime/panic.go:336 #5 runtime.gopanic (e=...) at /vol/gcc/src/hg/trunk/local/libgo/go/runtime/panic.go:527 #6 0xfe5a0758 in runtime_panicstring (s=0xfe3e32d8 "nil pointer dereference") at /vol/gcc/src/hg/trunk/local/libgo/runtime/panic.c:38 #7 0xfe59f65c in __go_runtime_error (i=) at /vol/gcc/src/hg/trunk/local/libgo/runtime/go-runtime-error.c:76 #8 0x000120b4 in main.MyType.String () at /vol/gcc/src/hg/trunk/local/gcc/testsuite/go.go-torture/execute/printnil.go:11 #9 0xfe6efa08 in fmt.pp.handleMethods (p=0x10bf4000, verb=115) at /vol/gcc/src/hg/trunk/local/libgo/go/fmt/print.go:603 #10 0xfe6eebdc in fmt.pp.printArg (p=0x10bf4000, arg=..., verb=115) at /vol/gcc/src/hg/trunk/local/libgo/go/fmt/print.go:686 #11 0xfe6f0d84 in fmt.pp.doPrintf (p=0x10bf4000, format=..., a=...) at /vol/gcc/src/hg/trunk/local/libgo/go/fmt/print.go:1003 #12 0xfe6f1460 in fmt.Sprintf (format=..., a=...) at /vol/gcc/src/hg/trunk/local/libgo/go/fmt/print.go:203 #13 0x000121e0 in main.main () at /vol/gcc/src/hg/trunk/local/gcc/testsuite/go.go-torture/execute/printnil.go:16 Seems like the new code doesn't play well on strict-alignment targets. Rainer -- - Rainer Orth, Center for Biotechnology, Bielefeld University
[C++ Patch] Kill -ffriend-injection
As prophesied in GCC 8.1, it's time to kill friend injection.
Committing to trunk.
nathan
--
Nathan Sidwell
2018-05-03 Nathan Sidwell
* doc/extend.texi (Deprecated Features): Remove
-ffriend-injection.
(Backwards Compatibility): Likewise.
* doc/invoke.texi (C++ Language Options): Likewise.
(C++ Dialect Options): Likewise.
c-family/
* c.opt (ffriend-injection): Remove functionality, issue warning.
cp/
* decl.c (cxx_init_decl_processing): Remove flag_friend_injection.
* name-lookup.c (do_pushdecl): Likewise.
testsuite/
Remove -ffriend-injection.
* g++.old-deja/g++.jason/scoping15.C: Delete.
* g++.old-deja/g++.mike/net43.C: Delete.
Index: c-family/c.opt
===
--- c-family/c.opt (revision 259900)
+++ c-family/c.opt (working copy)
@@ -1494,8 +1494,7 @@ C++ ObjC++ Var(flag_new_inheriting_ctors
Implement C++17 inheriting constructor semantics.
ffriend-injection
-C++ ObjC++ Var(flag_friend_injection)
-Inject friend functions into enclosing namespace.
+C++ ObjC++ Ignore Warn(switch %qs is no longer supported)
fkeep-inline-dllexport
C C++ ObjC ObjC++ Var(flag_keep_inline_dllexport) Init(1) Report Condition(TARGET_DLLIMPORT_DECL_ATTRIBUTES)
Index: cp/decl.c
===
--- cp/decl.c (revision 259900)
+++ cp/decl.c (working copy)
@@ -4175,9 +4175,6 @@ cxx_init_decl_processing (void)
if (!flag_new_for_scope)
warning_at (UNKNOWN_LOCATION, OPT_Wdeprecated,
"%<-fno-for-scope%> is deprecated");
- if (flag_friend_injection)
-warning_at (UNKNOWN_LOCATION, OPT_Wdeprecated,
- "%<-ffriend-injection%> is deprecated");
c_common_nodes_and_builtins ();
Index: cp/name-lookup.c
===
--- cp/name-lookup.c (revision 259900)
+++ cp/name-lookup.c (working copy)
@@ -3055,7 +3055,6 @@ do_pushdecl (tree decl, bool is_friend)
old = OVL_CHAIN (old);
check_template_shadow (decl);
- bool visible_injection = false;
if (DECL_DECLARES_FUNCTION_P (decl))
{
@@ -3073,11 +3072,8 @@ do_pushdecl (tree decl, bool is_friend)
/* Don't attempt to push it. */
return error_mark_node;
}
- if (!flag_friend_injection)
- /* Hide it from ordinary lookup. */
- DECL_ANTICIPATED (decl) = DECL_HIDDEN_FRIEND_P (decl) = true;
- else
- visible_injection = true;
+ /* Hide it from ordinary lookup. */
+ DECL_ANTICIPATED (decl) = DECL_HIDDEN_FRIEND_P (decl) = true;
}
}
@@ -3129,9 +3125,6 @@ do_pushdecl (tree decl, bool is_friend)
}
else if (VAR_P (decl))
maybe_register_incomplete_var (decl);
- else if (visible_injection)
- warning (0, "injected friend %qD is visible"
- " due to %<-ffriend-injection%>", decl);
if ((VAR_P (decl) || TREE_CODE (decl) == FUNCTION_DECL)
&& DECL_EXTERN_C_P (decl))
Index: doc/extend.texi
===
--- doc/extend.texi (revision 259900)
+++ doc/extend.texi (working copy)
@@ -23846,8 +23846,7 @@ that are now deprecated or have been rem
@table @code
@item -fno-for-scope
-@itemx -ffriend-injection
-These two options provide compatibility with pre-standard C++.
+This option provides compatibility with pre-standard C++.
@xref{Backwards Compatibility}.
@end table
@@ -23907,11 +23906,6 @@ The behavior is deprecated, only availab
@option{-fpermissive} option to enable it. The behavior will be
removed.
-@item Friend Injection
-The @option{-ffriend-injection} option makes injected friends visible
-to regular name lookup, unlike standard C++. This option is
-deprecated and will be removed.
-
@item Implicit C language
Old C system header files did not contain an @code{extern "C" @{@dots{}@}}
scope to set the language. On such systems, all header files are
Index: doc/invoke.texi
===
--- doc/invoke.texi (revision 259900)
+++ doc/invoke.texi (working copy)
@@ -193,7 +193,6 @@ in the following sections.
@gccoptlist{-fabi-version=@var{n} -fno-access-control @gol
-faligned-new=@var{n} -fargs-in-order=@var{n} -fcheck-new @gol
-fconstexpr-depth=@var{n} -fconstexpr-loop-limit=@var{n} @gol
--ffriend-injection @gol
-fno-elide-constructors @gol
-fno-enforce-eh-specs @gol
-ffor-scope -fno-for-scope -fno-gnu-keywords @gol
@@ -2448,18 +2447,6 @@ originally proposed semantics for the C+
of the final standard, so it is disabled by default. This option is
deprecated, and may be removed in a future version of G++.
-@item -ffriend-injection
-@opindex ffriend-injection
-Inject friend functions into the enclosing namespace, so that they are
-visible outside the scope of the class in which they are declared.
-Friend functions were documented to work this way in the old Annotated
-C++ Reference Manual.
-However, in ISO C++ a friend function that is not declared
-in an enclosing scope can on
Re: libgo patch committed: break dependence on unwind-pe.h
Thanks for catching that. I don't have access to test machines, but could you possibly try the attached patch? Thanks, Than On Thu, May 3, 2018 at 3:03 PM Rainer Orth wrote: > Hi Ian, > > This patch by Than McIntosh breaks the dependence of go-unwind.c on > > unwind-pe.h, by adding the required definitions and code directly to > > go-unwind.c. go-unwind.c still depends on the public unwind.h API. > > This makes it easier to build libgo separately. Bootstrapped and ran > > Go testsuite on x86_64-pc-linux-gnu. Committed to mainline. > I strongly suspect that this patch severely broke Go on Solaris/SPARC: > between 20180502 (r259840) and 20180503 (r259897) there appeared tons of > new execution failures, both 32 and 64-bit: > +FAIL: go.go-torture/execute/printnil.go execution, -O0 > +FAIL: go.go-torture/execute/printnil.go execution, -O1 > +FAIL: go.go-torture/execute/printnil.go execution, -O2 > +FAIL: go.go-torture/execute/printnil.go execution, -O2 -fbounds-check > +FAIL: go.go-torture/execute/printnil.go execution, -O2 -fomit-frame-pointer -finline-functions > +FAIL: go.go-torture/execute/printnil.go execution, -O2 -fomit-frame-pointer -finline-functions -funroll-loops > +FAIL: go.go-torture/execute/printnil.go execution, -O3 -g > +FAIL: go.go-torture/execute/printnil.go execution, -Os > and many more, also in libgo and gotools tests. > One example is printnil.x: > Thread 9 received signal SIGSEGV, Segmentation fault. > [Switching to Thread 4 (LWP 4)] > read_encoded_value (val=, p=0xfebcb953 "", > encoding=3 '\003', context=0x0) > at /vol/gcc/src/hg/trunk/local/libgo/runtime/go-unwind.c:250 > 250 decoded = (_Unwind_Internal_Ptr)(*(const void *const *)p); > (gdb) where > #0 read_encoded_value (val=, p=0xfebcb953 "", > encoding=3 '\003', context=0x0) > at /vol/gcc/src/hg/trunk/local/libgo/runtime/go-unwind.c:250 > #1 __gccgo_personality_v0 (version=, actions=1, > exception_class=, ue_header=0x1cc44000, context=0x105810ec) > at /vol/gcc/src/hg/trunk/local/libgo/runtime/go-unwind.c:472 > #2 0xfefbd450 in _Unwind_RaiseException (exc=0x1cc44000) > at /builds2/ulhg/workspace/Solaris_Trunk/Userland/full-build/02b-build-sparc/components/gcc7/gcc-7.3.0/libgcc/unwind.inc:113 > #3 0xfe59fb00 in runtime.throwException () > at /vol/gcc/src/hg/trunk/local/libgo/runtime/go-unwind.c:124 > #4 0xfe9e5a90 in runtime.unwindStack () > at /vol/gcc/src/hg/trunk/local/libgo/go/runtime/panic.go:336 > #5 runtime.gopanic (e=...) > at /vol/gcc/src/hg/trunk/local/libgo/go/runtime/panic.go:527 > #6 0xfe5a0758 in runtime_panicstring (s=0xfe3e32d8 "nil pointer dereference") > at /vol/gcc/src/hg/trunk/local/libgo/runtime/panic.c:38 > #7 0xfe59f65c in __go_runtime_error (i=) > at /vol/gcc/src/hg/trunk/local/libgo/runtime/go-runtime-error.c:76 > #8 0x000120b4 in main.MyType.String () > at /vol/gcc/src/hg/trunk/local/gcc/testsuite/go.go-torture/execute/printnil.go:11 > #9 0xfe6efa08 in fmt.pp.handleMethods (p=0x10bf4000, verb=115) > at /vol/gcc/src/hg/trunk/local/libgo/go/fmt/print.go:603 > #10 0xfe6eebdc in fmt.pp.printArg (p=0x10bf4000, arg=..., verb=115) > at /vol/gcc/src/hg/trunk/local/libgo/go/fmt/print.go:686 > #11 0xfe6f0d84 in fmt.pp.doPrintf (p=0x10bf4000, format=..., a=...) > at /vol/gcc/src/hg/trunk/local/libgo/go/fmt/print.go:1003 > #12 0xfe6f1460 in fmt.Sprintf (format=..., a=...) > at /vol/gcc/src/hg/trunk/local/libgo/go/fmt/print.go:203 > #13 0x000121e0 in main.main () > at /vol/gcc/src/hg/trunk/local/gcc/testsuite/go.go-torture/execute/printnil.go:16 > Seems like the new code doesn't play well on strict-alignment targets. > Rainer > -- - > Rainer Orth, Center for Biotechnology, Bielefeld University diff --git a/libgo/runtime/go-unwind.c b/libgo/runtime/go-unwind.c index 536a619d..6464bec7 100644 --- a/libgo/runtime/go-unwind.c +++ b/libgo/runtime/go-unwind.c @@ -247,7 +247,7 @@ read_encoded_value (struct _Unwind_Context *context, uint8_t encoding, break; } case DW_EH_PE_absptr: -decoded = (_Unwind_Internal_Ptr)(*(const void *const *)p); +__builtin_memcpy (&decoded, (const void *)p, sizeof(const void*)); p += sizeof(void *); break; default:
Re: Rb_tree constructor optimization
On 02/05/2018 13:49, Jonathan Wakely wrote:
On 01/05/18 21:56 +0200, François Dumont wrote:
Hi
If not told otherwise I'll commit attached patch tomorrow.
Please do not commit it, see below.
Already discussed here:
https://gcc.gnu.org/ml/libstdc++/2017-10/msg00053.html
There's no changelog entry with the patch, so to recap, the changes
are:
- noexcept specifications are automatically deduced instead of being
stated explicitly.
Yes, it helps to make sure rb tree code is correct and it avoids usage
of non-standard _S_always_equal. We could even use std::allocator_traits
in C++11.
- The allocator-extended move constructors get correct exception
specifications in Debug Mode (consistent with normal mode). This
should be done anyway, independent of any other changes.
Yes, I realized it after I wrote the tests to validate the noexcept
qualification.
- We avoid a `if (__x._M_root() != nullptr)` branch in the case where
the allocator-extended move constructor is used with an always-equal
allocator, right?
Yes, this is consistent with most of the other containers doing the same.
Deducing the noexcept specifications probably has a (small?) impact on
compilation speed, as currently the allocator-extended move
constructors have:
- noexcept(is_nothrow_copy_constructible<_Compare>::value
- && _Alloc_traits::_S_always_equal())
After the patch they have to determine the noexcept-ness of the
_Rep_type constructor taking allocator_type, which has to determine
the noexcept-ness of the _Rep_type constructor taking a
_Node_allocator, which has to determine the noexcept-ness of the
constructor it dispatches to depending on _S_always_equal(), which is
simply:
+ noexcept(is_nothrow_move_constructible<_Rb_tree_impl<_Compare>>::value)
So instead of just using that value in the first place we have to
perform three rounds of overload resolution to find the right
constructor and then check its exception specification. And then we
get the wrong answer (see below).
Compilation time for containers is already **much** slower since the
allocator-extended constructors were added for GCC 5.x, despite very
few people ever using those constructors. This patch seems to require
even more work from the compiler to parse constructors nobody uses.
I must confess that I didn't consider this aspect of the patch. I just
wanted the code to be more logical. I even wonder why it wasn't done
this way, now I know. Could this compilation cost be testable ? Isn't
the compiler doing this work only if the constructor is being used ? Or
even just only if it needs to know about the noexcept qualification ?
François
diff --git a/libstdc++-v3/include/bits/stl_map.h
b/libstdc++-v3/include/bits/stl_map.h
index a4a026e..2b8fd27 100644
--- a/libstdc++-v3/include/bits/stl_map.h
+++ b/libstdc++-v3/include/bits/stl_map.h
@@ -240,8 +240,8 @@ _GLIBCXX_BEGIN_NAMESPACE_CONTAINER
/// Allocator-extended move constructor.
map(map&& __m, const allocator_type& __a)
- noexcept(is_nothrow_copy_constructible<_Compare>::value
- && _Alloc_traits::_S_always_equal())
+ noexcept( noexcept(
+ _Rep_type(std::move(__m._M_t), declval<_Pair_alloc_type>())) )
All these calls to declval need to be qualified to avoid ADL.
It seems strange to have a mix of real values and declval expressions,
rather than:
_Rep_type(std::declval<_Rep_type>(),
std::declval<_Pair_alloc_type>())) )
Has std::declval<>() been modified recently ? I think I tried that
and it was working but after a while it started to fail so I had to
replace with the other expression. I'll try it again if I eventually
commit this.
: _M_t(std::move(__m._M_t), _Pair_alloc_type(__a)) { }
/// Allocator-extended initialier-list constructor.
diff --git a/libstdc++-v3/include/bits/stl_multimap.h
b/libstdc++-v3/include/bits/stl_multimap.h
index fc8f454..b9289ab 100644
--- a/libstdc++-v3/include/bits/stl_multimap.h
+++ b/libstdc++-v3/include/bits/stl_multimap.h
@@ -237,8 +237,8 @@ _GLIBCXX_BEGIN_NAMESPACE_CONTAINER
/// Allocator-extended move constructor.
multimap(multimap&& __m, const allocator_type& __a)
- noexcept(is_nothrow_copy_constructible<_Compare>::value
- && _Alloc_traits::_S_always_equal())
+ noexcept( noexcept(
+ _Rep_type(std::move(__m._M_t), declval<_Pair_alloc_type>())) )
: _M_t(std::move(__m._M_t), _Pair_alloc_type(__a)) { }
/// Allocator-extended initialier-list constructor.
diff --git a/libstdc++-v3/include/bits/stl_multiset.h
b/libstdc++-v3/include/bits/stl_multiset.h
index f41f56c..afaf3b6 100644
--- a/libstdc++-v3/include/bits/stl_multiset.h
+++ b/libstdc++-v3/include/bits/stl_multiset.h
@@ -253,8 +253,8 @@ _GLIBCXX_BEGIN_NAMESPACE_CONTAINER
/// Allocator-extended move constructor.
multiset(multiset&& __m, const allocator_type& __a)
- noexcept(is_nothrow_copy_constructible<_Compare>::value
- && _Alloc_traits::_S_always_equal())
+
[REPOST] [PATCH] Avoid excessive function type casts with splay-trees
Hi,
this is basically the same patch I posted a few months ago,
with a few formatting nits by Jakub fixed.
Bootstrapped and reg-tested again with current trunk.
Is it OK for trunk?
Bernd.
On 12/15/17 11:44, Bernd Edlinger wrote:
> Hi,
>
> when working on the -Wcast-function-type patch I noticed some rather
> ugly and non-portable function type casts that are necessary to accomplish
> some actually very simple tasks.
>
> Often functions taking pointer arguments are called with a different signature
> taking uintptr_t arguments, which is IMHO not really safe to do...
>
> The attached patch adds a context argument to the callback functions but
> keeps the existing interface as far as possible.
>
>
> Bootstrapped and reg-tested on x86_64-pc-linux-gnu.
> Is it OK for trunk?
>
>
> Thanks
> Bernd.
>
include:
2017-12-15 Bernd Edlinger
* splay-tree.h (splay_tree_compare_ex_fn, splay_tree_delete_key_ex_fn,
splay_tree_delete_value_ex_fn): New function types.
(splay_tree_s): Update to use new function types.
(splay_tree_ex_new): Declare new constructor.
(splay_tree_compare_strings, splay_tree_delete_pointers,
splay_tree_compare_wrapper, splay_tree_delete_key_wrapper,
splay_tree_delete_value_wrapper, splay_tree_xmalloc_allocate,
splay_tree_xmalloc_deallocate): Declare new utility functions.
libiberty:
2017-12-15 Bernd Edlinger
* splay-tree.c (splay_tree_delete_helper, splay_tree_splay,
splay_tree_insert, splay_tree_remove, splay_tree_lookup,
splay_tree_predecessor, splay_tree_successor): Adjust.
(splay_tree_new_typed_alloc): Call splay_tree_ex_new.
(splay_tree_ex_new): New constructor.
(splay_tree_compare_strings, splay_tree_delete_pointers,
splay_tree_compare_wrapper, splay_tree_delete_key_wrapper,
splay_tree_delete_value_wrapper): New utility functions.
(splay_tree_xmalloc_allocate, splay_tree_xmalloc_deallocate): Export.
gcc:
2017-12-15 Bernd Edlinger
* typed-splay-tree.h (typed_splay_tree::m_compare_outer_fn,
typed_splay_tree::m_delete_key_outer_fn,
typed_splay_tree::m_delete_value_outer_fn): New data members.
(typed_splay_tree::compare_inner_fn,
typed_splay_tree::delete_key_inner_fn,
typed_splay_tree::delete_value_inner_fn): New helper functions.
(typed_splay_tree::typed_splay_tree): Use splay_tree_ex_new.
* tree-dump.c (dump_node): Use splay_tree_delete_pointers.
c-family:
2017-12-15 Bernd Edlinger
* c-lex.c (get_fileinfo): Use splay_tree_compare_strings and
splay_tree_delete_pointers.
cp:
2017-12-15 Bernd Edlinger
* decl2.c (start_static_storage_duration_function): Use
splay_tree_delete_pointers.
Index: gcc/c-family/c-lex.c
===
--- gcc/c-family/c-lex.c (revision 255661)
+++ gcc/c-family/c-lex.c (working copy)
@@ -101,11 +101,9 @@ get_fileinfo (const char *name)
struct c_fileinfo *fi;
if (!file_info_tree)
-file_info_tree = splay_tree_new ((splay_tree_compare_fn)
- (void (*) (void)) strcmp,
+file_info_tree = splay_tree_new (splay_tree_compare_strings,
0,
- (splay_tree_delete_value_fn)
- (void (*) (void)) free);
+ splay_tree_delete_pointers);
n = splay_tree_lookup (file_info_tree, (splay_tree_key) name);
if (n)
Index: gcc/cp/decl2.c
===
--- gcc/cp/decl2.c (revision 255661)
+++ gcc/cp/decl2.c (working copy)
@@ -3558,8 +3558,7 @@ start_static_storage_duration_function (unsigned c
priority_info_map = splay_tree_new (splay_tree_compare_ints,
/*delete_key_fn=*/0,
/*delete_value_fn=*/
- (splay_tree_delete_value_fn)
- (void (*) (void)) free);
+ splay_tree_delete_pointers);
/* We always need to generate functions for the
DEFAULT_INIT_PRIORITY so enter it now. That way when we walk
Index: gcc/tree-dump.c
===
--- gcc/tree-dump.c (revision 255661)
+++ gcc/tree-dump.c (working copy)
@@ -736,8 +736,7 @@ dump_node (const_tree t, dump_flags_t flags, FILE
di.flags = flags;
di.node = t;
di.nodes = splay_tree_new (splay_tree_compare_pointers, 0,
- (splay_tree_delete_value_fn)
- (void (*) (void)) free);
+ splay_tree_delete_pointers);
/* Queue up the first node. */
queue (&di, t, DUMP_NONE);
Index: gcc/typed-splay-tree.h
===
--- gcc/typed-splay-tree.h (revision 255661)
+++ gcc/typed-splay-tree.h (working copy)
@@ -63,7 +63,30 @@ class typed_splay_tree
static value_type node_to_value (splay_tree_node node);
- private:
+ compare_fn m_compare_outer_fn;
+ static int compare_inner_fn (splay_tree_key k1, splay_tree_key k2,
+ void *user_data)
+ {
+
Re: [PATCH 1/2, expr.c] Optimize switch with sign-extended index.
On Thu, May 3, 2018 at 12:29 AM, Richard Biener wrote: > Just as a note, IIRC all the SUBREG_PROMOTED_* stuff is quite fragile > - I remember > Eric fixing things up a bit but some verification would be nice to > have (instrumentation > at RTL level that for SUBREG_PROMOTED_* the bits are as expected). If you are using SUBREG_PROMOTED_* in a late optimization pass like combine, then this requires that all earlier optimization passes propagate the info correctly. I suppose there could be issues there. But that isn't what this patch is doing. This is code called during initial RTL generation. The SUBREG_PROMOTED_* bits are set during this process because we know that arguments are passed sign-extended to full register size. We are then consuming the info while still in the RTL generation phase. I think that there is little that can go wrong here. Verifying this info in RTL generation would effectively be verifying that the argument passing conventions are implemented correctly, and we already have other ways to do that. It might be useful to try to verify this info before combine where it is more likely to be wrong. I don't think there is any easy way to verify this at compile time. This would probably require emitting code to check at application run-time that a promoted subreg actually has a properly promoted value, and call abort if it doesn't. This would likely be an expensive check that we don't want enabled by default, but might be useful for debugging purposes. I don't think we have any --enable-checking code like this at present. We have compiler compile-time checking and compiler run-time checking, but I don't think that we have application run-time checking. This would be more like a sanitizer option, except to validate info in the RTL. Is this what you are asking for? Jim
Re: libgo patch committed: break dependence on unwind-pe.h
Hi Than, > Thanks for catching that. > > I don't have access to test machines, but could you possibly try the > attached patch? I just did. However, it made no difference, while a full reversal of the patch fixed all new go and libgo failures on sparc-sun-solaris2.11. Rainer -- - Rainer Orth, Center for Biotechnology, Bielefeld University
[PATCH] PR libstdc++/82644 define TR1 hypergeometric functions in strict modes
Following a recent change for PR 82644 the non-standard hypergeomtric
functions are not defined by when __STRICT_ANSI__ is defined
(e.g. for -std=c++17, or -std=c++14 -D__STDCPP_WANT_MATH_SPEC_FUNCS__).
That caused errors in because the using-declarations for
tr1::hyperg et al are invalid in strict modes.
The solution is to define the TR1 hypergeometric functions inline in
if __STRICT_ANSI__ is defined.
PR libstdc++/82644
* include/tr1/cmath [__STRICT_ANSI__] (hypergf, hypergl, hyperg): Use
inline definitions instead of using-declarations.
[__STRICT_ANSI__] (conf_hypergf, conf_hypergl, conf_hyperg): Likewise.
* testsuite/tr1/5_numerical_facilities/special_functions/
07_conf_hyperg/compile_cxx17.cc: New.
* testsuite/tr1/5_numerical_facilities/special_functions/
17_hyperg/compile_cxx17.cc: New.
Tested powerpc64le-linux, committed to trunk.
commit 515ef39dc5027de6b87daa5c063f05f2c9202c32
Author: Jonathan Wakely
Date: Thu May 3 20:27:08 2018 +0100
PR libstdc++/82644 define TR1 hypergeometric functions in strict modes
Following a recent change for PR 82644 the non-standard hypergeomtric
functions are not defined by when __STRICT_ANSI__ is defined
(e.g. for -std=c++17, or -std=c++14 -D__STDCPP_WANT_MATH_SPEC_FUNCS__).
That caused errors in because the using-declarations for
tr1::hyperg et al are invalid in strict modes.
The solution is to define the TR1 hypergeometric functions inline in
if __STRICT_ANSI__ is defined.
PR libstdc++/82644
* include/tr1/cmath [__STRICT_ANSI__] (hypergf, hypergl, hyperg):
Use
inline definitions instead of using-declarations.
[__STRICT_ANSI__] (conf_hypergf, conf_hypergl, conf_hyperg):
Likewise.
* testsuite/tr1/5_numerical_facilities/special_functions/
07_conf_hyperg/compile_cxx17.cc: New.
* testsuite/tr1/5_numerical_facilities/special_functions/
17_hyperg/compile_cxx17.cc: New.
diff --git a/libstdc++-v3/include/tr1/cmath b/libstdc++-v3/include/tr1/cmath
index d1df3804120..c07dd5c73a5 100644
--- a/libstdc++-v3/include/tr1/cmath
+++ b/libstdc++-v3/include/tr1/cmath
@@ -1160,10 +1160,6 @@ namespace tr1
using std::comp_ellint_3l;
using std::comp_ellint_3;
- using __gnu_cxx::conf_hypergf;
- using __gnu_cxx::conf_hypergl;
- using __gnu_cxx::conf_hyperg;
-
using std::cyl_bessel_if;
using std::cyl_bessel_il;
using std::cyl_bessel_i;
@@ -1200,10 +1196,6 @@ namespace tr1
using std::hermitel;
using std::hermite;
- using __gnu_cxx::hypergf;
- using __gnu_cxx::hypergl;
- using __gnu_cxx::hyperg;
-
using std::laguerref;
using std::laguerrel;
using std::laguerre;
@@ -1246,7 +1238,6 @@ _GLIBCXX_END_NAMESPACE_VERSION
#include
#include
#include
-#include
#include
#include
#include
@@ -1372,23 +1363,6 @@ namespace tr1
}
inline float
- conf_hypergf(float __a, float __c, float __x)
- { return __detail::__conf_hyperg(__a, __c, __x); }
-
- inline long double
- conf_hypergl(long double __a, long double __c, long double __x)
- { return __detail::__conf_hyperg(__a, __c, __x); }
-
- /// 5.2.1.7 Confluent hypergeometric functions.
- template
-inline typename __gnu_cxx::__promote_3<_Tpa, _Tpc, _Tp>::__type
-conf_hyperg(_Tpa __a, _Tpc __c, _Tp __x)
-{
- typedef typename __gnu_cxx::__promote_3<_Tpa, _Tpc, _Tp>::__type __type;
- return __detail::__conf_hyperg<__type>(__a, __c, __x);
-}
-
- inline float
cyl_bessel_if(float __nu, float __x)
{ return __detail::__cyl_bessel_i(__nu, __x); }
@@ -1542,23 +1516,6 @@ namespace tr1
}
inline float
- hypergf(float __a, float __b, float __c, float __x)
- { return __detail::__hyperg(__a, __b, __c, __x); }
-
- inline long double
- hypergl(long double __a, long double __b, long double __c, long double __x)
- { return __detail::__hyperg(__a, __b, __c, __x); }
-
- /// 5.2.1.17 Hypergeometric functions.
- template
-inline typename __gnu_cxx::__promote_4<_Tpa, _Tpb, _Tpc, _Tp>::__type
-hyperg(_Tpa __a, _Tpb __b, _Tpc __c, _Tp __x)
-{
- typedef typename __gnu_cxx::__promote_4<_Tpa, _Tpb, _Tpc, _Tp>::__type
__type;
- return __detail::__hyperg<__type>(__a, __b, __c, __x);
-}
-
- inline float
laguerref(unsigned int __n, float __x)
{ return __detail::__laguerre(__n, __x); }
@@ -1668,4 +1625,77 @@ namespace tr1
_GLIBCXX_END_NAMESPACE_VERSION
} // namespace std
+#if _GLIBCXX_USE_STD_SPEC_FUNCS && !defined(__STRICT_ANSI__)
+namespace std _GLIBCXX_VISIBILITY(default)
+{
+_GLIBCXX_BEGIN_NAMESPACE_VERSION
+
+namespace tr1
+{
+ using __gnu_cxx::conf_hypergf;
+ using __gnu_cxx::conf_hypergl;
+ using __gnu_cxx::conf_hyperg;
+
+ using __gnu_cxx::hypergf;
+ using __gnu_cxx::hypergl;
+ using __gnu_cxx::hyperg;
+} // namespace tr1
+
+_GLIBCXX_END_NAMESPACE_VERSION
+} // namespace std
+
+#else // ! (_GLIBCXX_USE
C++ PATCH for c++/85600, virtual delete failure
When I removed some of the save_exprs, I was missing that we don't
save_expr on the virtual delete path, but then we use addr again to
check that it's non-null.
This patch simplifies the logic a bit so that we always save_expr when
we're deleting; if we're just calling the destructor we don't need to.
I also noticed that we were testing which of those we were doing in
two different ways; this introduces a local variable and makes sure
that the two ways agree.
Tested x86_64-pc-linux-gnu, applying to trunk.
commit 2296f3be0c8171b062fbf2daa1be6bb3820cb21e
Author: Jason Merrill
Date: Thu May 3 16:49:19 2018 -0400
PR c++/85600 - spec omnetpp failure.
* init.c (build_delete): Always save_expr when deleting.
diff --git a/gcc/cp/init.c b/gcc/cp/init.c
index 221a831b7b8..b934a0039ec 100644
--- a/gcc/cp/init.c
+++ b/gcc/cp/init.c
@@ -4601,6 +4601,9 @@ build_delete (tree otype, tree addr, special_function_kind auto_delete,
auto_delete, use_global_delete, complain);
}
+ bool deleting = (auto_delete == sfk_deleting_destructor);
+ gcc_assert (deleting == !(flags & LOOKUP_DESTRUCTOR));
+
if (TYPE_PTR_P (otype))
{
addr = mark_rvalue_use (addr);
@@ -4628,7 +4631,7 @@ build_delete (tree otype, tree addr, special_function_kind auto_delete,
"declared when the class is defined");
}
}
- else if (auto_delete == sfk_deleting_destructor && warn_delnonvdtor
+ else if (deleting && warn_delnonvdtor
&& MAYBE_CLASS_TYPE_P (type) && !CLASSTYPE_FINAL (type)
&& TYPE_POLYMORPHIC_P (type))
{
@@ -4664,9 +4667,9 @@ build_delete (tree otype, tree addr, special_function_kind auto_delete,
addr = convert_force (build_pointer_type (type), addr, 0, complain);
}
- tree head = NULL_TREE;
- tree do_delete = NULL_TREE;
- tree ifexp;
+ if (deleting)
+/* We will use ADDR multiple times so we must save it. */
+addr = save_expr (addr);
bool virtual_p = false;
if (type_build_dtor_call (type))
@@ -4676,13 +4679,18 @@ build_delete (tree otype, tree addr, special_function_kind auto_delete,
virtual_p = DECL_VIRTUAL_P (CLASSTYPE_DESTRUCTOR (type));
}
+ tree head = NULL_TREE;
+ tree do_delete = NULL_TREE;
+
+ if (!deleting)
+{
+ /* Leave do_delete null. */
+}
/* For `::delete x', we must not use the deleting destructor
since then we would not be sure to get the global `operator
delete'. */
- if (use_global_delete && auto_delete == sfk_deleting_destructor)
+ else if (use_global_delete)
{
- /* We will use ADDR multiple times so we must save it. */
- addr = save_expr (addr);
head = get_target_expr (build_headof (addr));
/* Delete the object. */
do_delete = build_op_delete_call (DELETE_EXPR,
@@ -4699,11 +4707,8 @@ build_delete (tree otype, tree addr, special_function_kind auto_delete,
/* If the destructor is non-virtual, there is no deleting
variant. Instead, we must explicitly call the appropriate
`operator delete' here. */
- else if (!virtual_p
- && auto_delete == sfk_deleting_destructor)
+ else if (!virtual_p)
{
- /* We will use ADDR multiple times so we must save it. */
- addr = save_expr (addr);
/* Build the call. */
do_delete = build_op_delete_call (DELETE_EXPR,
addr,
@@ -4715,8 +4720,7 @@ build_delete (tree otype, tree addr, special_function_kind auto_delete,
/* Call the complete object destructor. */
auto_delete = sfk_complete_destructor;
}
- else if (auto_delete == sfk_deleting_destructor
- && TYPE_GETS_REG_DELETE (type))
+ else if (TYPE_GETS_REG_DELETE (type))
{
/* Make sure we have access to the member op delete, even though
we'll actually be calling it from the destructor. */
@@ -4735,6 +4739,9 @@ build_delete (tree otype, tree addr, special_function_kind auto_delete,
if (expr == error_mark_node)
return error_mark_node;
+ if (!deleting)
+return expr;
+
if (do_delete && !TREE_SIDE_EFFECTS (expr))
expr = do_delete;
else if (do_delete)
@@ -4750,24 +4757,20 @@ build_delete (tree otype, tree addr, special_function_kind auto_delete,
if (head)
expr = build2 (COMPOUND_EXPR, void_type_node, head, expr);
- if (flags & LOOKUP_DESTRUCTOR)
-/* Explicit destructor call; don't check for null pointer. */
-ifexp = integer_one_node;
- else
-{
- /* Handle deleting a null pointer. */
- warning_sentinel s (warn_address);
- ifexp = cp_build_binary_op (input_location, NE_EXPR, addr,
- nullptr_node, complain);
- if (ifexp == error_mark_node)
- return error_mark_node;
- /* This is a compiler generated comparison, don't emit
- e.g. -Wnonnull-compare warning for it. */
- else if (TREE_CODE (ifexp) == NE_EXPR)
- TREE_NO_WARNING (ifexp) = 1;
-}
+ /* Handle deleting a null pointer. */
+ warning_sentinel s (warn_address);
+ tree ifexp = cp_build_binary_op (inp
libgo patch committed: Update go tool to match recent upstream changes
In https://golang.org/cl/111097 the gc version of cmd/go, which is
part of libgo, was updated to include some gccgo-specific changes. The
libgo code already has different versions of those changes; this patch
makes the libgo match the upstream code. 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 259900)
+++ gcc/go/gofrontend/MERGE (working copy)
@@ -1,4 +1,4 @@
-85ca682349af2cb1aa6b1eecac794aeb73d24f15
+bf6f714559bd7b27b7686811aaf0f6e8e7f1c0d5
The first line of this file holds the git revision number of the last
merge done from the gofrontend repository.
Index: libgo/go/cmd/go/alldocs.go
===
--- libgo/go/cmd/go/alldocs.go (revision 259805)
+++ libgo/go/cmd/go/alldocs.go (working copy)
@@ -1266,6 +1266,9 @@
//
// Special-purpose environment variables:
//
+// GCCGOTOOLDIR
+// If set, where to find gccgo tools, such as cgo.
+// The default is based on how gccgo was configured.
// GOROOT_FINAL
// The root of the installed Go tree, when it is
// installed in a location other than where it is built.
@@ -1279,9 +1282,6 @@
// Defined by Git. A colon-separated list of schemes that are
allowed to be used
// with git fetch/clone. If set, any scheme not explicitly
mentioned will be
// considered insecure by 'go get'.
-// GCCGOTOOLDIR
-// If set, where to find gccgo tools, such as cgo.
-// The default is based on how gccgo was configured.
//
//
// Import path syntax
Index: libgo/go/cmd/go/internal/cfg/cfg.go
===
--- libgo/go/cmd/go/internal/cfg/cfg.go (revision 259805)
+++ libgo/go/cmd/go/internal/cfg/cfg.go (working copy)
@@ -92,11 +92,12 @@ var (
// Update build context to use our computed GOROOT.
func init() {
BuildContext.GOROOT = GOROOT
- // Note that we must use runtime.GOOS and runtime.GOARCH here,
- // as the tool directory does not move based on environment variables.
- // This matches the initialization of ToolDir in go/build,
- // except for using GOROOT rather than runtime.GOROOT().
if runtime.Compiler != "gccgo" {
+ // Note that we must use runtime.GOOS and runtime.GOARCH here,
+ // as the tool directory does not move based on environment
+ // variables. This matches the initialization of ToolDir in
+ // go/build, except for using GOROOT rather than
+ // runtime.GOROOT.
build.ToolDir = filepath.Join(GOROOT,
"pkg/tool/"+runtime.GOOS+"_"+runtime.GOARCH)
}
}
@@ -107,6 +108,8 @@ func findGOROOT() string {
}
def := filepath.Clean(runtime.GOROOT())
if runtime.Compiler == "gccgo" {
+ // gccgo has no real GOROOT, and it certainly doesn't
+ // depend on the executable's location.
return def
}
exe, err := os.Executable()
Index: libgo/go/cmd/go/internal/help/helpdoc.go
===
--- libgo/go/cmd/go/internal/help/helpdoc.go(revision 259805)
+++ libgo/go/cmd/go/internal/help/helpdoc.go(working copy)
@@ -526,6 +526,9 @@ Architecture-specific environment variab
Special-purpose environment variables:
+ GCCGOTOOLDIR
+ If set, where to find gccgo tools, such as cgo.
+ The default is based on how gccgo was configured.
GOROOT_FINAL
The root of the installed Go tree, when it is
installed in a location other than where it is built.
@@ -539,9 +542,6 @@ Special-purpose environment variables:
Defined by Git. A colon-separated list of schemes that are
allowed to be used
with git fetch/clone. If set, any scheme not explicitly
mentioned will be
considered insecure by 'go get'.
- GCCGOTOOLDIR
- If set, where to find gccgo tools, such as cgo.
- The default is based on how gccgo was configured.
`,
}
Index: libgo/go/cmd/go/internal/load/pkg.go
===
--- libgo/go/cmd/go/internal/load/pkg.go(revision 259805)
+++ libgo/go/cmd/go/internal/load/pkg.go(working copy)
@@ -13,7 +13,6 @@ import (
"os"
pathpkg "path"
"path/filepath"
- "runtime"
"sort"
"strings"
"unicode"
@@ -976,7 +975,7 @@ func (p *Package) load(stk *ImportStack,
// This is for 'go tool'.
// Override all the usual logic and force it into the
tool directory.
if cfg.BuildToolchainNam
libgo patch committed: enable tests of go tool invoking vet
Since libgo does have the vet tool now, enable the tests in which the
go tool invokes it. 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 259918)
+++ gcc/go/gofrontend/MERGE (working copy)
@@ -1,4 +1,4 @@
-bf6f714559bd7b27b7686811aaf0f6e8e7f1c0d5
+12325f36d965e2ac3a4cbf787472ce24923327da
The first line of this file holds the git revision number of the last
merge done from the gofrontend repository.
Index: libgo/go/cmd/go/go_test.go
===
--- libgo/go/cmd/go/go_test.go (revision 259875)
+++ libgo/go/cmd/go/go_test.go (working copy)
@@ -3221,7 +3221,6 @@ func TestGoGetInternalWildcard(t *testin
}
func TestGoVetWithExternalTests(t *testing.T) {
- skipIfGccgo(t, "gccgo does not have vet")
tg := testgo(t)
defer tg.cleanup()
tg.makeTempdir()
@@ -3231,7 +3230,6 @@ func TestGoVetWithExternalTests(t *testi
}
func TestGoVetWithTags(t *testing.T) {
- skipIfGccgo(t, "gccgo does not have vet")
tg := testgo(t)
defer tg.cleanup()
tg.makeTempdir()
@@ -3241,7 +3239,6 @@ func TestGoVetWithTags(t *testing.T) {
}
func TestGoVetWithFlagsOn(t *testing.T) {
- skipIfGccgo(t, "gccgo does not have vet")
tg := testgo(t)
defer tg.cleanup()
tg.makeTempdir()
@@ -3251,7 +3248,6 @@ func TestGoVetWithFlagsOn(t *testing.T)
}
func TestGoVetWithFlagsOff(t *testing.T) {
- skipIfGccgo(t, "gccgo does not have vet")
tg := testgo(t)
defer tg.cleanup()
tg.makeTempdir()
libgo patch committed: update mkalldocs.sh
Update mkalldocs.sh from the current master sources, replacing the old mkdoc.sh. I think this got left out of the merges. 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 259919) +++ gcc/go/gofrontend/MERGE (working copy) @@ -1,4 +1,4 @@ -12325f36d965e2ac3a4cbf787472ce24923327da +30e2033a91fc08be9351d26737599a1fa6486017 The first line of this file holds the git revision number of the last merge done from the gofrontend repository. Index: libgo/go/cmd/go/mkalldocs.sh === --- libgo/go/cmd/go/mkalldocs.sh(nonexistent) +++ libgo/go/cmd/go/mkalldocs.sh(working copy) @@ -0,0 +1,11 @@ +#!/bin/bash +# Copyright 2012 The Go Authors. All rights reserved. +# Use of this source code is governed by a BSD-style +# license that can be found in the LICENSE file. + +set -e + +go build -o go.latest +./go.latest help documentation >alldocs.go +gofmt -w alldocs.go +rm go.latest Property changes on: libgo/go/cmd/go/mkalldocs.sh ___ Added: svn:executable ## -0,0 +1 ## +* \ No newline at end of property Index: libgo/go/cmd/go/mkdoc.sh === --- libgo/go/cmd/go/mkdoc.sh(revision 259805) +++ libgo/go/cmd/go/mkdoc.sh(nonexistent) @@ -1,9 +0,0 @@ -#!/bin/sh -# Copyright 2012 The Go Authors. All rights reserved. -# Use of this source code is governed by a BSD-style -# license that can be found in the LICENSE file. - -go install # So the next line will produce updated documentation. -go help documentation > doc.go -gofmt -w doc.go -
[ARM] Fix PR85434: spill of stack protector's guard address
I'll make a fool of myself but I still have further questions if you don't
mind (see inline).
On Friday, 4 May 2018, Segher Boessenkool
wrote:
> Hi!
>
> On Wed, May 02, 2018 at 07:57:55AM +0100, Thomas Preudhomme wrote:
>> As mentionned in the ticket this was my first thought but this means
>> making the pattern aware of all the possible way the address could be
>> access (PIC Vs non-PIC, Arm Vs Thumb-2 Vs Thumb-1) to decide how many
>> scratch registers are needed. I'd rather reuse the existing pattern as
>> much as possible to make sure they are well tested. Ideally I wanted a
>> way to mark a REG RTX so that it is never spilled and such that the
>> mark is propagated when the register is moved to another register or
>> propagated. But that is a bigger change so decided it should be an
>> improvement for later but needed another solution right now.
>
> How would that work, esp. for pseudos? If too many regs have such a
> mark then the compiler will have to sorry() or similar, not a good
> thing at all.
I'm missing something, there should be the same amount of pseudo with that
mark as there is scratch in the new pattern doing memory address load(s) +
set / check. I'm guessing this is not as easy to achieve as it sounds.
>
>> By the way about making sure the address is not left in a register, I
>> have a question regarding the current stack_protect_set and
>> stack_protect_check pattern and their requirements to have register
>> cleared afterwards: why is that necessary? Currently not all registers
>> are cleared and the guard is available in the canari before it is
>> overwritten anyway so I don't see how clearing the register adds any
>> extra security. What sort of attack is it protecting against?
>
> From md.texi:
>
> @item @samp{stack_protect_set}
> This pattern, if defined, moves a @code{ptr_mode} value from the memory
> in operand 1 to the memory in operand 0 without leaving the value in
> a register afterward. This is to avoid leaking the value some place
> that an attacker might use to rewrite the stack guard slot after
> having clobbered it.
>
> (etc.)
I've read that doc but what I don't understand is why the guard value being
leaked in a register would be a problem if modified. The pattern as they
are guarantee the guard is always reloaded from its canonical location
(e.g. TLS var). Because the patterns do not represent in RTL what they do
the compiler could not reuse the value left in a register. Are we worrying
about optimization the assembler could do?
>
> Having the canary in a global variable makes it a lot easier for exploit
> code to access it then if it is e.g. in TLS data. Actually leaking a
> pointer to it would make it extra easy...
If an attacker can execute code to access and modify the guard, why would
s/he bother doing a stack overflow instead of just executing the code he
wants to directly?
Best regards,
Thomas
Re: GCC 8.1 Released
On Fri, May 4, 2018 at 9:31 AM, Janne Blomqvist wrote: > On Fri, May 4, 2018 at 9:22 AM, Bert Wesarg > wrote: > >> Hi, >> >> On Wed, May 2, 2018 at 2:15 PM, Jakub Jelinek wrote: >> > Some code that compiled successfully with older GCC versions might >> require >> > source changes, see http://gcc.gnu.org/gcc-8/porting_to.html for >> > details. >> >> in "Fortran language issues" it reads: "Prior to GCC 7", shouldn't >> that be "Prior to GCC 8" or "Up to GCC 7"? >> > > Yes, indeed it should. Thanks for noticing. > > >> >> And can somebody can tell me, whether this Fortran issue effects also >> Fortran code which calls C functions? >> >> > If it's a "normal" C function with NULL-terminated strings, then no. If > it's a C function which is designed to follow the Fortran procedure ABI > (where strings are passed as a pointer + a hidden length argument), then > yes. > > > > -- > Janne Blomqvist > I committed the following: cvs diff: Diffing . Index: porting_to.html === RCS file: /cvs/gcc/wwwdocs/htdocs/gcc-8/porting_to.html,v retrieving revision 1.5 diff -p -u -r1.5 porting_to.html --- porting_to.html25 Apr 2018 15:46:36 -1.5 +++ porting_to.html4 May 2018 06:34:31 - @@ -167,12 +167,12 @@ In member function 'bool B::f() Character lengths are now handled as an INTEGER(kind=C_SIZE_T) variable whose size is dependent on the target system, allowing characters longer than - 2**31 on 64-bit targets. Prior to GCC 7, the character length was + 2**31 on 64-bit targets. Prior to GCC 8, the character length was an INTEGER(kind=4) variable on all targets. If calling - a Fortran procedure with character arguments from C without using - the standard ISO_C_BINDING feature, the hidden character length - argument at the end of the argument list must thus be modified to be - of type size_t rather than of + a Fortran procedure with character arguments from C (or vice versa) + without using the standard ISO_C_BINDING feature, the hidden + character length argument at the end of the argument list must thus + be modified to be of type size_t rather than of type int. For instance, calling the Fortran subroutine -- Janne Blomqvist
Re: [PATCH] Add constant folding support for next{after,toward}{,f,l} (PR libstdc++/85466)
On Thu, 3 May 2018, Jakub Jelinek wrote: > On Thu, May 03, 2018 at 06:35:50PM +0200, Jakub Jelinek wrote: > > That requires a machine_mode or tree, but I don't have either of those, > > nor the caller (fold_const_call_sss) has those. > > > > I could change it to: > > if (flag_signalling_nans > > && !flag_finite_math_only > > && format->has_nans > > so that it would better duplicate what HONOR_SNANS actually tests. > > Though, I think it is ok to punt if one of the operands is a signalling nan > > even if flag_signalling_nans. > > Though in theory the arg0's mode for which we have format pointer could > not have nans, but arg1's mode (for which we only have the REAL_VALUE_TYPE) > could have nans (or vice versa). Hmm, indeed. OTOH what's wrong with just removing the flag_singalling_nans check, just keeping the actual checks for REAL_VALUE_ISSIGNALING_NAN? Thus the patch is ok with just those checks. The requested assert shouldn't be neccessary indeed. Thanks, Richard.
