[PATCH, V5] PowerPC Turn on -mpcrel by default for -mcpu=future

Turn on -mpcrel by default for -mcpu=future I reworked the patches based on your comments: 1) I removed the check for 64-bit; 2) I now set the prefixed and PC-relative bits on by default; 3) I removed the #if around the test, and provided a definition earlier; 5) I removed the #undef in

[PATCH v2] aarch64: Add TX3 machine model

I just joined the gcc-patches list, so I hope the mail software can parse this out with an "In-Reply-To" header. I work for Marvell, and Anton's work is approved for submittal. I wrote the first version of the .md file. I'm certain we have a copyright assignment.in place, as we've had

[PATCH] free() was missing from a part of the documentation

Hello, The free() function was missing from a part of the documentation! diff --git a/gcc/doc/extend.texi b/gcc/doc/extend.texi index 81bb7a47de2..c17b1040bde 100644 --- a/gcc/doc/extend.texi +++ b/gcc/doc/extend.texi @@ -12315,6 +12315,7 @@ is called and the @var{flag} argument passed to it.

[committed] libstdc++: Fix __normal_iterator comparisons for C++20

This fixes a regression introduced when I replaced __normal_iterator's relational operators with operator<=>. If the wrapped iterator type doesn't define operator<=> then __normal_iterator doesdn't either, which breaks any use of fancy pointers that don't define <=>. The regression was found when

[PATCH] c++: Add test for c++/93807

This PR was initially accepts-invalid, but I think it's actually valid C++20 code. My reasoning is that in C++20 we no longer require the declaration of operator== (#if-defed in the test), because C++20's [temp.names]/2 says "A name is also considered to refer to a template if it is an

[patch, fortran] Fix PR 93956, wrong pointer when returned via function

Hello world, this one took a bit of detective work. When array pointers point to components of derived types, we currently set the span field and then create an array temporary when we pass the array pointer to a procedure as a non-pointer or non-target argument. (This is inefficient, but

Re: [PATCH] Fix use of singleton in optinfo framework

On Tue, 21 Apr 2020, Gustavo Romero wrote: > Hi Hans, Hi Gus, > On 4/14/20 12:33 AM, Hans-Peter Nilsson wrote: > > Sadly this patch doesn't fix PR bootstrap/87252; I just checked > > against f8e72b8d9f2:f81653ba8c1:2dd4ceacd8b (truncated from > > LAST_UPDATED; I don't remember which field is

[PATCH][v3], rs6000: Use plq/pstq for atomic_{load, store} (PR94622)

For future architecture with prefix instructions, always use plq/pstq rather than lq/stq for atomic load of quadword. Then we never have to do the doubleword swap on little endian. Before this fix, -mno-pcrel would generate lq with the doubleword swap (which was ok) and -mpcrel would generate plq,

Re: [PATCH] reject scalar array initialization with nullptr [PR94510]

On 4/21/20 2:33 PM, Jason Merrill wrote: On 4/17/20 5:18 PM, Martin Sebor wrote: On 4/17/20 12:19 AM, Jason Merrill wrote: On 4/15/20 1:30 PM, Martin Sebor wrote: On 4/13/20 8:43 PM, Jason Merrill wrote: On 4/12/20 5:49 PM, Martin Sebor wrote: On 4/10/20 8:52 AM, Jason Merrill wrote: On

Re: [PATCH] c++: Constrained inherited constructor template [PR94549]

On 4/20/20 4:38 PM, Patrick Palka wrote: A comment in satisfy_declaration constraints says /* For inherited constructors, consider the original declaration; it has the correct template information attached. */ d = strip_inheriting_ctors (d); But this comment seems to be false when

[committed] libstdc++: Improve C++14 and C++17 status docs

This adds a full table of contents for the C++14 and C++17 standards, with status for each part. For C++14 the list of proposals is removed, as it adds little value now that everything is supported. For C++17 the table of proposals is retained, because it documents he feature test macros for the

[committed] libphobos: Remove GDCFLAGSX variable from configure scripts.

Hi, This patch changes the testsuite to compile all tests with the same GDCFLAGS as used to build the library. Notably, this would now be using "-O2", whereas before the testsuite was compiling all tests with "-O0". That we are now compiling with "-O2", there is a possibility of previously

Re: [PATCH] Fix use of singleton in optinfo framework

Hi Hans, On 4/14/20 12:33 AM, Hans-Peter Nilsson wrote: Sadly this patch doesn't fix PR bootstrap/87252; I just checked against f8e72b8d9f2:f81653ba8c1:2dd4ceacd8b (truncated from LAST_UPDATED; I don't remember which field is the actual commit). So, would you mind to tell me precisely how to

Re: [PATCH 1/1] testsuite: Handle --save-temps in schedule-cleanups

On Mon, 2020-04-20 at 11:43 +, Christophe Lyon via Gcc-patches wrote: > Some tests use --save-temps, but schedule-cleanups strictly matches > -save-temps, so we leave many temporary files after validation. > Instead of fixing every offending testcase, it's simpler and > future-proof to make

[PATCH] coroutines: Fix for uses of structured binding [PR94701]

Hi, As reported by Michał Dominiak, we are generating incorrect code for structured binding of local vars. Somewhere in the machinations associated with lambda captures, I messed up the code handling DECL_VALUE_EXPRs. tested so far on x86_64-darwin16, OK for master if it passes regstrap on

Re: [PATCH] reject scalar array initialization with nullptr [PR94510]

On 4/17/20 5:18 PM, Martin Sebor wrote: On 4/17/20 12:19 AM, Jason Merrill wrote: On 4/15/20 1:30 PM, Martin Sebor wrote: On 4/13/20 8:43 PM, Jason Merrill wrote: On 4/12/20 5:49 PM, Martin Sebor wrote: On 4/10/20 8:52 AM, Jason Merrill wrote: On 4/9/20 4:23 PM, Martin Sebor wrote: On

Re: [PATCH] c++: Diagnose invalid use of member function in requires

On 4/21/20 2:03 PM, Patrick Palka wrote: This updates diagnose_valid_expression to mirror the convert_to_void check added to tsubst_valid_expression_requirement by r10-7554. Passes 'make check-c++', does this look OK to commit after a full bootstrap/regtest? OK, thanks. gcc/cp/ChangeLog:

[PATCH] add missing -Wno-stack-usage etc. options [PR90983]

In addition to accepting argument values in excess of INT_MAX in options like -Walloca-larger-than=byte-size, GCC 9 has changed the behavior of such options with byte-size of zero. While in prior versions zero disables the warning for any size, in GCC 9 it enables it for all non-zero sizes.

[wwwdocs] Update list of new C++20 features in libstdc++

Committed to wwwdocs. commit ba9d172720e36f93daf9c1b4569d4babe34e307e Author: Jonathan Wakely Date: Tue Apr 21 20:28:48 2020 +0100 Update list of new C++20 features in libstdc++ diff --git a/htdocs/gcc-10/changes.html b/htdocs/gcc-10/changes.html index fc8f16e7..06a4267a 100644 ---

Re: [PATCH, V4] PowerPC Turn on -mpcrel by default for -mcpu=future

On Tue, Apr 21, 2020 at 02:03:34PM -0400, Michael Meissner wrote: > On Tue, Apr 07, 2020 at 05:58:01PM -0500, Segher Boessenkool wrote: > > > + /* Enable -mprefixed by default on 64-bit 'future' systems. */ > > > + if (TARGET_FUTURE && TARGET_POWERPC64 > > > + && (rs6000_isa_flags_explicit

Re: PING [PATCH][gcc][PR94230]provide an option to change the size limitation for -Wmisleading-indent

David Malcolm writes: > On Tue, 2020-04-21 at 15:04 +0100, Richard Sandiford wrote: >> Qing Zhao via Gcc-patches writes: >> > Hi, >> > >> > Please take a look at the attached patch and let me know your >> > comments. >> > >> > Thanks. >> > >> > Qing >> >> Acting as a reviewer of last resort

We’ve Got An Early Gift Just For You .......!

ANH Digitizing (Embroidery, Custom Patches, Screen Printing, Graphics Art Work and All you need) We are providing special offers to our new customers and we have highly skilled team that’s why we provide 100% quality and shortest turnaround time. Digitzing Logo: - Each Cap And Left Chest

[PATCH] c++: Diagnose invalid use of member function in requires

This updates diagnose_valid_expression to mirror the convert_to_void check added to tsubst_valid_expression_requirement by r10-7554. Passes 'make check-c++', does this look OK to commit after a full bootstrap/regtest? gcc/cp/ChangeLog: PR c++/67825 * constraint.cc

Re: [PATCH, V4] PowerPC Turn on -mpcrel by default for -mcpu=future

On Tue, Apr 07, 2020 at 05:58:01PM -0500, Segher Boessenkool wrote: > > + /* Enable -mprefixed by default on 64-bit 'future' systems. */ > > + if (TARGET_FUTURE && TARGET_POWERPC64 > > + && (rs6000_isa_flags_explicit & OPTION_MASK_PREFIXED) == 0) > > +rs6000_isa_flags |=

Re: [patch, committed] Add numerous symbol attributes to -fdump-fortran-original

On Mon, Apr 20, 2020 at 1:25 PM Thomas Koenig via Fortran wrote: > > Hello world, > > after finding myself debug a PR where showing all the attributes > of a symbol would have helped enormously (which I realized only > afterwards), I went ahead and added most of the flags to show_attr, > in the

Re: [PATCH] aarch64, libgcc: Fix unwinding from pac-ret to normal frames [PR94514]

The 04/17/2020 11:05, Kyrylo Tkachov wrote: > Hi Szabolcs, > > > -Original Message- > > From: Szabolcs Nagy > > Sent: 09 April 2020 15:20 > > To: gcc-patches@gcc.gnu.org > > Cc: Richard Earnshaw ; Richard Sandiford > > ; Kyrylo Tkachov > > Subject: [PATCH] aarch64, libgcc: Fix unwinding

Re: [Patch v2, fortran] PR fortran/90350 - ubound ICE on assumed size array even though explicit bound is specified

Hi Jose, Proposed patch to Bug 90350 - ubound ICE on assumed size array even though explicit bound is specified Patch tested only on x86_64-pc-linux-gnu. Best regards, José Rui Looks good. Do you have commit privileges? It not, I can commit it for you. Regards Thomas

Re: [PATCH] aarch64: Fix .cfi_window_save with pac-ret [PR94515]

> i spoted failing execution tests that expected to pass, > it turns out change_cfi_row() needs something like > > - if (!old_row->window_save && new_row->window_save) > + if (old_row->window_save != new_row->window_save) > > to generate .cfi_window_save that correctly tracks the > toggled

[committed][hppa] Fix weakening of external objects

In looking at issues with libgfortran, I noticed the include definitions in libquadmath.h resulted in declarations for functions in libquadmath being of type DATA. As a result, the HP linker ended up looking for data symbols instead of code symbols. This occurred for functions declared with

Re: [PATCH][libstd++][PR92156]

added VERIFY in test and changed the template parameter naming. diff --git a/libstdc++-v3/include/std/any b/libstdc++-v3/include/std/any index 6b7e68f0e63..d350d0b2575 100644 --- a/libstdc++-v3/include/std/any +++ b/libstdc++-v3/include/std/any @@ -176,36 +176,23 @@

Re: PING [PATCH][gcc][PR94230]provide an option to change the size limitation for -Wmisleading-indent

On Tue, 2020-04-21 at 15:04 +0100, Richard Sandiford wrote: > Qing Zhao via Gcc-patches writes: > > Hi, > > > > Please take a look at the attached patch and let me know your > > comments. > > > > Thanks. > > > > Qing > > Acting as a reviewer of last resort since this isn't really my area,

Re: introduce target tmpnam and require it in tests relying on it

On 4/21/20 3:50 AM, Bernhard Reutner-Fischer wrote: On 17 April 2020 21:21:41 CEST, Martin Sebor via Gcc-patches wrote: On 4/17/20 11:48 AM, Alexandre Oliva wrote: On Apr 9, 2020, Alexandre Oliva wrote: Some target C libraries that aren't recognized as freestanding don't have filesystem

Re: [AArch64] (PR94383) Avoid C++17 empty base field checking for HVA/HFA

Thanks for doing this. Matthew Malcomson writes: > In C++17, an empty class deriving from an empty base is not an > aggregate, while in C++14 it is. In order to implement this, GCC adds > an artificial field to such classes. > > This artificial field has no mapping to Fundamental Data Types in

Re: [AArch64] (PR94383) Avoid C++17 empty base field checking for HVA/HFA

On Tue, Apr 21, 2020 at 02:39:12PM +0100, Matthew Malcomson wrote: > --- a/gcc/config/aarch64/aarch64.c > +++ b/gcc/config/aarch64/aarch64.c > @@ -15909,13 +15909,30 @@ aarch64_conditional_register_usage (void) > } > } > > +enum cpp17empty_state { > +DONT_AVOID = 0, > +AVOID = 1, >

Re: [PATCH] testsuite: Extend C++ struct-layout-1.exp testing to test C++14 vs. C++17 interoperability of structs with empty bases [PR94383]

On 4/21/20 5:57 AM, Jakub Jelinek wrote: Hi! Jonathan reported an ABI incompatibility between C++14 and C++17 in passing some aggregates with empty bases on aarch64 (and apparently on arm too). The following patch adds 3000 (by default) tests for such interoperability, using the

Re: [PATCH] c++: Dependent conversion operator in concept [PR94597]

On 4/21/20 9:55 AM, Patrick Palka wrote: When building the parameter mapping for an atomic constraint, find_template_parameters does not spot the template parameter within the conversion-type-id of a dependent conversion operator, which later leads to an ICE during substitution when looking up

Re: [PATCH] forwprop: Fix ICE when building a VEC_PERM_EXPR [PR94683]

On Tue, Apr 21, 2020 at 2:13 PM Richard Sandiford wrote: > > The type compatibility handling in simplify_vector_constructor is > based on the number of elements and on element type compatibility, > but that's no longer enough to ensure that two vector types are > compatible. This patch uses a

Re: [PATCH] aarch64: Fix .cfi_window_save with pac-ret [PR94515]

The 04/17/2020 15:26, Jason Merrill wrote: > On 4/17/20 1:55 PM, Szabolcs Nagy wrote: > > The 04/17/2020 12:50, Jason Merrill wrote: > > > On 4/17/20 6:08 AM, Kyrylo Tkachov wrote: > > > > Hi Szabolcs, > > > > > > > > > -Original Message- > > > > > From: Szabolcs Nagy > > > > > Sent: 09

Re: [PATCH] aarch64：Add an error message in large code model for ilp32 [PR94577]

"duanbo (C)" writes: > Hi > >> -Original Message- >> From: Richard Sandiford [mailto:richard.sandif...@arm.com] >> Sent: Monday, April 20, 2020 10:42 PM >> To: duanbo (C) >> Cc: GCC Patches >> Subject: Re: [PATCH] aarch64：Add an error message in large code model for >> ilp32 [PR94577]

Re: [PATCH 1/5] testsuite: [arm] Add arm_softfp_ok and arm_hard_ok effective targets.

On Tue, 14 Apr 2020 at 10:38, Andre Vieira (lists) wrote: > > On 10/04/2020 14:55, Christophe Lyon via Gcc-patches wrote: > > For arm-linux-gnueabi* targets, a toolchain cannot support the > > float-abi opposite to the one it has been configured for: since glibc > > does not support such

Re: PING [PATCH][gcc][PR94230]provide an option to change the size limitation for -Wmisleading-indent

Qing Zhao via Gcc-patches writes: > Hi, > > Please take a look at the attached patch and let me know your comments. > > Thanks. > > Qing Acting as a reviewer of last resort since this isn't really my area, but FWIW, I agree losing column tracking at the current limit is a genuine regression and

[PATCH] c++: Dependent conversion operator in concept [PR94597]

When building the parameter mapping for an atomic constraint, find_template_parameters does not spot the template parameter within the conversion-type-id of a dependent conversion operator, which later leads to an ICE during substitution when looking up the missing template argument for this

C++: ICE tsubsting ptr_plus

A colleague hit an ICE when build_pointer_plus exploded. tsubsting the pointer operand produced error_mark_node, and b_p_p is unprepared for that. pushed to trunk nathan -- Nathan Sidwell 2020-04-21 Nathan Sidwell * pt.c (tsubst_copy_and_build) [POINTER_PLUS_EXPR]: Check for

[AArch64] (PR94383) Avoid C++17 empty base field checking for HVA/HFA

In C++17, an empty class deriving from an empty base is not an aggregate, while in C++14 it is. In order to implement this, GCC adds an artificial field to such classes. This artificial field has no mapping to Fundamental Data Types in the AArch64 PCS ABI and hence should not count towards

Re: [PATCH] coroutines: Pass class reference to promise param preview [PR94682]

On 4/21/20 6:42 AM, Iain Sandoe wrote: Hi As reported in the PR, per [dcl.fct.def.coroutine]/4 we should be passing a reference to the object to the promise parameter preview, and we are currently passing a pointer (this). gcc/cp/ChangeLog: 2020-04-21 Iain Sandoe * coroutines.cc

Re: [og8] Report errors on missing OpenACC reduction clauses in nested reductions

Hi Frederik! On 2020-04-21T14:13:33+0200, Frederik Harwath wrote: > Thomas Schwinge writes: >> Via "10 issues located by the PVS-studio >> static analyzer" (so please reference that one on any patch submission), >> on

Re: set_rtx_cost used wrongly, should be set_src_cost

Alan Modra via Gcc-patches writes: > I believe set_rtx_cost is meant to handle a SET, not a PLUS as is > passed in these two locations. Using the proper function for a PLUS > doesn't make a huge difference: the only arg change to rtx_cost of any > consequence is outer_code of SET rather than

Re: [PATCH] c++: make __is_constructible work with paren-init of aggrs [PR94149]

On 09/04/20 17:00 -0400, Marek Polacek wrote: In C++20 this is well-formed: using T = int[2]; T t(1, 2); which means that std::is_constructible_v should be true. But constructible_expr immediately returned the error_mark_node when it saw a list with more than one element. To give accurate

Re: [PATCH, libphobos] Fix compilation dependencies on s390x-linux-musl

On 13/04/2020 15:36, Iain Buclaw via Gcc-patches wrote: > On 08/04/2020 10:14, Iain Buclaw via Gcc-patches wrote: >> On 28/01/2020 05:00, Mathias Lang wrote: >>> diff -Nurp a/libphobos/configure.ac b/libphobos/configure.ac >>> --- a/libphobos/configure.ac >>> +++ b/libphobos/configure.ac >>> @@

[AMD GCN] Use 'radeon' for the environment variable 'ACC_DEVICE_TYPE' (was: [committed, amdgcn/openacc] Rename acc_device_gcn to acc_device_radeon)

Hi Andrew! On 2020-01-17T18:18:41+, Andrew Stubbs wrote: > I've committed this patch, pre-approved by Thomas. It's basically just a > search and replace. > > I had originally invented acc_device_gcn for the device number, but as > Thomas pointed out the OpenACC documentation already uses >

Re: [og8] Report errors on missing OpenACC reduction clauses in nested reductions

Thomas Schwinge writes: Hi Thomas, > Via "10 issues located by the PVS-studio > static analyzer" (so please reference that one on any patch submission), > on in "Fragment N3, > Assigning a variable to itself",

[PATCH] forwprop: Fix ICE when building a VEC_PERM_EXPR [PR94683]

The type compatibility handling in simplify_vector_constructor is based on the number of elements and on element type compatibility, but that's no longer enough to ensure that two vector types are compatible. This patch uses a VIEW_CONVERT_EXPR if the permutation type and result type are

Re: [PATCH][libstd++][PR92156]

On Tue, 21 Apr 2020 at 11:29, kamlesh kumar wrote: > > Added the fix for emplace. > > diff --git a/libstdc++-v3/include/std/any b/libstdc++-v3/include/std/any > index 6b7e68f0e63..f35d90e548d 100644 > --- a/libstdc++-v3/include/std/any > +++ b/libstdc++-v3/include/std/any > @@ -178,30 +178,17 @@

[PATCH] aarch64：Add an error message in large code model for ilp32 [PR94577]

Hi > -Original Message- > From: Richard Sandiford [mailto:richard.sandif...@arm.com] > Sent: Monday, April 20, 2020 10:42 PM > To: duanbo (C) > Cc: GCC Patches > Subject: Re: [PATCH] aarch64：Add an error message in large code model for > ilp32 [PR94577] > > "duanbo (C)" writes: > >

Re: [PATCH], rs6000, PR/target 94622, Be more careful with plq for atomic_load

[ I never received the original mail? Not the one sent to me directly, that is. ] Subject: [PATCH], rs6000, PR/target 94622, Be more careful with plq for atomic_load That is too long... Also, PR should go at the end, etc., so smth like Subject: [PATCH] rs6000: Be more careful with plq for

[Patch v2, fortran] PR fortran/90350 - ubound ICE on assumed size array even though explicit bound is specified

Hi again! Proposed patch to Bug 90350 - ubound ICE on assumed size array even though explicit bound is specified Patch tested only on x86_64-pc-linux-gnu. Best regards, José Rui 2020-4-19 José Rui Faustino de Sousa PR fortran/90350 * simplify.c (simplify_bound): In the case of

[committed] testsuite: Add testcase for already fixed PR [PR94686]

Hi! This has been fixed by the PR71311 r7-1170-g4618c453205f18 change. Tested on x86_64-linux (also with gcc 6 where it ICEs), committed to trunk as obvious. 2020-04-21 Jakub Jelinek PR c/94686 * gcc.c-torture/compile/pr94686.c: New test. ---

[PATCH] coroutines: Pass class reference to promise param preview [PR94682]

Hi As reported in the PR, per [dcl.fct.def.coroutine]/4 we should be passing a reference to the object to the promise parameter preview, and we are currently passing a pointer (this). tested on x86_64-darwin, and in progress on x86_64/powerpc64-linux. OK for master if regtesting is successful on

Re: [PATCH PR94678] aarch64: unexpected result with -mgeneral-regs-only and sve

"Yangfei (Felix)" writes: >> -Original Message- >> From: Richard Sandiford [mailto:richard.sandif...@arm.com] >> Sent: Tuesday, April 21, 2020 4:01 PM >> To: Yangfei (Felix) >> Cc: gcc-patches@gcc.gnu.org >> Subject: Re: [PATCH PR94678] aarch64: unexpected result with -mgeneral- >>

[PATCH] testsuite: Extend C++ struct-layout-1.exp testing to test C++14 vs. C++17 interoperability of structs with empty bases [PR94383]

Hi! Jonathan reported an ABI incompatibility between C++14 and C++17 in passing some aggregates with empty bases on aarch64 (and apparently on arm too). The following patch adds 3000 (by default) tests for such interoperability, using the struct-layout-1* framework. The current 3000 tests are

Re: [PR93488] [OpenACC] ICE in type-cast 'async', 'wait' clauses

Hi Andrew! On 2020-01-30T21:12:59+, Andrew Stubbs wrote: > On 29/01/2020 12:30, Thomas Schwinge wrote: >> As can be seen in the code a few lines below, the very same problem also >> exists for the 'wait' clause; it seems reasonable to fix both at the same >> time. This is not a recent

Re: [PATCH] gcc-[89]: Fix sra_modify_expr handling of partial writes (PR 94482)

On Tue, 21 Apr 2020, Martin Jambor wrote: > On Wed, Apr 08 2020, Martin Jambor wrote: > > > [...] > > > > 2020-04-08 Martin Jambor > > Richard Biener > > > > PR tree-optimization/94482 > > * tree-sra.c (create_access_replacement): Dump new replacement with > > TDF_UID. >

Re: [PATCH] gcc-[89]: Fix sra_modify_expr handling of partial writes (PR 94482)

On Wed, Apr 08 2020, Martin Jambor wrote: > [...] > > 2020-04-08 Martin Jambor > Richard Biener > > PR tree-optimization/94482 > * tree-sra.c (create_access_replacement): Dump new replacement with > TDF_UID. > (sra_modify_expr): Fix handling of cases when the

Re: introduce target tmpnam and require it in tests relying on it

On 17 April 2020 21:21:41 CEST, Martin Sebor via Gcc-patches wrote: >On 4/17/20 11:48 AM, Alexandre Oliva wrote: >> On Apr 9, 2020, Alexandre Oliva wrote: >> >>> Some target C libraries that aren't recognized as freestanding don't >>> have filesystem support, so calling tmpnam, fopen/open and

Re: [PATCH] reject scalar array initialization with nullptr [PR94510]

On 17 April 2020 23:18:05 CEST, Martin Sebor via Gcc-patches wrote: + zero-initialialization for its type, taking pointers to members s/initialialization/initialization/

Re: [PATCH] correct strncpy range computation in restrict pass (PR 94647)

On Mon, Apr 20, 2020 at 11:29 PM Martin Sebor via Gcc-patches wrote: > > The restrict pass computes the wrong lower bound of the size > of accesses to member arrays passed to strncpy as the source: > it uses the third argument to the function even though the size > of the read is limited by the

Re: [PATCH 1/1] testsuite: Handle --save-temps in schedule-cleanups

On 20 April 2020 13:43:42 CEST, Christophe Lyon via Gcc-patches wrote: >Some tests use --save-temps, but schedule-cleanups strictly matches >-save-temps, so we leave many temporary files after validation. >Instead of fixing every offending testcase, it's simpler and >future-proof to make

Re: [PATCH PR94678] aarch64: unexpected result with -mgeneral-regs-only and sve

On Tue, Apr 21, 2020 at 08:37:09AM +, Yangfei (Felix) wrote: > Yes, that's right. And I have a question here: > Should aarch64_sve::init_builtins ()/aarch64_sve::handle_arm_sve_h () be > guarded by TARGET_SVE? > > I mean in aarch64_init_builtins: > if (TARGET_SVE) >

RE: [PATCH PR94678] aarch64: unexpected result with -mgeneral-regs-only and sve

> -Original Message- > From: Richard Sandiford [mailto:richard.sandif...@arm.com] > Sent: Tuesday, April 21, 2020 4:01 PM > To: Yangfei (Felix) > Cc: gcc-patches@gcc.gnu.org > Subject: Re: [PATCH PR94678] aarch64: unexpected result with -mgeneral- > regs-only and sve > > "Yangfei

RE: [PATCH v2] aarch64: Add TX3 machine model

Hi Anton, > -Original Message- > From: Gcc-patches On Behalf Of Anton > Youdkevitch > Sent: 20 April 2020 19:29 > To: gcc-patches@gcc.gnu.org > Cc: jo...@marvell.com > Subject: [PATCH v2] aarch64: Add TX3 machine model > > Here is the patch introducing thunderxt311 maching model > for

Re: [PATCH][libstd++][PR92156]

Added the fix for emplace. diff --git a/libstdc++-v3/include/std/any b/libstdc++-v3/include/std/any index 6b7e68f0e63..f35d90e548d 100644 --- a/libstdc++-v3/include/std/any +++ b/libstdc++-v3/include/std/any @@ -178,30 +178,17 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION /// Construct with a copy of

Re: [PATCH PR94678] aarch64: unexpected result with -mgeneral-regs-only and sve

"Yangfei (Felix)" writes: > Hi, > > It looks like there are several issues out there for sve codegen with > -mgeneral-regs-only. > I have created a bug for that: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94678 > > We do ISA extension checks for SVE in >

[PATCH] favor bcrypt over wincrypt for the random generator on Windows

BCrypt is more modern and supported in Universal Apps, Wincrypt is not and CryptGenRandom is deprecated: https://docs.microsoft.com/en-us/windows/win32/api/wincrypt/nf-wincrypt-cryptgenrandom BCrypt is available since Vista

Re: [PATCH v2] ubsan: Avoid -Wpadded warnings [PR94641]

On Tue, 21 Apr 2020, Jakub Jelinek wrote: > Hi! > > On Tue, Apr 21, 2020 at 08:21:36AM +0200, Richard Biener wrote: > > I believe most of those warnings should simply not look at > > TYPE_ARTIFICIAL types. So why the above kludge certainly > > works a better fix is on the -Wpadded side IMHO. >

[PATCH v2] ubsan: Avoid -Wpadded warnings [PR94641]

Hi! On Tue, Apr 21, 2020 at 08:21:36AM +0200, Richard Biener wrote: > I believe most of those warnings should simply not look at > TYPE_ARTIFICIAL types. So why the above kludge certainly > works a better fix is on the -Wpadded side IMHO. So like this if it passes bootstrap/regtest? 2020-04-21

[PATCH] doc: Document all D-specific configuration options.

Hi, This patch adds documentation for --enable-libphobos-checking and --with-libphobos-druntime-only options. Does it read and explain clearly enough? Regards Iain. gcc/ChangeLog: * doc/install.texi (D-Specific Options): Document --enable-libphobos-checking and

[PATCH PR94678] aarch64: unexpected result with -mgeneral-regs-only and sve

Hi, It looks like there are several issues out there for sve codegen with -mgeneral-regs-only. I have created a bug for that: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94678 We do ISA extension checks for SVE in check_required_extensions(aarch64-sve-builtins.cc). I think we may

[committed] d/dmd: Merge upstream dmd 62ce36f37 (PR94623)

Hi, This patch merges the D front-end implementation with dmd upstream 62ce36f37. Adjusts the hardcoded index of Error.bypassException. Bootstrapped and regression tested on x86_64-linux-gnu, and committed to mainline. Regards Iain --- gcc/d/dmd/MERGE| 2 +- gcc/d/dmd/dinterpret.c |

Re: [PATCH][libstd++][PR92156]

On Tue, 21 Apr 2020 at 09:11, Ville Voutilainen wrote: > > On Tue, 21 Apr 2020 at 04:10, kamlesh kumar wrote: > > > > Thank you for reviewing. > > without _Decay to decay_t in the constructor which takes inplace_type_t, > > cases like this fails > > auto a = std::any(std::in_place_type, 5); > >

Re: [PATCH] ubsan: Avoid -Wpadded warnings [PR94641]

On Tue, 21 Apr 2020, Jakub Jelinek wrote: > Hi! > > -Wpadded warnings aren't really useful for the artificial types that GCC > lays out for ubsan. > > Fixed thusly, bootstrapped/regtested on x86_64-linux and i686-linux, ok for > trunk? I believe most of those warnings should simply not look at

Re: [PATCH][libstd++][PR92156]

On Tue, 21 Apr 2020 at 04:10, kamlesh kumar wrote: > > Thank you for reviewing. > without _Decay to decay_t in the constructor which takes inplace_type_t, > cases like this fails > auto a = std::any(std::in_place_type, 5); > > for these constructors, standard does not say anything about >