On Wed, Jan 16, 2019 at 12:55 PM Tadeus Prastowo
wrote:
>
> On Wed, Jan 16, 2019 at 12:52 PM Richard Biener
> wrote:
> >
> > On Wed, Jan 16, 2019 at 10:40 AM Tadeus Prastowo
> > wrote:
> > >
> > > Hi,
> > >
> > > On this link https:
0%) 12 kB ( 0%)
> address lowering : 0.04 ( 0%) 0.00 ( 0%) 0.02 (
> 0%) 2 kB ( 0%)
> early local passes : 0.02 ( 0%) 0.01 ( 0%) 0.00 (
> 0%) 0 kB ( 0%)
> unaccounted optimizations : 0.01 ( 0%) 0.00 ( 0%) 0.00 (
>
On Thu, Jan 17, 2019 at 8:16 PM Michael Ploujnikov
wrote:
>
> Hi,
>
> I've been doing some investigations that required using a bitmap to keep
> track of decl IDs and I ran into segmentation fault after my bitmap has been
> loaded from a PCH. Attached is a short patch that can reliably reproduce
On Fri, Jan 18, 2019 at 4:11 AM Li Kun wrote:
>
> I need to known which rtx is expanded from a specific CALL_EXPR, how
> could i do ?
>
> Is INSN_LOCATION accurate enough ?
No. There's no accurate way to do this so you have to invent something.
Or start by explaining what you are wanting to do.
On Fri, Jan 18, 2019 at 10:33 AM Li Kun wrote:
>
>
>
> 在 2019/1/18 16:52, Richard Biener 写道:
> > On Fri, Jan 18, 2019 at 4:11 AM Li Kun wrote:
> >> I need to known which rtx is expanded from a specific CALL_EXPR, how
> >> could i do ?
> >>
> >&g
On January 18, 2019 2:38:44 PM GMT+01:00, Michael Ploujnikov
wrote:
>On 2019-01-18 3:45 a.m., Richard Biener wrote:
>> On Thu, Jan 17, 2019 at 8:16 PM Michael Ploujnikov
>> wrote:
>>>
>>> Hi,
>>>
>>> I've been doing some investigations tha
On Mon, Jan 21, 2019 at 2:46 AM Andi Kleen wrote:
>
> Wojciech Muła writes:
> >
> > The main concern is if it's a proper approach? Seems that to match
> > other logic functions, like "a & b | c", a separate pattern is required.
> > Since an argument can be either negated or not, and we can use th
On Mon, Jan 21, 2019 at 2:20 PM Anton Youdkevitch
wrote:
>
> Here is the prototype for doing vectorized reduction
> using SLP approach. I would appreciate feedback if this
> is a feasible approach and if overall the direction is
> right.
>
> The idea is to vectorize reduction like this
>
> S = A[0
On Wed, Jan 23, 2019 at 12:33 PM Jakub Jelinek wrote:
>
> On Wed, Jan 23, 2019 at 10:40:43AM +, Jonathan Wakely wrote:
> > There's a patch to add __builtin_dynamic_object_size to clang:
> > https://reviews.llvm.org/D56760
> >
> > It was suggested that this could be done via a new flag bit for
to detect the reduction group. The greedy matching
I talked about above can be applied anywhere, not
just at stores.
> --
>Thanks,
>Anton
>
>
> On 24/1/2019 13:47, Richard Biener wrote:
> > On Mon, Jan 21, 2019 at 2:20 PM Anton Youdkevitch
> > wrote:
> >>
>
On January 25, 2019 7:22:36 AM GMT+01:00, Nikhil Benesch
wrote:
>I am attempting to convince GCC to build target libraries with
>link-time
>optimizations enabled. I am primarily interested in libgo, but this
>discussion
>seems like it would be applicable to libstdc++, libgfortran, etc. The
>bench
On January 25, 2019 6:17:54 PM GMT+01:00, Joseph Myers
wrote:
>On Fri, 25 Jan 2019, Nikhil Benesch wrote:
>
>> I am attempting to convince GCC to build target libraries with
>link-time
>> optimizations enabled. I am primarily interested in libgo, but this
>discussion
>
>Note that as far as I know
On Mon, Jan 28, 2019 at 4:59 PM Bernhard Schommer
wrote:
>
> Hi,
>
> I would like to know if the handling of the option -fno-common has
> changed between version 7.3 and 8.2 for x86. I tried it with the
> default system version of OpenSUSE and for example:
>
> const int i;
>
> is placed in the .bs
On Wed, Jan 30, 2019 at 3:46 PM Sebastian Huber
wrote:
>
> Hello,
>
> we would like to use libgomp in a quite constraint environment. In this
> environment using for example the C locale support, errno, malloc(),
> realloc(), free(), and abort() are problematic. One option would be to
> introduce
On Wed, Jan 30, 2019 at 5:19 PM wrote:
>
> hi,
> on site:
> https://www.gnu.org/software/gcc/bugs/#dontwant
> in section
> Reporting Bugs > Summarized bug reporting instructions > What we do not want
> in 3 point you have
>
> An attached archive (tar, zip, shar, whatever) containing all (or some :
On Thu, Jan 31, 2019 at 10:37 AM Sebastian Huber
wrote:
>
> On 31/01/2019 10:29, Richard Biener wrote:
> > On Wed, Jan 30, 2019 at 3:46 PM Sebastian Huber
> > wrote:
> >> Hello,
> >>
> >> we would like to use libgomp in a quite constraint environmen
Status
==
We're one month into the stabilization phase (Stage 4), making some
good progress in the long march towards zero P1 regressions. Please
have a look at those that you assigned yourself to.
As usual this is a good time to test your non-{primary,secondary}
target making sure it buil
On Mon, Feb 11, 2019 at 10:46 PM Giuliano Belinassi
wrote:
>
> Hi,
>
> I was just wondering what API should I use to spawn threads and control
> its flow. Should I use OpenMP, pthreads, or something else?
>
> My point what if we break compatibility with something. If we use
> OpenMP, I'm afraid th
On February 15, 2019 1:45:10 PM GMT+01:00, Hi-Angel
wrote:
>I never could understand, why field reordering was removed from GCC?
The implementation simply was seriously broken, bitrotten and unmaintained.
Richard
I
>mean, I know that it's prohibited in C and C++, but, sure, GCC can
>detect
On February 19, 2019 5:19:11 PM GMT+01:00, Qing Zhao
wrote:
>Hi,
>
>Suppose we have a program called foo which is built with gcc
>-fprofile-generate, Now when foo is executed a bunch of .gcda files
>are created.
>
>What happens when foo is executed more than once. Are the .gcda files
>updated
On Tue, Feb 19, 2019 at 3:29 PM Matthew Malcomson
wrote:
>
> Hi there,
>
> I'd like to make handling of the __RTL function testcases where the
> startwith pass name is either invalid, not used for that optimisation
> level, or non-existant more understandable.
>
> Currently a problem with the pass
body think that just checksumming gtype-desc.o is a
degradation over the current state (which checksums thin archives)?
Thanks,
Richard.
2019-02-22 Richard Biener
c/
* Make-lang.in (cc1-checksum.c): Checksum only gtype-desc.o.
cp/
* Make-lang.in (cc1plus-checks
On February 22, 2019 5:03:46 PM GMT+01:00, Jakub Jelinek
wrote:
>On Fri, Feb 22, 2019 at 08:47:09AM -0700, Jeff Law wrote:
>> > 2019-02-22 Richard Biener
>> >
>> >c/
>> >* Make-lang.in (cc1-checksum.c): Checksum only gtype-desc.o.
>> &
On Mon, 25 Feb 2019, Mark Wielaard wrote:
> On Fri, 2019-02-22 at 12:29 +0100, Richard Biener wrote:
> > +struct build_id_note {
> > +/* The NHdr. */
> > +uint32_t namesz;
> > +uint32_t descsz;
> > +uint32_t type;
> > +
> > +char
On Tue, 26 Feb 2019, Mark Wielaard wrote:
> On Tue, 2019-02-26 at 09:33 +0100, Richard Biener wrote:
> > On Mon, 25 Feb 2019, Mark Wielaard wrote:
> > > Since the introduction of GNU Property notes this is (sadly) no
> > > longer
> > > the correct way to itera
On Tue, 26 Feb 2019, Richard Biener wrote:
> On Tue, 26 Feb 2019, Mark Wielaard wrote:
>
> > On Tue, 2019-02-26 at 09:33 +0100, Richard Biener wrote:
> > > On Mon, 25 Feb 2019, Mark Wielaard wrote:
> > > > Since the introduction of GNU Property notes this is (sad
On Tue, 26 Feb 2019, Michael Matz wrote:
> Hi,
>
> On Tue, 26 Feb 2019, Richard Biener wrote:
>
> > get_build_id_1 (struct dl_phdr_info *info, size_t, void *data)
> > {
>
> Isn't this all a bit silly? We could simply encode the svn revision, or
> maybe
On Tue, 26 Feb 2019, Mark Wielaard wrote:
> On Tue, 2019-02-26 at 15:36 +0100, Richard Biener wrote:
> > On Tue, 26 Feb 2019, Mark Wielaard wrote:
> >
> > > On Tue, 2019-02-26 at 09:33 +0100, Richard Biener wrote:
> > > > On Mon, 25 Feb 2019, Mark Wielaard wro
On March 1, 2019 6:49:20 PM GMT+01:00, Qing Zhao wrote:
>Jeff,
>
>thanks a lot for the reply.
>
>this is really helpful.
>
>I double checked the dumped intermediate file for pass “dom3", and
>located the following for _152:
>
>BEFORE the pass “dom3”, there is no _152, the corresponding Block
>
On Fri, Mar 1, 2019 at 10:02 PM Qing Zhao wrote:
>
>
> On Mar 1, 2019, at 1:25 PM, Richard Biener wrote:
>
> On March 1, 2019 6:49:20 PM GMT+01:00, Qing Zhao wrote:
>
> Jeff,
>
> thanks a lot for the reply.
>
> this is really helpful.
>
> I double checke
On Mon, Mar 4, 2019 at 11:44 AM P J P wrote:
>
> On Tuesday, 19 February, 2019, 3:55:35 PM IST, P J P
> wrote:
> >
> >Hello,
> >
> > -> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87210
> >
> >This RFE is about providing gcc option(s) to eliminate information leakage
> >issues from programs. I
On Mon, Mar 4, 2019 at 12:16 AM Jeff Law wrote:
>
> On 3/3/19 4:06 PM, Patrick Palka wrote:
> > Hi everyone,
> >
> > I am very interested in working on GCC as part of GSoC this year. A few
> > years
> > ago I was a somewhat active code contributor[1] and unfortunately my
> > contributing waned o
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:
> > > > * Make TREE_NO_WARNING more fine-grained
> > > > (inspired by comment #7 of PR74762 [3])
> > > > TREE_NO_WARNING is
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 fails to visit stmts generated by simplification. Can
> >> you open a bug report with a tes
On Tue, Mar 5, 2019 at 10:41 AM JunMa wrote:
>
> Hi All
>
> We are now optimizing some projects with lto enabled, however,
> there are some issues.
> First, lto_plugin.so needs to be passed to ar/nm/ranlib.
> For example, build static library with lto:
>
> gcc -flto -O2 a.c -c -o a.o
> gcc -flto -
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
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: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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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
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-
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)
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
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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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, 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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, 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 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 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, 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 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 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
901 - 1000 of 1673 matches
Mail list logo
