On Tue, Jul 24, 2018 at 12:02 PM Richard Sandiford
wrote:
>
> This patch changes LOOP_VINFO_MAY_MISALIGN_STMTS from an
> auto_vec to an auto_vec.
OK.
>
> 2018-07-24 Richard Sandiford
>
> gcc/
> * tree-vectorizer.h (_loop_vec_info::may_misalign_stmts): Change
> from an auto_vec
On Tue, Jul 24, 2018 at 12:02 PM Richard Sandiford
wrote:
>
> This patch makes stmt_info_for_cost carry a stmt_vec_info instead
> of a gimple stmt. The structure is internal to the vectoriser,
> so targets aren't affected.
OK
>
> 2018-07-24 Richard Sandiford
>
> gcc/
> * tree-vectori
On Tue, Jul 24, 2018 at 12:03 PM Richard Sandiford
wrote:
>
> ...and also make vect_find_last_scalar_stmt_in_slp return a stmt_vec_info.
OK
>
> 2018-07-24 Richard Sandiford
>
> gcc/
> * tree-vectorizer.h (get_earlier_stmt, get_later_stmt): Take and
> return stmt_vec_infos rath
On Tue, Jul 24, 2018 at 12:03 PM Richard Sandiford
wrote:
>
> If we use stmt_vec_infos to represent statements in the vectoriser,
> it's then more natural to use dyn_cast when processing the statement
> as an assignment, call, etc. This patch does that in a few more places.
OK.
>
> 2018-07-24
On Tue, Jul 24, 2018 at 12:03 PM Richard Sandiford
wrote:
>
> Various places called vect_dr_stmt or vinfo_for_stmt multiple times
> on the same input. This patch makes them reuse the earlier result.
> It also splits a couple of single vinfo_for_stmt calls out into
> separate statements so that th
On Tue, Jul 24, 2018 at 12:04 PM Richard Sandiford
wrote:
>
> This first part makes functions use stmt_vec_infos instead of
> gimple stmts in cases where the stmt_vec_info was already available
> and where the change is mechanical. Most of it is just replacing
> "stmt" with "stmt_info".
OK
>
>
On Wed, 25 Jul 2018, Richard Earnshaw (lists) wrote:
> On 24/07/18 17:30, Richard Biener wrote:
> > On July 24, 2018 5:50:33 PM GMT+02:00, Ramana Radhakrishnan
> > wrote:
> >> On Thu, Jul 19, 2018 at 10:11 AM, Richard Biener
> >> wrote:
> >>>
&g
On Tue, Jul 24, 2018 at 12:04 PM Richard Sandiford
wrote:
>
> This second part handles the less mechnical cases, i.e. those that don't
> just involve swapping a gimple stmt for an existing stmt_vec_info.
OK.
>
> 2018-07-24 Richard Sandiford
>
> gcc/
> * tree-vect-loop.c (vect_analyze_
On Tue, Jul 24, 2018 at 12:05 PM Richard Sandiford
wrote:
>
> 2018-07-24 Richard Sandiford
>
> gcc/
> * tree-vect-loop.c (vect_analyze_scalar_cycles_1): Change the type
> of the worklist from a vector of gimple stmts to a vector of
> stmt_vec_infos.
> * tree-vect
On Tue, Jul 24, 2018 at 12:05 PM Richard Sandiford
wrote:
>
> This first (less mechanical) part handles cases that involve changes in
> the callers or non-trivial changes in the functions themselves.
OK
>
> 2018-07-24 Richard Sandiford
>
> gcc/
> * tree-vect-data-refs.c (vect_describe
On Tue, Jul 24, 2018 at 12:06 PM Richard Sandiford
wrote:
>
> This patch makes vect_record_max_nunits and vect_record_base_alignment
> take a stmt_vec_info instead of a vec_info/gimple pair.
OK
>
> 2018-07-24 Richard Sandiford
>
> gcc/
> * tree-vect-data-refs.c (vect_record_base_align
On Tue, Jul 24, 2018 at 12:06 PM Richard Sandiford
wrote:
>
> This second part handles the mechanical change from a gimple stmt
> argument to a stmt_vec_info argument. It updates the function
> comments if they referred to the argument by name, but it doesn't
> try to retrofit mentions to other f
On Tue, Jul 24, 2018 at 12:06 PM Richard Sandiford
wrote:
>
> This patch makes vect_get_vec_def_for_stmt_copy take a vec_info
> rather than a vect_def_type. If the vector operand passed in is
> defined in the vectorised region, we should look for copies in
> the normal way. If it's defined in an
On Tue, Jul 24, 2018 at 12:06 PM Richard Sandiford
wrote:
>
> vect_pattern_recog_1 took a gimple_stmt_iterator as argument, but was
> only interested in the gsi_stmt, not anything else. This patch makes
> the associated routines operate directly on stmt_vec_infos.
OK
>
> 2018-07-24 Richard San
On Tue, Jul 24, 2018 at 12:07 PM Richard Sandiford
wrote:
>
> This patch adds a pattern_stmt_p field to stmt_vec_info, so that it's
> possible to tell whether the statement is a pattern statement without
> referring to other statements. The new field goes in what was
> previously a hole in the st
On Tue, Jul 24, 2018 at 12:08 PM Richard Sandiford
wrote:
>
> Alignment information is really a property of a stmt_vec_info
> (and the way we want to vectorise it) rather than the original scalar dr.
> I think that was true even before the recent dr sharing.
But that is only so as long as we hand
On Tue, Jul 24, 2018 at 12:08 PM Richard Sandiford
wrote:
>
> This patch makes various routines (mostly in tree-vect-data-refs.c)
> take stmt_vec_infos rather than data_references. The affected routines
> are really dealing with the way that an access is going to vectorised
> for a particular stm
On Wed, Jul 25, 2018 at 11:49 AM Richard Earnshaw (lists)
wrote:
>
> On 24/07/18 18:26, Richard Biener wrote:
> > On Mon, Jul 9, 2018 at 6:40 PM Richard Earnshaw
> > wrote:
> >>
> >>
> >> This patch defines a new intrinsic function
> >>
On Wed, Jul 25, 2018 at 11:50 AM Segher Boessenkool
wrote:
>
> On Wed, Jul 25, 2018 at 10:28:30AM +0200, Richard Biener wrote:
> > On Tue, Jul 24, 2018 at 7:18 PM Segher Boessenkool
> > wrote:
> > >
> > > This patch allows combine to combine two insns into
On Tue, 24 Jul 2018, Tom de Vries wrote:
> On Tue, Jul 24, 2018 at 02:34:26PM +0200, Tom de Vries wrote:
> > On 07/24/2018 01:46 PM, Jakub Jelinek wrote:
> > > On Tue, Jul 24, 2018 at 01:37:32PM +0200, Tom de Vries wrote:
> > >> Another drawback is that the fake uses confuse the unitialized warnin
On Wed, Jul 25, 2018 at 1:41 PM Richard Biener wrote:
>
> On Tue, 24 Jul 2018, Tom de Vries wrote:
>
> > On Tue, Jul 24, 2018 at 02:34:26PM +0200, Tom de Vries wrote:
> > > On 07/24/2018 01:46 PM, Jakub Jelinek wrote:
> > > > On Tue, Jul 24, 2018 at
On Wed, Jul 25, 2018 at 1:09 PM Richard Sandiford
wrote:
>
> Richard Biener writes:
> > On Tue, Jul 24, 2018 at 12:07 PM Richard Sandiford
> > wrote:
> >>
> >> This patch adds a pattern_stmt_p field to stmt_vec_info, so that it's
> >> p
On Tue, 24 Jul 2018, Richard Biener wrote:
>
> I am testing the following patch to avoid forcing DIEs for a type context
> for method clones late via limbo processing. Instead hang them off
> comp_unit_die if there is no early DIE for the function.
>
> One question is wheth
On Wed, Jul 25, 2018 at 2:41 PM Richard Earnshaw (lists)
wrote:
>
> On 25/07/18 11:36, Richard Biener wrote:
> > On Wed, Jul 25, 2018 at 11:49 AM Richard Earnshaw (lists)
> > wrote:
> >>
> >> On 24/07/18 18:26, Richard Biener wrote:
> >>>
On Wed, Jul 25, 2018 at 3:38 PM Martin Liška wrote:
>
> Hi.
>
> Target clones have DECL_ARTIFICIAL set to 1, but we want to
> provide --coverage for that. With patched GCC on can see:
>
> -:0:Source:pr85370.c
> -:0:Graph:pr85370.gcno
> -:0:Data:pr85370.gcda
>
gt; + when optimization level is lower than 2 or optimize for size.
> +
>
> gcc/testsuite/ChangeLog:
>
> +2018-07-25 Qing Zhao
> +
> + * gcc.dg/strcmpopt_5.c: Change to O2 to enable the transformation.
> + * gcc.dg/strcmpopt_6.c: Likewise.
> +
On Wed, Jul 25, 2018 at 5:30 PM Cesar Philippidis
wrote:
>
> This patch teaches GCC to inform the user how it assigned parallelism
> to each OpenACC loop at compile time using the -fopt-info-note-omp
> flag. For instance, given the acc parallel loop nest:
>
> #pragma acc parallel loop
> for (.
On Wed, Jul 25, 2018 at 5:54 PM Martin Sebor wrote:
>
> On 07/25/2018 08:57 AM, Jakub Jelinek wrote:
> > On Wed, Jul 25, 2018 at 08:54:13AM -0600, Martin Sebor wrote:
> >> I don't mean for the special value to be used except internally
> >> for the defaults. Otherwise, users wanting to override t
On Wed, Jul 25, 2018 at 8:03 PM Richard Earnshaw (lists)
wrote:
>
> On 24/07/18 18:26, Richard Biener wrote:
> > So, please make resolve_overloaded_builtin return a no-op on such targets
> > which means you can remove the above warning. Maybe such targets
> > shouldn'
On Wed, 25 Jul 2018, Martin Sebor wrote:
> > BUT - for the string_constant and c_strlen functions we are,
> > in all cases we return something interesting, able to look
> > at an initializer which then determines that type. Hopefully.
> > I think the strlen() folding code when it sets SSA ranges
On Thu, Jul 26, 2018 at 10:44 AM Martin Liška wrote:
>
> On 07/25/2018 03:50 PM, Richard Biener wrote:
> > On Wed, Jul 25, 2018 at 3:38 PM Martin Liška wrote:
> >>
> >> Hi.
> >>
> >> Target clones have DECL_ARTIFICIAL set to 1, but we want to
>
makes it the default,
> + ABI incompatibilities between GCC 8.1 and 8.2 can be reported with
> + -Wabi=12. See C++ changes for more
> + details.
> +
> Target Specific Changes
>
> IA-32/x86-64
>
> Jakub
>
>
--
Richard Biener
SUSE LINUX GmbH, GF: Felix Imendoerffer, Jane Smithard, Graham Norton, HRB
21284 (AG Nuernberg)
On Thu, Jul 26, 2018 at 12:55 PM Richard Sandiford
wrote:
>
> Richard Biener writes:
> > On Tue, Jul 24, 2018 at 12:08 PM Richard Sandiford
> > wrote:
> >>
> >> Alignment information is really a property of a stmt_vec_info
> >> (and the way we w
On Thu, Jul 26, 2018 at 1:05 PM Richard Sandiford
wrote:
>
> Richard Sandiford writes:
> > Richard Biener writes:
> >> On Tue, Jul 24, 2018 at 12:08 PM Richard Sandiford
> >> wrote:
> >>>
> >>> This patch makes various routines (mostly in t
On Thu, Jul 26, 2018 at 1:08 PM Richard Sandiford
wrote:
>
> [Updated after new 37/46 and 38/46]
>
> After previous changes, it makes more sense for STMT_VINFO_UNALIGNED_DR
> to be dr_vec_info rather than a data_reference.
OK.
>
> 2018-07-26 Richard Sandiford
>
> gcc/
> * tree-vectori
On Thu, Jul 26, 2018 at 12:29 PM Richard Sandiford
wrote:
>
> Richard Biener writes:
> > On Wed, Jul 25, 2018 at 1:09 PM Richard Sandiford
> > wrote:
> >>
> >> Richard Biener writes:
> >> > On Tue, Jul 24, 2018 at 12:07 PM Richard Sandiford
On Thu, Jul 26, 2018 at 1:10 PM Richard Sandiford
wrote:
>
> [Updated after new 37/46 and 38/46. 41 onwards are unaffected.]
>
> This patch replaces DR_VECT_AUX and vect_dr_stmt with a new
> vec_info::lookup_dr function, so that the lookup is relative
> to a particular vec_info rather than to glo
On Thu, Jul 26, 2018 at 12:12 PM Segher Boessenkool
wrote:
>
> The current code in reg_nonzero_bits_for_combine allows using the
> reg_stat info when last_set_mode is a different integer mode. This is
> completely wrong for non-pseudos. For example, as in the PR, a value
> in a DImode hard regis
On Thu, Jul 26, 2018 at 12:29 PM Alexander Monakov wrote:
>
> Hi,
>
> when using explicit register variables ('register int foo asm("%ebp");'),
> using const/volatile type qualifiers on the declaration does not result in
> the logically expected effect.
>
> The main issue is that gcc-8 got "better
On Thu, Jul 26, 2018 at 12:55 PM Martin Liška wrote:
>
> Hi.
>
> As requested in the PR, now we produce prefixes for temp files in LTO:
>
> Example:
> $ gcc -flto main.o a.o --save-temps -o mybinary
>
> generates:
> $ ls /tmp/mybinary*
> /tmp/mybinary /tmp/mybinary.ltrans0.o /tmp/mybinary.ltrans
On Thu, Jul 26, 2018 at 2:12 PM Martin Liška wrote:
>
> On 07/26/2018 01:34 PM, Richard Biener wrote:
> > On Thu, Jul 26, 2018 at 12:55 PM Martin Liška wrote:
> >>
> >> Hi.
> >>
> >> As requested in the PR, now we produce prefixes for temp files in
On Thu, Jul 26, 2018 at 12:03 PM Richard Earnshaw (lists)
wrote:
>
> On 25/07/18 14:47, Richard Biener wrote:
> > On Wed, Jul 25, 2018 at 2:41 PM Richard Earnshaw (lists)
> > wrote:
> >>
> >> On 25/07/18 11:36, Richard Biener wrote:
> >>> On Wed,
On Thu, Jul 26, 2018 at 3:06 PM Richard Earnshaw (lists)
wrote:
>
> On 26/07/18 13:41, Richard Biener wrote:
> > On Thu, Jul 26, 2018 at 12:03 PM Richard Earnshaw (lists)
> > wrote:
> >>
> >> On 25/07/18 14:47, Richard Biener wrote:
> >>> On Wed,
This patch from jwjager...@gmail.com clones the fixes done for
mingw and darwin to make LTO work together with -g in GCC 8+.
It's said to build OK in a djgpp configuration and I expect similar
results as for mingw and darwin.
The original application the reporter ran into the issue with isn't
f
On July 27, 2018 3:33:59 PM GMT+02:00, "Martin Liška" wrote:
>On 07/11/2018 02:31 PM, Richard Biener wrote:
>> Why not simply make popcountdi available in the kernel? They do have
>> implementations for other libgcc functions IIRC.
>
>Can you please Kugan creat
On July 27, 2018 3:27:49 PM GMT+02:00, Paul Koning
wrote:
>
>
>> On Jul 27, 2018, at 5:37 AM, Richard Earnshaw
> wrote:
>>
>>
>> This patch is intended as an example of all that is needed if the
>> target system doesn't support CPUs that have speculative execution.
>> I've chosen the pdp11 port
On Sun, 29 Jul 2018, Bernd Edlinger wrote:
> Hi!
>
> This fixes another not NUL terminated string literal that is created
> in tree-ssa-forwprop.c at simplify_builtin_call.
>
> src_buf is set up to contain a NUL at src_buf[src_len], thus use src_len + 1
> as length parameter to build_string_lite
On Sun, 29 Jul 2018, Martin Sebor wrote:
> On 07/29/2018 04:56 AM, Bernd Edlinger wrote:
> > Hi!
> >
> > This fixes two wrong code bugs where string_constant
> > returns over length string constants. Initializers
> > like that are rejected in C++, but valid in C.
>
> If by valid you are referri
On Mon, 30 Jul 2018, Bernd Edlinger wrote:
> Hi,
>
> this is how I would like to handle the over length strings issue in the C FE.
> If the string constant is exactly the right length and ends in one explicit
> NUL character, shorten it by one character.
>
> I thought Martin would be working on
er-3.c | 13 +++
> 17 files changed, 543 insertions(+), 1 deletion(-)
> create mode 100644 gcc/testsuite/c-c++-common/spec-barrier-1.c
> create mode 100644 gcc/testsuite/c-c++-common/spec-barrier-2.c
> create mode 100644 gcc/testsuite/gcc.dg/spec-barrier-3.c
>
>
--
Richard Biener
SUSE LINUX GmbH, GF: Felix Imendoerffer, Jane Smithard, Graham Norton, HRB
21284 (AG Nuernberg)
cc/targhooks.c | 7 +++
> gcc/targhooks.h | 1 +
> 4 files changed, 19 insertions(+), 1 deletion(-)
>
>
--
Richard Biener
SUSE LINUX GmbH, GF: Felix Imendoerffer, Jane Smithard, Graham Norton, HRB
21284 (AG Nuernberg)
On Sun, Jul 29, 2018 at 6:27 PM Jozef Lawrynowicz
wrote:
>
> pr45678-2.c ICEs for msp430-elf with -mlarge, because an alignment of
> POINTER_SIZE is attempted. POINTER_SIZE with -mlarge is 20-bits, so further
> code in the middle-end that expects this to be a power or 2 causes odd
> alignments to
On July 30, 2018 4:41:19 PM GMT+02:00, Bernd Edlinger
wrote:
>
>
>On 07/30/18 15:03, Richard Biener wrote:
>> On Mon, 30 Jul 2018, Bernd Edlinger wrote:
>>
>>> Hi,
>>>
>>> this is how I would like to handle the over length strings issue in
>
t;-g" }
> +
> +class string {
> +public:
> + string (int p) { this->p = p ; }
> + string (const string &s) { this->p = s.p; }
> +
> + int p;
> +};
> +
> +class foo {
> +public:
> + foo (string dir_hint) {
> +p = dir_hint.p; // { dg-final { gdb-test . "dir_hint.p" 3 } }
> + }
> +
> + int p;
> +};
> +
> +int
> +main (void)
> +{
> + string s = 3;
> + foo bar(s);
> + return !(bar.p == 3);
> +}
>
>
--
Richard Biener
SUSE LINUX GmbH, GF: Felix Imendoerffer, Jane Smithard, Graham Norton, HRB
21284 (AG Nuernberg)
On Mon, Jul 30, 2018 at 10:16 PM Martin Sebor wrote:
>
> The enhanced handling of MEM_REFs in -Warray-bounds assumes
> the object from whose address an offset is being computed has
> a complete type. Since the size of such objects isn't known,
> whether the offset (or index) from its beginning is
On Tue, 31 Jul 2018, Tamar Christina wrote:
> Ping 😊
>
> > -Original Message-
> > From: gcc-patches-ow...@gcc.gnu.org
> > On Behalf Of Tamar Christina
> > Sent: Tuesday, July 24, 2018 17:34
> > To: Richard Biener
> > Cc: gcc-patches@gcc.gnu.or
On Tue, Jul 31, 2018 at 12:35 AM Alexandre Oliva wrote:
>
> On Jul 24, 2018, Alexandre Oliva wrote:
>
> > Ok to install the first two patches? (the third is just for reference)
>
> Ping?
>
> https://gcc.gnu.org/ml/gcc-patches/2018-07/msg01419.html
OK for the middle-end parts, the Ada parts need
On Mon, Jul 30, 2018 at 7:47 PM Richard Sandiford
wrote:
>
> [Sorry, somehow missed this till now]
>
> Richard Biener writes:
> > On Mon, Jul 23, 2018 at 5:05 PM Richard Sandiford
> > wrote:
> >>
> >> Marc Glisse writes:
> >
On Tue, Jul 24, 2018 at 12:09 PM Richard Sandiford
wrote:
>
> This patch adds a new helper function for permanently removing a
> statement and its associated stmt_vec_info.
OK.
>
> 2018-07-24 Richard Sandiford
>
> gcc/
> * tree-vectorizer.h (vec_info::remove_stmt): Declare.
>
On Tue, Jul 24, 2018 at 12:09 PM Richard Sandiford
wrote:
>
> This patch adds a helper for replacing a stmt_vec_info's statement with
> a new statement.
OK.
>
> 2018-07-24 Richard Sandiford
>
> gcc/
> * tree-vectorizer.h (vec_info::replace_stmt): Declare.
> * tree-vectorizer.c
On Tue, Jul 24, 2018 at 12:10 PM Richard Sandiford
wrote:
>
> This patch makes free_stmt_vec_info take the stmt_vec_info that
> it's supposed to free and makes it free only that stmt_vec_info.
> Callers need to update the statement mapping where necessary
> (but now there are only a couple of call
On Tue, Jul 24, 2018 at 12:10 PM Richard Sandiford
wrote:
>
> There are no more direct uses of:
>
> - new_stmt_vec_info
> - set_vinfo_for_stmt
> - free_stmt_vec_infos
> - free_stmt_vec_info
>
> outside of vec_info, so they can now be private member functions.
> It also seemed better to put them in
On Tue, Jul 24, 2018 at 12:11 PM Richard Sandiford
wrote:
>
> Unlike the old vinfo_for_stmt, vec_info::lookup_stmt can cope with
> any statement, so there's no need to check beforehand that the statement
> is part of the vectorisable region. This means that there are no longer
> any calls to vect
On Tue, Jul 24, 2018 at 12:11 PM Richard Sandiford
wrote:
>
> This patch removes the stmt_vec_info wrapper class added near the
> beginning of the series and turns stmt_vec_info back into a typedef.
>
OK. For the whole series now if I didn't miss anything...
Richard.
> 2018-07-24 Richard Sand
On Tue, Jul 24, 2018 at 3:47 PM Martin Jambor wrote:
>
> Hi,
>
> I'd like to propose again a new variant of a fix that I sent here in
> November (https://gcc.gnu.org/ml/gcc-patches/2017-10/msg00881.html) that
> avoids store-to-load forwarding stalls in the ImageMagick benchmark by
> expanding copi
On Fri, Jul 27, 2018 at 11:47 PM David Malcolm wrote:
>
> This patch kit converts dump_print and dump_printf_loc from using
> fprintf etc internally to using a new pretty-printer
> based on pp_format, which supports formatting middle-end types.
>
> In particular, the following codes are implemente
On Fri, Jul 27, 2018 at 11:48 PM David Malcolm wrote:
>
> This patch removes some duplicated code in dumpfile.c by
> reimplementing the various dump_foo_loc calls in terms of dump_foo.
OK.
Richard.
> gcc/ChangeLog:
> * dump-context.h (dump_context::dump_loc): New decl.
> * dumpf
On Fri, Jul 27, 2018 at 11:48 PM David Malcolm wrote:
>
> With the addition of optinfo, the various dump_* calls had three parts:
> - optionally print to dump_file
> - optionally print to alt_dump_file
> - optionally make an optinfo_item and add it to the pending optinfo,
> creating it for dump_
On Fri, Jul 27, 2018 at 11:48 PM David Malcolm wrote:
>
> The format_char_info tables in c-format.c for our own formats contain
> a lot of repetition.
>
> This patch adds a macro to express the conversion specifiers implemented
> within pp_format, making it clearer which are custom ones added by t
On Fri, Jul 27, 2018 at 11:49 PM David Malcolm wrote:
>
> This patch converts dump_print and dump_printf_loc from using
> printf (and thus ATTRIBUTE_PRINTF) to using a new pretty-printer
> based on pp_format, which supports formatting middle-end types.
>
> In particular, the following codes are im
On Sat, 28 Jul 2018, Andris Pavenis wrote:
> On 07/27/2018 11:51 PM, DJ Delorie wrote:
> > Richard Biener writes:
> > > DJ, did you ever run the testsuite with a configuration that has LTO
> > > enabled? I don't see any djgpp results posted to gcc-testresults.
&g
On Tue, Jul 31, 2018 at 4:19 PM David Malcolm wrote:
>
> On Tue, 2018-07-31 at 15:03 +0200, Richard Biener wrote:
> > On Fri, Jul 27, 2018 at 11:49 PM David Malcolm
> > wrote:
> > >
> > > This patch converts dump_print and dump_printf_loc from using
> &g
On Tue, Jul 31, 2018 at 4:21 PM Richard Biener
wrote:
>
> On Tue, Jul 31, 2018 at 4:19 PM David Malcolm wrote:
> >
> > On Tue, 2018-07-31 at 15:03 +0200, Richard Biener wrote:
> > > On Fri, Jul 27, 2018 at 11:49 PM David Malcolm
> > > wrote:
> > >
On Tue, Jul 31, 2018 at 2:07 PM Paul Richard Thomas
wrote:
>
> Daniel Celis Garza and Damian Rouson have developed a runtime library
> and include file for the TS 29113 and F2018 C descriptors.
> https://github.com/sourceryinstitute/ISO_Fortran_binding
>
> The ordering of types is different to the
On Tue, Jul 31, 2018 at 5:34 PM David Malcolm wrote:
>
> On Tue, 2018-07-31 at 14:53 +0200, Richard Biener wrote:
> > On Fri, Jul 27, 2018 at 11:48 PM David Malcolm
> > wrote:
> > >
> > > With the addition of optinfo, the various dump_* calls had three
>
On Tue, 31 Jul 2018, Tamar Christina wrote:
> Hi Richard,
>
> The 07/31/2018 11:21, Richard Biener wrote:
> > On Tue, 31 Jul 2018, Tamar Christina wrote:
> >
> > > Ping 😊
> > >
> > > > -Original Message-
> > > > From: gcc-
ny GCC middle-end
> or global maintainer. It's not part of the code copied from another
> repo, which lives in gcc/go/gofrontend.
The change to have all STRING_CSTs NUL terminated (but that NUL
termination not necessarily inclided in STRING_LENGTH) is a good
one.
I'm not sure how we can reliably verify NUL termination after the
fact though and build_string already makes sure to NUL terminate
STRING_CSTs. So if GO strings are not NUL terminated then
the STRING_CSTs still are.
Bernd?
Richard.
> Ian
>
>
--
Richard Biener
SUSE LINUX GmbH, GF: Felix Imendoerffer, Jane Smithard, Graham Norton, HRB
21284 (AG Nuernberg)
The following fixes build with ISL 0.20, tested by building with
ISL 0.20 and 0.15 (the oldest supported ISL).
Applied to trunk, will commit to the branches as well.
Richard.
2018-08-01 Richard Biener
PR bootstrap/86724
* graphite.h: Include isl/id.h and isl/space.h to
On Tue, 31 Jul 2018, Martin Sebor wrote:
> On 07/31/2018 09:48 AM, Jakub Jelinek wrote:
> > On Tue, Jul 31, 2018 at 09:17:52AM -0600, Martin Sebor wrote:
> > > On 07/31/2018 12:38 AM, Jakub Jelinek wrote:
> > > > On Mon, Jul 30, 2018 at 09:45:49PM -0600, Martin Sebor wrote:
> > > > > Even without
use
of embedded NULs.
> Additionally not having oversize string constants produced
> by the front ends, where the extra characters are good for nothing,
> also helps to improve correctness.
>
>
> Bernd.
>
--
Richard Biener
SUSE LINUX GmbH, GF: Felix Imendoerffer, Jane Smithard, Graham Norton, HRB
21284 (AG Nuernberg)
ot of
> intersting
> things.
> I will post several patches in the afternoon.
>
> > Relying on the type here looks somewhat fragile to me.
> >
> > Abstracting a string_cst_nul_terminated_p () helper would be a good
> > idea I guess.
>
> Yes. indeed.
>
> > I realize using strlen(TREE_STRING_POINTER) doesn't work because
> > of embedded NULs.
> >
> >> Additionally not having oversize string constants produced
> >> by the front ends, where the extra characters are good for nothing,
> >> also helps to improve correctness.
> >>
>
>
--
Richard Biener
SUSE LINUX GmbH, GF: Felix Imendoerffer, Jane Smithard, Graham Norton, HRB
21284 (AG Nuernberg)
On Mon, Jul 30, 2018 at 9:09 AM Aldy Hernandez wrote:
>
> ...well, most of them anyhow...
>
> I got tired of submitting these piecemeal, and it's probably easier to
> review them in one go.
>
> There should be no difference in functionality, barring an extra call to
> set_and_canonicalize_value_ra
On Tue, Jul 31, 2018 at 7:40 PM Michael Ploujnikov
wrote:
>
> On 2018-07-26 01:27 PM, Michael Ploujnikov wrote:
> > On 2018-07-24 09:57 AM, Michael Ploujnikov wrote:
> >> On 2018-07-20 06:05 AM, Richard Biener wrote:
> >>>> /* Return a new assembler name for
On Fri, Oct 20, 2023 at 4:21 AM liuhongt wrote:
>
> >So with pow being available this limit shouldn't be necessary any more and
> >the testcase adjustment can be avoided?
> I tries, compile time still hogs on mpz_powm(3, INT_MAX), so i'll just
> keep this.
Doh :/ Maybe it's possible to limit the
On Fri, Oct 20, 2023 at 8:09 AM Alexandre Oliva wrote:
>
> On Oct 19, 2023, Richard Biener wrote:
>
> > Maybe time to do s/make_eh_edges/make_eh_edge/ though.
>
> How about this? Regstrapped on x86_64-linux-gnu and ppc64le-linux-gnu,
> on top of the patches for strub, ha
I went a little bit too simple with implementing SLP gather support
for emulated and builtin based gathers. The following fixes the
conflict that appears when running into .MASK_LOAD where we rely
on vect_get_operand_map and the bolted-on STMT_VINFO_GATHER_SCATTER_P
checking wrecks that. The foll
On Fri, 20 Oct 2023, Lehua Ding wrote:
> Hi Richard,
>
> I recompile the testcase with the fixup patch and still get the same ICE.
The following fixes it.
>From 377e911b1b64298def75ba9d9c46fdd22fe4cf84 Mon Sep 17 00:00:00 2001
From: Richard Biener
Date: Fri, 20 Oct 2023 10:25:31 +
On Fri, 20 Oct 2023, Richard Biener wrote:
> I went a little bit too simple with implementing SLP gather support
> for emulated and builtin based gathers. The following fixes the
> conflict that appears when running into .MASK_LOAD where we rely
> on vect_get_operand_map and t
The following makes sure to rewrite all gather/scatter detected by
dataref analysis plus stmts classified as VMAT_GATHER_SCATTER. Maybe
we need to rewrite all refs, the following covers the cases I've
run into now.
Bootstrapped and tested on x86_64-unknown-linux-gnu, pushed.
* tree-vect-
The following amends the {L,R}SHIFT_EXPR documentation with
documentation about the {L,R}ROTATE_EXPR case.
Build on x86_64-unknown-linux-gnu, pushed.
* doc/generic.texi ({L,R}ROTATE_EXPR): Document.
---
gcc/doc/generic.texi | 18 +++---
1 file changed, 11 insertions(+), 7 del
The following restricts moving variable shifts to when they are
always executed in the loop as we currently do not have an efficient
way to rewrite them to something that is unconditionally
well-defined and value range analysis will otherwise compute
invalid ranges for the shift operand.
Bootstrap
The following fixes the assert in vectorizable_simd_clone_call to
assert we have a vector type during transform. Whether we have
one during analysis depends on whether another SLP user decided
on the type of a constant/external already. When we end up with
a mismatch in desire the updating will f
The following addresses IVOPTs rewriting expressions in its
strip_offset without caring for definedness of overflow. Rather
than the earlier attempt of just using the proper
split_constant_offset from data-ref analysis the following adjusts
IVOPTs helper trying to minimize changes from this fix, p
The following fixes a missed check in the simple_iv attempt
to simplify (signed T)((unsigned T) base + step) where it
allows a truncating inner conversion leading to wrong code.
Bootstrap and regtest running on x86_64-unknown-linux-gnu.
PR tree-optimization/111445
* tree-scalar-ev
s_prolog,
> + vect_set_loop_condition (prolog, prolog_e, NULL, niters_prolog,
> step_prolog, NULL_TREE, false);
>
>/* Skip the prolog loop. */
>
>
>
>
>
--
Richard Biener
SUSE Software Solutions Germany GmbH,
Frankenstrasse 146, 90461 Nuernberg, Germany;
GF: Ivo Totev, Andrew McDonald, Werner Knoblich; (HRB 36809, AG Nuernberg)
ad of TREE_CONSTANT.
OK with those changes.
Richard.
> gcc/ChangeLog:
>
> PR tree-optimization/111882
> * tree-if-conv.cc (get_bitfield_rep): Return NULL_TREE for bitfields
> with
> non-constant offsets.
>
> gcc/testsuite/ChangeLog:
>
>
Pushed.
PR tree-optimization/111383
PR tree-optimization/110243
gcc/testsuite/
* gcc.dg/torture/pr111383.c: New testcase.
---
gcc/testsuite/gcc.dg/torture/pr111383.c | 29 +
1 file changed, 29 insertions(+)
create mode 100644 gcc/testsuite/gcc.dg
> Am 20.10.2023 um 15:47 schrieb Andre Vieira (lists)
> :
>
>
>
>> On 20/10/2023 14:41, Richard Biener wrote:
>>> On Fri, 20 Oct 2023, Andre Vieira (lists) wrote:
>>> Hi,
>>>
>>> This patch stops lowering of bitfields by ifcvt whe
> Am 20.10.2023 um 19:09 schrieb Qing Zhao :
>
> Sid,
>
> (Richard, can you please help me to make sure this? Thanks a lot)
>
> I studied a little bit more on the following question you raised during the
> review process:
>
> For the following small testing case:
>
> 1 struct annotated
On Sat, Oct 21, 2023 at 8:07 PM Andrew Pinski wrote:
>
> convert_to_complex when creating a COMPLEX_EXPR does
> not currently check if either the real or imag parts
> was not error_mark_node. This later on confuses the gimpilfier
> when there was a SAVE_EXPR wrapped around that COMPLEX_EXPR.
> The
301 - 400 of 25204 matches
Mail list logo
