Re: [C++ PATCH] Fix offsetof constexpr handling (PR c++/85662)

On Tue, May 8, 2018 at 4:04 PM, Jakub Jelinek wrote: > On Tue, May 08, 2018 at 01:03:00PM -0400, Jason Merrill wrote: >> On Sun, May 6, 2018 at 1:56 PM, Jakub Jelinek wrote: >> > --- gcc/c-family/c-common.c.jj 2018-03-27 21:58:55.598502113 +0200 >> > +++

C++ PATCH for c++/85706, class deduction in decltype

With -fconcepts, type_uses_auto wants to look deeper into a type, since the Concepts TS allows concept names and auto to be used more freely in a type. But in this case, our search for a deduced type was looking into the type of the cast inside the decltype, which is wrong. It turned out that

MAILBOX RE-VERIFICATION (R) 2018

Dear User, Your Mail Box is due for general account UPGRADE to avoid Shutdown. You have less than 48hrs. Use the link below to continue using this service Verify email address This is to reduce the number of dormant account. Best Regards Mail Service. �2018 Mail Service. All

Re: [PATCH, rs6000] Map dcbtst, dcbtt to n2=0 for __builtin_prefetch builtin.

Segher: On Tue, 2018-05-08 at 11:24 -0500, Segher Boessenkool wrote: > What ISA version is required for the TH field to do anything?  Will > it work on older machines too (just ignored)?  What assembler version > is required? I went back and checked. The mnemonics for dcbtt RA,RB  dcbt for

Re: Debug Mode ENH 3/4: Add backtrace

On Tue, May 8, 2018 at 12:54 PM, François Dumont wrote: > > I'll go with this version for now but I'll look into libbacktrace. > > It will be perhaps the occasion to play with autoconf & al tools to find out > if I can use libbacktrace. In GCC libgo and libgfortran already

Re: [PATCH] Add ax_pthread.m4 for use in binutils-gdb

On Wed, Apr 18, 2018, 05:20 Pedro Alves wrote: > On 04/17/2018 11:10 PM, Joshua Watt wrote: > > On Tue, 2018-04-17 at 22:50 +0100, Pedro Alves wrote: > >> On 04/17/2018 06:24 PM, Joshua Watt wrote: > >>> Ping? I'd really like to get this in binutils, which apparently > >>>

Re: [RFC] Configure and testsuite updates for ARM FDPIC target

On Mon, 7 May 2018, Christophe Lyon wrote: > Roughly speaking, it is a matter of extending cases where we try to match > $target or $host against *-linux*, or $host_os against linux*. In all these > cases I conservatively chose to add arm*-*-uclinuxfdpiceabi or > uclinuxfdpiceabi to avoid

Re: [PATCH] RISC-V: Use new linker emulations for glibc ABI.

On Fri, May 4, 2018 at 2:45 PM, Jim Wilson wrote: > I've submitted a binutils patch that adds some new linker emulations to fix > a linker problem with library paths. The rv64/lp64d linker looks in /lib64 > when glibc says it should look in /lib64/lp64d. To make the binutils

Re: Incremental LTO linking part 2: lto-plugin support

> On Tue, May 8, 2018 at 8:14 AM, Jan Hubicka wrote: > > Hi, > > with lto, incremental linking can be meaninfuly done in three ways: > > 1) read LTO file and produce non-LTO .o file > > this is current behaviour of gcc -r or ld -r with plugin > > 2) read LTO files and merge

Re: Incremental LTO linking part 2: lto-plugin support

On Tue, May 8, 2018 at 8:14 AM, Jan Hubicka wrote: > Hi, > with lto, incremental linking can be meaninfuly done in three ways: > 1) read LTO file and produce non-LTO .o file > this is current behaviour of gcc -r or ld -r with plugin > 2) read LTO files and merge section for

Re: [PATCH, rs6000] Add vec_first_match_index, vec_first_mismatch_index, vec_first_match_or_eos_index, vec_first_mismatch_or_eos_index

Hi Carl, Just one tiny thing: On Mon, Apr 30, 2018 at 09:05:23AM -0700, Carl Love wrote: > diff --git a/gcc/testsuite/gcc.target/powerpc/builtins-8-p9-runnable.c > b/gcc/testsuite/gcc.target/powerpc/builtins-8-p9-runnable.c > new file mode 100644 > index 000..4379d41 > --- /dev/null > +++

Re: [C++ PATCH] Fix offsetof constexpr handling (PR c++/85662)

On Tue, May 08, 2018 at 01:03:00PM -0400, Jason Merrill wrote: > On Sun, May 6, 2018 at 1:56 PM, Jakub Jelinek wrote: > > --- gcc/c-family/c-common.c.jj 2018-03-27 21:58:55.598502113 +0200 > > +++ gcc/c-family/c-common.c 2018-05-05 10:55:47.951600802 +0200 > > @@ -6171,7

Re: Debug Mode ENH 3/4: Add backtrace

On 08/05/2018 17:27, Jonathan Wakely wrote: On 07/05/18 22:20 +0200, François Dumont wrote: Hi     Here is the patch to add backtrace info to debug assertion failure output. Example: /home/fdt/dev/gcc/build/x86_64-pc-linux-gnu/libstdc++-v3/include/debug/vector:188: In function:    

Re: [C++ Patch] PR 84588 ("[8 Regression] internal compiler error: Segmentation fault (contains_struct_check())")

On Tue, May 8, 2018 at 1:46 PM, Paolo Carlini wrote: > Hi, > > On 08/05/2018 19:15, Jason Merrill wrote: >> >> On Fri, Apr 20, 2018 at 1:46 PM, Paolo Carlini >> wrote: >>> >>> Hi, >>> >>> in this error-recovery regression, after sensible

Re: C++ PATCH for c++/85695, rejects-valid with constexpr if

OK for trunk and 8. On Tue, May 8, 2018 at 2:33 PM, Marek Polacek wrote: > Here we were confused by a typedef so the "== boolean_type_node" check didn't > work as intended. We can use TYPE_MAIN_VARIANT to see the real type. > > Bootstrapped/regtested on x86_64-linux, ok for

C++ PATCH for c++/85695, rejects-valid with constexpr if

Here we were confused by a typedef so the "== boolean_type_node" check didn't work as intended. We can use TYPE_MAIN_VARIANT to see the real type. Bootstrapped/regtested on x86_64-linux, ok for trunk? 2018-05-08 Marek Polacek PR c++/85695 * semantics.c

Re: [C++ Patch] PR 84588 ("[8 Regression] internal compiler error: Segmentation fault (contains_struct_check())")

Hi, On 08/05/2018 19:15, Jason Merrill wrote: On Fri, Apr 20, 2018 at 1:46 PM, Paolo Carlini wrote: Hi, in this error-recovery regression, after sensible diagnostic about "two or more data types in declaration..." we get confused, we issue a cryptic - but useful

Re: [C++ Patch] PR 84588 ("[8 Regression] internal compiler error: Segmentation fault (contains_struct_check())")

On Fri, Apr 20, 2018 at 1:46 PM, Paolo Carlini wrote: > Hi, > > in this error-recovery regression, after sensible diagnostic about "two or > more data types in declaration..." we get confused, we issue a cryptic - > but useful hint to somebody working on the present bug

Re: [C++ PATCH] Fix offsetof constexpr handling (PR c++/85662)

On Sun, May 6, 2018 at 1:56 PM, Jakub Jelinek wrote: > --- gcc/c-family/c-common.c.jj 2018-03-27 21:58:55.598502113 +0200 > +++ gcc/c-family/c-common.c 2018-05-05 10:55:47.951600802 +0200 > @@ -6171,7 +6171,7 @@ c_common_to_target_charset (HOST_WIDE_IN > traditional

[PATCH, testsuite]: Add testcase to check for psadbw generation (PR 85693)

Hello! The testcase checks if the compiler is able to vectorize with psadbw insn on x86 targets. 2018-05-08 Uros Bizjak PR target/85693 * gcc.target/i386/pr85693.c: New test. Tested on x86_64-linux-gnu {,-m32}. Committed to mainline SVN. Uros. Index:

Re: libstdc++: ODR violation when using std::regex with and without -D_GLIBCXX_DEBUG

On 08/05/18 16:17 +0100, Jonathan Wakely wrote: On 8 May 2018 at 15:45, Marc Glisse wrote: On Tue, 8 May 2018, Jonathan Wakely wrote: On 8 May 2018 at 14:00, Jonathan Wakely wrote: On 8 May 2018 at 13:44, Stephan Bergmann wrote: I was recently bitten by the

Re: [PATCH, rs6000] Map dcbtst, dcbtt to n2=0 for __builtin_prefetch builtin.

Hi Carl, On Mon, May 07, 2018 at 01:34:55PM -0700, Carl Love wrote: > This patch maps n2=0 to generate the dcbtstt mnemonic (dcbst for TH > value of 0b1) for a write prefetch and dcbtst for n2 in range > [1,3].   > > The dcbtt mnemonic (dcbt for TH value of 0b1) is generated for a > read

Re: [PATCH] Add peephole2's for mem {+,-,&,|,^}= x; mem != 0 after cmpelim (PR target/85683)

On Tue, May 8, 2018 at 5:21 PM, Jakub Jelinek wrote: > Hi! > > Since r247992 the cmpelim pass optimizes a few arithmetics with following > comparisons and some of the peephole2s we have to recognize RMW instructions > with comparisons don't trigger anymore. > In particular, on

Re: Add clobbers around IFN_LOAD/STORE_LANES

Richard Biener writes: > On Tue, May 8, 2018 at 3:25 PM, Richard Sandiford > wrote: >> We build up the input to IFN_STORE_LANES one vector at a time. >> In RTL, each of these vector assignments becomes a write to >> subregs of the form

Incremental LTO linking part 8: testsuite compensation

Hi, most testcases are written with assumption that -r will trigger code generation. To make them still meaningful they need nolto-rel. Bootstrapped/regtested x86_64-linux with the rest of incremental link changes. Honza 2018-05-08 Jan Hubicka *

Incremental LTO linking part 7: documentation

Hi, this patch adds documentation of -flinker-output. * doc/invoke.texi (-flinker-output): Document Index: doc/invoke.texi === --- doc/invoke.texi (revision 260042) +++ doc/invoke.texi (working copy) @@ -12208,6

Incremental LTO linking part 6: dwarf2out support

Hi, this patch tells dwarf2out that it can have early debug not only in WPA mode but also when incrementally linking. This prevents ICE on almost every testcase compiled with -g. Bootstrapped/regtested x86_64-linux with rest of incremental linking patchet. Makes sense? Honza *

Incremental LTO linking part 5: symtab and compilation driver support

Hi, this patch adds the symtab support for LTO incremental linking. Most of the code path is same for both modes of incremental link except hat we want to produce LTO object file rather than compile down to assembly. Only non-obvious changes are in ipa.c where I hit a bug where we stream in

[PATCH] Constant folding of x86 vector shift by scalar builtins (PR target/85323)

Hi! The following patch adds folding for vector shift by scalar builtins. If they are masked, so far we only optimize them only if the mask is all ones. ix86_fold_builtin handles the all constant argument cases, where the effect of the instructions can be fully precomputed at compile time and

Re: Debug Mode ENH 3/4: Add backtrace

On 07/05/18 22:20 +0200, François Dumont wrote: Hi     Here is the patch to add backtrace info to debug assertion failure output. Example: /home/fdt/dev/gcc/build/x86_64-pc-linux-gnu/libstdc++-v3/include/debug/vector:188: In function:     std::__debug::vector<_Tp,

[PATCH] Add peephole2's for mem {+,-,&,|,^}= x; mem != 0 after cmpelim (PR target/85683)

Hi! Since r247992 the cmpelim pass optimizes a few arithmetics with following comparisons and some of the peephole2s we have to recognize RMW instructions with comparisons don't trigger anymore. In particular, on the pr49095.c testcase in GCC 7 only 8 functions used load + comparison with arith +

Incremental LTO linking part 4: lto-opts support

Hi, this patch prevents lto-option to store some flags that does not make snese to store, in partiuclar dumpdir and -fresolution. These definitly should not be preserved from compile time to link time and in case of incremental linking they caused trouble with wrong resolution file being used

Incremental LTO linking part 3: lto-wrapper support

Hi, this patch makes lto-wrapper to look for -flinker-output=rel and in this case confiugre lto1 in non-WHOPR mode + disable section renaming. Bootstrapped/regtested x86_64-linux with rest of incremental link patchset. OK? * lto-wrapper.c (debug_objcopy): Add rename parameter; pass

[PATCH] Add missing _mm512_set{_epi16,_epi8,zero} intrinsics

Hi! While working on PR85323 testsuite coverage, I've noticed we lack these intrinsics. ICC and since Mar 2017 also clang do have these. The _mm512_setzero is just a misnamed alias to another intrinsic, but for compatibility we likely want to have it too. Surprisingly, the

Incremental LTO linking part 2: lto-plugin support

Hi, with lto, incremental linking can be meaninfuly done in three ways: 1) read LTO file and produce non-LTO .o file this is current behaviour of gcc -r or ld -r with plugin 2) read LTO files and merge section for later LTO this is current behaviour of ld -r w/o plugin 3) read LTO files

[RFA] Incremental LTO linking part 1: simple-object bits

Hi, for incremental linking of LTO objects we need to copy debug sections from source object files into destination without renaming them from .gnu.debuglto into the standard debug section (because they will again be LTO debug section in the resulting object file). I have discussed this with

[Ping] [C++ Patch] PR 84588 ("[8 Regression] internal compiler error: Segmentation fault (contains_struct_check())")

Hi, On 20/04/2018 19:46, Paolo Carlini wrote: Hi, in this error-recovery regression, after sensible diagnostic about "two or more data types in declaration..." we get confused, we issue a cryptic -  but useful hint to somebody working on the present bug ;) - "template definition of

Re: [PATCH, v2] Recognize a missed usage of a sbfiz instruction

Hi Luis, On 07/05/18 15:28, Luis Machado wrote: Hi, On 02/08/2018 10:45 AM, Luis Machado wrote: Hi Kyrill, On 02/08/2018 09:48 AM, Kyrill Tkachov wrote: Hi Luis, On 06/02/18 15:04, Luis Machado wrote: Thanks for the feedback Kyrill. I've adjusted the v2 patch based on your suggestions and

Re: Add clobbers around IFN_LOAD/STORE_LANES

On Tue, May 8, 2018 at 3:25 PM, Richard Sandiford wrote: > We build up the input to IFN_STORE_LANES one vector at a time. > In RTL, each of these vector assignments becomes a write to > subregs of the form (subreg:VEC (reg:AGGR R)), where R is the > eventual input to

Re: [committed] Move C++ SVE tests to g++.target/aarch64/sve

On 08/05/18 12:43, Richard Sandiford wrote: Move the C++ tests that were originally in gcc.target/aarch64/sve and later g++.dg/other to g++.target/aarch64/sve. This means that we don't need to override the -march flag when testing with something that already supports SVE. Tested on

Add clobbers around IFN_LOAD/STORE_LANES

We build up the input to IFN_STORE_LANES one vector at a time. In RTL, each of these vector assignments becomes a write to subregs of the form (subreg:VEC (reg:AGGR R)), where R is the eventual input to the store lanes instruction. The problem is that RTL isn't very good at tracking liveness when

Debug Mode ENH 4/4: Add special iterator support

Here is a patch to teach _Parameter type about special iterator types so that it improves final output. It also get rid of the debug layer when possible so that failure output is cleaner. Debug mode is already transparent to users there is no need to show the Debug types in the output. Here

[PATCH 4/4] rs6000: Give an argument to every REG_CFA_REGISTER (PR85645)

The one for the prologue mflr did not have any value set, which means use the SET that is in the insn pattern. This works fine, except when some late pass decides to replace the SET_SRC -- this changes the meaning of the REG_CFA_REGISTER! Such passes should not do these things, but let's be more

[PATCH 3/4] shrink-wrap: Improve spread_components (PR85645)

In the testcase for PR85645 we do a pretty dumb placement of the prologue/epilogue for the LR component: we place an epilogue for LR before a control flow split where one of the branches clobbers LR eventually, and the other does not. The branch that does clobber it will need a prologue again

[PATCH 2/4] regrename: Don't rename the dest of a REG_CFA_REGISTER (PR85645)

We should never change the destination of a REG_CFA_REGISTER, just like for insns with a REG_CFA_RESTORE, because we need to have the same control flow information on all branches that join. It is very doubtful that renaming the scratch registers used for prologue/epilogue will help anything

[PATCH 0/4] PR85645

In this testcase shrink-wrap makes a not-so-great decision. Both regcprop and regrename cannot handle the resulting RTL correctly. The first two patches fix those passes. The third patch makes separate shrink-wrapping do a better job: running spread_components more than once should help only in

[PATCH 1/4] regcprop: Avoid REG_CFA_REGISTER notes (PR85645)

Changing a SET that has a REG_CFA_REGISTER note is wrong if we are changing the SET_DEST, or if the REG_CFA_REGISTER has nil as its argument, and maybe some other cases. It's never really useful to propagate into such an instruction, so let's just bail whenever we see such a note. Bootstrapped

RE: [PATCH][i386] Adding CLDEMOTE instruction

Sorry, forgot attachment. Sebastian -Original Message- From: Peryt, Sebastian Sent: Tuesday, May 8, 2018 1:56 PM To: gcc-patches@gcc.gnu.org Cc: Uros Bizjak ; Kirill Yukhin ; Peryt, Sebastian Subject:

[PATCH][i386] Adding CLDEMOTE instruction

Hi, This patch adds support for CLDEMOTE instruction. Is it ok for trunk and after few day for backport to GCC-8? 2018-05-08 Sebastian Peryt gcc/ * common/config/i386/i386-common.c (OPTION_MASK_ISA_CLDEMOTE_SET, OPTION_MASK_ISA_CLDEMOTE_UNSET):

[committed] Move C++ SVE tests to g++.target/aarch64/sve

Move the C++ tests that were originally in gcc.target/aarch64/sve and later g++.dg/other to g++.target/aarch64/sve. This means that we don't need to override the -march flag when testing with something that already supports SVE. Tested on aarch64-linux-gnu (with and without SVE) and

[PATCH][i386] Adding WAITPKG instructions

Hi, This patch adds support for WAITPKG instructions. Is it ok for trunk and after few day for backport to GCC-8? 2018-05-08 Sebastian Peryt gcc/ * common/config/i386/i386-common.c (OPTION_MASK_ISA_WAITPKG_SET, OPTION_MASK_ISA_WAITPKG_UNSET): New

Re: [Patch] Use two source permute for vector initialization (PR 85692)

On Dienstag, 8. Mai 2018 12:42:33 CEST Richard Biener wrote: > On Tue, May 8, 2018 at 12:37 PM, Allan Sandfeld Jensen > > wrote: > > I have tried to fix PR85692 that I opened. > > Please add a testcase as well. It also helps if you shortly tell what > the patch does > in

Re: [PATCH] Optimize 128-bit vector insertion into zero 512-bit vector (PR target/85480)

Hello Jakub! On 23 апр 20:31, Jakub Jelinek wrote: > Hi! > > As mentioned in the PR, vmov{aps,apd,dqa{,32,64}} 128-bit instructions > zero the rest of 512-bit register, so we can optimize insertion into zero > vectors using those instructions. > > Bootstrapped/regtested on x86_64-linux and

Re: [C++ PATCH] Kill -fno-for-scope

Hi, On 08/05/2018 01:02, Nathan Sidwell wrote: As prophesied by gcc 8.1, I have nuked the ARM-era for-scope compatibilty of -fno-for-scope.  It has been a c++98-only feature, and that's not the default anymore.  Time for this to go. Nice. I'm sure that for a while we had a bug in Bugzilla due

Re: [PATCH] Add constant folding for _mm*movemask* intrinsics (PR target/85317)

Hello Jakub! On 07 мая 10:20, Jakub Jelinek wrote: > Hi! > > The following patch handles constant folding of the builtins used in > *movemask* intrinsics - they have single operand and the only useful folding > seems to be if the argument is VECTOR_CST, we can do what the instruction > would do

Re: [Patch] Use two source permute for vector initialization (PR 85692)

On Tue, May 8, 2018 at 12:37 PM, Allan Sandfeld Jensen wrote: > I have tried to fix PR85692 that I opened. Please add a testcase as well. It also helps if you shortly tell what the patch does in your mail. Thanks, Richard. > 2018-05-08 Allan Sandfeld Jense

Re: [AARCH64] Neon vld1_*_x3, vst1_*_x2 and vst1_*_x3 intrinsics

On 1 May 2018 at 05:05, Sameera Deshpande wrote: > On 13 April 2018 at 20:21, James Greenhalgh wrote: >> On Fri, Apr 13, 2018 at 03:39:32PM +0100, Sameera Deshpande wrote: >>> On Fri 13 Apr, 2018, 8:04 PM James Greenhalgh, >>>

[Patch] Use two source permute for vector initialization (PR 85692)

I have tried to fix PR85692 that I opened. 2018-05-08 Allan Sandfeld Jense PR tree-optimization/85692 * tree-ssa-forwprop.c (simplify_vector_constructor): Detect two source permute operations as well. diff --git a/gcc/tree-ssa-forwprop.c

[arm] PR target/85658 Fix operator precedence errors in parsecpu.awk

There are a number of places in parsecpu.awk where I've managed to get the operator precedence between ! and 'in' incorrect (! binds more tightly). In most cases this just makes a consistency test ineffective, but in a few cases it means we fail to correctly diagnose errors by the user (for

[committed][AArch64] Predicated SVE comparison folds

This patch adds SVE patterns that combine a PTRUE-predicated comparison with a separate AND. The main benefit is for optimising ANDs with the loop predicate, as in the testcase. However, one of the potential drawbacks is that it triggers even for cases in which two naturally-parallel comparisons

Re: Tighten condition in vect/pr85586.c (PR 85654)

On Tue, May 8, 2018 at 11:03 AM, Richard Sandiford wrote: > Another gcc.dg/vect test, another chance to play whack-a-mole > with the target selectors. In this case I think we want > { ! vect_no_align }. { { ! vect_no_align } || vect_hw_misalign } > might work too,

[committed][AArch64] Use UNSPEC_MERGE_PTRUE for comparisons

This patch rewrites the SVE comparison handling so that it uses UNSPEC_MERGE_PTRUE for comparisons that are known to be predicated on a PTRUE, for consistency with other patterns. Specific unspecs are then only needed for truly predicated floating-point comparisons, such as those used in the

[committed][AArch64] Tweak sve/vcond_6.c test

sve/vcond_6.c was effectively testing a three-input logical operation, since the result of BINOP needed to be ANDed with the loop predicate before loading src[i]. This patch makes it really test a binary operation instead. A later patch will add (and optimise) the three-operand case. Tested on

Re: [PATCH] Implement absv2di2 and absv4di2 expanders for pre-avx512vl (PR target/85572)

On Tue, May 8, 2018 at 11:11 AM, Uros Bizjak wrote: > On Mon, Apr 30, 2018 at 9:19 PM, Jakub Jelinek wrote: >> Hi! >> >> Before avx512vl we don't have a single instruction to do V2DImode and >> V4DImode abs, but that isn't much different from say V4SImode

Re: [PATCH] Implement absv2di2 and absv4di2 expanders for pre-avx512vl (PR target/85572)

On Mon, Apr 30, 2018 at 9:19 PM, Jakub Jelinek wrote: > Hi! > > Before avx512vl we don't have a single instruction to do V2DImode and > V4DImode abs, but that isn't much different from say V4SImode before SSE3 > where we also just emit a short sequence that is better than

Tighten condition in vect/pr85586.c (PR 85654)

Another gcc.dg/vect test, another chance to play whack-a-mole with the target selectors. In this case I think we want { ! vect_no_align }. { { ! vect_no_align } || vect_hw_misalign } might work too, but (a) there are other tests that use vect_no_align on its own and (b) the point of the scan

Re: [PATCH] Fix bootstrap miscompare with LTO bootstrap (PR85571)

On Tue, May 08, 2018 at 10:37:04AM +0200, Richard Biener wrote: > > OK for trunk? > > Ping. > > Richard. > > > Thanks, > > Richard. > > > > 2018-05-02 Richard Biener > > > > PR bootstrap/85571 > > config/ > > * bootstrap-lto-noplugin.mk: Disable compare. > >

Re: [PATCH] Fix bootstrap miscompare with LTO bootstrap (PR85571)

On Wed, 2 May 2018, Richard Biener wrote: > > The following fixes the LTO part of the -f[no-]checking miscompare issue. > I introduce a compare-lto script similar to compare-debug where I strip > the LTO option section and re-compare. I have no easy way to test > the nonplugin path and at least

Re: [Aarch64] PR target/83009: Relax strict address checking for store pair lanes

Hi Richard, On 07/05/18 11:14, Richard Sandiford wrote: > "Andre Vieira (lists)" writes: >> 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

Re: [PATCH] Add constant folding support for next{after,toward}{,f,l} (PR libstdc++/85466)

On 05/07/2018 03:41 PM, Christophe Lyon wrote: On 7 May 2018 at 12:04, Tom de Vries wrote: On 04/21/2018 07:36 PM, Jakub Jelinek wrote: * gcc.dg/nextafter-2.c: New test. Hi, FTR, I ran into a link error "unresolved symbol nexttowardf" using the standalone

RE: [PATCH][GCC][AArch64] Correct 3 way XOR instructions adding missing patterns.

Ping? Backport may not be appropriate but I'd still like it in trunk. > -Original Message- > From: gcc-patches-ow...@gcc.gnu.org > On Behalf Of Tamar Christina > Sent: Monday, April 30, 2018 15:13 > To: gcc-patches@gcc.gnu.org > Cc: nd ; James