- Unfortunately using_auto_storage () needs to handle m_vec being null.
- Handle self move of an auto_vec to itself.
- punt on defining copy or move operators for auto_vec with inline storage,
until there is a need for them and we can decide what semantics they should
have.
- Make sure auto_vec
On Linux/x86_64,
d9f1466f88abef7c814d02ba39a6ea5ef420aaec is the first bad commit
commit d9f1466f88abef7c814d02ba39a6ea5ef420aaec
Author: Martin Sebor
Date: Mon Jun 14 16:34:48 2021 -0600
Teach compute_objsize about placement new [PR100876].
caused
FAIL:
On 6/14/21 4:04 PM, Richard Biener wrote:
The same issue that arises in PR100934 can happen in the backward
threader now (Aldy?) - we eventually run into mark_irreducible_loops
for non-FSM thread paths checking for paths crossing irreducible
region boundaries.
I haven't been following the
On 2021-06-14 17:16, Jan Hubicka wrote:
On 5/6/2021 8:36 PM, guojiufu via Gcc-patches wrote:
> Gentle ping.
>
> Original message:
> https://gcc.gnu.org/pipermail/gcc-patches/2020-October/555871.html
I think you need a more aggressive ping :-)
OK for the trunk. Sorry for the long delay. I
The x86_64 psABI says that an empty class isn't passed or returned in memory or
registers, so we shouldn't set %eax in this function. Is this a reasonable
place to implement that? Another possibility would be to remove the hack to
prevent i386.c:function_value_64 from returning NULL in this case
Ping: https://gcc.gnu.org/pipermail/gcc-patches/2021-June/571971.html
I got the go ahead to commit the Ada and Objective-C subset (patches
2 and 11). Most of the rest of the patches are mechanical replacements
and so nearly obvious but I'm still looking for a review/approval of
the warning
On 6/14/21 10:25 AM, Jonathan Wakely via Gcc-patches wrote:
I think this is an improvement on the current structure of the docs,
but I'd like to hear what others think.
The text looks more detailed and arguably more accurate but also
makes it sound more complicated and rigid than necessary.
On 6/14/21 4:29 PM, Giuliano Belinassi wrote:
Hi,
I will give an quick answer to this mail. I will analyze carefully what
richi said when I have more time available.
On Mon, 2021-06-14 at 15:55 -0600, Martin Sebor wrote:
On 6/13/21 11:00 AM, Giuliano Belinassi wrote:
This patch proposes a
Hi all!
Update to a proposed patch to:
Bug 93308 - bind(c) subroutine changes lower bound of array argument in
caller
Bug 93963 - Select rank mishandling allocatable and pointer arguments
with bind(c)
Bug 94327 - Bind(c) argument attributes are incorrectly set
Bug 94331 - Bind(C) corrupts
On 6/2/21 3:46 PM, Marek Polacek wrote:
On Wed, Jun 02, 2021 at 03:40:49PM -0600, Martin Sebor via Gcc-patches wrote:
+ if (!gimple_call_builtin_p (stmt, BUILT_IN_NORMAL))
+{
+ /* See if this is a call to placement new. */
+ if (!fn
+ || !DECL_IS_OPERATOR_NEW_P (fn)
+
On 6/13/21 5:45 PM, Jeff Law wrote:
On 6/2/2021 3:40 PM, Martin Sebor via Gcc-patches wrote:
The two forms of placement operator new defined in return their
pointer argument and may not be displaced by user-defined functions.
But because they are ordinary (not built-in) functions this
Hi all!
Proposed patch to:
Bug 94104 - Request for diagnostic improvement
Patch tested only on x86_64-pc-linux-gnu.
Error message improvement. In Fortran 2008 actual arguments to
procedures having a pointer, with intent attribute in, formal argument
can also have the target attribute not
Hi,
I will give an quick answer to this mail. I will analyze carefully what
richi said when I have more time available.
On Mon, 2021-06-14 at 15:55 -0600, Martin Sebor wrote:
> On 6/13/21 11:00 AM, Giuliano Belinassi wrote:
> > This patch proposes a fix to PR 100944 by improving the array
> >
Signed-off-by: Jonathan Wakely
libstdc++-v3/ChangeLog:
* include/bits/ranges_base.h (ranges::empty): Check whether
conversion to bool can throw.
* testsuite/std/ranges/access/empty.cc: Check for correct
noexcept-specifier.
Tested powerpc64le-linux. Committed to
On 6/14/21 12:08 PM, Jakub Jelinek wrote:
> On Wed, May 26, 2021 at 04:16:31PM -0500, Peter Bergner via Gcc-patches wrote:
>> Using an MMA builtin within an openmp parallel code block leads to an SSA
>> verification ICE on the temporaries we create while expanding the MMA
>> builtins
>> at gimple
On 6/13/21 11:00 AM, Giuliano Belinassi wrote:
This patch proposes a fix to PR 100944 by improving the array boundary
Thanks for the patch!
computation when the flexible array has no clear constructor: if no
constructor were found in the input code, we compute the size of the
array as:
Hi!
On Mon, Jun 14, 2021 at 01:50:57PM -0700, Carl Love wrote:
> The following patch removes some unused BU_P10_OVERLOAD_2 entries.
> Also, it fixes the builtin definition to use the altivec_eqv1ti
> instruction definition for the compare instruction.
> BU_P10V_AV_2 (VCMPGTUT,
As mentioned in the Text from the PR:
"When a range is being calculated for an ssa-name, the propagation
process often goes along back edges. These back edges sometime require
other ssa-names which have not be processed yet. These are flagged as
"poor values" and when propagation is done, we
GCC Maintainers:
The following patch removes some unused BU_P10_OVERLOAD_2 entries.
Also, it fixes the builtin definition to use the altivec_eqv1ti
instruction definition for the compare instruction.
The patch has been tested on powerpc64le-linux (Power 10 LE)
Please let me know if the patch
On Mon, Jun 14, 2021 at 09:56:12AM +0200, Gerald Pfeifer wrote:
> On Sun, 13 Jun 2021, Dimitar Dimitrov wrote:
> >> TI's server has been telling us that "The PRU-ICSS wiki is in the
> >> process of being migrated to software-dl.ti.com" for five months.
> >> Time to pull the plug.
> > Could you
The result of COMMON-REF(A&, B&&) where they have no common reference
type should not be a reference. The implementation of COMMON-REF fails
to check that the result is a reference, so is well-formed when it
shouldn't be. This means that common_reference uses that result when it
shouldn't.
The
V2HImode *punpckwd should not be split to the insn that depends on
TARGET_MMX_WITH_SSE, since the later is disabled on 32bit targets.
Also return true early from ix86_vectorize_vec_perm_const when testing
with V2HI mode. *punpckwd can be used to implement all permutations.
2021-06-14 Uroš
std::tuple elements are retrieved via std::get<> (template) not
[] (array); have the generated output string match this.
libstdc++-v3/ChangeLog:
* python/libstdcxx/v6/printers.py (StdTuplePrinter): Use <> not [].
---
The previous patch seems uncontroversial to me. I don't know about
Show 0-based offsets for std::tuple members, to match with std::get.
libstdc++-v3/ChangeLog:
* python/libstdcxx/v6/printers.py (StdTuplePrinter): don't increment
self.count until after generating the result string.
---
libstdc++-v3/python/libstdcxx/v6/printers.py | 13
On Mon, 2021-06-14 at 13:17 +0100, Jonathan Wakely wrote:
> PR c++/101052
>
> gcc/c-family/ChangeLog:
>
> * known-headers.cc (get_stdlib_header_for_name): Add known
> headers for EXIT_FAILURE, EXIT_SUCCESS, abort, atexit,
> calloc,
> exit, and getenv.
>
>
On 6/14/21 12:36 AM, Richard Biener via Gcc-patches wrote:
On Sun, Jun 13, 2021 at 7:00 PM Giuliano Belinassi via Gcc-patches
wrote:
This patch proposes a fix to PR 100944 by improving the array boundary
computation when the flexible array has no clear constructor: if no
constructor were
On Thu, May 20, 2021 at 08:37:24PM +0200, Stefan Schulze Frielinghaus wrote:
[...]
> > but we won't ever arrive here because of the niters condition. But
> > yes, doing the pattern matching in the innermost loop processing code
> > looks good to me - for the specific case it would be
> >
> >
Hi Gerald:
Thanks your patch, my grammar is really...weak :p
Hi Bernhard:
>> + Add new option -misa-spec=* to control ISA spec version.
>> + This controls the default version of each extensions.
>> + It defaults to 2.2.
> Is "each extensions" in plural really correct gramatically?
>
On Mon, 14 Jun 2021 at 18:03, Martin Sebor wrote:
>
> On 6/14/21 6:17 AM, Jonathan Wakely via Gcc-patches wrote:
> > PR c++/101052
> >
> > gcc/c-family/ChangeLog:
> >
> > * known-headers.cc (get_stdlib_header_for_name): Add known
> > headers for EXIT_FAILURE, EXIT_SUCCESS,
On Mon, Jun 14, 2021 at 01:17:10PM +0100, Jonathan Wakely via Gcc-patches wrote:
> commit 8f211596b34662f4b9a041fdf8634f69cf8efe4c
> Author: Jonathan Wakely
> Date: Mon Jun 14 11:38:11 2021
>
> c-family: Add fix-it suggestions for names [PR101052]
>
> PR c++/101052
>
On Wed, May 26, 2021 at 04:16:31PM -0500, Peter Bergner via Gcc-patches wrote:
> Using an MMA builtin within an openmp parallel code block leads to an SSA
> verification ICE on the temporaries we create while expanding the MMA builtins
> at gimple time. The solution is to use
I'd like to ping the following patch:
https://patchwork.ozlabs.org/project/gcc/patch/f96c751e-b534-e49c-d3ec-2b3567798...@linux.ibm.com/
Peter
On 6/14/21 6:17 AM, Jonathan Wakely via Gcc-patches wrote:
PR c++/101052
gcc/c-family/ChangeLog:
* known-headers.cc (get_stdlib_header_for_name): Add known
headers for EXIT_FAILURE, EXIT_SUCCESS, abort, atexit, calloc,
exit, and getenv.
gcc/testsuite/ChangeLog:
On Mon, 14 Jun 2021 at 18:01, Richard Sandiford
wrote:
>
> Christophe Lyon writes:
> > On Fri, 11 Jun 2021 at 18:25, Richard Sandiford
> > wrote:
> >>
> >> Christophe Lyon writes:
> >> > Thanks for the feedback. How about v2 attached?
> >> > Do you want me to merge neon_vec_unpack and
> >> >
The _S_has_simple_extra_args mechanism is used to simplify forwarding
of range adaptor's extra arguments when perfect forwarding call wrapper
semantics isn't required for correctness, on a per-adaptor basis.
Both views::take and views::drop are flagged as such, but it turns out
perfect forwarding
I think this is an improvement on the current structure of the docs,
but I'd like to hear what others think.
We don't currently say document anything about commit format for the
wwwdocs repo. Should the "wwwdocs" be a classifier (as in this email)
or a component tag?
commit
On Wed, Jun 09, 2021 at 02:18:43PM +0200, Tobias Burnus wrote:
> This patch add's OpenMP 5.1's defaultmap extensions to Fortran.
>
> There is one odd thing,
> integer :: ii, it
> target :: it
> both count as nonallocatable, nonpointer scalars (i.e. category 'scalar').
> But with implicit
Hi all!
Update to a proposed patch to:
PR100683 - Array initialization refuses valid
due to errors found by Dominique d'Humieres.
Patch tested only on x86_64-pc-linux-gnu.
Add call to simplify expression before parsing *and* check if the
expression is still an array after simplification.
Hi, Richard:
On Jun 11, 2021, at 10:49 AM, Qing Zhao via Gcc-patches
mailto:gcc-patches@gcc.gnu.org>> wrote:
On May 26, 2021, at 6:18 AM, Richard Biener
mailto:rguent...@suse.de>> wrote:
+/* Expand the IFN_DEFERRED_INIT function according to its second
argument. */
+static void
Christophe Lyon writes:
> On Fri, 11 Jun 2021 at 18:25, Richard Sandiford
> wrote:
>>
>> Christophe Lyon writes:
>> > Thanks for the feedback. How about v2 attached?
>> > Do you want me to merge neon_vec_unpack and
>> > mve_vec_unpack and only have different assembly?
>> > if (TARGET_HAVE_MVE)
Tamar Christina writes:
> Hi Richard,
>> -Original Message-
>> From: Richard Sandiford
>> Sent: Monday, June 14, 2021 3:50 PM
>> To: Tamar Christina
>> Cc: gcc-patches@gcc.gnu.org; nd ; Richard Earnshaw
>> ; Marcus Shawcroft
>> ; Kyrylo Tkachov
>> Subject: Re: [PATCH][RFC]AArch64 SVE:
*PING*
Forwarded Message
Subject: [Patch, fortran v2] PR fortran/92621 Problems with memory
handling with allocatable intent(out) arrays with bind(c)
Date: Mon, 26 Apr 2021 11:21:25 +
From: José Rui Faustino de Sousa
To: fort...@gcc.gnu.org, gcc-patches@gcc.gnu.org
Hi
On Mon, 14 Jun 2021 13:36:54 +0100
Julian Brown wrote:
> On Wed, 9 Jun 2021 16:47:21 +0200
> Marcel Vollweiler wrote:
> > In this patch a compatibility check is added to the configure.ac.
>
> The implementation of the solution looks fine, but I worry it's the
> wrong approach. What would
ping
> [Changes from V8:
> - Rebased to today's master.
> - Adapted to use the write-symbols new infrastructure recently
> applied upstream.
> - Little change in libiberty to copy .BTF sections over when
> LTOing.]
>
> Hi people!
>
> Last year we submitted a first patch series introducing
On Mon, 2021-03-08 at 11:04 -0700, Philip Herron wrote:
"Extract a common logger from the analyzer framework", surely?
> In development of the Rust FE logging is useful in debugging. Instead
> of
> rolling our own logger it became clear the loggers part of analyzer
Hi Richard,
> -Original Message-
> From: Richard Sandiford
> Sent: Monday, June 14, 2021 3:50 PM
> To: Tamar Christina
> Cc: gcc-patches@gcc.gnu.org; nd ; Richard Earnshaw
> ; Marcus Shawcroft
> ; Kyrylo Tkachov
> Subject: Re: [PATCH][RFC]AArch64 SVE: Fix multiple comparison masks on
>
Tamar Christina writes:
> Hi All,
>
> This RFC is trying to address the following inefficiency when vectorizing
> conditional statements with SVE.
>
> Consider the case
>
> void f10(double * restrict z, double * restrict w, double * restrict x,
>double * restrict y, int n)
> {
> for
Hi Richard,
I have all addressed all your review comments (in [1]) in the below patch.
On passing +cdecp[0-7] extension to the -march string in command line options,
multilib linking is failing as mentioned in PR100856. This patch fixes this
issue by
generating a separate canonical string by
On Fri, 11 Jun 2021 at 18:25, Richard Sandiford
wrote:
>
> Christophe Lyon writes:
> > Thanks for the feedback. How about v2 attached?
> > Do you want me to merge neon_vec_unpack and
> > mve_vec_unpack and only have different assembly?
> > if (TARGET_HAVE_MVE)
> > return "vmovlb.%# %q0, %q1";
On 14/06/2021 13:36, Julian Brown wrote:
On Wed, 9 Jun 2021 16:47:21 +0200
Marcel Vollweiler wrote:
This patch fixes an issue with global_load assembler functions leading
to a "invalid operand for instruction" error since in different LLVM
versions those functions use either one or two
On Mon, 14 Jun 2021 at 13:58, Christophe Lyon
wrote:
>
> Hi Jonathan,
>
> On Fri, 11 Jun 2021 at 20:25, Jonathan Wakely via Gcc-patches
> wrote:
> >
> > In C++23 there is a basic_string_view(Range&&) constructor, which is
> > constrained to take a range (specifically, a contiguous_range). When
This is a patch to fix BUG 87162 by returning false if cfg is null.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87162
diff --git a/gcc/trans-mem.c b/gcc/trans-mem.c
index 1d4eb80620295..326e1c412465b 100644
--- a/gcc/trans-mem.c
+++ b/gcc/trans-mem.c
@@ -2099,6 +2099,9 @@ gate_tm_init (void)
PR libstdc++/101034
* include/std/any (any(in_place_t, initializer_list, A&&...))
(any::emplace(initializer_list, A&&...)): Fix constraint
to use lvalue.
* testsuite/20_util/any/cons/101034.cc: New test.
Tested powerpc64le-linux. Committed to trunk.
commit
diff --git a/gcc/testsuite/c-c++-common/attr-fallthrough-2.c
b/gcc/testsuite/c-c++-common/attr-fallthrough-2.c
index e8659e572ca6d..1f3ca4ac37acf 100644
--- a/gcc/testsuite/c-c++-common/attr-fallthrough-2.c
+++ b/gcc/testsuite/c-c++-common/attr-fallthrough-2.c
@@ -48,6 +48,13 @@ fn (int i)
case
The same issue that arises in PR100934 can happen in the backward
threader now (Aldy?) - we eventually run into mark_irreducible_loops
for non-FSM thread paths checking for paths crossing irreducible
region boundaries.
The following thus initializes irreducible regions and makes
irreducible
Hi All,
This RFC is trying to address the following inefficiency when vectorizing
conditional statements with SVE.
Consider the case
void f10(double * restrict z, double * restrict w, double * restrict x,
double * restrict y, int n)
{
for (int i = 0; i < n; i++) {
z[i] =
Pushed as obvious.
Martin
gcc/ChangeLog:
* doc/invoke.texi: Remove '+' charasters.
---
gcc/doc/invoke.texi | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/gcc/doc/invoke.texi b/gcc/doc/invoke.texi
index 90a50ea48aa..a62c2d22521 100644
--- a/gcc/doc/invoke.texi
On 14.06.21 14:36, Julian Brown wrote:
On Wed, 9 Jun 2021 16:47:21 +0200
Marcel Vollweiler wrote:
This patch fixes an issue with global_load assembler functions leading
to a "invalid operand for instruction" error since in different LLVM
versions those functions use either one or two
The jump threading code requires marked irreducible regions for the
purpose of validating jump threading paths but DOM fails to provide
that resulting in mised number of iteration upper bounds clearing.
Bootstrap / regtest running on x86_64-unknown-linux-gnu.
2021-06-14 Richard Biener
PR libstdc++/101056
* libsupc++/compare (compare_partial_order_fallback): Add
constraint using reversed parameter order, as per LWG 3465.
* testsuite/18_support/comparisons/algorithms/fallback.cc:
Adjust expected result.
Tested powerpc64le-linux. Committed
This moves the same_as, decay_t<_Up>> checks from the
[cmp.alg] function bodies into their constraints.
Also add a test for the compare_xxx_order_fallback algorithms.
libstdc++-v3/ChangeLog:
* libsupc++/compare (__decayed_same_as): New helper concept.
(strong_order, weak_order,
On 14/06/21 11:54 +0100, Jonathan Wakely wrote:
The no_unique_address attribute is not a reserved name until C++20, so
to use it in C++11/14/17 modes we should use the __no_unique_address_
form. We already use that form when using the attribute, but not in the
__has_cpp_attribute check.
Hi Jonathan,
On Fri, 11 Jun 2021 at 20:25, Jonathan Wakely via Gcc-patches
wrote:
>
> In C++23 there is a basic_string_view(Range&&) constructor, which is
> constrained to take a range (specifically, a contiguous_range). When the
> filesystem::path comparison operators call lhs.compare(rhs) the
Found this odd code. It starts fine with:
gfc_ref *ref = gfc_get_ref ();
this uses XCNEW to return nullified memory.
We then operate on
ref->u.ar
where 'ar' is a struct which is in a 'u'nion which is in gfc_ref.
Hence, 'ref->u.ar' is not a pointer. Hence, the following is a
wasteful way to
On Wed, 9 Jun 2021 16:47:21 +0200
Marcel Vollweiler wrote:
> This patch fixes an issue with global_load assembler functions leading
> to a "invalid operand for instruction" error since in different LLVM
> versions those functions use either one or two registers.
LLVM is neither forward- nor
On Mon, Jun 14, 2021 at 02:34:53PM +0200, Tobias Burnus wrote:
> Rather obvious fix for a warning found by David via cppcheck.
>
> OK?
>
> Tobias
>
> -
> Mentor Graphics (Deutschland) GmbH, Arnulfstrasse 201, 80634 München
> Registergericht München HRB 106955, Geschäftsführer:
Thanks a lot guys. Patch is pushed.
//Claudiu
On Mon, Jun 14, 2021 at 12:34 AM Jeff Law wrote:
>
>
>
> On 6/13/2021 4:06 AM, Bernhard Reutner-Fischer wrote:
> > On Fri, 11 Jun 2021 14:25:24 +0300
> > Claudiu Zissulescu wrote:
> >
> >> Hi Bernhard,
> >>
> >> Please find attached my latest
Rather obvious fix for a warning found by David via cppcheck.
OK?
Tobias
-
Mentor Graphics (Deutschland) GmbH, Arnulfstrasse 201, 80634 München
Registergericht München HRB 106955, Geschäftsführer: Thomas Heurung, Frank
Thürauf
C/C++: Fix unused set var warning with
PR c++/101052
gcc/c-family/ChangeLog:
* known-headers.cc (get_stdlib_header_for_name): Add known
headers for EXIT_FAILURE, EXIT_SUCCESS, abort, atexit, calloc,
exit, and getenv.
gcc/testsuite/ChangeLog:
* g++.dg/spellcheck-stdlib.C: Add checks for
Hi,
Just adding 7 more tests, I will assume the OK still stands as it's more of the
same.
Thanks,
Tamar
> -Original Message-
> From: Richard Biener
> Sent: Wednesday, May 26, 2021 9:41 AM
> To: Tamar Christina
> Cc: nd
> Subject: RE: [PATCH 4/4]middle-end: Add tests middle end
Hi Richard,
I've attached a new version of the patch with the changes.
I have also added 7 new tests in the testsuite to check the cases you mentioned.
Bootstrapped Regtested on aarch64-none-linux-gnu and no issues.
Ok for master?
Thanks,
Tamar
gcc/ChangeLog:
* optabs.def
Ughhh.
I just fixed one exactly like this in ssa_equiv_stack. I used an
auto_vec instead of new/delete, which unbeknownst to me uses slightly
different nomenclature for arrays. Either way works fine.
Thanks for fixing this.
Aldy
On Mon, Jun 14, 2021 at 10:24 AM Martin Liška wrote:
>
>
On Mon, 14 Jun 2021, Richard Biener wrote:
> On Mon, 14 Jun 2021, Andre Vieira (lists) wrote:
>
> > Hi,
> >
> >
> > On 20/05/2021 11:22, Richard Biener wrote:
> > > On Mon, 17 May 2021, Andre Vieira (lists) wrote:
> > >
> > >> Hi,
> > >>
> > >> So this is my second attempt at finding a way to
The no_unique_address attribute is not a reserved name until C++20, so
to use it in C++11/14/17 modes we should use the __no_unique_address_
form. We already use that form when using the attribute, but not in the
__has_cpp_attribute check.
libstdc++-v3/ChangeLog:
PR libstdc++/101055
> -Original Message-
> From: Prathamesh Kulkarni
> Sent: 14 June 2021 08:59
> To: gcc Patches ; Kyrylo Tkachov
>
> Subject: Re: [ARM NEON] PR66791: Replace builtins in vceq_* (a, b) with a ==
> b.
>
> On Wed, 9 Jun 2021 at 14:49, Prathamesh Kulkarni
> wrote:
> >
> > Hi,
> > The
> -Original Message-
> From: Prathamesh Kulkarni
> Sent: 14 June 2021 08:58
> To: gcc Patches ; Kyrylo Tkachov
>
> Subject: Re: [ARM] PR97906 - Missed lowering abs(a) >= abs(b) to vacge
>
> On Mon, 7 Jun 2021 at 12:46, Prathamesh Kulkarni
> wrote:
> >
> > On Tue, 1 Jun 2021 at 16:03,
Hi,
This patch fixes the issue mentioned in PR101016, which is mve polymorphic
variants
failing at linking with undefined reference to "__ARM_undef" error.
Regression tested on arm-none-eabi and found no regressions.
This patch have cleanly applied, ok for the GCC-10 branch?
Regards,
Srinath.
Hi,
This patch fixes the issue mentioned in PR101016, which is mve polymorphic
variants
failing at linking with undefined reference to "__ARM_undef" error.
Regression tested on arm-none-eabi and found no regressions.
This patch have cleanly applied, ok for the GCC-11 branch?
gcc/ChangeLog:
Hi,
The current CMSE support in the multilib build for
"-march=armv8.1-m.main+mve -mfloat-abi=hard -mfpu=auto" is broken
as specified in PR99939 and this patch fixes the issue.
Regression tested on arm-none-eabi and found no regressions.
This patch have cleanly applied, ok for the GCC-10
Hi,
The current CMSE support in the multilib build for
"-march=armv8.1-m.main+mve -mfloat-abi=hard -mfpu=auto" is broken
as specified in PR99939 and this patch fixes the issue.
Regression tested on arm-none-eabi and found no regressions.
This patch have cleanly applied, ok for the GCC-11
>
>
> On 5/6/2021 8:36 PM, guojiufu via Gcc-patches wrote:
> > Gentle ping.
> >
> > Original message:
> > https://gcc.gnu.org/pipermail/gcc-patches/2020-October/555871.html
> I think you need a more aggressive ping :-)
>
> OK for the trunk. Sorry for the long delay. I kept hoping someone
On Sun, 13 Jun 2021 at 06:51, Tobias Burnus wrote:
>
> On 11.06.21 09:43, Martin Liška wrote:
> > I support the patch, please install it (except the not intentional change
> > in gcc/c/c-parser.c).
> Committed as r12-1408-gd554f43c98eb07f222afef5e90b5582d65519f7e
> > Then, please ask Jonathan for
On Mon, 14 Jun 2021, Andre Vieira (lists) wrote:
> Hi,
>
>
> On 20/05/2021 11:22, Richard Biener wrote:
> > On Mon, 17 May 2021, Andre Vieira (lists) wrote:
> >
> >> Hi,
> >>
> >> So this is my second attempt at finding a way to improve how we generate
> >> the
> >> vector IV's and teach the
Pushed as obvious.
Martin
The fixed error is:
==21166==ERROR: AddressSanitizer: alloc-dealloc-mismatch (operator new [] vs
operator delete) on 0x6030d900
#0 0x7367d7 in operator delete(void*, unsigned long)
Hi,
On 20/05/2021 11:22, Richard Biener wrote:
On Mon, 17 May 2021, Andre Vieira (lists) wrote:
Hi,
So this is my second attempt at finding a way to improve how we generate the
vector IV's and teach the vectorizer to share them between main loop and
epilogues. On IRC we discussed my idea to
On Wed, 9 Jun 2021 at 15:58, Prathamesh Kulkarni
wrote:
>
> On Fri, 4 Jun 2021 at 13:15, Christophe Lyon
> wrote:
> >
> > On Fri, 4 Jun 2021 at 09:27, Prathamesh Kulkarni via Gcc-patches
> > wrote:
> > >
> > > Hi,
> > > As mentioned in PR, for the following test-case:
> > >
> > > #include
> >
On Wed, 9 Jun 2021 at 14:49, Prathamesh Kulkarni
wrote:
>
> Hi,
> The attached patch replaces calls to _builtin_neon_vceq (a, b) with a
> == b
> for integral variants, and for fp variants it gates the equality
> comparison on __FAST_MATH__ because for fp variants a == b results in
> much longer
On Mon, Jun 14, 2021 at 09:47:18AM +0200, Richard Biener wrote:
> strlen opt uses ao_ref_init_from_ptr_and_size to prepare alias
> queries to invalidate its knowledge about strings. It constrains
> the size using the number of known-nonzero chars and adds one
> for a terminating nul - without
On Mon, 7 Jun 2021 at 12:46, Prathamesh Kulkarni
wrote:
>
> On Tue, 1 Jun 2021 at 16:03, Prathamesh Kulkarni
> wrote:
> >
> > Hi,
> > As mentioned in PR, for following test-case:
> >
> > #include
> >
> > uint32x2_t f1(float32x2_t a, float32x2_t b)
> > {
> > return vabs_f32 (a) >= vabs_f32
On Mon, 7 Jun 2021 at 12:45, Prathamesh Kulkarni
wrote:
>
> On Mon, 31 May 2021 at 16:01, Prathamesh Kulkarni
> wrote:
> >
> > On Mon, 31 May 2021 at 15:22, Prathamesh Kulkarni
> > wrote:
> > >
> > > On Wed, 26 May 2021 at 14:07, Marc Glisse wrote:
> > > >
> > > > On Wed, 26 May 2021,
On Sun, 13 Jun 2021, Dimitar Dimitrov wrote:
>> TI's server has been telling us that "The PRU-ICSS wiki is in the
>> process of being migrated to software-dl.ti.com" for five months.
>> Time to pull the plug.
> Could you please consider the following replacement?
>
strlen opt uses ao_ref_init_from_ptr_and_size to prepare alias
queries to invalidate its knowledge about strings. It constrains
the size using the number of known-nonzero chars and adds one
for a terminating nul - without knowing whether such nul exists
or even fits the object. The latter is now
On Sun, 13 Jun 2021, Bernhard Reutner-Fischer wrote:
>> + Add new option -misa-spec=* to control ISA spec version.
>> + This controls the default version of each extensions.
>> + It defaults to 2.2.
> Is "each extensions" in plural really correct gramatically?
> "default version of
On Sun, Jun 13, 2021 at 7:00 PM Giuliano Belinassi via Gcc-patches
wrote:
>
> This patch proposes a fix to PR 100944 by improving the array boundary
> computation when the flexible array has no clear constructor: if no
> constructor were found in the input code, we compute the size of the
> array
On 14 June 2021 07:56:38 CEST, Bernhard Reutner-Fischer
wrote:
>On 14 June 2021 01:45:36 CEST, Jeff Law via Gcc-patches
> wrote:
>>
>>
>>On 6/2/2021 3:40 PM, Martin Sebor via Gcc-patches wrote:
>>> The two forms of placement operator new defined in return
>their
>>> pointer argument and may not
95 matches
Mail list logo
