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:
>
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-
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
0:43 AM, Martin Liška wrote:
> > On 5/20/21 2:54 PM, Richard Biener wrote:
> >> On Thu, May 20, 2021 at 2:34 PM Martin Liška wrote:
> >>>
> >>> Hello.
> >>>
> >>> I've got a patch candidate that leverages partial li
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 s
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 Giac
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 severi
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:
> >>>
> &
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 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
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
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-co
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 a
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
> &
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
> > p
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
> >
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:
> > > &g
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
t the number N, then encoding symbol X in
> partition Z should also yield N.
>
> I believe this is not the case, during WPA time I am printing:
> 1. pid of lgen process that generated the encoding
> 2. index returned by lto_symtab_encoder_encode
> 3. varpool_node->name ()
&g
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 loo
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
xpr<&_reorg_base_var_node.reorg.reorder>}@.MEM_387
> (0299), {component_ref,mem_ref<0B>,addr_expr<&net>}@.MEM_387
> (0222), {abs_expr,red_cost_of_bea_42} (0134),
> {component_ref,mem_ref<0B>,addr_expr<&_reorg_base_var_node.reorg.reorder>}@.MEM_3
e.reorg.reorder *.
So what did you change in GCC? If you did not change value-numbering
then you can reduce the testcase down and extract a GIMPLE frontend
testcase for VN (use -fdump-tree-all-gimple and massage the GIMPLE
dumped before the FRE/PRE pass that causes the issue)
> Gary
>
&
ase
> I'm still kind of stuck.
>
> Gary
>
>
> From: Richard Biener
> Sent: Thursday, July 29, 2021 12:12 AM
> To: Gary Oblock
> Cc: gcc@gcc.gnu.org
> Subject: Re: A value number issue
>
> [EXTERNAL EMAIL NOTICE: This email origina
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.
use "add rax,rax; shr rax,53" instead of
> "shr rax,52; and eax,0x7ff" and save 2 bytes.
>
> Complete properly optimized code for __builtin_trunc is then as follows
> (11 instructions, 44 bytes):
>
> .code64
> .intel_syntax
> .equBIAS, 1023
> .t
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
On Fri, Aug 6, 2021 at 6:58 PM Thomas Schwinge wrote:
>
> Hi!
>
> So I'm trying to do some C++... ;-)
>
> Given:
>
> /* A map from SSA names or var decls to record fields. */
> typedef hash_map field_map_t;
>
> /* For each propagation record type, this is a map from SSA names or var
On Mon, Aug 9, 2021 at 8:52 AM Sebastian Huber
wrote:
>
> Hello,
>
> I would like to use gcov for a multi-threaded program running on an SMP
> machine using a 32-bit SPARC/LEON3 target. This target supports
> HAVE_atomic_compare_and_swapsi but not HAVE_atomic_compare_and_swapdi.
> Unfortunately we
On Mon, Aug 9, 2021 at 12:56 PM Sebastian Huber
wrote:
>
> On 09/08/2021 12:22, Richard Biener wrote:
> > On Mon, Aug 9, 2021 at 8:52 AM Sebastian Huber
> > wrote:
> >> Hello,
> >>
> >> I would like to use gcov for a multi-threaded program runnin
On Mon, Aug 9, 2021 at 2:03 PM Sebastian Huber
wrote:
>
>
>
> On 09/08/2021 13:27, Richard Biener wrote:
> >>> Can you not implement 64bit atomic support for 32bit SPARC somehow?
> >> The 32-bit SPARC/LEON3 has only a 32-bit compare and swap instruction
> &g
On Tue, Aug 10, 2021 at 8:07 AM Sebastian Huber
wrote:
>
> On 09/08/2021 14:13, Richard Biener wrote:
> >>> But I guess using 32bit counters on sparc-rtems might be the way to
> >>> go ...
> >> Yes, you somehow just have to make sure that your test pr
On Mon, Aug 16, 2021 at 2:44 PM Thomas Schwinge wrote:
>
> Hi!
>
> On 2021-08-09T12:02:02+0200, Richard Biener via Gcc wrote:
> > On Fri, Aug 6, 2021 at 6:58 PM Thomas Schwinge
> > wrote:
> >> So I'm trying to do some C++... ;-)
> >>
> >
On Tue, Aug 17, 2021 at 8:40 AM Thomas Schwinge wrote:
>
> Hi!
>
> On 2021-08-16T14:10:00-0600, Martin Sebor wrote:
> > On 8/16/21 6:44 AM, Thomas Schwinge wrote:
> >> [...], to document the current behavior, I propose to
> >> "Add more self-tests for 'hash_map' with Value type with non-trivial
>
K to push the attached
>"Make 'gcc/hash-map-tests.c:test_map_of_type_with_ctor_and_dtor_expand'
>work on 32-bit architectures [PR101959]", which does resolve the issue
>for a '-m32' i686-pc-linux-gnu build?
Ok.
Richard.
>
>Grüße
> Thomas
>
>
>> On Tue, Aug 17, 202
On Wed, Aug 25, 2021 at 7:30 AM Gary Oblock via Gcc wrote:
>
> I print out a bit of GIMPLE for a program and it looks like this:
>
>[local count: 13634385]:
> # a_1 = PHI
> # n_11 = PHI
> loop:
> # DEBUG n => n_11
> # DEBUG a => a_1
> _2 = (long unsigned int) a_1;
> _3 = _2 & 7;
On Wed, Aug 25, 2021 at 11:09 AM Jojo R via Gcc wrote:
>
>
> — Jojo
> 在 2021年8月25日 +0800 PM3:27，Jonathan Wakely ，写道：
> >
> >
> > On Wed, 25 Aug 2021, 07:45 Jojo R wrote:
> > > Hi,
> > >
> > > I want to use struct or array type as container in my project,
> > >
> > > but GCC does no
so would have changed analysis/transform the
reasonable thing to do is to reset them (gimple_debug_bind_reset_value).
The only "special" thing about the debug stmts is that they do not
have GIMPLE-like RHS but instead they have GENERIC trees
on the RHS.
Richard.
>
> Thanks,
>
>
On Wed, Sep 8, 2021 at 12:44 PM Aldy Hernandez wrote:
>
> First of all. Thanks so much for this incredibly useful explanation.
> It helps a lot.
>
> I'm still trying to wrap my head around this, so please bear with me.
>
> On 9/7/21 4:45 PM, Michael Matz wrote:
> > Hello,
> >
> > On Tue, 7 Sep 20
On Wed, Sep 8, 2021 at 3:25 PM Aldy Hernandez wrote:
>
> > It would be helpful to have the patch causing the issue to look at the IL.
> > But as Micha said, there needs to be a perfect loop nest for interchange
> > to work.
> >
> > Richard.
>
> Absolutely! I'm attaching the reduced testcase, as w
On Wed, Sep 8, 2021 at 8:13 PM Michael Matz wrote:
>
> 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
On Wed, Sep 8, 2021 at 10:50 PM Erick Ochoa via Gcc wrote:
>
> Hello,
>
> I am refactoring some old code that runs as an IPA_PASS. This code is
> intended to run at link-time using the LTO framework and so I am
> always testing it that way. At the moment, I am trying to use
> hash-maps but having
On Thu, Sep 9, 2021 at 9:37 AM Aldy Hernandez wrote:
>
>
>
> On 9/9/21 8:57 AM, Richard Biener wrote:
> > On Wed, Sep 8, 2021 at 8:13 PM Michael Matz wrote:
> >>
> >> Hello,
> >>
> >> [lame answer to self]
> >>
> >> On Wed,
On Thu, Sep 9, 2021 at 10:14 AM Aldy Hernandez wrote:
>
>
>
> On 9/8/21 8:13 PM, Michael Matz wrote:
> > 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 dif
On Thu, Sep 9, 2021 at 10:36 AM Aldy Hernandez wrote:
>
>
>
> On 9/9/21 9:45 AM, Richard Biener wrote:
> > On Thu, Sep 9, 2021 at 9:37 AM Aldy Hernandez wrote:
> >>
> >>
> >>
> >> On 9/9/21 8:57 AM, Richard Biener wrote:
&g
On Thu, Sep 9, 2021 at 11:21 AM Aldy Hernandez wrote:
>
>
>
> On 9/9/21 10:58 AM, Richard Biener wrote:
> > On Thu, Sep 9, 2021 at 10:36 AM Aldy Hernandez wrote:
> >>
> >>
> >>
> >> On 9/9/21 9:45 AM, Richard Biener wrote:
>
ould address those.
Pushed.
Richard.
>From f4e66a329096bb1f9f0fc51bd8a5b35cad77f1b8 Mon Sep 17 00:00:00 2001
From: Richard Biener
Date: Tue, 14 Sep 2021 13:45:42 +0200
Subject: [PATCH] Add recent target obsoletions / removals
This adds a note about obsoleted and removed target support.
---
htdocs/gcc-
On Wed, Sep 15, 2021 at 4:02 AM Liu, Hongtao via Gcc wrote:
>
> I got some feedback from my colleague
>
> -
> What we need from GCC
>
> 1. generate SPIR-V
But is SPIR-V powerful enough here, if wikipedia is right and it is
close to GLSL
then it likely has not the ability to perfor
On Thu, Sep 16, 2021 at 1:37 AM Paul Koning via Gcc wrote:
>
>
>
> > On Sep 15, 2021, at 5:21 PM, Joseph Myers wrote:
> >
> > On Wed, 15 Sep 2021, Paul Koning via Gcc wrote:
> >
> >> Some questions about developer branches:
> >>
> >> 1. Who may create one? Who may write to them?
> >> 2. Are they
On Thu, Sep 16, 2021 at 10:36 PM Joseph Myers wrote:
>
> On Thu, 16 Sep 2021, Chris Kennelly wrote:
>
> > In terms of relying on the feature: If __memcmpeq is ever exposed as an a
> > simple alias for memcmp (since the notes mention that it's a valid
> > implementation), does that open up the pos
On Fri, Sep 17, 2021 at 10:08 AM Florian Weimer wrote:
>
> * Richard Biener via Gcc:
>
> > On Thu, Sep 16, 2021 at 10:36 PM Joseph Myers
> > wrote:
> >>
> >> On Thu, 16 Sep 2021, Chris Kennelly wrote:
> >>
> >> > In terms of relying on
On Fri, Sep 17, 2021 at 10:37 AM Florian Weimer wrote:
>
> * Richard Biener:
>
> > On Fri, Sep 17, 2021 at 10:08 AM Florian Weimer wrote:
> >>
> >> * Richard Biener via Gcc:
> >>
> >> > On Thu, Sep 16, 2021 at 10:36 PM Joseph Myers
&g
On Fri, Sep 17, 2021 at 1:17 PM Thomas Schwinge wrote:
>
> Hi!
>
> On 2021-09-10T10:00:25+0200, I wrote:
> > On 2021-09-01T19:31:19-0600, Martin Sebor via Gcc-patches
> > wrote:
> >> On 8/30/21 4:46 AM, Thomas Schwinge wrote:
> >>> Ping -- we still need to plug the memory leak; see patch attache
On Fri, Sep 17, 2021 at 2:39 PM Jonathan Wakely wrote:
>
> On Fri, 17 Sept 2021 at 13:08, Richard Biener
> wrote:
> >
> > On Fri, Sep 17, 2021 at 1:17 PM Thomas Schwinge
> > wrote:
> > >
> > > Hi!
> > >
> > > On 2021-09-10T10:0
ce-on-valid-code: ICE on code that is syntactically valid.
>>>
>>
>> What about syntactically valid but semantically invalid code? I'd call
>> that ICE-on-invalid as well.
>
>My understanding of the "valid" in the keyword is that it refers
>only to
On Fri, Sep 17, 2021 at 5:52 PM Thomas Schwinge wrote:
>
> Hi!
>
> On 2021-09-17T15:03:18+0200, Richard Biener
> wrote:
> > On Fri, Sep 17, 2021 at 2:39 PM Jonathan Wakely
> > wrote:
> >> On Fri, 17 Sept 2021 at 13:08, Richard Biener
> >> wrote:
On Fri, Sep 24, 2021 at 3:45 AM Eugene Rozenfeld via Gcc
wrote:
>
> I ran into a bug with lto: no line number info gets emitted when building my
> project with -flto and -g (with gcc 8.2). I'd like to provide a repro in the
> bug report but I don't know if there is an easy way to collect everyth
On Fri, Sep 24, 2021 at 10:04 AM Aldy Hernandez via Gcc wrote:
>
> Hi folks.
>
> My upcoming threading improvements turn the test below into an infinite
> runtime loop:
>
> int a, b;
> short c;
>
> int
> main ()
> {
>int j, d = 1;
>for (; c >= 0; c++)
> {
> BODY:
>a = d;
>
On Mon, Sep 27, 2021 at 5:08 PM David Edelsohn wrote:
>
> Richi and Aaron,
>
> Thanks for the great conversation about register pressure at the GCC
> BoF at LPC2021. It was a very productive session with good ideas
> about how to proceed.
>
> Where do you suggest that I place the Register pressur
Status
==
The GCC development branch is open for general development (Stage 1),
but the two-month general bugfixing period (Stage 3) is ahead with
historical data telling us to expect it to start Nov 15th and last
through the Christmas holidays.
Take the quality data below with a big grain
On Mon, Oct 4, 2021 at 12:08 PM Jakub Jelinek via Fortran
wrote:
>
> Hi!
>
> On powerpc64le-linux target, one can select between two incompatible
> long double formats (both of them are 16-byte), __ibm128 which is
> a sum of two doubles, and __float128 (note, not implemented through
> libquadmath)
2101 - 2200 of 2622 matches
Mail list logo
