Fix handling of deferred SSA names in modref

Hi, in the testcase we fail to analyze SSA name because flag do_dataflow is set and thus triggers early exist in analyze_ssa_name. Fixed by disabling early exits when handling deferred names. Bootstrapped/regtested x86_64-linux, comitted. gcc/ChangeLog: 2021-12-20 Jan Hubicka PR

Re: [PATCH v3 06/12] LoongArch Port: Builtin macros.

Hi, I've bootstraped the patch with my GNU-stack fix (https://github.com/loongson/gcc/pull/62) and --enable-werror-always. Bootstrap succeeded, but with some warnings: ../../gcc/config/loongarch/loongarch.md:3205:1: warning: operand 0 missing mode?

Re: [PATCH v8 2/2] Don't move cold code out of loop by checking bb count

On Wed, Dec 8, 2021 at 7:32 AM Xionghu Luo wrote: > > > > On 2021/12/7 20:17, Richard Biener wrote: > >>> + class loop *coldest_loop = coldest_outermost_loop[loop->num]; > >>> + if (loop_depth (coldest_loop) < loop_depth (outermost_loop)) > >>> +{ > >>> + class loop *hotter_loop =

Re: [PATCH 2/2] Use dominators to reduce ranger cache-flling.

On Tue, Dec 7, 2021 at 3:16 PM Andrew MacLeod wrote: > > On 12/7/21 02:12, Richard Biener wrote: > > On Mon, Dec 6, 2021 at 7:39 PM Andrew MacLeod wrote: > >> On > >> Well, its only does the fill now when there is range info located on an > >> outgoing edge of the dominator. Its still used,

[PATCH, rs6000] Implement mffscrni pattern

Hi, I modified the patch according to David and Segher's advice. This patch defines a pattern for mffscrni. If the RN is a constant, it can call gen_rs6000_mffscrni directly. The "rs6000-builtin-new.def" defines prototype for builtin arguments. The pattern "rs6000_set_fpscr_rn" is then

Re: [PATCH] [i386] Optimize bit_and op1 float_vector_all_ones_operands to op1.

On Thu, Dec 16, 2021 at 1:59 PM liuhongt wrote: > > Bootstrapped and regtested on x86_64-pc-linux-gnu{-m32,}. > Ok for trunk? Pushed to trunk. > > gcc/ChangeLog: > > PR target/98468 > * config/i386/sse.md (*bit_and_float_vector_all_ones): New > pre-reload splitter. > >

[r12-6066 Regression] FAIL: g++.dg/modules/xtreme-header_a.H -std=c++2b (internal compiler error: tree check: expected none of template_decl, have template_decl in add_specializations, at cp/module.cc

On Linux/x86_64, 6bcb6ed5a44b6f271891246ef7ae568bfdc14e9c is the first bad commit commit 6bcb6ed5a44b6f271891246ef7ae568bfdc14e9c Author: Matthias Kretz Date: Wed Dec 15 09:45:06 2021 +0100 c++: don't ICE on NAMESPACE_DECL inside FUNCTION_DECL caused FAIL:

[PATCH 2/2] libphobos: don't compile empty switchcontext.S

If it does not contain any files, then there is no point compiling it. Skipping this saves some milliseconds and ~650 bytes in libgphobos.a. --- libphobos/configure.ac| 1 + libphobos/libdruntime/Makefile.am | 2 ++ .../libdruntime/config/x86/switchcontext.S

[PATCH 1/2] libphobos: fix CET for non-glibc targets

On musl, linking against libphobos fails because it requires ucontext but is not explicitly linked against it. This is caused by configure assuming that it is implemented in assembly, but it is actually not implemented. This silently works on other libcs because context API does not require an

Re: [patch, Fortran] IEEE support for aarch64-apple-darwin

Hi Thomas, > OK, and thanks for the patch! Thanks for the review, committed a slightly amended patch as 220b9bdfe8faebdd2aea0ab7cea81c162d42d8e0 with underflow control support added. FX ieee.patch Description: Binary data

Re: [patch, Fortran] Make REAL(KIND=16) detection more robust

Hi Thomas, > I am not sure the logic is correct for POWER (old style) where we have > a 16-byte long double made up from two 8-byte doubles, which is not > __float128 (IFmode) As written, the patch should be a no-op for existing platforms. I know about the ppc double-double "long double" type,

[PATCH] Change the xfail in gcc.dg/uninit-pr89230-1.c

From: Andrew Pinski With the recent PHI-OPT patch for line numbers, I had missed this testcase was now failing. The uninitialized warning was there before my recent patch, just was on the wrong line. The testcase had added an xfail in r12-4698-gf6d012338 (though a bug report was not filed to

Fix early exit in modref_merge_call_site_flags

Hi, when adding support for static chain and return slot flags I forgot to update early exit condition in modref_merge_call_site_flags. This yields to wrong code as demonstrated by the Fortran testcase attached to PR (which I hope someone will help me to turn into testuite one).

[PATCH] gcc: pass-manager: Fix memory leak. [PR jit/63854]

This patch fixes a memory leak in the pass manager. In the existing code, the m_name_to_pass_map is allocated in pass_manager::register_pass_name, but never deallocated. This is fixed by adding a deletion in pass_manager::~pass_manager. Moreover the string keys in m_name_to_pass_map are all

Re: [patch, Fortran] IEEE support for aarch64-apple-darwin

Hi FX, Since support for target aarch64-apple-darwin has been submitted for review, it’s time to submit the Fortran part, i.e. enabling IEEE support on that target. The patch has been in use now for several months, in a developer branch shipped by some distros on macOS (including

Re: [patch, Fortran] Make REAL(KIND=16) detection more robust

Hi FX, I am not sure the logic is correct for POWER (old style) where we have a 16-byte long double made up from two 8-byte doubles, which is not __float128 (IFmode), see https://gcc.gnu.org/pipermail/fortran/2021-November/056912.html I have a proposal: Since I am currently trying to unravel

Re: [PATCH] config: Add check whether D compiler works (PR103528)

> On 18/12/2021 22:30 Segher Boessenkool wrote: > > > On Fri, Dec 17, 2021 at 12:12:28AM +0100, Iain Buclaw wrote: > > Hi, > > > > This patch extends AC_PROG_GDC so that as well as checking for the > > existence of a GDC compiler, also validate that it has also been built > > with libphobos,

[PATCH] ix86: Don't match the 'm' constraint on x86_64_general_operand

x86_64_general_operand is different from general_operand for 64-bit target. To avoid LRA selecting a memory operand which doesn't satisfy x86_64_general_operand for 64-bit target: 1. Add a 'BM' constraint which is similar to the 'm' constraint, but checks x86_64_general_operand for integers > 16

[r12-6061 Regression] FAIL: gcc.dg/uninit-pr89230-1.c (test for bogus messages, line 21) on Linux/x86_64

On Linux/x86_64, d957d250942b130142c62afa1a67146b655b91d7 is the first bad commit commit d957d250942b130142c62afa1a67146b655b91d7 Author: Andrew Pinski Date: Sat Dec 18 11:52:37 2021 + Improve location for new statements in match-and-simplify phiopt caused FAIL:

Re: [PATCH] Testsuite: mark two tests that require alias

> I think such patches are OK under the "trivial and obvious rules”. Committed as ba64166bf81b6eaa6e12e1aab786f22f6605401f FX

Re: [PATCH] Testsuite: mark two tests that require alias

Hi FX > On 19 Dec 2021, at 11:26, FX wrote: > Not sure who can review/approve this patch. These two tests have been failing > on darwin, apparently since they were introduced earlier this year. Mark them > with dg-require-alias. > > Tested on aarch64-apple-darwin21. > OK to commit? I think

[PATCH] Testsuite: mark two tests that require alias

Hi, Not sure who can review/approve this patch. These two tests have been failing on darwin, apparently since they were introduced earlier this year. Mark them with dg-require-alias. Tested on aarch64-apple-darwin21. OK to commit? FX alias.patch Description: Binary data

Re: [patch] Fix libfortran/98507, handling of timezone near year boundaries

Hi FX, DATE_AND_TIME can return incorrect values for non-UTC timezones, near the new year, when the local time and UTC time are in different years. https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98507 Attached patch fixes the issue by correcting the logic to account for that wrapping of