Re: The riscv compilation chain for your own operating system cannot recognize march.

On 9/25/24 2:56 AM, Troy Mitchell via Gcc wrote: Hi everyone, I'm new to the world of gcc. I don't know if this is the right place to post, but I'm having some issues that are really annoying. I've created a Unix-like system, and although it's not very complete yet, I want to make a cross-

Re: Proposed new pass to optimise mode register assignments

On 9/7/24 7:06 PM, Andrew Carlotti wrote: On Sat, Sep 07, 2024 at 09:09:52AM +0200, Richard Biener wrote: Am 06.09.2024 um 17:38 schrieb Andrew Carlotti : Hi, I'm working on optimising assignments to the AArch64 Floating-point Mode Register (FPMR), as part of our FP8 enablement work. C

Re: Proposed new pass to optimise mode register assignments

On 9/12/24 8:22 AM, Richard Sandiford wrote: This has recently come up in the RISC-V space due to needing VXRM assignments so that we can utilize the vaaddu add-with-averaging instructions.Placement of VXRM mode switches looks optimal from an LCM standpoint, but speculation can measurabl

Re: Proposed new pass to optimise mode register assignments

On 9/7/24 7:06 PM, Andrew Carlotti wrote: I forgot to explain how FPMR is used. The FPMR register contains a large number of fields that control the data formats and saturation/scaling behaviour used in various fp8 conversion an multiplication intrinsics. At present, I think there are 2^26

Re: Proposed new pass to optimise mode register assignments

On 9/8/24 12:52 AM, Richard Biener wrote: I suppose LCM could be enhanced to handle partial antic and if the edges it speculates on are cold that might even be profitable on less great implementations? Yea, that's not a bad idea at all and suspect it would be useful outside this mode swit

Re: Proposed new pass to optimise mode register assignments

On 9/7/24 1:09 AM, Richard Biener wrote: Am 06.09.2024 um 17:38 schrieb Andrew Carlotti : Hi, I'm working on optimising assignments to the AArch64 Floating-point Mode Register (FPMR), as part of our FP8 enablement work. Claudio has already implemented FPMR as a hard register, with the i

Re: Referencing a register in different modes

On 8/8/24 10:26 AM, Stefan Schulze Frielinghaus wrote: Since you installed this idea into my brain, I gave it a try. Maybe something along the lines: rtx orig_reg = regno_reg_rtx[regno]; machine_mode m1 = GET_MODE (orig_reg); machine_mode m2 = GE

Re: RISC-V Pioneer Box for builder.sourceware.org gcc CI

On 8/8/24 9:13 AM, Mark Wielaard wrote: But I don't fully understand how the gcc testsuite detects whether rvv is implemented. e.g. rvv.exp seems to just check whether the target is RISC-V and if so just executes all tests assuming it can just set -march=rv64gcv* and/or -mrvv-* and run the t

Re: Referencing a register in different modes

On 8/8/24 6:26 AM, Stefan Schulze Frielinghaus wrote: On Thu, Aug 08, 2024 at 06:03:13AM -0600, Jeff Law wrote: On 8/8/24 5:15 AM, Stefan Schulze Frielinghaus via Gcc wrote: However `(reg:DI 61 [ MEM[(const union T *)p_2(D)] ])` referencing the same pseudo in a different mode is not

Re: Referencing a register in different modes

On 8/8/24 5:15 AM, Stefan Schulze Frielinghaus via Gcc wrote: However `(reg:DI 61 [ MEM[(const union T *)p_2(D)] ])` referencing the same pseudo in a different mode is not substituted in insn 6 which leads in the following to an error. The insn is emitted in s390_expand_insv() during There

Re: RISC-V Pioneer Box for builder.sourceware.org gcc CI

On 8/6/24 1:50 PM, Florian Weimer wrote: * Jeff Law via Gcc: On 8/5/24 4:23 PM, Mark Wielaard wrote: It was suggested to just ignore the machine has rvv since it isn't 1.0 compliant. So it is now configured --with-arch=rv64gc --with-abi=lp64d --with-multilib-list=lp64d but that d

Re: RISC-V Pioneer Box for builder.sourceware.org gcc CI

On 8/5/24 4:23 PM, Mark Wielaard wrote: It was suggested to just ignore the machine has rvv since it isn't 1.0 compliant. So it is now configured --with-arch=rv64gc --with-abi=lp64d --with-multilib-list=lp64d but that didn't really change any of the testresults since the rvv vector tests are

Re: [RISC-V] Combining vfmv and .vv instructions into a .vf instruction

On 7/24/24 11:25 AM, Artemiy Volkov wrote: Hi Juzhe, Demin, Jeff, This email is intended to continue the discussion started in https://marc.info/?l=gcc-patches&m=170927452922009&w=2 about combining vfmv.v.f and vfmxx.vv instructions into the scalar-vector form vfmxx.vf. There was a mention o

Re: Insn combine trying (ior:HI (clobber:HI (const_int 0)))

On 7/16/24 4:29 AM, Georg-Johann Lay wrote: Am 15.07.24 um 19:53 schrieb Richard Sandiford: Georg-Johann Lay writes: In a test case I see insn combine trying to match such expressions, which do not make any sense to me, like: Trying 2 -> 7:   2: r45:HI=r48:HI     REG_DEAD r48:HI

Re: Straw poll on shifts with out of range operands

On 6/25/24 8:44 PM, Andrew Pinski via Gcc wrote: I am in the middle of improving the isolation path pass for shifts with out of range operands. There are 3 options we could do really: 1) isolate the path to __builtin_unreachable 2) isolate the path to __builtin_trap This is what is curren

Re: How to target a processor with very primitive addressing modes?

On 6/8/24 10:45 AM, Paul Koning via Gcc wrote: On Jun 8, 2024, at 5:32 AM, Mikael Pettersson via Gcc wrote: On Thu, Jun 6, 2024 at 8:59 PM Dimitar Dimitrov wrote: Have you tried defining TARGET_LEGITIMIZE_ADDRESS for your target? From a quick search I see that the iq2000 and rx backends

Re: How to target a processor with very primitive addressing modes?

On 6/8/24 3:32 AM, Mikael Pettersson via Gcc wrote: On Thu, Jun 6, 2024 at 8:59 PM Dimitar Dimitrov wrote: Have you tried defining TARGET_LEGITIMIZE_ADDRESS for your target? From a quick search I see that the iq2000 and rx backends are rewriting some PLUS expression addresses with insn seque

Re: Which GCC version start to support RISC-V RVV1.0

On 6/4/24 8:51 PM, Erick Kuo-Chen Huang(黃國鎭) via Gcc-help wrote: Hi, We would like to know which GCC version start to support RISC-V RVV1.0 ? We appreciate for your help. gcc-14. Jeff

Re: Epiphany target

On 6/3/24 8:12 AM, Andreas Olofsson via Gcc wrote: Hi, Letting the community know that we are working on getting the Epiphany port back to a proper operational state. There will be a GCC maintainer assigned soon. New Epiphany silicon is in development and old Epiphany devices are still in cir

Re: Question about optimizing function pointers for direct function calls

On 5/23/24 9:51 PM, Hanke Zhang via Gcc wrote: Hi, I got a question about optimizing function pointers for direct function calls in C. Consider the following scenario: one of the fields of a structure is a function pointer, and all its assignments come from the same function. Can all its uses

Re: [committed] PATCH for Re: Stepping down as maintainer for ARC and Epiphany

On 5/21/24 8:02 AM, Paul Koning wrote: On May 21, 2024, at 9:57 AM, Jeff Law wrote: On 5/21/24 12:05 AM, Richard Biener via Gcc wrote: On Mon, May 20, 2024 at 4:45 PM Gerald Pfeifer wrote: On Wed, 5 Jul 2023, Joern Rennecke wrote: I haven't worked with these targets in year

Re: [committed] PATCH for Re: Stepping down as maintainer for ARC and Epiphany

On 5/21/24 12:05 AM, Richard Biener via Gcc wrote: On Mon, May 20, 2024 at 4:45 PM Gerald Pfeifer wrote: On Wed, 5 Jul 2023, Joern Rennecke wrote: I haven't worked with these targets in years and can't really do sensible maintenance or reviews of patches for them. I am currently working on

Re: Updated Sourceware infrastructure plans

On 5/1/24 2:04 PM, Jason Merrill wrote: On 5/1/24 12:15, Jeff Law wrote: On 4/22/24 9:24 PM, Tom Tromey wrote: Jason> Someone mentioned earlier that gerrit was previously tried Jason> unsuccessfully. We tried it and gdb and then abandoned it.  We tried to integrate it in

Re: Updated Sourceware infrastructure plans

On 4/22/24 9:24 PM, Tom Tromey wrote: Jason> Someone mentioned earlier that gerrit was previously tried Jason> unsuccessfully. We tried it and gdb and then abandoned it. We tried to integrate it into the traditional gdb development style, having it send email to gdb-patches. I found these s

Re: Deprecation/removal of nios2 target support

On 4/18/24 9:57 AM, Joel Sherrill wrote: On Thu, Apr 18, 2024 at 10:46 AM Joseph Myers > wrote: On Wed, 17 Apr 2024, Sandra Loosemore wrote: > Therefore I'd like to mark Nios II as obsolete in GCC 14 now, and remove > support from all toolchai

Re: Sourceware mitigating and preventing the next xz-backdoor

On 4/3/24 8:04 AM, Tom Tromey wrote: "Florian" == Florian Weimer writes: Florian> Everyone still pushes their own patches, and there are no Florian> technical countermeasures in place to ensure that the pushed version is Florian> the reviewed version. This is a problem for gdb as well. Pr

Re: How to add a custom instruction to the RISC-V GCC tools?

On 2/5/24 20:57, hameeza ahmed via Gcc wrote: Hello, I want to add an intrinsic in gcc toolchain that will generate the assembly instruction. As it is said I need to add a pattern to the gcc/config/riscv/riscv.md file to describe the instruction. Can you please help me. Are there any tutorial

Re: Building a GCC backend for the STM8

On 1/27/24 20:41, Sophie 'Tyalie' Friedrich via Gcc wrote: Hello dear people, I want to try building a GCC compiler backend for the STM8 micro-controller target in order to make this wonderful architecture more accessible. But as I'm fairly new in this area of building compiler backends f

Re: Stage 4 date

On 1/7/24 08:48, waffl3x via Gcc wrote: https://gcc.gnu.org/develop.html#timeline The date for stage 4 is listed as the 8th on here, is that date final? There is at least 1 patch pending (mine) that is complete but Jason Merril hasn't been active for a few days. He had expressed to me that he

Re: Deprecating nds32-*-linux-* target for GCC 14 (and removing it for GCC 15)

On 12/13/23 23:25, Chung-Ju Wu wrote: As for gdbsim/openocd, I remember that we did have nds32 contributions previously:   - gdb: http://sourceware.org/ml/gdb-patches/2013-07/msg00223.html   - openocd: http://openocd.zylin.com/1259 I suppose they have recently been dropped from the cur

Re: Deprecating nds32-*-linux-* target for GCC 14 (and removing it for GCC 15)

On 12/11/23 16:19, Andrew Pinski via Gcc wrote: nds32 support in Linux was removed last year: https://www.phoronix.com/news/Andes-Tech-NDS32-Removal The support for glibc never made it upstream as far as I can tell either. What are others thoughts on this? I believe the architecture is dead,

Re: [PATCH] strub: disable on rl78

On 12/8/23 19:18, Alexandre Oliva wrote: Hello, Jeff, DJ, Thanks for the info. On Dec 7, 2023, Jeff Law wrote: On 12/6/23 15:03, DJ Delorie wrote: Alexandre Oliva writes: This looks like a latent bug in the port. I'm not surprised, that port was weird. This was just a plai

Re: strub causing libgcc to fail to build on rl78-elf

On 12/6/23 15:03, DJ Delorie wrote: Alexandre Oliva writes: This looks like a latent bug in the port. I'm not surprised, that port was weird. This was just a plain asm insn in strub.c: /* Make sure the stack overwrites are not optimized away. */ asm ("" : : "m" (end[0])); whose

Re: NOP_EXPR vs. CONVERT_EXPR

On 12/5/23 07:53, Richard Biener via Gcc wrote: On Tue, Dec 5, 2023 at 3:54 PM Alexander Monakov via Gcc wrote: Greetings, the definitions for NOP_EXPR and CONVERT_EXPR in tree.def, having survived all the way from 1992, currently say: /* Represents a conversion of type of a value.

Re: Lots of FAILs in gcc.target/riscv/rvv/autovec/*

On 11/7/23 21:31, Maxim Blinov wrote: I see, thanks for clarifying, that makes sense. In that case, what about doing the inverse? I mean, are there unique patches in the vendor branch, and would it be useful to try to upstream them into master? My motivation is to get the best autovectorized

Re: Lots of FAILs in gcc.target/riscv/rvv/autovec/*

On 11/7/23 05:50, Maxim Blinov wrote: Hi all, I can see about 500 failing tests on the vendors/riscv/gcc-13-with-riscv-opts, a mostly-full list at the bottom of this email. It's mostly test cases scraping for vector instructions. Correct. There are generic vectorizer changes that would need

Re: Suspecting a wrong behavior in the value range propagation analysis for __builtin_clz

On 11/1/23 05:29, Giuseppe Tagliavini via Gcc wrote: I found an unexpected issue working with an experimental target (available here: https://github.com/EEESlab/tricore-gcc), but I was able to reproduce it on mainstream architectures. For the sake of clarity and reproducibility, I always re

Re: Help with clz(0) and optimization

On 10/31/23 08:26, Enrico via Gcc wrote: I am working on GCC for a target architecture where clz(0) is defined and is 32 (TriCore). The code under test is the following: #include int f(unsigned int a) { unsigned int res = 32 - __builtin_clz(a); if(res > 0) printf("test"); retu

Re: Question about gimple code during optimizing if-conversion

On 10/14/23 09:49, Andrew Pinski via Gcc wrote: On Fri, Oct 13, 2023 at 10:16 PM Hanke Zhang via Gcc wrote: Hi, I'm working on optimizing if-conversion for my own business recently. I got a problem here. I tried to optimize it in such a case, for example, when a conditional statement block

Re: Test with an lto-build of libgfortran.

On 9/27/23 12:21, Toon Moene wrote: The lto-ing of libgfortran did succeed, because I did get a new warning: gfortran -O3 -flto -flto-partition=none -static  -o xlintstrfz zchkrfp.o zdrvrfp.o zdrvrf1.o zdrvrf2.o zdrvrf3.o zdrvrf4.o zerrrfp.o zlatb4.o zlaipd.o zlarhs.o zsbmv.o zget04.o zpo

Re: Report from the additional type errors for GCC 14 BoF at Cauldron

On 9/26/23 02:28, Florian Weimer via Gcc wrote: My understanding of the consensus goes as follows: * We want to make some changes in this area for GCC 14. * We should do the same thing that Clang does: default to the relevant -Werror= options. * Unlike regular warnings, these warnings-as-e

Re: Using ranger from cfgexpand

On 9/2/23 18:40, Andrew Pinski via Gcc wrote: Hi, I was trying to use the ranger from inside of cfgexpand but since at this point we have a mix of RTL and gimple basic blocks, things fall over very fast. First does it make sense to use the ranger from expand or should we change the gimple

Re: Porting to a custom ISA

On 8/15/23 05:37, MegaIng via Gcc wrote: One of the big challenges I am facing is that for our backend we sometimes support 16bit as the max size a CPU supports, including for pointers, and sometimes 32bit or 64bit. Am I seeing it correctly that POINTER_SIZE has to be a compile time constant

Ju-Zhe Zhong and Robin Dapp as RISC-V reviewers

I am pleased to announce that the GCC Steering Committee has appointed Ju-Zhe Zhong and Robin Dapp as reviewers for the RISC-V port. Ju-Zhe and Robin, can you both updated your MAINTAINERS entry appropriately. Thanks, Jeff

Re: m68k Coldfire and PC-relative addressing distances

On 7/11/23 04:48, Richard Biener via Gcc wrote: On Tue, Jul 11, 2023 at 11:36 AM Florian Weimer via Gcc wrote: How does the Coldfire m68k subtarget and sure that displacements in PIC code are within the addressable range? There is usually a branch shortening pass relying on correct instru

Re: Stepping down as maintainer for ARC and Epiphany

On 7/5/23 12:43, Joern Rennecke wrote: I haven't worked with these targets in years and can't really do sensible maintenance or reviews of patches for them. I am currently working on optimizations for other ports like RISC-V. ARC has still an active maintainer in Claudiu Zissulescu, so is ba

Re: Followup on PR/109279: large constants on RISCV

On 6/12/23 13:32, Vineet Gupta wrote: Gave this a try and it seems to fix Andrew's test, but then regresses the actual large const case: 0x1010101_01010101 : the mem to const_int transformation was being done in cse1 which no longer happens and the const pool from initial expand remains a

Re: Followup on PR/109279: large constants on RISCV

On 6/1/23 20:38, Vineet Gupta wrote: Hi Jeff, I finally got around to collecting various observations on PR/109279 - more importantly the state of large constants in RV backend, apologies in advance for the long email. It seems the various commits in area have improved the original test

Re: Probe emission in fstack-clash-protection

On 5/2/23 22:36, Varun Kumar E via Gcc wrote: Hello, https://godbolt.org/z/P3M8s8jqh The above case shows that gcc first decreases the stack pointer and then probes. As mentioned by Jeff Law (reference <https://developers.redhat.com/blog/2019/04/30/stack-clash-mitigation-in-gcc-why-fst

Re: GCC-13 Branch with RISC-V Performance-Related Backports

On 4/18/23 04:34, Kito Cheng wrote: Based on some discussions, it looks like a handful of vendors are planning on maintaining GCC-13 branches that include various performance-related backports (ie, patches not suitable for the standard GCC-13 release branch). Did you consider also include ne

Re: GCC-13 Branch with RISC-V Performance-Related Backports

On 4/17/23 12:50, Palmer Dabbelt wrote: Based on some discussions, it looks like a handful of vendors are planning on maintaining GCC-13 branches that include various performance-related backports (ie, patches not suitable for the standard GCC-13 release branch). I don't think we'd actuall

Re: ideas on PR/109279

On 3/31/23 03:11, Vineet Gupta wrote: Hi Jeff, Kito, I need some ideas to proceed with PR/109279: pertaining to longer term direction and short term fix. First the executive summary: long long f(void) {   return 0x0101010101010101ull; } Up until gcc 12 this used to generate const pool t

Re: The macro STACK_BOUNDARY may overflow

On 3/24/23 07:48, Paul Iannetta via Gcc wrote: Hi, Currently, the macro STACK_BOUNDARY is defined as Macro: STACK_BOUNDARY Define this macro to the minimum alignment enforced by hardware for the stack pointer on this machine. The definition is a C expression for the des

Re: Using __gnu_lto_slim to detect -fno-fat-lto-objects

On 2/22/23 01:18, Florian Weimer via Gcc wrote: Can we use the COMMON symbol __gnu_lto_slim to detect -fno-fat-lto-objects on contemporary GNU/Linux (with the LTO linker plugin)? We currently build the distribution with -ffat-lto-objects, and I want to switch away from that. Packages will ne

Re: Stepping down as gcov maintainer and callgraph reviewer

On 2/17/23 09:18, Aldy Hernandez via Gcc wrote: Woah. Sad to see you leave! Definitely a sad day, both for the project and for me personally. It's always been a pleasure to work with you. Thanks for all the great work, and good luck on your next endeavors. Likewise. And if you want to c

Re: Default initialization of poly-ints

On 1/3/23 04:16, Florian Weimer via Gcc wrote: It seems that the default constructor of the non-POD poly-ints does nothing. Is this intentional? I expected zero initialization, to match regular ints. I think it was intentional. Richard Sandiford would know for sure. But Martin Sebor might

Re: Possible regression in DF analysis

On 12/8/22 04:51, Claudiu Zissulescu Ianculescu via Gcc wrote: Hi Eric, The problem shows in loop-doloop.c when I introduce a loop end pattern that replaces the first jump instruction (JUMP_INSN 15) with a pattern that clobbers CC reg. However, the DF doesn't look like it works as the doloop s

Re: query about commit 666fdc46bc8489 ("RISC-V: Fix bad insn splits with paradoxical subregs")

On 11/4/22 17:38, Vineet Gupta wrote: commit 666fdc46bc848984ee7d2906f2dfe10e1ee5d535 Author: Jim Wilson Date:   Sat Jun 30 21:52:01 2018 +     RISC-V: Add patterns to convert AND mask to two shifts.     gcc/     * config/riscv/predicates.md (p2m1_shift_operand): New.    

Re: query about commit 666fdc46bc8489 ("RISC-V: Fix bad insn splits with paradoxical subregs")

On 11/4/22 16:59, Vineet Gupta wrote: Hi Jakub, I had a question about the aforementioned commit in RV backend. (define_split   [(set (match_operand:GPR 0 "register_operand") (and:GPR (match_operand:GPR 1 "register_operand")    (match_operand:GPR 2 "p2m1_shift_operand"))) +  

Re: Fwd: Request easy bug fix

On 10/30/22 09:01, Baruch Burstein via Gcc wrote: On Tue, Feb 15, 2022 at 5:20 PM Jonathan Wakely wrote: On Tue, 15 Feb 2022 at 13:58, David Malcolm wrote: On Tue, 2022-02-15 at 12:55 +, Jonathan Wakely via Gcc wrote: On Tue, 15 Feb 2022 at 12:34, Baruch Burstein via Gcc < gcc@gcc.g

Re: Toolchain Infrastructure project statement of support

On 10/23/22 11:09, Frank Ch. Eigler via Libc-alpha wrote: Hi - [...] To be specific, gcc steering committee and glibc FSF stewards have announced the decision for their projects [...] I may be missing something. All I've seen so far were some of the leaders of some of the projects being jo

Re: Toolchain Infrastructure project statement of support

On 10/23/22 10:07, Siddhesh Poyarekar wrote: If you're trying to suggest that overseers, contrary to our repeated public statements, wish to block all migration, that is untrue and you will need to retract this. Here's a more precise statement: Two of the overseers are leaders of projects h

Re: Toolchain Infrastructure project statement of support

On 10/23/22 09:16, Frank Ch. Eigler via Gcc wrote: Hi - [...] Given that the current sourceware admins have decided to block migration of all sourceware assets to the LF IT [...] If you're trying to say that projects have not unanimously shown interest in moving infrastructure to LF IT, jus

Re: Redundant constants in coremark crc8 for RISCV/aarch64 (no-if-conversion)

On 10/19/22 01:46, Richard Biener wrote: On Wed, Oct 19, 2022 at 5:44 AM Jeff Law via Gcc wrote: On 10/18/22 20:09, Vineet Gupta wrote: On 10/18/22 16:36, Jeff Law wrote: There isn't a great place in GCC to handle this right now. If the constraints were relaxed in PRE, then we

Re: Redundant constants in coremark crc8 for RISCV/aarch64 (no-if-conversion)

On 10/18/22 20:09, Vineet Gupta wrote: On 10/18/22 16:36, Jeff Law wrote: There isn't a great place in GCC to handle this right now.  If the constraints were relaxed in PRE, then we'd have a chance, but getting the cost model right is going to be tough. It would have been better

Re: Redundant constants in coremark crc8 for RISCV/aarch64 (no-if-conversion)

On 10/18/22 15:51, Vineet Gupta wrote: Where BB4 corresponds to .L2 and BB6 corresponds to .L3. Evaluation of the constants occurs in BB3 and BB5. And Evaluation here means use of the constant (vs. definition ?). In this case, use of the constant. PRE/GCSE is better suited for this

Re: Redundant constants in coremark crc8 for RISCV/aarch64 (no-if-conversion)

On 10/14/22 09:56, Vineet Gupta wrote: Hi, When analyzing coremark build for RISC-V, noticed redundant constants not being eliminated. While this is a recurrent issue with RV, this specific instance is not unique to RV as I can trigger similar output on aarch64 with -fno-if-conversion, henc

Re: [RFC] Analysis of PR105586 and possible approaches to fix issue

On 7/27/2022 12:58 AM, Richard Biener via Gcc wrote: On Tue, Jul 26, 2022 at 8:55 PM Surya Kumari Jangala via Gcc wrote: Hi, I am working on PR105586. This is a -fcompare-debug failure, with the differences starting during sched1 pass. The sequence of two instructions in a basic block (blo

Re: GCC 12.0.1 Status Report (2022-04-28)

On 4/28/2022 9:29 AM, Jakub Jelinek wrote: On Thu, Apr 28, 2022 at 09:25:43AM -0600, Jeff Law via Gcc wrote: On 4/28/2022 8:59 AM, Jakub Jelinek via Gcc wrote: Status == We have reached zero P1 regressions today and releases/gcc-12 branch has been created. GCC 12.1-rc1 will be built

Re: GCC 12.0.1 Status Report (2022-04-28)

On 4/28/2022 8:59 AM, Jakub Jelinek via Gcc wrote: Status == We have reached zero P1 regressions today and releases/gcc-12 branch has been created. GCC 12.1-rc1 will be built likely tomorrow. The branch is now frozen for blocking regressions and documentation fixes only, all changes to t

Re: [committed] exec-stack warning for test which wants executable stacks

On 4/25/2022 8:37 AM, Jeff Law wrote: On 4/25/2022 6:56 AM, Martin Liška wrote: I used -z execstack rather than --no-warn-execstack as the former is recognized by older versions of ld, but the latter is a new option. Thanks for it. Unfortunately, I should have looked at the other

Re: [committed] exec-stack warning for test which wants executable stacks

On 4/25/2022 9:26 AM, Nick Clifton wrote: Hi Jeff,   Just FYI - I am also looking at adding in another warning.  This time for   when the linker creates a PT_LOAD segment which has all of the RWX flags   set.  At the moment my testing seems to show that it only causes problems   when a cus

Re: [committed] exec-stack warning for test which wants executable stacks

On 4/25/2022 8:42 AM, Nick Clifton wrote: Hi Jeff, I used -z execstack rather than --no-warn-execstack as the former is recognized by older versions of ld, but the latter is a new option. Thanks for it. Unfortunately, I should have looked at the other failures that have popped up over the

Re: [committed] exec-stack warning for test which wants executable stacks

On 4/25/2022 6:56 AM, Martin Liška wrote: I used -z execstack rather than --no-warn-execstack as the former is recognized by older versions of ld, but the latter is a new option. Thanks for it. Unfortunately, I should have looked at the other failures that have popped up over the last wee

[committed] exec-stack warning for test which wants executable stacks

etter since we'd like most tests to fail if somehow their stacks were executable. Committed to the trunk. Jeff commit 6b7441a46c771aa6ecdc0c8ed96197417d036b9a Author: Jeff Law Date: Sun Apr 24 13:38:14 2022 -0400 [committed] exec-stack warning for test which wants executa

Re: Uninit warnings due to optimizing short-circuit conditionals

On 2/14/2022 8:57 AM, David Malcolm via Gcc wrote: [CCing Mark in the hopes of insight from the valgrind side of things] There is a false positive from -Wanalyzer-use-of-uninitialized-value on gcc.dg/analyzer/pr102692.c here: ‘fix_overlays_before’: events 1-3 | | 75 | while

Re: Help with an ABI peculiarity

On 1/7/2022 2:55 PM, Paul Koning via Gcc wrote: On Jan 7, 2022, at 4:06 PM, Iain Sandoe wrote: Hi Folks, In the aarch64 Darwin ABI we have an unusual (OK, several unusual) feature of the calling convention. When an argument is passed *in a register* and it is integral and less than SI

Re: Mass rename of C++ .c files to .cc suffix?

On 1/7/2022 7:49 AM, Jeff Law wrote: On 1/7/2022 3:25 AM, Martin Jambor wrote: Hi, Would anyone be terribly against mass renaming all *.c files (that are actually C++ files) within the gcc subdirectory to ones with .cc suffix? We already have 47 files with suffix .cc directly in the gcc

Re: Mass rename of C++ .c files to .cc suffix?

On 1/7/2022 3:25 AM, Martin Jambor wrote: Hi, Would anyone be terribly against mass renaming all *.c files (that are actually C++ files) within the gcc subdirectory to ones with .cc suffix? We already have 47 files with suffix .cc directly in the gcc subdirectory and 160 if we also count tho

Re: distinguishing gcc compilation valgrind false positives

On 11/24/2021 12:41 PM, Zdenek Sojka wrote: Hello Jeff, -- Původní e-mail -- Od: Jeff Law via Gcc Komu: Paul Floyd , gcc@gcc.gnu.org Datum: 24. 11. 2021 20:33:02 Předmět: Re: distinguishing gcc compilation valgrind false positives On 11/24/2021 12:15 PM, Paul Floyd

Re: Question about match.pd

On 11/24/2021 2:19 PM, Navid Rahimi via Gcc wrote: Hi GCC community, I have a question about pattern matching in match.pd. So I have a pattern like this [1]: #define CMP != bool f(bool c, int i) { return (c << i) CMP 0; } bool g(bool c, int i) { return c CMP 0;} It is verifiably correct to

Re: distinguishing gcc compilation valgrind false positives

On 11/24/2021 12:15 PM, Paul Floyd via Gcc wrote: On 24/11/2021 20:05, Zdenek Sojka via Gcc wrote: Hello, from time to time, I come upon a testcase that failed during the automated runs, but passes during reduction; there are valgrind warnings present, however. How do I distinguish what w

Re: GCC's excellent tail-call optimizations

On 11/5/2021 8:13 AM, Andrew Appel wrote: Dear GCC developers: TL;DR Can I talk to a maintainer of gcc's tail-call optimizer to learn more about the very impressive technology behind it? Or is there a paper, or documentation, that explains it? No paper or documentation I'm aware of. I

Re: -Wuninitialized false positives and threading knobs

On 10/31/2021 6:12 AM, Aldy Hernandez wrote: After Jeff's explanation of the symbiosis between jump threading and the uninit pass, I'm beginning to see that (almost) every Wuninitialized warning is cause for reflection. It usually hides a missing jump thread. I investigated one such false po

Re: dejagnu version update?

On 10/27/2021 5:00 PM, Bernhard Reutner-Fischer wrote: On Sat, 4 Aug 2018 18:32:24 +0200 Bernhard Reutner-Fischer wrote: On Tue, 16 May 2017 at 21:08, Mike Stump wrote: On May 16, 2017, at 5:16 AM, Jonathan Wakely wrote: The change I care about in 1.5.3 So, we haven't talked much about

Re: [TCWG CI] 471.omnetpp slowed down by 8% after gcc: Avoid invalid loop transformations in jump threading registry.

On 9/27/2021 7:52 AM, Aldy Hernandez wrote: [CCing Jeff and list for broader audience] On 9/27/21 2:53 PM, Maxim Kuvyrkov wrote: Hi Aldy, Your patch seems to slow down 471.omnetpp by 8% at -O3.  Could you please take a look if this is something that could be easily fixed? First of all, t

Re: More aggressive threading causing loop-interchange-9.c regression

On 9/10/2021 10:05 AM, Aldy Hernandez wrote: On 9/10/21 5:43 PM, Jeff Law wrote: On 9/9/2021 3:21 AM, Aldy Hernandez wrote:    /* If this path does not thread through the loop latch, then we are   using the FSM threader to find old style jump threads. This   is good, except

Re: More aggressive threading causing loop-interchange-9.c regression

On 9/9/2021 4:15 AM, Richard Biener wrote: b) Even though we can seemingly fold everything DOM/threader does, in order to replace it with a backward threader instance we'd have to merge the cost/profitability code scattered throughout the forward threader, as well as the EDGE_FSM* / EDGE_COP

Re: More aggressive threading causing loop-interchange-9.c regression

On 9/9/2021 3:21 AM, Aldy Hernandez wrote:    /* If this path does not thread through the loop latch, then we are   using the FSM threader to find old style jump threads. This   is good, except the FSM threader does not re-use an existing   threading path to reduce code duplicat

Re: More aggressive threading causing loop-interchange-9.c regression

On 9/9/2021 2:58 AM, Richard Biener wrote: On Thu, Sep 9, 2021 at 10:36 AM Aldy Hernandez wrote: On 9/9/21 9:45 AM, Richard Biener wrote: On Thu, Sep 9, 2021 at 9:37 AM Aldy Hernandez wrote: On 9/9/21 8:57 AM, Richard Biener wrote: On Wed, Sep 8, 2021 at 8:13 PM Michael Matz wrote:

Re: More aggressive threading causing loop-interchange-9.c regression

On 9/9/2021 2:14 AM, Aldy Hernandez wrote: On 9/8/21 8:13 PM, Michael Matz wrote: Hello, [lame answer to self] On Wed, 8 Sep 2021, Michael Matz wrote: The forward threader guards against this by simply disallowing threadings that involve different loops.  As I see The thread in questi

Re: Enable the vectorizer at -O2 for GCC 12

On 8/30/2021 9:30 PM, Hongtao Liu via Gcc wrote: On Tue, Aug 31, 2021 at 11:11 AM Kewen.Lin via Gcc wrote: on 2021/8/30 下午10:11, Bill Schmidt wrote: On 8/30/21 8:04 AM, Florian Weimer wrote: There has been a discussion, both off-list and on the gcc-help mailing list (“Why vectorization did

Re: gcc_assert() and inhibit_libc

On 8/16/2021 11:06 AM, Jakub Jelinek via Gcc wrote: On Mon, Aug 16, 2021 at 12:50:49PM -0400, Jason Merrill via Gcc wrote: The trap builtin is target-specific. Making this system-specific (in this case RTEMS) could be an issue. Is that necessary? Are there interesting targets that don't hav

Re: Failures building glibc with mainline GCC

On 7/30/2021 10:19 AM, Aldy Hernandez via Libc-alpha wrote: There's a new jump threader in GCC which is much more aggressive, and may trigger latent problems with other warning passes, especially -Warray-bounds, -Woverflow, and -Wuninitialized. [ ... ] Ugh.  First attempt got blocked as messag

Re: Failures building glibc with mainline GCC

On 7/30/2021 10:19 AM, Aldy Hernandez via Libc-alpha wrote: There's a new jump threader in GCC which is much more aggressive, and may trigger latent problems with other warning passes, especially -Warray-bounds, -Woverflow, and -Wuninitialized. Do your problems go away if you take out commit

Re: Proper Place for builtin_define(__ELF__)

On 7/22/2021 8:12 AM, Joel Sherrill wrote: On Wed, Jul 21, 2021 at 10:08 PM Jeff Law wrote: On 7/21/2021 6:31 PM, Michael Eager wrote: On 7/21/21 5:22 PM, Joel Sherrill wrote: On Wed, Jul 21, 2021, 7:12 PM Michael Eager mailto:ea...@eagercon.com>> wrote: On 7/21/21 2:28 PM

Re: Proper Place for builtin_define(__ELF__)

On 7/21/2021 6:31 PM, Michael Eager wrote: On 7/21/21 5:22 PM, Joel Sherrill wrote: On Wed, Jul 21, 2021, 7:12 PM Michael Eager > wrote:     On 7/21/21 2:28 PM, Joel Sherrill wrote: > Hi > > We are in the process of porting RTEMS to the Microbla

Re: replacing the backwards threader and more

On 6/21/2021 8:40 AM, Aldy Hernandez wrote: On 6/9/21 2:09 PM, Richard Biener wrote: On Wed, Jun 9, 2021 at 1:50 PM Aldy Hernandez via Gcc wrote: Hi Jeff.  Hi folks. What started as a foray into severing the old (forward) threader's dependency on evrp, turned into a rewrite of the backw

Aldy Hernandez and Andrew MacLeod as VRP maintainers

I am pleased to announce that the GCC Steering Committee has appointed Aldy Hernandez and Ian MacLeod as maintainers for the VRP subsystem (EVRP, VRP, Ranger). Aldy/Andrew, please update the MAINTAINERS file appropriately. Thanks, jeff

Re: replacing the backwards threader and more

On 6/14/2021 11:39 PM, Aldy Hernandez wrote: On 6/15/21 6:03 AM, Jeff Law wrote: On 6/14/2021 12:40 AM, Richard Biener wrote: I bet it's going to be tougher to remove DOM's threader.  It knows how to do thinks like resolve memory references using temporary equivalences

  1   2   3   4   5   6   7   8   9   10   >