Re: V2 [PATCH 3/3] Build x86 libatomic with -march=i486 or better

On Thu, Jan 14, 2021 at 04:08:20PM -0800, H.J. Lu wrote: I think best would be to revert the i386-options.c change until this is all fixed, keeping the trunk broken too long is undesirable. Second, I didn't mean to talk specifically about libatomic, but about all the 3 configure.tgt changes. And

Re: [patch] gcc.dg/analyzer tests: relax dependency on alloca.h

Hi Alex, > On 14 Jan 2021, at 22:13, Alexandre Oliva wrote: > > Hello, Olivier, > > On Dec 18, 2020, Olivier Hainque wrote: > >> Ping for https://gcc.gnu.org/pipermail/gcc-patches/2020-October/557548.html >> (copied below for convenience), please ? > > I think defining alloca as a macro in a

Re: [PATCH] keep scope blocks for all inlined functions (PR 98664)

On Thu, Jan 14, 2021 at 8:13 PM Martin Sebor via Gcc-patches wrote: > > One aspect of PR 98465 - Bogus warning stringop-overread for std::string > is the inconsistency between -g and -g0 which turns out to be due to > GCC eliminating apparently unused scope blocks from inlined functions > that are

Re: [PATCH] combine: zeroing cost for new copies

Hi Segher, Thanks for the comments! on 2021/1/15 上午4:43, Segher Boessenkool wrote: > Hi! > > On Wed, Dec 09, 2020 at 05:49:53PM +0800, Kewen.Lin wrote: >> This patch is to treat those new pseudo-to-pseudo copies >> after hard-reg-to-pseudo-copy as zero costs. The >> justification is that these

Re: [PATCH] rs6000: Use rldimi for vec init instead of shift + ior

Hi Segher, on 2021/1/15 上午8:50, Segher Boessenkool wrote: > Hi! > > On Tue, Dec 22, 2020 at 04:08:26PM +0800, Kewen.Lin wrote: >> This patch is to make unsigned int vector init go with >> rldimi to merge two integers instead of shift and ior. >> >> I tried to use nonzero_bits in md file to make i

[PATCH] c++: ICE with USING_DECL redeclaration [PR98687]

My recent patch that introduced push_using_decl_bindings didn't handle USING_DECL redeclaration, therefore things broke. This patch amends that. Note that I don't know if the other parts of finish_nonmember_using_decl are needed (e.g. the binding->type setting) -- I couldn't trigger it by any of

[PATCH 2/2] Power10: Add IEEE 128-bit fp conditional move.

[PATCH 2/2] Power10: Add IEEE 128-bit fp conditional move. This patch adds the support for power10 IEEE 128-bit floating point conditional move and for automatically generating min/max. Unlike the previous patch, I decided to keep two separate patterns for fpmask before splitting (one pattern for

[PATCH 1/2] Power10: Add IEEE 128-bit min/max support.

[PATCH 1/2] Power10: Add IEEE 128-bit min/max support. This patch adds the support for the IEEE 128-bit floating point C minimum and maximum instructions. The next patch will add the support for using the compare and set mask instruction to implement conditional moves. Rather than trying to over

[PATCH 0/2] PowerPC: Add power10 IEEE 128-bit min/max/cmove

These patches have been kicking around for awhile, and I really would like to get them in. They aren't as important as the other float128 patches I've submitted today, since many of those patches are designed to allow switching the long double format to IEEE 128-bit, which we need in GCC 11. I ha

[PATCH 3/3] PowerPC: Force IBM long double for conversion test.

[PATCH 3/3] PowerPC: Force IBM long double for conversion test. The test c-c++-common/dfp/convert-bfp-11.c explicit expects long double to use the IBM 128-bit extended double format. In particular, some of the tests expect an infinity to be created if decimal values that are converted that are to

[PATCH 2/3] PowerPC: PR target/70117, Force long double to be IBM 128-bit.

[PATCH 2/3] PowerPC: PR target/70117, Force long double to be IBM 128-bit. This patch fixes the pr70117 test to use IBM 128-bit long double. I have run tests on a little endian power9 system with 3 compilers: * One compiler using the default IBM 128-bit format; * One compiler using th

[PATCH 1/3] PowerPC: Add long double target-supports.

[PATCH 1/3] PowerPC: Add long double target-supports. This patch add several more selections to target-supports.exp: * 3 selections for the current long double format; * 3 selections if we can change the long double format to a particular value. * 3 functions to return t

[PATCH 0/3] PowerPC: Fix up tests for IEEE 128-bit long double

In November, I submitted a patch to fix up some of the tests for when IEEE 128-bit is used as the long double format. Segher had some suggestions. These patches are based on those suggestions: https://gcc.gnu.org/pipermail/gcc-patches/2020-November/559836.html These patches add several more sele

Re: Ping ^ 4: [PATCH 3/4] rs6000: Enable vec_insert for P8 with rs6000_expand_vector_set_var_p8

Ping^4, thanks. On 2020/12/23 10:18, Xionghu Luo via Gcc-patches wrote: Ping^3 for stage 3. And this followed patch: [PATCH 4/4] rs6000: Update testcases' instruction count. Thanks:) On 2020/12/3 22:16, Xionghu Luo via Gcc-patches wrote: Ping. Thanks. On 2020/11/27 09:04, Xionghu Luo via

Go patch committed: Add support for reading embedcfg files

This patch to the Go frontend adds support for reading embedcfg files. An embedcfg file is a JSON file created by the go command when it sees a go:embed directive, and passed to the Go frontend via the new -fgo-embedcfg option. This code is not yet called, and does not yet do anything. It's being

Re: [PATCH] libstdc++: c++2b, implement WG21 P1679R3

On Thu, Jan 14, 2021 at 5:06 PM Jonathan Wakely wrote: > > On 13/01/21 01:21 +, Paul Fee via Libstdc++ wrote: > >Add contains member function to basic_string_view and basic_string. > > > >The new method is enabled for -std=gnu++20, gnu++2b and c++2b. This allows > >users to access the method

[PATCH v2] libstdc++: C++23, implement WG21 P1679R3

Add contains member function to basic_string_view and basic_string. The new method is enabled for -std=gnu++20, gnu++2b and c++2b. This allows users to access the method as a GNU extension to C++20. The conditional test may be reduced to "__cplusplus > 202011L" once GCC has a c++2b switch. Chan

Re: [PATCH] rs6000: Use rldimi for vec init instead of shift + ior

Hi! On Tue, Dec 22, 2020 at 04:08:26PM +0800, Kewen.Lin wrote: > This patch is to make unsigned int vector init go with > rldimi to merge two integers instead of shift and ior. > > I tried to use nonzero_bits in md file to make it more > general, but the testing shows it isn't doable. The > reas

Re: [PATCH/RFC] combine: Tweak the condition of last_set invalidation

Hi! On Wed, Dec 16, 2020 at 04:49:49PM +0800, Kewen.Lin wrote: > When I was investigating unsigned int vec_init issue on Power, > I happened to find there seems something we can enhance in how > combine pass invalidate last_set (set last_set_invalid nonzero). > > Currently we have the check: > >

V2 [PATCH 3/3] Build x86 libatomic with -march=i486 or better

On Thu, Jan 14, 2021 at 3:01 PM Jakub Jelinek wrote: > > On Thu, Jan 14, 2021 at 01:04:31PM -0800, H.J. Lu via Gcc-patches wrote: > > If x86 libatomic isn't compiled with -march=i486 or better, append > > -march=i486 XCFLAGS for x86 libatomic build. Set try_ifunc to yes > > if -mcx16 isn't used t

Re: [committed] jit: remove "Alpha" warning from docs

David Malcolm writes: > On Thu, 2021-01-14 at 23:23 +0100, Andrea Corallo wrote: >> Hi Dave and all, >> >> libgccjit is still advertized as alpha state in the documentation >> despite having being introduced few years ago. >> >> I think we may want to evaluate to promote it as beta with the >>

[committed] jit: remove "Alpha" warning from docs

On Thu, 2021-01-14 at 23:23 +0100, Andrea Corallo wrote: > Hi Dave and all, > > libgccjit is still advertized as alpha state in the documentation > despite having being introduced few years ago. > > I think we may want to evaluate to promote it as beta with the > following > motivations: > > - T

Re: [PATCH 3/3] Build x86 libatomic with -march=i486 or better

On Thu, Jan 14, 2021 at 01:04:31PM -0800, H.J. Lu via Gcc-patches wrote: > If x86 libatomic isn't compiled with -march=i486 or better, append > -march=i486 XCFLAGS for x86 libatomic build. Set try_ifunc to yes > if -mcx16 isn't used to compile x86-64 libatomic or -march=i686 or > better isn't used

Re: Add dg-require-wchars to libstdc++ testsuite

On Jan 14, 2021, Jonathan Wakely wrote: > The problem is that uses wchar_t in default > template arguments: > I think we should fix the header, not disable tests that don't use > that default template argument. The attached patch should allow you to > use wstring_convert and wbuffer_convert wit

Re: [PATCH] Handle fancy_abort before diagnostic initialization [PR98586]

On Tue, 2021-01-12 at 08:44 +0100, Richard Biener wrote: > On Mon, Jan 11, 2021 at 10:57 PM David Malcolm via Gcc-patches > wrote: > > If fancy_abort is called before the diagnostic subsystem is > > initialized, > > internal_error will crash internally in a way that prevents a > > useful > > messa

Re: [PATCH/RFC] Add GCC_EXTRA_DIAGNOSTIC_OUTPUT environment variable for fix-it hints

On Thu, Jan 14, 2021 at 4:34 PM David Malcolm via Gcc-patches wrote: ... > > One remaining issue raised in that Emacs bug is the encoding of these > > lines, and, indeed, the encoding of GCC's stderr in general: > > currently we emit a mixture of bytes and UTF-8; I believe we emit > > filenames as

[PATCH 2/2] PowerPC: Use __builtin_pack_ibm128 instead of __builtin_pack_longdouble.

[PATCH 2/2] PowerPC: Use __builtin_pack_ibm128 instead of __builtin_pack_longdouble. In the patch submitted on October 22nd, 2020: https://gcc.gnu.org/pipermail/gcc-patches/2020-October/556869.html https://gcc.gnu.org/pipermail/gcc-patches/2020-October/557529.html Segher suggested that rather th

[PATCH 1/2] PowerPC: Allow __ibm128 on older systems.

[PATCH 1/2] PowerPC: Allow __ibm128 on older systems. In the patch submitted on October 22nd, 2020: https://gcc.gnu.org/pipermail/gcc-patches/2020-October/556869.html https://gcc.gnu.org/pipermail/gcc-patches/2020-October/557529.html Segher suggested that rather than add #ifdef code in libgcc's i

[PATCH 0/2] PowerPC: Add __ibm128 to PowerPC targets without float128 support

In the patch submitted on October 22nd, 2020: https://gcc.gnu.org/pipermail/gcc-patches/2020-October/556869.html https://gcc.gnu.org/pipermail/gcc-patches/2020-October/557529.html Segher suggested that rather than add #ifdef code in libgcc's ibm-ldouble.c to use __builtin_pack_ibm128 instead of __

Re: [PATCH/RFC] Add GCC_EXTRA_DIAGNOSTIC_OUTPUT environment variable for fix-it hints

On Sat, 2020-11-14 at 14:43 -0500, David Malcolm wrote: > GCC has had the ability to emit fix-it hints in machine-readable form > since GCC 7 via -fdiagnostics-parseable-fixits and > -fdiagnostics-generate-patch. > > The former emits additional specially-formatted lines to stderr; the > option and

[PATCH, rs6000] Update pr88233.c test (pr91799)

[PATCH, rs6000] Update pr88233.c test (pr91799) Hi, This is a follow-up fix to clean up pr91799. Per review of test results, it appears that the combination of target and dg-require stanzas is not sufficient to properly limit the test to 64-bit only on darwin. This adds additional clauses to li

Re: The performance data for two different implementation of new security feature -ftrivial-auto-var-init

Hi, More data on code size and compilation time with CPU2017: Compilation time data: the numbers are the slowdown against the default “no”: benchmarks A/no D/no 500.perlbench_r 5.19% 1.95% 502.gcc_r 0.46% -0.23% 505.mcf_r

Re: [patch] gcc.dg/analyzer tests: relax dependency on alloca.h

Hello, Olivier, On Dec 18, 2020, Olivier Hainque wrote: > Ping for https://gcc.gnu.org/pipermail/gcc-patches/2020-October/557548.html > (copied below for convenience), please ? I think defining alloca as a macro in analyzer-alloca.h might conflict with system headers included before or after an

[PATCH]middle-end (committed) slp: Add Tests for complex mul, mls and mla"

Hi All, This adds the initial tests for the complex mul, mls and mla. These will be enabled in the commits that add the optabs. Bootstrapped Regtested on aarch64-none-linux-gnu and no issues. Committed as obvious variations of existing tests. Thanks, Tamar gcc/testsuite/ChangeLog: * g

[PATCH 3/3] Build x86 libatomic with -march=i486 or better

If x86 libatomic isn't compiled with -march=i486 or better, append -march=i486 XCFLAGS for x86 libatomic build. Set try_ifunc to yes if -mcx16 isn't used to compile x86-64 libatomic or -march=i686 or better isn't used to compile x86 libatomic. PR target/70454 * configure.tgt (XCFL

[PATCH 0/3] Build x86 libitm/libgomp/libatomic with -march=i486 or better

Starting from commit 77d372abec0fbf2cfe922e3140ee3410248f979e Author: H.J. Lu Date: Thu Jan 14 05:56:46 2021 -0800 x86: Error on -fcf-protection with incompatible target GCC issues an error on -fcf-protection with incompatible target. CET is enabled in run-time libraries on x86 when GCC

[PATCH 2/3] Build x86 libgomp with -march=i486 or better

If x86 libgomp isn't compiled with -march=i486 or better, append -march=i486 XCFLAGS for x86 libgomp build. PR target/70454 * configure.tgt (XCFLAGS): Append -march=i486 to compile x86 libgomp if needed. --- libgomp/configure.tgt | 36

[PATCH 1/3] Build x86 libitm with -march=i486 or better

If x86 libitm isn't compiled with -march=i486 or better, append -march=i486 XCFLAGS for x86 libitm build. PR target/70454 * configure.tgt (XCFLAGS): Append -march=i486 to compile x86 libitm if needed. --- libitm/configure.tgt | 39 +++ 1

RE: [EXTERNAL] Re: [PATCH][tree-optimization]Optimize combination of comparisons to dec+compare

I got more feedback for the patch from Gabriel Ravier and Jakub Jelinek in https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96674 and re-worked it accordingly. The changes from the previous patch are: 1. Switched the tests to use __attribute__((noipa)) instead of __attribute__((noinline)) . 2. Fixed

[committed] analyzer: fixes to -fdump-analyzer-json

I've been implementing a PyGTK viewer for the output of -fdump-analyzer-json, to help me debug analyzer issues: https://github.com/davidmalcolm/gcc-analyzer-viewer The viewer is very much just a work in progress. This patch adds some fields that were missing from the dump, and fixes some mistake

[committed] analyzer: const fixes [PR98679]

Successfully bootstrapped & regrtested on x86_64-pc-linux-gnu. Pushed to master as r11-6689-g8a18261afd923151b8d2a37f667e4673b27acd3f gcc/analyzer/ChangeLog: PR analyzer/98679 * analyzer.h (region_offset::operator==): Make const. * pending-diagnostic.h (pending_diagnostic::

Re: [PATCH] combine: zeroing cost for new copies

Hi! On Wed, Dec 09, 2020 at 05:49:53PM +0800, Kewen.Lin wrote: > This patch is to treat those new pseudo-to-pseudo copies > after hard-reg-to-pseudo-copy as zero costs. The > justification is that these new copies are closely after > the corresponding hard-reg-to-pseudo-copy insns, register > all

Re: [r11-6672 Regression] Failed to bootstrap on Linux/x86_64

On Thu, Jan 14, 2021 at 12:33 PM Jakub Jelinek wrote: > > On Thu, Jan 14, 2021 at 10:52:24AM -0800, sunil.k.pandey via Gcc-patches > wrote: > > On Linux/x86_64, > > It breaks x86_64-linux build pretty much everywhere. > libatomic (but as well libgomp and libitm) uses -march=i486 in certain cases.

Re: [PATCH v2] Add --ld-path= to specify an arbitrary executable as the linker

On Thu, Jan 14, 2021 at 12:21:05PM -0800, Fangrui Song wrote: > On 2021-01-14, Martin Liška wrote: > > On 1/14/21 11:07 AM, Richard Biener wrote: > > > I see no particular reason to allow arbitrary garbage to be used as > > > linker. It just asks for users to shoot themselves in the foot and > > >

Re: [r11-6672 Regression] Failed to bootstrap on Linux/x86_64

On Thu, Jan 14, 2021 at 10:52:24AM -0800, sunil.k.pandey via Gcc-patches wrote: > On Linux/x86_64, It breaks x86_64-linux build pretty much everywhere. libatomic (but as well libgomp and libitm) uses -march=i486 in certain cases. While for --with-arch or --with-arch_32 configured compilers it woul

Re: [PATCH v2] Add --ld-path= to specify an arbitrary executable as the linker

On 2021-01-14, Martin Liška wrote: On 1/14/21 11:07 AM, Richard Biener wrote: I see no particular reason to allow arbitrary garbage to be used as linker. It just asks for users to shoot themselves in the foot and for strange bugreports to pop up. Well, for a strange bug report, we'll see even

[pushed] c++: Tweak g++.dg/template/pr98372.C.

This test was failing in C++11 because variable templates are only available in C++14. Tested x86_64-pc-linux-gnu, applying to trunk. gcc/testsuite/ChangeLog: * g++.dg/template/pr98372.C: Only run in C++14 and up. --- gcc/testsuite/g++.dg/template/pr98372.C | 2 +- 1 file changed, 1 ins

Re: [PATCH] libgomp_g.h: Include stdint.h instead of gstdint.h

Hi! On 2019-09-30T00:03:00-0700, Frederik Harwath wrote: > The patch changes libgomp/libgomp_g.h to include stdint.h instead of the > internal gstdint.h. The inclusion of gstdint.h has been > introduced by GCC trunk r265930, presumably because this introduced uses of > uintptr_t. Since gstdint.

Re: [PATCH] libstdc++/98466 Fix _GLIBCXX_DEBUG N3644 integration

On 14/01/21 19:33 +0100, François Dumont wrote: On 14/01/21 6:10 pm, Jonathan Wakely wrote: On 01/01/21 18:51 +0100, François Dumont via Libstdc++ wrote: I think the PR is not limited to unordered containers iterator, it impacts all _GLIBCXX_DEBUG iterators. However unordered containers l

[gcn offloading] Only supported in 64-bit configurations (was: [PATCH 7/7 libgomp,amdgcn] GCN Libgomp Plugin)

Hi! On 2019-11-12T13:29:16+, Andrew Stubbs wrote: > This patch contributes the GCN libgomp plugin, with the various > configure and make bits to go with it. > --- a/libgomp/plugin/configfrag.ac > +++ b/libgomp/plugin/configfrag.ac > + amdgcn*) > + case "${target}" in > + x86_

[PATCH 2/2] RTEMS: Add -mcustom-fpu-cfg=fph2 multilib

This multilib supports Nios II configurations with the "Nios II Floating Point Hardware 2 Component". gcc/ * config/nios2/t-rtems: Reset all MULTILIB_* variables. Shorten multilib directory names. Use MULTILIB_REQUIRED instead of MULTILIB_EXCEPTIONS. Add -mhw-mul -mhw-m

[PATCH 1/2] nios2: Add -mcustom-fpu-cfg=fph2

The new -mcustom-fpu-cfg=fph2 option variant is useful to build a multilib for the "Nios II Floating Point Hardware 2 Component": https://www.intel.com/content/dam/www/programmable/us/en/pdfs/literature/ug/ug_nios2_custom_instruction.pdf Directly using the corresponding -mcustom-insn=N options fo

[PATCH] keep scope blocks for all inlined functions (PR 98664)

One aspect of PR 98465 - Bogus warning stringop-overread for std::string is the inconsistency between -g and -g0 which turns out to be due to GCC eliminating apparently unused scope blocks from inlined functions that aren't explicitly declared inline and artificial. PR 98664 tracks just this part

Re: calibrate intervals to avoid zero in futures poll test

On Jan 14, 2021, Jonathan Wakely wrote: >> + /* Got for some 10 cycles, but we're already past that and still > I can't parse "Got for some 10 cycles". If that's just a typo Yeah, I meant "Go for ... but if ..." and managed to double-mangle it. Thanks for spotting it. Here's the patch I'm

[r11-6672 Regression] Failed to bootstrap on Linux/x86_64

On Linux/x86_64, 77d372abec0fbf2cfe922e3140ee3410248f979e is the first bad commit commit 77d372abec0fbf2cfe922e3140ee3410248f979e Author: H.J. Lu Date: Thu Jan 14 05:56:46 2021 -0800 x86: Error on -fcf-protection with incompatible target caused build failure when configured with: ../gcc/

Re: [PATCH] libstdc++/98466 Fix _GLIBCXX_DEBUG N3644 integration

On 14/01/21 6:15 pm, Jonathan Wakely wrote: On 14/01/21 17:10 +, Jonathan Wakely wrote: On 01/01/21 18:51 +0100, François Dumont via Libstdc++ wrote: I think the PR is not limited to unordered containers iterator, it impacts all _GLIBCXX_DEBUG iterators. However unordered containers loca

Re: [PATCH] libstdc++/98466 Fix _GLIBCXX_DEBUG N3644 integration

On 14/01/21 6:10 pm, Jonathan Wakely wrote: On 01/01/21 18:51 +0100, François Dumont via Libstdc++ wrote: I think the PR is not limited to unordered containers iterator, it impacts all _GLIBCXX_DEBUG iterators. However unordered containers local_iterator was more complicated to handle. Becau

[PATCH] c-family, v2: Improve MEM_REF printing for diagnostics [PR98597]

On Thu, Jan 14, 2021 at 10:49:42AM -0700, Martin Sebor wrote: > > In the light of Martins patch this is probably reasonable but still > > the general direction is wrong (which is why I didn't approve Martins > > original patch). I'm also somewhat disappointed we're breaking this > > so late in the

[nvptx libgomp plugin] Build only in supported configurations (was: [nvptx offloading] Only 64-bit configurations are currently supported)

Hi! On 2015-07-08T17:03:02+0200, I wrote: > On Wed, 18 Feb 2015 09:50:15 +0100, I wrote: >> So far, we have concentrated only on the 64-bit x86_64 configuration; >> 32-bit has several known issues to be resolved. >> filed. (This still holds, and is unlikely to ever g

Re: [Patch, RFC] PR fortran/93340 - [8/9/10/11 Regression] fix missed substring simplifications

Hi Harald, It looks OK to me. I can see why you are asking about the implementation but cannot offer a better solution. OK for master. Thanks Paul On Tue, 12 Jan 2021 at 22:03, Harald Anlauf via Fortran wrote: > Dear all, > > when playing around with the issues exposed by PR93340, particula

Re: [PATCH] PR fortran/98661 - valgrind issues with error recovery

Hi Harald, That's OK for master. Thanks Paul On Wed, 13 Jan 2021 at 21:25, Harald Anlauf via Fortran wrote: > Dear all, > > the former Fortran testcase charlen_03.f90, which some time ago used to > ICE, could still display issues during error recovery. As Dominique > pointed out, this requi

libgo patch committed: Update hurd support

This libgo patch by Svante Signell updates the hurd support. This fixes GCC PR 98496. Bootstrapped and ran Go testsuite on x86_64-pc-linux-gnu. Committed to mainline. Ian ab5bf5f728be354427a5b06784f34011fea555bc diff --git a/gcc/go/gofrontend/MERGE b/gcc/go/gofrontend/MERGE index cd95c3d0755..8

Re: [PATCH] c-family: Improve MEM_REF printing for diagnostics [PR98597]

On 1/14/21 12:43 AM, Richard Biener wrote: On Wed, 13 Jan 2021, Jakub Jelinek wrote: Hi! The following patch doesn't actually fix the print_mem_ref bugs, I've kept it for now as broken as it was, but at least improves the cases where we can unambiguously map back MEM[&something + off] into som

Re: [PATCH v5] rtl: builtins: (not just) rs6000: Add builtins for fegetround, feclearexcept and feraiseexcept [PR94193]

On Thu, Jan 07, 2021 at 11:20:39AM -0300, Raoni Fassina Firmino wrote: > On Wed, Nov 18, 2020 at 06:38:22AM -0600, Segher Boessenkool wrote: > > We can handle the constants issue similarly to what we do for > > __builtin_fpclassify, too. > > I think that if we must safe-guard for future or unfores

[PATCH 2/2] PowerPC: PR 97791: Do not set gnu attributes on moves

>From 84ae44abc7a79b9c2e6d9f18a30516d3e8f65b1f Mon Sep 17 00:00:00 2001 From: Michael Meissner Date: Wed, 13 Jan 2021 21:45:20 -0500 Subject: [PATCH 2/2] PowerPC: PR 97791: Do not set gnu attributes on moves This patch eliminates the code in rs6000_emit_move to set the long double attribute. Thi

[PATCH 1/2] PowerPC: PR 97791: Fix an issue with gnu attributes.

[PATCH 1/2] PowerPC: PR 97791: Fix an issue with gnu attributes. This patch patch fixes the problem that we set the GNU attribute for long double if a type were passed or returned that uses the same representation as the long double type (i.e. passing explicit __float128/_Float128 when long double

[PATCH 0/2] PowerPC: PR 97791: Fix attribute problems

There are many issues with the current implementation of GNU attributes to mark functions that use long double. The idea of .gnu_attributes was to mark objects with ABI requirements. The two patches in this thread fixes a small subset of the GNU attributes problems. It does not fix all of the pr

Re: [PATCH] libstdc++/98466 Fix _GLIBCXX_DEBUG N3644 integration

On 14/01/21 17:10 +, Jonathan Wakely wrote: On 01/01/21 18:51 +0100, François Dumont via Libstdc++ wrote: I think the PR is not limited to unordered containers iterator, it impacts all _GLIBCXX_DEBUG iterators. However unordered containers local_iterator was more complicated to handle. B

Re: [PATCH] libstdc++/98466 Fix _GLIBCXX_DEBUG N3644 integration

On 01/01/21 18:51 +0100, François Dumont via Libstdc++ wrote: I think the PR is not limited to unordered containers iterator, it impacts all _GLIBCXX_DEBUG iterators. However unordered containers local_iterator was more complicated to handle. Because of c++/65816 I prefer to review _Node_iter

[PATCH] PowerPC: Add float128/Decimal conversions.

[PATCH] PowerPC: Add float128/Decimal conversions. This patch replaces the following two patches: September 24th, 2020: Message-ID: <20200924203545.gd31...@ibm-toto.the-meissners.org> October 22nd, 2020: Message-ID: <2020100603.ga11...@ibm-toto.the-meissners.org> This patch rewrites those p

Re: [PATCH] libstdc++: c++2b, implement WG21 P1679R3

On 13/01/21 01:21 +, Paul Fee via Libstdc++ wrote: Add contains member function to basic_string_view and basic_string. The new method is enabled for -std=gnu++20, gnu++2b and c++2b. This allows users to access the method as a GNU extension to C++20. The conditional test may be reduced to "

[PATCH] PowerPC: Map IEEE 128-bit long double built-ins.

>From 78435dee177447080434cdc08fc76b1029c7f576 Mon Sep 17 00:00:00 2001 From: Michael Meissner Date: Wed, 13 Jan 2021 21:47:03 -0500 Subject: [PATCH] PowerPC: Map IEEE 128-bit long double built-ins. This patch replaces patches previously submitted: September 24th, 2020: Message-ID: <202009242031

[committed] libstdc++: Define function to throw filesystem_error [PR 98471]

Fix ordering problem on Windows targets where filesystem_error was used before being defined. libstdc++-v3/ChangeLog: PR libstdc++/98471 * include/bits/fs_path.h (__throw_conversion_error): New function to throw or abort on character conversion errors. (__wstr_from

[Patch, fortran] PR64290 - [F03] No finalization at deallocation of LHS

Hi All, This patch was triggered by a thread on clf. Some years ago Tobias and I discussed the remaining conditions where finalization should be triggered and is not. Intrinsic assignment was one of the glaring omissions for which implementation looked like a heavy lift job. As it happens, it wasn

[PATCH][pushed] gcov: add one more pytest

gcc/testsuite/ChangeLog: * g++.dg/gcov/gcov-17.C: New test. * g++.dg/gcov/test-gcov-17.py: New test. --- gcc/testsuite/g++.dg/gcov/gcov-17.C | 40 +++ gcc/testsuite/g++.dg/gcov/test-gcov-17.py | 37 + 2 files changed, 77 insertions(+)

[PATCH][pushed] mklog: skip unsupported files

This fixes an infinite loop one could see for: git show b87ec922c40 | ./contrib/mklog.py contrib/ChangeLog: * mklog.py: Fix infinite loop for unsupported files. --- contrib/mklog.py | 3 +++ 1 file changed, 3 insertions(+) diff --git a/contrib/mklog.py b/contrib/mklog.py index bf51e563

Re: [PATCH] RTEMS: Fix Ada build for riscv

This is OK, thanks. > gcc/ada/ > > PR ada/98595 > Makefile.rtl (LIBGNAT_TARGET_PAIRS) : Use > wraplf version of Aux_Long_Long_Float. > --- > gcc/ada/Makefile.rtl | 5 + > 1 file changed, 5 insertions(+) > > diff --git a/gcc/ada/Makefile.rtl b/gcc/ada/Makefile.rtl > index 8

[PATCH] RTEMS: Fix Ada build for riscv

gcc/ada/ PR ada/98595 Makefile.rtl (LIBGNAT_TARGET_PAIRS) : Use wraplf version of Aux_Long_Long_Float. --- gcc/ada/Makefile.rtl | 5 + 1 file changed, 5 insertions(+) diff --git a/gcc/ada/Makefile.rtl b/gcc/ada/Makefile.rtl index 81df1e8babc..35faf13ea46 100644 --- a/

[PATCH] i386: Resolve variable shadowing in i386-options.c [PR98671]

Also change global variable pta_size to unsigned. 2021-01-14 Uroš Bizjak gcc/ PR target/98671 * config/i386/i386-options.c (ix86_valid_target_attribute_inner_p): Remove declaration and initialization of shadow variable "ret". (ix86_option_override_internal): Remove declaration

Re: [PATCH] x86: Error on -fcf-protection with incompatible target

On Thu, Jan 14, 2021 at 6:51 AM Uros Bizjak wrote: > > On Thu, Jan 14, 2021 at 3:05 PM H.J. Lu wrote: > > > > -fcf-protection with CF_BRANCH inserts ENDBR32 at function entries. > > ENDBR32 is NOP only on 64-bit processors and 32-bit TARGET_CMOVE > > processors. Issue an error for -fcf-protectio

Re: [PATCH] i386: Update PR target/95021 tests

On Thu, Jan 14, 2021 at 4:00 PM H.J. Lu wrote: > > Also pass -mpreferred-stack-boundary=4 -mno-stackrealign to avoid > disabling STV by: > > /* Disable STV if -mpreferred-stack-boundary={2,3} or > -mincoming-stack-boundary={2,3} or -mstackrealign - the needed > stack realignment will b

Re: [PATCH] match.pd: Add ~(X - Y) -> ~X + Y simplification [PR96685]

On Thu, 14 Jan 2021, Maciej W. Rozycki wrote: > On Tue, 12 Jan 2021, Richard Biener wrote: > > > >>> The point of the match.pd changes is to canonicalize GIMPLE on some form > > >>> when there are several from GIMPLE POV equivalent or better forms of > > >>> writing > > >>> the same thing. The a

[PATCH] i386: Update PR target/95021 tests

Also pass -mpreferred-stack-boundary=4 -mno-stackrealign to avoid disabling STV by: /* Disable STV if -mpreferred-stack-boundary={2,3} or -mincoming-stack-boundary={2,3} or -mstackrealign - the needed stack realignment will be extra cost the pass doesn't take into account and the

Re: [PATCH] match.pd: Add ~(X - Y) -> ~X + Y simplification [PR96685]

On Tue, 12 Jan 2021, Richard Biener wrote: > >>> The point of the match.pd changes is to canonicalize GIMPLE on some form > >>> when there are several from GIMPLE POV equivalent or better forms of > >>> writing > >>> the same thing. The advantage of having one canonical way is that ICF, > >>> SCC

Re: [PATCH] x86: Error on -fcf-protection with incompatible target

On Thu, Jan 14, 2021 at 3:05 PM H.J. Lu wrote: > > -fcf-protection with CF_BRANCH inserts ENDBR32 at function entries. > ENDBR32 is NOP only on 64-bit processors and 32-bit TARGET_CMOVE > processors. Issue an error for -fcf-protection with CF_BRANCH when > compiling for 32-bit non-TARGET_CMOVE ta

Re: [PATCH 1/4] Remove build dependence on HSA run-time

Hi! I'm raising here an issue with HSA libgomp plugin code changes from a while ago. While HSA is now no longer relevant for GCC master branch, the same code has also been copied into the GCN libgomp plugin. This is commit b8d89b03db5f212919e4571671ebb4f5f8b1e19d (r242749) "Remove build dependen

Re: [PATCH] libstdc++: Add support for C++20 barriers

On 07/01/21 12:56 -0800, Thomas Rodgers via Libstdc++ wrote: Tested x86_64-pc-linux-gnu, committed to master. The copyright years need updating. Pushed to master. commit 194a9d67be45568d81bb8c17e9102e31c1309e5f Author: Jonathan Wakely Date: Thu Jan 14 14:25:05 2021 libstdc++: Update

RE: [PR66791][ARM] Replace __builtin_neon_vcge* with >= and <= for vcge and vcle intrinsics

Hi Prathamesh, > -Original Message- > From: Prathamesh Kulkarni > Sent: 14 January 2021 14:04 > To: gcc Patches ; Kyrylo Tkachov > > Subject: [PR66791][ARM] Replace __builtin_neon_vcge* with >= and <= for > vcge and vcle intrinsics > > Hi, > The attached patch removes __builtin_neon_vcg

Re: [PATCH]middle-end slp: elide intermediate nodes for complex add and avoid truncate

On Thu, 14 Jan 2021, Tamar Christina wrote: > Hi All, > > This applies the same feedback received for MUL and the rest to > ADD which was already committed. In short it elides the intermediate > nodes vec and avoids the use of truncate on the SLP child. > > Bootstrapped Regtested on aarch64-non

[PATCH] x86: Error on -fcf-protection with incompatible target

-fcf-protection with CF_BRANCH inserts ENDBR32 at function entries. ENDBR32 is NOP only on 64-bit processors and 32-bit TARGET_CMOVE processors. Issue an error for -fcf-protection with CF_BRANCH when compiling for 32-bit non-TARGET_CMOVE targets. gcc/ PR target/98667 * config/i38

[PR66791][ARM] Replace __builtin_neon_vcge* with >= and <= for vcge and vcle intrinsics

Hi, The attached patch removes __builtin_neon_vcge* function with >= and <= operators for vcge and vcle intrinsics respectively. Cross tested on arm*-*-*. OK for trunk ? Thanks, Prathamesh vcge-1.diff Description: Binary data

Re: [PATCH] gimple UIDs, LTO and -fanalyzer [PR98599]

> On Wed, Jan 13, 2021 at 11:04 PM David Malcolm via Gcc-patches > wrote: > > > > gimple.h has this comment for gimple's uid field: > > > > /* UID of this statement. This is used by passes that want to > > assign IDs to statements. It must be assigned and used by each > > pass. By d

Re: Split wchars tests from the normal variant

On 28/12/20 19:39 +0100, François Dumont via Libstdc++ wrote: On 22/12/20 10:27 pm, Alexandre Oliva wrote: This change extracts apart the wchar specific parts of character conversion tests to allow conditonalizating these parts on actual wchar support while applying the rest more generally. Th

Re: Split wchars tests from the normal variant

On 22/12/20 18:27 -0300, Alexandre Oliva wrote: This change extracts apart the wchar specific parts of character conversion tests to allow conditonalizating these parts on actual wchar support while applying the rest more generally. This turned out useful during our work on the libstdc++ suppor

Re: Add dg-require-wchars to libstdc++ testsuite#

On 14/01/21 13:41 +, Jonathan Wakely wrote: Is it the case that the wchar_t type is defined on this target, it's just that libc doesn't have support for wcslen etc? Because we should probably audit all our uses of _GLIBCXX_USE_WCHAR_T and find which ones actually need libc support and which

Re: Add dg-require-wchars to libstdc++ testsuite

On 22/12/20 18:12 -0300, Alexandre Oliva wrote: --- a/libstdc++-v3/testsuite/22_locale/codecvt/codecvt_utf16/79980.cc +++ b/libstdc++-v3/testsuite/22_locale/codecvt/codecvt_utf16/79980.cc @@ -16,6 +16,7 @@ // . // { dg-do run { target c++11 } } +// { dg-require-wcha

[PATCH] tree-optimization/98674 - improve dependence analysis

This improves dependence analysis on refs that access the same array but with different typed but same sized accesses. That's obviously safe for the case of types that cannot have any access function based off them. For the testcase this is signed short vs. unsigned short. Bootstrapped on x86_64

Re: [PATCH] Add pytest for a GCOV test-case

On 1/14/21 2:22 PM, Rainer Orth wrote: Hi Martin, * Besides, the test outcomes are not generic message facilities but are supposed to follow a common format: : [] with the pathname to the test relative to (in this case) gcc/testsuite. In this case, this might be something lik

Re: [PATCH] Add pytest for a GCOV test-case

Hi Martin, >>> * If we now have an (even optional) dependency on python/pytest, this >>>(with the exact versions and use) needs to be documented in >>>install.texi. >> >> Done that. > > +be installed. Some optional tests also require Python3 and pytest module. > > It would be better to be

Re: [PATCH] Add pytest for a GCOV test-case

Hi Martin, >> * Besides, the test outcomes are not generic message facilities but are >>supposed to follow a common format: >>: [] >>with the pathname to the test relative to (in this case) >>gcc/testsuite. In this case, this might be something like >>UNSUPPORTED: g++.dg/gco

  1   2   >