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 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 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 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 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 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
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
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
>
&
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
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
The GNU Compiler Collection version 11.2 has been released.
GCC 11.2 is a bug-fix release from the GCC 11 branch containing important
fixes for regressions and serious bugs in GCC 11.1 with more than 95 bugs
fixed since the previous release.
This release is available from the WWW and FTP servers
Status
==
The GCC 11.2.0 tarballs have been generated and uploaded and the
GCC 11 branch is again open for regression and documentation fixes.
Quality Data
Priority # Change from last report
--- ---
P1
P2
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 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 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 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 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 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 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 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 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
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
The first release candidate for GCC 11.2 is available from
https://sourceware.org/pub/gcc/snapshots/11.2-RC-20210721/
and shortly its mirrors. It has been generated from git commit
076930b9690ac3564638636f6b13bbb6bc608aea.
I have so far bootstrapped and tested the release candidate
on x86_64-
Status
==
The GCC 11 branch is now frozen for the upcoming GCC 11.2 release.
All changes require release manager approval now.
Quality Data
Priority # Change from last report
--- ---
P1
P2 260 - 12
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 Thu, 15 Jul 2021, H.J. Lu wrote:
> On Tue, Jul 6, 2021 at 12:00 AM Richard Biener wrote:
> >
> >
> > Status
> > ==
> >
> > The GCC 11 branch is open for regression and documentation fixes.
> > It's time for a GCC 11.2 release and we a
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 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 Wed, 14 Jul 2021, H.J. Lu wrote:
> On Tue, Jul 6, 2021 at 12:00 AM Richard Biener wrote:
> >
> >
> > Status
> > ==
> >
> > The GCC 11 branch is open for regression and documentation fixes.
> > It's time for a GCC 11.2 release and we a
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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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; /
Status
==
The GCC 11 branch is open for regression and documentation fixes.
It's time for a GCC 11.2 release and we are aiming for a release
candidate in about two weeks which would result in the GCC 11.2
release about three months after GCC 11.1.
Two weeks give you ample time to care for i
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 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 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 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 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 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 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 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 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 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 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, 17 Jun 2021, Jakub Jelinek wrote:
> On Thu, Jun 17, 2021 at 03:21:05PM +0200, Richard Biener wrote:
> > but the difficulty is in the (const_int ..) operand to (vec_merge ..).
> > I've tried sth like
> >
> > (define_mode_attr addsub_cst [(V4DF "(co
I'm trying to merge
(define_insn "avx_addsubv4df3"
[(set (match_operand:V4DF 0 "register_operand" "=x")
(vec_merge:V4DF
(minus:V4DF
(match_operand:V4DF 1 "register_operand" "x")
(match_operand:V4DF 2 "nonimmediate_operand" "xm"))
(plus:V4DF (
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 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 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 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 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 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 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 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 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 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 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
The GNU Compiler Collection version 9.4 has been released.
GCC 9.4 is a bug-fix release from the GCC 9 branch containing important
fixes for regressions and serious bugs in GCC 9.3 with more than 190 bugs
fixed since the previous release.
This release is available from the WWW and FTP servers
Status
==
The GCC 9 branch is again open for regression and documentation fixes.
Quality Data
Priority # Change from last report
--- ---
P1
P2 304
P3 26 + 3
P4 173 -
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
A second release candidate for GCC 9.4 is available from
https://sourceware.org/pub/gcc/snapshots/9.4.0-RC-20210528/
and shortly its mirrors. It has been generated from git commit
ebfe8b28d40746ff33724bd5b9ade2552e619213, containing a build fix
with recent kernel headers and fixes for a few C+
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 Fri, 21 May 2021, Jason Merrill wrote:
> Sorry, just pushed 3 patches before I noticed this. They're safe but not
> critical, should I back them out?
They look safe indeed, so let's keep them in.
Richard.
> On Wed, May 19, 2021 at 4:06 AM Richard Biener wrote
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 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 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 Wed, 19 May 2021, Richard Biener wrote:
>
> The first release candidate for GCC 9.4 is available from
>
> https://sourceware.org/pub/gcc/snapshots/9.4.0-RC-20210519/
>
> and shortly its mirrors. It has been generated from git commit
> 8091c46cf736124a106922ddfd1fdb99
The first release candidate for GCC 9.4 is available from
https://sourceware.org/pub/gcc/snapshots/9.4.0-RC-20210519/
and shortly its mirrors. It has been generated from git commit
8091c46cf736124a106922ddfd1fdb99f33b0241.
I have so far bootstrapped and tested the release candidate
on {x86_64
Status
==
The GCC 9 branch is now frozen for the upcoming GCC 9.4 release.
I will announce a first release candidate shortly.
All changes require release manager approval now.
Quality Data
Priority # Change from last report
--- --
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 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 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 s
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,
> > >
> &g
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 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 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 Wed, 12 May 2021, Tamar Christina wrote:
>
>
> > -Original Message-
> > From: Richard Biener
> > Sent: Tuesday, May 11, 2021 12:45 PM
> > To: Tamar Christina
> > Cc: gcc@gcc.gnu.org; Richard Sandiford ;
> > Jakub Jelinek
> > Subject
; to introduce compiler-generated saturating operations.
>
> RTL already has per-operation saturation such as ss_plus/us_plus,
> ss_minus/us_minus, ss_neg/us_neg, ss_mult/us_mult, ss_div,
> ss_ashift/us_ashift and ss_abs. I think we should do the same
> in gimple, using internal
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 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 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, 11 May 2021, Tamar Christina wrote:
> Hi All,
>
> We are looking to implement saturation support in the compiler. The aim is to
> recognize both Scalar and Vector variant of typical saturating expressions.
>
> As an example:
>
> 1. Saturating addition:
>char sat (char a, char b)
>
On Thu, 6 May 2021, Prathamesh Kulkarni wrote:
> On Thu, 6 May 2021 at 15:43, Richard Biener wrote:
> >
> > On Thu, 6 May 2021, Prathamesh Kulkarni wrote:
> >
> > > Hi Richard,
> > > I was just wondering if second (and higher) order hoistings may defe
On Thu, 6 May 2021, Prathamesh Kulkarni wrote:
> Hi Richard,
> I was just wondering if second (and higher) order hoistings may defeat
> the "AVAIL_OUT in at least one successor heuristic" ?
>
> For eg:
> bb2:
> if (cond1) goto bb3 else goto bb4;
>
> bb3:
> if (cond2) goto bb5 else goto bb6;
>
>
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 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 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.
> > */
> >
401 - 500 of 2565 matches
Mail list logo
