[PATCH] widening_mul: Fix a > ~b to .ADD_OVERFLOW optimization [PR98256]

Hi! Unfortunately, my latest tree-ssa-math-opts.c patch broke the following testcase. The problem is that the code is adding .ADD_OVERFLOW or .SUB_OVERFLOW before or after the stmt on which the function has been called, which is normally a addition or subtraction that has all the operands. But

[patch, fortran, committed] Improved parse dump for coarrays

Hello world, I have just committed as obvious and simple (and as no-user-impact) an improvement to the tree dump, plus the ability to call debug(array_reference) in the debugger. The revision is r11-5967. The dump for a coarray assignment now looks like ASSIGN main:a(FULL)[THIS_IMAGE]

Re: [patch, fortran] Optionally improve debugging of auxiliary variables

Thomas Koenig via Fortran wrote: Hello world, I have struggled with debugging the GENERIC generated by the Fortran front end because it is only possible to look at the code via -fdump-tree-original, but it is not possible to inspect the values; additionally, the D.3456 form makes it hard to

Re: [patch, fortran] Optionally improve debugging of auxiliary variables

Hi Thomas, Thomas Koenig wrote: If it’s part of a symbol used by the rest of the toolchain (assembler, linker debugger) then it’s also important to note that some OS/tool pairs might be more constrained than the one you’ve tested. In particular, some assemblers will not accept all

Re: [patch, fortran] Optionally improve debugging of auxiliary variables

Thomas Koenig via Fortran wrote: yes a configure option is a possible way around a conflict. I was thinking more along making it a run-time option. This is an option which will only be used by a developer, who should know what the source code contains and what the tool chain supports (and

Re: [PATCH] Limit perf data buffer during feature checking

On 12/9/20 5:45 AM, Ilya Leoshkevich via Gcc-patches wrote: > Bootstrapped and regtested on x86_64-redhat-linux. Ok for master? > > Commit 2ead1ab91123 ("Limit perf data buffer during profiling") added > -m8 to perf invocations during running tests, but the same problem > exists for checking

Re: [PATCH] Fix up testcase.

On 12/9/20 3:24 AM, Hongtao Liu via Gcc-patches wrote: > On Wed, Dec 9, 2020 at 5:22 PM Prathamesh Kulkarni via Gcc-patches > wrote: >> On Wed, 9 Dec 2020 at 00:29, sunil.k.pandey wrote: >>> On Linux/x86_64, >>> >>> 3a6e3ad38a17a03ee0139b49a0946e7b9ded1eb1 is the first bad commit >>> commit

Re: [committed] Fix non-unique testnames

On 12/7/20 9:19 AM, Martin Sebor wrote: > On 12/4/20 3:17 PM, Jeff Law via Gcc-patches wrote: >> >> >> On 12/4/20 2:55 PM, Mike Stump wrote: >>> On Nov 30, 2020, at 8:00 AM, Jeff Law via Gcc-patches >>> wrote: This patch fixes a handful of tests with non-unique names which confuse

Re: [PATCH] add g_nonstandard_bool attribute for GIMPLE FE use

On 12/11/20 2:02 AM, Richard Biener wrote: > This adds __attribute__((g_nonstandard_bool(precision))) to be able > to construct nonstandard boolean types which for the included testcase > is needed to simulate Ada and LTO interaction (Ada uses a 8 bit > precision boolean_type_node). This will

[PATCH] Fix _GLIBCXX_DEBUG tests

Some tests are XPASS because array assertions have been disabled for a good reason in C++11. I wonder if the respective non-constexpr _GLIBCXX_ASSERTION checks shouldn't target C++14 too. At the moment they are failing as expected but because of an Undefined Behavior no ? The other test is

Re: [PATCH] varasm, v2: Reject soft frame or arg pointer registers for register vars [PR92469]

On 12/10/20 8:11 AM, Jakub Jelinek wrote: > On Thu, Dec 10, 2020 at 12:00:17PM +0100, Jakub Jelinek wrote: >> So, would it be better to check for one of FRAME_POINTER_REGNUM, >> ARG_POINTER_REGNUM or RETURN_ADDRESS_POINTER_REGNUM if they >> are mentioned in (from part of pairs in)

[C PATCH] Drop qualifiers of assignment expressions [PR 97981]

Here is a patch to drop qualifiers in assignment expressions. -- Martin C: Drop qualifiers of assignment expressions. [PR98047] ISO C17 6.5.15.1 specifies that the result is the type the LHS would have after lvalue conversion. 2020-12-12  Martin Uecker   gcc/c/  PR c/98047

Re: rs6000: Update the processor defaults for FreeBSD

Hello, this is only default tuning (-mtune, not -mcpu). Linux also does similarly in linux64.h: 74 #undef PROCESSOR_DEFAULT 75 #define PROCESSOR_DEFAULT PROCESSOR_POWER7 76 #undef PROCESSOR_DEFAULT64 77 #define PROCESSOR_DEFAULT64 PROCESSOR_POWER8 Although there is hard to

Re: [PATCH] VAX: Fix lower bound adjustment with `casesi'

On 12/10/20 4:20 AM, Maciej W. Rozycki wrote: > Fix an issue with the `casesi' expander using `GEN_INT' to produce the > constant rtx for lower bound adjustment. This generates a VOIDmode > value which may overflow the SImode range required for the operand to > stay within to satisfy

Re: [PATCH 1/3] VAX: Remove unused register allocation from QMATH DImode add/sub handler

On 12/11/20 1:47 PM, Maciej W. Rozycki wrote: > An allocation is made for a temporary register, however it is unneeded, > as actually explained in the comment preceding the conditional block in > question, and consequently never used, so remove it. The `temp' rtx is > already used elsewhere

Re: [RFC] [avr] Toolchain Integration for Testsuite Execution (avr cc0 to mode_cc0 conversion)

On 12/12/20 11:33 AM, abebeos wrote: > > > On Sat, 12 Dec 2020 at 01:15, Segher Boessenkool > mailto:seg...@kernel.crashing.org>> wrote: > > On Fri, Dec 11, 2020 at 11:20:01PM +0200, abebeos wrote: > > Στις Παρ, 11 Δεκ 2020 στις 11:00 μ.μ., ο/η Segher Boessenkool < > >

Re: [PATCH] doc: Remove -mcet

On 12/6/20 8:09 AM, H.J. Lu via Gcc-patches wrote: > -mcet was removed by > > commit 231baae28ef7ff784683fa5a80df119da2b9a99b > Author: H.J. Lu > Date: Tue Apr 24 16:56:04 2018 + > > x86/CET: Remove the -mcet command-lint option > > PR target/98162 > * doc/extend.texi:

Re: rs6000: Update the processor defaults for FreeBSD

On Sun, Dec 13, 2020 at 01:10:58AM +0100, Gerald Pfeifer wrote: > Piotr is the one spending most times on ensuring FreeBSD ports work > fine on POWER, so personally I'm happy to follow his recommendation > on such matters. I have a question though: > -/* Until now the 970 is the only Processor

Re: [patch, fortran] Optionally improve debugging of auxiliary variables

Hi Iain, yes a configure option is a possible way around a conflict. I was thinking more along making it a run-time option. This is an option which will only be used by a developer, who should know what the source code contains and what the tool chain supports (and who can try out an

Re: rs6000: Update the processor defaults for FreeBSD

Hi! On Sun, Dec 13, 2020 at 03:34:57PM +0100, Piotr Kubaj wrote: > this is only default tuning (-mtune, not -mcpu). It is both, actually (-mcpu= implies -mtune=) > Linux also does similarly in linux64.h: > 74 #undef PROCESSOR_DEFAULT > 75 #define PROCESSOR_DEFAULT PROCESSOR_POWER7 >

PING^1: V3 [PATCH 0/2] Switch to a new section if the SECTION_RETAIN bit doesn't match

On Tue, Dec 8, 2020 at 4:51 AM H.J. Lu wrote: > > When SECTION_RETAIN is used, definitions marked with used attribute and > unmarked definitions are placed in a section with the same name. Instead > of issue an error: > > [hjl@gnu-cfl-2 gcc]$ /usr/gcc-11.0.0-x32/bin/gcc -S c.c >

Re: [PATCH 2/3] VAX: Handle constant 0 with QMATH DImode add/sub

On 12/11/20 1:48 PM, Maciej W. Rozycki wrote: > Handle constant 0 passed to the QMATH DImode add/sub handler such as > with: > > #2 0x11d409b0 in gen_adddi3 (operand0=0x75c0a128, > operand1=0x75c60480, operand2=0x75c60470) > at .../gcc/config/vax/vax.md:755 > 755

Re: [PATCH 3/3] VAX: Handle subtracting from self with QMATH DImode add/sub

On 12/11/20 1:48 PM, Maciej W. Rozycki wrote: > Remove an assertion the failure of which has not been actually observed, > but which appears clearly dangerous, for when the QMATH DImode add/sub > handler is invoked with the subtrahend and the minuend both the same. > Instead handle the

Re: [PATCH 2/2] VAX: Unify push operation selection

On 12/12/20 5:05 AM, Maciej W. Rozycki wrote: > Avoid the possibility of code discrepancies like one fixed with the > previous change and improve the structure of code by selecting between > push and non-push operations in a single place in `vax_output_int_move'. > > The PUSHAB/MOVAB address

Re: [PATCH 1/2] VAX: Check the correct operand for constant 0 push operation

On 12/12/20 5:05 AM, Maciej W. Rozycki wrote: > Check the output operand for representing pushing a value onto the stack > rather than the constant 0 input in determining whether to use the PUSHL > or the CLRL instruction for a SImode move. The latter actually works by > means of using the

Re: [patch, fortran] Optionally improve debugging of auxiliary variables

Hi Iain, If it’s part of a symbol used by the rest of the toolchain (assembler, linker debugger) then it’s also important to note that some OS/tool pairs might be more constrained than the one you’ve tested.  In particular, some assemblers will not accept all characters in an  identifier.

[C PATCH] Avoid incorrect warning for volatile in compound expressions [PR 98260]

Here is a patch that fixes an incorrect warning for volatile that appeared with the lvalue change.  -- Martin C: Avoid incorrect warning for volatile in compound expressions [PR98260] 2020-12-12  Martin Uecker   gcc/c/  PR c/98260  * c-parser.c (c_parser_expression): Look into

Re: [PATCH] sanitizer: do not ICE for pointer cmp/sub

On 12/10/20 1:31 AM, Martin Liška wrote: > Hello. > > In C FE we have troubles to instrument top-level pointer comparison > (and subtraction): > > /home/marxin/Programming/gcc/gcc/testsuite/c-c++-common/asan/pr98204.c:5:1: > internal compiler error: in pointer_diff, at c/c-typeck.c:3954 >   

Re: introduce overridable clear_cache emitter

On 12/10/20 3:58 AM, Alexandre Oliva wrote: > On Dec 3, 2020, Alexandre Oliva wrote: > >> +local_define_builtin ("__builtin___clear_cache", ftype, >> + BUILT_IN_CLEAR_CACHE, >> + "__builtin___clear_cache", >> + ECF_NOTHROW); >

Re: [PATCH] widening_mul: Fix a > ~b to .ADD_OVERFLOW optimization [PR98256]

On December 13, 2020 12:02:48 PM GMT+01:00, Jakub Jelinek wrote: >Hi! > >Unfortunately, my latest tree-ssa-math-opts.c patch broke the following >testcase. The problem is that the code is adding .ADD_OVERFLOW or >.SUB_OVERFLOW before or after the stmt on which the function has been >called,

Re: [RFC] [avr] Toolchain Integration for Testsuite Execution (avr cc0 to mode_cc0 conversion)

On Sun, Dec 13, 2020 at 09:49:25AM -0700, Jeff Law wrote: > On 12/12/20 11:33 AM, abebeos wrote: > > Here it is: > > > > https://gcc.gnu.org/pipermail/gcc-patches/2020-December/561718.html > > > > > > My understanding is that

Re: [PATCH] correct -Wmismatched-new-delete (PR 98160, 98166)

On 12/8/20 1:46 PM, Martin Sebor wrote: > PR 98160 reports an ICE in pretty printer code called from the newly > added -Wmismatched-new-delete.  The ICE is just a simple oversight, > but much more interesting is the warning issued for the test case. > It highlights an issue I didn't consider in

Re: [19/23] rtlanal: Add some new helper classes

On 11/13/20 1:20 AM, Richard Sandiford via Gcc-patches wrote: > This patch adds some classes for gathering the list of registers > and memory that are read and written by an instruction, along > with various properties about the accesses. In some ways it's > similar to the information that DF

Re: [PATCH] PR target/98152: Checking python is available before using

On 12/5/20 11:12 PM, Kito Cheng wrote: > We'll try to canonicalize the arch string for --with-arch, > and the script is written in python, however it will turns out > GCC require python to build for RISC-V port, it's not expect as > the GCC requirement. > > So this patch is made this as

Re: [RFC] [avr] Toolchain Integration for Testsuite Execution (avr cc0 to mode_cc0 conversion)

On Fri, 11 Dec 2020 at 20:32, Jeff Law wrote: > > > On 12/9/20 6:12 AM, abebeos via Gcc-patches wrote: > > Essence: > > > > I need a confirmation that the testsuite setup as presented in: > > > > https://github.com/abebeos/avr-gnu > > > > works fine. > > > > The problem with the avr target is

Re: [patch, fortran] Optionally improve debugging of auxiliary variables

Hi Iain, I guess the hard thing is for the developer to know that (s)he wants the option and what to do when a conflict occurs. Actually, I just hit on a much simpler solution. We translate all symbols to lower case (except for those with BIND(C), which do not matter in this context). So,

Re: [PATCH] Fix _GLIBCXX_DEBUG tests

On 13/12/20 15:52 +0100, François Dumont via Libstdc++ wrote: Some tests are XPASS because array assertions have been disabled for a good reason in C++11. I wonder if the respective non-constexpr _GLIBCXX_ASSERTION checks shouldn't target C++14 too. At the moment they are failing as expected

Re: [patch, fortran] Optionally improve debugging of auxiliary variables

Hi Thomas, Thomas Koenig via Fortran wrote: I guess the hard thing is for the developer to know that (s)he wants the option and what to do when a conflict occurs. Actually, I just hit on a much simpler solution. :) .. I’m all in favour of simplicity. We translate all symbols to lower

Re: [PATCH 2/3] VAX: Handle constant 0 with QMATH DImode add/sub

On Sun, 13 Dec 2020, Jeff Law wrote: > > gcc/ > > * config/vax/vax.c (vax_expand_addsub_di_operands): Handle the > > addition or subtraction of 0. > OK, though I would have generally expected something to catch this earlier. Doesn't it matter that this pattern is produced in the

Re: [PATCH] Correct -fdump-go-spec's handling of incomplete types

On 12/10/20 4:44 PM, Rainer Orth wrote: I'm attaching the -save-temps output, so you can work on the real data rather than trying to figure things out from the Illumos repos. Thanks, that was helpful. I also have successfully acquired access to gcc211, so I should be self sufficient moving

[PATCH] PR fortran/95372 - ICE in find_array_section, at fortran/expr.c:1687

ICE on valid code. Original patch by Steve, slightly adjusted and regtested on x86_64-pc-linux-gnu. OK for master? Backports? Should be safe everywhere, as it replaces an assert by an if condition. Thanks, Harald PR fortran/95372 - ICE in find_array_section, at fortran/expr.c:1687 Fix

Re: [PATCH] Correct -fdump-go-spec's handling of incomplete types

On 12/13/20 4:55 PM, Nikhil Benesch wrote: There are a few more hurdles before this patch is ready for commit. The changes to godump.c deserve new test cases. [...] Updated patch attached, as promised, and is ready for review. gcc/: * godump.c (go_output_typedef): Suppress typedefs

Re: [RFC] [avr] Toolchain Integration for Testsuite Execution (avr cc0 to mode_cc0 conversion)

On Fri, 11 Dec 2020 at 20:32, Jeff Law wrote: I'm definitely curious about the testing setup and whether or not it can be replicated into our Jenkins setup. Hi, Jeff. The gcc testsuite setup is described in the readme of avrtest:

Re: [PATCH] avr: cc0 to mode_cc conversion

On Sun, 13 Dec 2020 at 20:51, Georg-Johann Lay wrote: > > (I really tried to follow this > https://gcc.gnu.org/contribute.html#patches, > > but my stomach) > > > > Hi there all! > > > > The attached patch contains a new avr-backend, stripped from cc0. > > > > The author is gcc maintainer Snethil

Re: [PATCH] add g_nonstandard_bool attribute for GIMPLE FE use

On 12/11/20 2:02 AM, Richard Biener wrote: This adds __attribute__((g_nonstandard_bool(precision))) to be able to construct nonstandard boolean types which for the included testcase is needed to simulate Ada and LTO interaction (Ada uses a 8 bit precision boolean_type_node). This will also be

Re: [C PATCH] Avoid incorrect warning for volatile in compound expressions [PR 98260]

On 12/13/20 9:12 AM, Uecker, Martin wrote: Here is a patch that fixes an incorrect warning for volatile that appeared with the lvalue change. It's helpful to mention the bug id in the first line of the regression tests committed with the fix. (No need to repost the patch just with that

Re: [RFC] [avr] Toolchain Integration for Testsuite Execution (avr cc0 to mode_cc0 conversion)

On Thu, 10 Dec 2020 at 15:57, abebeos wrote: > > > Στις Πέμ, 10 Δεκ 2020 στις 7:42 π.μ., ο/η Dimitar Dimitrov < > dimi...@dinux.eu> έγραψε: > >> On сряда, 9 декември 2020 г. 15:12:49 EET abebeos via Gcc-patches wrote: >> > Essence: >> > >> > I need a confirmation that the testsuite setup as

Re: [PATCH] Fix _GLIBCXX_DEBUG tests

On 13/12/20 11:17 pm, Jonathan Wakely wrote: On 13/12/20 15:52 +0100, François Dumont via Libstdc++ wrote: Some tests are XPASS because array assertions have been disabled for a good reason in C++11. I wonder if the respective non-constexpr _GLIBCXX_ASSERTION checks shouldn't target C++14

Re: [PATCH] Correct -fdump-go-spec's handling of incomplete types

On Sun, Dec 13, 2020 at 3:30 PM Nikhil Benesch wrote: > > On 12/13/20 4:55 PM, Nikhil Benesch wrote: > > There are a few more hurdles before this patch is ready for commit. The > > changes to godump.c deserve new test cases. [...] > > Updated patch attached, as promised, and is ready for review.