On March 19, 2018 4:27:58 PM GMT+01:00, Sebastiaan Peters
wrote:
>Thank you for your quick response.
>
>Does the GIMPLE optimization pipeline include only the Tree SSA passes
>or also the RTL passes?
Yes, it only includes only Tree SSA passes. The RTL part of the pipeline hasn't
been audited to
nd current_function_decl plus
globals in the individual passes which is easiest dealt with by not allowing a
single pass to run at the same time in multiple threads). TLS can be used for
some of the global state plus of course some global data structures need
locking.
Richard.
>_____
On Mon, Mar 19, 2018 at 9:55 PM, Richard Biener
wrote:
> On March 19, 2018 8:09:32 PM GMT+01:00, Sebastiaan Peters
> wrote:
>>>The goal should be to extend TU wise parallelism via make to function
>>wise parallelism within GCC.
>>
>>Could you please elaborate
On Tue, Mar 20, 2018 at 3:49 PM, David Malcolm wrote:
> On Tue, 2018-03-20 at 14:02 +0100, Richard Biener wrote:
>> On Mon, Mar 19, 2018 at 9:55 PM, Richard Biener
>> wrote:
>> > On March 19, 2018 8:09:32 PM GMT+01:00, Sebastiaan Peters > > 7...@hotmail.com> wrot
On Tue, Mar 20, 2018 at 8:57 PM, Martin Liška wrote:
> Hi.
>
> I did similar stats for postgresql server, more precisely for pgbench:
> pgbench -s100 & 10 runs of pgbench -t1 -v
Without looking at the benchmark probably only because it is flawed
(aka not I/O or memory bandwidth limited). It
On Wed, Mar 21, 2018 at 9:50 AM, Sebastiaan Peters
wrote:
>>On Tue, Mar 20, 2018 at 3:49 PM, David Malcolm wrote:
>>> On Tue, 2018-03-20 at 14:02 +0100, Richard Biener wrote:
>>>> On Mon, Mar 19, 2018 at 9:55 PM, Richard Biener
>>>> wrote:
>&g
On Wed, Mar 21, 2018 at 8:04 PM, Sebastiaan Peters
wrote:
>>On Wed, Mar 21, 2018 at 9:50 AM, Sebastiaan Peters
>> wrote:
>>>>On Tue, Mar 20, 2018 at 3:49 PM, David Malcolm wrote:
>>>>> On Tue, 2018-03-20 at 14:02 +0100, Richard Biener wrote:
>>>>
On March 22, 2018 7:48:33 PM GMT+01:00, Steve Ellcey wrote:
>On Thu, 2018-03-22 at 11:42 -0700, H.J. Lu wrote:
>> On Thu, Mar 22, 2018 at 11:08 AM, Steve Ellcey
>> wrote:
>> >
>> > I have a question about the math vector library routines in
>> > libmvec.
>> > If I compile a program on x86 with -
On Thu, Mar 22, 2018 at 7:47 PM, Jakub Jelinek wrote:
> On Thu, Mar 22, 2018 at 11:08:58AM -0700, Steve Ellcey wrote:
>> I have a question about the math vector library routines in libmvec.
>> If I compile a program on x86 with -Ofast, something like:
>>
>> void foo(double * __restrict x, double *
Status
==
The GCC 8 trunk is open for regression and documentation fixes. Following
past releases we are aiming at a first release candidate mid April though
if you look at the quality data below that looks ambitious.
So please help tackling (and confirming, bisecting, reducing, etc.)
regre
On Wed, Mar 28, 2018 at 12:29 AM, Joseph Myers wrote:
> On Tue, 27 Mar 2018, Steve Ellcey wrote:
>
>> Here is another libmvec question. While testing on x86 I could easily make
>> a loop with calls to sin, cos, log, exp, or pow and see them vectorized when
>> I compile with -Ofast. But if I try
On Thu, Mar 29, 2018 at 12:15 PM, Eric Botcazou wrote:
>> I noticed there are quite many selective scheduling PRs:
>> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84872
>> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84842
>> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84659
>>
>> and many others
On March 29, 2018 5:14:42 PM GMT+02:00, Eric Botcazou
wrote:
>> Are you suggesting we should not care about regressions with features
>> that are not enabled by default or which are only exposed with
>> "non-standard" flags? The current scheme on which bugs get P1/P2/P4+
>> assigned is quite sim
On Sat, Mar 31, 2018 at 2:44 AM, Damian Rouson
wrote:
> All,
>
> Jerry DeLisle, Daniel Celis Garza, and I would greatly appreciate feedback on
> our approach to patching the GCC build system to build MPICH and OpenCoarrays
> after it builds gfortran (gfortran requires MPI and OpenCoarrays to sup
On Wed, Apr 4, 2018 at 8:24 AM, Damian Rouson
wrote:
> On April 3, 2018 at 1:36:37 AM, Richard Biener (richard.guent...@gmail.com)
> wrote:
>
>
> You probably only want a new target_module for the MPI library. Note
> it's name has to match that of the directory containing t
On Sun, Apr 8, 2018 at 8:56 PM, Damian Rouson
wrote:
> On April 4, 2018 at 1:12:25 AM, Richard Biener
> (richard.guent...@gmail.com(mailto:richard.guent...@gmail.com)) wrote:
>
>> In that case user programs compiled with -fcoarray=lib are but gfortran
>> or libgfortran
On Tue, Apr 10, 2018 at 12:29 PM, Jakub Jelinek wrote:
> On Tue, Apr 10, 2018 at 11:22:03AM +0100, Szabolcs Nagy wrote:
>> On 10/04/18 11:14, Janne Blomqvist wrote:
>> > As I mentioned previously in that thread you linked to, the fortran
>> > frontend never generates a direct call to libm sin(), o
On April 10, 2018 3:06:55 PM GMT+02:00, Jakub Jelinek wrote:
>On Tue, Apr 10, 2018 at 02:55:43PM +0200, Richard Biener wrote:
>> > And the easiest solution is in the Fortran FE based on some flag
>> > (e.g. -mveclibabi=glibc) through a target hook add
>> > __attri
On April 10, 2018 3:06:55 PM GMT+02:00, Jakub Jelinek wrote:
>On Tue, Apr 10, 2018 at 02:55:43PM +0200, Richard Biener wrote:
>> > And the easiest solution is in the Fortran FE based on some flag
>> > (e.g. -mveclibabi=glibc) through a target hook add
>> > __attri
On Tue, Apr 17, 2018 at 3:54 PM, Szabolcs Nagy wrote:
> On 10/04/18 14:27, Richard Biener wrote:
>>
>> On April 10, 2018 3:06:55 PM GMT+02:00, Jakub Jelinek
>> wrote:
>>>
>>> On Tue, Apr 10, 2018 at 02:55:43PM +0200, Richard Biener wrote:
>>>>
On Wed, 18 Apr 2018, Uros Bizjak wrote:
> Hello!
>
> Currently, CET is enabled by default for linux if target supports
> multi-byte NOPs and if assembler supports CET insn. Effectively, with
> newer binutils, CET support is an opt-out feature.
>
> I don't think this should be the case, and I pro
On Thu, Apr 19, 2018 at 8:33 AM, Thomas Koenig wrote:
> Hi Matt,
> [timings]
>
>> Intel AVX2:
>>
>> C_SW 1.4931
>> D_SW 5.4254
>> PG_D 1.0878
>> TRACER_2D 24.7418
>> REMAPPING 27.2644
>
>
>> Now I looked at GNU Fortran (7.3.0). Here my "stock" flags are quite
On Sun, Apr 22, 2018 at 4:27 PM, Toon Moene wrote:
> A few days ago there was a rant on the Fortran Standardization Committee's
> e-mail list about Fortran's "whole array arithmetic" being unoptimizable.
>
> An example picked at random from our weather forecasting code:
>
> ZQICE(1:NPROMA,1:NF
On Mon, Apr 23, 2018 at 12:59 PM, Bin.Cheng wrote:
> On Sun, Apr 22, 2018 at 3:27 PM, Toon Moene wrote:
>> A few days ago there was a rant on the Fortran Standardization Committee's
>> e-mail list about Fortran's "whole array arithmetic" being unoptimizable.
>>
>> An example picked at random from
On Mon, Apr 23, 2018 at 2:31 PM, Janne Blomqvist
wrote:
> On Mon, Apr 23, 2018 at 2:02 PM, Richard Biener
> wrote:
>>
>> On Mon, Apr 23, 2018 at 12:59 PM, Bin.Cheng wrote:
>> > On Sun, Apr 22, 2018 at 3:27 PM, Toon Moene wrote:
>> >> A few d
On Mon, Apr 23, 2018 at 8:35 PM, Toon Moene wrote:
> On 04/23/2018 01:00 PM, Richard Biener wrote:
>
>> On Sun, Apr 22, 2018 at 4:27 PM, Toon Moene wrote:
>>>
>>> A few days ago there was a rant on the Fortran Standardization
>>> Committee's
On Wed, Apr 25, 2018 at 5:17 AM, Hrishikesh Kulkarni
wrote:
> Hi,
>
> Thanks a lot for giving me this wonderful opportunity to work with GCC
> under your guidance and mentorship (GSOC 2018).
>
> Just a few starting queries
>
>1.
>
>As a starting point to read lto-object file, is it suffici
Sorry for the late response.
Richard.
>
> Thanks,
>
> Hrishikesh
>
> On Wed, Apr 25, 2018 at 1:35 PM, Richard Biener
> wrote:
>> On Wed, Apr 25, 2018 at 5:17 AM, Hrishikesh Kulkarni
>> wrote:
>>> Hi,
>>>
>>> Thanks a lot for giving me thi
On Thu, May 3, 2018 at 8:43 PM, Toon Moene wrote:
> Consider the attached Fortran code (the most expensive routine,
> computation-wise, in our weather forecasting model).
>
> verint.s.7.3 is the result of:
>
> gfortran -g -O3 -S -march=native -mtune=native verint.f
>
> using release 7.3.
>
> verin
On May 9, 2018 6:19:47 PM GMT+02:00, Kyrill Tkachov
wrote:
>Hi all,
>
>I'm looking into implementing the usad/ssad optabs for aarch64 to catch
>code like in PR 85693
>and I'm a bit lost with what the midend expects the optabs to produce.
>The documentation for them says that the addend operand (
On May 10, 2018 10:53:19 AM GMT+02:00, Kyrill Tkachov
wrote:
>Hi Richard,
>
>On 09/05/18 19:37, Richard Biener wrote:
>> On May 9, 2018 6:19:47 PM GMT+02:00, Kyrill Tkachov
> wrote:
>>> Hi all,
>>>
>>> I'm looking into implementing the usad/ssa
On Thu, May 10, 2018 at 11:32 PM, Freddie Chopin wrote:
> Hi!
>
> In one of my embedded projects I have an option to enable LTO. This was
> working more or less fine for GCC 6 and GCC 7, however for GCC 8.1.0
> (and binutils 2.30) - with the same set of options - I see something
> like this
>
> --
On Wed, May 9, 2018 at 6:35 PM, Andrew Stubbs wrote:
> Honza, Martin,
>
> Further to our conversation on IRC ...
>
> We have just completed work on a GCN3 & GCN5 port intended for running
> OpenMP and OpenACC offload kernels on AMD Fiji and Vega discrete GPUs.
> Unfortunately Carrizo is probably b
On May 11, 2018 5:49:44 PM GMT+02:00, Freddie Chopin
wrote:
>On Fri, 2018-05-11 at 13:06 +0200, David Brown wrote:
>> For the Cortex-M devices (and probably many other RISC targets),
>> -fdata-sections comes at a big cost - it effectively blocks
>> -fsection-anchors and makes access to file-stati
On Tue, May 15, 2018 at 1:38 AM Julius Werner wrote:
> Hi,
> I'm a firmware/embedded engineer and frequently run into cases where
> certain parts of the code need to be placed in a special memory area (for
> example, because the area that contains the other code is not yet
> initialized or curre
On May 15, 2018 10:12:45 PM GMT+02:00, Freddie Chopin
wrote:
>On Tue, 2018-05-15 at 21:39 +0200, Freddie Chopin wrote:
>> On Fri, 2018-05-11 at 18:51 +0200, Richard Biener wrote:
>> > As to a workaround for the ld bug you can try keeping all .debug_*
>> > sections.
On Tue, May 15, 2018 at 9:56 PM Julius Werner wrote:
> > I think you are asking for per-function constant pool sections. Because
> > we generally cannot avoid the need of a constant pool and dependent
> > on the target that is always global. Note with per-function constant
> > pools you will no
On May 16, 2018 6:03:35 PM GMT+02:00, Andrew Stubbs
wrote:
>Hi all,
>
>I'm in the process of trying to update our AMD GCN port from GCC 7 to
>GCC 8+, but I've hit a problem ...
>
>It seems there's a new assumption that pointers and addresses will be
>scalar, but GCN load instructions require ve
On May 16, 2018 6:35:05 PM GMT+02:00, Andrew Stubbs
wrote:
>On 16/05/18 17:24, Richard Biener wrote:
>> On May 16, 2018 6:03:35 PM GMT+02:00, Andrew Stubbs
> wrote:
>>> Is there a new way of dealing with vectors of pointers?
>>
>> Maybe you can masquerade it b
On Thu, May 17, 2018 at 11:10 PM Segher Boessenkool <
seg...@kernel.crashing.org> wrote:
> On Thu, May 17, 2018 at 06:10:13PM +0200, Michael Matz wrote:
> > On Wed, 16 May 2018, Richard Biener wrote:
> > > > Are constant pool entries merged at compile time or at link ti
On May 18, 2018 8:03:05 PM GMT+02:00, Paul Koning
wrote:
>Gents,
>
>In some targets, like pdp11 and vax, most instructions can reference
>data in memory directly.
>
>So when I have "if (x < y) ..." I would expect something like this:
>
> cmpw x, y
> bgeq 1f
> ...
>
>What I act
On May 20, 2018 7:20:25 AM GMT+02:00, Steve Kargl
wrote:
>So, there is a P1 blocking bootstrap failure on trunk.
>I've opened a PR and finally had time to locate the
>offending commit.
>
>https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85843
>
>As I cannot bootstrap gcc, I cannot test a set of
>patc
On Tue, May 22, 2018 at 2:19 AM Paul Koning wrote:
> > On May 18, 2018, at 2:07 PM, Richard Biener
wrote:
> >
> > On May 18, 2018 8:03:05 PM GMT+02:00, Paul Koning <
paulkon...@comcast.net> wrote:
> >> Gents,
> >>
> >> In some targets,
On Tue, May 22, 2018 at 12:51 AM Kugan Vivekanandarajah <
kugan.vivekanandara...@linaro.org> wrote:
> Hi,
> I am looking to introduce ABSU_EXPR and that would create:
> unsigned short res = ABSU_EXPR (short);
> Note that the argument is signed and result is unsigned. As per the
> review, I have
onstrained could be made conditional, only for
> targets like cortex-m7. I have attached a prototype patch based on
> this approach (approach-9.diff). Although it works for attached
> test-cases, unfortunately it ICE's with the original test-case in
> tail-merge, I am working on that.
>
> I am not sure though if either of these approaches are in the correct
> direction and would
> be grateful for suggestions on the issue!
>
> Thanks,
> Prathamesh
>
--
Richard Biener
SUSE LINUX GmbH, GF: Felix Imendoerffer, Jane Smithard, Graham Norton, HRB
21284 (AG Nuernberg)
On Wed, May 23, 2018 at 2:50 AM Paul Koning wrote:
> > On May 22, 2018, at 3:26 PM, Segher Boessenkool <
seg...@kernel.crashing.org> wrote:
> >
> >
> > -fdump-rtl-combine-all (or just -da or -dap), and then look at the dump
> > file. Does combine try this combination? If so, it will tell you
On Fri, 25 May 2018, Bin.Cheng wrote:
> On Fri, May 25, 2018 at 10:23 AM, Prathamesh Kulkarni
> wrote:
> > On 23 May 2018 at 18:37, Jeff Law wrote:
> >> On 05/23/2018 03:20 AM, Prathamesh Kulkarni wrote:
> >>> On 23 May 2018 at 13:58, Richard Biener
wrote:
>>>>> On 23 May 2018 at 13:58, Richard Biener wrote:
>>>>>> On Wed, 23 May 2018, Prathamesh Kulkarni wrote:
>>>>>>
>>>>>>> Hi,
>>>>>>> I am trying to work on PR80155, which exposes a problem with
>c
On May 25, 2018 9:25:51 PM GMT+02:00, Jeff Law wrote:
>On 05/25/2018 11:54 AM, Richard Biener wrote:
>> On May 25, 2018 6:57:13 PM GMT+02:00, Jeff Law
>wrote:
>>> On 05/25/2018 03:49 AM, Bin.Cheng wrote:
>>>> On Fri, May 25, 2018 at 10:23 AM, Prathamesh Kulkarni
On May 26, 2018 11:32:29 AM GMT+02:00, Allan Sandfeld Jensen
wrote:
>I brought this subject up earlier, and was told to suggest it again for
>gcc 9,
>so I have attached the preliminary changes.
>
>My studies have show that with generic x86-64 optimization it reduces
>binary
>size with around 0.
On May 27, 2018 1:25:25 AM GMT+02:00, Allan Sandfeld Jensen
wrote:
>On Sonntag, 27. Mai 2018 00:05:32 CEST Segher Boessenkool wrote:
>> On Sat, May 26, 2018 at 11:32:29AM +0200, Allan Sandfeld Jensen
>wrote:
>> > I brought this subject up earlier, and was told to suggest it again
>for
>> > gcc 9,
On Fri, May 25, 2018 at 8:05 PM Paul Koning wrote:
> One of my testsuite failures for the pdp11 back end is
gcc.c-torture/compile/930326-1.c which is:
> struct
> {
>char a, b, f[3];
> } s;
> long i = s.f-&s.b;
> It fails with "error: initializer element is not computable at load time".
> I
On Sat, May 26, 2018 at 12:36 PM Richard Biener
wrote:
> On May 26, 2018 11:32:29 AM GMT+02:00, Allan Sandfeld Jensen <
li...@carewolf.com> wrote:
> >I brought this subject up earlier, and was told to suggest it again for
> >gcc 9,
> >so I have attached the preliminary
On Sat, 26 May 2018, Bin.Cheng wrote:
> On Fri, May 25, 2018 at 5:54 PM, Richard Biener wrote:
> > On May 25, 2018 6:57:13 PM GMT+02:00, Jeff Law wrote:
> >>On 05/25/2018 03:49 AM, Bin.Cheng wrote:
> >>> On Fri, May 25, 2018 at 10:23 AM, Prathamesh Kulkarni
>
On May 28, 2018 12:45:04 PM GMT+02:00, Andreas Schwab wrote:
>On Mai 28 2018, Richard Biener wrote:
>
>> It means there's no relocation that can express the result of 's.f -
>&s.b'
>> and the frontend doesn't consider this a constant exp
On Mon, May 28, 2018 at 5:50 PM Allan Sandfeld Jensen
wrote:
> On Montag, 28. Mai 2018 12:58:20 CEST Richard Biener wrote:
> > compile-time effects of the patch on that. Embedded folks may want to
rhn
> > their favorite benchmark and report results as well.
> >
> > So
On Mon, May 28, 2018 at 8:34 PM Paul Koning wrote:
> > On May 28, 2018, at 12:03 PM, Richard Biener
>
wrote:
> >
> > On May 28, 2018 12:45:04 PM GMT+02:00, Andreas Schwab
wrote:
> >> On Mai 28 2018, Richard Biener wrote:
> >>
> >>> It mean
On Tue, May 29, 2018 at 11:32 AM Richard Biener
wrote:
> On Mon, May 28, 2018 at 5:50 PM Allan Sandfeld Jensen
> wrote:
> > On Montag, 28. Mai 2018 12:58:20 CEST Richard Biener wrote:
> > > compile-time effects of the patch on that. Embedded folks may want to
>
On Tue, May 29, 2018 at 5:24 PM Allan Sandfeld Jensen
wrote:
> On Dienstag, 29. Mai 2018 16:57:56 CEST Richard Biener wrote:
> >
> > so the situation improves but isn't fully fixed (STLF issues maybe?)
> >
> That raises the question if it helps in these case
On Wed, May 30, 2018 at 11:25 AM Richard Biener
wrote:
> On Tue, May 29, 2018 at 5:24 PM Allan Sandfeld Jensen
> wrote:
> > On Dienstag, 29. Mai 2018 16:57:56 CEST Richard Biener wrote:
> > >
> > > so the situation improves but isn't fully fixed (STLF issues
On Wed, May 30, 2018 at 1:53 AM Andrew MacLeod wrote:
>
> I'd like to introduce a project we've been working on for the past year
> an a half.
>
> The original project goal was to see if we could derived accurate range
> information from the IL without requiring much effort on the client
> side. T
On June 1, 2018 7:34:25 PM GMT+02:00, vineet singh
wrote:
>Hi,
>
>I want to know that whether GCC provides a pass that gives us "may
>alias"
>information and how we can access it?
>
>If yes, then is this may alias information available before and after
>each
>pass of GCC?
May alias info is avail
On Fri, Jun 1, 2018 at 10:38 PM Andrew MacLeod wrote:
>
> On 06/01/2018 05:48 AM, Richard Biener wrote:
>
> On Wed, May 30, 2018 at 1:53 AM Andrew MacLeod wrote:
bah, gmail now completely mangles quoting :/
>
> This allows queries for a range on an edge, on entry to a block,
On Mon, Jun 4, 2018 at 5:17 PM Richard Biener
wrote:>
> On Fri, Jun 1, 2018 at 10:38 PM Andrew MacLeod wrote:
> >
> > On 06/01/2018 05:48 AM, Richard Biener wrote:
> >
> > On Wed, May 30, 2018 at 1:53 AM Andrew MacLeod wrote:
>
> bah, gmail now completely m
On Mon, Jun 4, 2018 at 8:11 PM Laszlo Ersek wrote:
>
> Hi!
>
> Apologies if this isn't the right place for asking. For the problem
> statement, I'll simply steal Ard's writeup [1]:
>
> > KVM on ARM refuses to decode load/store instructions used to perform
> > I/O to emulated devices, and instead r
On Tue, Jun 5, 2018 at 1:39 AM Martin Sebor wrote:
>
> GCC silently (without -Wpedantic) accepts declarations of zero
> length arrays that are followed by other members in the same
> struct, such as in:
>
>struct A { char a, b[0], c; };
>
> Is it intended that accesses to elements of such arra
On Thu, Jun 7, 2018 at 9:06 AM Aldy Hernandez wrote:
>
> Howdy.
>
> I'm looking at the ABS_EXPR code in extract_range_from_unary_expr() and
> have noticed that by the time we get here:
>
>/* If a VR_ANTI_RANGEs contains zero, then we have
> ~[-INF, min(MIN, MAX)]. */
>if
gt;
> >> > On Tue, Jun 05, 2018 at 03:07:14PM +0200, Laszlo Ersek wrote:
> >> >> On 06/05/18 13:30, Richard Biener wrote:
> >> >> > On Mon, Jun 4, 2018 at 8:11 PM Laszlo Ersek wrote:
> >> >> >>
> >> >> >> Hi!
>
On Thu, Jun 7, 2018 at 11:45 AM Ard Biesheuvel
wrote:
>
> On 7 June 2018 at 11:35, Richard Biener wrote:
> > On Thu, Jun 7, 2018 at 10:45 AM Ard Biesheuvel
> > wrote:
> >>
> >> On 7 June 2018 at 10:21, Christoffer Dall wrote:
> >> > On Thu,
On Wed, Jun 6, 2018 at 11:10 PM Zan Lynx wrote:
>
> On 06/06/2018 10:22 AM, Dmitry Mikushin wrote:
> > The opinion you've mentioned is common in scientific community. However, in
> > more detail it often surfaces that the used set of GCC compiler options
> > simply does not correspond to that "fas
On Wed, Jun 6, 2018 at 8:31 PM Ryan Burn wrote:
>
> One case where ICC can generate much faster code sometimes is by using
> the nontemporal pragma [https://software.intel.com/en-us/node/524559]
> with loops.
>
> AFAIK, there's no such equivalent pragma in gcc
> [https://gcc.gnu.org/ml/gcc/2012-01
On Wed, Jun 6, 2018 at 5:52 PM Paul Menzel
wrote:
>
> Dear GCC folks,
>
>
> Some scientists in our organization still want to use the Intel
> compiler, as they say, it produces faster code, which is then executed
> on clusters. Some resources on the Web [1][2] confirm this. (I am aware,
> that it’
On Thu, Jun 7, 2018 at 12:01 PM Will Deacon wrote:
>
> On Thu, Jun 07, 2018 at 09:48:50AM +0200, Christoffer Dall wrote:
> > [+Will]
> >
> > On Tue, Jun 05, 2018 at 03:07:14PM +0200, Laszlo Ersek wrote:
> > > On 06/05/18 13:30, Richard Biener wrote:
> > &g
On Fri, Jun 8, 2018 at 11:42 AM Aldy Hernandez wrote:
>
> Howdy.
>
> Am I missing something or are these two sets identical?
>
> > /* Get the lower and upper bounds of the type. */
> > if (TYPE_OVERFLOW_WRAPS (expr_type))
> > {
> > type_min = wi::min_value (p
On Tue, Apr 10, 2018 at 3:07 PM Jakub Jelinek wrote:
>
> On Tue, Apr 10, 2018 at 02:55:43PM +0200, Richard Biener wrote:
> > > And the easiest solution is in the Fortran FE based on some flag
> > > (e.g. -mveclibabi=glibc) through a target hook add
> > > __at
On Fri, Jun 15, 2018 at 9:59 AM Florian Weimer wrote:
>
> * Richard Biener:
>
> > 'pure' makes it pure but there doesn't seem to be a way to make it const?
>
> Does Fortran support setting the rounding mode?
>
> In C, sin is not const because it depe
On Fri, Jun 15, 2018 at 10:39 AM Szabolcs Nagy wrote:
>
> On 15/06/18 08:59, Florian Weimer wrote:
> > * Richard Biener:
> >
> >> 'pure' makes it pure but there doesn't seem to be a way to make it const?
> >
> > Does Fortran support settin
On Fri, Jun 15, 2018 at 11:08 AM Florian Weimer wrote:
>
> * Richard Biener:
>
> > That said, good to see some glibc folks jump in on this thread.
> > I'd like to see glibc provide a fortran intrinsic header advertising
> > the libmvec routines it has. W
Hi,
I'm in the process of changing the vectorizer to consider all
vector sizes as advertised by targetm.autovectorize_vector_sizes
and to decide which one to use based on its cost model.
I expect that to make sense for example when choosing between
AVX128 and AVX256 since the latter may have pe
On Fri, 15 Jun 2018, Jan Hubicka wrote:
> >
> > Hi,
> >
> > I'm in the process of changing the vectorizer to consider all
> > vector sizes as advertised by targetm.autovectorize_vector_sizes
> > and to decide which one to use based on its cost model.
> >
> > I expect that to make sense for exam
On Fri, Jun 15, 2018 at 10:59 PM Joseph Myers wrote:
>
> On Fri, 15 Jun 2018, Thomas Koenig wrote:
>
> > Hi Richard,
> >
> > > First and foremost we need a syntax that actually works for the
> > > Fortran frontend and a way to automatically include this special
> > > header / module.
> >
> > I can
On June 18, 2018 5:06:08 PM GMT+02:00, Joseph Myers
wrote:
>On Mon, 18 Jun 2018, Richard Biener wrote:
>
>> I'm thinking of sth like the C stdc-predef.h header which is always
>included
>> by the compiler. So it needs to be sth parseable by gfortran which
>means
On Wed, Jun 20, 2018 at 7:31 AM Jeff Law wrote:
>
> On 06/19/2018 12:30 PM, Michael Ploujnikov wrote:
> > Hi everyone,
> >
> > (I hope this is the right place to ask, if not my apologies; please
> > point me in the right direction)
> >
> > I'm trying to get a better understanding of the following
On Wed, Jun 20, 2018 at 8:26 PM Paul Koning wrote:
>
> I'm running into an ICE in the GIMPLE phase, for gcc.c-torture/compile/386.c,
> on pdp11 -mint32. That's an oddball where int is 32 bits (due to the flag)
> but Pmode is 16 bits (HImode).
>
> The ICE message is:
>
> ../../gcc/gcc/testsuite/
On Wed, Jun 20, 2018 at 11:12 PM NightStrike wrote:
>
> On Wed, Jun 6, 2018 at 11:57 AM, Joel Sherrill wrote:
> >
> > On Wed, Jun 6, 2018 at 10:51 AM, Paul Menzel <
> > pmenzel+gcc.gnu@molgen.mpg.de> wrote:
> >
> > > Dear GCC folks,
> > >
> > >
> > > Some scientists in our organization still
On Tue, Jul 3, 2018 at 11:59 AM Andrew Stubbs wrote:
>
> Hi All,
>
> I'm trying to implement maskload/maskstore for AMD GCN, which has up-to
> 64-lane, 512-byte fully-masked vectors. All seems fine as far as the
> vector operations themselves go, but I've found a problem with the RTL
> Dead Store
On Tue, Jul 3, 2018 at 12:57 PM Andrew Stubbs wrote:
>
> On 03/07/18 11:33, Andrew Stubbs wrote:
> > On 03/07/18 11:15, Richard Biener wrote:
> >> AVX ones are all UNSPECs I believe - how do your patterns look like?
> >
> > AVX has both unspec and vec_merge var
On Tue, Jul 3, 2018 at 1:06 PM Andrew Stubbs wrote:
>
> On 03/07/18 12:02, Richard Biener wrote:
> > I believe that the AVX variants like
> >
> > (define_expand "maskstore"
> >[(set (match_operand:V48_AVX512VL 0 "memory_o
On Tue, Jul 3, 2018 at 1:38 PM Andrew Stubbs wrote:
>
> On 03/07/18 12:30, Richard Biener wrote:
> >> Hmm, so they're safe, but may prevent the optimization of nearby variables?
> >
> > Yes, they prevent earlier stores into lanes that are "really" writte
On Tue, Jul 3, 2018 at 1:57 PM Andrew Stubbs wrote:
>
> On 03/07/18 12:45, Richard Biener wrote:
> > On Tue, Jul 3, 2018 at 1:38 PM Andrew Stubbs
> > wrote:
> >>
> >> On 03/07/18 12:30, Richard Biener wrote:
> >>>> Hmm, so they&
On Tue, Jul 3, 2018 at 2:46 PM Andrew Stubbs wrote:
>
> On 03/07/18 13:21, Richard Biener wrote:
> > Ok, so if we vectorize the above with 64 element masked stores
> > then indeed the RTL representation is _not_ safe. That is because
> > while the uses in the masked stor
On July 3, 2018 5:19:24 PM GMT+02:00, Andrew Stubbs
wrote:
>On 03/07/18 14:52, Richard Biener wrote:
>> If you look at RTL dumps (with -fstrict-aliasing, thus -O2+) you
>should
>> see MEM_ALIAS_SETs differing for the earlier stores and the masked
>> store uses.
>>
On July 3, 2018 4:56:57 PM GMT+02:00, Michael Ploujnikov
wrote:
>On 2018-06-20 04:23 AM, Richard Biener wrote:
>> On Wed, Jun 20, 2018 at 7:31 AM Jeff Law wrote:
>>>
>>> On 06/19/2018 12:30 PM, Michael Ploujnikov wrote:
>>>> Hi everyone,
>>>>
On July 3, 2018 6:01:19 PM GMT+02:00, Qing Zhao wrote:
>Hi,
>
>In order to collect complete information on all the inlining
>transformation that GCC applies on a given program,
>I searched online, and found that the option -fopt-info-inline might be
>the right option to use:
>
>https://gcc.gnu.org
On Tue, Jul 3, 2018 at 9:09 PM Jeff Law wrote:
>
> On 07/03/2018 11:55 AM, Michael Ploujnikov wrote:
> > On 2018-07-03 12:46 PM, Richard Biener wrote:
> >> On July 3, 2018 4:56:57 PM GMT+02:00, Michael Ploujnikov
> >> wrote:
> >>> On 2018-06-20 04:23 AM
On Thu, Jul 5, 2018 at 9:47 AM Aldy Hernandez wrote:
>
> After 20 years of hacking on GCC I feel like I have literally wasted
> days of my life typing out ChangeLog entries that could have easily been
> generated programmatically.
>
> Can someone refresh my memory here, what are the remaining argu
On Thu, Jul 5, 2018 at 12:13 PM Eric Botcazou wrote:
>
> > They are definitely useful in my day-to-day work when tracking down changes
> > given I can easily grep them.
>
> Seconded.
>
> > I think that any change here should be _after_ we've switched to git
> > (finally).
>
> Well, git doesn't mak
On Thu, Jul 5, 2018 at 1:01 PM Jakub Jelinek wrote:
>
> On Thu, Jul 05, 2018 at 06:46:11AM -0400, Aldy Hernandez wrote:
> > However, even if you could "git log --grep" the commit messages, I assume
> > your current use is grepping for function names and such, right? Being able
> > to grep a commit
On Thu, Jul 5, 2018 at 1:48 PM NightStrike wrote:
>
> On Thu, Jul 5, 2018 at 6:28 AM, Richard Biener
> wrote:
> > On Thu, Jul 5, 2018 at 12:13 PM Eric Botcazou wrote:
> >>
> >> > They are definitely useful in my day-to-day work when tracking down
> >
On July 5, 2018 6:37:58 PM GMT+02:00, Martin Sebor wrote:
>Ada tests don't seem to respond to the INT signal: when
>I interrupt a parallel make check while the Ada tests are
>running, other test suites are interrupted as well and go
>away, but ada tests keep running. Is there some trick to
>have
1301 - 1400 of 2616 matches
Mail list logo
