Re: [PATCH 2/6] detect unterminated const arrays in strlen calls (PR 86552)

On 09/09/18 01:47, Jeff Law wrote: > On 9/8/18 3:47 PM, Bernd Edlinger wrote: >> Hi, >> >> >>> -fold_builtin_strlen (location_t loc, tree type, tree arg) >>> +fold_builtin_strlen (location_t loc, tree fndecl, tree type, tree arg) >>>

Re: [PATCH] Adjust c_getstr/c_strlen to new STRING_CST semantic

On 08/31/18 19:45, Bernd Edlinger wrote: > On 08/31/18 16:42, Jeff Law wrote: >> On 08/31/2018 01:08 AM, Bernd Edlinger wrote: >>> Hi, >>> >>> >>> when re-testing the new STRING_CST semantic patch here: >>> https://gcc.gnu.org/ml/gcc-patche

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

On 09/13/18 20:42, Jeff Law wrote: > On 8/24/18 2:18 PM, Bernd Edlinger wrote: >> >> [PATCHv2] Handle overlength string literals in the fortan FE >> https://gcc.gnu.org/ml/gcc-patches/2018-08/msg01568.html > I've committed this patch to the trunk. > Hi Jeff,

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

On 09/13/18 20:44, Jeff Law wrote: > On 8/24/18 2:18 PM, Bernd Edlinger wrote: >> Hi! >> >> >> This is an alternative approach in making STRING_CST semantics >> consistent. >> >> This means it makes STRING_CST used for literals and for initializers >

Re: [PATCH] Avoid another non zero terminated string constant (revert)

On 07/30/18 08:52, Richard Biener wrote: > 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 c

[PATCHv2] Handle not explicitly zero terminated strings in merge sections

. Thus there are no pre-requisite patches necessary at this time. Bootstrapped and reg-tested on x86_64-pc-linux-gnu. Is it OK for trunk? Thanks Bernd. gcc: 2018-08-27 Bernd Edlinger * varasm.c (output_constant): Add new parameter merge_strings. Make strings properly zero terminated in merge

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

On 09/14/18 21:01, Jakub Jelinek wrote: > On Fri, Sep 14, 2018 at 06:39:38PM +0000, Bernd Edlinger wrote: >> Hi, >> >> this is an upate of the string-merge section, it is based on the >> V2-STRING_CST >> semantic patch series, which was finally installed yesterday

[PATCH] Resolve the TODO in fold_builtin_strlen

Bernd Edlinger * builtins.c (fold_builtin_strlen): Remove TODO comment. testsuite: 2018-09-14 Bernd Edlinger * gcc.dg/warn-strlen-no-nul.c: Add some missing test cases. diff -Npur gcc/builtins.c gcc/builtins.c --- gcc/builtins.c 2018-08-30 08:21:13.0 +0200 +++ gcc/builtins.c 2018

Re: [PATCH] look harder for MEM_REF operand equality to avoid -Wstringop-truncation (PR 84561)

issues a warning. I understand that walking the references is fragile at least in this state. But why not just prevent warnings when this is called from CCP? Like this? Bootstrapped and reg-tested on x86_64-pc-linux-gnu. Is it OK for trunk? Thanks Bernd. gcc: 2018-09-15 Bernd Edlinger P

Re: [PATCH] Make strlen range computations more conservative

e two get_range_strlen functions at the same time as it is rather confusing to have to count the parameters in order to tell which function is meant. Bootstrapped and reg-tested on x86_64-pc-linux-gnu. Is it OK for trunk? Thanks Bernd. gcc: 2018-08-26 Bernd Edlinger * gimple-f

[PATCH] Fix ms-sysv generator with gcc-4.8 host-g++

? Thanks Bernd. 2018-09-16 Bernd Edlinger * gcc.target/x86_64/abi/ms-sysv/ms-sysv.exp: Don't pass TEST_ALWAYS_FLAGS to HOSTCXX. Index: gcc/testsuite/gcc.target/x86_64/abi/ms-sysv/ms-sysv.exp === --- gcc/testsuite/gcc.t

[PATCH] Cleanup strcpy/stpcpy no nul warning code

size of the whole DECL, cannot access an adjacent member. Bootstrapped and reg-tested on x86_64-pc-linux-gnu. Is it OK for trunk? Thanks Bernd. gcc: 2018-09-16 Bernd Edlinger * builtins.h (unterminated_array): Remove prototype. * builtins.c (unterminated_array): Simplify. Make

Re: [PATCH 00/25] AMD GCN Port

writes: > Given a pattern with a number of operands: > > (match_operand 0 "" "=&v") > (match_operand 1 "" " v0") > (match_operand 2 "" " v0") > (match_operand 3 "" " v0") > > GCC will currently increment "reject" once, for operand 0, and then decrement > it once for each of the other operands, end

Re: [PATCH] Cleanup strcpy/stpcpy no nul warning code

On 09/17/18 19:33, Jeff Law wrote: > On 9/16/18 1:58 PM, Bernd Edlinger wrote: >> Hi, >> >> this is a cleanup of the recently added strlen/strcpy/stpcpy >> no nul warning code. >> >> Most importantly it moves the SSA_NAME handling from >> untermin

Re: [PATCH] look harder for MEM_REF operand equality to avoid -Wstringop-truncation (PR 84561)

On 09/17/18 19:35, Richard Biener wrote: > On September 17, 2018 7:24:16 PM GMT+02:00, Jeff Law wrote: >> On 9/15/18 2:14 AM, Bernd Edlinger wrote: >>> On 9/14/18, Martin Sebor wrote: >>>> As I said above, this happens during the

Re: [PATCH] Cleanup strcpy/stpcpy no nul warning code

On 09/17/18 20:32, Jeff Law wrote: > On 9/17/18 12:20 PM, Bernd Edlinger wrote: >> On 09/17/18 19:33, Jeff Law wrote: >>> On 9/16/18 1:58 PM, Bernd Edlinger wrote: >>>> Hi, >>>> >>>> this is a cleanup of the recently added strlen/strcpy/stpcp

Re: [PATCH] Cleanup strcpy/stpcpy no nul warning code

On 09/18/18 07:31, Jeff Law wrote: > On 9/17/18 1:18 PM, Bernd Edlinger wrote: >> On 09/17/18 20:32, Jeff Law wrote: >>> On 9/17/18 12:20 PM, Bernd Edlinger wrote: >>>> On 09/17/18 19:33, Jeff Law wrote: >>>>> On 9/16/18 1:58 PM, Bernd Edlinger wrote:

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

Hi Jakub, are your concerns addressed with this answer, or do you have objections to this patch? Thanks Bernd. On 09/14/18 21:06, Bernd Edlinger wrote: > On 09/14/18 21:01, Jakub Jelinek wrote: >> On Fri, Sep 14, 2018 at 06:39:38PM +0000, Bernd Edlinger wrote: >>> Hi, >&g

Re: [PATCH] Cleanup strcpy/stpcpy no nul warning code

On 09/24/18 19:48, Jeff Law wrote: > On 9/16/18 1:58 PM, Bernd Edlinger wrote: >> Hi, >> >> this is a cleanup of the recently added strlen/strcpy/stpcpy >> no nul warning code. >> >> Most importantly it moves the SSA_NAME handling from >> untermin

Re: [PATCH 1/4] introduce struct strlen_data_t into gimple-fold

Hi, > --- a/gcc/calls.c > +++ b/gcc/calls.c > @@ -1557,7 +1557,10 @@ maybe_warn_nonstring_arg (tree fndecl, tree exp) >tree bound = NULL_TREE; > >/* The range of lengths of a string argument to one of the comparison > - functions. If the length is less than the bound it is used inst

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

On 10/05/18 20:15, Andreas Schwab wrote: > On Sep 14 2018, Bernd Edlinger wrote: > >> diff -Npur gcc/testsuite/gnat.dg/string_merge1.adb >> gcc/testsuite/gnat.dg/string_merge1.adb >> --- gcc/testsuite/gnat.dg/string_merge1.adb 1970-01-01 01:00:00.0 >&

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

On 10/08/18 13:14, Rainer Orth wrote: > Hi Bernd, > >> On 10/05/18 20:15, Andreas Schwab wrote: >>> On Sep 14 2018, Bernd Edlinger wrote: >>> >>>> diff -Npur gcc/testsuite/gnat.dg/string_merge1.adb >>>> gcc/testsuite/gnat.dg/string_merge1.adb

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

bootstrapped the attached patch successfully. Is it OK for trunk? Thanks Bernd. 2018-10-09 Bernd Edlinger * varasm.c (mergeable_string_section): Don't try to move zero-length strings to the merge section. Index: gcc/varasm.c

[PING**2] [PATCH] Fix not properly nul-terminated string constants in JIT

Ping... On 08/26/18 21:40, Bernd Edlinger wrote: > Ping... > > This is just plain wrong, independent > of any STRING_CST semantic issues. > > The original patch (retested on current trunk) is > here: https://gcc.gnu.org/ml/gcc-patches/2018-08/msg00370.html > >

[REPOST] [PATCH] Avoid excessive function type casts with splay-trees

Hi, this is basically the same patch I posted a few months ago, with a few formatting nits by Jakub fixed. Bootstrapped and reg-tested again with current trunk. Is it OK for trunk? Bernd. On 12/15/17 11:44, Bernd Edlinger wrote: > Hi, > > when working on the -Wcast-function-typ

[PING] [PATCH] Avoid excessive function type casts with splay-trees

Ping... On 05/03/18 22:13, Bernd Edlinger wrote: > Hi, > > this is basically the same patch I posted a few months ago, > with a few formatting nits by Jakub fixed. > > Bootstrapped and reg-tested again with current trunk. > > Is it OK for trunk? > > > Ber

Re: [PING] [PATCH] Avoid excessive function type casts with splay-trees

On 05/17/18 15:39, Richard Biener wrote: > On Thu, May 17, 2018 at 3:21 PM Bernd Edlinger > wrote: > >> Ping... > > So this makes all traditional users go through the indirect > splay_tree_compare_wrapper > and friends (which is also exported for no good rea

RE: [PATCH, PR 57748] Check for out of bounds access, Part 3

s in TO_RTX can have VOIDmode, we must not try   to call force_reg for that case.  Avoid that case." This comment is completely out of sync: There is no longer any force_reg in that if-block, and a constant address in TO_RTX has SImode or DImode in GET_MODE (XEXP (to_rtx, 0)) I do not know

RE: [PATCH] preprocessor/58580 - preprocessor goes OOM with warning for zero literals

Sorry Dodji, I still do not see how this is supposed to work: If the previous invocation of get_line already had read some characters of the following line(s), how is that information recovered? I see it is copied behind lineptr[cur_len]. But when get_line is re-entered, cur_len is set to zero a

RE: [PATCH] Factorize the two read_line functions present in gcov.c and input.c

Hi, just some thoughts... fgetc will definitely be much faster than fread 16K and fseek back to the end of line position. Note: fgetc is already buffered and not too slow on average, but only if you do not fseek around. In that case the buffered file-stream data is lost. Well, reading 16K in

RE: [PATCH, PR 57748] Check for out of bounds access, Part 2

Hi, On Fri, 25 Oct 2013 12:51:13, Richard Biener wrote: > > On Fri, Oct 25, 2013 at 12:02 PM, Bernd Edlinger > wrote: >> Hi, >> >>> Eh ... even >>> >>> register struct { int i; int a[0]; } asm ("ebx"); >>> >>> works

RE: [PATCH, PR 57748] Check for out of bounds access, Part 2

oops - this time with attachments... > Hi, > > On Fri, 25 Oct 2013 12:51:13, Richard Biener wrote: >> >> On Fri, Oct 25, 2013 at 12:02 PM, Bernd Edlinger >> wrote: >>> Hi, >>> >>>> Eh ... even >>>> >>>> register

RE: [PATCH] Factorize the two read_line functions present in gcov.c and input.c

On Thu, 7 Nov 2013 13:48:14, Jakub Jelinek wrote: > On Thu, Nov 07, 2013 at 01:25:00PM +0100, Bernd Edlinger wrote: >> just some thoughts... >> >> >> fgetc will definitely be much faster than fread 16K and fseek back to the >> end of line position. >> >

RE: [PATCH] Factorize the two read_line functions present in gcov.c and input.c

> On 11/07/13 09:32, Dodji Seketeli wrote: > >> From the above, what I can say is that input.o was already linked with >> gcov. But I think it's minimal enough to only drag libcpp and the >> diagnostic subsystem. > > I disagree. While input.o was available to gcov, I don't think it was being > pull

[PATCH, i386] Fix -mpreferred-stack-boundary

er i686-pc-linux-gnu. Boot-strapped and regression-tested under i686-pc-linux-gnu. OK for trunk? Regards Bernd. 2013-11-10 Bernd Edlinger PR target/58964 * config/i386/i386.c (ix86_valid_targ

RE: [PATCH, i386] Fix -mpreferred-stack-boundary

ting? Bernd. PS: I have one more patch pending, and would like to know what you think about it: http://gcc.gnu.org/ml/gcc-patches/2013-11/msg00133.html That has also to do with global state variables that are modified due to target options, and initially I was expecting that the patch fo

RE: [PATCH] preprocessor/58580 - preprocessor goes OOM with warning for zero literals

Hi, On Tue, 12 Nov 2013 16:33:41, Dodji Seketeli wrote: > > +/* Reads the next line from FILE into *LINE. If *LINE is too small > + (or NULL) it is allocated (or extended) to have enough space to > + containe the line. *LINE_LENGTH must contain the size of the > + initial*LINE buffer. It's then up

RE: [PATCH] preprocessor/58580 - preprocessor goes OOM with warning for zero literals

> >>> + memmove (*line, l, len); >>> + (*line)[len - 1] = '\0'; >>> + *line_len = --len; >> >> Generally, I would prefer to use memcpy, >> if it is clear that the memory does not overlap. > > I don't mind. I'll change that in my local copy. Thanks. > >> You copy one char too much and set it to zero

RE: [PATCH, i386] Fix -mpreferred-stack-boundary

On Tue, 12 Nov 2013 17:50:27, Sriraman Tallam wrote: > > On Tue, Nov 12, 2013 at 5:17 PM, Sriraman Tallam wrote: >> On Tue, Nov 12, 2013 at 2:53 PM, Bernd Edlinger >> wrote: >>> Hi, >>> >>> >>> On Tue, 12 Nov 2013 10:30:16, Sriraman Tallam w

RE: [PATCH] reimplement -fstrict-volatile-bitfields v4, part 1/2

n 10/29/2013 02:51 AM, Bernd Edlinger wrote: >>> >>> >>> On Mon, 28 Oct 2013 21:29:24, Sandra Loosemore wrote: >>>> >>>> On 10/28/2013 03:20 AM, Bernd Edlinger wrote: >>>>> >>>>> I have attached an update to you

[PING] [PATCH] Fix C++0x memory model for -fno-strict-volatile-bitfields on ARM

> Boot-strapped and regression-tested as usual. > > OK for trunk? > > Bernd. > >> Hi, >> >> On Fri, 25 Oct 2013 11:26:20, Richard Biener wrote: >>> >>> On Fri, Oct 25, 2013 at 10:40 AM, Bernd Edlinger >>> wrote: >>>>

RE: [PATCH] reimplement -fstrict-volatile-bitfields v4, part 1/2

Hi, On Thu, 14 Nov 2013 16:31:10, Richard Biener wrote: > > On Thu, Nov 14, 2013 at 11:16 AM, Bernd Edlinger > wrote: >> Hi, >> >> sorry, for the delay. >> Sandra seems to be even more busy than me... >> >> Attached is a combined patch of the or

RE: [PATCH, i386] Fix -mpreferred-stack-boundary

On Fri, 15 Nov 2013 10:09:02, Uros Bizjak wrote: > > On Fri, Nov 15, 2013 at 4:54 AM, Sriraman Tallam wrote: > >> Currently on trunk the option -mpreferred-stack-boundary does not >> work >> together with #pragma GCC target("sse") or >> __attribute__((target("sse"

RE: [PATCH] Fix C++0x memory model for -fno-strict-volatile-bitfields on ARM

> > Err, well. This just means that the generic C++ memory model > handling isn't complete. We do > > if (TREE_CODE (to) == COMPONENT_REF > && DECL_BIT_FIELD_TYPE (TREE_OPERAND (to, 1))) > get_bit_range (&bitregion_start, &bitregion_end, to, &bitpos, &offset); > > and thus restrict ourselves to bit

RE: [PATCH] reimplement -fstrict-volatile-bitfields v4, part 1/2

>> >> hmm... >> the above change is just not aggressive enough. >> >> >> with a slightly changed test case I have now got a >> recursion on the extract_fixed_bit_fields on ARM but >> interestingly not on powerpc: >> >> #include >> >> typedef struct { >> char pad; >> int arr[0]; >> } __attribute__(

RE: [PATCH] reimplement -fstrict-volatile-bitfields v4, part 1/2

> > But then why is the mode QImode in the first place? The access is > definitely of SImode. > that's in the test case:   s->arr[0] = 0x12345678; it is QImode from that in expand_assignment:   to_rtx = expand_expr (tem, NULL_RTX, VOIDmode, EXPAND_WRITE); tem is "s", a MEM_REF, of QImode,

RE: [PATCH] Fix C++0x memory model for -fno-strict-volatile-bitfields on ARM

on x86_64-linux-gnu. OK for trunk? Thanks Bernd. 2013-11-18 Bernd Edlinger Fix C++0x memory model for unaligned fields in packed, aligned(4) structures with -fno-strict-volatile-bitfields on STRICT_ALIGNMENT targets like arm-none-eabi. * exp

RE: [PATCH] reimplement -fstrict-volatile-bitfields v4, part 1/2

on of the bitfields-update patch, it is again relative to the already approved version of the volatile-bitfields patch v4, part 1/2. Boot-strapped and regression-tested on X86_64-linux-gnu. additionally tested with an ARM cross-compiler. OK for trunk? Thanks Bernd.

[PING] Fix PR58115

PING... this patch still needs review: http://gcc.gnu.org/ml/gcc-patches/2013-11/msg00133.html Thanks. > on i686-pc-linux-gnu the test case gcc.target/i386/intrinsics_4.c fails > because of > an internal compiler error, see PR58155. > > The reason for this is that the optab CODE_FOR_movv8sf i

RE: [PATCH] Fix PR58115

On Tue, 19 Nov 2013 06:21:22, H.J. Lu wrote: > > On Sun, Nov 3, 2013 at 2:25 AM, Bernd Edlinger > wrote: >> Hello, >> >> on i686-pc-linux-gnu the test case gcc.target/i386/intrinsics_4.c fails >> because of >> an internal compiler error, see PR58155. >

[PATCH, PR 57748] Check for out of bounds access, Part 2

tachments... > > >> Hi, >> >> On Fri, 25 Oct 2013 12:51:13, Richard Biener wrote: >>> >>> On Fri, Oct 25, 2013 at 12:02 PM, Bernd Edlinger >>> wrote: >>>> Hi, >>>> >>>>> Eh ... even >>>>> >>>>

[PATCH] Strict volatile bit-fields clean-up

l/gcc-patches/2013-11/msg00581.html :[PATCH, PR 57748] Check for out of bounds access, Part 3 http://gcc.gnu.org/ml/gcc-patches/2013-11/msg00133.html:[PATCH] Fix PR58115 2013-11-20 Bernd Edlinger * expr.c (expand_assignment): Remove dependen

RE: [PATCH] Fix C++0x memory model for -fno-strict-volatile-bitfields on ARM

of this patch. Boot-strapped and regression-tested on x86_64-linux-gnu. Ok for trunk? Bernd. > On Mon, 18 Nov 2013 11:37:05, Bernd Edlinger wrote: > > Hi, > > On Fri, 15 Nov 2013 13:30:51, Richard Biener wrote: >>> That looks like always pretending it is a bit field. >&

[PATCH] Fix PR ipa/61190, 2nd edition‏

warnings. Thanks Bernd. 2014-10-07 Bernd Edlinger PR ipa/61190 * cgraph.h (symtab_node::call_for_symbol_and_aliases): Fix comment. (cgraph_node::call_for_symbol_and_aliases): Likewise. (cgraph_node::call_for_symbol_thunks_and_aliases_1): New funct

[PING] [PATCH] Fix PR ipa/61190, 2nd edition‏

Ping... see: https://gcc.gnu.org/ml/gcc-patches/2014-10/msg00536.html > Hi Honza, > > > as you know, we have a wrong code bug, when a pure or const method is called > via a virtual thunk. > I had some more Ideas, how to fix that, but all of them had some serious > draw-backs, so I leave the det

RE: [PING**2] [PATCH] Fix PR ipa/61190, 2nd edition‏

Ping again... Thanks. > From: bernd.edlin...@hotmail.de > To: hubi...@ucw.cz > CC: gcc-patches@gcc.gnu.org; richard.guent...@gmail.com > Subject: [PING] [PATCH] Fix PR ipa/61190, 2nd edition‏ > Date: Tue, 14 Oct 2014 11:40:56 +0200 > > Ping... > > see: ht

[PATCH] Fix PR ipa/61190

ed and Regression-Tested on x86_64-linux-gnu. Ok for trunk? Thanks Bernd. 2014-06-02 Bernd Edlinger PR ipa/61190 * cgraphunit.c (expand_thunk): Don't try to output the thunk for a virtual base class via targetm.asm_out.outp

RE: [PATCH] Fix PR ipa/61190

Hi, On Mon, 2 Jun 2014 12:06:12, Richard Biener wrote: > > On Mon, Jun 2, 2014 at 11:00 AM, Bernd Edlinger > wrote: >> Hi, >> >> the test case g++.old-deja/g++.mike/p4736b.C is mis-compiled with with all >> optimization levels, except -O0 and -Og. This pr

[PING**2] [PATCH, FORTRAN] Fix PR fortran/60718

gt;> >> On Fri, 11 Apr 2014 16:04:51, Tobias Burnus wrote: >>> >>> Hi Tobias, >>> >>> On Fri, Apr 11, 2014 at 02:39:57PM +0200, Bernd Edlinger wrote: >>>> On Fri, 11 Apr 2014 13:37:46, Tobias Burnus wrote: >>>> Hmm, >>>>

[PATCH] PR rtl-optimization/61047

Hi, this patch fixes PR 61047, where rtx_addr_can_trap_p_1 incorrectly assumes, that all SP-relative offsets can be safely read witout causing any traps. And therefore such references are safe to be moved out of an if-block. This patch tries to get safe lower and upper bounds where accesses are a

RE: [PATCH] PR rtl-optimization/61047

On  Thu, 12 Jun 2014 10:36:25, Eric Botcazou wrote: > >> Btw, I wonder if we can simply mark the MEMs generated from spill code >> with MEM_NOTRAP_P so we can remove the special casing of >> frame-pointer-based addresses from add while properly initializing >> MEM_NOTRAP_p from rtx_addr_can_trap_p?

RE: [PATCH] PR rtl-optimization/61047

On Thu, 12 Jun 2014 10:50:29, Eric Botcazou wrote: > >> Btw I am not sure at all, why argp-references can never be dangerous? >> For instance in a struct with an array inside, passed as function argument? > > IMO there cannot be any definitive solution to this issue until after we move > all the af

RE: [PATCH] PR rtl-optimization/61047

Hi, On Thu, 12 Jun 2014 12:49:13, Richard Biener wrote: > > On Thu, Jun 12, 2014 at 10:36 AM, Eric Botcazou wrote: >>> Btw, I wonder if we can simply mark the MEMs generated from spill code >>> with MEM_NOTRAP_P so we can remove the special casing of >>> frame-pointer-based addresses from add whi

[Ada] PR ada/61505

the run time mentioned in paragraph @strong{53}" I am not sure how to handle that without paragraph numbers, maybe like this: "See documentation in the sources of the run time mentioned in the previous paragraph." 2014-06-14 Bernd Edlinger PR ada/61505 * gn

RE: [PATCH] Fix PR ipa/61190

Hi Honza, On Mon, 2 Jun 2014 18:12:10, Jan Hubicka wrote: > >> Hi, >> >> On Mon, 2 Jun 2014 12:06:12, Richard Biener wrote: >>> >>> On Mon, Jun 2, 2014 at 11:00 AM, Bernd Edlinger >>> wrote: >>>> Hi, >>>> >>

Re: fix math wrt volatile-bitfields vs C++ model

Hi, On Tue, 17 Jun 2014 10:08:33, Richard Biener wrote: > On Tue, Jun 17, 2014 at 4:08 AM, DJ Delorie wrote: >> >>> Looks ok to me, but can you add a testcase please? >> >> I have a testcase, but if -flto the testcase doesn't include *any* >> definition of the test function, just all the LTO dat

RE: [PATCH, rs6000] Fix PR61542 - V4SF vector extract for little endian

Hi, On Wed, 18 Jun 2014 09:56:15, David Edelsohn wrote: > > On Tue, Jun 17, 2014 at 6:44 PM, BIll Schmidt > wrote: >> Hi, >> >> As described in https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61542, a >> new test case (gcc.dg/vect/vect-nop-move.c) was added in 4.9. This >> exposes a bug on PowerPC l

[PATCH] Change default for --param allow-...-data-races to off

trunk? Thanks Bernd. gcc/ChangeLog: 2014-06-19 Bernd Edlinger Set default for --param allow-...-data-races to off. * params.def (PARAM_ALLOW_LOAD_DATA_RACES, PARAM_ALLOW_STORE_DATA_RACES, PARAM_ALLOW_PACKED_LOAD_DATA_RACES

[PATCH] Remove bogus include path with in-tree cloog

rapped and regression-tested on x86_64-linux-gnu. OK for trunk? Thanks Bernd. 2014-06-20 Bernd Edlinger Fix include path for in-tree cloog. * config/cloog.m4 (CLOOG_INIT_FLAGS): Remove bogus include path. * configure: Regenerat

[PATCH] Fix forwporp pattern (T)(P + A) - (T)P -> (T)A

and regression-tested on x86_64-linux-gnu with all languages, including Ada. OK for trunk? Thanks Bernd. gcc/ChangeLog: 2014-06-22 Bernd Edlinger * tree-ssa-forwprop.c (associate_plusminus): For widening conversions check for undefi

RE: [PATCH] Change default for --param allow-...-data-races to off

Hi, On Fri, 20 Jun 2014 13:44:18, Martin Jambor wrote: > > Hi, > > On Thu, Jun 19, 2014 at 06:18:47PM +0200, Bernd Edlinger wrote: >> Hi, >> >> from a recent discussion on g...@gcc.gnu.org I have learned that the default >> of >> --param allow-stor

RE: [PATCH] Change default for --param allow-...-data-races to off

Hi Martin, >> >> Well actually, I am not sure if we ever wanted to have a race condition here. >> Have you seen any impact of --param allow-store-data-races on any benchmark? > > It's trivially to write one. The only pass that checks the param is > tree loop invariant motion and it does that when

RE: [PATCH] Fix forwporp pattern (T)(P + A) - (T)P -> (T)A

Hi, On Mon, 23 Jun 2014 10:40:53, Richard Biener wrote: > > On Sun, Jun 22, 2014 at 9:14 AM, Bernd Edlinger > wrote: >> Hi, >> >> I noticed that several testcases in the GMP-4.3.2 test suite are failing now >> which >> did not happen with GCC 4.9.0. I d

RE: [PATCH] Fix forwporp pattern (T)(P + A) - (T)P -> (T)A

Hi, On Mon, 23 Jun 2014 10:27:59, Jeff Law wrote: > > On 06/22/14 01:14, Bernd Edlinger wrote: >> Hi, >> >> I noticed that several testcases in the GMP-4.3.2 test suite are failing now >> which >> did not happen with GCC 4.9.0. I debugged the first one, mpz/co

RE: [PATCH] Fix forwporp pattern (T)(P + A) - (T)P -> (T)A

Hi, On Mon, 23 Jun 2014 19:12:47, Richard Biener wrote: > > On Mon, Jun 23, 2014 at 4:28 PM, Bernd Edlinger > wrote: >> Hi, >> >> On Mon, 23 Jun 2014 10:40:53, Richard Biener wrote: >>> >>> On Sun, Jun 22, 2014 at 9:14 AM, Bernd Edlinger >>

RE: [PATCH] Fix forwporp pattern (T)(P + A) - (T)P -> (T)A

Hi, On Mon, 23 Jun 2014 16:22:13, Eric Botcazou wrote: > >> I noticed that several testcases in the GMP-4.3.2 test suite are failing now >> which did not happen with GCC 4.9.0. I debugged the first one, >> mpz/convert, and found the file mpn/generic/get_str.c was miscompiled. >> >> mpn/get_str.c.1

[PATCH] Fix forwprop pattern (T)(P + A) - (T)P -> (T)A, Part 1

point types. Thus _Sat is only allowed with _Frac or _Accum. I have not seen anything different, for instance a vector, with saturation yet. OK for trunk after boot-strap & regression-test? Thanks Bernd. gcc/ChangeLog: 2014-06-24 Bernd Edli

[PATCH] Fix forwprop pattern (T)(P + A) - (T)P -> (T)A, Part 2

for trunk? Thanks Bernd. 2014-06-25 Bernd Edlinger * tree-ssa-forwprop.c (associate_plusminus): For widening conversions check for undefined overflow in (T)(P + A) - (T)P -> (T)A. Issue a strict overflow warning if appropri

RE: [PATCH] Change default for --param allow-...-data-races to off

Hi, On Thu, 26 Jun 2014 08:43:46, Richard Biener wrote: > > On June 26, 2014 12:03:21 AM CEST, Martin Jambor wrote: >>Hi, >> >>On Wed, Jun 25, 2014 at 03:14:31PM -0600, Jeff Law wrote: >>> On 06/24/14 14:19, Martin Jambor wrote: >>>>On Mon, Jun 23, 2

RE: [patch 0/27] RFC: Use automake-1.11.6 across the tree

Hi, On Tue, 5 May 2015 18:03:15, Michael Haubenwallner wrote: > > Now that gcc-5 is out, what about an automake-1.11.6 update for gcc-6? > > BTW, the actual commands I use to re-run automake for everything (I found) is: > $ export AUTOMAKE='automake-1.11 --add-missing --copy --force-missing' > $

RE: [patch 1/28] top-level: Use automake-1.11.6

Hi, On Wed, 6 May 2015 15:55:57, Joseph S. Myers wrote: > > On Wed, 6 May 2015, Michael Haubenwallner wrote: > >> Am 2015-05-05 um 18:03 schrieb Michael Haubenwallner: >>> Now that gcc-5 is out, what about an automake-1.11.6 update for gcc-6? >> >> Patch for top-level files. > > I don't think this

RE: [patch 0/27] RFC: Use automake-1.11.6 across the tree

Hi Michael, On Thu, 7 May 2015 18:52:52, Michael Haubenwallner wrote: > > Hi Bernd, > > On 05/06/2015 03:01 PM, Bernd Edlinger wrote: >> On Tue, 5 May 2015 18:03:15, Michael Haubenwallner wrote: >>> >>> Now that gcc-5 is out, what about an automake-1.11.6 updat

RE: [patch 1/28] top-level: Use automake-1.11.6

Hi, On Thu, 7 May 2015 15:25:14, Joseph S. Myers wrote: > > On Thu, 7 May 2015, Bernd Edlinger wrote: > >> But that is not the case for other tool scripts. I think these should >> be in-sync with the automake version that creates the configure scripts >> that make use

RE: [patch 1/28] top-level: Use automake-1.11.6

Hi, On Fri, 8 May 2015 16:41:02, Joseph S. Myers wrote: > > On Fri, 8 May 2015, Bernd Edlinger wrote: > >> One example where there is an incompatibility is "missing": >> >> Formerly it had code that emulated the missing "flex" by >> creating

RE: [patch 1/28] top-level: Use automake-1.11.6

Hi, On Fri, 8 May 2015 20:20:55, Joseph S. Myers wrote: > > On Fri, 8 May 2015, Bernd Edlinger wrote: > >> But it made the in-tree gmp configure script fail. That would not >> have happened if we did not pass our version of missing to a sub- >> module like gmp, that al

RE: [PATCH, committed] Update Automake files

Hello Jan-Benedict, > Hi! > > This patch updates the files taken from Automake. Committed. > > MfG, JBG the updated version of "missing" will confuse the gmp-4.3.2 configure script if it is installed in-tree with "contrib/download_prerequisites" and flex is not installed: ... checking readli

Re: [PATCH 4/4] OpenMP 4.0 offloading to Intel MIC: non-fallback testing

Aehm Kirill, excuse me please, but if I do autogen Makefile.def I get this from svn diff Index: Makefile.in === --- Makefile.in    (revision 217890) +++ Makefile.in    (working copy) @@ -35238,9 +35238,6 @@ $(SHELL) $(srcdir)

RE: [PATCH 4/4] OpenMP 4.0 offloading to Intel MIC: non-fallback testing

Hi Ilya, On Fri, 21 Nov 2014 21:44:40, Ilya Verbin wrote: > > Hi, > > On 21 Nov 19:19, Bernd Edlinger wrote: >> so, did you really regenerate Makefile.in in that patch, or am I missing >> something ? > > You're right. This patch was rebased so many times, th

[PATCH] Work around in-tree gmp configure problems

for trunk? Thanks Bernd. 2014-11-22 Bernd Edlinger * Makefile.def (module=gmp): Work around in-tree gmp configure bug with missing flex. * Makefile.in: Regenerated. patch-gmp.diff Description: Binary data

RE: [PING**4] [PATCH] Fix PR ipa/61190, 2nd edition‏

re_flag to exclude the virtual >>>> thunks, taking care that other >>>> users of call_for_symbol_thunks_and_aliases do not get a different >>>> behavior than before this patch. >>>> >>>> >>>> The attached patch was boot-strapped

RE: [PATCH] Work around in-tree gmp configure problems

Hi Richard, On Mon, 24 Nov 2014 14:11:19 +0100, Jan-Benedict Glaw wrote: > > Hi Richard, > > On Mon, 2014-11-24 12:53:11 +0100, Richard Biener > wrote: >> On Sat, Nov 22, 2014 at 4:34 PM, Jan-Benedict Glaw wrote: >>> On Sat, 2014-11-22 14:33:29 +0100, Bernd Ed

RE: [PATCH] Fix PR ipa/61190, updated

thod function_or_virtual_thunk_symbol() for this. And simplified the algorithm of both function_symbol variants a bit. Attached, you'll find my updated patch for review. Boot-strapped and regression tested on x86_64-linux-gnu. OK for trunk? Thanks Bernd. > Can you, please, sen

[PATCH, REPOST] Fix PR fortran/60718

, Bernd Edlinger wrote: > > Hi Tobias, > > On Fri, 11 Apr 2014 16:04:51, Tobias Burnus wrote: >> >> Hi Tobias, >> >> On Fri, Apr 11, 2014 at 02:39:57PM +0200, Bernd Edlinger wrote: >>> On Fri, 11 Apr 2014 13:37:46, Tobias Burnus wrote: >>> Hmm, &g

RE: [PATCH] Fix another wrong-code bug with -fstrict-volatile-bitfields

regression-tested on x86_64-linux-gnu. OK for trunk and 4.9? Thanks Bernd. gcc: 2015-03-04 Bernd Edlinger * expmed.c (strict_volatile_bitfield_p): Don't return different results if !STRICT_ALIGNMENT. Use GET_MODE_BITSIZE inste

[PATCH] Fix a typo in the german language translation

Hi, if nobody objects, I'd like to fix this in the german language translation file locally. I have already informed the german language translation team and yesterday this message has been fixed upstream.  But this typo is just too ugly to leave it for another year! Bernd. 2015-03-04 

RE: [PATCH] Fix a typo in the german language translation

On Wed, 4 Mar 2015 17:52:11, Jospeh S. Myers wrote: > > On Wed, 4 Mar 2015, Bernd Edlinger wrote: > >> if nobody objects, I'd like to fix this in the german language >> translation file locally. I have already informed the german language > > All local changes to .

[PATCH] Fix PR rtl-optimization/65067

load the value first in a register, we can safely use store_bit_field on the register and move the result back. Boot-Strapped and regression-tested on Cortex-M3. OK for trunk? Thanks Bernd. gcc: 2015-03-05 Bernd Edlinger PR rt

RE: [PATCH] Fix PR rtl-optimization/65067

Hi, On Thu, 5 Mar 2015 09:52:54, Richard Biener wrote: > > On Thu, Mar 5, 2015 at 8:10 AM, Bernd Edlinger > wrote: >> Hi, >> >> on ARM we have a code quality regression, because of the strict volatile >> bitfields handing. The reason is that the current im

RE: [PATCH] Fix another wrong-code bug with -fstrict-volatile-bitfields

Hi, On Thu, 5 Mar 2015 10:00:26, Richard Biener wrote: > > On Wed, Mar 4, 2015 at 3:13 PM, Bernd Edlinger > wrote: >> bounced... again, without html. >> >> >> Hi Richard, >> >> while working on another bug in the area of -fstrict-volatile-bitfiel

RE: [PATCH] Fix another wrong-code bug with -fstrict-volatile-bitfields

Hi, On Thu, 5 Mar 2015 12:24:56, Richard Biener wrote: > > On Thu, Mar 5, 2015 at 12:00 PM, Bernd Edlinger > wrote: >> Hi, >> >> On Thu, 5 Mar 2015 10:00:26, Richard Biener wrote: >>> >>> On Wed, Mar 4, 2015 at 3:13 PM, Bernd Edlinger >> Maybe o

<    2   3   4   5   6   7   8   9   10   11   >