On Wed, Mar 31, 2021 at 1:36 PM Mark Wielaard wrote:
>
> You are referencing the recent open letter which isn't really what
> people are discussing here. Although many probably sympathize with
> calling for the removal of the entire Board of the Free Software
> Foundation and calling for Richard M
On Wed, Mar 31, 2021 at 2:59 PM David Edelsohn wrote:
>
> On Wed, Mar 31, 2021 at 8:28 AM Richard Biener via Gcc
> wrote:
> >
> > On Wed, Mar 31, 2021 at 1:36 PM Mark Wielaard wrote:
> > >
> > > You are referencing the recent open letter which isn't
On March 31, 2021 5:23:09 PM GMT+02:00, David Edelsohn
wrote:
>On Wed, Mar 31, 2021 at 9:46 AM Florian Weimer
>wrote:
>>
>> * David Edelsohn via Gcc:
>>
>> > Has the GCC SC blocked any new port or major feature? Not that I'm
>aware of.
>>
>> What about the plugin framework? The libgcc licensin
On Thu, Apr 1, 2021 at 2:50 PM Erick Ochoa via Gcc wrote:
>
> Hi,
>
> just a high level question. I know that IPA-PTA is a SIMPLE_IPA_PASS
> and that ideally it would be better as an IPA_PASS. I understand that
> one of the biggest challenges of changing IPA-PTA to an IPA_PASS is
> that on the cur
On April 1, 2021 3:52:37 PM GMT+02:00, Erick Ochoa wrote:
>>
>> I don't think this would remove any problem that is present.
>>
>
>I have a problem understanding what you mean here because later on you
>state:
>
>> Now - the reason you think of is likely that IPA transform will
>instantiate
>> IPA
On April 1, 2021 5:23:25 PM GMT+02:00, "Andrea G. Monaco"
wrote:
>
>I strongly disagree with the removal of Dr. Stallman from the Steering
>Committee.
>
>Not only RMS wrote the GCC initially, but I think he is the best person
>by far who can guarantee the values of free software, with unmatched
>
On April 1, 2021 9:49:19 PM GMT+02:00, Jonathan Wakely via Gcc
wrote:
>On Thu, 1 Apr 2021 at 20:23, Iain Sandoe wrote:
>>
>> Richard Biener wrote:
>>
>> > On April 1, 2021 4:08:21 PM GMT+02:00, Eric Botcazou
>> > wrote:
>> >>> I have so far bootstrapped and tested the release candidate on
>> >>
On Thu, Apr 1, 2021 at 9:21 PM Ian Lance Taylor via Gcc wrote:
>
> On Thu, Apr 1, 2021 at 10:08 AM Nathan Sidwell wrote:
> >
> > Richard Biener pointed out dysfunction in the SC. The case of the
> > missing question I asked in 2019 also points to that. This response
> > gives me no confidence t
On Mon, Apr 5, 2021 at 10:56 PM Simon Marchi via Gcc wrote:
>
> On 2021-04-05 3:36 p.m., Jim Wilson wrote:> On Sat, Apr 3, 2021 at 6:24 PM
> Simon Marchi via Gcc mailto:gcc@gcc.gnu.org>> wrote:
> >
> > The default debug format (when using only -g) for the AVR target is
> > stabs. Is ther
On April 8, 2021 1:17:53 AM GMT+02:00, David Edelsohn wrote:
>On Tue, Apr 6, 2021 at 6:34 AM Richard Biener via Gcc
>wrote:
>>
>> On Mon, Apr 5, 2021 at 10:56 PM Simon Marchi via Gcc
> wrote:
>> >
>> > On 2021-04-05 3:36 p.m., Jim Wilson wrote:> On Sat
On Thu, Apr 8, 2021 at 8:03 AM Richard Biener
wrote:
>
> On April 8, 2021 1:17:53 AM GMT+02:00, David Edelsohn
> wrote:
> >On Tue, Apr 6, 2021 at 6:34 AM Richard Biener via Gcc
> >wrote:
> >>
> >> On Mon, Apr 5, 2021 at 10:56 PM Simon Marchi via Gcc
>
On Sun, Apr 11, 2021 at 7:22 PM Jonathan Wakely via Gcc wrote:
>
> On Sun, 11 Apr 2021, 16:56 David Brown, wrote:
>
> >
> > The big problem with a fork, rather than an amiable split (where FSF/GNU
> > accepts that gcc wants to be a separate project) is the name. If the
> > FSF keep their own "gcc
On Mon, Apr 12, 2021 at 11:24 PM Nathan Sidwell wrote:
>
> On 4/12/21 5:32 AM, Richard Biener via Gcc wrote:
>
> >
> > Please concentrate on the important things, we're supposed to get a
> > release of GCC 11 out of the door.
>
> Then it is important thi
On April 14, 2021 12:19:16 PM GMT+02:00, Jonathan Wakely via Gcc
wrote:
>N.B. Jeff is no longer @redhat.com so I've changed the CC
>
>On Wed, 14 Apr 2021 at 11:03, Thomas Koenig
>wrote:
>> - All gfortran developers move to the new branch. This will not
>>happen, I can guarantee you that.
>
On April 15, 2021 6:02:50 PM GMT+02:00, Jason Merrill wrote:
>On Wed, Apr 14, 2021 at 8:08 AM Richard Biener via Gcc
> wrote:
>> On April 14, 2021 12:19:16 PM GMT+02:00, Jonathan Wakely via Gcc
> wrote:
>> >N.B. Jeff is no longer @redhat.com so I've changed the CC
>
On Sat, May 6, 2017 at 12:37 AM, Steve Ellcey wrote:
> I have a simple question about dump_printf and dump_printf_loc. I notice
> that most (all?) of the uses of these function are of the form:
>
> if (dump_enabled_p ())
> dump_printf_loc (MSG_*, ..);
>
> Since dump_en
On Sun, May 7, 2017 at 11:22 AM, Fredrik Hederstierna
wrote:
> Hi,
>
> I have a question about loop induction variables, related to
>
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67213
>
> Consider a simple loop like
>
> int ix;
> for (ix = 0; ix < 6; ix++) {
> data[ix] = ix;
> }
>
> I
On Fri, Apr 23, 2021 at 7:28 AM Xinliang David Li via Gcc
wrote:
>
> Hi, the create_gcov tool was probably removed with the assumption that it
> was only used with Google GCC branch, but it is actually used with GCC
> trunk as well.
>
> Given that, the tool will be restored in the github repo. It
On Fri, Apr 23, 2021 at 9:18 AM Martin Liška wrote:
>
> On 4/23/21 9:00 AM, Richard Biener via Gcc wrote:
> > On Fri, Apr 23, 2021 at 7:28 AM Xinliang David Li via Gcc
> > wrote:
> >>
> >> Hi, the create_gcov tool was probably removed with the assumption th
On Thu, Apr 29, 2021 at 5:40 AM JojoR via Gcc wrote:
>
> Hi,
>
> I have a little know about for 'Sizes and offsets as runtime
> invariants’,
>
> and need to add vector types like V2SImode as compile-time constants
> with enabled vector types of runtime invariants.
>
>
On Fri, Apr 30, 2021 at 9:51 AM Florian Weimer via Gcc wrote:
>
> * Feng Xue:
>
> > To simplify explanation of this memory gathering optimization, pseudo
> > code on original nested loops is given as:
> >
> > outer-loop ( ) { /* data in inner loop are also invariant in outer loop.
> > */
> >
On Mon, May 3, 2021 at 11:10 PM Andrew Pinski via Gcc wrote:
>
> Hi all,
> I noticed my (highly, -j24) parallel build of GCC is serialized on
> compiling gimple-match.c. Has anyone looked into splitting this
> generated file into multiple files?
There were threads about this in the past, yes.
On Wed, May 5, 2021 at 12:19 AM Gary Oblock via Gcc wrote:
>
> My jaws hit the floor when I saw this bug:
>
> psimplex.c: In function ‘master.constprop’:
> psimplex.c:124:6: error: non-trivial conversion in ‘constructor’
> 124 | void master(network_t *net, int num_threads)
> | ^
> str
On Tue, May 11, 2021 at 5:01 PM Segher Boessenkool
wrote:
>
> On Tue, May 04, 2021 at 10:40:38AM +0200, Richard Biener via Gcc wrote:
> > On Mon, May 3, 2021 at 11:10 PM Andrew Pinski via Gcc
> > wrote:
> > > I noticed my (highly, -j24) parallel build of GCC is se
On Tue, May 11, 2021 at 6:34 PM Serge Belyshev via Gcc wrote:
>
>
> > $ egrep "mpfr\.h" log/cfg/cfg.gcc-11.1.0.log
> > checking for the correct version of mpfr.h... buggy but acceptable
> >
> > It appears "gcc-11.1.0/contrib/download_prerequisites"
> > specifies "mpfr-3.1.4.tar.bz2" whereas top le
On Wed, May 12, 2021 at 11:03 AM Andrew Pinski wrote:
>
> On Wed, May 12, 2021 at 1:19 AM Richard Biener
> wrote:
> >
> > On Tue, May 11, 2021 at 5:01 PM Segher Boessenkool
> > wrote:
> > >
> > > On Tue, May 04, 2021 at 10:40:38AM +0200, Richard Bien
On May 14, 2021 10:53:21 AM GMT+02:00, "Martin Liška" wrote:
>On 5/12/21 10:51 AM, Richard Biener via Gcc wrote:
>> On Tue, May 11, 2021 at 6:34 PM Serge Belyshev via Gcc
> wrote:
>>>
>>>
>>>> $ egrep "mpfr\.h" log/cfg/cfg.gcc-11.1.
On Sun, May 16, 2021 at 4:37 PM Bernd Edlinger
wrote:
>
> On 5/14/21 10:20 PM, Andrew Pinski via Gcc wrote:
> > On Fri, May 14, 2021 at 3:27 AM Richard Biener via Gcc
> > wrote:
> >>
> >> On May 14, 2021 10:53:21 AM GMT+02:00, "Martin Liška"
On Sun, May 16, 2021 at 8:57 AM Uecker, Martin
wrote:
>
>
>
> Hi Richard,
>
> I noticed that GCC 11 has different behavior in the following
> example relative to 10.2 with -O2. I wonder whether this
> is an intentional change and if yes, what are the rules?
Yes, this is a fix for the long-standin
On Mon, May 17, 2021 at 9:32 AM Uecker, Martin
wrote:
>
>
>
> Am Montag, den 17.05.2021, 09:08 +0200 schrieb Richard Biener:
> > On Sun, May 16, 2021 at 8:57 AM Uecker, Martin
> > wrote:
> > >
> > >
> > > Hi Richard,
> > >
> > > I noticed that GCC 11 has different behavior in the following
> > >
On Mon, May 17, 2021 at 1:46 PM Uecker, Martin
wrote:
>
>
>
> Am Montag, den 17.05.2021, 09:44 +0200 schrieb Richard Biener:
> > On Mon, May 17, 2021 at 9:32 AM Uecker, Martin
> > wrote:
> > >
> > >
> > > Am Montag, den 17.05.2021, 09:08 +0200 schrieb Richard Biener:
> > > > On Sun, May 16, 2021
On Tue, May 18, 2021 at 4:51 AM Andrew Pinski via Gcc wrote:
>
> On Mon, May 17, 2021 at 6:52 PM Andrew Pinski wrote:
> >
> > I noticed while debugging why my "A?CST1:CST0" patch was broken for
> > Ada, I noticed the following ranges for boolean types:
> > # RANGE [0, 1] NONZERO 1
> > _14 = c
On Tue, May 18, 2021 at 11:41 AM Eric Botcazou wrote:
>
> > I noticed while debugging why my "A?CST1:CST0" patch was broken for
> > Ada, I noticed the following ranges for boolean types:
> > # RANGE [0, 1] NONZERO 1
> > _14 = checks__saved_checks_tos.482_2 > 0;
> > # RANGE [0, 255] NONZERO 1
On Thu, May 20, 2021 at 2:34 PM Martin Liška wrote:
>
> Hello.
>
> I've got a patch candidate that leverages partial linking for a couple of
> selected object files.
>
> I'm sending make all-host- jX results for my machine:
>
> before: 3m18s (user 32m52s)
> https://gist.githubusercontent.com/marx
On Thu, May 20, 2021 at 3:06 PM Martin Liška wrote:
>
> On 5/20/21 2:54 PM, Richard Biener wrote:
> > So why did you go from applying this per-file to multiple files?
>
> When I did per-file for {gimple,generic}-match.c I hit the following issue
> with lto.priv symbols:
>
> /usr/lib64/gcc/x86_64-
On Thu, May 20, 2021 at 3:16 PM Richard Biener
wrote:
>
> On Thu, May 20, 2021 at 3:06 PM Martin Liška wrote:
> >
> > On 5/20/21 2:54 PM, Richard Biener wrote:
> > > So why did you go from applying this per-file to multiple files?
> >
> > When I did per-file for {gimple,generic}-match.c I hit the
On Fri, May 28, 2021 at 7:12 AM Jason Merrill via Gcc wrote:
>
> On 5/27/21 11:59 PM, Jason Merrill wrote:
> > PR100797 seems like a P1 regression from 9.3, I'd like to fix it before
> > the release.
>
> Here's a candidate patch. Going to bed now.
I have bootstrapped and tested it on x86_64-unkn
On Tue, Jun 1, 2021 at 9:33 AM Martin Liška wrote:
>
> @Richi: Can you please reply to this email?
Not sure what I should add here? Honza suggested to mangle the
promoted symbol names. I don't
really like the idea to compile multiple TUs into one object. Also
+LTO_LINKER_FLAGS = -flto=auto --
On Tue, Jun 1, 2021 at 1:25 PM Martin Liška wrote:
>
> On 6/1/21 9:42 AM, Richard Biener wrote:
> > On Tue, Jun 1, 2021 at 9:33 AM Martin Liška wrote:
> >>
> >> @Richi: Can you please reply to this email?
> >
> > Not sure what I should add here? Honza suggested to mangle the
> > promoted symbol
On June 1, 2021 7:30:54 PM GMT+02:00, David Malcolm via Gcc
wrote:
>On Tue, 2021-06-01 at 10:00 -0400, David Edelsohn via Gcc wrote:
>> GCC was created as part of the GNU Project but has grown to operate
>> as
>> an autonomous project.
>>
>> The GCC Steering Committee has decided to relax the re
On June 6, 2021 12:54:03 AM GMT+02:00, Andrew Pinski via Gcc
wrote:
>While debugging PR 100925, I found that after my match.pd (for
>A?CST0:CST1) and phiopt patch to use match-and-simplify, gcc will
>produce an negate assignment gimple which has a pointer type (and
>offset type). Before we would
On Thu, Jun 3, 2021 at 5:27 PM Jason Merrill via Gcc wrote:
>
> On Thu, Jun 3, 2021 at 10:46 AM Giacomo Tesio wrote:
>
> >
> > I would have really appreciated if the GCC SC had announced such change
> > for the upcoming GCC 12 while sticking to the old policy in GCC 11.
> >
>
> That is how I was
On Mon, Jun 7, 2021 at 3:10 PM Giacomo Tesio wrote:
>
> Hi Richard,
>
> On June 7, 2021 7:35:01 AM UTC, Richard Biener
> wrote:
> > On Thu, Jun 3, 2021 at 5:27 PM Jason Merrill via Gcc
> > wrote:
> > >
> > > On Thu, Jun 3, 2021 at 10:46 AM Giacomo Tesio
> > wrote:
> > >
> > > >
> > > > I would
On Wed, Jun 9, 2021 at 1:50 PM Aldy Hernandez via Gcc wrote:
>
> Hi Jeff. Hi folks.
>
> What started as a foray into severing the old (forward) threader's
> dependency on evrp, turned into a rewrite of the backwards threader
> code. I'd like to discuss the possibility of replacing the current
>
On Wed, Jun 9, 2021 at 4:22 PM Giacomo Tesio wrote:
>
> Hi Gabriel,
>
> On June 9, 2021 12:41:09 PM UTC, Gabriel Ravier
> wrote:
> >
> > I do consider that a lack of transparency is pretty bad, and that
> > discussions on subjects like this should be done in public, but I
> > wouldn't say it's ju
On June 9, 2021 5:34:03 PM GMT+02:00, Aldy Hernandez wrote:
>
>
>On 6/9/21 2:09 PM, Richard Biener wrote:
>> On Wed, Jun 9, 2021 at 1:50 PM Aldy Hernandez via Gcc
> wrote:
>>>
>>> Hi Jeff. Hi folks.
>>>
>>> What started as a foray into severing the old (forward) threader's
>>> dependency on evrp,
On Fri, Jun 11, 2021 at 12:07 PM Erick Ochoa via Gcc wrote:
>
> Hi,
>
> I am looking for a small clarification. I understand that during late
> SIMPLE_IPA_PASSes some statically initialized global variables might
> have error_mark_node trees in their DECL_INITIAL field.
>
> I believe that I read s
On June 13, 2021 4:03:16 AM GMT+02:00, Andrew Pinski wrote:
>On Sat, Jun 12, 2021 at 5:21 PM Andrew Pinski
>wrote:
>>
>> On Sat, Jun 12, 2021 at 4:54 PM Andrew Pinski
>wrote:
>> >
>> > Hi all,
>> > While moving the simple A CMP 0 ? A : -A patterns from
>> > fold_cond_expr_with_comparison to ma
On Mon, Jun 14, 2021 at 12:02 AM Jeff Law via Gcc wrote:
>
>
>
> On 6/9/2021 5:48 AM, Aldy Hernandez wrote:
> > Hi Jeff. Hi folks.
> >
> > What started as a foray into severing the old (forward) threader's
> > dependency on evrp, turned into a rewrite of the backwards threader
> > code. I'd like
On Fri, Jun 18, 2021 at 3:03 PM Erick Ochoa via Gcc wrote:
>
> Hi,
>
> I am having some trouble understanding the semantics of OBJ_TYPE_REF.
> I understand that it is made of three operands:
>
> 1. OBJ_TYPE_REF_EXPR: An expression that evaluates the value to use.
> 2. OBJ_TYPE_REF_OBJECT: Is the o
On Thu, Jun 24, 2021 at 6:14 PM Jeff Law wrote:
>
>
>
> On 6/21/2021 8:40 AM, Aldy Hernandez wrote:
> >
> >
> > On 6/9/21 2:09 PM, Richard Biener wrote:
> >> On Wed, Jun 9, 2021 at 1:50 PM Aldy Hernandez via Gcc
> >> wrote:
> >>>
> >>> Hi Jeff. Hi folks.
> >>>
> >>> What started as a foray into
On Fri, Jun 25, 2021 at 9:54 AM Richard Biener
wrote:
>
> On Thu, Jun 24, 2021 at 6:14 PM Jeff Law wrote:
> >
> >
> >
> > On 6/21/2021 8:40 AM, Aldy Hernandez wrote:
> > >
> > >
> > > On 6/9/21 2:09 PM, Richard Biener wrote:
> > >> On Wed, Jun 9, 2021 at 1:50 PM Aldy Hernandez via Gcc
> > >> wro
On Fri, Jun 25, 2021 at 6:20 PM Aldy Hernandez wrote:
>
> Hi folks.
>
> I'm done with benchmarking, testing and cleanups, so I'd like to post my
> patchset for review. However, before doing so, I'd like to address a
> handful of meta-issues that may affect how I post these patches.
First of all
On Wed, Jun 30, 2021 at 10:23 AM Erick Ochoa via Gcc wrote:
>
> Hello,
>
> I am wondering if there's a way to get the global namespace at LTO
> during LGEN in each of the partitions being processed. I believe that
> during parse time for c/c++ there is a global_namespace macro or
> variable that c
On June 30, 2021 4:07:00 PM GMT+02:00, Erick Ochoa via Gcc
wrote:
>Hi,
>
>I am still working on understanding the LTO framework and how the
>gimple representation works across multiple partitions. I found myself
>printing all global variables and printing their DECL_UID. I noticed
>that for some
On June 30, 2021 6:28:29 PM GMT+02:00, Erick Ochoa wrote:
>On Wed, 30 Jun 2021 at 17:06, Richard Biener
> wrote:
>>
>> On June 30, 2021 4:07:00 PM GMT+02:00, Erick Ochoa via Gcc
> wrote:
>> >Hi,
>> >
>> >I am still working on understanding the LTO framework and how the
>> >gimple representation wo
On Thu, Jul 1, 2021 at 9:40 AM Erick Ochoa via Gcc wrote:
>
> Hello,
>
> I have a function that looks at identifiers of formal parameters. I
> found that when I ran this function on larger projects, the compiler
> segfaulted. I looked into this and I found that there are some formal
> parameters w
On Fri, Jul 2, 2021 at 5:34 AM Kewen.Lin via Gcc wrote:
>
> Hi,
>
> I am investigating one degradation related to SPEC2017 exchange2_r,
> with loop vectorization on at -O2, it degraded by 6%. By some
> isolation, I found it isn't directly caused by vectorization itself,
> but exposed by vectoriza
On Fri, Jul 2, 2021 at 11:05 AM Kewen.Lin wrote:
>
> Hi Richard,
>
> on 2021/7/2 下午4:07, Richard Biener wrote:
> > On Fri, Jul 2, 2021 at 5:34 AM Kewen.Lin via Gcc wrote:
> >>
> >> Hi,
> >>
> >> I am investigating one degradation related to SPEC2017 exchange2_r,
> >> with loop vectorization on at
On Fri, Jul 2, 2021 at 6:33 PM Martin Sebor via Gcc wrote:
>
> Most sanitizer built-in argument types are all of pointer types.
> For example:
>
>BUILT_IN_UBSAN_HANDLE_SHIFT_OUT_OF_BOUNDS
> as
>BT_FN_VOID_PTR_PTR_PTR
>
> or
>
>BUILT_IN_UBSAN_HANDLE_VLA_BOUND_NOT_POSITIVE
> as
>BT_F
On Wed, Jul 7, 2021 at 11:00 AM Florian Weimer via Gcc wrote:
>
> It seems to me that the arc port still defaults to -fcommon, presumably
> due to this in gcc/common/config/arc/arc-common.c:
>
> static void
> arc_option_init_struct (struct gcc_options *opts)
> {
> opts->x_flag_no_common = 255; /
On Wed, Jul 7, 2021 at 11:56 AM Richard Biener
wrote:
>
> On Wed, Jul 7, 2021 at 11:00 AM Florian Weimer via Gcc
> wrote:
> >
> > It seems to me that the arc port still defaults to -fcommon, presumably
> > due to this in gcc/common/config/arc/arc-common.c:
> >
> > static void
> > arc_option_init
On Thu, Jul 8, 2021 at 11:17 AM LIU Hao via Gcc wrote:
>
> Last known good build was on 06/21, but I now keep getting this error:
>
>
> /d/lh_mouse/GitHub/MINGW-packages-dev/mingw-w64-gcc-git/src/gcc/libgomp/configure:
> line 4071:
> ./conftest.exe: cannot execute binary file: Exec format err
On Thu, Jul 8, 2021 at 1:36 PM LIU Hao wrote:
>
> 在 2021-07-08 17:49, Richard Biener 写道:
> >
> > Maybe it was the EH format changes or dwarf5 stuff backported, CCing
> > Eric. It would be nice to see
> > the conftest.exe to see what's wrong (if there's anything obvious).
> >
> > Can you open a bu
On Fri, Jul 9, 2021 at 9:52 AM Erick Ochoa via Gcc wrote:
>
> Hi, I noticed this is also happening also for local variables. Again,
> storing tree declarations on a summary during LGEN and then at WPA
> time reading from those summaries. I can print the declaration, but
> when I try to look for it
On Mon, Jul 12, 2021 at 7:20 PM Jonathan Wakely via Gcc wrote:
>
> On Mon, 12 Jul 2021 at 18:04, Eli Zaretskii via Gcc wrote:
> >
> > > From: Matthias Kretz
> > > Date: Mon, 12 Jul 2021 16:54:50 +0200
> > >
> > > On Monday, 12 July 2021 16:30:23 CEST Martin Liška wrote:
> > > > On 7/12/21 4:12 P
On Tue, Jul 13, 2021 at 11:21 AM Erick Ochoa wrote:
>
> Hi,
>
> Just to clarify a similar question: I am using stream_write_tree and
> looking at the comments it says that it is assumed that the tree T is
> already in the encoder cache. Does this mean that I have to use
> lto_symtab_encoder_t for
On Tue, Jul 13, 2021 at 1:52 PM Eli Zaretskii wrote:
>
> > From: Richard Biener
> > Date: Tue, 13 Jul 2021 08:24:17 +0200
> > Cc: Eli Zaretskii , "gcc@gcc.gnu.org"
> >
> > I actually like texinfo (well, because I know it somewhat, compare to
> > sphinx).
> > I think it produces quite decent PDF
On Tue, Jul 13, 2021 at 12:50 PM Erick Ochoa wrote:
>
> > There are entities, like SSA names and STRING_CSTs which are specially
> > encoded and if you stream those in your LGEN data you have to set up
> > appropriate encoders. In general streaming arbitrary trees isn't the
> > best thing to do,
On Tue, Jul 13, 2021 at 2:19 PM Christoph Müllner via Gcc
wrote:
>
> On Tue, Jul 13, 2021 at 2:11 AM Alexandre Oliva wrote:
> >
> > On Jul 12, 2021, Christoph Müllner wrote:
> >
> > > * Why does the generic by-pieces infrastructure have a higher priority
> > > than the target-specific expansion
On Wed, Jul 14, 2021 at 6:42 AM Gary Oblock via Gcc wrote:
>
> OK, I haven't asked a dumb question for a while so here goes!
>
> I'm trying to debug my optimization in lto running 505mcf_r
> (yes it's SPEC17.)
>
> Here's the bit that fails from the make.out:
>
> /home/gary/gcc_build_gcc11/install/
On Wed, Jul 14, 2021 at 7:50 AM Sebastian Huber
wrote:
>
> Hello,
>
> I noticed that the following static read-only object gets optimized away
> if optimization is enabled:
>
> /* Generate the pointer to the gcov_info_var in a dedicated section. */
>
> static void
> build_gcov_info_var_registrati
On Wed, Jul 14, 2021 at 9:00 AM Hongtao Liu via Gcc-patches
wrote:
>
> On Wed, Jul 14, 2021 at 2:39 PM Matthias Kretz wrote:
> >
> > On Wednesday, 14 July 2021 07:18:29 CEST Hongtao Liu via Gcc-help wrote:
> > > On Wed, Jul 14, 2021 at 1:15 PM Hongtao Liu wrote:
> > > > Hi:
> > > > The origina
On Wed, Jul 14, 2021 at 9:49 AM Matthias Kretz wrote:
>
> On Wednesday, 14 July 2021 09:39:42 CEST Richard Biener wrote:
> > -ffast-math decomposes to quite some flag_* and those generally are not
> > reflected into the IL but can be different per function (and then
> > prevent inlining).
>
> Is t
On Wed, Jul 14, 2021 at 10:11 AM Hongtao Liu wrote:
>
> On Wed, Jul 14, 2021 at 3:49 PM Matthias Kretz wrote:
> >
> > On Wednesday, 14 July 2021 09:39:42 CEST Richard Biener wrote:
> > > -ffast-math decomposes to quite some flag_* and those generally are not
> > > reflected into the IL but can be
On Wed, Jul 14, 2021 at 10:56 AM Hongtao Liu wrote:
>
> On Wed, Jul 14, 2021 at 4:17 PM Richard Biener
> wrote:
> >
> > On Wed, Jul 14, 2021 at 10:11 AM Hongtao Liu wrote:
> > >
> > > On Wed, Jul 14, 2021 at 3:49 PM Matthias Kretz wrote:
> > > >
> > > > On Wednesday, 14 July 2021 09:39:42 CEST
On Wed, Jul 14, 2021 at 3:56 PM Erick Ochoa wrote:
>
> > I guess the way to encode SSA trees would be to use sth like a
> > , SSA-version tuple much like PTA internally
> > uses the varinfo array index as identifier for the variables in the
> > constraints. For local decls (as opposed to SSA name
On Thu, Jul 15, 2021 at 10:22 AM Erick Ochoa via Gcc wrote:
>
> Hi,
>
> I was sorting SSA trees and DECL_P trees into different buckets. I
> used DECL_P as a proxy for it being a local/global variable/function
> (essentially a declaration). It seems that "probabilistically", I'm
> kinda right. Nor
On July 17, 2021 8:54:38 PM GMT+02:00, Stefan Kanthak
wrote:
>Hi,
>
>GCC 10.2.0 (and GCC 8.3; other versions and targets except i386 and
>amd64 not tested) generate rather bad code for the following ternary
>expression:
>
>--- repro.c ---
>#define NULL (char *) 0
>
>char *dummy(char *string, long
On Wed, Jul 21, 2021 at 6:55 PM Erick Ochoa wrote:
>
> Hello Richard, I need a little bit more help. In our previous messages
> you mentioned ""
>
> > >
> > > > I guess the way to encode SSA trees would be to use sth like a
> > > > , SSA-version tuple much like PTA internally
> > > > uses the vari
On Tue, Jul 20, 2021 at 4:54 PM Florian Weimer via Gcc wrote:
>
> Currently, the GNU/Linux ABI does not really specify whether the thread
> pointer (the address of the TCB) may change at a function boundary.
>
> Traditionally, GCC assumes that the ABI allows caching addresses of
> thread-local var
On Wed, Jul 21, 2021 at 2:45 PM Sebastian Huber
wrote:
>
> Hello,
>
> while testing this patch
>
> https://www.google.com/search?client=firefox-b-e&q=gcc+enable_runtime_checking
>
> I noticed that __gcov_info_to_gcda() uses abort(). This is due to (from
> tsystem.h):
>
> #ifdef ENABLE_RUNTIME_CHEC
On Thu, Jul 22, 2021 at 8:06 AM Gary Oblock via Gcc wrote:
>
> I seem to be having a problem with the pre pass.
>
> When eliminate_dom_walker::eliminate_stmt is called with
> the gsi to "dedangled_864 = bea_43->tail;" which in turn
> calls eliminate_dom_walker::eliminate_avail op of dedangled_864.
On Thu, Jul 22, 2021 at 2:04 PM Erick Ochoa wrote:
>
> > > If this is the case, I can indeed get the varpool node's at WPA time
> > > (as shown above), but comparing their pointer addresses will be
> > > distinct. How can one find out that two varpool nodes/cgraph nodes are
> > > the same at WPA t
On Thu, Jul 22, 2021 at 2:33 PM Erick Ochoa wrote:
>
> > > > 1. pid of lgen process that generated the encoding
> > > > 2. index returned by lto_symtab_encoder_encode
> > > > 3. varpool_node->name ()
> > > > 4. the pointer address being pointed by varpool node
> >
> > Well, yes, during LGEN no WPA
On Sun, Jul 25, 2021 at 1:58 PM Uecker, Martin
wrote:
>
>
>
> Hi Richard,
>
> here is another case where it seems that TBAA goes
> wrong. Since this is not in a loop, it seems this
> is something else than what we discussed. Is
> this a known issue?
>
> Best,
> Martin
>
>
> #include
> #include
>
On Sun, Jul 25, 2021 at 1:58 PM Uecker, Martin
wrote:
>
>
>
> Hi Richard,
>
> here is another case where it seems that TBAA goes
> wrong. Since this is not in a loop, it seems this
> is something else than what we discussed. Is
> this a known issue?
No, it's not known and it is a bug. It seems t
On Mon, Jul 26, 2021 at 11:06 AM Prathamesh Kulkarni via Gcc
wrote:
>
> On Fri, 23 Jul 2021 at 23:29, Andrew Pinski wrote:
> >
> > On Fri, Jul 23, 2021 at 3:55 AM Prathamesh Kulkarni via Gcc
> > wrote:
> > >
> > > Hi,
> > > Continuing from this thread,
> > > https://gcc.gnu.org/pipermail/gcc-pat
On Tue, Jul 27, 2021 at 10:05 AM Richard Biener
wrote:
>
> On Sun, Jul 25, 2021 at 1:58 PM Uecker, Martin
> wrote:
> >
> >
> >
> > Hi Richard,
> >
> > here is another case where it seems that TBAA goes
> > wrong. Since this is not in a loop, it seems this
> > is something else than what we discus
On Thu, Jul 22, 2021 at 4:33 PM Erick Ochoa wrote:
>
> >
> > But the addresses are at LGEN time?
>
> The following is what runs at WPA time
>
> unsigned long pid = streamer_read_uhwi (&ib);
> unsigned long id = streamer_read_uhwi (&ib);
> lto_symtab_encoder_t encoder = file_data->symtab_node_encod
On Fri, Jul 23, 2021 at 3:40 AM Gary Oblock wrote:
>
> Richard,
>
> OK, all that I've gotten so far out of the dump file is
> that the name of "_920" is just something sccvn concocted
> and wasn't something I accidentally caused.
>
> That still leaves me with the question of what is going on.
>
>
On Wed, Jul 28, 2021 at 11:03 PM Gary Oblock wrote:
>
> Richard,
>
> Here is more on the actual failure.
>
> From the pre pass dump:
>
> :
> Inserted _975 = (struct node.reorg.reorder *) dedangled_865;
> Replaced bea_43->tail with _975 in dedangled_864 = bea_43->tail;
>
>
>
> EMERGENCY DUMP:
>
> v
On Thu, Jul 29, 2021 at 9:29 AM Gary Oblock wrote:
>
> Richard,
>
> I didn't find a use of _975 with that type...
>
> A small test case is easier said than done. It's mcf
> and I pulled a copy out of SPEC for my unit tests (we have
> a SPEC license) and that passes. However, when I compile it
> in
On Thu, Jul 29, 2021 at 6:09 PM Joseph Myers wrote:
>
> On Thu, 29 Jul 2021, Florian Weimer via Gcc wrote:
>
> > On GNU/Linux, SEGFS is used to implement the thread pointer, to avoid
> > dedicating a general-purpose register to it. At address zero with the
> > SEGFS prefix, the offset itself is s
On Sat, Jul 31, 2021 at 9:34 PM Segher Boessenkool
wrote:
>
> On Thu, Jul 29, 2021 at 04:08:36PM +, Joseph Myers wrote:
> > On Thu, 29 Jul 2021, Florian Weimer via Gcc wrote:
> > > On GNU/Linux, SEGFS is used to implement the thread pointer, to avoid
> > > dedicating a general-purpose register
On Wed, Aug 4, 2021 at 2:07 AM Aaron Sawdey wrote:
>
> Richard,
>
> So, I’m noticing that in get_reassociation_width() we know how many ops
> (ops_num) are in the expression being considered for parallel reassociation,
> but this is not passed to the target hook. In my testing this seems like it
On Thu, Aug 5, 2021 at 11:44 AM Gabriel Paubert wrote:
>
> On Thu, Aug 05, 2021 at 09:25:02AM +0200, Stefan Kanthak wrote:
> > Hi,
> >
> > targeting AMD64 alias x86_64 with -O3, GCC 10.2.0 generates the
> > following code (13 instructions using 57 bytes, plus 4 quadwords
> > using 32 bytes) for __
On Thu, Aug 5, 2021 at 3:45 PM Erick Ochoa wrote:
>
> Hello Richard,
>
> I'm still working on the points-to analysis and I am happy to say that
> after reviewing the ipa-cp code I was able to generate summaries for
> local variables, ssa variables, heap variables, global variables and
> functions.
On Fri, Aug 6, 2021 at 2:47 PM Stefan Kanthak wrote:
>
> Gabriel Paubert wrote:
>
> > Hi,
> >
> > On Thu, Aug 05, 2021 at 01:58:12PM +0200, Stefan Kanthak wrote:
> >> Gabriel Paubert wrote:
> >>
> >>
> >> > On Thu, Aug 05, 2021 at 09:25:02AM +0200, Stefan Kanthak wrote:
>
> >> >>
On August 6, 2021 4:32:48 PM GMT+02:00, Stefan Kanthak
wrote:
>Michael Matz wrote:
>
>
>> 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 accepta
201 - 300 of 756 matches
Mail list logo
