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,
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'
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
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: 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
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-
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
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 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
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/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 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: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: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: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: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:
> 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:
> 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: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: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.
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
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
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.
>
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 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:
> 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:
> 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:
> 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:
> 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:
> 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: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: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:
> 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:
> 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 `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/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 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
Tested x86_64-pc-linux-gnu, committed.
> On Oct 27, 2020, at 3:23 AM, Jonathan Wakely wrote:
>
> On 26/10/20 14:48 -0700, Thomas Rodgers wrote:
>> +#include
>> +
>> +#if __has_include()
>> +#define _GLIBCXX_HAVE_POSIX_SEMAPHORE 1
>> +#include
>
> It occurs to me now that this check probably i
On 11/20/20 2:57 PM, Jakub Jelinek wrote:
On Fri, Nov 20, 2020 at 02:54:34PM -0700, Martin Sebor wrote:
At the point the attribute is created there is no SAVE_EXPR. So for
something like:
int f (void);
void g (int a[f () + 1]) { }
the bound is a PLUS_EXPR (CALL_EXPR (f), 1).
I don't do a
On 11/7/20 10:11 AM, Iain Sandoe wrote:
Hi,
For Objective-C++/C, we cater for the possibility that a class interface
(@interface) might be preceded by prefix attributes. In the case of
Objective-C++, the reference implementation (a.k.a. clang) also allows
(and combines) prefix attributes that p
On 11/17/20 2:32 PM, Marek Polacek wrote:
This invalid (?) code broke my assumption that if decl_specifiers->type
is null, there must be any type-specifiers. Turn the assert into an if
to fix this crash.
Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk?
gcc/cp/ChangeLog:
PR
On 11/16/20 9:58 PM, Marek Polacek wrote:
[dcl.constexpr]/3 says that the function-body of a constexpr function
shall not contain an identifier label, but we aren't enforcing that.
This patch implements that. Of course, we can't reject artificial
labels.
Bootstrapped/regtested on x86_64-pc-lin
On 11/16/20 6:52 PM, Marek Polacek wrote:
On Mon, Nov 16, 2020 at 05:02:14PM -0500, Jason Merrill via Gcc-patches wrote:
On 11/15/20 10:34 PM, Marek Polacek wrote:
[ This year's end-of-stage1 I'm working virtually from American Samoa. ]
This patch finishes the second half of -Wrange-loop-const
On 11/18/20 1:16 PM, Marek Polacek wrote:
On Tue, Nov 17, 2020 at 01:05:20PM -0500, Marek Polacek via Gcc-patches wrote:
Our implementation of template lambdas incorrectly requires the optional
lambda-declarator. This was probably required by an early draft of
generic lambdas, but now the produ
On 11/17/20 1:05 PM, Marek Polacek wrote:
Our implementation of template lambdas incorrectly requires the optional
lambda-declarator. This was probably required by an early draft of
generic lambdas, but now the production is [expr.prim.lambda.general]:
lambda-expression:
lambda-introduce
On 11/19/20 8:21 PM, Marek Polacek wrote:
When I implemented the code to detect modifying const objects in
constexpr contexts, we couldn't have constexpr destructors, so I didn't
consider them. But now we can and that caused a bogus error in this
testcase: [class.dtor]p5 says that "const and vol
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't seem to work. A toolchain
configured without specifying arch/a
On 11/20/20 2:27 PM, Richard Sandiford wrote:
When adding the verify_type_context target hook, I'd missed
a site that needs to check an array element type.
Tested on aarch64-linux-gnu and x86_64-linux-gnu. OK for master
and GCC 10 branch?
OK.
Thanks,
Richard
gcc/cp/
PR c++/97904
On Fri, Nov 20, 2020 at 02:54:34PM -0700, Martin Sebor wrote:
> At the point the attribute is created there is no SAVE_EXPR. So for
> something like:
>
> int f (void);
> void g (int a[f () + 1]) { }
>
> the bound is a PLUS_EXPR (CALL_EXPR (f), 1).
>
> I don't do anything with the expression e
On 11/20/20 2:41 PM, Jakub Jelinek wrote:
On Fri, Nov 20, 2020 at 02:30:43PM -0700, Martin Sebor wrote:
VLA parameter bounds can involve any other expressions, including
function calls. It's those rather than other parameters that also
trigger the problem (at least in the test cases I've seen).
> On Nov 20, 2020, at 4:57 AM, Aaron Sawdey via Gcc-patches
> wrote:
>
>
>> On Nov 20, 2020, at 3:55 AM, Richard Sandiford
>> wrote:
>>
>> acsawdey--- via Gcc-patches writes:
>>> @@ -16767,7 +16768,7 @@ loc_descriptor (rtx rtl, machine_mode mode,
>>> break;
>>>
>>>case CONST_INT:
Here, since we only mention bar, we never emit debug information for it.
But we do emit debug information for H::h, so we need to refer to the
debug info for bar::J even though there is no bar. We deal with this
sort of thing in dwarf2out with the limbo_die_list; parentless dies like J
get attache
When checking for mismatches between the array forms of arguments
between the current and the new declaration of a function
warn_parm_array_mismatch() assumes that the new declaration is
valid and compatible with the current one. When that's not so
the function crashes with a null pointer derefer
On Fri, Nov 20, 2020 at 02:30:43PM -0700, Martin Sebor wrote:
> VLA parameter bounds can involve any other expressions, including
> function calls. It's those rather than other parameters that also
> trigger the problem (at least in the test cases I've seen).
>
> When/how would the unsharing caus
On 11/20/20 1:37 PM, Jakub Jelinek wrote:
On Fri, Nov 20, 2020 at 01:28:03PM -0700, Martin Sebor via Gcc-patches wrote:
On 11/20/20 12:29 PM, Marek Polacek wrote:
On Fri, Nov 20, 2020 at 12:00:58PM -0700, Martin Sebor via Gcc-patches wrote:
To detect a subset of VLA misuses, the C front associ
Check for the presence of _SC_NPROCESSORS_ONLN rather than using a list
of OS-specific macros to decide whether to use `sysconf' like elsewhere
across GCC sources, fixing a compilation error:
adaint.c: In function '__gnat_number_of_cpus':
adaint.c:2398:26: error: '_SC_NPROCESSORS_ONLN' undeclare
On Mon, 16 Nov 2020, Jeff Law wrote:
> > libgcc/
> > * unwind-dw2-fde-dip.c [__OpenBSD__ || __NetBSD__]
> > (USE_PT_GNU_EH_FRAME): Do not define if !TARGET_DL_ITERATE_PHDR.
> OK
Committed now, thank you for your review.
Maciej
On Wed, 18 Nov 2020, Eric Botcazou wrote:
> > that broke the build of an ada cross compiler targeting
> > powerpc64le-linux-gnu. target_cpu is powerpc64le which is not matched by
> > the Makefile logic.
> >
> > Ok for the trunk?
> >
> > PR ada/97859
> > * Makefile.rtl (powerpc% linux%):
Hi,
not sure if this is covered directly by my Darwin maintainer’s hat so …
-
On macOS / Darwin, the environ variable can be used directly in the
code of an executable, but cannot be used in the code of a shared
library (i.e. libgfortran.dylib)**
In such cases, the function _NSGetEnviron
On 11/18/20 4:36 PM, Jeff Law wrote:
On 11/18/20 3:41 PM, Martin Sebor via Gcc-patches wrote:
The access attribute handler doesn't check to make sure the mode
argument is an identifier and readily accepts string arguments
which are assumed to be the condensed internal representation
the user a
This patch to the Go frontend and libgo changes the name mangling
convention. The previous convention (which was actually the second
one) turned out to be ambiguous when the path to a package contained a
dot; this is a common case, as many package paths are of the form
"github.com/name/package".
On Fri, Nov 20, 2020 at 01:28:03PM -0700, Martin Sebor via Gcc-patches wrote:
> On 11/20/20 12:29 PM, Marek Polacek wrote:
> > On Fri, Nov 20, 2020 at 12:00:58PM -0700, Martin Sebor via Gcc-patches
> > wrote:
> > > To detect a subset of VLA misuses, the C front associates the bounds
> > > of VLAs
On 11/20/20 12:29 PM, Marek Polacek wrote:
On Fri, Nov 20, 2020 at 12:00:58PM -0700, Martin Sebor via Gcc-patches wrote:
To detect a subset of VLA misuses, the C front associates the bounds
of VLAs in function argument lists with the corresponding variables
by implicitly adding an instance of at
On 6/12/20 3:25 PM, Martin Jambor wrote:
> Hi,
>
> when Fortran functions pass array descriptors they receive as a
> parameter to another function, they actually rebuild it. Thanks to
> work done mainly by Feng, IPA-CP can already handle the cases when
> they pass directly the values loaded fro
Hi,
this is an updated patch based on our conversation on IRC today. So far
I have had a look at the effects on only tramp3d and although it makes
the heuristics more pessimistic more times than optimistic (number of
clones at -Ofast drops from 559 to 557), there are also lattices which
are massi
Hi,
another remaining case is that we end up comparing calls with mismatching
number of parameters or with different permutations of them.
This is because we hash decls to nothing. This patch improves that by
hashing decls by their code and parm decls by indexes that are stable.
Also for defualt d
On Fri, Nov 20, 2020 at 07:27:54PM +, Richard Sandiford via Gcc-patches
wrote:
> When adding the verify_type_context target hook, I'd missed
> a site that needs to check an array element type.
>
> Tested on aarch64-linux-gnu and x86_64-linux-gnu. OK for master
> and GCC 10 branch?
Not an ap
On Fri, Nov 20, 2020 at 12:00:58PM -0700, Martin Sebor via Gcc-patches wrote:
> To detect a subset of VLA misuses, the C front associates the bounds
> of VLAs in function argument lists with the corresponding variables
> by implicitly adding an instance of attribute access to each function
> declar
When adding the verify_type_context target hook, I'd missed
a site that needs to check an array element type.
Tested on aarch64-linux-gnu and x86_64-linux-gnu. OK for master
and GCC 10 branch?
Thanks,
Richard
gcc/cp/
PR c++/97904
* pt.c (tsubst): Use verify_type_context to chec
On Linux/x86_64,
fdace7584056de2f63bde2e3087f26beb6b0f97d is the first bad commit
commit fdace7584056de2f63bde2e3087f26beb6b0f97d
Author: Uros Bizjak
Date: Fri Nov 20 10:26:34 2020 +0100
i386: Optimize abs expansion [PR97873]
caused
FAIL: gcc.target/i386/pr97873-1.c scan-assembler pabsq
On 6/30/20 12:46 PM, Ilya Leoshkevich wrote:
> v1: https://gcc.gnu.org/pipermail/gcc-patches/2020-June/547236.html
>
> This is the implementation of Jakub's suggestion: allow
> __builtin_constant_p () after IPA, but fold it into 0. Smoke test
> passed on s390x-redhat-linux, full regtest and boo
Matthew Malcomson writes:
> Adding hwasan tests.
>
> Only interesting thing here is that we have to make sure the tagging mechanism
> is deterministic to avoid flaky tests.
Sorry for not reviewing this one earlier. TBH I only spot-checked
the tests themselves (they look good). But on hwasan-dg.
Hi!
As Peter remarked, the input_operand's in the disassemble patterns are
better as something more specific (input_operand has everything a "mov"
pattern can handle, but pretty much nothing else can on a load/store
architecture like Power -- it will likely still work, but only after
reloads, so n
To detect a subset of VLA misuses, the C front associates the bounds
of VLAs in function argument lists with the corresponding variables
by implicitly adding an instance of attribute access to each function
declared to take VLAs with the bound expressions chained on the list
of attribute arguments
Hi there,
I was just doing some double-checks and noticed I'd placed the
documentation in the wrong section of tm.texi. The `MEMTAG` hooks were
documented in the `Register Classes` section, so I've now moved it to
the `Misc` section.
That's the only change, Ok for trunk?
Matthew
-
Hi there,
I was just doing some double-checks and noticed I'd placed the
documentation in the wrong section of tm.texi. The `MEMTAG` hooks were
documented in the `Register Classes` section, so I've now moved it to
the `Misc` section.
That's the only change, Ok for trunk?
Matthew
---
On 13/11/2020 17:22, Martin Liška wrote:
On 11/13/20 5:57 PM, Matthew Malcomson wrote:
Hi there,
Thanks for the heads-up.
As it turns out the most recent `libhwasan` crashes when displaying an
address on the stack in Linux.
Hello.
What a bad luck.
I'm currently working on getting it fixe
On Fri, Nov 20, 2020 at 10:42:19AM -0500, Michael Meissner wrote:
> Power10: Add missing IEEE 128-bit XSCMP* built-in mappings.
Okay for trunk (and needed backports after waiting for possible
fallout). Thanks!
Segher
> 2020-11-18 Michael Meissner
>
> * config/rs6000/rs6000-call.c (r
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 attribute *dealloc). The function also prints
function arguments (and th
On 13/01/2020 10:40, Matthew Malcomson wrote:
On 11/01/2020 07:19, Gerald Pfeifer wrote:
On Thu, 12 Dec 2019, Matthew Malcomson wrote:
gcc/ChangeLog:
2019-12-12 Matthew Malcomson
* doc/install.texi: Document bootstrap-asan configuration option.
I see this introduces a new table.
Hi!
On Fri, Nov 20, 2020 at 04:22:47PM +0100, Jan Hubicka wrote:
> As you know I spend quite some time on inliner heuristics but even after
> the years I have no clear idea how the requirements differs from x86-64
> to ppc, arm and s390. Clearly compared to x86_64 prologues may get more
> expensi
Matthew Malcomson writes:
> @@ -7877,6 +7903,26 @@ gimple_build_vector (gimple_seq *seq, location_t loc,
>return builder->build ();
> }
>
> +/* Emit gimple statements into &stmts that take a value given in `old_size`
> + and generate a value guaranteed to be rounded upwards to `align`.
>
Updates after latest review.
(testing underway)
---
There are four main features to this change:
1) Check pointer tags match address tags.
When sanitizing for hwasan we now put HWASAN_CHECK internal functions before
memory accesses in the `asan` pass. This checks that a tag in
thanks for taking a look, I hope this is better -- I add a forward
reference from -fmodules-ts option description, so as to not have to
explain C++ terms of art just there :)
nathan
--
Nathan Sidwell
diff --git c/gcc/doc/cppopts.texi w/gcc/doc/cppopts.texi
index 7f1849d841f..e5ece92487b 100644
On Fri, Nov 20, 2020 at 10:19:55AM -0500, Nathan Sidwell wrote:
> Here is an update c++ modules documentation patch. I'd be grateful for
> review. Especially checking I'm not using too much implementor-speak
>
> nathan
> --
> Nathan Sidwell
> diff --git c/gcc/doc/cppopts.texi w/gcc/doc/cppopts
Hello
New OpenMP 5.0 features that won't be available in GCC 9, are planned for GCC 10
or later versions as time permits:
...
- nested declare target support
You said in an email two years ago that nested declare target was not supported
yet. I do not see any patches that claim to implemen
On Mon, Nov 16, 2020 at 01:50:20PM -0500, Paul Koning wrote:
> > On Nov 16, 2020, at 6:57 AM, Jakub Jelinek via Gcc-patches
> > wrote:
> > Working virtually out of Baker Island - AoE timezone.
> >
> > The following patch implements __builtin_clear_padding builtin that clears
> > the padding bits
On 20/11/2020 16:25, Martin Liška wrote:
Apart from these 2 hooks, I bet you will also need gcov_position and
gcov_seek functions,
can be seen in my sent patch.
For what do I need them?
I prefer the way with the 2 extra hooks.
Can you please prepare a patch where the newly added functions
On 11/19/20 10:56 PM, sunil.k.pandey wrote:
On Linux/x86_64,
d0d8b5d83614d8f0d0e40c0520d4f40ffa01f8d9 is the first bad commit
commit d0d8b5d83614d8f0d0e40c0520d4f40ffa01f8d9
Author: Andrew MacLeod
Date: Thu Nov 19 17:41:30 2020 -0500
Process only valid shift ranges.
caused
FAIL: gcc.d
Power10: Add missing IEEE 128-bit XSCMP* built-in mappings.
This patch is a simplification of earlier patches to fix the built-in functions
that introduced new power10 IEEE 128-bit instructions. Some of the built-in
functions were already handled, but the scalar_cmp_exp_qp_gt, etc. functions
were
Kyrylo Tkachov writes:
>> -Original Message-
>> From: Andrea Corallo
>> Sent: 09 November 2020 18:24
>> To: gcc-patches@gcc.gnu.org
>> Cc: Kyrylo Tkachov ; Richard Earnshaw
>> ; nd ;
>> christophe.l...@linaro.org
>> Subject: [PATCH] [PR target/97727] aarch64: [testcase] fix
>> bf16_vstN_
On Fri, 20 Nov 2020, Eric Botcazou wrote:
> > gcc/
> > PR target/58901
> > * reload.c (reload_inner_reg_of_subreg): Also request reloading
> > for pseudo registers associated with mode dependent memory
> > references.
> > (push_reload): Handle pseudo registers.
>
> The han
On 11/20/20 11:11 AM, Sebastian Huber wrote:
On 20/11/2020 10:49, Martin Liška wrote:
On 11/20/20 10:25 AM, Sebastian Huber wrote:
On 20/11/2020 09:37, Martin Liška wrote:
On 11/17/20 10:57 AM, Sebastian Huber wrote:
This is a proposal to get the gcda data for a gcda info in a free-standing
> On Thu, Nov 19, 2020 at 03:30:37PM -0700, Jeff Law wrote:
> > > No, the vast majority of people will *not* (consciously) use them,
> > > because the target defaults will set things to useful values.
> > >
> > > The compiler could use saner "generic" defaults perhaps, but those will
> > > still no
Here is an update c++ modules documentation patch. I'd be grateful for
review. Especially checking I'm not using too much implementor-speak
nathan
--
Nathan Sidwell
diff --git c/gcc/doc/cppopts.texi w/gcc/doc/cppopts.texi
index 7f1849d841f..e5ece92487b 100644
--- c/gcc/doc/cppopts.texi
+++ w/g
> -Original Message-
> From: Andrea Corallo
> Sent: 09 November 2020 18:24
> To: gcc-patches@gcc.gnu.org
> Cc: Kyrylo Tkachov ; Richard Earnshaw
> ; nd ;
> christophe.l...@linaro.org
> Subject: [PATCH] [PR target/97727] aarch64: [testcase] fix
> bf16_vstN_lane_2.c for big endian targets
I noticed a couple of places we used @code{program} instead of
@command{program}.
gcc/
* doc/invoke.texi: Replace a couple of @code with @command
pushing to trunk
--
Nathan Sidwell
diff --git c/gcc/doc/invoke.texi w/gcc/doc/invoke.texi
index 07232c6b33d..29ae36861ad 100644
--- c
Kyrylo Tkachov writes:
>> -Original Message-
>> From: Andrea Corallo
>> Sent: 16 November 2020 16:11
>> To: Andrea Corallo via Gcc-patches
>> Cc: nd ; Richard Earnshaw ;
>> Kyrylo Tkachov
>> Subject: [PATCH] [PR target/97726] arm: [testsuite] fix some simd tests on
>> armbe
>>
>> Andr
On Fri, Nov 20, 2020 at 2:48 AM Richard Biener
wrote:
>
> On Fri, Nov 20, 2020 at 12:58 AM Segher Boessenkool
> wrote:
> >
> > On Thu, Nov 19, 2020 at 03:30:37PM -0700, Jeff Law wrote:
> > > > No, the vast majority of people will *not* (consciously) use them,
> > > > because the target defaults w
On Fri, Nov 20, 2020 at 9:57 AM Martin Liška wrote:
>
> On 11/19/20 3:46 PM, Richard Biener wrote:
> > OK, so can you send an updated patch?
+ tree pos_one = build_int_cst (type, 1);
+ if (!left->m_has_forward_bb
+ && !right->m_has_forward_bb
+ && left->m_case_bb == righ
1 - 100 of 137 matches
Mail list logo
