Re: Add support to trace comparison instructions and switch statements

On Sun, Sep 3, 2017 at 12:01 PM, Jakub Jelinek wrote: > On Sun, Sep 03, 2017 at 10:50:16AM +0200, Dmitry Vyukov wrote: >> What we instrument in LLVM is _comparisons_ rather than control >> structures. So that would be: >> _4 = x_8(D) == 98; >> For example, result of the comparison can be store

Re: Add support to trace comparison instructions and switch statements

On Sun, Sep 3, 2017 at 12:19 PM, Dmitry Vyukov wrote: > On Sun, Sep 3, 2017 at 12:01 PM, Jakub Jelinek wrote: >> On Sun, Sep 03, 2017 at 10:50:16AM +0200, Dmitry Vyukov wrote: >>> What we instrument in LLVM is _comparisons_ rather than control >>> structures. So that would be: >>> _4 = x_8(D)

Re: Add support to trace comparison instructions and switch statements

. > Wish Wu > > -- > From:Dmitry Vyukov > Time:2017 Sep 3 (Sun) 18:21 > To:Jakub Jelinek > Cc:Wish Wu ; gcc ; gcc-patches > ; Jeff Law ; wishwu007 > > Subject:Re: Add support to trace comparison instructions and switch statements >

Calling functions through a pointerI

This isn't a GCC question specifically - it's more of a C language question. I'm involved in a discussion involving C language function pointers. The other party claims calling functions through a function pointer is "undefined behavior" because it's not specifical

Strange error message about condition code in assembly (ia32)

Hello, On GCC: gcc (Ubuntu 7.2.0-8ubuntu3) 7.2.0, Binutils: GNU ld (GNU Binutils for Ubuntu) 2.29.1,I get such error messages: boot.c: In function ‘dummy_do_not_call’: boot.c:1656:3: error: invalid 'asm': operand is not a condition code, invalid operand code 'c&#

GCC interpretation of C11 atomics (DR 459)

Hi I have read multiple bug reports (84522, 80878, 70490), and the past decision regarding GCC change to redirect double-width (128-bit) atomics for x86-64 and arm64 to libatomic. Below I mention major concerns as well as the response from C11 (WG14) regarding DR 459 which, most likely

Fw: GCC interpretation of C11 atomics (DR 459)

Alexander, Thank you for your comments. Please see my response below. I definitely do not want to fight for or against this change in gcc, but there are definitely legitimate concerns to consider.  I think, it would really be good to consider this change to make things more compatible (i.e., at

Re: Fw: GCC interpretation of C11 atomics (DR 459)

> I'd say the main issue is that libatomic is not guaranteed to work like that. > Today it relies on IFUNC for redirection, so you may (and not "will") get the > desired behavior on Glibc (implying Linux), not on other OSes, and neither on > Linux with non-GNU libc (nor on bare metal, for that ma

Re: GCC compiler -Warray-bounds option

Hello, What exactly is the -Warray-bounds option to the GCC compiler supposed to warn about? My g++ --version: g++ (GCC) 7.3.1 20180130 (Red Hat 7.3.1-2) Regards, Mustafa On Wed, Feb 21, 2018 at 9:19 PM, Jeff Law wrote: > On 02/21/2018 03:20 PM, Mustafa i. wrote: > > Hi, > &g

Re: GCC interpretation of C11 atomics (DR 459)

rds compatibility concern? I agree, sounds like a good idea. Certainly for _Atomic objects > 8 bytes. > and then with new enough libatomic on Glibc this segfaults > with GCC on x86_64 too due to IFUNC redirection mentioned > in the other subthread. Seems like it is a problem anyway. Another reason to never emit _Atomic inside .rodata

Re: GCC interpretation of C11 atomics (DR 459)

On Monday, February 26, 2018 1:15 PM, Florian Weimer wrote: > I think x86-64 should be able to do atomic load and store via SSE2 > registers, but perhaps if the memory is suitably aligned (which is the > other problem—the libatomic code will work irrespective of alignment, as > far as I und

Re: GCC interpretation of C11 atomics (DR 459)

er, it seems counterintuitive -- I specify a flag that mcx16 is supported but gcc still does not use it (at least directly). It is possible to make a change to libatomic to always use cmpxchg16b when available (even on systems without IFFUNC), this way it is totally consistent and binary comp

Re: Fw: GCC interpretation of C11 atomics (DR 459)

Torvald, I definitely do not want to insist on this design choice, but it makes sense to at least seriuously consider it given the concerns I described. And especially because IFFUNC in libatomic already redirects to cmpxchg16b, so it just adds extra cost and indirection. Quite frankly, I do not

Re: Fw: GCC interpretation of C11 atomics (DR 459)

Thanks, everyone, for the output, it is very useful. I am just proposing to consider the change unless there are clear roadblocks. (Either design choice is probably OK with respect to the standard formally speaking, but there are some clear advantages also.) I wrote a summary of pros & cons (whi

Re: Fw: GCC interpretation of C11 atomics (DR 459)

t though, and thus > it's defined in that context. But my point is that a programmer cannot rely on this feature anyway unless she/he wants to write code which compiles only with gcc. It is unspecified by the standard and implementations that use read-modify-write for atomic_load are p

Re: Fw: GCC interpretation of C11 atomics (DR 459)

> 1) your proposal would make gcc non-conforming to iso c unless it changes how > static const objects are emitted. I do not think, ISO C requires to put const objects to .rodata. And it is easily solved by not placing it there for _Atomic objects that cannot be safely loaded from rea

Re: Fw: GCC interpretation of C11 atomics (DR 459)

Torvald, thank you for your output, but I think, this discussion gets a little pointless. There is nothing else I can add since gcc folks are reluctant to this change anyway. In my opinion, there is no compelling reason against such an implementation (it is perfectly fine with the standard

Re: GCC interpretation of C11 atomics (DR 459)

conversation... And what good solution gcc offers right now? It forces producer and consumer to use lock-based (BTW: global lock!) approach for *both* producer and consumer if we are talking about 128-bit types.  Therefore, sometimes producers *will* wait (by, effectively, blocking). Basically, it

Re: GCC interpretation of C11 atomics (DR 459)

> But we're not talking about that special case of 128b types here.  The > majority of synchronization doesn't need more than machine word size. Then why do you worry about read-only access for 128b types? (it is a special case anyway). > No, such a program would have a bug anyway.  It wouldn't

Re: GCC interpretation of C11 atomics (DR 459)

Torvald, I think this discussion, indeed, gets pointless. Some of your responses clearly take my comments out of larger picture and context of the discussion. One thing is clear that either implementation is fine with the standard (formally speaking) simply because the standard allows too much l

Simple GCC projects page

Hello all, If this belongs in a different mailbox, please let me know where it should be sent. I would like to start contributing to GCC. In viewing the relevant pages it became clear that they have not been updated for some time, which makes starting to contribute a bit more challenging.  To

Re: How to disable multiple declarations

ile my doc does whatever little is > possible at the documentation level, I was also looking for a way > for being able to disable multiple declarations in the Makefile > itself. >  > Is there some way I can get the gcc compiler to throw an error > at compile time if it spots multip

Finding virtual address of functions in code

Hi, Is there any builtin function in C which prints the virtual address of functions including the main? I see __builtin_return_address() but that returns the “return address”. Regards, Mahmood

Re: D build on powerpc broken (was Re: GCC 11.1 Release Candidate available from gcc.gnu.org)

Peter Bergner via Gcc wrote: On 4/20/21 4:20 PM, Jakub Jelinek via Gcc wrote: On Tue, Apr 20, 2021 at 03:27:08PM -0500, William Seurer via Gcc wrote: /tmp/cc8zG8DV.s: Assembler messages: /tmp/cc8zG8DV.s:2566: Error: unsupported relocation against r13 /tmp/cc8zG8DV.s:2570: Error: unsupported

Re: help debug hash_map garbage collection issue

On 4/20/21 4:15 PM, Martin Sebor wrote: On 4/20/21 2:36 PM, Martin Sebor wrote: On 4/20/21 2:13 PM, Marek Polacek wrote: On Tue, Apr 20, 2021 at 02:03:00PM -0600, Martin Sebor via Gcc wrote: I have a static hash_map object that needs to persist across passes:    static GTY(()) hash_map *map

Re: D build on powerpc broken (was Re: GCC 11.1 Release Candidate available from gcc.gnu.org)

On 4/20/21 4:20 PM, Jakub Jelinek wrote: On Tue, Apr 20, 2021 at 03:27:08PM -0500, William Seurer via Gcc wrote: On 4/20/21 10:24 AM, Jakub Jelinek via Gcc wrote: The first release candidate for GCC 11.1 is available from https://gcc.gnu.org/pub/gcc/snapshots/11.1.0-RC-20210420/ ftp

Re: GCC 11.1 Release Candidate available from gcc.gnu.org

On Tue, Apr 20, 2021 at 7:52 PM Thomas Rodgers wrote: > > On 2021-04-20 15:25, David Edelsohn via Gcc wrote: > > On Tue, Apr 20, 2021 at 12:43 PM Jakub Jelinek via Gcc > wrote: > > > The first release candidate for GCC 11.1 is available from > > https://gcc.gnu.o

Re: help debug hash_map garbage collection issue

On 4/20/21 5:03 PM, Martin Sebor wrote: On 4/20/21 4:15 PM, Martin Sebor wrote: On 4/20/21 2:36 PM, Martin Sebor wrote: On 4/20/21 2:13 PM, Marek Polacek wrote: On Tue, Apr 20, 2021 at 02:03:00PM -0600, Martin Sebor via Gcc wrote: I have a static hash_map object that needs to persist across

Re: GCC 11.1 Release Candidate available from gcc.gnu.org

On Tue, Apr 20, 2021 at 8:23 PM Thomas Rodgers wrote: > > On 2021-04-20 17:09, David Edelsohn wrote: > > On Tue, Apr 20, 2021 at 7:52 PM Thomas Rodgers > wrote: > > > On 2021-04-20 15:25, David Edelsohn via Gcc wrote: > > On Tue, Apr 20, 2021 at 12:43 PM J

Re: GCC 11.1 Release Candidate available from gcc.gnu.org

On Tue, Apr 20, 2021 at 8:43 PM David Edelsohn wrote: > > On Tue, Apr 20, 2021 at 8:23 PM Thomas Rodgers > wrote: > > > > On 2021-04-20 17:09, David Edelsohn wrote: > > > > On Tue, Apr 20, 2021 at 7:52 PM Thomas Rodgers > > wrote: > > > > &g

Re: help debug hash_map garbage collection issue

On Tue, Apr 20, 2021 at 8:31 PM Martin Sebor via Gcc wrote: > > On 4/20/21 5:03 PM, Martin Sebor wrote: > > On 4/20/21 4:15 PM, Martin Sebor wrote: > >> On 4/20/21 2:36 PM, Martin Sebor wrote: > >>> On 4/20/21 2:13 PM, Marek Polacek wrote: > >>>>

Please fix --disable-hosted-libstdcxx asap

Thank you. I have submitted the patch before. Please just apply it or do that by yourself. Sent from Mail for Windows 10

Re: Please fix --disable-hosted-libstdcxx asap

On 21/04/21 10:41 +, unlvsur unlvsur via Libstdc++ wrote: Thank you. I have submitted the patch before. Please just apply it or do that by yourself. Your patch was completely unacceptable, removing lots of things that should not be removed. Just because a piece of code isn't useful for *y

[RISCV] RISC-V GNU Toolchain Biweekly Sync-up call (April 22, 201)

Hi all, There is the agenda for tomorrow's meeting. If you have topics to discuss or share, please let me know and I can add them to the agenda. ## Agenda: 1. Updates from the initial psABI meeting 2. Status update of B, K, P extension implementations. 3. discuss https://github.com/riscv/riscv-

Request Quotation - Heavy Machinery

Dear Supplier, Please advise us if you can ship to Europe to enable us to send our purchase list for a newly approved extensive project of one of our Customers. Anticipating your immediate reply.­­ Many thanks, Regards,­­ *Marika Saonari *I Buyer – THE *CONRAN* SHOP I 22 Shad Thames I Lond

Re: help debug hash_map garbage collection issue

On 4/20/21 8:26 PM, Jason Merrill wrote: On Tue, Apr 20, 2021 at 8:31 PM Martin Sebor via Gcc wrote: On 4/20/21 5:03 PM, Martin Sebor wrote: On 4/20/21 4:15 PM, Martin Sebor wrote: On 4/20/21 2:36 PM, Martin Sebor wrote: On 4/20/21 2:13 PM, Marek Polacek wrote: On Tue, Apr 20, 2021 at 02

State of AutoFDO in GCC

GCC documentation for AutoFDO points to create_gcov tool that converts perf.data file into gcov format that can be consumed by gcc with -fauto-profile (https://gcc.gnu.org/onlinedocs/gcc/Optimize-Options.html, https://gcc.gnu.org/wiki/AutoFDO/Tutorial). I noticed that the source code for

Re: State of AutoFDO in GCC

On Fri, Apr 23, 2021 at 7:28 AM Xinliang David Li via Gcc wrote: > > Hi, the create_gcov tool was probably removed with the assumption that it > was only used with Google GCC branch, but it is actually used with GCC > trunk as well. > > Given that, the tool will be restored in t

Re: State of AutoFDO in GCC

On Fri, Apr 23, 2021 at 9:18 AM Martin Liška wrote: > > On 4/23/21 9:00 AM, Richard Biener via Gcc wrote: > > On Fri, Apr 23, 2021 at 7:28 AM Xinliang David Li via Gcc > > wrote: > >> > >> Hi, the create_gcov tool was probably removed with the assumption th

GCC 8.5 Status Report (2021-04-23)

Status == GCC 8.5 release and closing of the 8 branch is several months overdue, we don't have enough time to maintain trunk and 4 supported release branches. Therefore, I'd like to do 8.5-rc1 on 7th of May and release 8.5 and close the branch a week after that. We have one P1

Second GCC 11.1 Release Candidate available from gcc.gnu.org

Some blocker bugs were reported against the first release candidate of GCC 11.1, so there is a second release candidate for GCC 11.1 available from https://gcc.gnu.org/pub/gcc/snapshots/11.1.0-RC-20210423/ ftp://gcc.gnu.org/pub/gcc/snapshots/11.1.0-RC-20210423 and shortly its mirrors. It has

"musttail" statement attribute for GCC?

Would it be feasible to implement a "musttail" statement attribute in GCC to get a guarantee that tail call optimization will be performed? Such an attribute has just landed in the trunk of Clang (https://reviews.llvm.org/D99517). It makes it possible to write algorithms that use arbitr

Re: origin/trunk branch - who added it?

On Fri, Apr 23, 2021 at 5:13 AM Martin Liška wrote: > > Few weeks ago, I noticed we have a new remote branch that follows > origin/master: > https://gcc.gnu.org/git/?p=gcc.git;a=shortlog;h=refs/heads/trunk > > Do we know who added it? And what was the motivation? I did; I've always preferred tha

Re: "musttail" statement attribute for GCC?

On Fri, 2021-04-23 at 12:44 -0700, Josh Haberman via Gcc wrote: > Would it be feasible to implement a "musttail" statement attribute in > GCC to get a guarantee that tail call optimization will be performed? > > Such an attribute has just landed in the trunk of Clang >

Re: "musttail" statement attribute for GCC?

David Malcolm via Gcc wrote: On Fri, 2021-04-23 at 12:44 -0700, Josh Haberman via Gcc wrote: Would it be feasible to implement a "musttail" statement attribute in GCC to get a guarantee that tail call optimization will be performed? Such an attribute has just landed in the trun

Re: "musttail" statement attribute for GCC?

David Malcolm via Gcc wrote: > FWIW I implemented something like this in GCC's middle-end here: > https://gcc.gnu.org/git/?p=gcc.git;a=commitdiff;h=9a385c2d3d74ffed78f2ed9ad47b844d2f294105 > exposing it in API form for libgccjit: > https://gcc.gnu.org/git/?p=gcc.g

Re: GCC 8.5 Status Report (2021-04-23)

On Fri, Apr 23, 2021 at 7:55 AM Jakub Jelinek wrote: > > Status > ====== > > GCC 8.5 release and closing of the 8 branch is several months overdue, > we don't have enough time to maintain trunk and 4 supported release branches. > Therefore, I'd like to do 8.5-rc1 on

Re: "musttail" statement attribute for GCC?

On Fri, Apr 23, 2021 at 2:45 PM Josh Haberman via Gcc wrote: > > Would it be feasible to implement a "musttail" statement attribute in > GCC to get a guarantee that tail call optimization will be performed? > > Such an attribute has just landed in the trunk of Clang &g

Re: "musttail" statement attribute for GCC?

On Fri, Apr 23, 2021 at 4:34 PM Andrew Pinski wrote: > > On Fri, Apr 23, 2021 at 2:45 PM Josh Haberman via Gcc wrote: > > > > I wrote more about some motivation for guaranteed tail calls here: > > https://blog.reverberate.org/2021/04/21/musttail-efficient-interpreters.h

Re: Second GCC 11.1 Release Candidate available from gcc.gnu.org

On 4/23/21 8:31 AM, Jakub Jelinek via Gcc wrote: Some blocker bugs were reported against the first release candidate of GCC 11.1, so there is a second release candidate for GCC 11.1 available from https://gcc.gnu.org/pub/gcc/snapshots/11.1.0-RC-20210423/ ftp://gcc.gnu.org/pub/gcc/snapshots

Re: Second GCC 11.1 Release Candidate available from gcc.gnu.org

William Seurer via Gcc wrote: On 4/23/21 8:31 AM, Jakub Jelinek via Gcc wrote: Some blocker bugs were reported against the first release candidate of GCC 11.1, so there is a second release candidate for GCC 11.1 available from https://gcc.gnu.org/pub/gcc/snapshots/11.1.0-RC-20210423/ ftp

Re: Second GCC 11.1 Release Candidate available from gcc.gnu.org

On Sun, Apr 25, 2021 at 08:21:12PM +0100, Iain Sandoe via Gcc wrote: > William Seurer via Gcc wrote: > > > On 4/23/21 8:31 AM, Jakub Jelinek via Gcc wrote: > > > Some blocker bugs were reported against the first release candidate > > > of GCC 11.1, so there is a se

Pointer to the current function

Hello: I wonder what do you think about a patch to implement getting a pointer to the current function. Is it a "no, under no circumstances"? Or it is a "maybe, show us the code"? I'll explain better what I mean: currently there is the statement __func__ that returns a string with the name o

Re: gcc-11-20210425 is now available

Hi, > Snapshot gcc-11-20210425 is now available on > https://gcc.gnu.org/pub/gcc/snapshots/11-20210425/ > and on various mirrors, see http://gcc.gnu.org/mirrors.html for details. > > This snapshot has been generated from the GCC 11 git branch > with the following options: git

Re: State of AutoFDO in GCC

ary format is not documented. The binary format is not >> guaranteed to >> > be backward compatible, so sharing the same format may not be the best >> way >> > as changes for clang may break GCC. >> > >> > Since linux perf format does not change, the

Re: "musttail" statement attribute for GCC?

On Fri, 23 Apr 2021, Josh Haberman via Gcc wrote: > On Fri, Apr 23, 2021 at 1:10 PM Iain Sandoe wrote: > > I did try to use it this ^ for GCC coroutines (where such a guarantee is > > pretty important) > > > > However, the issue there is that not all targets support i

Re: "musttail" statement attribute for GCC?

Alexander Monakov wrote: On Fri, 23 Apr 2021, Josh Haberman via Gcc wrote: On Fri, Apr 23, 2021 at 1:10 PM Iain Sandoe wrote: I did try to use it this ^ for GCC coroutines (where such a guarantee is pretty important) However, the issue there is that not all targets support indirect

Re: "musttail" statement attribute for GCC?

On 26/04/2021 14:49, Iain Sandoe via Gcc wrote: Alexander Monakov wrote: On Fri, 23 Apr 2021, Josh Haberman via Gcc wrote: On Fri, Apr 23, 2021 at 1:10 PM Iain Sandoe wrote: I did try to use it this ^ for GCC coroutines (where such a guarantee is pretty important) However, the issue

Re: State of AutoFDO in GCC

Jan Hubicka writes: > > Is there a way to get this working w/o using older perf? It's usually rather simple to fix up autofdo for new perf. I did it before here https://github.com/andikleen/autofdo/commits/perf4-3 I think it would work always if it just ignored unknown records (which is quite p

[walter thierry]RE:Journée fantastique

Je l'ai aimé❗ http://9w6ed2v.worknumbermethod.work/d10 walter thierry loyalement

Re: State of AutoFDO in GCC

>There are multiple directional changes in this new tool: >1) it uses perf-script trace output (in text) as input profile data;  I suspect this will break regularly too (I personally did numerous changes to perf script output, and also wrote a lot of parsing scripts) The perf script outp

Re: State of AutoFDO in GCC

with extended uses. Thanks, Hongtao From: Xinliang David Li Date: Monday, April 26, 2021 at 11:05 AM To: Andi Kleen Cc: Jan Hubicka , gcc@gcc.gnu.org , Wei Mi , Eugene Rozenfeld , Wenlei He , Hongtao Yu Subject: Re: State of AutoFDO in GCC On Mon, Apr 26, 2021 at 11:00 AM Andi Kleen

Re: State of AutoFDO in GCC

On Mon, Apr 26, 2021 at 06:40:56PM +, Hongtao Yu wrote: >Andi, thanks for pointing out the perf script issues. Can you please >elaborate a bit on the exact issue you have seen? We’ve been using >specific output of perf script such as mmap, LBR and callstack events >filtered by p

Re: Has FSF stopped processing copyright paperwork

Hi, (Please note that this mail is *NOT* about the recent discussions about the relationship with the FSF. AFAIK to date FSF copyright assignment is still required to contribute to gcc and this request is solely about how to have one signed.) Few weeks later, I would like to know if anyone on

Re: Has FSF stopped processing copyright paperwork

Le 26 avr. 2021 à 23:31, Gerald Pfeifer mailto:ger...@pfeifer.com>> a écrit : I got notified of copyright assignments related to GCC by copyright-cl...@fsf.org<mailto:copyright-cl...@fsf.org> on April 5th, April 8th, April 22nd (two instances) and April 26th (today). So the process

SOOL Hashes

a712557bc4d071895a30d5691395661c15d40f738e7090ea8ffc923e20d746ac2177374146a5699512a3a9f1d6e576ad4b070a78233d01ec9493f88e8564a198 SOOL Presentation - in depth.pdf 532f84ce40ed291d7c00b3714904300c2bd538f836cb3bdf5b28003eb0c19ebdcf1f9faf0fabf8a3be6ecc6f7c29cfedd67464e467f98742445e0b2d555145d0 SOOL P

GCC 11.1 Released

The GCC developers are proud to announce another major GCC release, 11.1. This release switches the default debugging format to DWARF 5 [1] on most targets and switches the default C++ language version to -std=gnu++17. It makes great progress in the C++20 language support, both on the compiler

GCC 11.1.1 Status Report (2021-04-27)

Status == GCC 11.1 has been released, the releases/gcc-11 branch is open again for regression and documentation bugfixing. GCC 11.2 can be expected in 2-3 months from now unless something serious changes the plans. Quality Data Priority # Change from last report

Some really strange GIMPLE

I'm chasing a bug and I used Creduce to produce a reduced test case. However, that's really beside to point. I this file: typedef struct basket { } a; long b; a *basket; int d, c, e; a *flake[2]; void primal_bea_mpp(); void primal_net_simplex() { flake[1] = &bask

Re: Some really strange GIMPLE

On Tue, 2021-04-27 at 20:10 +, Gary Oblock via Gcc wrote: > I'm chasing a bug and I used Creduce to produce a > reduced test case. However, that's really beside to > point. > > I this file: > > typedef struct basket { > } a;

Re: Some really strange GIMPLE

On Tue, Apr 27, 2021 at 3:51 PM Gary Oblock via Gcc wrote: > > I'm chasing a bug and I used Creduce to produce a > reduced test case. However, that's really beside to > point. > > I this file: > > typedef struct basket { > } a;

Re: Some really strange GIMPLE

> CONFIDENTIALITY NOTICE: This e-mail message, including any attachments, is > for the sole use of the intended recipient(s) and contains information that > is confidential and proprietary to Ampere Computing or its subsidiaries. It > is to be used solely for the purpose of furthering the partie

GSoC Student Engagement

Hello, This is Nick Vidal from Rocket.Chat We’ve been part of GSoC for 5 years now, and as a way to celebrate and give back to the open source community, this year we are reaching out to other GSoC organizations to provide assistance on setting up Rocket.Chat to engage with students (pro bono).

Re: State of AutoFDO in GCC

rsion and other packages. I guess gcc will really need a replacement that doesn't pull in all of LLVM if it wants to continue supporting autofdo. I'm myself unable to build now. I'm using the old version I had a git fork of and that was before all of this. I added a patch to make i

Is it very hard to support wasi backend?

I helped built libstdc++ on wasm32-wasi with clang. It works great. However, are we going to have GCC’s own wasm32-wasi backend support in the future? Sent from Mail for Windows 10

Re: Could vector type of poly_int and compile-time constants be enabled at the same time ?

JojoR via Gcc writes: > Hi, > > I have a little know about for 'Sizes and offsets as runtime > invariants’, > > and need to add vector types like V2SImode as compile-time constants > with enabled vector types of runtime invariants. > > Co

Re: Could vector type of poly_int and compile-time constants be enabled at the same time ?

On Thu, Apr 29, 2021 at 5:40 AM JojoR via Gcc wrote: > > Hi, > > I have a little know about for 'Sizes and offsets as runtime > invariants’, > > and need to add vector types like V2SImode as compile-time constants > with enabled vecto

RFC: attributes for marking security boundaries (system calls/ioctls, user vs kernel pointers etc)

I've been going through old Linux kernel CVEs, trying to prototype some possible new warnings for -fanalyzer in GCC 12 (and, alas, finding places where the analyzer internals need work...) I think I want a way for the user to be able to mark security boundaries in their code: for example:

TREE_NO_WARNING and internal variables

The C front end (and perhaps others as well) creates internal variables in a few places, such as in convert_lvalue_to_rvalue like so: /* Remove the qualifiers for the rest of the expressions and create the VAL temp variable to hold the RHS. */ nonatomic_type = build_qualifie

Re: TREE_NO_WARNING and internal variables

On Thu, Apr 29, 2021 at 11:22:15AM -0600, Martin Sebor via Gcc wrote: > The C front end (and perhaps others as well) creates internal > variables in a few places, such as in convert_lvalue_to_rvalue > like so: > > /* Remove the qualifiers for the rest of the expressions and

Re: TREE_NO_WARNING and internal variables

On 4/29/21 11:32 AM, Jakub Jelinek wrote: On Thu, Apr 29, 2021 at 11:22:15AM -0600, Martin Sebor via Gcc wrote: The C front end (and perhaps others as well) creates internal variables in a few places, such as in convert_lvalue_to_rvalue like so: /* Remove the qualifiers for the rest of

Re: RFC: attributes for marking security boundaries (system calls/ioctls, user vs kernel pointers etc)

On 4/29/21 11:18 AM, David Malcolm wrote: I've been going through old Linux kernel CVEs, trying to prototype some possible new warnings for -fanalyzer in GCC 12 (and, alas, finding places where the analyzer internals need work...) I think I want a way for the user to be able to mark sec

Re: TREE_NO_WARNING and internal variables

On Thu, Apr 29, 2021 at 11:54:27AM -0600, Martin Sebor via Gcc wrote: > On 4/29/21 11:32 AM, Jakub Jelinek wrote: > > On Thu, Apr 29, 2021 at 11:22:15AM -0600, Martin Sebor via Gcc wrote: > > > The C front end (and perhaps others as well) creates internal > > > variabl

Re: [RFC] A memory gathering optimization for loop

v2 = cache_arr[cache_idx]->c_v2; > v3 = cache_arr[cache_idx]->c_v3; > } > ... > cache_idx++; > iter = NEXT_FN (iter); > } > ... > } > > free (cache_arr); Why do you need the init field? I

Re: [RFC] A memory gathering optimization for loop

On Fri, Apr 30, 2021 at 9:51 AM Florian Weimer via Gcc wrote: > > * Feng Xue: > > > To simplify explanation of this memory gathering optimization, pseudo > > code on original nested loops is given as: > > > > outer-loop ( ) { /* data in inner loop

Re: [RFC] A memory gathering optimization for loop

* Richard Biener: >> Can you change this optimization so that it can use a fixed-size buffer? >> This would avoid all issues around calling calloc. If iter_count can be >> very large, allocating that much extra memory might not be beneficial >> anyway. > > It would need to be TLS storage though o

RE: [EXTERNAL] Re: State of AutoFDO in GCC

Is the format produced by create_gcov and expected by GCC under -fauto-rpofile documented somewhere? How is it different from .gcda used in FDO, e.g., as described here: http://src.gnu-darwin.org/src/contrib/gcc/gcov-io.h.html? My input data is different from perf.data and I'd like to wr

Re: State of AutoFDO in GCC

172060...@hdu.edu.cn writes: > Hi all, > > I`m using GCC 9.3 AutoFDO and the old version create_gcov on arm64 > and it works well. Actually it support not only LBR like mode but > also inst_retired even cycles event, which`s the early implementation > of AutoFDO[1]. There i

Re: [EXTERNAL] Re: State of AutoFDO in GCC

Eugene Rozenfeld via Gcc writes: > Is the format produced by create_gcov and expected by GCC under > -fauto-rpofile documented somewhere? How is it different from .gcda > used in FDO, e.g., as described here: > http://src.gnu-darwin.org/src/contrib/gcc/gcov-io.h.html? I belie

Re: RFC: attributes for marking security boundaries (system calls/ioctls, user vs kernel pointers etc)

David Malcolm via Gcc writes: > I think I want a way for the user to be able to mark security > boundaries in their code: for example: > * in the Linux kernel the boundary between untrusted user-space data > and kernel data, or, > * for a user-space daemon, the boundary between d

Speed of compiling gimple-match.c

Hi all, I noticed my (highly, -j24) parallel build of GCC is serialized on compiling gimple-match.c. Has anyone looked into splitting this generated file into multiple files? Thanks, Andrew Pinski

Re: Speed of compiling gimple-match.c

On Mon, May 3, 2021 at 11:10 PM Andrew Pinski via Gcc wrote: > > Hi all, > I noticed my (highly, -j24) parallel build of GCC is serialized on > compiling gimple-match.c. Has anyone looked into splitting this > generated file into multiple files? There were threads about this i

Re: -flto and -Werror

On 5/4/21 6:39 AM, Matthias Klose wrote: Using -flto exposes some new warnings in code, as seen in the both build logs below, for upstream elfutils and systemd. I have seen others. These upstreams enable -Werror by default, but probably don't see these warnings turning to errors themself, becau

What is going on here with fixup_cfg?

_modif_basket *[4061] struct _modif_basket *[4061] # .MEM_111 = VDEF <.MEM_103> perm ={v} {CLOBBER}; during GIMPLE pass: fixup_cfg psimplex.c:124:6: internal compiler error: verify_gimple failed 0x12da3a4 verify_gimple_in_cfg(function*, bool) ../../sources/gcc/tree-cfg.c:5482 0x10e69f8 execute_functio

Re: Gcc Digest, Vol 15, Issue 5

I've got to say appearances can be deceptive in GCC and struct _modif_basket *[4061] is not necessarily equal to struct _modif_basket *[4061] even though the printed representation is the same... Gary From: Gcc on behalf of gcc-requ...@gcc.gnu.org Sent: Tu

Re: What is going on here with fixup_cfg?

On Wed, May 5, 2021 at 12:19 AM Gary Oblock via Gcc wrote: > > My jaws hit the floor when I saw this bug: > > psimplex.c: In function ‘master.constprop’: > psimplex.c:124:6: error: non-trivial conversion in ‘constructor’ > 124 | void master(network_t *ne

Successive hoisting and AVAIL_OUT in at least one successor heuristic

Hi Richard, I was just wondering if second (and higher) order hoistings may defeat the "AVAIL_OUT in at least one successor heuristic" ? For eg: bb2: if (cond1) goto bb3 else goto bb4; bb3: if (cond2) goto bb5 else goto bb6; bb5: return x + y; bb6: return x + y; bb4: if (cond3) goto bb7 else g

unsubscribe

unsubscribe On Friday, April 30, 2021, Xun Li via llvm-dev wrote: > Hi, > > I noticed that when compiling lambda functions, the generated function > names use different conventions than GCC. > Example: https://godbolt.org/z/5qvqKqEe6 > The lambda in Clang is named "_Z3barI

Re: Successive hoisting and AVAIL_OUT in at least one successor heuristic

On Thu, 6 May 2021 at 15:43, Richard Biener wrote: > > On Thu, 6 May 2021, Prathamesh Kulkarni wrote: > > > Hi Richard, > > I was just wondering if second (and higher) order hoistings may defeat > > the "AVAIL_OUT in at least one successor heuristic" ? > > > > For eg: > > bb2: > > if (cond1) goto

Issue with pointer types marked with scalar_storage_order

Hello, for a few years now, GCC has supported the scalar_storage_order attribute (and pragma) that allows specifying the storage order (endianness) of structures. This affects both the code GCC generates to access variables declared using the attribute, and also the debug info: GCC emits the

<    32   33   34   35   36   37   38   39   40   41   >