On Tue, Oct 13, 2020 at 2:40 PM Erick Ochoa
wrote:
>
>
>
> On 13/10/2020 13:37, Richard Biener wrote:
> > On Tue, Oct 13, 2020 at 1:17 PM Erick Ochoa
> > wrote:
> >>
> >> Hi,
> >>
> >> I am analyzing gimple calls during LTO.
On Fri, Oct 16, 2020 at 9:59 PM Gary Oblock via Gcc wrote:
>
> I have a tiny program composed of a few functions
> and one of those functions (setupB) has gone missing.
> Since I need to walk its GIMPLE, this is a problem.
>
> The program:
>
> -- aux.h -
> #
s what we're talking about?),
but definitely the IL is unmodified in that state.
Maybe Martin has an idea.
Richard.
> Gary
>
>
>
>
> From: Richard Biener
> Sent: Sunday, October 18, 2020 11:28 PM
> To: Gary Oblock
> Cc: gcc@gcc.gn
On Tue, Oct 20, 2020 at 1:02 PM Martin Jambor wrote:
>
> Hi,
>
> On Tue, Oct 20 2020, Richard Biener wrote:
> > On Mon, Oct 19, 2020 at 7:52 PM Gary Oblock
> > wrote:
> >>
> >> Richard,
> >>
> >> I guess that will work for me. Howeve
IPA process you're experiencing the issue.
Richard.
> Am I missing something?
>
> Gary
> ________
> From: Jan Hubicka
> Sent: Tuesday, October 20, 2020 4:34 AM
> To: Richard Biener
> Cc: GCC Development ; Gary Oblock
> Subject: Re: Where did my function go?
>
> [EX
On Wed, Oct 21, 2020 at 12:04 PM Prathamesh Kulkarni
wrote:
>
> On Thu, 24 Sep 2020 at 16:44, Richard Biener
> wrote:
> >
> > On Thu, Sep 24, 2020 at 12:36 PM Prathamesh Kulkarni
> > wrote:
> > >
> > > On Wed, 23 Sep 2020 at 16:40, Richard Biener
On Fri, Oct 23, 2020 at 5:10 AM Gary Oblock via Gcc wrote:
>
> I'm finishing up coding my patterns for the structure reorganization
> optimization. They recognize certain instructions and replace them
> other instructions. I've got some code that generates gimple which is
> inserted as it's create
On October 23, 2020 7:49:04 PM GMT+02:00, "Nicolas König"
wrote:
>Hello everyone,
>
>I'm hoping to get shared coarrays for fortran (the devel/coarray_native
>branch) merged for GCC 11 as an experimental feature, but, since the
>library uses a lot of low-level routines, I'm a bit scared of breakin
On Sun, Oct 25, 2020 at 8:37 PM Stefan Kanthak wrote:
>
> Hi,
>
> for the AMD64 alias x86_64 platform and the __int128_t [DW]type,
> the first few lines of the __mulvDI3() function from libgcc2.c
>
> | DWtype
> | __mulvDI3 (DWtype u, DWtype v)
> | {
> | /* The unchecked multiplication needs 3 Wt
On Mon, Oct 26, 2020 at 10:59 AM Stefan Schulze Frielinghaus via Gcc
wrote:
>
> I'm trying to detect loops of the form
>
> while (*x != y)
> ++x;
>
> which mimic the behaviour of function rawmemchr. Note, the size of *x is not
> necessarily one byte. Thus ultimately I would like to detect
On Tue, Oct 27, 2020 at 12:01 AM Stefan Kanthak wrote:
>
> Richard Biener wrote:
>
> > On Sun, Oct 25, 2020 at 8:37 PM Stefan Kanthak
> > wrote:
> >>
> >> Hi,
> >>
> >> for the AMD64 alias x86_64 platform and the __int128_t [DW]type,
On Tue, Oct 27, 2020 at 7:36 PM Ilya Leoshkevich via Gcc
wrote:
>
> Hi,
>
> I'd like to revive the old discussion regarding the interaction of
> jump threading and b_c_p causing the latter to incorrectly return 1 in
> certain cases:
>
> https://gcc.gnu.org/pipermail/gcc-patches/2020-June/547236.ht
On Thu, Oct 29, 2020 at 6:20 PM Ilya Leoshkevich wrote:
>
> On Wed, 2020-10-28 at 12:18 +0100, Richard Biener wrote:
> > On Tue, Oct 27, 2020 at 7:36 PM Ilya Leoshkevich via Gcc
> > wrote:
> > > Hi,
> > >
> > > I'd like to revive the old
On Fri, Oct 30, 2020 at 6:44 PM Erick Ochoa
wrote:
>
> Hello again,
>
> I've been working on several implementations of data layout
> optimizations for GCC, and I am again kindly requesting for a review of
> the type escape based dead field elimination and field reorg.
>
> Thanks to everyone that
On Wed, Nov 4, 2020 at 7:33 PM Uros Bizjak via Gcc wrote:
>
> Hello!
>
> I was looking at the recent linux patch series [1] where segment
> qualifiers (named address spaces) were introduced to handle percpu
> variables. In the patch [2], the author mentions that:
>
> --q--
> Unfortunately, gcc doe
On Thu, Nov 5, 2020 at 9:56 AM Uros Bizjak wrote:
>
> On Thu, Nov 5, 2020 at 8:26 AM Richard Biener
> wrote:
> >
> > On Wed, Nov 4, 2020 at 7:33 PM Uros Bizjak via Gcc wrote:
> > >
> > > Hello!
> > >
> > > I was looking at the recent lin
On Thu, Nov 5, 2020 at 1:16 PM Alexander Monakov via Gcc
wrote:
>
>
>
> On Thu, 5 Nov 2020, Uros Bizjak wrote:
>
> > On Thu, Nov 5, 2020 at 12:38 PM Alexander Monakov
> > wrote:
> > >
> > > On Thu, 5 Nov 2020, Uros Bizjak via Gcc wrote:
> > >
> > > > > What is the usecase for stripping the addre
re
> made and how some criticisms may fail to really address the reason why
> these designs were made.
>
> On 03/11/2020 15:58, Richard Biener wrote:
> > On Fri, Oct 30, 2020 at 6:44 PM Erick Ochoa
> > wrote:
> >>
> >> Hello again,
> >>
> >> I&#x
On November 6, 2020 8:45:55 PM GMT+01:00, Jakub Jelinek via Gcc
wrote:
>On Tue, Nov 03, 2020 at 06:26:58PM +, Joseph Myers wrote:
>> On Mon, 2 Nov 2020, Jakub Jelinek via Gcc wrote:
>>
>> > It isn't that easy (because update_version_git checks the gcc trunk
>and
>> > so I had to insert a sh
On Sun, Nov 15, 2020 at 11:53 AM Uecker, Martin
wrote:
>
>
> > On Wed, Nov 04, 2020 at 07:31:42PM +0100, Uros Bizjak wrote:
> > > Hello!
> > >
> > > I was looking at the recent linux patch series [1] where segment
> > > qualifiers (named address spaces) were introduced to handle percpu
> > > varia
On Sat, Nov 21, 2020 at 1:21 AM m...@klomp.org wrote:
>
> On Fri, Nov 20, 2020 at 08:22:26PM +, Alexander Yermolovich wrote:
> > On llvm side of compiler world there has been work done by Igor Kudrin to
> > enable DWARF64.
> > I am trying to add a flag to Clang to enable DWARF64 generation.
On Mon, Nov 23, 2020 at 10:53 AM Marius Hillenbrand via Gcc
wrote:
>
> Hi,
>
> Digging into a test case failure with section anchors, I found
> dependence analysis return false negatives, leading to bad optimization
> by cse1. Two variables are synthetically constructed aliases. One is
> addressed
On Tue, Nov 24, 2020 at 8:45 AM Jakub Jelinek wrote:
>
> On Mon, Nov 23, 2020 at 06:38:16PM -0800, David Blaikie via Gcc wrote:
> > > I would pick -gdwarf32/-gdwarf64 (are we sure the DWARF spec will
> > > never reach version 32 or 64?
> > > maybe -g32 / -g64 similar to -m32/-m64 are good enough?)
On Tue, Nov 24, 2020 at 12:14 PM Marius Hillenbrand
wrote:
>
> On 11/23/20 12:04 PM, Richard Biener wrote:
> > On Mon, Nov 23, 2020 at 10:53 AM Marius Hillenbrand via Gcc
> > wrote:
> >>
> >> Hi,
> >>
> >> Digging into a test case failure
On Tue, Nov 24, 2020 at 3:20 PM Adhemerval Zanella via Gcc
wrote:
>
>
>
> On 24/11/2020 10:59, Siddhesh Poyarekar wrote:
> > On 11/24/20 7:11 PM, Szabolcs Nagy wrote:
> >> ideally fpclassify (and other classification macros) would
> >> handle all representations.
> >>
> >> architecturally invalid
On Tue, Nov 24, 2020 at 7:38 PM David Blaikie wrote:
>
> On Tue, Nov 24, 2020 at 3:11 AM Jakub Jelinek wrote:
> >
> > On Tue, Nov 24, 2020 at 12:04:45PM +0100, Mark Wielaard wrote:
> > > Hi,
> > >
> > > On Tue, 2020-11-24 at 08:50 +0100, Richard Biene
On Wed, Nov 25, 2020 at 8:15 AM Marc Glisse wrote:
>
> On Wed, 25 Nov 2020, Ilya Leoshkevich via Gcc wrote:
>
> > I have a C floating point comparison (a <= b && a >= b), which
> > test_for_singularity turns into (a <= b && a == b) and vectorizer turns
> > into ((a <= b) & (a == b)). So far so go
On Fri, Nov 27, 2020 at 3:48 AM Liu Hao via Gcc wrote:
>
> 在 2020/11/27 上午7:50, Jonathan Wakely via Gcc 写道:
> > I've touched on the subject a few times, e.g.
> > https://gcc.gnu.org/pipermail/gcc/2019-December/230993.html
> > and https://gcc.gnu.org/pipermail/gcc/2019-December/231013.html
> >
> >
On Thu, Dec 3, 2020 at 6:52 PM David Blaikie wrote:
>
>
> On Wed, Dec 2, 2020 at 5:10 PM Alexander Yermolovich
> wrote:
>
>>
>>
>> --
>> *From:* David Blaikie
>> *Sent:* Wednesday, December 2, 2020 1:12 PM
>> *
On Fri, Dec 4, 2020 at 7:01 PM Alexander Yermolovich
wrote:
>
>
> --
> *From:* Richard Biener
> *Sent:* Friday, December 4, 2020 12:36 AM
> *To:* David Blaikie
> *Cc:* Alexander Yermolovich ; Jakub Jelinek <
> ja...@redhat.com>; M
On Sat, Dec 5, 2020 at 1:55 AM Martin Sebor via Gcc wrote:
>
> On 12/4/20 4:33 PM, Martin Sebor wrote:
> > I'm looking for a way to get the FUNCTION_DECL for the library
> > (i.e., non-built-in) form of a function given the corresponding
> > built-in DECL. Is there an API I can all with either th
On Tue, Dec 8, 2020 at 2:08 AM Jim Wilson wrote:
>
> I'm not aware of any other target that has a similar feature, so I thought
> a bit of discussion first might be useful.
>
> For most ISAs, there is one organization that owns it, and does development
> internally, in private. For RISC-V, the IS
On Thu, Dec 10, 2020 at 9:47 AM Xionghu Luo via Gcc wrote:
>
> Hi,
>
> I have a maybe silly question about whether there is any *standard*
> or *options* (like -ffast-math) for GCC that allow double to float
> demotion optimization? For example,
The only option we have to this effect would be -f
On Fri, Dec 11, 2020 at 7:26 AM Xionghu Luo wrote:
>
> Thanks,
>
> On 2020/12/10 17:12, Richard Biener wrote:
> >> 2) From PR90070:
> >>
> >>double temp1 = (double)r->red;
> >>double temp2 = (double)aggregate.red;
> >>doub
On Fri, Dec 11, 2020 at 10:44 AM Xionghu Luo wrote:
>
>
> On 2020/12/11 15:47, Richard Biener wrote:
> >> Note that the add/sub sequence is different for (3) and (4) since
> >> -funsafe-math-optimizations is implicitly true. "fp-contract=fast" in
> >&
On December 29, 2020 6:42:30 PM GMT+01:00, Marc Glisse
wrote:
>On Tue, 29 Dec 2020, Richard Sandiford via Gcc wrote:
>
>> Any thoughts on what f should return in the following testcase, given
>the
>> usual GNU behaviour of treating signed >> as arithmetic shift right?
>>
>>typedef int vs4 __a
On Tue, Dec 29, 2020 at 8:19 PM Alexander Monakov wrote:
>
> On Tue, 29 Dec 2020, Richard Biener via Gcc wrote:
>
> > >I think clang follows gcc and uses the type of the first operand.
> >
> > The desired behavior is the one that OpenCL specifies. If it is
>
On Fri, Jan 1, 2021 at 10:16 PM Gary Oblock via Gcc wrote:
>
> The offsets seem to actually be created. However,
> they are almost immediately are being deleted.
Use a watchpoint to see where.
> Any ideas what's going on? Has some kind
> of memory management gizmo gone awry?
>
> Gary
>
> PS For
On Thu, Jan 7, 2021 at 10:41 PM Martin Sebor wrote:
>
> The test case in PR 98465 brings to light a problem we've discussed
> before (e.g., PR 93971) where a standard container (std::string in
> this case but the problem applies to any class that owns and manages
> allocated memory) might trigger
On Fri, Jan 8, 2021 at 9:16 PM Martin Sebor wrote:
>
> On 1/8/21 12:51 AM, Richard Biener wrote:
> > On Thu, Jan 7, 2021 at 10:41 PM Martin Sebor wrote:
> >>
> >> The test case in PR 98465 brings to light a problem we've discussed
> >> before (e.g
On Sat, Jan 9, 2021 at 12:24 AM Tucker Kern via Gcc wrote:
>
> Hi,
>
> I'm implementing named addresses spaces for a Harvard architecture machine
> to support copying data from instruction memory to data memory. This is
> achieved via a special instruction. e.g. think AVR and progmem/__flash.
>
>
On Mon, Jan 11, 2021 at 4:09 PM Martin Jambor wrote:
>
> Hello,
>
> there have already been some inquiries from prospective students and so
> I would like to start preparing for the next year of Google Summer of
> Code now. I'll be happy to volunteer to be the main Org Admin for GCC
> again - so
from expand_expr_real_*
so I don't
see a good way to handle this correctly. But maybe Joseph has an idea.
Richard.
> On Mon, Jan 11, 2021 at 12:50 AM Richard Biener
> wrote:
>>
>> On Sat, Jan 9, 2021 at 12:24 AM Tucker Kern via Gcc wrote:
>> >
>> >
On January 17, 2021 2:23:55 AM GMT+01:00, JiangNing OS via Gcc
wrote:
>> -Original Message-
>> From: Feng Xue OS
>> Sent: Thursday, January 14, 2021 12:28 PM
>> To: gcc@gcc.gnu.org
>> Cc: JiangNing OS ; Hao Liu OS
>>
>> Subject: [RFC] A memory gathering optimization for loop
>>
>> 1. B
On Tue, Jan 19, 2021 at 9:04 PM unlvsur unlvsur via Gcc wrote:
>
> That is not for inline. That is to allow implementing memcpy without
> introducing any libc runtime which allows us to use it in freestanding
> environment.
Note that GCC requires memcpy, memmove, memset and memcmp to exist even
On Thu, Jan 21, 2021 at 3:31 PM Alan Lehotsky wrote:
>
> I’m working on performance tuning a gcc 8.3 port and wanted to turn off SRA
> for an experiment. But passing both
>
> -fno-tree-sra
> -fno-ipa-sra
>
> but it’s still tagging compiled functions with a “_isra” suffix, which would
On Mon, Feb 8, 2021 at 4:26 AM Naoki Shibata via Gcc wrote:
>
>
> Hello,
>
> I have a question as to the auto-vectorizer in GCC.
>
> When AVX512 instruction is available, the auto-vectorizer in gcc
> sometimes generates calls to AVX2 functions instead of AVX512 functions.
>
>
> $ cat vabitest.c
>
On February 13, 2021 12:20:48 AM GMT+01:00, Marc Glisse
wrote:
>On Fri, 12 Feb 2021, Andrew MacLeod via Gcc wrote:
>
>> I dont't want to immediately open a PR, so I'll just ask about
>> testsuite/gcc.dg/pr83609.c.
>>
>> the compilation string is
>> -O2 -fno-tree-forwprop -fno-tree-ccp -fno-t
On Tue, Feb 23, 2021 at 1:12 AM Gary Oblock via Gcc wrote:
>
> I'm having a "linker" error (according to Martin Liška) when
> compiling a SPEC test (x264_r) with a vendor branch under development (my
> optimization is done at LTO time.)
>
> The binutils on my development machine is the version
>
On March 14, 2021 6:55:32 AM GMT+01:00, Paul Edwards via Gcc
wrote:
>If I have code like this:
>
>char foo(char *p)
>{
>return (p[-1]);
>}
>
>It generates a negative index, like this:
>
>* Function foo code
> L 2,=F'-1'
> L 3,0(11)
> SLR 15,15
> IC
ctually take effect, and go up into the 4 GiB to 8 GiB
>region.
And that's exactly what I said. Pmode is DImode but ptr_mode is SImode.
>
>Is your answer still applicable (I don't really understand
>your answer. :-) ).
>
>Thanks. Paul.
>
>
>
>
>-Orig
es and maybe not set up
to deal with 64bit address registers at all.
> Thanks. Paul.
>
>
>
>
> -Original Message-
> From: Richard Biener
> Sent: Monday, March 15, 2021 12:37 AM
> To: Paul Edwards ; gcc@gcc.gnu.org
> Subject: Re: negative indexes
>
>
On March 15, 2021 7:31:46 PM GMT+01:00, Thomas Schwinge
wrote:
>Hi!
>
>First time I'm using this API -- so the error certainly may be on my
>side. ;-)
>
>What I'm doing, is a 'walk_gimple_seq', and in that one's
>'callback_stmt', call 'walk_stmt_load_store_addr_ops', to collect
>variable load/st
On Tue, Mar 16, 2021 at 1:16 PM Erick Ochoa via Gcc wrote:
>
> Hello,
>
> I'm currently working on improving my understanding of the implementation
> of the intraprocedural points-to analysis in GCC. I have already read the
> papers by Daniel Berlin and have been looking at the source for some tim
On Tue, Mar 16, 2021 at 4:02 PM Thomas Schwinge wrote:
>
> Hi!
>
> Richard, thanks for your answer. I'll need to look into this more; two
> questions already:
>
> On 2021-03-15T20:17:17+0100, Richard Biener via Gcc wrote:
> > On March 15, 2021 7:31:46 PM GMT+01
On Tue, Mar 16, 2021 at 4:25 PM Michael Matz wrote:
>
> 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
> > >>expect
On Wed, Mar 17, 2021 at 12:25 AM Thomas Schwinge
wrote:
>
> Hi!
>
> Thanks, Michael, and again Richard for your quick responses.
>
> On 2021-03-16T15:25:10+, Michael Matz wrote:
> > On Tue, 16 Mar 2021, Thomas Schwinge wrote:
> >
> >> >>Indeed, given (Fortran) 'zzz = 1', we produce GIMPLE:
>
On Wed, Mar 17, 2021 at 11:34 AM Erick Ochoa via Gcc wrote:
>
> Hello,
>
> I'm still trying to compare the solution generated from the
> intraprocedural points-to analysis in GCC against an external solver.
>
> Yesterday it was pointed out that "NULL is not conservatively
> correctly represented i
On Wed, Mar 17, 2021 at 4:17 PM Erick Ochoa wrote:
>
> Hi Richard, I think I misunderstood yesterday's answer and deviated a
> little bit. But now I want to focus on this:
>
> > > * the process in GCC that generates the constraints for NULL works
> > > fine (i.e., feeding the constraints generated
:
>
> computed for foo:
>
> ```
> ANYTHING = { ANYTHING }
> ESCAPED = { NULL }
> NONLOCAL = { ESCAPED NONLOCAL }
> STOREDANYTHING = { }
> INTEGER = { ANYTHING }
> ISRA.4 = { NONLOCAL }
> derefaddrtmp(9) = { NULL }
> foo.constprop.0.isra.0 = { }
> ```
>
>
On Mon, Mar 22, 2021 at 7:41 AM guojiufu via Gcc wrote:
>
> Hi All,
>
> As we know, type conversion is not in favor of optimization, and may
> cause performance issue.
>
> For example:
> for (unsigned int i = 0; i < n; ++i)
>a[m + i] = 1; //or a[30 + i] =
>
> In this code, the index to a
On Tue, Mar 23, 2021 at 4:33 AM guojiufu wrote:
>
> On 2021-03-22 16:31, Jakub Jelinek via Gcc wrote:
> > On Mon, Mar 22, 2021 at 09:22:26AM +0100, Richard Biener via Gcc wrote:
> >> Better than doing loop versioning is to enhance SCEV (and thus also
> >> depen
On Wed, Mar 24, 2021 at 3:55 AM guojiufu wrote:
>
> On 2021-03-23 16:25, Richard Biener via Gcc wrote:
> > On Tue, Mar 23, 2021 at 4:33 AM guojiufu
> > wrote:
> >>
> >> On 2021-03-22 16:31, Jakub Jelinek via Gcc wrote:
> >> > On Mon, Mar 22, 2021 a
On Fri, Mar 26, 2021 at 9:03 PM Nathan Sidwell wrote:
>
> [double sigh, attaching a pdf causes it to be blocked, and I guess the number
> of
> URLs is also triggering a spam trap for the follow up. I have removed many of
> the URLS from this, you'll have to use your google-fu for sources. I ema
On Tue, Mar 30, 2021 at 10:52 AM Erick Ochoa via Gcc wrote:
>
> Hi,
>
> I am looking at the points-to analysis in GCC and I found the
> following comment in tree-ssa-structalias.c:
>
> /* Collect field information. */
> if (use_field_sensitive
> && var_can_have_subvars (decl)
> /*
On Tue, Mar 30, 2021 at 1:39 PM Erick Ochoa wrote:
>
> > If the global is module local we should initialize it with NULL, yes. If
> > it is
> > not module local it should be initialized with NONLOCAL (that's both what
> > should currently happen correctly - it's needed for non-field-sensitive in
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 s
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
&g
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,
> > >
> &g
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 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
2001 - 2100 of 2622 matches
Mail list logo
