Re: wishlist: support for shorter pointers

I want to preface this stating that I have little to no experience in compiler development, I am only merely just getting into it. With that said, I have messed around with library design a fair amount, and this seems like something that could be implemented in a library. It might be slightly comf

Re: [PATCH] Basic asm blocks should always be volatile

On Tue, Jun 27, 2023 at 9:16 AM Julian Waters wrote: > > Perhaps this only affects compilation when GIMPLE isn't being used? The only time GIMPLE is not used is if you supply -fsyntax-only so ... Thanks, Andrew > > On Wed, Jun 28, 2023 at 12:15 AM Julian Waters > wrote: >> >> Hi Andrew, >> >>

Re: [PATCH] Basic asm blocks should always be volatile

On Tue, Jun 27, 2023 at 9:15 AM Julian Waters wrote: > > Hi Andrew, > > That can't be right, on my system a test of asm vs asm volatile with -O3 and > -flto=auto yields very different results, with only the latter being correct. > The patch fixed it and caused gcc to emit correct assembly Can y

Re: [PATCH] Basic asm blocks should always be volatile

Perhaps this only affects compilation when GIMPLE isn't being used? On Wed, Jun 28, 2023 at 12:15 AM Julian Waters wrote: > Hi Andrew, > > That can't be right, on my system a test of asm vs asm volatile with -O3 > and -flto=auto yields very different results, with only the latter being > correct

Re: [PATCH] Basic asm blocks should always be volatile

Hi Andrew, That can't be right, on my system a test of asm vs asm volatile with -O3 and -flto=auto yields very different results, with only the latter being correct. The patch fixed it and caused gcc to emit correct assembly best regards, Julian On Wed, Jun 28, 2023 at 12:08 AM Andrew Pinski wr

Re: [PATCH] Basic asm blocks should always be volatile

On Tue, Jun 27, 2023 at 9:03 AM Julian Waters via Gcc wrote: > > gcc's documentatation mentions that all basic asm blocks are always volatile, > yet the parser fails to account for this by only ever setting > volatile_p to true > if the volatile qualifier is found. This patch fixes this by adding

Re: [PATCH] Basic asm blocks should always be volatile

My apologies, I sent this to the wrong list. I have already resent it to the correct one regards, Julian

[PATCH] Basic asm blocks should always be volatile

gcc's documentatation mentions that all basic asm blocks are always volatile, yet the parser fails to account for this by only ever setting volatile_p to true if the volatile qualifier is found. This patch fixes this by adding a special case check for extended_p before finish_asm_statement is calle

Re: [gimple-ssa] Get the gimple corresponding to the definition of a VAR_DECL

Hello, On Tue, 27 Jun 2023, Pierrick Philippe wrote: > My main problem is regarding uninitialized definition, but still not being > considered undefined behavior. > For example, the following code: > >int x; >int *y = &x; >*y = 6; > > What I'm doing is basically looking at each gimp

wishlist: support for shorter pointers

Hello everybody, I'm not quite sure if this is correct mailbox for this suggestion (may be "embedded" would be better), but let me present it first (and while the examples is from ARM stm32 environment, the issue would equally apply to i386 or even amd64). So: 1. Small MPU (like stm32f103) w

Re: [gimple-ssa] Get the gimple corresponding to the definition of a VAR_DECL

On 27/06/2023 11:42, Richard Biener wrote: On Tue, Jun 27, 2023 at 11:36 AM Pierrick Philippe wrote: Hi everyone, I'm trying to get the gimple * associated to the definition of a given var_decl. Basically, I am iterating over the locals of a function (through the local_decls member) and I nee

Re: School Districts Contacts 2023

Hi there, We are excited to offer you a comprehensive email list of school districts that includes key contact information such as phone numbers, email addresses, mailing addresses, company revenue, size, and web addresses. Our databases also cover related industries such as: * K-12 schools

Re: CLOBBER(eol)

On Tue, 27 Jun 2023, Richard Biener wrote: I think this is a bug in NRV, yes, is special but the above would allow to DSE the three stores. Can you open a bugreport? Done! https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110434

Re: CLOBBER(eol)

On Tue, Jun 27, 2023 at 12:07 PM Krister Walfridsson via Gcc wrote: > > I'm working on an updated version of my translation validator [*], and I > have some problems with CLOBBER(eol). > > I currently treat CLOBBER(eol) as making the memory invalid (i.e. all > subsequent accesses is undefined beha

CLOBBER(eol)

I'm working on an updated version of my translation validator [*], and I have some problems with CLOBBER(eol). I currently treat CLOBBER(eol) as making the memory invalid (i.e. all subsequent accesses is undefined behavior), but the tool reports miscompilation for a few cases where the tree-nr

Query status of GSoC project: CPyChecker

Hi Eric, I am Steven (now) from the CPython team. How is the project going? Do you have any prototypes or ideas that can be discussed? Which part will you start at? I recently debugged dozens of Python bugs, some involving C APIs. I can provide some test cases for you. For the ref count part:

Re: [gimple-ssa] Get the gimple corresponding to the definition of a VAR_DECL

On Tue, Jun 27, 2023 at 11:36 AM Pierrick Philippe wrote: > > Hi everyone, > > I'm trying to get the gimple * associated to the definition of a given > var_decl. > Basically, I am iterating over the locals of a function (through the > local_decls member) and I need to be able to get the gimple * o

[gimple-ssa] Get the gimple corresponding to the definition of a VAR_DECL

Hi everyone, I'm trying to get the gimple * associated to the definition of a given var_decl. Basically, I am iterating over the locals of a function (through the local_decls member) and I need to be able to get the gimple * of its definition within the function's gimple_seq. Does any of you