On Mon, Jun 24, 2019 at 2:12 PM Martin Liška wrote:
>
> On 6/24/19 2:02 PM, Richard Biener wrote:
> > On Fri, Jun 21, 2019 at 4:01 PM Martin Liška wrote:
> >>
> >> On 6/21/19 2:57 PM, Jan Hubicka wrote:
> >>> This looks like good step (and please s
On Fri, Jun 21, 2019 at 7:17 PM Martin Sebor wrote:
>
> On 6/21/19 6:06 AM, Richard Biener wrote:
> > On Wed, Jun 19, 2019 at 5:15 AM Martin Sebor wrote:
> >>
> >> Bug 90923 shows that even though GCC hash-table based containers
> >> like hash_map can be
On Fri, Jun 21, 2019 at 4:01 PM Martin Liška wrote:
>
> On 6/21/19 2:57 PM, Jan Hubicka wrote:
> > This looks like good step (and please stream it in host independent
> > way). I suppose all these issues can be done one-by-one.
>
> So there's a working patch for that. However one will see followin
On Fri, Jun 21, 2019 at 4:13 PM Jakub Jelinek wrote:
>
> On Fri, Jun 21, 2019 at 04:04:00PM +0200, Martin Liška wrote:
> > On 6/21/19 1:58 PM, Jakub Jelinek wrote:
> > > On Fri, Jun 21, 2019 at 01:52:09PM +0200, Martin Liška wrote:
> > >> On 6/21/19 1:47 PM, Jonathan Wakely wrote:
> > >>> On Fri,
On Fri, 21 Jun 2019 at 11:22, Martin Liška wrote:
> >>>>
> >>>> On 6/20/19 9:53 PM, Richard Biener wrote:
> >>>>> On June 20, 2019 5:09:55 PM GMT+02:00, "Martin Liška"
> >>>>> wrote:
> >>>>>> On
On Fri, Jun 21, 2019 at 12:20 PM Martin Liška wrote:
>
> Hi.
>
> The patch is about a new ELF section that will contain information
> about LTO version. And for the future, used compression will be stored
> here. The patch removes streaming of the version into each section.
I'd like each section
On Wed, Jun 19, 2019 at 5:15 AM Martin Sebor wrote:
>
> Bug 90923 shows that even though GCC hash-table based containers
> like hash_map can be instantiated on types with user-defined ctors
> and dtors they invoke the dtors of such types without invoking
> the corresponding ctors.
>
> It was thank
On June 20, 2019 5:09:55 PM GMT+02:00, "Martin Liška" wrote:
>On 6/20/19 4:21 PM, David Edelsohn wrote:
>> On Thu, Jun 20, 2019 at 10:05 AM Martin Liška wrote:
>>>
>>> Hi.
>>>
>>> In order to not buffer stderr output in LTO mode, I would like to
>remove
>>> support for repo files (tlink). If I'm
On June 19, 2019 6:03:21 PM GMT+02:00, Jeff Law wrote:
>On 6/19/19 3:21 AM, Martin Liška wrote:
>> Hi.
>>
>> I've written a patch draft that replaces zlib with the zstd
>compression algorithm ([1])
>> in LTO. I'm also sending statistics that are collected for couple of
>quite big C++ source
>> fi
On Mon, Jun 17, 2019 at 5:02 PM wrote:
>
> > From: Richard Biener
> > Sent: Monday, June 17, 2019 9:57 AM
> > To: taylor, david
> > Cc: GCC Development
> > Subject: Re: gcc: -ftest-coverage and -auxbase
>
> > On Mon, Jun 17, 2019 at 2:46 PM David Tayl
gcc dot gnu dot org. Hopefully I didn't screw up the editing.
>
> From: Richard Biener
> Date: Thu, 13 Jun 2019 10:22:54 +0200
>
>
>
> On Wed, Jun 12, 2019 at 10:17 PM wrote:
> >
&
On Thu, 13 Jun 2019, Jim Wilson wrote:
> On Thu, Jun 13, 2019 at 10:39 AM Joel Sherrill
> wrote:
> > Ok with me if no one steps up and the downstream projects like Debian gets
> > notice. This is just a reflection of this architecture's status in the
> > world.
>
> I sent email to the debian-ia
ia64 has no maintainer anymore so the following deprecates it
with the goal of eliminating the port for GCC 11 if no maintainer
steps up.
OK?
Thanks,
Richard.
2019-06-13 Richard Biener
* config.gcc: Mark ia64*-*-* targets as deprecated/obsolete.
Index: gcc/config.gcc
On Wed, Jun 12, 2019 at 10:17 PM wrote:
>
> When doing a build, we use a pipe between GCC and GAS.
> And because we wish to do some analysis of the assembly code,
> we do not use -pipe but instead do '-S -c -'. And this has worked
> fine for many years.
Can you please show us complete command-li
On Wed, Jun 12, 2019 at 5:22 AM Li Jia He wrote:
>
> Hi,
>
> I recently did some analysis on the automatic vectorization of gcc, I
> found that singed char can not be vectorized in the following code.
>
> ---
> #define ITERATIONS 100
>
> #if defined(do_reduce_signed_char)
> #define TYPE signed
On Fri, Jun 7, 2019 at 4:54 PM Andrew MacLeod wrote:
>
> On 6/7/19 8:25 AM, Richard Biener wrote:
> > On Wed, Jun 5, 2019 at 10:56 PM Andrew MacLeod wrote:
> >> After the various discussions, I've evaluated how I think everything can
> >> fit together, so this
On Wed, Jun 5, 2019 at 10:56 PM Andrew MacLeod wrote:
>
> After the various discussions, I've evaluated how I think everything can
> fit together, so this is my proposal for integration with trunk.
>
>
> The complete Ranger prototype consists of 5 major components, one of
> which is missing/un-im
On Wed, Jun 5, 2019 at 3:26 PM Jozef Lawrynowicz wrote:
>
> The MSP430 target in the large memory model uses the (non-ISO) __int20 type
> for
> SIZE_TYPE and PTRDIFF_TYPE.
> The preprocessor therefore expands a builtin such as __SIZE_TYPE__ to
> "__int20 unsigned" in user code.
> When compiling w
On Wed, Jun 5, 2019 at 6:32 PM Farid Parpia wrote:
>
>
> Greetings,
>
> It appears that the given sha512 sum for gcc-7.4.0.tar.gz may be incorrect
> on at least the following mirrors:
>http://mirrors.concertpass.com/
>http://www.netgull.com/
>https://bigsearcher.com/
It's incorrect on
On Tue, Jun 4, 2019 at 9:55 PM Andrew MacLeod wrote:>
> On 6/4/19 1:07 PM, Richard Biener wrote:
> > On June 4, 2019 6:50:07 PM GMT+02:00, Andrew MacLeod
> > wrote:
> >> On 6/4/19 11:37 AM, Richard Biener wrote:
> >>
> >>> where the sing
On June 4, 2019 6:50:07 PM GMT+02:00, Andrew MacLeod
wrote:
>On 6/4/19 11:37 AM, Richard Biener wrote:
>> On Tue, Jun 4, 2019 at 5:26 PM Richard Biener
>> wrote:
>>>
>>> But you still have a reference to the range in evry BB dominated by
>the
>&
On Tue, Jun 4, 2019 at 5:26 PM Richard Biener
wrote:
>
> On Fri, May 31, 2019 at 5:40 PM Andrew MacLeod wrote:
> >
> > On 5/29/19 7:15 AM, Richard Biener wrote:
> > > On Tue, May 28, 2019 at 4:17 PM Andrew MacLeod
> > > wrote:
> > >> On 5/27/
On Fri, May 31, 2019 at 5:40 PM Andrew MacLeod wrote:
>
> On 5/29/19 7:15 AM, Richard Biener wrote:
> > On Tue, May 28, 2019 at 4:17 PM Andrew MacLeod wrote:
> >> On 5/27/19 9:02 AM, Richard Biener wrote:
> >>> On Fri, May 24, 2019 at 5:50 PM Andrew MacLeod
eate
and assemble it, see how tree-profile.c uses build_decl.
Richard.
> Thanks,
> Arslan
>
> On Wed, May 29, 2019 at 3:17 AM Richard Biener
> wrote:
> >
> > On Tue, May 28, 2019 at 1:01 AM Arslan Khan wrote:
> > >
> > > Hi,
> > > I am a beginner to
On Tue, May 28, 2019 at 4:41 PM Jeff Law wrote:
>
> On 5/23/19 7:10 AM, Richard Biener wrote:
> > On Thu, May 23, 2019 at 3:29 AM Andrew MacLeod wrote:
> >>
> >> There is a functioning prototype in branch “ssa-range” which is a proof
> >> of concept tha
On Tue, May 28, 2019 at 4:17 PM Andrew MacLeod wrote:
>
> On 5/27/19 9:02 AM, Richard Biener wrote:
> > On Fri, May 24, 2019 at 5:50 PM Andrew MacLeod wrote:
> >>
> >>> The above suggests that iff this is done at all it is not in GORI because
> >>> t
On Tue, May 28, 2019 at 1:01 AM Arslan Khan wrote:
>
> Hi,
> I am a beginner to GCC and am trying to implement safe stack using a
> GCC Plugin for embedded systems. I am using a cross compiler, with GCC
> version:
>
> arm-none-eabi-gcc (GNU Tools for ARM Embedded Processors
> 6-2018-q4-major) 6.3.
On Fri, May 24, 2019 at 5:51 PM Andrew MacLeod wrote:
>
> On 5/23/19 10:07 AM, Richard Biener wrote:
> > On Thu, May 23, 2019 at 3:30 AM Andrew MacLeod wrote:
> >>
> >> This aspect of all calculations being driven from the opcode and
> >> combined generica
On Fri, May 24, 2019 at 5:50 PM Andrew MacLeod wrote:
>
> On 5/23/19 8:55 AM, Richard Biener wrote:
> > On Thu, May 23, 2019 at 3:28 AM Andrew MacLeod wrote:
> >>
> >> 2 * GORI
> >>
> >> The second component is the “Generates Outgoin
On May 25, 2019 2:52:53 PM GMT+02:00, Thomas Koenig
wrote:
>Hi,
>
>consider this: There is a bug, confirmed by several people. This occurs
>in closed-source, proprietary software, and appears to be due to one
>of my commits.
>
>Despite considerable help from somebody who has access to the source,
On Fri, May 24, 2019 at 12:27 AM Eric Botcazou wrote:
>
> > While I agree that symbolic ranges are a complication and that most
> > cases it currently handles are not "value-range" things I do not agree
> > with the idea that we can simply remove handling them and deal
> > with the fallout in some
On Thu, May 23, 2019 at 3:30 AM Andrew MacLeod wrote:
>
> A primary goal of this approach is to try to pull the various aspects of
> VRP apart and make them individually viable so they can be used at
> appropriate places as needed. The various components of VRP were
> identified as:
> - Rang
On Thu, May 23, 2019 at 3:29 AM Andrew MacLeod wrote:
>
> We have done extensive performance analysis to help address concerns
> about the nature of an on-demand model. LLVM made an attempt at
> something similar, but suffered from significant performance issues
> they could not solve with their
On Thu, May 23, 2019 at 3:29 AM Andrew MacLeod wrote:
>
> There is a functioning prototype in branch “ssa-range” which is a proof
> of concept that the approach is functional as well as quick, and can be
> used to answer questions which come up regarding what it can and can’t
> do. Our last merge
On Thu, May 23, 2019 at 3:28 AM Andrew MacLeod wrote:
>
> *This note will talk about the 4 major components of the prototype and
> explain how they work together. I will be fairly light on detail just
> to give an overview, we can delve into whatever details are needed.
> - Range-ops : Range ope
On Wed, May 22, 2019 at 10:36 AM Martin Reinecke
wrote:
>
> Hi Matthias!
>
> > I agree, we need more information from the compiler. Esp. whether the user
> > specified `-mprefer-avx128` or `-mprefer-vector-width=none/128/256/512`.
> > OTOH `-msve-vector-bits=N` is reported as __ARM_FEATURE_SVE_BIT
On Tue, May 14, 2019 at 9:21 PM Aaron Sawdey wrote:
>
> GCC does not currently do inline expansion of overlapping memmove, nor does it
> have an expansion pattern to allow for non-overlapping memcpy, so I plan to
> add
> patterns and support to implement this in gcc 10 timeframe.
>
> At present m
On Sun, 12 May 2019, Giuliano Belinassi wrote:
> Hi, Richard
>
> On 05/07, Richard Biener wrote:
> > On Mon, 6 May 2019, Giuliano Belinassi wrote:
> >
> > > Hi,
> > >
> > > On 03/29, Richard Biener wrote:
> > > > On Thu, 28 Mar 20
On Mon, 6 May 2019, Giuliano Belinassi wrote:
> Hi,
>
> On 03/29, Richard Biener wrote:
> > On Thu, 28 Mar 2019, Giuliano Belinassi wrote:
> >
> > > Hi, Richard
> > >
> > > On 03/28, Richard Biener wrote:
> > > > On We
On Sun, May 5, 2019 at 11:09 PM Eric Botcazou wrote:
>
> > I have now applied this variant.
>
> You backported it onto the 8 branch on Friday:
>
> 2019-05-03 Richard Biener
>
> Backport from mainline
> [...]
> 2019-03-07 Richard Biener
>
On Thu, May 2, 2019 at 6:16 PM Segher Boessenkool
wrote:
>
> On Thu, May 02, 2019 at 02:17:51PM +0200, Richard Biener wrote:
> > On Tue, Apr 30, 2019 at 9:53 PM Jeff Law wrote:
> > > This is loop unswitching. It's a standard GCC optimization. If it's
> &g
On Tue, Apr 30, 2019 at 9:53 PM Jeff Law wrote:
>
> On 4/30/19 12:34 PM, cmdLP #CODE wrote:
> > Hello GCC-team,
> >
> > I use GCC for all my C and C++ programs. I know how to use GCC, but I am
> > not a contributor to GCC (yet). I often discover some problems C and C++
> > code have in general. Th
On Thu, Apr 25, 2019 at 3:03 PM Peter Sewell wrote:
>
> On 25/04/2019, Richard Biener wrote:
> > On Wed, Apr 24, 2019 at 11:18 PM Peter Sewell
> > wrote:
> >>
> >> On 24/04/2019, Jeff Law wrote:
> >> > On 4/24/19 4:19 AM, Richard Biener wrote:
On Wed, Apr 24, 2019 at 11:18 PM Peter Sewell wrote:
>
> On 24/04/2019, Jeff Law wrote:
> > On 4/24/19 4:19 AM, Richard Biener wrote:
> >> On Thu, Apr 18, 2019 at 3:42 PM Jeff Law wrote:
> >>>
> >>> On 4/18/19 6:20 AM, Uecker, Martin wrote:
>
On Wed, Apr 24, 2019 at 8:41 PM Jeff Law wrote:
>
> On 4/24/19 4:19 AM, Richard Biener wrote:
> > On Thu, Apr 18, 2019 at 3:42 PM Jeff Law wrote:
> >>
> >> On 4/18/19 6:20 AM, Uecker, Martin wrote:
> >>> Am Donnerstag, den 18.04.2019, 11:45 +0100 schrie
On Fri, Apr 19, 2019 at 11:09 AM Jens Gustedt wrote:
>
> Hello Jakub,
>
> On Fri, 19 Apr 2019 10:49:08 +0200 Jakub Jelinek
> wrote:
>
> > On Fri, Apr 19, 2019 at 10:19:28AM +0200, Jens Gustedt wrote:
> > > > OTOH GCC transforms
> > > > (uintptr_t)&a != (uintptr_t)(&b+1)
> > > > into &a != &b + 1
On Thu, Apr 18, 2019 at 3:42 PM Jeff Law wrote:
>
> On 4/18/19 6:20 AM, Uecker, Martin wrote:
> > Am Donnerstag, den 18.04.2019, 11:45 +0100 schrieb Peter Sewell:
> >> On Thu, 18 Apr 2019 at 10:32, Richard Biener
> >> wrote:
> >
> >
> >>
On Thu, Apr 18, 2019 at 3:29 PM Jeff Law wrote:
>
> On 4/18/19 6:50 AM, Jakub Jelinek wrote:
> > On Thu, Apr 18, 2019 at 02:47:18PM +0200, Jakub Jelinek wrote:
> >> On Thu, Apr 18, 2019 at 02:42:22PM +0200, Richard Biener wrote:
> >>>> 1.) Compilers do
On Thu, Apr 18, 2019 at 2:20 PM Uecker, Martin
wrote:
>
> Am Donnerstag, den 18.04.2019, 11:45 +0100 schrieb Peter Sewell:
> > On Thu, 18 Apr 2019 at 10:32, Richard Biener
> > wrote:
>
>
> > An equality test of two pointers, on the other hand, doesn't
On Thu, Apr 18, 2019 at 1:57 PM Uecker, Martin
wrote:
>
> Am Donnerstag, den 18.04.2019, 11:56 +0200 schrieb Richard Biener:
> > On Thu, Apr 18, 2019 at 11:31 AM Richard Biener
> > wrote:
> > >
> > > On Wed, Apr 17, 2019 at 4:12 PM Uecker, Martin
> >
On Thu, Apr 18, 2019 at 11:31 AM Richard Biener
wrote:
>
> On Wed, Apr 17, 2019 at 4:12 PM Uecker, Martin
> wrote:
> >
> > Am Mittwoch, den 17.04.2019, 15:34 +0200 schrieb Richard Biener:
> > > On Wed, Apr 17, 2019 at 2:56 PM Uecker, Martin
> > >
On Wed, Apr 17, 2019 at 4:12 PM Uecker, Martin
wrote:
>
> Am Mittwoch, den 17.04.2019, 15:34 +0200 schrieb Richard Biener:
> > On Wed, Apr 17, 2019 at 2:56 PM Uecker, Martin
> > wrote:
> > >
> > > Am Mittwoch, den 17.04.2019, 14:41 +0200 schrieb Richard Biene
On Wed, Apr 17, 2019 at 2:56 PM Uecker, Martin
wrote:
>
> Am Mittwoch, den 17.04.2019, 14:41 +0200 schrieb Richard Biener:
> > On Wed, Apr 17, 2019 at 1:53 PM Uecker, Martin
> > wrote:
>
> > >
> > > > Since
> > > > your proposal is based on
On Wed, Apr 17, 2019 at 1:53 PM Uecker, Martin
wrote:
>
>
> Hi Richard,
>
> Am Mittwoch, den 17.04.2019, 11:41 +0200 schrieb Richard Biener:
> > On Wed, Apr 17, 2019 at 11:15 AM Peter Sewell
> > wrote:
> > >
> > > On 17/04/2019, Richard Biener w
On Wed, Apr 17, 2019 at 11:15 AM Peter Sewell wrote:
>
> On 17/04/2019, Richard Biener wrote:
> > On Fri, Apr 12, 2019 at 5:31 PM Peter Sewell
> > wrote:
> >>
> >> On Fri, 12 Apr 2019 at 15:51, Jeff Law wrote:
> >> >
> >> &
On Fri, Apr 12, 2019 at 5:31 PM Peter Sewell wrote:
>
> On Fri, 12 Apr 2019 at 15:51, Jeff Law wrote:
> >
> > On 4/2/19 2:11 AM, Peter Sewell wrote:
> > > Dear all,
> > >
> > > continuing the discussion from the 2018 GNU Tools Cauldron, we
> > > (the WG14 C memory object model study group) now
>
On Tue, Apr 16, 2019 at 1:39 PM Jakub Jelinek wrote:
>
> On Tue, Apr 16, 2019 at 01:25:38PM +0200, Richard Biener wrote:
> > So for the parser it's small differences that accumulate, for example
> > a lot more comptype calls via null_ptr_cst_p (via c
On Tue, Apr 16, 2019 at 11:56 AM Richard Biener
wrote:
>
> On Tue, Apr 16, 2019 at 10:53 AM Michael Matz wrote:
> >
> > Hello Martin,
> >
> > On Tue, 16 Apr 2019, Martin Liška wrote:
> >
> > > Yes, except kdecore.cc I used in all cases .ii pre-pr
On Tue, Apr 16, 2019 at 10:53 AM Michael Matz wrote:
>
> Hello Martin,
>
> On Tue, 16 Apr 2019, Martin Liška wrote:
>
> > Yes, except kdecore.cc I used in all cases .ii pre-processed files. I'm
> > going to start using kdecore.ii as well.
>
> If the kdecore.cc is the one from me it's also preproce
On Mon, 8 Apr 2019, nick wrote:
>
>
> On 2019-04-08 3:29 a.m., Richard Biener wrote:
> > On Sun, 7 Apr 2019, nick wrote:
> >
> >>
> >>
> >> On 2019-04-07 5:31 a.m., Richard Biener wrote:
> >>> On April 5, 2019 6:11:15 PM GMT+02:
On Mon, Apr 8, 2019 at 2:31 PM Michael Matz wrote:
>
> Hi,
>
> On Mon, 8 Apr 2019, Richard Biener wrote:
>
> > Not sure if in this case we run into an RTL optimization that breaks things
> > (PRE / scheduling / invariant motion are candidates).
>
> That's
On Mon, Apr 8, 2019 at 11:33 AM Richard Biener
wrote:
>
> On Mon, Apr 8, 2019 at 10:38 AM Andrew Haley wrote:
> >
> > On 4/7/19 5:03 PM, Thomas Koenig wrote:
> > > Hi Richard,
> > >
> > >> I don't know without looking, but I'd start at
On Mon, Apr 8, 2019 at 10:38 AM Andrew Haley wrote:
>
> On 4/7/19 5:03 PM, Thomas Koenig wrote:
> > Hi Richard,
> >
> >> I don't know without looking, but I'd start at assemble_variable in
> >> varasm.c.
> >
> > Thanks. I've done that, and this is what a patch could look like.
> > However, I wil
On Sun, Apr 7, 2019 at 11:10 AM ashwina kumar wrote:
>
> Hi ,
>
> While working I just figured out that -Wconversion is buggy. Please see the
> below code- -
>
> $ cat b.c
> #include
>
> void main (void)
> {
> //contains build errors
> uint16_t x = 1;
> uint16_t y = 2;
>
On Sat, Apr 6, 2019 at 1:09 AM Martin Sebor wrote:
>
> On 4/5/19 4:02 PM, Jeff Law wrote:
> > On 4/5/19 3:37 PM, Martin Sebor wrote:
> >> On 4/5/19 3:29 PM, Jeff Law wrote:
> >>> On 4/5/19 2:50 PM, Eric Botcazou wrote:
> > Say if the first bootstrap succeeds and I then change a single
> >
On Fri, Apr 5, 2019 at 6:25 PM Michael Matz wrote:
>
> Hello,
>
> On Fri, 5 Apr 2019, Jozef Lawrynowicz wrote:
>
> > Some setjmp/longjmp tests[1] depend on the value of an auto set before
> > setjmp
> > to to be retained after returning from the longjmp. As I understand, this
> > behaviour is act
On Sun, 7 Apr 2019, nick wrote:
>
>
> On 2019-04-07 5:31 a.m., Richard Biener wrote:
> > On April 5, 2019 6:11:15 PM GMT+02:00, nick wrote:
> >>
> >>
> >> On 2019-04-05 6:25 a.m., Richard Biener wrote:
> >>> On Wed, 3 Apr 2019, nick wr
On April 5, 2019 6:11:15 PM GMT+02:00, nick wrote:
>
>
>On 2019-04-05 6:25 a.m., Richard Biener wrote:
>> On Wed, 3 Apr 2019, nick wrote:
>>
>>>
>>>
>>> On 2019-04-03 7:30 a.m., Richard Biener wrote:
>>>> On Mon, 1 Apr 2019, nick wr
On April 6, 2019 3:59:41 PM GMT+02:00, Thomas Koenig
wrote:
>Am 05.04.19 um 12:15 schrieb Richard Biener:
>
>> Putting readonly data into .rodata isn't required by the C standard I
>think
>> so we could freely choose .bss for data exceeding a reasonable
>> size
On Wed, 3 Apr 2019, nick wrote:
>
>
> On 2019-04-03 7:30 a.m., Richard Biener wrote:
> > On Mon, 1 Apr 2019, nick wrote:
> >
> >>
> >>
> >> On 2019-04-01 9:47 a.m., Richard Biener wrote:
> >>> On Mon, 1 Apr 2019, nick wrote:
> >
On Thu, Apr 4, 2019 at 9:53 PM Thomas Koenig wrote:
>
> Hi Andreas,
>
> >> Well, nothing is going to write to it (this is not accessible by
> >> user code), so that should not be a problem.
> > Then don't make it read-only.
>
> I tried this, and while it solves the executable size problem, it
> ca
On April 3, 2019 7:59:47 PM GMT+02:00, Martin Sebor wrote:
>On 4/3/19 5:13 AM, Richard Biener wrote:
>> On Tue, Apr 2, 2019 at 6:20 PM Martin Sebor wrote:
>>>
>>> GCC tries to align a vector on its natural boundary, i.e., that
>>> given by its size, up to MAX
On Tue, Apr 2, 2019 at 1:43 AM Patrick Palka wrote:
>
> Hi Richard, Jakub and Martin,
>
> First of all I'm sorry for the very late reply, and I will be more
> punctual with my replies from now on.
>
> On Fri, Mar 8, 2019 at 4:35 AM Richard Biener
> wrote:
> >
On Mon, 1 Apr 2019, nick wrote:
>
>
> On 2019-04-01 9:47 a.m., Richard Biener wrote:
> > On Mon, 1 Apr 2019, nick wrote:
> >
> >> Well I'm talking about the shared roots of this garbage collector core
> >> state
> >> data structure or ju
On Tue, Apr 2, 2019 at 6:20 PM Martin Sebor wrote:
>
> GCC tries to align a vector on its natural boundary, i.e., that
> given by its size, up to MAX_OBJECT_ALIGNMENT. Vectors that are
> bigger than that are either silently [mis]aligned on that same
> maximum boundary (PR 89798), silently truncat
On April 2, 2019 11:46:14 AM GMT+02:00, Ulrich Weigand
wrote:
>Hello,
>
>the spu-elf target in GCC supports generating code for the SPU
>processors
>of the Cell Broadband Engine; it has been part of upstream GCC since
>2008.
>
>However, at this point I believe this target is no longer in use:
>-
On Mon, 1 Apr 2019, nick wrote:
>
>
> On 2019-04-01 5:56 a.m., Richard Biener wrote:
> > On Fri, 29 Mar 2019, nick wrote:
> >
> >>
> >>
> >> On 2019-03-29 10:28 a.m., nick wrote:
> >>>
> >>>
> >>> O
On Fri, 29 Mar 2019, nick wrote:
>
>
> On 2019-03-29 10:28 a.m., nick wrote:
> >
> >
> > On 2019-03-29 5:08 a.m., Richard Biener wrote:
> >> On Thu, 28 Mar 2019, nick wrote:
> >>
> >>>
> >>>
> >>> On 2019-0
n between
second and final evaluation depends a lot on the amount of issues
unconvered.
Thanks,
Richard.
> Thank you,
> Giuliano.
>
--
Richard Biener
SUSE Linux GmbH, Maxfeldstrasse 5, 90409 Nuernberg, Germany;
GF: Felix Imendörffer, Mary Higgins, Sri Rasiah; HRB 21284 (AG Nürnberg)
Status
==
We should be at the end of the stabilization phase (Stage 4) having
made some good progress in the long march towards zero P1 regressions.
Please have a look at those that you assigned yourself to.
There's still 12 P1 left at the moment though at some point bugs
not severe (wrong-
On Thu, 28 Mar 2019, nick wrote:
>
>
> On 2019-03-28 4:59 a.m., Richard Biener wrote:
> > On Wed, Mar 27, 2019 at 6:31 PM nick wrote:
> >>
> >> Greetings All,
> >>
> >> I've already done most of the work required for signing up for GSoC
On Thu, 28 Mar 2019, Giuliano Belinassi wrote:
> Hi, Richard
>
> On 03/28, Richard Biener wrote:
> > On Wed, Mar 27, 2019 at 2:55 PM Giuliano Belinassi
> > wrote:
> > >
> > > Hi,
> > >
> > > On 03/26, Richard Biener wrote:
> > >
On Wed, Mar 27, 2019 at 6:31 PM nick wrote:
>
> Greetings All,
>
> I've already done most of the work required for signing up for GSoC
> as of last year i.e. reading getting started, being signed up legally
> for contributions.
>
> My only real concern would be the proposal which I started writing
On Wed, Mar 27, 2019 at 3:43 PM nick wrote:
>
>
>
> On 2019-03-27 9:55 a.m., Giuliano Belinassi wrote:
> > Hi,
> >
> > On 03/26, Richard Biener wrote:
> >> On Tue, 26 Mar 2019, David Malcolm wrote:
> >>
> >>> On Mon, 2019-03-25 at 19
On Wed, Mar 27, 2019 at 2:55 PM Giuliano Belinassi
wrote:
>
> Hi,
>
> On 03/26, Richard Biener wrote:
> > On Tue, 26 Mar 2019, David Malcolm wrote:
> >
> > > On Mon, 2019-03-25 at 19:51 -0400, nick wrote:
> > > > Greetings All,
> > > >
>
On Wed, Mar 27, 2019 at 1:27 PM Martin Liška wrote:
>
> On 3/25/19 1:36 PM, Moritz Strübe wrote:
> > Hi,
> >
> > I have an issue with the optimization options. We are on an stm32 and it
> > only has a prefetcher, but no cache. Thus it's nice to have linear
> > default path. For example, we use __
On Wed, Mar 27, 2019 at 10:09 AM Jakub Jelinek wrote:
>
> On Wed, Mar 27, 2019 at 10:02:21AM +0100, Richard Biener wrote:
> > On Wed, Mar 27, 2019 at 8:48 AM Thomas König wrote:
> > >
> > > Hi Eric,
> > > > There is an entire machinery in the middle-end
On Wed, Mar 27, 2019 at 8:48 AM Thomas König wrote:
>
> Hi Eric,
> > There is an entire machinery in the middle-end and the back-ends to support
> > this (look for trampolines/descriptors in the manual and the source code).
> > This should essentially work out of the box for any language front-e
On Tue, 26 Mar 2019, David Malcolm wrote:
> On Mon, 2019-03-25 at 19:51 -0400, nick wrote:
> > Greetings All,
> >
> > I would like to take up parallelize compilation using threads or make
> > c++/c
> > memory issues not automatically promote. I did ask about this before
> > but
> > not get a rep
On Thu, Mar 21, 2019 at 9:25 AM Alexander Monakov wrote:
>
> On Thu, 21 Mar 2019, Richard Biener wrote:
> > > Maybe an example would help.
> > >
> > > Consider this code:
> > >
> > > for (int i = start; i < limit; i++) {
> > > fo
On Wed, Mar 20, 2019 at 8:05 PM Tom Tromey wrote:
>
> > "Segher" == Segher Boessenkool writes:
>
> >> Section 6.2.5.2 outlines the line number information state machine's
> >> opcodes. One of them is "DW_LNS_set_epilogue_begin". Its definition
> >> is:
>
> Segher> How should this work with sh
On Wed, Mar 20, 2019 at 6:36 PM Andrew Haley wrote:
>
> On 3/20/19 2:08 PM, Moritz Strübe wrote:
> >
> > Ok, I played around a bit. Interestingly, if I set
> > -fsanitize=udefined and -fsanitize-undefined-trap-on-error the
> > compiler detects that it will always trap, and optimizes the code
> > a
On Tue, Mar 19, 2019 at 9:38 PM Justin Paston-Cooper
wrote:
>
> Hello,
>
> In my message https://sourceware.org/ml/gdb/2019-03/msg00042.html to
> the gdb mailing list, I asked whether it would be possible to
> implement a command which breaks at all exit points of the current
> stack frame. This w
On Tue, Mar 19, 2019 at 8:53 PM Jeff Law wrote:
>
> On 3/6/19 3:05 AM, Richard Biener wrote:
> > On Tue, Mar 5, 2019 at 10:36 PM Jeff Law wrote:
> >>
> >> On 3/5/19 7:44 AM, Richard Biener wrote:
> >>
> >>> So fixing it properly with also
On Fri, Mar 8, 2019 at 8:56 AM Vanida Plamondon
wrote:
>
> I have been working on some PPA's that will provide standard Ubuntu
> and Linux Mint packages that are compiled with the znver1 cpu
> optimisations (Ryzen CPU). It has been quite tedious (though not
> particularly hard) to modify existing
On Thu, Mar 7, 2019 at 7:20 PM Martin Sebor wrote:
>
> On 3/4/19 6:17 AM, Richard Biener wrote:
> > On Mon, Mar 4, 2019 at 1:23 PM Jakub Jelinek wrote:
> >>
> >> On Mon, Mar 04, 2019 at 01:13:29PM +0100, Richard Biener wrote:
> >>>>
On Wed, Mar 6, 2019 at 11:05 AM Richard Biener
wrote:
>
> On Tue, Mar 5, 2019 at 10:36 PM Jeff Law wrote:
> >
> > On 3/5/19 7:44 AM, Richard Biener wrote:
> >
> > > So fixing it properly with also re-optimize_stmt those stmts so we'd CSE
> > > the M
On Tue, Mar 5, 2019 at 10:36 PM Jeff Law wrote:
>
> On 3/5/19 7:44 AM, Richard Biener wrote:
>
> > So fixing it properly with also re-optimize_stmt those stmts so we'd CSE
> > the MAX_EXPR introduced by folding makes it somewhat ugly.
> >
> > Bootstrapped o
On Tue, Mar 5, 2019 at 11:44 AM Richard Biener
wrote:
>
> On Tue, Mar 5, 2019 at 10:48 AM Richard Biener
> wrote:
> >
> > On Mon, Mar 4, 2019 at 11:01 PM Qing Zhao wrote:
> > >
> > > Hi, Richard,
> > >
> > > > On Mar 4, 2019, at 5
On Tue, Mar 5, 2019 at 10:48 AM Richard Biener
wrote:
>
> On Mon, Mar 4, 2019 at 11:01 PM Qing Zhao wrote:
> >
> > Hi, Richard,
> >
> > > On Mar 4, 2019, at 5:45 AM, Richard Biener
> > > wrote:
> > >>
> > >> It looks like DOM
901 - 1000 of 2565 matches
Mail list logo
