Re: [PATCH] Allow different vector types for stmt groups

Hello, On Thu, 14 Oct 2021, Richard Biener via Gcc-patches wrote: > > I have bisected an AMD zen2 10% performance regression of SPEC 2006 FP > > 433.milc bechmark when compiled with -Ofast -march=native -flto to this > > commit. See also: > > > > > >

Re: [PATCH][RFC] Introduce TREE_AOREFWRAP to cache ao_ref in the IL

Hello, On Thu, 14 Oct 2021, Richard Biener wrote: > > So, at _this_ write-through of the email I think I like the above idea > > best: make ao_ref be a tree (at least its storage, because it currently > > is a one-member-function class), make ao_ref.volatile_p be > > tree_base.volatile_flag

Re: environment register / ABI

Hello, On Wed, 13 Oct 2021, Martin Uecker wrote: > > [... static chain ...] > > If you mean that, then it's indeed psABI specific, and possibly not > > al ABIs specify it (in which case GCC will probably have set a de- > > facto standard at least for unixy systems).  The x86-64 psABI for > >

Re: environment register / ABI

Hello, On Wed, 13 Oct 2021, Martin Uecker wrote: > does anybody know if all architectures support passing > an environment pointer in their function call ABI? Define "environment pointer". I can imagine two things you could mean: the custom to pass envp as third argument to main() in hosted

Re: [PATCH][RFC] Introduce TREE_AOREFWRAP to cache ao_ref in the IL

Hello, [this is the fourth attempt to write a comment/review/opinion for this ao_ref-in-tcc_reference, please accept some possible incoherence] On Tue, 12 Oct 2021, Richard Biener via Gcc-patches wrote: > This prototype hack introduces a new tcc_reference TREE_AOREFWRAP > which we can use to

Re: [PATCH] tree-optimization: [PR102622]: wrong code due to signed one bit integer and "a?-1:0"

Hello, On Sat, 9 Oct 2021, apinski--- via Gcc-patches wrote: > + (lshift (convert (convert:boolean_type_node @0)) { shift; }))) > +/* a ? -1 : 0 -> -a. No need to check the TYPE_PRECISION not being 1 > + here as the powerof2cst case above will handle that case correctly. > */

Re: [RFC] More jump threading restrictions in the presence of loops.

Hello, On Tue, 5 Oct 2021, Richard Biener wrote: > > First notice that this doesn't have an empty latch block to start with > > (in fact, there is no separate latch block at all), so the loop > > optimizers haven't been initialized for simple latches at this point. > > Still, I would say

Re: [RFC] More jump threading restrictions in the presence of loops.

Hello, On Mon, 4 Oct 2021, Jeff Law wrote: > And just in case it got lost.  Here's the analysis on 960218-1 on visium: > > We've got this going into ethread: > > int f (int x) > { >   int D.1420; >   int a; > > ;;   basic block 2, loop depth 0, maybe hot > ;;    prev block 0, next block 3,

Re: S390 should change the meaning of -m31

Hello, On Wed, 29 Sep 2021, Jesus Antonio via Gcc wrote: > m31 is semantically the same as the m32 option. > > > The m31 option allows for 32 bit addressing and that is confusing since > the m31 option in S390 would mean 2 GiB space addressing Indeed that's exactly what it means, and what

Re: [PATCH] middle-end/102360 - adjust .DEFERRED_INIT expansion

Hello, On Thu, 16 Sep 2021, Richard Biener via Gcc-patches wrote: > > Typically for the native_interpret/native_encode we punt if > > BITS_PER_UNIT != 8 || CHAR_BIT != 8 because nobody had the energy to > > deal with the weird platforms (especially if we have currently none, I > > believe

Re: Regression with recent change

Hello, On Mon, 13 Sep 2021, Aldy Hernandez via Gcc-patches wrote: The testcase still tests what it's supposed to test with ... > > typedef unsigned short uint16_t; > > > > uint16_t a, b; > > > > int *j_global; > > uint16_t f(void) > > { > >int c, **p; > >short d = 2, e = 4; > > ... "c

Re: Regression with recent change

Hello, On Mon, 13 Sep 2021, Jeff Law via Gcc-patches wrote: > > So it looks like there's some undefined behavior going on, even before > > my patch. I'd like to get some feedback, because this is usually the > > type of problems I see in the presence of a smarter threader... things > > get

Re: [PATCH] Always default to DWARF2_DEBUG if not specified, warn about deprecated STABS

Hello, On Fri, 10 Sep 2021, Richard Biener via Gcc-patches wrote: > diagnostic from the Ada frontend. The warnings are pruned from the > testsuite output via prune_gcc_output but somehow this doesn't work > for the tests in gfortran.dg/debug which are now failing with excess > errors. That

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

Hello, On Fri, 10 Sep 2021, Aldy Hernandez via Gcc-patches wrote: > Like this? Yep, but I can't approve. Ciao, Michael.

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

Hi, On Fri, 10 Sep 2021, Aldy Hernandez via Gcc-patches wrote: > } > + > + /* Threading through a non-empty latch would cause code to be added "through an *empty* latch". The test in code is correct, though. And for the before/after loops flag you added: we have a cfun->curr_properties

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

Hello, On Thu, 9 Sep 2021, Aldy Hernandez wrote: > > Here there's no simple latch block to start with (the backedge comes > > directly out of the loop exit block). So my suggested improvement > > (testing if the latch was empty and only then reject the thread), would > > solve this. > > Well,

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

Hello, On Thu, 9 Sep 2021, Aldy Hernandez wrote: > The ldist-22 regression is interesting though: > > void foo () > { > int i; > >: > goto ; [INV] > >: > a[i_1] = 0; > if (i_1 > 100) > goto ; [INV] > else > goto ; [INV] > >: > b[i_1] = i_1; > >: > i_8 =

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

Hello, On Thu, 9 Sep 2021, Richard Biener wrote: > > I believe something like below would be appropriate, it disables > > threading if the path contains a latch at the non-last position (due > > to being backwards on the non-first position in the array). I.e. it > > disables rotating the

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

Hello, [lame answer to self] On Wed, 8 Sep 2021, Michael Matz wrote: > > > The forward threader guards against this by simply disallowing > > > threadings that involve different loops. As I see > > > > The thread in question (5->9->3) is all within t

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

Hello, On Wed, 8 Sep 2021, Aldy Hernandez wrote: > > The forward threader guards against this by simply disallowing > > threadings that involve different loops. As I see > > The thread in question (5->9->3) is all within the same outer loop, > though. BTW, the backward threader also

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

Hello, On Tue, 7 Sep 2021, Aldy Hernandez via Gcc wrote: > The regression comes from the simple_reduc_1() function in > tree-ssa/loop-interchange-9.c, and it involves the following path: > > === BB 5 > Imports: n_10(D) j_19 > Exports: n_10(D) j_13 j_19 > j_13 :

Re: post-commit hook failure

Hello, On Wed, 25 Aug 2021, Martin Liška wrote: > > remote: File "hooks/post_receive.py", line 47, in post_receive_one > > remote: update.send_email_notifications() > > remote: File > > "/sourceware1/projects/src-home/git-hooks/hooks/updates/__init__.py", ... > > remote:

Re: [Patch] gfortran: Fix in-build-tree testing [PR101305, PR101660]

Hello, On Tue, 10 Aug 2021, Jakub Jelinek via Gcc-patches wrote: > > +# Place ISO_Fortran_binding.h also under include/ in the build directory > > such > > +# that it can be used for in-built-tree testsuite runs without > > interference of > > +# other files in the build dir - like intrinsic

Re: Suboptimal code generated for __buitlin_trunc on AMD64 without SS4_4.1

Hello, On Fri, 6 Aug 2021, Stefan Kanthak wrote: > >> For -ffast-math, where the sign of -0.0 is not handled and the > >> spurios invalid floating-point exception for |argument| >= 2**63 is > >> acceptable, > > > > This claim would need to be proven in the wild. > > I should have left the

Re: Suboptimal code generated for __buitlin_trunc on AMD64 without SS4_4.1

Hello, On Fri, 6 Aug 2021, Stefan Kanthak wrote: > For -ffast-math, where the sign of -0.0 is not handled and the spurios > invalid floating-point exception for |argument| >= 2**63 is acceptable, This claim would need to be proven in the wild. |argument| > 2**52 are already integer, and

Re: Optional machine prefix for programs in for -B dirs, match ing Clang

Hello, On Wed, 4 Aug 2021, John Ericson wrote: > On Wed, Aug 4, 2021, at 10:48 AM, Michael Matz wrote: > > ... the 'as' and 'ld' executables should be simply found within the > > version and target specific GCC libexecsubdir, possibly by being symlinks > > to whate

Re: Re: Optional machine prefix for programs in for -B dirs, match ing Clang

Hello, On Wed, 4 Aug 2021, John Ericson wrote: > > Doesn't GCC automatically look for those commands in the --prefix > > directory that you configure GCC with? Or is that only for native > > compilers? > > It will search only if --with-*=... was not passed, and it will never > prefix the

Re: Disabling TLS address caching to help QEMU on GNU/Linux

Hello, On Thu, 22 Jul 2021, Richard Biener via Gcc wrote: > But how does TLS usage transfer between threads? On the gimple level > the TLS pointer is not visible and thus we'd happily CSE its address: Yes. All take-address operations then need to be encoded explicitely with a non-CSE-able

Re: HELP!! How to inhibit optimizations applied to .DEFERRED_INIT argument?

Hello, On Thu, 1 Jul 2021, Richard Sandiford wrote: > Well, it does feel like this is pressing the reset button on a thread > whose message count is already in the high double figures. There's a > risk that restarting the discussion now is going to repeat a lot of the > same ground, probably at

Re: [PATCH] Port GCC documentation to Sphinx

Hello, On Thu, 1 Jul 2021, Martin Liška wrote: > On 7/1/21 3:33 PM, Eli Zaretskii wrote: > > > Cc: jos...@codesourcery.com, gcc@gcc.gnu.org, gcc-patc...@gcc.gnu.org > > > From: Martin Liška > > > Date: Thu, 1 Jul 2021 14:44:10 +0200 > > > > > > > It helps some, but not all of the issues

Re: [PATCH] Port GCC documentation to Sphinx

Hello, On Thu, 1 Jul 2021, Martin Liška wrote: > On 7/1/21 3:33 PM, Eli Zaretskii wrote: > > > Cc: jos...@codesourcery.com, g...@gcc.gnu.org, gcc-patches@gcc.gnu.org > > > From: Martin Liška > > > Date: Thu, 1 Jul 2021 14:44:10 +0200 > > > > > > > It helps some, but not all of the issues

Re: [PATCH] tree-optimization/101280 - revise interchange fix for PR101173

Hello, On Thu, 1 Jul 2021, Richard Biener wrote: > diff --git a/gcc/gimple-loop-interchange.cc b/gcc/gimple-loop-interchange.cc > index 43045c5455e..43ef112a2d0 100644 > --- a/gcc/gimple-loop-interchange.cc > +++ b/gcc/gimple-loop-interchange.cc > @@ -1043,8 +1043,11 @@

Re: HELP!! How to inhibit optimizations applied to .DEFERRED_INIT argument?

Hello, I haven't followed this thread too closely, in particular I haven't seen why the current form of the .DEFERRED_INIT call was chosen or suggested, but it triggered my "well, that's obviously wrong" gut feeling; so sorry for stating something which might be obvious to thread participants

Re: [llvm-dev] RFC: Add GNU_PROPERTY_UINT32_AND_XXX/GNU_PROPERTY_UINT32_OR_XXX

Hello, On Tue, 22 Jun 2021, H.J. Lu wrote: > > > The issue is that libfoo.so used in link-time can be different from > > > libfoo.so at run-time. The symbol, foobar, in libfoo.so at link-time > > > has the default visibility. But foobar in libfoo.so at run-time can be > > > protected. ld.so

Re: [llvm-dev] RFC: Add GNU_PROPERTY_UINT32_AND_XXX/GNU_PROPERTY_UINT32_OR_XXX

t; > gold and ld.lld just emit an error unconditionally. I think non-x86 > > GNU ld ports which never support "copy relocations on protected data > > symbols" may want to make the diagnostic unconditional as well. > > Well, while (Michael Matz and ) I think compatibility check fo

Re: git gcc-commit-mklog doesn't extract PR number to ChangeLog

Hello, On Thu, 17 Jun 2021, Martin Sebor via Gcc wrote: > > The original problem is that the PR wasn't _in the body_ of the commit > > But I see [PR100085] right there at the end of the _summary line_: Emphasis mine. Ciao, Michael.

Re: Aligning stack offsets for spills

Hello, On Tue, 8 Jun 2021, Jeff Law wrote: > On 6/8/2021 9:06 AM, H.J. Lu wrote: > > On Tue, Jun 8, 2021 at 7:56 AM Jakub Jelinek via Gcc-patches > > wrote: > >> On Tue, Jun 08, 2021 at 08:47:26AM -0600, Jeff Law wrote: > Why is the machinery involving STACK_SLOT_ALIGNMENT and >

Re: Aligning stack offsets for spills

Hello, On Mon, 7 Jun 2021, Jeff Law wrote: > > So, as many of you know I left Red Hat a while ago and joined Tachyum.  We're > building a new processor and we've come across an issue where I think we need > upstream discussion. > > I can't divulge many of the details right now, but one of the

Re: GCC documentation: porting to Sphinx

Hello, On Tue, 1 Jun 2021, Martin Liška wrote: > On 5/31/21 5:49 PM, Michael Matz wrote: > > Hello Martin, > > > > On Mon, 31 May 2021, Martin Liška wrote: > > > >> I've made quite some progress with the porting of the documentation and > >> I

Re: GCC documentation: porting to Sphinx

Hello, On Tue, 1 Jun 2021, Martin Liška wrote: > On 5/31/21 5:49 PM, Michael Matz wrote: > > Hello Martin, > > > > On Mon, 31 May 2021, Martin Liška wrote: > > > >> I've made quite some progress with the porting of the documentation and > >> I

Re: GCC documentation: porting to Sphinx

Hello Martin, On Mon, 31 May 2021, Martin Liška wrote: > I've made quite some progress with the porting of the documentation and > I would like to present it to the community now: > https://splichal.eu/scripts/sphinx/ > > Note the documentation is automatically ([1]) generated from texinfo

Re: GCC documentation: porting to Sphinx

Hello Martin, On Mon, 31 May 2021, Martin Liška wrote: > I've made quite some progress with the porting of the documentation and > I would like to present it to the community now: > https://splichal.eu/scripts/sphinx/ > > Note the documentation is automatically ([1]) generated from texinfo

Re: [PATCH] Generate gimple-match.c and generic-match.c earlier

Hello, On Fri, 28 May 2021, Bernd Edlinger wrote: > >> I was wondering, why gimple-match.c and generic-match.c > >> are not built early but always last, which slows down parallel > >> makes significantly. > >> > >> The reason seems to be that generated_files does not > >> mention gimple-match.c

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

Hello, On Thu, 6 May 2021, Prathamesh Kulkarni via Gcc wrote: > Well, I was thinking of this test-case: > > int f(int cond1, int cond2, int cond3, int x, int y) > { > void f1(); > void f2(int); > void f3(); > > if (cond1) > f1 (); > else > { > if (cond2) > f2 (x

Re: [PATCH] Avoid DSE/DCE of pure call that throws

Hello, On Mon, 3 May 2021, Jan Hubicka wrote: > > (it should not abort). The documentation of 'pure' must be read > > as that 'pure' is not valid for 'foo' since throwing an exception > > is obviously an observable effect on the state of the program > > (in particular for the testcase at hand).

Re: RFC: Sphinx for GCC documentation

Hello, On Wed, 7 Apr 2021, Martin Liška wrote: > > I like the output quite a bit, especially that things like option > > references are automagically linked to their documentation.  I spent > > just a bit of time looking through the HTML and PDF above and found > > a few minor issues.  I suspect

Re: 'walk_stmt_load_store_addr_ops' for non-'gimple_assign_single_p (stmt)'

Hello, On Wed, 17 Mar 2021, Richard Biener wrote: > > The walk_gimple functions are intended to be used on the SSA form of > > gimple (i.e. the one that it is in most of the time). > > Actually they are fine to use pre-SSA. Structurally, sure. > They just even pre-SSA distinguish between

Re: 'walk_stmt_load_store_addr_ops' for non-'gimple_assign_single_p (stmt)'

Hello, On Tue, 16 Mar 2021, Thomas Schwinge wrote: > >>Indeed, given (Fortran) 'zzz = 1', we produce GIMPLE: > >> > >>gimple_assign > >> > >>..., and calling 'walk_stmt_load_store_addr_ops' on that, I see, as > >>expected, the 'visit_store' callback invoked, with 'rhs' and 'arg': > >>''. >

RE: [EXTERNAL] Re: DWARF Debug Info Relocations (.debug_str STRP references)

Hello, On Tue, 1 Dec 2020, Bill Messmer via Gcc wrote: > Thank you very much for the help. I was so fixated on the fact that the > .rela.debug* sections were there that I didn't pay attention to the > e_type in the ELF header. Apparently, neither did the library that I > was using to parse

Re: [00/23] Make fwprop use an on-the-side RTL SSA representation

Hello, On Mon, 30 Nov 2020, Jeff Law wrote: > >> So, then let's start with one of > >> the prime examples of SSA deconstruction problems, the lost swap, and how > >> it comes to be: we start with a swap: > >> > >> x = ..., y = ... > >> if (cond) > >> tmp=x, x=y, y=tmp > >> > >> (1)

Re: [RFC] Increase libstdc++ line length to 100(?) columns

Hello, On Mon, 30 Nov 2020, Allan Sandfeld Jensen wrote: > > > On Sonntag, 29. November 2020 18:38:15 CET Florian Weimer wrote: > > > > * Allan Sandfeld Jensen: > > > > > If you _do_ change it. I would suggest changing it to 120, which is > > > > > next > > > > > common step for a lot of C++

Re: [RFC] Increase libstdc++ line length to 100(?) columns

Hello, On Sun, 29 Nov 2020, Allan Sandfeld Jensen wrote: > On Sonntag, 29. November 2020 18:38:15 CET Florian Weimer wrote: > > * Allan Sandfeld Jensen: > > > If you _do_ change it. I would suggest changing it to 120, which is next > > > common step for a lot of C++ projects. > > > > 120 can be

Re: [00/23] Make fwprop use an on-the-side RTL SSA representation

Hello, On Thu, 26 Nov 2020, Richard Sandiford via Gcc-patches wrote: > >> The aim is only to provide a different view of existing RTL instructions. > >> Unlike gimple, and unlike (IIRC) the old RTL SSA project from way back, > >> the new framework isn't a “native” SSA representation. This means

Re: [libgcc2.c] Implementation of __bswapsi2()

Hello, On Thu, 12 Nov 2020, Stefan Kanthak wrote: > Does GCC generate (unoptimised) code there, similar to the following i386 > assembly, using 4 loads, 4 shifts, 2 ands plus 3 ors? Try for yourself. '-m32 -O2 -march=i386' is your friend. Ciao, Michael. Spoiler: it's generating:

Re: [PATCH] Canonicalize real X - CST to X + -CST

Hello, On Wed, 16 Sep 2020, Richard Biener wrote: > This removes the canonicalization of X + -CST to X - CST to facilitate > SLP vectorization analysis where we currently treat the added testcase > as two-operation plus blend vectorization opportunity. While there > may be the possibility to

Re: [PATCH] tree-optimization/96043 - BB vectorization costing improvement

Hello, On Tue, 8 Sep 2020, Richard Biener wrote: > CCing some people to double-check my graph partitioning algorithm. I seem to not know the pre-existing data structures enough to say anything about this, but I noticed small things which might or might not indicate thinkos or incompleteness:

Re: Problems with changing the type of an ssa name

Hello, On Sat, 25 Jul 2020, Gary Oblock via Gcc wrote: > if ( TYPE_P ( type) ) > { >TREE_TYPE ( ssa_name) = TYPE_MAIN_VARIANT ( type); >if ( ssa_defined_default_def_p ( ssa_name) ) > { > // I guessing which I know is a terrible thing to do... >

RE: New x86-64 micro-architecture levels

Hello, On Wed, 22 Jul 2020, Mallappa, Premachandra wrote: > > That's deliberate, so that we can use the same x86-* names for 32-bit > > library selection (once we define matching micro-architecture levels there). > > Understood. > > > If numbers are out, what should we use instead? > >

Re: New mklog script

Hello, On Tue, 19 May 2020, Jakub Jelinek wrote: > On Tue, May 19, 2020 at 05:21:16PM +0100, Richard Earnshaw wrote: > > This is really a wart in the GNU coding style. And one reason why I > > tend to indent such labels by a single space. It particularly affects > > things like class

Re: New mklog script

Hello, On Tue, 19 May 2020, Jakub Jelinek wrote: > On Tue, May 19, 2020 at 05:21:16PM +0100, Richard Earnshaw wrote: > > This is really a wart in the GNU coding style. And one reason why I > > tend to indent such labels by a single space. It particularly affects > > things like class

Re: New mklog script

Hello, On Tue, 19 May 2020, Martin Liška wrote: > > The common problems I remember is that e.g. when changing a function comment > > above some function, it is attributed to the previous function rather than > > following, labels in function confusing it: > > void > > foo () > > { > >

Re: New mklog script

Hello, On Tue, 19 May 2020, Martin Liška wrote: > > The common problems I remember is that e.g. when changing a function comment > > above some function, it is attributed to the previous function rather than > > following, labels in function confusing it: > > void > > foo () > > { > >

Re: [PATCH] Implement no_stack_protect attribute.

Hello, On Mon, 18 May 2020, Florian Weimer wrote: > * Michael Matz: > > >> So does -fcf-protection. -fno-omit-frame-pointer does not work for me at > >> all for some reason, the frame pointer is always missing? > > > > Not for me: > > I see. I did

Re: [PATCH] Implement no_stack_protect attribute.

Hello, On Mon, 18 May 2020, Florian Weimer wrote: > >> In glibc, we already have this: > >> > >> /* Used to disable stack protection in sensitive places, like ifunc > >>resolvers and early static TLS init. */ > >> #ifdef HAVE_CC_NO_STACK_PROTECTOR > >> # define inhibit_stack_protector \ >

Re: [PATCH] Implement no_stack_protect attribute.

Hello, On Mon, 18 May 2020, Florian Weimer via Gcc-patches wrote: > > The patch adds new no_stack_protect attribute. The change is requested > > from kernel folks and is direct equivalent of Clang's no_stack_protector. > > Unlike Clang, I chose to name it no_stack_protect because we already > >

Re: Should ARMv8-A generic tuning default to -moutline-atomics

Hello, On Wed, 29 Apr 2020, Florian Weimer via Gcc wrote: > Distributions are receiving requests to build things with > -moutline-atomics: > > > > Should this be reflected in the GCC upstream defaults for ARMv8-A > generic tuning?

Re: GCC optimizations with O3

Hello, On Wed, 22 Apr 2020, Erick Ochoa wrote: > in order for me to debug my issue, I'm going to have to refactor passes > which directly reference optimize. For debugging you can also work backwards: use -O3 and add -fno-xy options. At least you then know (after disabling all O3 passes)

Re: Not usable email content encoding

Hello, On Mon, 13 Apr 2020, Christopher Faylor wrote: > On Wed, Apr 08, 2020 at 04:15:27PM -0500, Segher Boessenkool wrote: > >On Wed, Apr 08, 2020 at 01:50:51PM +, Michael Matz wrote: > >>On Wed, 8 Apr 2020, Mark Wielaard wrote: > >>>Earlier versions of Mainma

Re: Not usable email content encoding

Hello, On Wed, 8 Apr 2020, Mark Wielaard wrote: > On Tue, 2020-04-07 at 11:53 +0200, Florian Weimer via Overseers wrote: > > Gmail can drop mail for any reason. It's totally opaque, so it's a > > poor benchmark for any mailing list configuration changes because it's > > very hard to tell if a

Re: Not usable email content encoding

Hello, On Tue, 7 Apr 2020, Frank Ch. Eigler wrote: > > I find that unconvincing, because even googlegroup email lists don't > > mangle From: from sender domains that are now mangled by sourceware.org > > :-/ > > It turns out receiving mail FROM google-groups mail is itself > sometimes at risk

Re: Not usable email content encoding

Hello, On Tue, 7 Apr 2020, Jonathan Wakely via Gcc wrote: > On Mon, 6 Apr 2020 at 23:00, Maciej W. Rozycki via Gcc > wrote: > > And can certainly score a positive though not a definite rating in spam > > qualification. I don't think we ought to encourage bad IT management > > practices by

Re: Question about undefined functions' parameters during LTO

Hello, On Tue, 7 Apr 2020, Erick Ochoa wrote: > > So, when you want to compare types use useless_type_conversion_p (for > > equivalence you need useless(a,b) && useless(b,a)). In particular, > > for record types T it's TYPE_CANONICAL(T) that needs to be > > pointer-equal. (I.e. you could

Re: Question about undefined functions' parameters during LTO

Hello, On Tue, 7 Apr 2020, Erick Ochoa wrote: > Thanks for this lead! It is almost exactly what I need. I do have one more > question about this. It seems that the types obtained via > FOR_EACH_FUNCTION_ARGS and TREE_TYPE are different pointers when compiled with > -flto. > > What do I mean by

Re: [RFC] Fix for pr64706 testcase faulre

Hello, On Thu, 26 Mar 2020, Jan Hubicka wrote: > > I think we should continue to try to model ELF semantics re weak and > > aliases. If so, then yes, LTO gets it wrong and the above testcase should > > not abort. Weak doesn't enter the picture for creating aliases (the > > aliases is

Re: [RFC] Fix for pr64706 testcase faulre

Hello, On Thu, 26 Mar 2020, Richard Biener wrote: > > = b.c: > > > > __attribute__((weak)) > > __attribute__((noinline)) > > > > int a() > > { > > return 1; > > } > > > > __attribute__((noinline)) > > static int b() __attribute__((alias("a"))); > > void > > test() > > { > > if

Re: [PATCH v2] generate EH info for volatile asm statements (PR93981)

Hello, On Thu, 19 Mar 2020, J.W. Jagersma via Gcc-patches wrote: > I just realized that changing all outputs to in+out would generate > worse code for *every* single asm that has any outputs. Under -fnon-call-exception only. And I'm not sure what you mean, the only effect of the additional

Re: [PATCH v2] generate EH info for volatile asm statements (PR93981)

Hello, On Wed, 18 Mar 2020, J.W. Jagersma via Gcc-patches wrote: > > Well, it's both: on the exception path the compiler has to assume that the > > the value wasn't changed (so that former defines are regarded as dead) or > > that it already has changed (so that the effects the throwing > >

Re: [PATCH v2] generate EH info for volatile asm statements (PR93981)

Hello, On Wed, 18 Mar 2020, Segher Boessenkool wrote: > > > Similarly for non-call exceptions on other statements. It sounds like > > > what you're describing requires the corresponding definition to happen > > > for memory outputs regardless of whether the asm throws or not, so that > > >

Re: Not usable email content encoding

Hello, On Wed, 18 Mar 2020, Frank Ch. Eigler via Gcc wrote: > > > The From: header rewriting for DMARC participants is something sourceware > > > is doing now. > > > > Out of curiousity, is this rewriting you are talking about the cause for a > > lot of mails showing up as "From: GCC List"

Re: Not usable email content encoding

Hi, On Wed, 18 Mar 2020, Frank Ch. Eigler via Gcc wrote: > > > The key here is to realize that the raw message is not what you get > > > back from the mailing list reflector, and also not the raw message > > > that was sent by the sender. In this day of mta intermediaries, > > > proxies,

Re: [PATCH v2] generate EH info for volatile asm statements (PR93981)

Hello, On Mon, 16 Mar 2020, Richard Sandiford wrote: > Segher Boessenkool writes: > > On Mon, Mar 16, 2020 at 05:47:03PM +, Richard Sandiford wrote: > >> Segher Boessenkool writes: > >> >> we do delete "x = 1" for f1. I think that's the expected behaviour. > >> >> We don't yet delete the

Re: Question about undefined functions' parameters during LTO

Hello, On Fri, 13 Mar 2020, Erick Ochoa wrote: > +for (tree parm = DECL_ARGUMENTS (undefined_function->decl); parm; parm = > DECL_CHAIN (parm)) > + { > + tree type = TREE_TYPE(parm); > + if (dump_file) fprintf(dump_file, "I want the type, do I have it? > %s\n", type ? "true"

Re: [PATCH][RFC] API extension for binutils (type of symbols).

Hello, On Tue, 10 Mar 2020, Martin Liška wrote: > >>> We nee to support different variables, like TLS, data and bss variables. > >> > >> Why do we need TLS? Right now, it's not supported by nm. > > > > Of course it does. It's the 'T' (or 't') character. > > Thank you reply! > > Are you sure

Re: [PATCH][RFC] API extension for binutils (type of symbols).

Hello, On Mon, 9 Mar 2020, Martin Liška wrote: > On 3/9/20 4:36 PM, H.J. Lu wrote: > > We nee to support different variables, like TLS, data and bss variables. > > Why do we need TLS? Right now, it's not supported by nm. Of course it does. It's the 'T' (or 't') character. When you introduce

Re: [PATCH, v3] wwwdocs: e-mail subject lines for contributions

Hello, On Mon, 3 Feb 2020, Richard Earnshaw (lists) wrote: > Well, I'd review a patch differently depending on whether or not it was > already committed, a patch requiring review or an RFC looking for more > general comments, so I *do* think such an email prefix is useful. As I said: a very

Re: [PATCH, v3] wwwdocs: e-mail subject lines for contributions

Hello, On Mon, 3 Feb 2020, Richard Earnshaw (lists) wrote: > Well, I'd review a patch differently depending on whether or not it was > already committed, a patch requiring review or an RFC looking for more > general comments, so I *do* think such an email prefix is useful. As I said: a very

Re: [PATCH, v3] wwwdocs: e-mail subject lines for contributions

Hello, On Mon, 3 Feb 2020, Jakub Jelinek wrote: > > > The idea is that the [...] part is NOT part of the commit, only part of > > > the email. > > > > I understand that, but the subject line of this thread says "e-mail > > subject lines", so I thought we were talking about, well, exactly

Re: [PATCH, v3] wwwdocs: e-mail subject lines for contributions

Hello, On Mon, 3 Feb 2020, Jakub Jelinek wrote: > > > The idea is that the [...] part is NOT part of the commit, only part of > > > the email. > > > > I understand that, but the subject line of this thread says "e-mail > > subject lines", so I thought we were talking about, well, exactly

Re: [PATCH, v3] wwwdocs: e-mail subject lines for contributions

Hi, On Mon, 3 Feb 2020, Richard Earnshaw (lists) wrote: > The idea is that the [...] part is NOT part of the commit, only part of > the email. I understand that, but the subject line of this thread says "e-mail subject lines", so I thought we were talking about, well, exactly that; and I see

Re: [PATCH, v3] wwwdocs: e-mail subject lines for contributions

Hi, On Mon, 3 Feb 2020, Richard Earnshaw (lists) wrote: > The idea is that the [...] part is NOT part of the commit, only part of > the email. I understand that, but the subject line of this thread says "e-mail subject lines", so I thought we were talking about, well, exactly that; and I see

Re: [PATCH, v3] wwwdocs: e-mail subject lines for contributions

Hello, On Mon, 3 Feb 2020, Richard Earnshaw (lists) wrote: > Where does your '50 chars' limit come from? It's not in the glibc text, > and it's not in the linux kernel text either. AFAICT this is your > invention and you seem to be the only person proposing it. Nope, it's fairly common, so

Re: [PATCH, v3] wwwdocs: e-mail subject lines for contributions

Hello, On Mon, 3 Feb 2020, Richard Earnshaw (lists) wrote: > Where does your '50 chars' limit come from? It's not in the glibc text, > and it's not in the linux kernel text either. AFAICT this is your > invention and you seem to be the only person proposing it. Nope, it's fairly common, so

Re: [PATCH] doc: clarify the situation with pointer arithmetic

Hi, On Thu, 30 Jan 2020, Michael Matz wrote: > > and the pointers have the same address, then it would evaluate to true > > at run-time. If I understand correctly, you somehow want to make this > > case be UB, but I haven't quite understood how (if it is not t

Re: [PATCH] doc: clarify the situation with pointer arithmetic

Hi, On Thu, 30 Jan 2020, Uecker, Martin wrote: > > guarantees face serious implementation difficulties I think > > so the only alternative to PVNI (which I think is implementable > > but at a optimization opportunity cost) is one that makes > > two pointers with the same value always have the

Re: [PATCH] Come up with constructors of symtab_node, cgraph_node and varpool_node.

Hi, On Thu, 5 Dec 2019, Richard Biener wrote: > >> Indeed - please adjust that as well. > > > >Explicit ctors are a c++11+ feature. > > Surely not. Whoops, I was conflating ctors and conversion functions, the latter can be explicit only in c++11+. Ciao, Michael.

Re: [RFC] Characters per line: from punch card (80) to line printer (132) (was: [Patch][OpenMP/OpenACC/Fortran] Fix mapping of optional (present|absent) arguments)

Hello, (oh a flame bait :) ) On Thu, 5 Dec 2019, Thomas Schwinge wrote: > So, I formally propose that we lift this characters per line restriction > from IBM punch card (80) to mainframe line printer (132). > > Tasks: > > - Discussion. I object to cluttering code in excuse for using

Re: [RFC] Characters per line: from punch card (80) to line printer (132) (was: [Patch][OpenMP/OpenACC/Fortran] Fix mapping of optional (present|absent) arguments)

Hello, (oh a flame bait :) ) On Thu, 5 Dec 2019, Thomas Schwinge wrote: > So, I formally propose that we lift this characters per line restriction > from IBM punch card (80) to mainframe line printer (132). > > Tasks: > > - Discussion. I object to cluttering code in excuse for using

Re: [PATCH] Come up with constructors of symtab_node, cgraph_node and varpool_node.

Hi, On Thu, 5 Dec 2019, Richard Biener wrote: > On December 5, 2019 3:35:17 PM GMT+01:00, Tom Tromey wrote: > >> "Martin" == Martin Liška writes: > > > >Martin> + /* Default constructor. */ > >Martin> + symtab_node (symtab_type t) > > > >FWIW, in gdb, we normally make single-argument

Re: [PATCH] Add if-chain to switch conversion pass.

Hi, On Wed, 13 Nov 2019, Martin Liška wrote: > > Not a review, just a few questions: > > Hello. > > Thank you for it. > > > > > 1) what does it do if __builtin_expect* has been used, does it preserve > > the probabilities and if in the end decides to expand as ifs, are those > >

Re: Fix PR90796

Hello, On Mon, 28 Oct 2019, Rainer Orth wrote: > >> > +FAIL: gcc.dg/unroll-and-jam.c scan-tree-dump-times unrolljam "applying > >> > unroll and jam" 6 > >> > >> Hrmpf, I'll have a look :-/ Thanks for noticing. > > > > A strange interaction with LIM, which only does something on 32bit, but > >

<    1   2   3   4   5   6   7   8   9   10   >