Re: Question regarding riscv_valid_lo_sum_p vs strict-align

IIRC, the reason is that, under strict alignment, it can be assumed that accessing subfields of an aligned datatype won't cross a boundary that would cause the high part to change, thus requiring a different LUI instruction for the subfield access. Under non-strict alignment, this assumption doesn

Question regarding riscv_valid_lo_sum_p vs strict-align

Hi, When -mstrict-align was added for RISC-V, there was a change for riscv_valid_lo_sum_p: @@ -726,7 +733,8 @@ riscv_valid_lo_sum_p (enum riscv_symbol_type sym_type, enum machine_mode mode) /* We may need to split multiword moves, so make sure that each word can be accessed without indu

Re: Inquiry Regarding -Wrange-loop-construct Warning Behavior in GCC 14

On Fri, 13 Sept 2024 at 12:52, Jonathan Wakely wrote: > > On Fri, 13 Sept 2024 at 10:30, Sunil Kumar Dora > wrote: > > > > Dear GCC Community, > > I am currently encountering an issue with the -Wrange-loop-construct > > warning in GCC version 14, as well as in earlier versions. It appears that

Re: Inquiry Regarding -Wrange-loop-construct Warning Behavior in GCC 14

On Fri, 13 Sept 2024 at 10:30, Sunil Kumar Dora wrote: > > Dear GCC Community, > I am currently encountering an issue with the -Wrange-loop-construct warning > in GCC version 14, as well as in earlier versions. It appears that the > warning is triggered incorrectly for certain loop constructs. >

Inquiry Regarding -Wrange-loop-construct Warning Behavior in GCC 14

Dear GCC Community, I am currently encountering an issue with the -Wrange-loop-construct warning in GCC version 14, as well as in earlier versions. It appears that the warning is triggered incorrectly for certain loop constructs. Issue Details: I have tested the following code, which produces a w

Re: I have questions regarding the 4.3 codebase...

ic block coverage is done. I've tracked down > > where/how mcount() calls are generated, but I haven't even been able to > > determine what function(s) are called to increment a basic block's count. > > I'd also like to find more detailed information regarding pr

Re: I have questions regarding the 4.3 codebase...

en't even been able to > determine what function(s) are called to increment a basic block's count. > I'd also like to find more detailed information regarding profiling, > coverage, and function instrumentation. Look into gcc/tree-profile.c > On Wed, Mar 22, 2023 at 6:27 PM Sid

Re: I have questions regarding the 4.3 codebase...

ck's count. I'd also like to find more detailed information regarding profiling, coverage, and function instrumentation. On Wed, Mar 22, 2023 at 6:27 PM Sid Maxwell wrote: > Is there anyone on the list with experience with the gcc 4.3 codebase? > I'm currently maintai

Re: [Regarding GCOV].gcda:stamp mismatch with notes file

On Thu, 25 Apr 2024 at 09:54, Jonathan Wakely wrote: > > On Thu, 25 Apr 2024 at 07:47, Gejoe Daniel via Gcc wrote: > > > > Hi team, > > The following is my query posted but would need more inputs : > > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114751 > > > > The gcov tool which was working so

Re: [Regarding GCOV].gcda:stamp mismatch with notes file

On Thu, 25 Apr 2024 at 07:47, Gejoe Daniel via Gcc wrote: > > Hi team, > The following is my query posted but would need more inputs : > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114751 > > The gcov tool which was working so far seems to fail with our latest branch > where gcc is 11.4.0 and he

Re: [Regarding GCOV].gcda:stamp mismatch with notes file

Am 25.04.2024 um 08:45 schrieb Gejoe Daniel via Gcc: Hi team, The following is my query posted but would need more inputs : https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114751 The gcov tool which was working so far seems to fail with our latest branch where gcc is 11.4.0 and hence we wanted to

[Regarding GCOV].gcda:stamp mismatch with notes file

Hi team, The following is my query posted but would need more inputs : https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114751 The gcov tool which was working so far seems to fail with our latest branch where gcc is 11.4.0 and hence we wanted to sort this out by getting the right help as early as po

Re: Regarding OMPD

Hello Mohamed, Jakub Jelinek wrote: Mohamed Atef via Gcc wrote: I am still interested in working on OMPD. Are there any plans for OMPD, soon? I think no one is currently working on OMPD or is planning to do so in the near future - but support for OMPD would be surely nice. It is surely to

Re: Regarding OMPD

On Thu, Jan 18, 2024 at 02:36:02PM +0200, Mohamed Atef via Gcc wrote: > I'm sorry for not getting back to you this long time. As I mentioned > The military service here is a must. Thank God I finished my military > service. > I am still interested in working on OMPD. Are there any plans for OMP

Regarding OMPD

Hello everyone, I'm sorry for not getting back to you this long time. As I mentioned The military service here is a must. Thank God I finished my military service. I am still interested in working on OMPD. Are there any plans for OMPD, soon? Would anyone be able to work with me on some parts of

Re: Clarification regarding various classes DIE's attribute value class

> Hello, > I am working on a project to produce the LTO object file from the compiler > directly. So far, we have > correctly outputted .symtab along with various .debug sections. The only > thing remaining is to > correctly output attribute values and their corresponding values in the > .debug_inf

Re: Clarification regarding various classes DIE's attribute value class

On Tue, 10 Oct 2023, Rishi Raj wrote: > Hello, > I am working on a project to produce the LTO object file from the compiler > directly. So far, we have > correctly outputted .symtab along with various .debug sections. The only > thing remaining is to > correctly output attribute values and their c

Clarification regarding various classes DIE's attribute value class

Hello, I am working on a project to produce the LTO object file from the compiler directly. So far, we have correctly outputted .symtab along with various .debug sections. The only thing remaining is to correctly output attribute values and their corresponding values in the .debug_info section. Thi

Re: Concerns regarding the -ffp-contract=fast default

On Mon, 18 Sep 2023, Alexander Monakov wrote: > > On Mon, 18 Sep 2023, Florian Weimer wrote: > > > Okay, you meant “changing the result” as in “changing the result in a > > permitted way”. Sorry, was confused. So this is a bad example all > > around. Are there better ones (that don't involve

Re: Concerns regarding the -ffp-contract=fast default

On Mon, 18 Sep 2023, Florian Weimer wrote: > Okay, you meant “changing the result” as in “changing the result in a > permitted way”. Sorry, was confused. So this is a bad example all > around. Are there better ones (that don't involve FMA)? If you're looking for something similar to your ori

Re: Concerns regarding the -ffp-contract=fast default

* Alexander Monakov: >> > Contracting 'x + x - x' to fma(x, 2, -x) would be fine. >> >> It still changes the result, doesn't it? > > I don't follow. I doesn't change the result for infinities (produces > a NaN). It changes the result when x is so large that 'x + x' is > not representable (exponen

Re: Concerns regarding the -ffp-contract=fast default

On Mon, 18 Sep 2023, Martin Uecker wrote: > > The hardest part would be popping the pragma state when leaving a block, > > which didn't seem difficult (at least for C). > > It is fairly restricted where it can appear, it essentially operates > on the level of compound statements (!= blocks).

Re: Concerns regarding the -ffp-contract=fast default

Am Montag, dem 18.09.2023 um 14:43 +0300 schrieb Alexander Monakov: > On Mon, 18 Sep 2023, Jakub Jelinek wrote: > > > Perhaps we should add some initial hammer approach for the pragma, like > > if you ever use the pragma to turn it somewhere off, it is turned off > > globally, or ditto per functio

Re: Concerns regarding the -ffp-contract=fast default

On Mon, 18 Sep 2023, Florian Weimer via Gcc wrote: > But the contraction would still be valid after an isfinite check > (something that ranger might catch these days), or with with > -ffinite-math-only in general. Right? Nope, still not valid for negative zero ('x + x - x' would yield positive

Re: Concerns regarding the -ffp-contract=fast default

On Mon, 18 Sep 2023, Jakub Jelinek wrote: > Perhaps we should add some initial hammer approach for the pragma, like > if you ever use the pragma to turn it somewhere off, it is turned off > globally, or ditto per function. Might be far easier than trying to > make it precise that contraction is

Re: Concerns regarding the -ffp-contract=fast default

* Richard Biener: >> How much numerical code is compatible with that? For example, David >> Goldberg's What Every Computer Scientist Should Know About >> Floating-Point Arithmetic (revised) contains this sentence: >> >> | A language definition that does not require parentheses to be honored >> |

Re: Concerns regarding the -ffp-contract=fast default

* Alexander Monakov: > On Mon, 18 Sep 2023, Florian Weimer via Gcc wrote: > >> x - x is different because replacing it with 0 doesn't seem to be a >> valid contraction because it's incorrect for NaNs. x + x - x seems to >> be different in this regard, but in our implementation, there might be a >

Re: Concerns regarding the -ffp-contract=fast default

On Mon, Sep 18, 2023 at 01:26:54PM +0200, Martin Uecker wrote: > > I think that changing the default to =standard without -ffast-math is > > reasonable. > > IIRC the standard allows such default if it's indicated, so it doesn't > > require > > =off anywhere. > > The C standard requires a pragma t

Re: Concerns regarding the -ffp-contract=fast default

Am Montag, dem 18.09.2023 um 10:06 +0200 schrieb Richard Biener via Gcc: > On Mon, Sep 18, 2023 at 9:51 AM Alexander Monakov wrote: > > > > Hi Florian, > > > > On Thu, 14 Sep 2023, Alexander Monakov wrote: > > > > > > > > On Thu, 14 Sep 2023, Florian Weimer via Gcc wrote: > > > > > > > While

Re: Concerns regarding the -ffp-contract=fast default

On Mon, 18 Sep 2023, Florian Weimer via Gcc wrote: > x - x is different because replacing it with 0 doesn't seem to be a > valid contraction because it's incorrect for NaNs. x + x - x seems to > be different in this regard, but in our implementation, there might be a > quirk about sNaNs and qNa

Re: Concerns regarding the -ffp-contract=fast default

On Mon, Sep 18, 2023 at 12:10 PM Florian Weimer wrote: > > * Richard Biener: > > >> > > GCC contraction behavior is rather inconsistent. It does not contract > >> > > x > >> > > + x - x without -ffast-math, for example, although I believe it would > >> > > be > >> > > permissible under the rule

Re: Concerns regarding the -ffp-contract=fast default

* Richard Biener: >> > > GCC contraction behavior is rather inconsistent. It does not contract x >> > > + x - x without -ffast-math, for example, although I believe it would be >> > > permissible under the rules that enable FMA contraction. This whole > > Is that really just x + x - x? We curre

Re: Concerns regarding the -ffp-contract=fast default

On Mon, Sep 18, 2023 at 9:51 AM Alexander Monakov wrote: > > Hi Florian, > > On Thu, 14 Sep 2023, Alexander Monakov wrote: > > > > > On Thu, 14 Sep 2023, Florian Weimer via Gcc wrote: > > > > > While rebuilding CentOS Stream with -march=x86-64-v3, I rediscovered > > > several packages had test sui

Re: Concerns regarding the -ffp-contract=fast default

Hi Florian, On Thu, 14 Sep 2023, Alexander Monakov wrote: > > On Thu, 14 Sep 2023, Florian Weimer via Gcc wrote: > > > While rebuilding CentOS Stream with -march=x86-64-v3, I rediscovered > > several packages had test suite failures because x86-64 suddenly gained > > FMA support. I say “redisc

Re: Concerns regarding the -ffp-contract=fast default

On Thu, 14 Sep 2023, Florian Weimer via Gcc wrote: > While rebuilding CentOS Stream with -march=x86-64-v3, I rediscovered > several packages had test suite failures because x86-64 suddenly gained > FMA support. I say “rediscovered” because these issues were already > visible on other architectu

Concerns regarding the -ffp-contract=fast default

While rebuilding CentOS Stream with -march=x86-64-v3, I rediscovered several packages had test suite failures because x86-64 suddenly gained FMA support. I say “rediscovered” because these issues were already visible on other architectures with FMA. So far, our package/architecture maintainers ha

Re: Compilation Error Regarding RID_MAX

On Wed, Sep 13, 2023 at 9:38 PM Andrew Pinski wrote: > > On Wed, Sep 13, 2023 at 9:35 PM Ken Matsui wrote: > > > > On Wed, Sep 13, 2023 at 9:23 PM Andrew Pinski wrote: > > > > > > On Wed, Sep 13, 2023 at 9:09 PM Ken Matsui via Gcc > > > wrote: > > > > > > > > Hi, > > > > > > > > I have merged

Re: Compilation Error Regarding RID_MAX

On Wed, Sep 13, 2023 at 9:35 PM Ken Matsui wrote: > > On Wed, Sep 13, 2023 at 9:23 PM Andrew Pinski wrote: > > > > On Wed, Sep 13, 2023 at 9:09 PM Ken Matsui via Gcc wrote: > > > > > > Hi, > > > > > > I have merged all my patches into a single branch for better > > > maintainability for me, but

Re: Compilation Error Regarding RID_MAX

On Wed, Sep 13, 2023 at 9:23 PM Andrew Pinski wrote: > > On Wed, Sep 13, 2023 at 9:09 PM Ken Matsui via Gcc wrote: > > > > Hi, > > > > I have merged all my patches into a single branch for better > > maintainability for me, but I am unable to build GCC. Initially, I > > faced an error related to

Re: Compilation Error Regarding RID_MAX

On Wed, Sep 13, 2023 at 9:09 PM Ken Matsui via Gcc wrote: > > Hi, > > I have merged all my patches into a single branch for better > maintainability for me, but I am unable to build GCC. Initially, I > faced an error related to RID_MAX, which was fixed in > https://github.com/ken-matsui/gcc-gsoc23

Compilation Error Regarding RID_MAX

Hi, I have merged all my patches into a single branch for better maintainability for me, but I am unable to build GCC. Initially, I faced an error related to RID_MAX, which was fixed in https://github.com/ken-matsui/gcc-gsoc23/commit/c32d49bc990acde4d3ec5654ddb81b0a7d081378. The ICE was caused by

Help regarding architecture and related info needed for ELF header

like architecture, machine type and OS ABI in ELF header rather than reading it from crtbegin.o. I tried my hand at it but couldn't find anything substantial. Any suggestion regarding the same will be helpful! Also a question to Jan and Martin, right now should I focus on debugging part or get

Re: Regarding bypass-asm patch and help in an error during bootstrapped build

6:22: error inline function ‘static bool > > is_a_helper::test(U*) [with U = symtab_node; T = varpool_node*]’ used > > but never defined [enabled by default] > > > > I have tested the .symtab and dummy symbols addition on the > > non-bootstrapped build, and they ar

Re: Regarding bypass-asm patch and help in an error during bootstrapped build

ymbols addition on the > non-bootstrapped build, and they are working fine. I also ran the lto test > suite, and it passed as expected. I am looking into the error produced > during bootstrapped build currently. I would appreciate any help/guidance > regarding this. This is because you mis

Regarding bypass-asm patch and help in an error during bootstrapped build

produced during bootstrapped build currently. I would appreciate any help/guidance regarding this. -- Regards Rishi

Re: Patch regarding addition of .symtab while generating object file from libiberty [WIP]

On Mon, 26 Jun 2023 at 23:24, Jan Hubicka wrote: > > > > +simple_object_write_add_symbol(simple_object_write *sobj, const char > > > *name, > > > > +size_t size, unsigned int align); > > > > > > Symbols has much more properties in addition to sizes and alignments. > > > We will eventually need to

Re: Patch regarding addition of .symtab while generating object file from libiberty [WIP]

> > > +simple_object_write_add_symbol(simple_object_write *sobj, const char > > *name, > > > +size_t size, unsigned int align); > > > > Symbols has much more properties in addition to sizes and alignments. > > We will eventually need to get dwarf writting, so we will need to > > support them. Howev

Re: Patch regarding addition of .symtab while generating object file from libiberty [WIP]

> __gnu_lto_slim symbol into it so that at a later stage, it can be > > recognized that this object file has been produced using -flto enabled. > > This patch is regarding the same. Although I am still testing this > patch, I > > want general feedback on my code and design

Re: Patch regarding addition of .symtab while generating object file from libiberty [WIP]

this object file has been produced using -flto enabled. > This patch is regarding the same. Although I am still testing this patch, I > want general feedback on my code and design choice. > I have extended simple_object_wrtie_struct to hold a list of symbols ( > similar to sections ). A funct

Patch regarding addition of .symtab while generating object file from libiberty [WIP]

s patch is regarding the same. Although I am still testing this patch, I want general feedback on my code and design choice. I have extended simple_object_wrtie_struct to hold a list of symbols ( similar to sections ). A function in simple-object.c to add symbols. I am calling this function in lto-object

Re: I have questions regarding the 4.3 codebase...

I'll take a look, Paul, thanks. It hadn't occurred to me to compare different machines' uses. -+- Sid On Thu, Mar 23, 2023 at 10:29 AM Paul Koning wrote: > > > > On Mar 23, 2023, at 10:13 AM, Sid Maxwell via Gcc > wrote: > > > > Thanks for reaching out, Julian, I greatly appreciate your help.

Re: I have questions regarding the 4.3 codebase...

> On Mar 23, 2023, at 10:13 AM, Sid Maxwell via Gcc wrote: > > Thanks for reaching out, Julian, I greatly appreciate your help. Please > forgive and over- or under-sharing. If I've left something out, please let > me know. > > From my pdp10.md: > > ;; JIRA sw_gcc-68. gcc recognizes the "m

Re: I have questions regarding the 4.3 codebase...

Thanks for reaching out, Julian, I greatly appreciate your help. Please forgive and over- or under-sharing. If I've left something out, please let me know. >From my pdp10.md: ;; JIRA sw_gcc-68. gcc recognizes the "movmemhi" 'instruction' for ;; doing block moves, as in struct assignment. This

Re: I have questions regarding the 4.3 codebase...

On Wed, 22 Mar 2023 18:27:28 -0400 Sid Maxwell via Gcc wrote: > Is there anyone on the list with experience with the gcc 4.3 > codebase? I'm currently maintaining a fork of it, with a PDP10 code > generator. > > I've run into an issue involving the transformation of a movmemhi to a > single PDP

I have questions regarding the 4.3 codebase...

Is there anyone on the list with experience with the gcc 4.3 codebase? I'm currently maintaining a fork of it, with a PDP10 code generator. I've run into an issue involving the transformation of a movmemhi to a single PDP10 instruction (an xblt, if you're curious). The transformation appears to

Re: Regarding GSOC

Hello, please CC the mailing list on these discussions. On Fri, Mar 17 2023, Megha Raj wrote: > Thank you for your mail > Now I'm focusing on internal working of compiler > As having a rough idea is enough for the contribution or I need depth > knowledge?? that depends on the project but for man

Re: Regarding GSOC

Hello, On Mon, Mar 13 2023, Megha Raj via Gcc wrote: > Respected sir/mam, > > Actually I want to know what are skills you desire to have in the members > of your organization as I’m aware with c &c++ so, can you please let me > know other than this what knowledge should I know for getting selected

Regarding GSOC

Respected sir/mam, Actually I want to know what are skills you desire to have in the members of your organization as I’m aware with c &c++ so, can you please let me know other than this what knowledge should I know for getting selected in your franchise in deep

Re: Question regarding copyright assignment

Antoni, You'll want to get an employer disclaimer signed by your employer to make sure your contributions cannot be claimed by them. Please email ass...@fsf.org and we can work through the process. -- All the best, Craig Topham Copyright & Licensing Associate Free Software Foundation 51 Frankli

Re: Question regarding copyright assignment

On Thu, Oct 6, 2022 at 8:58 PM Antoni Boucher via Gcc wrote: > Hi. > I contribute to gcc outside of work, but I'm about to sign a new work > contract which contains a work ownership clause saying that I give the > ownership to the company of any work not listed in some appendix. > > What exactly

Question regarding copyright assignment

Hi. I contribute to gcc outside of work, but I'm about to sign a new work contract which contains a work ownership clause saying that I give the ownership to the company of any work not listed in some appendix. What exactly should I list to make sure my contributions to GCC are not affected by thi

Re: Regarding gnu.org

Hi, So, what do you think? Regards, Mark Smith [image: Mailtrack] Sender notified by Mailtrack 07/29/22,

Regarding gnu.org

Hello , I am currently representing the sale of the following domain: *GNU .ai* I can share with you the pricing and other details. Looking forward to hearing from you. Regards, Mark Smith

Re: Updating patch regarding bypassing assembler when generating LTO object files

Hi Ankur, > On 8 May 2022, at 15:29, Ankur Saini via Gcc wrote: > > I have been fiddling around with the patch regarding "bypassing assmebler > while generating slim lto files" and managed to make it build with the > current trunk. Though the patch seems to be wor

Updating patch regarding bypassing assembler when generating LTO object files

Hi, I have been fiddling around with the patch regarding "bypassing assmebler while generating slim lto files" and managed to make it build with the current trunk. Though the patch seems to be working on Linux machine, it causes an ICE on macOS (it crashes in langhooks.cc while

Re: Query regarding GSoC

On Thu, Mar 17, 2022 at 1:39 PM Riva Malthiyar via Gcc wrote: > > Respected mentor, > I am Riva Malthiyar from India. I am experienced in C/C++. I saw the list > of projects in your GSoC project ideas and wish to work in one of them. In > the "Before You Apply" Section there is something related t

Query regarding GSoC

Respected mentor, I am Riva Malthiyar from India. I am experienced in C/C++. I saw the list of projects in your GSoC project ideas and wish to work in one of them. In the "Before You Apply" Section there is something related to compiler, I did not understand that point. What kind of compiler is nee

Re: Project guidance regarding the cp-demangler non recursive .

make sure you do understand the algorithmic issues behind the project very well before embarking on the project. Looking things up there on the go is definitely not good enough. > As you are the project mentor I would like to ask guidance from you > regarding the process of the project ,how to

Regarding passing additional parameters in runtime schedule

Dear gcc, I wanted to pass the address of an array defined in C code to the runtime schedule in libgomp. Basically I want to pass some information from the C code to the scheduler in OpenMp. I don't know how to achieve it. After analyzing the assembly code generated by GCC, I understood there is

Re: Query regarding generating NOTE instruction at GIMPLE level

On Sun, Feb 6, 2022 at 8:42 PM Shubham Narlawar via Gcc wrote: > > Hello, > > Is it possible to generate a NOTE instruction at GIMPLE level? > > My use case scenario is as below - > I want to create a note for __builtin_xyz(_x) such that there is a > placeholder just before function call and in RT

Query regarding generating NOTE instruction at GIMPLE level

Hello, Is it possible to generate a NOTE instruction at GIMPLE level? My use case scenario is as below - I want to create a note for __builtin_xyz(_x) such that there is a placeholder just before function call and in RTL pass, I want to modify/assign register number at this placeholder location.

RE: Re: Query regarding unusual behaviour for tail padding with different c++ standards

> On Mon, 13 Dec 2021 at 05:14, Andrew Pinski wrote: > > > > On Sun, Dec 12, 2021 at 9:04 PM Nayan Deshmukh via Gcc   > >wrote: > > > #include  > > > #include  > > > #include  > > > struct A { > > >   int a; > > >   uint64_t b; > > >   int c = -1; > > > }; > > > > The question becomes is the above 

Re: Query regarding unusual behaviour for tail padding with different c++ standards

On Mon, 13 Dec 2021 at 05:14, Andrew Pinski wrote: > > On Sun, Dec 12, 2021 at 9:04 PM Nayan Deshmukh via Gcc > wrote: > > #include > > #include > > #include > > struct A { > > int a; > > uint64_t b; > > int c = -1; > > }; > > The question becomes is the above a standard layout class or

Re: Query regarding unusual behaviour for tail padding with different c++ standards

On Sun, Dec 12, 2021 at 9:04 PM Nayan Deshmukh via Gcc wrote: > #include > #include > #include > struct A { > int a; > uint64_t b; > int c = -1; > }; The question becomes is the above a standard layout class or not. I Noticed clang does not change the rules for layout between C++11 and C

Query regarding unusual behaviour for tail padding with different c++ standards

Hello, When I tried to link two modules which were compiled with different c++ standards, I observed that the offset of some fields of struct were different when the same struct was accessed from both the modules. The issue is due to the use of tail padding to allocate member variables in some

Re: Regarding __gcov_dump and __gcov_reset usage

@gcc.gnu.org Subject: Re: Regarding __gcov_dump and __gcov_reset usage On 5/24/21 1:44 PM, Gejoe Daniel via Gcc wrote: > Adding gcc mailing list for the clarification. > > Thank you team !  > > From: "Gejoe Daniel"<gej...@rediffmail.com>; >

Re: Fw: Regarding __gcov_dump and __gcov_reset usage

On 5/24/21 1:44 PM, Gejoe Daniel via Gcc wrote: Adding gcc mailing list for the clarification. Thank you team !  From: "Gejoe Daniel"<gej...@rediffmail.com> Sent: Mon, 24 May 2021 15:02:12 To: "gcc-h...@gcc.gnu.org"<gcc-h...@gcc.gnu.org> Subject: Re: Regard

Fw: Regarding __gcov_dump and __gcov_reset usage

Adding gcc mailing list for the clarification. Thank you team !  From: "Gejoe Daniel"<gej...@rediffmail.com> Sent: Mon, 24 May 2021 15:02:12 To: "gcc-h...@gcc.gnu.org"<gcc-h...@gcc.gnu.org> Subject: Re: Regarding __gcov_dump and __gcov_reset usage Hi team, A

Regarding last question

Never mind... assume I'm grumbling about the documentation. ;-( Gary 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.

Re: A silly question regarding function types

On Fri, Sep 4, 2020 at 4:39 AM Gary Oblock via Gcc wrote: > > Note, isn't a problem, rather, it's something that puzzles me. > > On walking a function types argument types this way > > for ( arg = TYPE_ARG_TYPES ( func_type); >arg != NULL; >arg = TREE_CHAIN ( arg)) > { >

A silly question regarding function types

Note, isn't a problem, rather, it's something that puzzles me. On walking a function types argument types this way for ( arg = TYPE_ARG_TYPES ( func_type); arg != NULL; arg = TREE_CHAIN ( arg)) { . . } I noticed an extra void argument that didn't exist tagged

Re: Questions regarding update_stmt and release_ssa_name_fn.

type_t * min_x; > int i; > struct type_t * data; > >[local count: 10737416]: > data_10 = malloc (16); > goto ; [100.00%] > >[local count: 1063004409]: > _1 = _4 * 16; > _2 = data_10 + _1; > _3 = drand48 (); > _2->x = _3; > i_

Re: Questions regarding update_stmt and release_ssa_name_fn.

goto ; [0.04%] else goto ; [99.96%] [local count: 4295]: __builtin_puts (&"min_x error"[0]); exit (-1); [local count: 10733121]: _5 = min_x_12->x; printf ("min_x %e\n", _5); return 0; } Am I crazy? Thanks, Gary _

Re: Questions regarding update_stmt and release_ssa_name_fn.

A operand of that stmt. Richard. >Thanks, > >Gary > >From: Richard Biener >Sent: Thursday, August 27, 2020 2:04 AM >To: Gary Oblock >Cc: gcc@gcc.gnu.org >Subject: Re: Questions regarding update_stmt and release_ssa_name_fn. > >[EXTER

Re: Questions regarding update_stmt and release_ssa_name_fn.

then update that statement. Thanks, Gary From: Richard Biener Sent: Thursday, August 27, 2020 2:04 AM To: Gary Oblock Cc: gcc@gcc.gnu.org Subject: Re: Questions regarding update_stmt and release_ssa_name_fn. [EXTERNAL EMAIL NOTICE: This email originated from an e

Re: Questions regarding update_stmt and release_ssa_name_fn.

On Wed, Aug 26, 2020 at 11:32 PM Gary Oblock via Gcc wrote: > > I'm having some major grief with a few related things that I'm try to > do. The mostly revolve around trying to change the type of an SSA name > (which I've given up in favor of creating new SSA names and replacing > the ones I wanted

Questions regarding update_stmt and release_ssa_name_fn.

I'm having some major grief with a few related things that I'm try to do. The mostly revolve around trying to change the type of an SSA name (which I've given up in favor of creating new SSA names and replacing the ones I wanted to change.) However, this seems too has its own issues. In one proble

Re: Question regarding usage of vec.h

Hi Chung-Lin, I think you need to initialize the 'vec extrema' field with vNULL, or maybe some other constructor. Thanks, I'll give it a try. Regards Thomas

Re: Question regarding usage of vec.h

On 2020/8/3 12:24 AM, Thomas Koenig via Gcc wrote: Hi, in a patch I am developing, I have the following code: typedef struct {   gfc_code *c;   int branch_level;   bool seen_goto;   vec extrema; } do_t; static vec doloop_list; [...]   do_t loop;   doloop_list.safe_push (loop);   do

Question regarding usage of vec.h

Hi, in a patch I am developing, I have the following code: typedef struct { gfc_code *c; int branch_level; bool seen_goto; vec extrema; } do_t; static vec doloop_list; [...] do_t loop; doloop_list.safe_push (loop); doloop_list.last().extrema.reserve (1 << doloop_level); wher

Re: Questions regarding control flow during IPA passes

On Fri, Jul 3, 2020 at 6:04 AM Gary Oblock via Gcc wrote: > > At IPA time I'm creating GIMPLE statements. I've noticed during dumps > that gotos and labels don't seem to exist. In fact when I tried > introducing them, at least the gotos, failed. I assume that at this > point in compilation GCC re

Questions regarding control flow during IPA passes

At IPA time I'm creating GIMPLE statements. I've noticed during dumps that gotos and labels don't seem to exist. In fact when I tried introducing them, at least the gotos, failed. I assume that at this point in compilation GCC relies on the control flow graph (which I'm updating as I create new BB

Re: [OMPD] regarding const char **ompd_dll_locations

On Thu, Jun 18, 2020 at 06:19:43PM -0400, y2s1982 . wrote: > Thank you for the quick response. I assume, then, there's no need for > making a function to set this global variable at this point. Should I > create a simple unit test that asserts the value to be "libgompd.so.1" for > now, or should I

Re: [OMPD] regarding const char **ompd_dll_locations

Hello Jakub, Thank you for the quick response. I assume, then, there's no need for making a function to set this global variable at this point. Should I create a simple unit test that asserts the value to be "libgompd.so.1" for now, or should I skip the unit test on this for now? Cheers, Tony Si

Re: [OMPD] regarding const char **ompd_dll_locations

On Thu, Jun 18, 2020 at 05:24:25PM -0400, y2s1982 . wrote: > (LLVM currently simply puts { "ompd.so", NULL }, but I am assuming this was > just a placeholder.) Let's put there { "libgompd" SONAME_SUFFIX (1), NULL } for now. You'll need to change the SONAME_SUFFIX macros though - remove the ()s aro

[OMPD] regarding const char **ompd_dll_locations

Hello everyone, I would like to share some of my thoughts and seek some opinions on coding for const char **ompd_dll_locations. After reviewing the documentation , looking over LLVM approach

DejaGnu/GCC testsuite behavior regarding multiple 'dg-do'

Hi! Comparing DejaGnu/GCC testsuite '*.sum' files between two systems ("old" vs. "new") that ought to return identical results, I found that they didn't: @@ -75032,6 +75023,7 @@ PASS: g++.dg/expr/bitfield4.C -std=c++98 (test for excess errors) PASS: g++.dg/expr/bitfield5.C -std=c++14

Re: Request for clarification regarding C++ version requirements in non-C++ frontends

On October 19, 2019 9:11:52 AM GMT+02:00, The Other wrote: >Hi, > >I'm currently working on a branch of gccrs aiming to create some kind >of >Rust frontend within GCC. I've advanced to the stage where attempting >to >use pre-C++11 features is becoming inconvenient, particularly in the >unique_ptr

Request for clarification regarding C++ version requirements in non-C++ frontends

Hi, I'm currently working on a branch of gccrs aiming to create some kind of Rust frontend within GCC. I've advanced to the stage where attempting to use pre-C++11 features is becoming inconvenient, particularly in the unique_ptr department. Part of the frontend AST is best expressed as vectors of

Urgent - Regarding SMS Count

Hi Team, Please kindly confirm the attached monthly sms counts and get back to us asap as we are about to release the payment for September sms push, to release October SMS payment in few days to come as well. Download link http://emaila.drbatras.com/gtrack?clientid=283&ul= BwdVCwECCBgITQFQAHJf

  1   2   3   4   5   6   >