VRP: abstract out MIN/MAX/ABS wide int code

No change in functionality, just a straight up conversion. OK for trunk? gcc/ * wide-int-range.cc (wide_int_range_abs): New. (wide_int_range_order_set): Rename from wide_int_range_min_max. * wide-int-range.h (wide_int_range_abs): New. (wide_int_range_min_max): New. * tree-vrp.c (extract_ran

Re: [PATCH] DWARF: add DW_AT_count to zero-length arrays

On Thu, Aug 16, 2018 at 11:54:53PM -0700, Omar Sandoval wrote: > On Thu, Aug 16, 2018 at 10:27:48PM -0700, Andrew Pinski wrote: > > On Thu, Aug 16, 2018 at 9:29 PM Omar Sandoval wrote: > > > > > > Hi, > > > > > > This fixes the issue that it is impossible to distinguish a zero-length > > > array

Re: [PATCH 4/4] rs6000: Delete old add+cmp patterns

On Thu, Aug 16, 2018 at 7:14 PM, Segher Boessenkool <> wrote: > There are some patterns that recognise the parallel of an add and a > compare, and split it back to the same two insns. This apparently > helped RIOS machines before RTL scheduling existed? Either way, it > isn't helpful anymore, and

Re: [PING] [PATCH] Fix wrong code with truncated string literals (PR 86711/86714)

Hi! After the other patch has been applied, I re-based this patch accordingly. Except the mechanical changes, there are a few notable differences to the previous version: In string_constant, I added a similar check for the STRING_CSTs because when callers don't use mem_size, they assume to be a

[PATCH] Fix PR86841

Applied as obvious. Richard. 2018-08-17 Richard Biener PR tree-optimization/86841 * wide-int-range.cc (wide_int_range_lshift): Use to_uhwi. Index: gcc/wide-int-range.cc === --- gcc/wide-int-range.cc (revi

Re: [PATCH] Check the STRING_CSTs in varasm.c

On Fri, 3 Aug 2018, Jeff Law wrote: > On 08/01/2018 05:35 AM, Bernd Edlinger wrote: > > Hi, > > > > this completes the previous patches, and adds a check in varasm.c > > that ensures that all string constants are NUL terminated, > > And that varasm does not strip anything but _exactly_ one NUL >

Re: [PATCH] Check the STRING_CSTs in varasm.c

On Sat, 4 Aug 2018, Bernd Edlinger wrote: > On 08/03/18 23:36, Jeff Law wrote: > > On 08/01/2018 05:35 AM, Bernd Edlinger wrote: > >> Hi, > >> > >> this completes the previous patches, and adds a check in varasm.c > >> that ensures that all string constants are NUL terminated, > >> And that varasm

Re: [PATCH][2/4] Add rev_post_order_and_mark_dfs_back_seme

On Sat, 4 Aug 2018, Bernhard Reutner-Fischer wrote: > On Wed, 1 Aug 2018 at 16:31, Richard Biener wrote: > > --- a/gcc/cfganal.c > > +++ b/gcc/cfganal.c > > @@ -1057,6 +1057,119 @@ pre_and_rev_post_order_compute (int *pre_order, int > > *rev_post_order, > >return pre_order_num; > > } > > >

[RFC][debug] Fix handling of vlas in lto

Hi, Atm, when running vla-1.c with -O0 -flto, we have: ... FAIL: gcc.dg/guality/vla-1.c -O0 -flto -fuse-linker-plugin \ -fno-fat-lto-objects line 17 sizeof (a) == 6 ... The vla a[i + 1] in f1 is gimplified into: ... f1 (int i) { char a[0:D.1922] [value-expr: *a.0]; char[0:D.1922] * a.0;

Re: [PATCH] Check the STRING_CSTs in varasm.c

Richard Biener wrote: > Note that I'm a little bit confused here given build_string > already appends a '\0' after TREE_STRING_LENGTH. So it is safe > to call strlen() on all STRING_CSTs. I think I raised this in > the review of one of Bernds patches but to be honest all the > various threads ha

Re: [PATCH] Make strlen range computations more conservative

On Tue, 7 Aug 2018, Martin Sebor wrote: > On 08/07/2018 11:44 AM, Richard Biener wrote: > > On August 7, 2018 4:37:00 PM GMT+02:00, Martin Sebor > > wrote: > > > On 08/07/2018 02:51 AM, Richard Biener wrote: > > > > On August 7, 2018 4:24:42 AM GMT+02:00, Martin Sebor > > > wrote: > > > > > On 0

Re: [PATCH] Check the STRING_CSTs in varasm.c

Richard Biener wrote: > +embedded @code{NUL} characters. However, the > +@code{TREE_STRING_LENGTH} always includes a trailing @code{NUL} that > +is not part of the language string literal but appended by the front end. > +If the string shall not be @code{NUL}-terminated the @code{TREE_TYPE} > +is

[PATCH][8-branch][OBVIOUS] Fix wrong option declaration of fcilkplus (PR other/86992).

Hi. This is obvious fix of wrong option declaration. Unfortunately current AWK can't catch that. I'm going to install that to GCC-8 branch, it's the only affected now. Trunk fix is the same, but it's part of an overhaul. Martin gcc/c-family/ChangeLog: 2018-08-17 Martin Liska PR oth

[PATCH] Call braced_list_to_string after array size is fixed

Hi, Yes I know Martin will see this as a capital offense, but to my excuse I must say it only happened in self defense :-) As my other patch series depends on STRNG_CSTs with certain properties, it got broken by the way the string constants are created now, due to the 71625 patch. In order to b

[PATCH] Move cpp_macro to cpplib.h

Way back Geoff Keating broke cpp-id-data.h out of internal.h so that PCH could write out tokenized macro definitions. That removed the need to stringize and retokenize them. cpp-id-data.h was fed to the gty machinery, and users of cpplib continued to use cpplib.h unaware of the cpp_macro defi

Re: [PATCH][GCC][AARCH64] Use stdint integers in vect_su_add_sub.c

On Fri, Aug 3, 2018 at 6:28 PM Matthew Malcomson wrote: > > On 02/08/18 20:18, James Greenhalgh wrote: > > On Tue, Jul 31, 2018 at 04:53:19AM -0500, Matthew Malcomson wrote: > >> Fixing the ilp32 issue that Christophe found. > >> > >> The existing testcase uses `long` to represent a 64 bit integer

Re: [PATCH] Check the STRING_CSTs in varasm.c

On 08/17/18 06:46, Jeff Law wrote: > On 08/05/2018 04:28 AM, Bernd Edlinger wrote: >> Hi, >> >> I would like to do a minor tweak to the patch. >> While staring at the other patch I realized that I should >> better pass size and not thissize to the check >> function, instead of making use of how thi

Re: [PATCH] Check the STRING_CSTs in varasm.c

On Fri, 17 Aug 2018, Bernd Edlinger wrote: > Richard Biener wrote: > > > Note that I'm a little bit confused here given build_string > > already appends a '\0' after TREE_STRING_LENGTH. So it is safe > > to call strlen() on all STRING_CSTs. I think I raised this in > > the review of one of Bern

Re: [PATCH] Add a character size parameter to c_strlen/get_range_strlen

On Fri, 17 Aug 2018, Jeff Law wrote: > On 08/16/2018 05:01 PM, Joseph Myers wrote: > > On Thu, 16 Aug 2018, Jeff Law wrote: > > > >> restores previous behavior. The sprintf bits want to count element > >> sized chunks, which for wchars is 4 bytes (that count will then be > > > >>/* Compute

Re: [PATCH] Check the STRING_CSTs in varasm.c

On Fri, 17 Aug 2018, Bernd Edlinger wrote: > Richard Biener wrote: > > +embedded @code{NUL} characters. However, the > > +@code{TREE_STRING_LENGTH} always includes a trailing @code{NUL} that > > +is not part of the language string literal but appended by the front end. > > +If the string shall no

Re: [PATCH] Check the STRING_CSTs in varasm.c

On 08/17/18 14:19, Richard Biener wrote: > On Fri, 17 Aug 2018, Bernd Edlinger wrote: > >> Richard Biener wrote: >>> +embedded @code{NUL} characters. However, the >>> +@code{TREE_STRING_LENGTH} always includes a trailing @code{NUL} that >>> +is not part of the language string literal but appended

[PATCH RFC] add generic expansion for MULT_HIGHPART_EXP

Hello, We currently have an unfortunate situation where, on the one hand, scalar MULT_HIGHPART_EXPR is usable only if the backend provides the corresponding pattern (otherwise ICEs in expand), but on the other hand, the BRIG frontend wants to make use of it. I think BRIG FE is making assumptions

[PATCH RFC] gimplefe: expose MULT_HIGHPART_EXPR

For testing generic expansion of MULT_HIGHPART_EXPR I chose to expose it via the GIMPLE FE with the following patch. "h*" is how tree-pretty-print dumps MULT_HIGHPART_EXPR. This patch accepts "h*" which ideally shouldn't happen, but I don't see a simple way to fix that. Is this desirable for tru

[PATCH] scev: dump final value replacement expressions

Hello, I'd like to apply the following patch to make GENERIC expressions used in final value replacement visible in pass dumps. We currently dump only the last statement, but that is not very convenient as final values are sometimes complex and expand to multiple gimple statements. * tre

Re: [PATCH] Check the STRING_CSTs in varasm.c

On Fri, 17 Aug 2018, Bernd Edlinger wrote: > On 08/17/18 14:19, Richard Biener wrote: > > On Fri, 17 Aug 2018, Bernd Edlinger wrote: > > > >> Richard Biener wrote: > >>> +embedded @code{NUL} characters. However, the > >>> +@code{TREE_STRING_LENGTH} always includes a trailing @code{NUL} that > >>

Re: [PATCH] PR86844: Fix for store merging

On Tue, Aug 7, 2018 at 1:35 PM Andreas Krebbel wrote: > > From: Andreas Krebbel > > Bootstrapped and regtested on s390x and x86_64. Eric, didn't your patches explicitely handle this case of a non-constant inbetween? Can you have a look / review here? Thanks, Richard. > gcc/ChangeLog: > > 2018

Re: [PATCH] Check the STRING_CSTs in varasm.c

On 08/17/18 15:38, Richard Biener wrote: > On Fri, 17 Aug 2018, Bernd Edlinger wrote: > >> On 08/17/18 14:19, Richard Biener wrote: >>> On Fri, 17 Aug 2018, Bernd Edlinger wrote: >>> Richard Biener wrote: > +embedded @code{NUL} characters. However, the > +@code{TREE_STRING_LENGTH} al

Re: [PATCH, rs6000] Early gimple folding of vec_mergeh and vec_mergel for float

On Wed, Aug 8, 2018 at 12:59 AM Segher Boessenkool wrote: > > Hi! > > On Tue, Aug 07, 2018 at 02:24:58PM -0500, Will Schmidt wrote: > >This adds support for gimple folding of vec_mergeh and vec_mergel > > for float and double types. Support for the integral types is already > > in-tree. > >

Re: [PATCH, RFC, rs6000] enable GIMPLE folding of vec_splat

On Tue, Aug 7, 2018 at 9:25 PM Will Schmidt wrote: > > Hi > Enable GIMPLE folding of the vec_splat() intrinsic. > > For review.. feedback is expected. :-) > > I came up with the following after spending some time poking around > at the tree_vec_extract() and vector_element() functions as seen > in

Re: [PATCH] scev: dump final value replacement expressions

On 08/17/2018 07:19 AM, Alexander Monakov wrote: > Hello, > > I'd like to apply the following patch to make GENERIC expressions > used in final value replacement visible in pass dumps. > > We currently dump only the last statement, but that is not very > convenient as final values are sometimes c

Re: PING [PATCH] warn for strlen of arrays with missing nul (PR 86552, 86711, 86714) )

On 08/16/2018 11:14 PM, Jeff Law wrote: On 08/01/2018 08:44 PM, Martin Sebor wrote: Since the foundation of the patch is detecting and avoiding the overly aggressive folding of unterminated char arrays, besides issuing a warning for such arguments to strlen, the patch also fixes pr86711 - wrong

Re: [PATCH, rs6000] Early gimple folding of vec_mergeh and vec_mergel for float

On Fri, 2018-08-17 at 16:00 +0200, Richard Biener wrote: > On Wed, Aug 8, 2018 at 12:59 AM Segher Boessenkool > wrote: > > > > Hi! > > > > On Tue, Aug 07, 2018 at 02:24:58PM -0500, Will Schmidt wrote: > > >This adds support for gimple folding of vec_mergeh and vec_mergel > > > for float and do

Re: [PATCH, rs6000] Early gimple folding of vec_mergeh and vec_mergel for float

On August 17, 2018 5:02:53 PM GMT+02:00, Will Schmidt wrote: >On Fri, 2018-08-17 at 16:00 +0200, Richard Biener wrote: >> On Wed, Aug 8, 2018 at 12:59 AM Segher Boessenkool >> wrote: >> > >> > Hi! >> > >> > On Tue, Aug 07, 2018 at 02:24:58PM -0500, Will Schmidt wrote: >> > >This adds support

Re: Async I/O patch with compilation fix

Hi Christophe, sorry that this took so long, but a holiday followed by a business trip seven timezones away can do that :-) I applied this patch, and again I still see regressions on armeb-none-linux-gnueabihf --with-cpu cortex-a9 --with-fpu neon-fp16 The info that you supplied in the PR indi

Re: [PATCH] Make strlen range computations more conservative

On 08/17/2018 04:31 AM, Richard Biener wrote: On Tue, 7 Aug 2018, Martin Sebor wrote: On 08/07/2018 11:44 AM, Richard Biener wrote: On August 7, 2018 4:37:00 PM GMT+02:00, Martin Sebor wrote: On 08/07/2018 02:51 AM, Richard Biener wrote: On August 7, 2018 4:24:42 AM GMT+02:00, Martin Sebor

[PATCH] Macro body is trailing array

This patch changes the representation of a macro body, rather than be a pointer to an array of tokens, it is a trailing array of tokens. That's only for iso macros, traditional ones are still a pointer to a [segmented] char array. I introduce two helpers to deal with allocation (cpp uses an

Re: [committed] diagnostics: add line numbers to source (PR other/84889)

On 09/08/18 21:09, David Malcolm wrote: It turns out that we convert tab characters to *single* space characters when printing source code. This behavior has been present since Manu first implemented -fdiagnostics-show-caret in r186305 (aka 5a9830842f69ebb059061e26f8b0699cbd85121e, PR 24985), w

Re: [PATCH, OpenACC] Add support for gang local storage allocation in shared memory

On 16 August 2018 17:46:43 CEST, Julian Brown wrote: >On Wed, 15 Aug 2018 21:56:54 +0200 >Bernhard Reutner-Fischer wrote: > >> On 15 August 2018 18:46:37 CEST, Julian Brown >> wrote: >> >On Mon, 13 Aug 2018 12:06:21 -0700 >> >Cesar Philippidis wrote: >> >> atttribute has more t than strictly

[PATCH,rs6000] Add builtins for accessing the FPSCR

GCC maintainers: The following patch adds builtins to change the value of the FPSCR. Specifically, __builtin_set_fpscr_rn, __builtin_set_fpscr_drn, __builtin_mffsl, __builtin_mtfsb0, __builtin_mtfsb1. I added documentation on the builtins in extend.texi. In addition to listing the builtin, I ad

Re: [committed] diagnostics: add line numbers to source (PR other/84889)

On Aug 17 2018, Manuel López-Ibáñez wrote: > However, I see that GCC trunk still counts tabs as 1-column, probably > because emacs counts tabs as one column when interpreting column numbers > in the output of GCC. That is not true. Emacs is using screen columns by default for almost 20 years no

[PATCH] Fix poly types after PR tree-optimization/71625 strlen optimization

On 15/08/18 16:51, Martin Sebor wrote: On 08/15/2018 04:28 AM, James Greenhalgh wrote: On Tue, Aug 14, 2018 at 09:34:08PM -0500, Martin Sebor wrote: On 08/14/2018 09:24 AM, Martin Sebor wrote: On 08/14/2018 09:08 AM, Martin Sebor wrote: --- gcc/config/aarch64/aarch64-builtins.c    (revision 26

[PATCH] rs6000: Give names to cbranch/creturn patterns

This gives a name to the conditional branch and conditional return patterns, so that it looks neater in dumps and verbose asm. Also, the comment for conditional branch was out of date; this fixes it. Committing. Segher 2018-08-17 Segher Boessenkool * config/rs6000/rs6000.md (*cbra

Re: [PATCH] Fix poly types after PR tree-optimization/71625 strlen optimization

Hi Szabolcs, On 17/08/18 18:18, Szabolcs Nagy wrote: On 15/08/18 16:51, Martin Sebor wrote: > On 08/15/2018 04:28 AM, James Greenhalgh wrote: >> On Tue, Aug 14, 2018 at 09:34:08PM -0500, Martin Sebor wrote: >>> On 08/14/2018 09:24 AM, Martin Sebor wrote: On 08/14/2018 09:08 AM, Martin Sebor

Re: [PATCH] Minor optimisations in operator new(size_t, align_val_t)

On Mon, 13 Aug 2018, Jonathan Wakely wrote: Thanks to Lars for the suggestions. * libsupc++/new_opa.cc (operator new(size_t, align_val_t)): Use __is_pow2 to check for valid alignment. Avoid branching when rounding size to multiple of alignment. Tested x86_64-linux, comm

Re: [PATCH] Handle not explicitly zero terminated strings in merge sections

Hi, this is an update of the patch, which has just two Ada test cases added for string merging which are based on Olivier's suggested test case. Note that except the "Check STRING_CSTs in varasm.c" patch series, there is now another patch needed to work around issues with 71625: [PATCH] Call bra

Re: [committed] diagnostics: add line numbers to source (PR other/84889)

On 17/08/18 17:50, Andreas Schwab wrote: On Aug 17 2018, Manuel López-Ibáñez wrote: However, I see that GCC trunk still counts tabs as 1-column, probably because emacs counts tabs as one column when interpreting column numbers in the output of GCC. That is not true. Emacs is using screen co

[PATCH] PR libstdc++/86963 Implement LWG 2729 constraints on tuple assignment

PR libstdc++/86963 * include/std/tuple (__tuple_base): New class template with deleted copy assignment operator. (tuple, tuple<_T1, _T2>): Derive from __tuple_base so that implicit copy/move assignment operator will be deleted/suppressed. (tuple::__a

Re: [PATCH] Minor optimisations in operator new(size_t, align_val_t)

On 17/08/18 19:28 +0200, Marc Glisse wrote: On Mon, 13 Aug 2018, Jonathan Wakely wrote: Thanks to Lars for the suggestions. * libsupc++/new_opa.cc (operator new(size_t, align_val_t)): Use __is_pow2 to check for valid alignment. Avoid branching when rounding size to mult

Re: [PATCH] PR libstdc++/86963 Implement LWG 2729 constraints on tuple assignment

On 17/08/18 18:52 +0100, Jonathan Wakely wrote: + // The tag parameter ensures that in nested tuples each __tuple_base + // is a different type and can use the empty base-class optimisation. + template +class __tuple_base Specifically, this would fail if __tuple_base was not a class temp

Re: [PATCH] v2: Formatted printing for dump_* in the middle-end

On Thu, 2018-08-16 at 22:08 -0600, Jeff Law wrote: > On 08/02/2018 11:54 AM, David Malcolm wrote: > > On Tue, 2018-07-31 at 19:56 +, Joseph Myers wrote: > > > On Tue, 31 Jul 2018, David Malcolm wrote: > > > > > > > I didn't exhaustively check every callsite to the changed > > > > calls; > > >

Re: [PATCH] Add a character size parameter to c_strlen/get_range_strlen

On 08/17/2018 06:14 AM, Joseph Myers wrote: On Fri, 17 Aug 2018, Jeff Law wrote: On 08/16/2018 05:01 PM, Joseph Myers wrote: On Thu, 16 Aug 2018, Jeff Law wrote: restores previous behavior. The sprintf bits want to count element sized chunks, which for wchars is 4 bytes (that count will the

Re: [PATCH] Minor optimisations in operator new(size_t, align_val_t)

On Fri, 17 Aug 2018, Jonathan Wakely wrote: On 17/08/18 19:28 +0200, Marc Glisse wrote: On Mon, 13 Aug 2018, Jonathan Wakely wrote: Thanks to Lars for the suggestions. * libsupc++/new_opa.cc (operator new(size_t, align_val_t)): Use __is_pow2 to check for valid alignment. Avoi

Re: [PATCH] Add a character size parameter to c_strlen/get_range_strlen

On 08/17/18 20:23, Martin Sebor wrote: > On 08/17/2018 06:14 AM, Joseph Myers wrote: >> On Fri, 17 Aug 2018, Jeff Law wrote: >> >>> On 08/16/2018 05:01 PM, Joseph Myers wrote: On Thu, 16 Aug 2018, Jeff Law wrote: > restores previous behavior.  The sprintf bits want to count element >>

Re: [PATCH,rs6000] Add builtins for accessing the FPSCR

GCC maintainers: > In addition to listing > the builtin, I added a C style comment to describe the builtin a > little.  I don't see any of the other builtins documented like this.  > But I felt some explanation of the builtins were > helpful.  Suggestions > on a better way to add the comments on t

Re: [PATCH] PR libstdc++/86963 Implement LWG 2729 constraints on tuple assignment

On 17/08/18 19:01 +0100, Jonathan Wakely wrote: On 17/08/18 18:52 +0100, Jonathan Wakely wrote: + // The tag parameter ensures that in nested tuples each __tuple_base + // is a different type and can use the empty base-class optimisation. + template +class __tuple_base Specifically, thi

Re: [committed] diagnostics: add line numbers to source (PR other/84889)

On Aug 17 2018, Manuel López-Ibáñez wrote: > In my Emacs, it jumps to column 8 (where the "a" is). That's because there is no way to place it on column 1. Andreas. -- Andreas Schwab, sch...@linux-m68k.org GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510 2552 DF73 E780 A9DA AEC1 "And now for so

Re: [2/5] C-SKY port v3: Backend implementation

On 08/16/2018 11:45 PM, Jeff Law wrote: On 08/05/2018 10:34 PM, Sandra Loosemore wrote: csky-gcc-2.log 2018-08-05 Jojo Huibin Wang Sandra Loosemore Chung-Lin Tang C-SKY port: Backend implementation gcc/ * config/csky/*: Ne

[PATCH] RFC: remove std::tuple partial specialization

While fixing PR 86963 I realised we can get rid of the 2-tuple partial specialization, and just add the relevant constructors and assignment operators to the primary template. They're all constrained anyway, so they won't be available except when sizeof...(_Elements) == 2. This patch also removes

Re: [PATCH v2 2/4] libgcc: add crt{begin,end} for powerpc-wrs-vxworks target

Hi Rasmus, > On 16 Aug 2018, at 11:30, Rasmus Villemoes wrote: > > On 2018-06-28 10:43, Rasmus Villemoes wrote: >> In order to allow ZCX on VxWorks, we need the frame_dummy function to do >> the register_frame_info(). So make sure crtbegin.o and crtend.o are >> available for use with a custom sp

[PATCH] doc: Use @ref, not @xref, in the middle of a sentence

makeinfo warns about this. Obvious, tested, committing. Segher 2018-08-17 Segher Boessenkool * doc/md.texi (Patterns): Use @ref instead of @xref in the middle of a sentence. --- gcc/doc/md.texi | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/gcc/doc/md

Re: [PATCH] RFC: remove std::tuple partial specialization

On 17 August 2018 at 22:29, Jonathan Wakely wrote: > That was added by https://gcc.gnu.org/ml/libstdc++/2016-12/msg00122.html > but I see no justification for that in the standard (and neither > libc++ nor MSFTL does anything special here, so they fail the test > too). > > Ville, I'm no longer con

Re: [PATCH] RFC: remove std::tuple partial specialization

On 17 August 2018 at 22:46, Ville Voutilainen wrote: >> >> If we think the test is right, we should report a defect. Either way, >> I think this patch would be a nice simplification. We can either fix >> (or just remove) the test, or constrain the primary template. > > I think the test is reasonab

Re: [PATCH] RFC: remove std::tuple partial specialization

On 17/08/18 22:46 +0300, Ville Voutilainen wrote: On 17 August 2018 at 22:29, Jonathan Wakely wrote: That was added by https://gcc.gnu.org/ml/libstdc++/2016-12/msg00122.html but I see no justification for that in the standard (and neither libc++ nor MSFTL does anything special here, so they fai

Re: [PATCH] Add a character size parameter to c_strlen/get_range_strlen

On 08/17/2018 12:44 PM, Bernd Edlinger wrote: On 08/17/18 20:23, Martin Sebor wrote: On 08/17/2018 06:14 AM, Joseph Myers wrote: On Fri, 17 Aug 2018, Jeff Law wrote: On 08/16/2018 05:01 PM, Joseph Myers wrote: On Thu, 16 Aug 2018, Jeff Law wrote: restores previous behavior. The sprintf bi

[PATCH][debug] Fix handling of vlas in lto

I've rewritten the patch to work generically, not just for DW_AT_upper_bound, and to reuse the code already there in add_scalar_info. OK for trunk? Thanks, - Tom [debug] Fix handling of vlas in lto Atm, when running vla-1.c with -O0 -flto, we have: ... FAIL: gcc.dg/guality/vla-1.c -O0 -flto -fu

Re: [PATCH,rs6000] Add builtins for accessing the FPSCR

Hi Carl, On Fri, Aug 17, 2018 at 11:46:06AM -0700, Carl Love wrote: > > In addition to listing > > the builtin, I added a C style comment to describe the builtin a > > little.  I don't see any of the other builtins documented like this.  > > But I felt some explanation of the builtins were > > hel

[committed]: C++: -Wwrite-strings: use location of string constant

Consider: extern int callee (const char *one, char *two, const char *three); int test () { return callee ("first", "second", "third"); } for which -Wwrite-strings was emitting: Wwrite-strings.C: In function 'int test()': Wwrite-strings.C:10:44: warning: ISO C++ forbids converting a string con

Re: [PATCH] Merge Ignore and Deprecated in .opt files.

Hi! On Thu, Aug 16, 2018 at 11:18:15AM +0200, Martin Liška wrote: > On 08/15/2018 06:38 PM, Joseph Myers wrote: > > On Wed, 15 Aug 2018, Martin Liška wrote: > > > >> Ok, so you have very similar opinion as Jakub. Thus I'm sending new > >> version that preserves status quo, it only does: > > > >

Re: [PATCH] convert braced initializers to strings (PR 71625)

Hi everybody, On 08/16/18 08:36, Bernd Edlinger wrote: > Jeff Law wrote: >> I wonder if the change to how we set up the initializers is ultimately >> changing the section those go into and ultimately causing an overflow of >> the .sdata section. > > > Yes, that is definitely the case. > Due to t

Re: [PATCH] Add a character size parameter to c_strlen/get_range_strlen

On 08/17/18 22:17, Martin Sebor wrote: > On 08/17/2018 12:44 PM, Bernd Edlinger wrote: >> On 08/17/18 20:23, Martin Sebor wrote: >>> On 08/17/2018 06:14 AM, Joseph Myers wrote: On Fri, 17 Aug 2018, Jeff Law wrote: > On 08/16/2018 05:01 PM, Joseph Myers wrote: >> On Thu, 16 Aug 201

[PATCH] Adjust lazy macro definition

We provide a lazy macro definition hook, to deal with the FP macros where it is expensive to generate the string representation of the FP value. The current hook is much more general than needed, but it's not clear that generality can be used because we don't document what macro state can be m

Re: [PATCH] Add a character size parameter to c_strlen/get_range_strlen

On 08/17/2018 12:23 PM, Martin Sebor wrote: > On 08/17/2018 06:14 AM, Joseph Myers wrote: >> On Fri, 17 Aug 2018, Jeff Law wrote: >> >>> On 08/16/2018 05:01 PM, Joseph Myers wrote: On Thu, 16 Aug 2018, Jeff Law wrote: > restores previous behavior.  The sprintf bits want to count eleme

Re: [PATCH] Add a character size parameter to c_strlen/get_range_strlen

On 08/17/2018 12:44 PM, Bernd Edlinger wrote: > On 08/17/18 20:23, Martin Sebor wrote: >> On 08/17/2018 06:14 AM, Joseph Myers wrote: >>> On Fri, 17 Aug 2018, Jeff Law wrote: >>> On 08/16/2018 05:01 PM, Joseph Myers wrote: > On Thu, 16 Aug 2018, Jeff Law wrote: > >> restores previo

Re: [PATCH] Add a character size parameter to c_strlen/get_range_strlen

On 08/17/2018 02:17 PM, Martin Sebor wrote: > On 08/17/2018 12:44 PM, Bernd Edlinger wrote: >> On 08/17/18 20:23, Martin Sebor wrote: >>> On 08/17/2018 06:14 AM, Joseph Myers wrote: On Fri, 17 Aug 2018, Jeff Law wrote: > On 08/16/2018 05:01 PM, Joseph Myers wrote: >> On Thu, 16 Au

Re: [PATCH] Check the STRING_CSTs in varasm.c

On 08/17/2018 06:13 AM, Bernd Edlinger wrote: >> > > Yes, there is a JIT code gen bug, that was caught by the assertion in my > patch: > > [PATCH] Fix not properly nul-terminated string constants in JIT > https://gcc.gnu.org/ml/gcc-patches/2018-08/msg00370.html THanks for the reference. I didn't

Re: [PATCH][Middle-end]patch for fixing PR 86519

Hi Qing: > > the change has been committed as: > https://gcc.gnu.org/viewcvs/gcc?view=revision&revision=263563 > > > Qing > The strcmpopt_6.c test still fails on mips64el target. gcc.dg/strcmpopt_6.c: memcmp found 4 times FAIL: gcc

Re: [PATCH] Check the STRING_CSTs in varasm.c

On 08/17/2018 07:53 AM, Bernd Edlinger wrote: > On 08/17/18 15:38, Richard Biener wrote: >> On Fri, 17 Aug 2018, Bernd Edlinger wrote: >> >>> On 08/17/18 14:19, Richard Biener wrote: On Fri, 17 Aug 2018, Bernd Edlinger wrote: > Richard Biener wrote: >> +embedded @code{NUL} charact

Re: [PATCH][Middle-end]patch for fixing PR 86519

On 08/17/2018 09:43 PM, Paul Hua wrote: > Hi Qing: > >> >> the change has been committed as: >> https://gcc.gnu.org/viewcvs/gcc?view=revision&revision=263563 >> >> >> Qing >> > > The strcmpopt_6.c test still fails on mips64el target

Re: [PING] [PATCH] Fix wrong code with truncated string literals (PR 86711/86714)

On 08/17/2018 03:14 AM, Bernd Edlinger wrote: > Hi! > > > After the other patch has been applied, I re-based this patch accordingly. > > Except the mechanical changes, there are a few notable differences to the > previous version: > > In string_constant, I added a similar check for the STRING_C

Re: [PATCH] Add a character size parameter to c_strlen/get_range_strlen

On 08/17/2018 06:14 AM, Joseph Myers wrote: > On Fri, 17 Aug 2018, Jeff Law wrote: > >> On 08/16/2018 05:01 PM, Joseph Myers wrote: >>> On Thu, 16 Aug 2018, Jeff Law wrote: >>> restores previous behavior. The sprintf bits want to count element sized chunks, which for wchars is 4 bytes (

Re: [PATCH] convert braced initializers to strings (PR 71625)

On 08/17/2018 04:26 PM, Bernd Edlinger wrote: > Hi everybody, > > On 08/16/18 08:36, Bernd Edlinger wrote: >> Jeff Law wrote: >>> I wonder if the change to how we set up the initializers is ultimately >>> changing the section those go into and ultimately causing an overflow of >>> the .sdata secti

Re: [PATCH 1/3] Fix probabilities for jump table (PR tree-optimization/86702).

On 08/03/2018 06:58 AM, marxin wrote: > The patch set even probability to jump tables based on number of > cases which are handled on each edge. > > gcc/ChangeLog: > > 2018-08-06 Martin Liska > > PR tree-optimization/86702 > * tree-switch-conversion.c (jump_table_cluster::emit):

Re: [PATCH 2/3] Fix probability for bit-tests.

On 08/03/2018 08:10 AM, marxin wrote: > The patch set even probability to bit test based on number of > cases which are handled on each edge. > > gcc/ChangeLog: > > 2018-08-06 Martin Liska > > * tree-switch-conversion.c (bit_test_cluster::find_bit_tests): > Add new argument to b