On 11/19/20 11:41 AM, Jason Merrill wrote:
On 11/17/20 3:44 AM, Jan Hubicka wrote:
On Tue, Nov 17, 2020 at 01:33:48AM -0500, Jason Merrill via
Gcc-patches wrote:
Why doesn't the middle-end warning work for inline functions?
It does but only when they're called (and, as usual, also unless
the
On 11/20/20 11:12 AM, Martin Sebor via Gcc-patches wrote:
> dump_function_to_file prints DECL_ATTRIBUTES but not TYPE_ATTRIBUTES
> when both can be important and helpful for debugging, especially with
> attributes that are added implicitly (such attribute access and
> the proposed internal attri
On 11/19/20 8:34 PM, Maciej W. Rozycki wrote:
> The `c' operand format specifier is handled directly by the middle end
> in `output_asm_insn':
>
>%cN means require operand N to be a constant
> and print the constant expression with no punctuation.
>
> however it resorts to the target f
On 11/19/20 8:34 PM, Maciej W. Rozycki wrote:
> It makes sense to use what other targets do and run all the VAX test
> cases over all the usual optimization levels, so make `vax.exp' use our
> `gcc-dg-runtest' rather than the generic `dg-runtest' test driver.
>
> This breaks `pr56875.c' however,
On 11/19/20 8:34 PM, Maciej W. Rozycki wrote:
> The `builtins.md' machine description fragment is not included anywhere
> and is therefore dead code, which has become bitrotten due to non-use.
>
> If actually enabled, it does not build due to the use of an unknown `t'
> constraint:
>
> .../gcc/c
On 11/19/20 8:34 PM, Maciej W. Rozycki wrote:
> Regardless of the machine mode all the interlocked branches of the same
> kind, one of the two provided by the ISA, use the same RTL patterns and
> machine instructions, except for the memory operand's constraint.
>
> Remove code duplication then a
On 11/19/20 8:34 PM, Maciej W. Rozycki wrote:
> With mode-specific interlocked branch insns already folded into iterated
> templates now fold the two templates into one too, observing that the
> only difference between them is the value of the bit branched on, which
> is of course reflected both
On 11/19/20 8:35 PM, Maciej W. Rozycki wrote:
> Test cases will follow.
>
> gcc/
> * config/vax/vax.md: Include `builtins.md'.
OK. THough probably shouldn't commit individually, but instead once all
the prereqs are done.
jeff
On 11/19/20 8:35 PM, Maciej W. Rozycki wrote:
> gcc/testsuite/
> * gcc.target/vax/ffssi.c: New test.
OK. Same comment about prereqs.
jeff
On 11/19/20 8:35 PM, Maciej W. Rozycki wrote:
> Based on gcc.dg/pr61756.c.
>
> gcc/testsuite/
> * gcc.target/vax/bbcci.c: New test.
> * gcc.target/vax/bbssi.c: New test.
OK
jeff
On 11/19/20 8:35 PM, Maciej W. Rozycki wrote:
> Our `ffssi2_internal' pattern and the machine FFS instruction, which
> technically is a bitfield operation, match the `ctz' operation exactly,
> with the result produced for the bitfield source operand of zero equal
> to its width as specified with
On 11/19/20 8:35 PM, Maciej W. Rozycki wrote:
> The FFS machine instruction provides for arbitrary input bitfield widths
> so take advantage of this and convert `ffssi2' and `ctzsi2' to templates
> for all the three of QI, HI, SI machine modes.
>
> Test cases will be added separately.
>
>
On 11/19/20 8:35 PM, Maciej W. Rozycki wrote:
> The middle end does not refer to `ctzqi2'/`ctzhi2' or `ffsqi2'/`ffshi2'
> patterns by name where `__builtin_ctz' or `__builtin_ffs' respectively
> is invoked for an argument of the QImode or HImode type, and instead it
> extends the data type befor
On 11/19/20 8:35 PM, Maciej W. Rozycki wrote:
> gcc/testsuite/
> * gcc.target/vax/cpymem.c: New test.
OK
jeff
On 11/19/20 8:35 PM, Maciej W. Rozycki wrote:
> The MOVC3 machine instruction has `memmove' semantics[1]:
>
> "The operation of the instruction is such that overlap of the source and
> destination strings does not affect the result."
>
> so use it to provide the `movmemhi' instruction as well.
>
From: Thomas Rodgers
Should include all discussion on and off list to date.
Adds
libstdc++/ChangeLog:
* include/Makefile.am (std_headers): Add new header.
* include/Makefile.in: Regenerate.
* include/std/barrier: New file.
* include/std/version: Add __cpp_lib_b
This patch updates libgo to the Go 1.15.5 release. Bootstrapped and
ran Go testsuite on x86_64-pc-linux-gnu. Committed to mainline.
Ian
6c458bbaaa54755de5b25e5a844186893b2b8568
diff --git a/gcc/go/gofrontend/MERGE b/gcc/go/gofrontend/MERGE
index 9545a598738..37374d55853 100644
--- a/gcc/go/gofro
On 11/19/20 8:34 PM, Maciej W. Rozycki wrote:
> The VAX ELF psABI does not permit the use of all hardware operand modes
> for PIC symbol references due to the need to use PC-relative addressing
> for symbols that end up local and the need to make references indirect
> symbols that end up global.
On 11/19/20 8:34 PM, Maciej W. Rozycki wrote:
> Expression costs are required to be given in terms of COSTS_N_INSNS (n),
> which is defined to stand for the count of single fast instructions, and
> actually returns `n * 4'. The VAX backend however instead operates on
> naked numbers, causing an
On 11/19/20 8:36 PM, Maciej W. Rozycki wrote:
> It makes no sense for insn operand predicates, as long as they accept a
> register operand, to be more restrictive than the set of the associated
> constraints, because expand will choose the insn based on the relevant
> operand being a pseudo regi
On 11/19/20 8:36 PM, Maciej W. Rozycki wrote:
> Correct issues with commented-out insns, which fail to build if enabled:
>
> .../gcc/config/vax/vax.md:503:1: repeated operand number 1
> .../gcc/config/vax/vax.md:503:1: repeated operand number 2
>
> and then when the issue with the repeated opera
On 11/19/20 8:36 PM, Maciej W. Rozycki wrote:
> Use a double colon to introduce the comments like elsewhere throughout
> the VAX machine description.
>
> gcc/
> * config/vax/vax.md (divmoddisi4, *amulsi4): Make the comment
> notation consistent with the rest of the file.
OK
jef
On 11/19/20 8:36 PM, Maciej W. Rozycki wrote:
> We do not define a comparison operation between floating-point and
> integer data, including integer zero constant. Consequently the RTL
> instruction stream presented to the post-reload comparison elimination
> pass will include, where applicable
On 11/19/20 8:37 PM, Maciej W. Rozycki wrote:
> gcc/testsuite/
> PR target/95294
> * gcc.target/vax/cmpelim-eq-adddf.c: New test.
> * gcc.target/vax/cmpelim-eq-addhi.c: New test.
> * gcc.target/vax/cmpelim-eq-addqi.c: New test.
> * gcc.target/vax/cmpelim-eq-ad
On 11/19/20 8:34 PM, Maciej W. Rozycki wrote:
> Add wide integer aka 'w' rtx format support to int iterators so that
> machine description can iterate over `const_int' expressions.
>
> This is made by expanding standard integer aka 'i' format support,
> observing that any standard integer alread
On 11/19/20 8:34 PM, Maciej W. Rozycki wrote:
> VAX has interlocked branch instructions used for atomic operations and
> we want to have them wrapped in UNSPEC_VOLATILE so as not to have code
> carried across. This however breaks with jump optimization and leads
> to an ICE in the build of libb
On 11/19/20 8:35 PM, Maciej W. Rozycki wrote:
> Remove an ICE like:
>
> during RTL pass: expand
> .../libatomic/tas_n.c: In function 'libat_test_and_set_1':
> .../libatomic/tas_n.c:39:1: internal compiler error: in patch_jump_insn, at
> cfgrtl.c:1298
>39 | }
> | ^
> 0x108a09ff patch_j
On 2/11/20 11:43 AM, Ulrich Weigand wrote:
> Hello,
>
> this second version of the patch incorporates all changes discussed
> in the original mail thread starting here:
> https://gcc.gnu.org/ml/gcc-patches/2020-01/msg02097.html
>
> The patch now implements the following set of changes:
>
> 1. If
On 11/9/20 9:00 AM, Martin Sebor wrote:
> Ping:
> https://gcc.gnu.org/pipermail/gcc-patches/2020-September/554000.html
>
> Jeff, I don't expect to have the cycles to reimplement this patch
> using the Ranger APIs before stage 1 closes. I'm open to giving
> it a try in stage 3 if it's still in s
These 3 patches are the slight reworking of two separate patches for the
library tests.
The first patch that has been replaced is:
Date: Sun, 15 Nov 2020 12:17:47 -0500
Subject: [PATCH] PowerPC Fix ibm128 defaults for pr70117.c test.
Message-ID: <20201115171747.ga10...@ibm-toto.the-meissners.org>
On Thu, Nov 19, 2020 at 08:03:02AM -0600, Segher Boessenkool wrote:
> On Thu, Nov 19, 2020 at 03:08:05AM -0500, Michael Meissner wrote:
> > On Wed, Nov 18, 2020 at 04:29:09PM -0600, Segher Boessenkool wrote:
> > > Mike, please add a comment, what number it represents? Okay for trunk
> > > with tha
On Wed, Nov 18, 2020 at 01:27:12PM -0600, Segher Boessenkool wrote:
> Hi!
>
> On Sun, Nov 15, 2020 at 12:23:50PM -0500, Michael Meissner wrote:
> > --- a/gcc/testsuite/c-c++-common/dfp/convert-bfp-11.c
> > +++ b/gcc/testsuite/c-c++-common/dfp/convert-bfp-11.c
> > @@ -1,4 +1,5 @@
> > /* { dg-skip-
PowerPC: Add long double target-supports.
This patch adds 3 target supports to test what type of PowerPC long double is
used by the test:
1) Long double uses the IBM 128-bit extended double format;
2) Long double uses the IEEE 128-bit format; (and)
3) Long double uses the 64-bit fo
PowerPC: require IBM long double for pr70117.
Since the test is explicitly checking for IBM extended double, do not try to
run it when long double is IEEE 128-bit.
I have tested this patch and the first patch in the series on a little endian
power9 system with 3 compilers that have the 3 differen
PowerPC: Require IBM long double for conversion test.
The test c-c++-common/dfp/convert-bfp-11.c explicit expects long double to use
the IBM 128-bit extended double format. In particular, some of the tests
expect an infinity to be created if decimal values that are converted that are
too large fo
On Sat, Nov 21, 2020 at 6:12 AM Jim Wilson wrote:
>
> On Fri, Nov 20, 2020 at 12:34 AM Kito Cheng wrote:
>
> > - Define MULTILIB_DEFAULTS can reduce the total number of multilib if
> >the default arch and ABI are listed in the multilib config.
> >
>
> It looks like a good idea, but it doesn'
Hi!
The following patch recognizes some further forms of additions with overflow
checks as shown in the testcase, in particular where the unsigned addition is
performed in a wider mode just to catch overflow with a > narrower_utype_max
check.
Bootstrapped/regtested on x86_64-linux and i686-linux,
101 - 137 of 137 matches
Mail list logo
