Re: [PATCH] rtl cse: Fix PR94740, ICE on testsuite/gcc.dg/sso/t5.c with -mcpu=future -mpcrel -O1

On Wed, 2020-04-29 at 17:54 -0500, Segher Boessenkool wrote: > On Wed, Apr 29, 2020 at 08:56:11AM -0600, Jeff Law wrote: > > On Tue, 2020-04-28 at 20:03 -0500, Segher Boessenkool wrote: > > > What are the actual rules? Where is this documented? > > > > > > Of course it is highly desirable to

Re: [PATCH] rtl cse: Fix PR94740, ICE on testsuite/gcc.dg/sso/t5.c with -mcpu=future -mpcrel -O1

On 4/29/20 4:15 PM, Peter Bergner wrote: > On 4/29/20 3:28 PM, Richard Sandiford wrote: >> (Sorry for going ahead and writing an alternative patch, since if we do >> go for this, I guess the earlier misdirections will have wasted two days >> of your time. But it seemed like I was just never going

Re: [PATCH] rtl cse: Fix PR94740, ICE on testsuite/gcc.dg/sso/t5.c with -mcpu=future -mpcrel -O1

On Wed, Apr 29, 2020 at 08:56:11AM -0600, Jeff Law wrote: > On Tue, 2020-04-28 at 20:03 -0500, Segher Boessenkool wrote: > > What are the actual rules? Where is this documented? > > > > Of course it is highly desirable to have CONST around such constant > > addresses, but when is it *required*?

Re: [PATCH v2] diagnostics: Add %{...%} pretty-format support for URLs and use it in -Wpsabi diagnostcs

On Wed, Apr 29, 2020 at 09:42:59PM +, Joseph Myers wrote: > This is missing documentation for the new configure option in > install.texi. I was considering it, but then didn't find any docs for the --with-documentation-root= option either, so punted on that. I'll try to write something for

Re: [PATCH v2] diagnostics: Add %{...%} pretty-format support for URLs and use it in -Wpsabi diagnostcs

This is missing documentation for the new configure option in install.texi. -- Joseph S. Myers jos...@codesourcery.com

Re: [PATCH] rtl cse: Fix PR94740, ICE on testsuite/gcc.dg/sso/t5.c with -mcpu=future -mpcrel -O1

On 4/29/20 3:28 PM, Richard Sandiford wrote: > I think at this point it would be better to go for the > simplify_replace_fn_rtx thing I mentioned in the original review, > rather than try to hack at the current code even more. What do you > think about the attached? Testing in progress. My

Re: [PATCH] rtl cse: Fix PR94740, ICE on testsuite/gcc.dg/sso/t5.c with -mcpu=future -mpcrel -O1

On 4/29/20 3:28 PM, Richard Sandiford wrote: > (Sorry for going ahead and writing an alternative patch, since if we do > go for this, I guess the earlier misdirections will have wasted two days > of your time. But it seemed like I was just never going to think about > this PR properly unless I

Re: [PATCH] c++: Member template function lookup failure [PR94799]

On 4/28/20 11:55 PM, Marek Polacek wrote: Whew, this took a while. We fail to parse "p->template A::a()" (where p is of type A *) because since r249752 we treat the RHS of the -> as dependent and avoid a lookup in the enclosing context: since that rev cp_parser_template_name checks

[PATCH] tree: Don't reuse types if TYPE_USER_ALIGN differ [PR94775]

Here we trip on the TYPE_USER_ALIGN (t) assert in strip_typedefs: it gets "const d[0]" with TYPE_USER_ALIGN=0 but the result built by build_cplus_array_type is "const char[0]" with TYPE_USER_ALIGN=1. When we strip_typedefs the element of the array "const d", we see it's a typedef_variant_p, so we

Re: [PATCH v5 GCC] libffi/test: Fix compilation for build sysroot

* Jeff Law via Libffi-discuss: > FWIW, I'm expecting Florian to be digging into some libffi stuff > relatively soon and once those issues are ironed out, there'll be a > push for a libffi upstream release -- which seems like a good place > to re-sync GCC to the upstream libffi master. I'm not

Re: [PATCH] rtl cse: Fix PR94740, ICE on testsuite/gcc.dg/sso/t5.c with -mcpu=future -mpcrel -O1

Peter Bergner writes: > On 4/29/20 10:13 AM, Richard Sandiford wrote: >> If this is a bug we need to fix for GCC 10 then how about this: > > I do think this is important to fix. Mike Meissner just switched our > -mcpu=future code to enable -mpcrel by default in GCC10, so we're going > to see a

[PR c+ 94827]: template parm with default requires

Jason, this is the patch you suggested, as I understood it. I kept finish_nested_require's saving of the (converted) current_template_parms, becase of the comment about use in diagnostics. Is this what you meant? boostrapped on x86_64-linux. nathan -- Nathan Sidwell 2020-04-27 Jason

Re: [PATCH] rtl cse: Fix PR94740, ICE on testsuite/gcc.dg/sso/t5.c with -mcpu=future -mpcrel -O1

On 4/29/20 10:13 AM, Richard Sandiford wrote: > If this is a bug we need to fix for GCC 10 then how about this: I do think this is important to fix. Mike Meissner just switched our -mcpu=future code to enable -mpcrel by default in GCC10, so we're going to see a lot more of these types of

[committed] libstdc++: Fix outdated comment about std::string instantiations (PR 94854)

PR libstdc++/94854 * include/bits/basic_string.tcc: Update comment about explicit instantiations. Committed to master as obvious. Backports to follow. commit 8f1591763fd50b143af0dc1770741f326a97583a Author: Jonathan Wakely Date: Wed Apr 29 18:57:34 2020 +0100

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

On Tue, 2020-04-28 at 20:43 -0300, Alexandre Oliva wrote: > On Apr 28, 2020, Bernhard Reutner-Fischer wrote: > > > ISTM the corresponding documentation hunk for sourcebuild.texi is missing. > > Thanks, I wasn't aware that testsuite effective targets were documented > there. > > Here's the

Re: [PATCH] contrib/vimrc: Reduce textwidth for commit messages

On Wed, Apr 29, 2020 at 11:06:27AM -0600, Jeff Law via Gcc-patches wrote: > On Tue, 2020-04-28 at 00:31 -0400, Patrick Palka via Gcc-patches wrote: > > The bundled vimrc script, when enabled, currently sets the text width to > > 80 characters for all files within the source directory.

Re: [PATCH v5 GCC] libffi/test: Fix compilation for build sysroot

On Sat, 2020-04-25 at 21:33 +0100, Maciej W. Rozycki wrote: > On Wed, 22 Apr 2020, Jeff Law wrote: > > > > libffi/ > > > * Makefile.am (DISTCLEANFILES): New variable. > > > * configure.ac: Produce `local.exp'. > > > * Makefile.in: Regenerate. > > > * configure: Regenerate. > > > *

Re: [PATCH] rs6000, Fix header comment for intrinsic function

On 4/22/20 1:20 PM, Carl Love wrote: GCC maintainers: The following is a trivial patch to fix a comment describing the intrinsic function _mm_movemask_epi8. The comment was expanded to clarify the layout of the returned result. The patch does not make any functional changes. Please let me

Re: [PATCH] contrib/vimrc: Reduce textwidth for commit messages

On Tue, 2020-04-28 at 00:31 -0400, Patrick Palka via Gcc-patches wrote: > The bundled vimrc script, when enabled, currently sets the text width to > 80 characters for all files within the source directory. Unfortunately > this means the setting also applies when editing .git/COMMIT_EDITMSG, >

Re: [PATCH] toplev.c: Check for null argument to fprintf

On Tue, 2020-04-28 at 09:03 +0200, Stefan Schulze Frielinghaus via Gcc-patches wrote: > Ensure that CF does not equal NULL in function output_stack_usage_1 > before calling fprintf. This fixes the following warning/error: > > gcc/toplev.c:976:13: error: argument 1 null where non-null expected [-

Re: [PATCH] match.pd: Decrease number of nop conversions around bitwise ops [PR94718]

On Wed, 29 Apr 2020, Jakub Jelinek wrote: > On Tue, Apr 28, 2020 at 11:16:13AM +0200, Richard Biener wrote: > > I think we generally want to use :s, but OTOH even for your new case, > > since you restrict to nop-conversions, :s isn't strictly needed since > > VN should know how to materialize

RE: arm: Fix vfp_operand_register for VFP HI regs

Hi Christophe, > -Original Message- > From: Gcc-patches On Behalf Of > Christophe Lyon via Gcc-patches > Sent: 29 April 2020 16:53 > To: gcc Patches > Subject: arm: Fix vfp_operand_register for VFP HI regs > > Hi, > > While looking at PR target/94743 I noticed an ICE when I tried to

Re: [PATCH] arm: Remove duplicate entries in isr_attribute_args [PR target/57002]

On Wed, Apr 29, 2020 at 4:19 PM Christophe Lyon via Gcc-patches wrote: > > Remove two duplicate entries in isr_attribute_args ("abort" and > "ABORT"). > > 2020-04-29 Christophe Lyon > > PR target/57002 > gcc/ > * config/arm/arm.c (isr_attribute_args): Remove duplicate

Re: [PATCH] aarch64: prefer using csinv, csneg in zero extend contexts

Thanks for doing this. Alex Coplan writes: > Hello, > > The attached patch adds an optimization to the AArch64 backend to catch > additional cases where we can use csinv and csneg. > > Given the C code: > > unsigned long long inv(unsigned a, unsigned b, unsigned c) > { > return a ? b : ~c; > }

Re: [PATCH] s390: Fix up -Wpsabi diagnostcs + analysis [PR94704]

On 28.04.20 17:44, Jakub Jelinek wrote: > On Tue, Apr 28, 2020 at 04:23:24PM +0200, Andreas Krebbel via Gcc-patches > wrote: >> Given that this is something which hasn't been covered by the ABI so far I'm >> not sure we really need >> a -Wpsabi warning for that. > > Attached are two (updated)

Re: [PATCH] var-tracking.c: Fix possible use of uninitialized variable pre

On Tue, 2020-04-28 at 11:44 +0200, Richard Biener via Gcc-patches wrote: > > Btw, does s390 have different inlining parameters somehow? I think so. We saw a ton of backend warnings that were specific to the s390 builds in Fedora that appeared to be triggered by different inlining decisions. It

Re: [PATCH v2] diagnostics: Add %{...%} pretty-format support for URLs and use it in -Wpsabi diagnostcs

On Wed, 2020-04-29 at 17:49 +0200, Jakub Jelinek wrote: > On Wed, Apr 29, 2020 at 11:34:06AM -0400, David Malcolm wrote: > > > I think it will be called infrequently, and emitting a diagnostic > > > is > > > already > > > slow. > > > > I was more concerned about the case for which the url is

arm: Fix vfp_operand_register for VFP HI regs

Hi, While looking at PR target/94743 I noticed an ICE when I tried to save all the FP registers: this was because all HI registers wouldn't match vfp_register_operand. Regression-tested and bootstrapped OK. 2020-04-29 Christophe Lyon gcc/ * config/arm/predicates.md

Re: [PATCH v2] diagnostics: Add %{...%} pretty-format support for URLs and use it in -Wpsabi diagnostcs

On Wed, Apr 29, 2020 at 11:34:06AM -0400, David Malcolm wrote: > > I think it will be called infrequently, and emitting a diagnostic is > > already > > slow. > > I was more concerned about the case for which the url is built but then > the "inform" is not called - I was worried it might happen

[PATCH 1/1] IBM Z: vec_store_len_r/vec_load_len_r fix

This fixes a problem with the vec_store_len_r intrinsic. The macros mapping the intrinsic to a GCC builtin had the wrong signature. With the patch an immediate length operand of vlrl/vstrl is handled the same way as if it was passed in a register to vlrlr/vstrlr. Values bigger than 15 always

Re: [PATCH v2] diagnostics: Add %{...%} pretty-format support for URLs and use it in -Wpsabi diagnostcs

On Wed, 2020-04-29 at 16:42 +0200, Jakub Jelinek wrote: > On Wed, Apr 29, 2020 at 10:25:38AM -0400, David Malcolm wrote: > > > I'd prefer not to at this point, all that could be commonized are > > > the two inform calls perhaps with a bool or enum arg which one it > > > is, > > > but usually the

Re: [PATCH] match.pd: Decrease number of nop conversions around bitwise ops [PR94718]

On Tue, Apr 28, 2020 at 11:16:13AM +0200, Richard Biener wrote: > I think we generally want to use :s, but OTOH even for your new case, > since you restrict to nop-conversions, :s isn't strictly needed since > VN should know how to materialize nop-converted variants. I think > it's different for

[PATCH] arm: Remove duplicate entries in isr_attribute_args [PR target/57002]

Remove two duplicate entries in isr_attribute_args ("abort" and "ABORT"). 2020-04-29 Christophe Lyon PR target/57002 gcc/ * config/arm/arm.c (isr_attribute_args): Remove duplicate entries. --- gcc/config/arm/arm.c | 2 -- 1 file changed, 2 deletions(-) diff --git

[PATCH] arm: Warn if IRQ handler is not compiled with -mgeneral-regs-only [PR target/94743]

The interrupt attribute does not guarantee that the FP registers are saved, which can result in problems difficult to debug. Saving the FP registers and status registers can be a large penalty, so it's probably not desirable to do that all the time. If the handler calls other functions, we'd

Re: [PATCH] rtl cse: Fix PR94740, ICE on testsuite/gcc.dg/sso/t5.c with -mcpu=future -mpcrel -O1

Peter Bergner writes: > On 4/28/20 5:39 PM, Richard Sandiford wrote: >> If we use simplify_gen_binary then I don't think we need to validate >> each change individually. It should be enough to do something like: >> >> x0 = cse_process_notes (XEXP (x, 0), object, changed); >> x1 =

Re: [PATCH] diagnostics: Add %{...%} pretty-format support for URLs and use it in -Wpsabi diagnostcs

On 29/04/20 09:24 -0400, David Malcolm wrote: On Wed, 2020-04-29 at 14:46 +0200, Jakub Jelinek wrote: @@ -6416,6 +6416,8 @@ aapcs_vfp_is_call_or_return_candidate (e && ((alt = aapcs_vfp_sub_candidate (type, _mode, NULL)) != ag_count)) { +

Re: [PATCH] rtl cse: Fix PR94740, ICE on testsuite/gcc.dg/sso/t5.c with -mcpu=future -mpcrel -O1

On Tue, 2020-04-28 at 20:03 -0500, Segher Boessenkool wrote: > Hi! > > On Tue, Apr 28, 2020 at 08:38:56AM +0100, Richard Sandiford wrote: > > Also, the (const:P ...) ought to be there even outside of a MEM. E.g. we > > ought to have: > > > > (set (reg X) (const:P (plus:P (symbol_ref:P S)

Re: [PATCH v2] diagnostics: Add %{...%} pretty-format support for URLs and use it in -Wpsabi diagnostcs

On Wed, Apr 29, 2020 at 10:25:38AM -0400, David Malcolm wrote: > > I'd prefer not to at this point, all that could be commonized are > > the two inform calls perhaps with a bool or enum arg which one it is, > > but usually the backends prefer to keep their -Wpsabi stuff visible > > there. > > Yes,

Re: [PATCH v2] diagnostics: Add %{...%} pretty-format support for URLs and use it in -Wpsabi diagnostcs

On Wed, 2020-04-29 at 15:52 +0200, Jakub Jelinek wrote: > On Wed, Apr 29, 2020 at 09:24:09AM -0400, David Malcolm wrote: [...] > > There's some pre-existing repetition between arm, aarch64, and > > rs6000, > > in which this patch has to make the same changes in multiple > > places. > > Could

[committed] Fix a couple more instruction length issues on the H8 port

And another case were the H8 port had the wrong lengths which resulted in using a short branch instead of the necessary long branch and the short branch going off into never-never land. It usually "worked" anyway, but if addresses in the C runtime line up just right we'd get a fault. I know

Re: [Patch, Fortran] OpenMP/OpenACC – fix more issues with OPTIONAL

Hi Thomas, was a bit on the backburner but I now digged again. See: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94848 The problem is a generated static array variable in the device function: static integer(kind=4) A.12[3] = {1, 2, 3}; used as _26 = A.12[S.13_67]; With -ftree-pre, the

[PATCH v2] diagnostics: Add %{...%} pretty-format support for URLs and use it in -Wpsabi diagnostcs

On Wed, Apr 29, 2020 at 09:24:09AM -0400, David Malcolm wrote: > Overall I like the idea; some nits inline below (and I think it won't > bootstrap due to a const-correctness issue). I'll start a bootstrap soon. > Ideally we ought to have an integration test for this in DejaGnu > somewhere,

Re: [PATCH] rs6000: Fix rs6000_atomic_assign_expand_fenv [PR94826]

On Wed, Apr 29, 2020 at 7:48 AM Jakub Jelinek wrote: > > Hi! > > This is the rs6000 version of the earlier committed x86, aarch64 and arm > fixes, as create_tmp_var_raw is used because the C FE can call this outside > of function context, we need to make sure the first references to those >

Re: [PATCH] diagnostics: Add %{...%} pretty-format support for URLs and use it in -Wpsabi diagnostcs

On Wed, 2020-04-29 at 14:46 +0200, Jakub Jelinek wrote: > Hi! > > The following patch attempts to use the diagnostics URL support if > available > to provide more information about the C++17 empty base and C++20 > [[no_unique_address]] empty class ABI changes in -Wpsabi diagnostics. > > GCC 10.1

Re: [wwwdocs] Correct status and macro for P1907R1

On Wed, Apr 29, 2020 at 10:51:21AM +0100, Jonathan Wakely wrote: > As noted in PR c++/94765 floating point types are not supported as > non-type template args. > > Marek added the P1907R1 paper in commit d59a823fb but didn't give it a > distinct entries for the "Supported in GCC?" and "SD-6

Re: [PATCH] diagnostics: Add %{...%} pretty-format support for URLs and use it in -Wpsabi diagnostcs

Jakub Jelinek via Gcc-patches writes: > @@ -5747,16 +5748,18 @@ rs6000_discover_homogeneous_aggregate (m > unsigned uid = TYPE_UID (TYPE_MAIN_VARIANT (type)); > if (uid != last_reported_type_uid) > { > + const char *url > +

RE: [PATCH]use vnode->get_constructor () to get intial in lto[PR94822]

Hi Richard, Thanks you for your reply. And sorry for not responding in time. The reason why the ctor_for_folding was not used here before is that the variable here is read-only, and ctor_for_folding would return error_mark_node. If I want to keep the size check for array, I had to skip the

[PATCH] diagnostics: Add %{...%} pretty-format support for URLs and use it in -Wpsabi diagnostcs

Hi! The following patch attempts to use the diagnostics URL support if available to provide more information about the C++17 empty base and C++20 [[no_unique_address]] empty class ABI changes in -Wpsabi diagnostics. GCC 10.1 at the end of the diagnostics is then in some terminals underlined with

RE: [PATCH][GCC-8][Aarch64]: Backport Force TImode values into even registers

> -Original Message- > From: Andre Vieira (lists) > Sent: 29 April 2020 13:37 > To: gcc-patches@gcc.gnu.org > Cc: Kyrylo Tkachov > Subject: [PATCH][GCC-8][Aarch64]: Backport Force TImode values into even > registers > > Hi, > > This is a backport from trunk/gcc-9 that I think we need

[PATCH][GCC-8][Aarch64]: Backport Force TImode values into even registers

Hi, This is a backport from trunk/gcc-9 that I think we need now that we have backported the casp LSE instructions. Bootstrapped and regression tested on aarch64. Is this OK for gcc-8? Cheers, Andre The LSE CASP instruction requires values to be placed in even register pairs.  A solution

Re: [PATCH] x86: Allow -fcf-protection with external thunk

On Wed, Apr 29, 2020 at 5:02 AM H.J. Lu wrote: > > On Tue, Apr 28, 2020 at 11:38 PM Richard Biener > wrote: > > > > On Wed, Apr 29, 2020 at 4:22 AM H.J. Lu via Gcc-patches > > wrote: > > > > > > Allow -fcf-protection with external thunk since the external thunk can be > > > made compatible with

Re: [PATCH, PR94769] fortran/io.c: Fix use of uninitialized variable num

On Wed, Apr 29, 2020 at 01:53:01PM +0200, Stefan Schulze Frielinghaus wrote: > Hi Tobias, > > On Tue, Apr 28, 2020 at 05:06:15PM +0200, Tobias Burnus wrote: > > Hi Stefan, > > > > I prefer Jakub's suggestion – his change LGTM. > > Please find attached an updated patch. Bootstrapped and

Re: [PATCH] x86: Allow -fcf-protection with external thunk

On Tue, Apr 28, 2020 at 11:38 PM Richard Biener wrote: > > On Wed, Apr 29, 2020 at 4:22 AM H.J. Lu via Gcc-patches > wrote: > > > > Allow -fcf-protection with external thunk since the external thunk can be > > made compatible with -fcf-protection. > > > > OK for master? > > OK. I guess also OK

Re: [PATCH, PR94769] fortran/io.c: Fix use of uninitialized variable num

Hi Tobias, On Tue, Apr 28, 2020 at 05:06:15PM +0200, Tobias Burnus wrote: > Hi Stefan, > > I prefer Jakub's suggestion – his change LGTM. Please find attached an updated patch. Bootstrapped and regtested on S/390. Ok for master? Cheers, Stefan > On 4/28/20 2:30 PM, Jakub Jelinek via

[PATCH] rs6000: Fix rs6000_atomic_assign_expand_fenv [PR94826]

Hi! This is the rs6000 version of the earlier committed x86, aarch64 and arm fixes, as create_tmp_var_raw is used because the C FE can call this outside of function context, we need to make sure the first references to those VAR_DECLs are through a TARGET_EXPR, so that it gets gimple_add_tmp_var

Re: [PATCH] x86: Fix -O0 remaining intrinsic macros [PR94832]

On Wed, Apr 29, 2020 at 1:11 PM Jakub Jelinek wrote: > > Hi! > > A few other macros seem to suffer from the same issue. What I've done was: > cat gcc/config/i386/*intrin.h | sed -e ':x /\\$/ { N; s/\\\n//g ; bx }' \ > | grep '^[[:blank:]]*#[[:blank:]]*define[[:blank:]].*(' | sed 's/[ ]\+/

Re: [PATCH] x86: Fix -O0 intrinsic *gather*/*scatter* macros [PR94832]

On Wed, Apr 29, 2020 at 1:04 PM Jakub Jelinek wrote: > > Hi! > > As reported in the PR, while most intrinsic -O0 macro argument uses > are properly wrapped in ()s or used in context where having a complex > expression passed as the argument doesn't pose a problem (e.g. when > macro argument use

[PATCH] x86: Fix -O0 remaining intrinsic macros [PR94832]

Hi! A few other macros seem to suffer from the same issue. What I've done was: cat gcc/config/i386/*intrin.h | sed -e ':x /\\$/ { N; s/\\\n//g ; bx }' \ | grep '^[[:blank:]]*#[[:blank:]]*define[[:blank:]].*(' | sed 's/[ ]\+/ /g' \ > /tmp/macros and then looking for regexps: )[a-zA-Z] )

[committed] doc: Add missing arm_arch_v8a_hard_ok anchor

Fix a missing anchor in my earlier arm patch. Sorry for the breakage. Clearly I didn't test the doc part properly in the rush to get this out. (The code itself was fully tested as committed, honest.) Richard 2020-04-29 Richard Sandiford gcc/ * doc/sourcebuild.texi: Add missing

[PATCH] x86: Fix -O0 intrinsic *gather*/*scatter* macros [PR94832]

Hi! As reported in the PR, while most intrinsic -O0 macro argument uses are properly wrapped in ()s or used in context where having a complex expression passed as the argument doesn't pose a problem (e.g. when macro argument use is in between commas, or between ( and comma, or between comma and )

Re: [committed] aarch64: Fix parameter passing for [[no_unique_address]]

On Wed, Apr 29, 2020 at 11:48:51AM +0100, Richard Sandiford wrote: > Jakub Jelinek writes: > > On Wed, Apr 29, 2020 at 10:57:24AM +0100, Richard Sandiford wrote: > >> This patch makes the ABI code ignore zero-sized [[no_unique_address]] > >> fields when deciding whether something is a HFA or HVA.

[PATCH] coroutines: Improve error recovery [PR94817, PR94829].

Hi, When we have completely missing key information (e.g. the coroutine_traits) or a partially transformed function body, we need to try and balance returning useful information about failures with the possibility that some part of the diagnostics machinery or following code will not be able to

Re: [committed] aarch64: Fix parameter passing for [[no_unique_address]]

Jakub Jelinek writes: > On Wed, Apr 29, 2020 at 10:57:24AM +0100, Richard Sandiford wrote: >> This patch makes the ABI code ignore zero-sized [[no_unique_address]] >> fields when deciding whether something is a HFA or HVA. > > As you use cxx17_empty_base_field_p, can you please remove the FIXME >

RE: [PATCH] arm: Fix parameter passing for [[no_unique_address]]

Hi Richard, > -Original Message- > From: Richard Sandiford > Sent: 29 April 2020 11:04 > To: gcc-patches@gcc.gnu.org > Cc: ni...@redhat.com; Richard Earnshaw ; > Ramana Radhakrishnan ; Kyrylo > Tkachov > Subject: [PATCH] arm: Fix parameter passing for [[no_unique_address]] > > This

Re: [PATCH] arm: Extend the PR94780 fix to arm

On Wed, Apr 29, 2020 at 11:30 AM Richard Sandiford wrote: > > Essentially the same fix as for x86. > > Tested on arm-linux-gnueabihf and armeb-eabi. Bordering on the obvious > I guess, but OK to install? > > Richard > Ok. Ramana > > 2020-04-29 Richard Sandiford > > gcc/ > *

[PATCH] arm: Extend the PR94780 fix to arm

Essentially the same fix as for x86. Tested on arm-linux-gnueabihf and armeb-eabi. Bordering on the obvious I guess, but OK to install? Richard 2020-04-29 Richard Sandiford gcc/ * config/arm/arm-builtins.c (arm_atomic_assign_expand_fenv): Use TARGET_EXPR instead of

[PATCH] lto/94822 - fix ICE in component_ref_size

Bootstrapped/tested on x86_64-unknown-linux-gnu, pushed. This ICE appears because gcc will stream it to the function_body section when processing the variable with the initial value of the constructor type, and the error_mark_node to the decls section. When recompiling, the value obtained with

Re: [committed] aarch64: Fix parameter passing for [[no_unique_address]]

On Wed, Apr 29, 2020 at 10:57:24AM +0100, Richard Sandiford wrote: > This patch makes the ABI code ignore zero-sized [[no_unique_address]] > fields when deciding whether something is a HFA or HVA. As you use cxx17_empty_base_field_p, can you please remove the FIXME in calls.h because it then

[PATCH] arm: Fix parameter passing for [[no_unique_address]]

This patch makes the ABI code ignore zero-sized [[no_unique_address]] fields when deciding whether something is a HFA or HVA. For the tests, I wanted an -march setting that was stable enough to use check-function-bodies and also wanted to force -mfloat-abi=hard. I couldn't see any existing way of

Re: [Patch, Fortran] OpenMP/OpenACC – fix more issues with OPTIONAL

Hi Tobias! Do you happen to have any update regarding this one: On 2020-01-08T09:55:06+0100, Tobias Burnus wrote: > On 1/8/20 9:33 AM, Thomas Schwinge wrote: >> With 'dg-do run' added, on [...] x86_64-pc-linux-gnu with offloading I'm >> seeing: | PASS:

[committed] aarch64: Fix parameter passing for [[no_unique_address]]

This patch makes the ABI code ignore zero-sized [[no_unique_address]] fields when deciding whether something is a HFA or HVA. As things stood, we'd get two sets of -Wpsabi warnings, one when trying to decide whether something was an SVE function, and another when actually processing the function

[wwwdocs] Correct status and macro for P1907R1

As noted in PR c++/94765 floating point types are not supported as non-type template args. Marek added the P1907R1 paper in commit d59a823fb but didn't give it a distinct entries for the "Supported in GCC?" and "SD-6 Feature Test" columns. This keeps it grouped with P0732R2 but in its own row.

[committed] testsuite: Save dg-do-what-default in mve.exp

mve.exp changed the default dg-do action to "assemble", but then left it like that for later exp files. This meant that in a two-multilib test run, the first arm.exp run would have a default of "dg-do compile" and the second would have a default of "dg-do assemble". Tested on arm-linux-gnueabihf

Re: [PATCH] Add OpenACC 2.6 `acc_get_property' support

Hi! On 2019-12-17T00:00:04+0100, I wrote: > On 2019-11-14T16:35:31+0100, Frederik Harwath > wrote: >> this patch implements OpenACC 2.6 "acc_get_property" and related functions. > As I mentioned before ("thinking aloud"): > > | [...] 'acc_device_current' [is] relevant only for > |

Harden and adjust 'gcc/configure' parsing of '--enable-offload-targets' (was: [committed] Simplify omp-device-properties.h creation (PR bootstrap/92314))

Hi Jakub! On 2019-11-02T00:38:02+0100, Jakub Jelinek wrote: > Apparently my recent change broke quite a lot of setups where people were > configuring --enable-offload-targets= without having the corresponding > offloading compiler already installed. > The following patch simplifies it by

Re: [Patch][AMD GCN][OpenMP] Add gcc/config/gcn/t-omp-device for OpenMP declare variant kind/arch/isa

Hi! On 2019-11-04T17:35:32+0100, Jakub Jelinek wrote: > On Mon, Nov 04, 2019 at 04:33:27PM +, Andrew Stubbs wrote: >> On 04/11/2019 15:37, Jakub Jelinek wrote: >> > My preference would be that arch on amdgcn is something like amdgcn or gcn. >> > I hope the general distinction between arch

[committed] libphobos: Fix KERNEL_VERSION condition in libphobos testsuite

Hi, This patch fixes an effective target check in the libphobos testsuite. A typo in the macro call meant that the #error always triggered. Regression tested on x86_64-linux-gnu with multilib configurations {-m64,-m32,-mx32}, committed to mainline. Regards Iain. --- libphobos/ChangeLog:

Re: [PATCH]use vnode->get_constructor () to get intial in lto[PR94822]

On Wed, Apr 29, 2020 at 8:44 AM Richard Biener wrote: > > On Wed, Apr 29, 2020 at 6:04 AM lizekun (A) wrote: > > > > Hi, > > > > This ICE appears because gcc will stream it to the function_body section > > when processing the > > variable with the initial value of the constructor type, and the

[committed] d: Merge bug fix from upstream dmd 06160ccae

Hi, This patch adds classKind information to the front-end AST, which in turn allows us to fix code generation of type names for extern(C) and extern(C++) structs and classes. Inspecting such types inside a debugger now just works without the need to cast(module_name.cxx). Bootstrapped on

Re: [rtl] Harden 'set_noop_p' for non-constant selectors [PR94279]

Hi! On 2020-04-22T18:23:24+0100, Richard Sandiford wrote: > Andrew Stubbs writes: >> On 22/04/2020 17:43, Thomas Schwinge wrote: >>> In "[amdgcn] internal compiler error: RTL >>> check: expected code 'const_int', have 'reg' in rtx_to_poly_int64, at >>>

Re: [committed] libphobos: Add power*-*-linux* as a supported target

On 28/04/2020 19:12, Segher Boessenkool wrote: > Hi! > > On Sun, Apr 26, 2020 at 11:35:21AM +0200, Iain Buclaw wrote: >> This patch adds power*-*-linux* as a supported target for libphobos. > > Many thanks for doing this! > > A problem though: libphobos/libdruntime is built for -m32 as well,

[gcn] Set 'UI_NONE' for 'TARGET_EXCEPT_UNWIND_INFO' [PR94282] (was: [PATCH] amdgcn: Add stub personality function)

Hi! On 2020-04-23T13:05:33+0200, I wrote: > On 2020-04-23T09:15:29+0100, Andrew Stubbs wrote: >> On 22/04/2020 22:10, Kwok Cheung Yeung wrote: >>> [...] allows the following tests in the libgomp >>> testsuite that were previously failing with a linker error to compile >>> and run, provided that

Re: [PATCH v3 04/10] GCN machine description

Hi! On 2018-12-12T11:52:23+, Andrew Stubbs wrote: > This patch contains the machine description portion of the GCN > back-end. > --- /dev/null > +++ b/gcc/config/gcn/gcn.md > +(define_insn_and_split "*mov_insn" > + [(set (match_operand:DIDF 0 "nonimmediate_operand" > +

[gcn] Don't default to building target-libstdc++-v3 [PR92713] (was: [PATCH v3 06/10] GCN back-end config)

Hi! On 2018-12-12T11:52:53+, Andrew Stubbs wrote: > This patch contains the configuration adjustments needed to enable the GCN > back-end. In addition to default-enabling libgomp, which Tobias already pushed to master branch in commit 29b1533acd5c57e3e327261b0054d0ee2858a166 "configure -

Re: [AMD GCN] Use 'radeon' for the environment variable 'ACC_DEVICE_TYPE'

Hi! On 2020-04-23T17:27:45+0100, Andrew Stubbs wrote: > On 21/04/2020 13:24, Thomas Schwinge wrote: >> [...], what about the user-visible 'gcn' in the >> 'ACC_DEVICE_TYPE' environment variable? As I'd quoted in >> : >> >> |

Re: [Patch][OpenMP][Fortran] Support absent optional args with use_device_{ptr, addr} (+ OpenACC's use_device clause)

Hi! On 2019-11-11T13:14:43+0100, I wrote: > On 2019-11-08T16:41:23+0100, Tobias Burnus wrote: >> --- /dev/null >> +++ b/libgomp/testsuite/libgomp.fortran/use_device_ptr-optional-2.f90 > > When adding '{ dg-do run }' for torture testing (please remember to), I > see the '-O0' and '-O1' execution

Re: [PATCH] Add value range info for affine combination to improve store motion (PR83403)

On 2020/4/28 18:30, Richard Biener wrote: > > OK, I guess instead of get_range_info expr_to_aff_combination could > simply use determine_value_range (op0, , ) == VR_RANGE > (the && TREE_CODE (op0) == SSA_NAME check can then be removed)? > Tried with determine_value_range, it works and is

RE: [PATCH PR94708] [8/9/10 Regression] pr94780.c fails with ICE on aarch64

Thanks for your suggestions. I have modified accordingly. Is the v2 patch ok? Please help install it this patch is ok, as I am not a committer. >From 15d8675676b3fcced3fa5695b3d9c37f3ec3be18 Mon Sep 17 00:00:00 2001 From: Haijian Zhang Date: Wed, 29 Apr 2020 15:00:00 +0800 Subject: [PATCH]

[PATCH] aarch64: prefer using csinv, csneg in zero extend contexts

Hello, The attached patch adds an optimization to the AArch64 backend to catch additional cases where we can use csinv and csneg. Given the C code: unsigned long long inv(unsigned a, unsigned b, unsigned c) { return a ? b : ~c; } Prior to this patch, AArch64 GCC at -O2 generates: inv:

Re: [PATCH PR94708] [8/9/10 Regression] pr94780.c fails with ICE on aarch64

On Wed, Apr 29, 2020 at 07:16:53AM +, Zhanghaijian (A) wrote: > 2020-04-29 Haijian Zhang Two spaces before < rather than just one. > PR target/94820 > * config/aarch64/aarch64-builtins.c > (aarch64_atomic_assign_expand_fenv): Use TARGET_EXPR instead

[PATCH PR94708] [8/9/10 Regression] pr94780.c fails with ICE on aarch64

Hi This is a simple fix for pr94820. The PR was only fixed on i386, the same error was also reported on aarch64. This function, because it is sometimes called even outside of function bodies, uses create_tmp_var_raw rather than create_tmp_var. But in order for that to work, when first

Re: [PATCH]use vnode->get_constructor () to get intial in lto[PR94822]

On Wed, Apr 29, 2020 at 6:04 AM lizekun (A) wrote: > > Hi, > > This ICE appears because gcc will stream it to the function_body section when > processing the > variable with the initial value of the constructor type, and the > error_mark_node to the > decls section. When recompiling, the value

Re: [PATCH]use vnode->get_constructor () to get intial in lto[PR94822]

On Wed, Apr 29, 2020 at 6:04 AM lizekun (A) wrote: > > Hi, > > This ICE appears because gcc will stream it to the function_body section when > processing the > variable with the initial value of the constructor type, and the > error_mark_node to the > decls section. When recompiling, the value

Re: [PATCH] x86: Allow -fcf-protection with external thunk

On Wed, Apr 29, 2020 at 4:22 AM H.J. Lu via Gcc-patches wrote: > > Allow -fcf-protection with external thunk since the external thunk can be > made compatible with -fcf-protection. > > OK for master? OK. I guess also OK for backporting to branches where CET support is in a reasonable state (not

Re: [RFC] Clarify -ffinite-math-only documentation

On Tue, Apr 28, 2020 at 10:54 PM Sandra Loosemore wrote: > > On 4/27/20 9:08 AM, Matthias Kretz wrote: > > > > @item -ffinite-math-only > > @opindex ffinite-math-only > > -Allow optimizations for floating-point arithmetic that assume > > -that arguments and results are not NaNs or +-Infs. > >

Re: [PATCH, PR94774] tree-optimization: Fix use of uninitialized variable

On Tue, Apr 28, 2020 at 6:14 PM Martin Sebor via Gcc-patches wrote: > > On 4/27/20 10:58 AM, Stefan Schulze Frielinghaus wrote: > > Array retval is not necessarily initialized by function is_call_safe and > > may be used afterwards. Thus, initialize it explicitly. > > > > Ok for master? > > The