Re: Question?

Hi just a quick question, My name is Chamsi Pirson. I'm a freelance writer, with 5 years of experience, creating content for varied online portals. I have expertise in writing about technology related topics. You can check out some of my previous posts here and here! I'm reaching out

openmp question

Jakub, is libgomp/testsuite/libgomp.c++/udr-3.C well formed? Specifically V::baz? If you remove the templatedness and plug in typedefs for T & D on its only instantiation (as the attached does), you get the following errors: devvm293:414>g++ -std=c++11 -c -fopenmp udr-3.C udr-3.C: In member f

trapv question

  exit (0); And then the test case fails because it uses -ftrapv and expects there to be a trap and it was removed IT can all be disabled by not registering that relationship when flag_trapv is set... my question is whether that is the correct solution tho... It seems to me it might jus

Dominators question

When something like the loop unswitching code adds elements to the CFGs, does this invalidate the dominators? or are they updated?  or is it in an in between state. Im curious because a) the relation code uses it under the covers, and b) Im looking to add a ranger caching improvement which als

Re: openmp question

^ I guess you're right that W::W(int) should be defined. And the question is why it isn't diagnosed during instantiation, sure. The initialized (omp_priv (12)) etc. clause means that for the type(s) for which the declare reduction is defined, when omp-low.c privatizes the variable,

Re: trapv question

e it uses -ftrapv and expects there >to be a trap and it was removed > > >IT can all be disabled by not registering that relationship when >flag_trapv is set... my question is whether that is the correct >solution >tho... > >It seems to me it might just be the t

Question on __gcov_indirect_call

piling .c with adding -ftls-model=initial-exec, the above linking error disappeared. Our question is: If __gcov_indirect_call can be linked into a shared library and can be referenced from non-PIC code ? If So, gcc should generate more relaxed TLS mode for it. Thanks a lot for your help. Qing

Re: Dominators question

On December 3, 2021 3:15:25 PM GMT+01:00, Andrew MacLeod wrote: >When something like the loop unswitching code adds elements to the CFGs, >does this invalidate the dominators? or are they updated?  or is it in >an in between state. > >Im curious because a) the relation code uses it under the co

Re: Dominators question

On 12/3/21 11:46, Richard Biener wrote: On December 3, 2021 3:15:25 PM GMT+01:00, Andrew MacLeod wrote: When something like the loop unswitching code adds elements to the CFGs, does this invalidate the dominators? or are they updated?  or is it in an in between state. Im curious because a) th

Re: Dominators question

On 12/14/2021 12:51 PM, Andrew MacLeod via Gcc-patches wrote: On 12/3/21 11:46, Richard Biener wrote: On December 3, 2021 3:15:25 PM GMT+01:00, Andrew MacLeod wrote: When something like the loop unswitching code adds elements to the CFGs, does this invalidate the dominators? or are they up

Question regarding bug 70584

While analysing this bug we arrived to the following code at tree.c:145 (lvalue_kind): case VAR_DECL: if (TREE_READONLY (ref) && ! TREE_STATIC (ref) && DECL_LANG_SPECIFIC (ref) && DECL_IN_AGGR_P (ref)) return clk_none; That condition fails so a fall-through to the next c

lambda capture scope question

Jason, What is the scope of a lambda capture? AFAICT it depends on whether the capture is simple or initialized. the attached program prints: [x] is i [x=x] is i [x=x] {short x;} is s I'm not sure that's right. The clearest one is an initialized capture. [5.1.6]/12 says this is equivalent t

demangler output format question

I discovered a bug in my fix for 82195, but it leads me towards a design question whose answer is not obvious to me the simplest testcase is: void Foo () { // _ZZ3FoovENKUlT_E_clIiEEfS_ [](auto) ->float { struct Local { // _ZZZ3FoovENKUlT_E_clIiEEfS_EN5Local2fnEv sta

[patch] Re: trapv question

(0); }    else if (child == -1) Is that the right thing to do? THanks Andrew Done... pushed commit 842afc4e289ed3fe69583672c1a180f268d73799 Author: Andrew MacLeod Date: Wed Jan 20 16:27:34 2021 -0500 Re: trapv question Adjust testcase to so the ADD that is expected

Basic REG_EQUIV comprehension question

Hi, I have been working on making better use of s390's vzero instruction. Currently we rather zero a vector register once and load it into other registers via vlr instead of emitting multiple vzeros. At IRA/reload point we e.g. have (insn 8 5 19 2 (set (reg/v:V2DI 64 [ zero ]) (const_vec

A GGC related question

of_compilation, but if inlining happens, it crashes down. if the functions are independent, is it safe to force to do GGC after tree_rest_of_compilation? Brs, Thanks! danxiaoqiang -- View this message in context: http://gcc.1065356.n5.nabble.com/A-GGC-related-question-tp988400.htm

A question about forward_addr.

f 'addr r155' + 8 is equal to 'addr r167 + 40', so I think that we should preffer to take the new addr, technically will be profitable ??? Brs, Peter Xu. - Dying in the sun. -- View this message in context: http://gcc.1065356.n5.nabble.com/A-question-about-forward

Question about gimplify.c:gimplify_adjust_omp_clauses_1, GOVD_MAP_TO_ONLY

Hi! In gimplify.c:gimplify_adjust_omp_clauses_1, does the case for GOVD_MAP_TO_ONLY have a real current use case (I couldn't spot any), or is it "just for completeness"? diff --git gcc/gimplify.c gcc/gimplify.c index 3738589..870550c 100644 --- gcc/gimplify.c +++ gcc/gimplify.c @@ -6136,9 +6136,9

Re: Question regarding bug 70584

(reposting in gcc@ and adding more information) On Fri, May 20, 2016 at 3:43 PM, Andres Tiraboschi wrote: > While analysing this bug we arrived to the following code at > tree.c:145 (lvalue_kind): > > case VAR_DECL: > if (TREE_READONLY (ref) && ! TREE_STATIC (ref) > && DECL_LANG_S

Re: Question regarding bug 70584

On 05/20/2016 01:18 PM, Daniel Gutson wrote: (reposting in gcc@ and adding more information) On Fri, May 20, 2016 at 3:43 PM, Andres Tiraboschi wrote: While analysing this bug we arrived to the following code at tree.c:145 (lvalue_kind): case VAR_DECL: if (TREE_READONLY (ref) && ! T

Re: Question regarding bug 70584

On Fri, May 20, 2016 at 5:42 PM, Jeff Law wrote: > On 05/20/2016 01:18 PM, Daniel Gutson wrote: >> >> (reposting in gcc@ and adding more information) >> >> On Fri, May 20, 2016 at 3:43 PM, Andres Tiraboschi >> wrote: >>> >>> While analysing this bug we arrived to the following code at >>> tree.c:

Question about lambda function variables

nally { ASAN_MARK (1, &message, 4); } } Where for quite obvious reasons variables 'message' can't be put as a stack variable and ICE is triggered in: /tmp/use-after-scope-ice-1.ii:31:23: internal compiler error: in make_decl_rtl, at varasm.c:1311 My question is how to p

RE: Question about default_elf_asm_named_section function

: Friday, October 14, 2011 4:29 PM To: Iyer, Balaji V Cc: 'g...@gcc.gnu.org' Subject: Re: Question about default_elf_asm_named_section function "Iyer, Balaji V" writes: > Can I submit a patch for it? Or is it a small thing that patch is not > necessary? I will preapprov

Re: Basic REG_EQUIV comprehension question

Small addition to clarify: (insn 8) from the example is of course matched to a vzero. The "problem" begins when (reg 64) is later moved into another register and the (const_vector) has been optimized to a single definition e.g. by CSE, i.e. we have several (insn yy (set (reg:V2DI xx) (reg:V2DI 6

Re: Basic REG_EQUIV comprehension question

Robin Dapp via Gcc-patches writes: > Hi, > > I have been working on making better use of s390's vzero instruction. > Currently we rather zero a vector register once and load it into other > registers via vlr instead of emitting multiple vzeros. > > At IRA/reload point we e.g. have > > (insn 8 5 19

Re: Basic REG_EQUIV comprehension question

> Yeah, rtx_costs (or preferably insn_cost, if that works) seem like the > best way of addressing this. If the target says that register moves are > cheaper than constant moves then it's a feature that CSE & co remove > duplicate constants. The REG_EQUIV note is still useful in those cases > beca

Re: question about register pairs

Yup, my registers are smaller than Pmode. This is what I ended up with... Some notes: I lie to gcc and tell it that $fp (reg 22) is two bytes when it's really one. None of the register classes have reg 23 (used for the upper half of $fp) in them. Reg 23 is also listed as being two bytes, to ke

Re: question about register pairs

On 25 October 2013 05:15, DJ Delorie wrote: > > Yup, my registers are smaller than Pmode. > > This is what I ended up with... > > Some notes: I lie to gcc and tell it that $fp (reg 22) is two bytes > when it's really one. Well, it's not really a lie if you map hardware registers 22 and 23 to a si

Re: question about register pairs

> > Some notes: I lie to gcc and tell it that $fp (reg 22) is two bytes > > when it's really one. > > Well, it's not really a lie if you map hardware registers 22 and 23 to > a single register for the purposes of gcc internals. Yeah, I'm basically making those two registers into a permanent bigg

Re: question about register pairs

> Seeing the patched code in its entirety like this, I notice that we > would use HARD_REGNO_NREGS for a regno that's not ok for the mode. > That can be avoided if we put a break into the if. And then the > !bad term in the loop condition becomes redundant. Although the > HARD_REGNO_NREGS defini

Re: A GGC related question

On 11/22/2013, 8:08 AM, dxq wrote: hi, I'm doing a work to make unroll, doloop, and sms pass work together as following way: * before the first unroll pass, duplicate all global information such as insn chain and CFG as backup. * unroll with factor = 1, go on to finish sms, and record the

Re: A GGC related question

cc crashes down. That's what I can think of. you know, it's a very big and hard work. do you have any suggestions about our current solution? thanks for your reply! danxiaoqiang -- View this message in context: http://gcc.1065356.n5.nabble.com/A-GGC-related-question-tp988

Re: A GGC related question

On 11/22/2013, 8:04 PM, dxq wrote: fixing SMS, do you mean that we only modify the SMS pass? You don't need loop unrolling when you have a good software pipelining and loop vectorization. A good software pipelining can see through any number of iterations and has no problems with code cache l

Re: A GGC related question

ply! >danxiaoqiang > > > > -- > View this message in context: > http://gcc.1065356.n5.nabble.com/A-GGC-related-question-tp988400p988645.html > Sent from the gcc - patches mailing list archive at Nabble.com.

Re: Question about gimplify.c:gimplify_adjust_omp_clauses_1, GOVD_MAP_TO_ONLY

On Thu, Jan 09, 2014 at 09:38:25PM +0100, Thomas Schwinge wrote: > In gimplify.c:gimplify_adjust_omp_clauses_1, does the case for > GOVD_MAP_TO_ONLY have a real current use case (I couldn't spot any), or > is it "just for completeness"? It is typically for any artificial vars that are known not to

Re: Question about gimplify.c:gimplify_adjust_omp_clauses_1, GOVD_MAP_TO_ONLY

Hi! On Thu, 9 Jan 2014 21:43:35 +0100, Jakub Jelinek wrote: > On Thu, Jan 09, 2014 at 09:38:25PM +0100, Thomas Schwinge wrote: > > In gimplify.c:gimplify_adjust_omp_clauses_1, does the case for > > GOVD_MAP_TO_ONLY have a real current use case (I couldn't spot any), or > > is it "just for complet

Re: Question about gimplify.c:gimplify_adjust_omp_clauses_1, GOVD_MAP_TO_ONLY

Hi! On Thu, 09 Jan 2014 23:21:26 +0100, I wrote: > On Thu, 9 Jan 2014 21:43:35 +0100, Jakub Jelinek wrote: > > On Thu, Jan 09, 2014 at 09:38:25PM +0100, Thomas Schwinge wrote: > > > In gimplify.c:gimplify_adjust_omp_clauses_1, does the case for > > > GOVD_MAP_TO_ONLY have a real current use case

Re: question about section 10.12

> From: Kenneth Zadeck > Date: Mon, 28 Jan 2013 02:02:41 +0100 > this looks good to me. does your patch also address the vec_concat > issue that marc raised? You mean the issue being "same thing there"? I can confirm that (I've stumbled upon) the same issue being there (i.e. similarly applies

Question about submitting an article

Hi there, I'm a member of the content team at ATI Restoration, a disaster recovery firm. I have a connection that works with a number of related organizations, and they mentioned that you might be open to publishing submitted articles. Is this true, and if so, what are the guidelines? Thank you!

OpenACC data clause syntax question/patch

While trying to get the following benchmarks to run: https://codesign.llnl.gov/lulesh.php I came across some cases where the code and the compiler differed in its interpretation of the OpenACC spec. Specifically, this occurs for acc data clauses with arrays, like: #pragma acc data copyin(a[

Re: Question about lambda function variables

r quite obvious reasons variables 'message' can't be put as a stack > variable and ICE is triggered in: > /tmp/use-after-scope-ice-1.ii:31:23: internal compiler error: in > make_decl_rtl, at varasm.c:1311 > > My question is how to properly identify local variab

Re: Question about lambda function variables

::DispatchConnectionCloseEvent (_1, __closure->__message); >> } >> finally >> { >> ASAN_MARK (1, &message, 4); >> } >> } >> >> Where for quite obvious reasons variables 'message' can't be put as a stac

question on Multiple level macro expansion

) \ instr (addr) The compilation succeed. also icc can successfully compile the original small testing case. My question is: is this a bug for GCC? or this is a coding error? thanks a lot for your help. Qing

Question about non-POD class type

For an instance of a non-POD class, can I always assume that any operation on it should be type-safe, any wrong or even trick code to violate this is UB in C++ spec? For example, here are some ways: union { Type1 *p1; Type2 *p2; }; or union { Type1 t1; Type2 t2; }; or void

Question on -fwrapv and -fwrapv-pointer

Hi, I have several questions on these options: 1.are pointers treated as signed integers in general? (I thought that pointers are addresses to the memory, should be treated as unsigned integer…) 2. If Yes, why? 3. why a separate option for pointesr -fwrapv-pointer in addition to -fwrapv if the

Question on patch -fprofile-partial-training

e.c (tree_profiling): Only do value_profile_transformations when profile is read. My question is: Can this patch be back ported to GCC8 easily? I am wondering any significant Change between GCC8 and GCC10 that might make the backporting very hard? Thanks a lot for your help. Qing

Re: OpenACC data clause syntax question/patch

On Fri, Sep 23, 2016 at 06:02:32PM +0200, Bernd Schmidt wrote: > While trying to get the following benchmarks to run: > https://codesign.llnl.gov/lulesh.php > > I came across some cases where the code and the compiler differed in its > interpretation of the OpenACC spec. Specifically, this occur

Ping: question on Multiple level macro expansion

Hi, This is a ping on: https://gcc.gnu.org/ml/gcc-patches/2019-09/msg01628.html Anyway, I filed a gcc bug on this issue: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91973 If you t

Patch ping and question about copyright assignment

Hi, all! I'm pinging about this patch: https://gcc.gnu.org/ml/gcc-patches/2014-12/msg01925.html (PR c/48956) I know that maybe it's too early for sending a ping (less than 2 weeks), but I also have a question regarding my patch: Is this patch considered small enough to be accept

Re: Question on -fwrapv and -fwrapv-pointer

On Thu, Sep 14, 2023 at 3:42 PM Qing Zhao via Gcc-patches wrote: > > Hi, > > I have several questions on these options: > > 1.are pointers treated as signed integers in general? (I thought that > pointers are addresses to the memory, should be treated as unsigned integer…) > 2. If Yes, why? > 3.

Re: Question on -fwrapv and -fwrapv-pointer

Thanks for the info. > On Sep 14, 2023, at 10:06 AM, Richard Biener > wrote: > > On Thu, Sep 14, 2023 at 3:42 PM Qing Zhao via Gcc-patches > wrote: >> >> Hi, >> >> I have several questions on these options: >> >> 1.are pointers treated as signed integers in general? (I thought that >> poin

Re: Question on -fwrapv and -fwrapv-pointer

> Am 14.09.2023 um 17:01 schrieb Qing Zhao : > > Thanks for the info. > >> On Sep 14, 2023, at 10:06 AM, Richard Biener >> wrote: >> >>> On Thu, Sep 14, 2023 at 3:42 PM Qing Zhao via Gcc-patches >>> wrote: >>> >>> Hi, >>> >>> I have several questions on these options: >>> >>> 1.are poi

Re: Question on -fwrapv and -fwrapv-pointer

> On Sep 14, 2023, at 11:12 AM, Richard Biener > wrote: > > > >> Am 14.09.2023 um 17:01 schrieb Qing Zhao : >> >> Thanks for the info. >> >>> On Sep 14, 2023, at 10:06 AM, Richard Biener >>> wrote: >>> On Thu, Sep 14, 2023 at 3:42 PM Qing Zhao via Gcc-patches wrote: >>

Re: Question on -fwrapv and -fwrapv-pointer

On Thu, 2023-09-14 at 15:57 +, Qing Zhao via Gcc-patches wrote: > Currently, GCC behaves as following: > > /* True if overflow wraps around for the given integral or pointer type.  That >    is, TYPE_MAX + 1 == TYPE_MIN.  */ > #define TYPE_OVERFLOW_WRAPS(TYPE) \ >   (POINTER_TYPE_P (TYPE) 

Re: Question on -fwrapv and -fwrapv-pointer

> On Sep 14, 2023, at 12:18 PM, Xi Ruoyao wrote: > > On Thu, 2023-09-14 at 15:57 +, Qing Zhao via Gcc-patches wrote: >> Currently, GCC behaves as following: >> >> /* True if overflow wraps around for the given integral or pointer type. >> That >>is, TYPE_MAX + 1 == TYPE_MIN. */ >> #

Re: Question on -fwrapv and -fwrapv-pointer

On Thu, Sep 14, 2023 at 1:50 PM Qing Zhao via Gcc-patches wrote: > > > > > On Sep 14, 2023, at 12:18 PM, Xi Ruoyao wrote: > > > > On Thu, 2023-09-14 at 15:57 +, Qing Zhao via Gcc-patches wrote: > >> Currently, GCC behaves as following: > >> > >> /* True if overflow wraps around for the given

Re: Question on -fwrapv and -fwrapv-pointer

> On Sep 14, 2023, at 4:57 PM, Andrew Pinski wrote: > > On Thu, Sep 14, 2023 at 1:50 PM Qing Zhao via Gcc-patches > wrote: >> >> >> >>> On Sep 14, 2023, at 12:18 PM, Xi Ruoyao wrote: >>> >>> On Thu, 2023-09-14 at 15:57 +, Qing Zhao via Gcc-patches wrote: Currently, GCC behaves as

Re: Question on -fwrapv and -fwrapv-pointer

On Thu, Sep 14, 2023 at 01:57:41PM -0700, Andrew Pinski wrote: > Now -fsanitize=pointer-overflow is already there for GCC which was > added in r8-2238-gc9b39a4955f56fe609ef5478 . LLVM/clang also provides > it in the same timeframe too . > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80998 Ah, than

Re: Question on -fwrapv and -fwrapv-pointer

On Thu, 2023-09-14 at 21:41 +, Qing Zhao wrote: > > > CLANG already provided -fsanitize=unsigned-integer-overflow. GCC > > > might need to do the same. > > > > NO. There is no such thing as unsigned integer overflow. That option > > is badly designed and the GCC community has rejected a few ti

Re: Question on -fwrapv and -fwrapv-pointer

Qing Zhao writes: > Even though unsigned integer overflow is well defined, it might be > unintentional, shall we warn user about this? This would be better addressed by providing operators or functions that do overflow checking in the language, so that they can be explicitly used where overflow

Re: Question on -fwrapv and -fwrapv-pointer

> On Sep 15, 2023, at 3:43 AM, Xi Ruoyao wrote: > > On Thu, 2023-09-14 at 21:41 +, Qing Zhao wrote: CLANG already provided -fsanitize=unsigned-integer-overflow. GCC might need to do the same. >>> >>> NO. There is no such thing as unsigned integer overflow. That option >>> is badl

Re: Question on -fwrapv and -fwrapv-pointer

On Fri, Sep 15, 2023 at 8:12 AM Qing Zhao wrote: > > > > > On Sep 15, 2023, at 3:43 AM, Xi Ruoyao wrote: > > > > On Thu, 2023-09-14 at 21:41 +, Qing Zhao wrote: > CLANG already provided -fsanitize=unsigned-integer-overflow. GCC > might need to do the same. > >>> > >>> NO. There is n

Re: Question on -fwrapv and -fwrapv-pointer

> On Sep 15, 2023, at 8:41 AM, Arsen Arsenović wrote: > > > Qing Zhao writes: > >> Even though unsigned integer overflow is well defined, it might be >> unintentional, shall we warn user about this? > > This would be better addressed by providing operators or functions that > do overflow ch

Re: Question on -fwrapv and -fwrapv-pointer

> Am 15.09.2023 um 17:25 schrieb Qing Zhao : > >  > >> On Sep 15, 2023, at 8:41 AM, Arsen Arsenović wrote: >> >> >> Qing Zhao writes: >> >>> Even though unsigned integer overflow is well defined, it might be >>> unintentional, shall we warn user about this? >> >> This would be better ad

Re: Question on -fwrapv and -fwrapv-pointer

> On Sep 15, 2023, at 11:29 AM, Richard Biener > wrote: > > > >> Am 15.09.2023 um 17:25 schrieb Qing Zhao : >> >>  >> >>> On Sep 15, 2023, at 8:41 AM, Arsen Arsenović wrote: >>> >>> >>> Qing Zhao writes: >>> Even though unsigned integer overflow is well defined, it might be

Re: Question on -fwrapv and -fwrapv-pointer

On Fri, 2023-09-15 at 15:37 +, Qing Zhao wrote: > > > > On Sep 15, 2023, at 11:29 AM, Richard Biener > > wrote: > > > > > > > > > Am 15.09.2023 um 17:25 schrieb Qing Zhao : > > > > > >  > > > > > > > On Sep 15, 2023, at 8:41 AM, Arsen Arsenović > > > > wrote: > > > > > > > > > > > >

Re: Question on -fwrapv and -fwrapv-pointer

> Am 15.09.2023 um 17:37 schrieb Qing Zhao : > >  > >>> On Sep 15, 2023, at 11:29 AM, Richard Biener >>> wrote: >>> >>> >>> Am 15.09.2023 um 17:25 schrieb Qing Zhao : >>> >>>  >>> On Sep 15, 2023, at 8:41 AM, Arsen Arsenović wrote: Qing Zhao writes:

Re: Question on -fwrapv and -fwrapv-pointer

> On Sep 15, 2023, at 1:26 PM, Richard Biener > wrote: > > > >> Am 15.09.2023 um 17:37 schrieb Qing Zhao : >> >>  >> On Sep 15, 2023, at 11:29 AM, Richard Biener wrote: > Am 15.09.2023 um 17:25 schrieb Qing Zhao :  > On Sep 15, 2023,

Re: Question on -fwrapv and -fwrapv-pointer

> On Sep 15, 2023, at 12:53 PM, Xi Ruoyao wrote: > > On Fri, 2023-09-15 at 15:37 +, Qing Zhao wrote: >> >> >>> On Sep 15, 2023, at 11:29 AM, Richard Biener >>> wrote: >>> >>> >>> Am 15.09.2023 um 17:25 schrieb Qing Zhao :  > On Sep 15, 2023, at 8:41 AM, Arse

Re: Question on -fwrapv and -fwrapv-pointer

On Fri, Sep 15, 2023 at 08:18:28AM -0700, Andrew Pinski wrote: > On Fri, Sep 15, 2023 at 8:12 AM Qing Zhao wrote: > > > > > > > > > On Sep 15, 2023, at 3:43 AM, Xi Ruoyao wrote: > > > > > > On Thu, 2023-09-14 at 21:41 +, Qing Zhao wrote: > > CLANG already provided -fsanitize=unsigned-int

Re: Question on -fwrapv and -fwrapv-pointer

On Fri, Sep 15, 2023 at 05:47:08PM +, Qing Zhao wrote: > > > > On Sep 15, 2023, at 1:26 PM, Richard Biener > > wrote: > > > > > > > >> Am 15.09.2023 um 17:37 schrieb Qing Zhao : > >> > >>  > >> > On Sep 15, 2023, at 11:29 AM, Richard Biener > wrote: > > >

Re: Question on -fwrapv and -fwrapv-pointer

On Fri, Sep 15, 2023 at 11:43 AM Kees Cook via Gcc-patches wrote: > > On Fri, Sep 15, 2023 at 05:47:08PM +, Qing Zhao wrote: > > > > > > > On Sep 15, 2023, at 1:26 PM, Richard Biener > > > wrote: > > > > > > > > > > > >> Am 15.09.2023 um 17:37 schrieb Qing Zhao : > > >> > > >>  > > >> > > >

Re: Question on -fwrapv and -fwrapv-pointer

On Thu, Feb 15, 2024 at 12:32:17AM -0800, Fangrui Song wrote: > On Fri, Sep 15, 2023 at 11:43 AM Kees Cook via Gcc-patches > wrote: > > > > On Fri, Sep 15, 2023 at 05:47:08PM +, Qing Zhao wrote: > > > > > > > > > > On Sep 15, 2023, at 1:26 PM, Richard Biener > > > > wrote: > > > > > > > > >

Re: [PATCH] Rs6000 infrastructure cleanup (switches), question

No before I go an redo the main part of patch #2, I have a question, which people prefer. The current code has sequences of: target_flags |= MASK_FOO; /* set -mfoo */ if ((target_flags_explicit & MASK_FOO)) ... /* Did user do -mfo

Re: [PATCH] Rs6000 infrastructure cleanup (switches), question

On Tue, Oct 9, 2012 at 7:37 PM, Michael Meissner wrote: > No before I go an redo the main part of patch #2, I have a question, which > people prefer. > > The current code has sequences of: > > target_flags |= MASK_FOO; /* set -mfoo */ > if ((

Re: question about REG_PARM_STACK_SPACE usage in expand_call

On 13-12-13 06:43, Jeff Law wrote: Was this meant perhaps? ... || (reg_parm_stack_space != REG_PARM_STACK_SPACE (current_function_decl)) I think you're probably right. sibcall/tailcall basically re-use the current function's stack Jeff, Right, say we have function a tail-calling funct

Re: question about REG_PARM_STACK_SPACE usage in expand_call

On Sat, Dec 14, 2013 at 09:14:34PM +0100, Tom de Vries wrote: > I wonder if OUTGOING_REG_PARM_STACK_SPACE makes a difference here. > > If OUTGOING_REG_PARM_STACK_SPACE == 0, it is the responsibility of > the callee to allocate the area reserved for arguments passed in > registers. AFAIU, both func

Re: question about REG_PARM_STACK_SPACE usage in expand_call

On 15-12-13 04:37, Alan Modra wrote: On Sat, Dec 14, 2013 at 09:14:34PM +0100, Tom de Vries wrote: I wonder if OUTGOING_REG_PARM_STACK_SPACE makes a difference here. If OUTGOING_REG_PARM_STACK_SPACE == 0, it is the responsibility of the callee to allocate the area reserved for arguments passed

Re: question about REG_PARM_STACK_SPACE usage in expand_call

On 12/14/13 13:14, Tom de Vries wrote: I wonder if OUTGOING_REG_PARM_STACK_SPACE makes a difference here. If I'm reading the archives correctly is the caller/callee may have different ABIs (by way of sysv/ms_abi attributes). Presumably there's some magic to deal with the differences in the ABI

Re: Question on patch -fprofile-partial-training

provement. So, without -fprofile-partial-training, the >>> PGO hurt the performance for those cases? >> >> Yes, to get code size improvements we assume that the non-trained part >> of code is cold and with -Os we are very aggressive to optimize for >> siz

Re: Question on patch -fprofile-partial-training

t; (compute_branch_probabilities): For partial profiles do not apply > profile when entry count is zero. > * tree-profile.c (tree_profiling): Only do > value_profile_transformations > when profile is read. > > My question is: Hello. Why would any

Re: Question on patch -fprofile-partial-training

_probabilities): With partial profile >>watch if edge count is zero and turn all probabilities to guessed. >>(compute_branch_probabilities): For partial profiles do not apply >>profile when entry count is zero. >> * tree-profile.c (tree_profil

Re: Question on patch -fprofile-partial-training

ial profiles do not apply >>>profile when entry count is zero. >>>* tree-profile.c (tree_profiling): Only do >>> value_profile_transformations >>>when profile is read. >>> >>> My question is: >> >> Hello. &

Re: Question on patch -fprofile-partial-training

tial profile >>>> watch if edge count is zero and turn all probabilities to guessed. >>>> (compute_branch_probabilities): For partial profiles do not apply >>>> profile when entry count is zero. >>>> * tree-profile.c (tree_profiling): On

Re: Question on patch -fprofile-partial-training

. My question is: Hello. Why would anybody backport such change to unsupported code-stream of GCC 8? Generally speaking, I discourage from doing that. Yes, I agree. However, many users still use GCC8 right now, and some of them are asking for more performance from PGO recently. That’s the

Re: Question on patch -fprofile-partial-training

> > > > > > > > From my understanding, -fprofile-partial-training is one important > > > > option for PGO performance. > > > > > > I don't think so, speed benefit would be rather small I guess. > > I saw some articles online to introduce this option for gcc10, > > https://documentation.suse.com

Re: Question on patch -fprofile-partial-training

Honza, Thanks a lot for your comments. > On May 9, 2023, at 6:22 AM, Jan Hubicka wrote: > > > From my understanding, -fprofile-partial-training is one important option > for PGO performance. I don't think so, speed benefit would be rather small I guess. >>> I saw some

Re: Question on patch -fprofile-partial-training

> Honza, > > Main motivation for this was profiling programs that contain specific > > code paths for different CPUs (such as graphics library in Firefox or Linux > > kernel). In the situation training machine differs from the machine > > program is run later, we end up optimizing for size all code

Re: Question on patch -fprofile-partial-training

that the non-trained part > of code is cold and with -Os we are very aggressive to optimize for > size. We now have two-level optimize_for size, so I think we could > make this more fine grained this stage1. Okay. I see. Thanks a lot for the info. Another question (which is confusi

RFC: lra-constraints.c and TARGET_HARD_REGNO_CALL_PART_CLOBBERED question/patch

I have a reload/register allocation question and possible patch.  While working on the Aarch64 SIMD ABI[1] I ran into a problem where GCC was saving and restoring registers that it did not need to.  I tracked it down to lra-constraints.c and its use of targetm.hard_regno_call_part_clobbered on

Question on adding an option control to libcpp

Hi, in order to fix PR90581: (provide an option to adjust the maximum depth of nested #include) https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90581 we need to add a new option to preprocessor. where should I put this option? I tried to add

RFC: GCC Aarch64 SIMD vectorization question involving libmvec

) ones? This is obviously a question for the pre-SVE vector instructions, I am not sure how this would be handled in SVE. Steve Ellcey sell...@marvell.com P.S. Here a test case in Fortran that generated the 2 element vector call. It unrolled the loop into one vector call of 2 elements

Question on direction of GCC support for HWASAN.

libc so that libhwasan can run its own code. The method of intercepting events has some known difficulties. Also, as one of the LLVM hwasan developers mentioned, this ABI is not being developed any more https://gcc.gnu.org/ml/gcc-patches/2019-09/msg00773.html. --- If this aim is acceptable, th

Re: Ping: question on Multiple level macro expansion

This is not a bug (except in icc, since you said icc accepts the code). gcc-help would have been a better mailing list for this sort of question. -- Joseph S. Myers jos...@codesourcery.com

[AARCH64, Question] Does AARCH64 GCC support long calls?

Hi, I find that the -mlong-calls option is not there for AARCH64. So can this port generate long calls? Any plan on this option? I would like to have a try on this if it's missing :-) Thanks.

Re: Patch ping and question about copyright assignment

On Tue, 6 Jan 2015, Mikhail Maltsev wrote: > Hi, all! > I'm pinging about this patch: > https://gcc.gnu.org/ml/gcc-patches/2014-12/msg01925.html (PR c/48956) > I know that maybe it's too early for sending a ping (less than 2 > weeks), but I also have a question regarding

[PATCH] Re: Vectorizer question: DIV to RSHIFT conversion

On Tue, Dec 13, 2011 at 05:57:40PM +0400, Kirill Yukhin wrote: > > Let me hack up a quick pattern recognizer for this... Here it is, untested so far. On the testcase doing 200 f1+f2+f3+f4 calls in the loop with -O3 -mavx on Sandybridge (so, vectorized just with 16 byte vectors) gives: vanilla

Question on SUBREG simplification for big endian target.

We don't really have a good place for discussions anymore other than gcc-patches, but this really isn't a patch.. Oh well. I'm debugging a failure of ext-dce on a big endian target (m68k) and I can't help but think it's actually exposed a latent bug in subreg handling. Your input would be a

[Ada] Replace a question mark comment with assertion

Cleanup related to loading of compilation units. Tested on x86_64-pc-linux-gnu, committed on trunk gcc/ada/ * lib.adb (Remove_Unit): Replace defensive code with an assertion. * par-load.adb (Load): Address a question mark in the comment.diff --git a/gcc/ada/lib.adb b/gcc

Re: RFC: lra-constraints.c and TARGET_HARD_REGNO_CALL_PART_CLOBBERED question/patch

On 07/11/2018 02:07 PM, Steve Ellcey wrote: > I have a reload/register allocation question and possible patch.  While > working on the Aarch64 SIMD ABI[1] I ran into a problem where GCC was > saving and restoring registers that it did not need to.  I tracked it > down to lra-constrain

  1   2   3   >