Re: [committed] wwwdocs: ada: Tweak link to GNAT: The GNU Ada Compiler.

Gerald, Really sorry for the long delay on this one: > > I spoke too fast, that was a 404 page. > > > > > -> > href="https://www2.adacore.com/gap-static/GNAT_Book/html/";>GNAT: > > > + https://www.adacore.com/gap-static/GNAT_Book/html/";>GNAT: > > > > Arnaud, Eric, Pierre-Marie, what do y

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

On Thu, Jan 14, 2021 at 08:43:54AM +0100, Richard Biener wrote: > > But for > > diagnostics that is what the user actually want to see IMHO. > > So on the attached testcase, instead of printing what is in left column > > it prints what is in right column: > > ((int*)t) + 3 t.u.b > >

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

On Thu, Jan 14, 2021 at 09:28:31AM +0100, Jakub Jelinek via Gcc-patches wrote: > I'm afraid yes, because it is not a toplevel routine, but something called > from the c-family pretty-printers, so it can be in the middle of arbitrary > C/C++ expressions. And printing > (3 * (access to a memory obje

[PATCH] aarch64: Reimplement vmovn_high_* intrinsics using builtins

Hi all, The vmovn_high* intrinsics are supposed to map to XTN2 instructions that narrow their source vector and instert it into the top half of the destination vector. This patch reimplements them away from inline assembly to an RTL builtin that performs a vec_concat with a truncate. Bootstrapp

[PATCH] aarch64: Reimplememnt vmovn/vmovl intrinsics with builtins instead

Hi all, Turns out __builtin_convertvector is not as good a fit for the widening and narrowing intrinsics as I had hoped. During the veclower phase we lower most of it to bitfield operations and hope DCE cleans it back up into vector pack/unpack and extend operations. I received reports that in m

[PATCH] aarch64: reimplement vqmovn_high* intrinsics using builtins

Hi all, This patch reimplements the saturating-truncate-and-insert-into-high intrinsics using the appropriate RTL codes and builtins. Bootstrapped on aarch64-none-linux-gnu and tested on aarch64_be-none-elf too. Pushing to trunk. Thanks, Kyrill gcc/ * config/aarch64/aarch64-simd.md (aar

Re: [PATCH] Add a new pattern in 4-insn combine

Segher,     Gentle ping this: https://gcc.gnu.org/pipermail/gcc-patches/2020-November/560573.html Thanks a lot. On 4/1/2021 上午 10:03, HAO CHEN GUI wrote: Segher,     Gentle ping this: https://gcc.gnu.org/pipermail/gcc-patches/2020-November/560573.html Thanks a lot. On 11/12/2020 上午 10:14

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

On 1/13/21 2:38 PM, Rainer Orth wrote: Hi Martin, On 1/6/21 12:36 AM, Jeff Law wrote: unresolved "could not find python interpreter $testcase" in run-gcov-pytest if you find the right magic in the output of your spawn. Achieved that with the updated patch. Ready for master? unfortunately,

Re: [stage1][PATCH] Change semantics of -frecord-gcc-switches and add -frecord-gcc-switches-format.

PING^2 On 1/6/21 3:21 PM, Martin Liška wrote: PING On 12/4/20 2:30 PM, Martin Liška wrote: On 12/4/20 10:03 AM, Richard Biener wrote: Otherwise 0001- looks good to me. Pushed that to master. As said I'd like to see opinions from others on the driver / backend communication for 0002. To

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

PING^3 On 1/6/21 3:22 PM, Martin Liška wrote: PING^2 On 12/4/20 2:45 PM, Martin Liška wrote: PING May I please ping the patch, it's waiting here for a review for quite some time. Thanks, Martin On 7/23/20 12:17 PM, Martin Liška wrote: On 7/21/20 6:07 AM, Fangrui Song wrote: If the value d

[PATCH] match.pd: Optimize ~(X >> Y) to ~X >> Y if ~X can be simplified [PR96688]

Hi! This patch optimizes two GIMPLE operations into just one. As mentioned in the PR, there is some risk this might create more expensive constants, but sometimes it will make them on the other side less expensive, it really depends on the exact value. And if it is an important issue, we should do

Re: [PATCH] PR target/96307: Fix KASAN option checking.

It's OK for gcc 10? I just forgot to backport that... On Fri, Nov 6, 2020 at 11:24 AM Kito Cheng wrote: > > Committed, thanks :) > > On Fri, Nov 6, 2020 at 6:21 AM Jeff Law wrote: > > > > > On 10/16/20 3:01 AM, Martin Liška wrote: > > > On 10/16/20 9:41 AM, Kito Cheng wrote: > > >> I think it is

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

On Thu, 14 Jan 2021, Jakub Jelinek wrote: > On Thu, Jan 14, 2021 at 09:28:31AM +0100, Jakub Jelinek via Gcc-patches wrote: > > I'm afraid yes, because it is not a toplevel routine, but something called > > from the c-family pretty-printers, so it can be in the middle of arbitrary > > C/C++ express

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

On Thu, 14 Jan 2021, Martin Liška wrote: > PING^3 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. Richard. > On 1/6/21 3:22 PM, Martin Liška wrote: > > PING^2 > > > > On 12

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

On Thu, Jan 14, 2021 at 11:05:40AM +0100, Richard Biener wrote: > > > Could we print > > > t.u.b > > > if the TBAA type is compatible with the type of the reference and perhaps > > > *(int*)&t.u.b > > > if it is incompatible? > > > >From the aliasing perspective that is still different, but we don'

Re: [PATCH] match.pd: Optimize ~(X >> Y) to ~X >> Y if ~X can be simplified [PR96688]

On Thu, 14 Jan 2021, Jakub Jelinek wrote: > Hi! > > This patch optimizes two GIMPLE operations into just one. > As mentioned in the PR, there is some risk this might create more expensive > constants, but sometimes it will make them on the other side less expensive, > it really depends on the exa

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

On Thu, 14 Jan 2021, Jakub Jelinek wrote: > On Thu, Jan 14, 2021 at 11:05:40AM +0100, Richard Biener wrote: > > > > Could we print > > > > t.u.b > > > > if the TBAA type is compatible with the type of the reference and > > > > perhaps > > > > *(int*)&t.u.b > > > > if it is incompatible? > > > > >

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

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-none-linux-gnu and no issues. Ok for master? Thanks, Tamar

[wwwdocs] Add "porting to" notes for libstdc++ in GCC 11

Pushed to wwwdocs. commit b1448ab2ec847fd9a8283881f620d3ace0aea8ed Author: Jonathan Wakely Date: Thu Jan 14 10:40:47 2021 + Add "porting to" notes for libstdc++ in GCC 11 diff --git a/htdocs/gcc-11/porting_to.html b/htdocs/gcc-11/porting_to.html index 4187dd8e..83227c74 100644 --- a/h

[wwwdocs] Document addition of C++ header in C++11

Pushed to wwwdocs. commit 768ecbe7af00a219cfdff9fba96874a0fe9c94bb Author: Jonathan Wakely Date: Thu Jan 14 10:41:43 2021 + Document addition of C++ header in C++11 diff --git a/htdocs/gcc-11/changes.html b/htdocs/gcc-11/changes.html index e044d710..3527428f 100644 --- a/htdocs/gcc-1

Re: [wwwdocs] Document addition of C++ header in C++11

On 14/01/21 10:42 +, Jonathan Wakely wrote: Pushed to wwwdocs. commit 768ecbe7af00a219cfdff9fba96874a0fe9c94bb Author: Jonathan Wakely Date: Thu Jan 14 10:41:43 2021 + Document addition of C++ header in C++11 Doh, that was meant to say GCC 11 not C++11.

[PATCH] i386: Fix the pmovzx SSE4.1 define_insn_and_split patterns [PR98670]

Hi! I've made two mistakes in the *sse4_1_zero_extend* define_insn_and_split patterns. One is that when it uses vector_operand, it should use Bm rather than m constraint, and the other one is that because it is a post-reload splitter it needs isa attribute to select which alternatives are valid f

Re: [PATCH] i386: Fix the pmovzx SSE4.1 define_insn_and_split patterns [PR98670]

On Thu, Jan 14, 2021 at 11:44 AM Jakub Jelinek wrote: > > Hi! > > I've made two mistakes in the *sse4_1_zero_extend* define_insn_and_split > patterns. One is that when it uses vector_operand, it should use Bm rather > than m constraint, and the other one is that because it is a post-reload > spli

[PATCH] vect: Account for unused IFN_LOAD_LANES results

At the moment, if we use only one vector of an LD4 result, we'll treat the LD4 as having the cost of a single load. But all 4 loads and any associated permutes take place regardless of which results are actually used. This patch therefore counts the cost of unused LOAD_LANES results against the fi

Re: [PATCH] vect: Account for unused IFN_LOAD_LANES results

On Thu, 14 Jan 2021, Richard Sandiford wrote: > At the moment, if we use only one vector of an LD4 result, > we'll treat the LD4 as having the cost of a single load. > But all 4 loads and any associated permutes take place > regardless of which results are actually used. > > This patch therefore

Re: [PATCH] [AVX512] Fix ICE: Convert integer mask to vector in ix86_expand_fp_vec_cmp/ix86_expand_int_vec_cmp [PR98537]

ping. On Thu, Jan 7, 2021 at 1:22 PM Hongtao Liu wrote: > > On Wed, Jan 6, 2021 at 10:39 PM Jakub Jelinek wrote: > > > > On Wed, Jan 06, 2021 at 02:49:13PM +0800, Hongtao Liu wrote: > > > ix86_expand_fp_vec_cmp/ix86_expand_int_vec_cmp are used by vec_cmpmn > > > for vector comparison to vector

GCC 11.0.0 Status Report (2021-01-14), Stage 3 closes Jan 16th

Status == GCC trunk which eventually will become GCC 11 is nearing the end of Stage 3 which will happen on Jan 17th which is when Stage 4 starts (aka regression and documentation fixes only). We have accumulated quite a number of regressions, where P1 classified regressions should be fixed

[PATCH] i386: Remove redundant assignment in i386-options.c [PR98671]

Also rename x86_prefetch_sse to ix86_prefetch_sse. 2021-01-14 Uroš Bizjak gcc/ PR target/98671 * config/i386/i386-options.c (ix86_function_specific_save): Remove redundant assignment to opts->x_ix86_branch_cost. * config/i386/i386.c (ix86_prefetch_sse): Rename from x86_pref

Re: calibrate intervals to avoid zero in futures poll test

On 05/01/21 04:44 -0300, Alexandre Oliva wrote: We get occasional failures of 30_threads/future/members/poll.cc on some platforms whose high resolution clock doesn't have such a high resolution; wait_for_0 ends up as 0, and then some asserts fail as intervals measured as longer than zero are tes

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

On 13/01/21 14:29 -0300, Alexandre Oliva wrote: On Dec 28, 2020, François Dumont wrote: On 22/12/20 10:12 pm, Alexandre Oliva wrote: Some tests uses structures from the libstdc++ that are present only if the target has a wchar.h header. However, those tests do not check that the target supp

c++: Fix erroneous parm comparison logic [PR 98372]

I flubbed an application of De Morgan's law. Let's justexpress the logic directly and let the compiler figure it out. This bug made it look like pr52830 was fixed, but it is not. PR c++/98372 gcc/cp/ * tree.c (cp_tree_equal): Correct map_context logic. g

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

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 eventually usage of the --ld-path= opti

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

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

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

[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: 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

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: 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: 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: [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

[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

[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

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

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] 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: [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] 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] 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

[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 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

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] 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

[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

[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/

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][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

[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, 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

[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] 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

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: 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++/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

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

[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

[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 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

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

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

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] 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

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

[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

[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

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

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

[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: 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

[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

[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 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

[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_

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

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.

[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 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

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 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 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] 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

[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::

[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

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

[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

[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 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 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]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

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

  1   2   >