Re: [PATCH v3, rs6000] Add built-in support for vector compare listed in the ABI

On Dez 06 2016, "Carl E. Love" wrote: > diff --git a/gcc/testsuite/gcc.target/powerpc/builtins-3-p9.c > b/gcc/testsuite/gcc.target/powerpc/builtins-3-p9.c > new file mode 100644 > index 000..d846e29 > --- /dev/null > +++ b/gcc/testsuite/gcc.target/powerpc/builtins-3-p9.c > @@ -0,0 +1,42 @@ >

Re: [PATCH] Do not suggest -fsanitize=all (PR driver/78863).

On 12/21/2016 04:03 PM, Martin Liška wrote: > On 12/21/2016 11:28 AM, Jakub Jelinek wrote: >> On Wed, Dec 21, 2016 at 11:20:33AM +0100, Martin Liška wrote: >>> I like your approach! >>> make check -k -j10 RUNTESTFLAGS="dg.exp=spellcheck-options-*" works fine. >>> >>> Am I install the patch after it

Re: [PATCH] Do not suggest -fsanitize=all (PR driver/78863).

On Mon, Jan 02, 2017 at 01:52:22PM +0100, Martin Liška wrote: > Is it fine to install the patch to gcc-6 branch? Ok. Jakub

Re: [committed] Fix up libgomp/hashtab.h license

On Tue, 1 Nov 2016, Jakub Jelinek wrote: > libgomp is GPLv3 + runtime exception licensed, hashtab.h has been copied > and adjusted from include/ similarly how splay-tree.c has been changed, > the latter got the GPLv3 + runtime exception boiler plate, but not > hashtab.h. > > Fixed thusly, committe

[doc] cfg.texi - remove two references to Java

Applied. Gerald 2017-01-02 Gerald Pfeifer * doc/cfg.texi (Edges): Remove reference to Java. (Maintaining the CFG): Ditto. Index: doc/cfg.texi === --- doc/cfg.texi(revision 244001) +++ doc/cfg.texi

[patch,avr] PR78883: Implement CANNOT_CHANGE_MODE_CLASS.

This fixes PR78883 which is a problem in reload revealed by a change to combine.c. The fix is as proposed by Segher: implement CANNOT_CHANGE_MODE_CLASS. Ok for trunk? Johann gcc/ PR target/78883 * config/avr/avr.h (CANNOT_CHANGE_MODE_CLASS): New define. * config/avr/av

Re: [patch,avr] PR78883: Implement CANNOT_CHANGE_MODE_CLASS.

On Mon, Jan 02, 2017 at 03:47:43PM +0100, Georg-Johann Lay wrote: > This fixes PR78883 which is a problem in reload revealed by a > change to combine.c. The fix is as proposed by Segher: implement > CANNOT_CHANGE_MODE_CLASS. > > Ok for trunk? > > Johann > > > gcc/ > PR target/78883 >

Re: RFC [1/3] divmod transform v2

On 10/16/2016 07:59 AM, Prathamesh Kulkarni wrote: > + /* Disable the transform if either is a constant, since > division-by-constant > + may have specialized expansion. */ > + if (CONSTANT_CLASS_P (op1) || CONSTANT_CLASS_P (op2)) > +return false; Hello. I've just played a bit with DI

Re: [patch,avr] PR78883: Implement CANNOT_CHANGE_MODE_CLASS.

On 02.01.2017 15:54, Dominik Vogt wrote: On Mon, Jan 02, 2017 at 03:47:43PM +0100, Georg-Johann Lay wrote: This fixes PR78883 which is a problem in reload revealed by a change to combine.c. The fix is as proposed by Segher: implement CANNOT_CHANGE_MODE_CLASS. Ok for trunk? Johann gcc/

Re: [PATCH] DWARF: make signedness explicit for enumerator const values

On 12/09/2016 03:06 PM, Jason Merrill wrote: I think it's fine guarded by !dwarf_strict; most consumers should happily ignore it if they don't know what to do with it. Thank you for your feedback! This ultimate patch is much smaller. :-) Still bootstrapped and tested successfuly on x86_64-linu

Re: [PATCH] DWARF: make signedness explicit for enumerator const values

On Mon, Jan 02, 2017 at 06:24:43PM +0100, Pierre-Marie de Rodat wrote: > --- a/gcc/dwarf2out.c > +++ b/gcc/dwarf2out.c > @@ -20930,6 +20930,11 @@ gen_enumeration_type_die (tree type, dw_die_ref > context_die) > if (ENUM_IS_OPAQUE (type)) > add_AT_flag (type_die, DW_AT_declaration

Re: RFC [1/3] divmod transform v2

On 2 January 2017 at 20:37, Martin Liška wrote: > On 10/16/2016 07:59 AM, Prathamesh Kulkarni wrote: >> + /* Disable the transform if either is a constant, since >> division-by-constant >> + may have specialized expansion. */ >> + if (CONSTANT_CLASS_P (op1) || CONSTANT_CLASS_P (op2)) >> +

[PATCH] Fix ICE with -fno-sso-struct=none (PR driver/78957)

Hi! Enum options should not allow negative form, otherwise the option handling ICEs on it. -fsso-struct= allows only big-endian or little-endian, -fno-sso-struct=big-endian or -fno-sso-struct=whatever makes no sense. Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk? 2017-01-0

[C++ PATCH] Reject invalid reference type non-static data members in unions (PR c++/78890)

Hi! As mentioned in the PR, C++98 didn't allow static data members nor any members with reference type, and r211318 guarded all that with cxx_dialect < cxx11. Which is correct for the VAR_P check, but as C++11 and later says that non-static data members of reference type are ill-formed in unions,

[PATCH] Avoid -fprintf-return-value from optimizing away snprintf (0, 0, "...%n...", ...) (PR tree-optimization/78965)

Hi! Even when we know the exact return value of a snprintf call with 0 length (i.e. one that doesn't write anything into a buffer), there can be %n directives in the format string that have side-effects that shouldn't be discarded. The following patch avoids the replacement of the snprintf call w

[PATCH] Avoid ICEs with throwing calls with -fprintf-return-value (PR middle-end/78901)

Hi! As my earlier patch to adjust cfns.gperf for C99/C11 builtins has been committed already, the non-__*_chk builtins (and when using __builtin__*_chk form even those) should be all noexcept, and when using fortification the glibc headers declare those properly throw() and ssp includes just use b

[PATCH] Optimize away useless snprintf calls with -fprintf-return-value

Hi! As mentioned in PR78901, the current -fprintf-return-value optimization will remove (replace with constant) calls like: int foo (void) { return snprintf (0, 0, "%s%d", "abcde", 5); } but not void bar (void) { snprintf (0, 0, "%s%d", "abcde", 5); } which doesn't have any side-effect either

Make MIPS soft-fp preserve NaN payloads for NAN2008

The MIPS sfp-machine.h has an _FP_CHOOSENAN implementation which emulates hardware semantics of not preserving signaling NaN payloads for an operation with two NaN arguments (although that doesn't suffice to avoid sNaN payload preservation in any case with just one NaN argument). However, those ar

[C++ PATCH] Don't reject auto deduction of multiple variables if some initializers were type dependent (PR c++/78693)

Hi! As the testcase shows, if some initializers are type dependent, auto_result is still using auto, is not yet deduced and the deduction will happen during instantiation. So rejecting it due to inconsistent deduction when one type is int and another type auto (or vice versa) is wrong, during ins

[PATCH] Special case clzl like builtins in factor_out_conditional_conversion (PR tree-optimization/71016)

Hi! The clzl-like integral unary builtins at least from my short testing on x86_64-linux and aarch64-linux usually benefit from factor_out_conditional_conversion not being performed, i.e. the sign-extension (or zero-extension) being performed closer to the actual builtin, because both library call

[PATCH, i386]: Fix PR 78967, inserts are not effective

Hello! Attached patch introduces various missing insert patterns, improving attached testcases considerably. As a necessary complication to improve robustness, the patch tags x86_64 patterns that require memory operands without REX prefix with a UNSPEC_NOREX_MEM tag to prevent unwanted pattern mat

Re: [PATCH] Avoid -fprintf-return-value from optimizing away snprintf (0, 0, "...%n...", ...) (PR tree-optimization/78965)

On 01/02/2017 12:36 PM, Jakub Jelinek wrote: Hi! Even when we know the exact return value of a snprintf call with 0 length (i.e. one that doesn't write anything into a buffer), there can be %n directives in the format string that have side-effects that shouldn't be discarded. The following patc

Re: [PATCH] Avoid -fprintf-return-value from optimizing away snprintf (0, 0, "...%n...", ...) (PR tree-optimization/78965)

On Mon, Jan 02, 2017 at 03:51:14PM -0700, Martin Sebor wrote: > On 01/02/2017 12:36 PM, Jakub Jelinek wrote: > > Hi! > > > > Even when we know the exact return value of a snprintf call with 0 length > > (i.e. one that doesn't write anything into a buffer), there can be %n > > directives in the for

Re: [PATCH] Avoid ICEs with throwing calls with -fprintf-return-value (PR middle-end/78901)

On 01/02/2017 12:54 PM, Jakub Jelinek wrote: Hi! As my earlier patch to adjust cfns.gperf for C99/C11 builtins has been committed already, the non-__*_chk builtins (and when using __builtin__*_chk form even those) should be all noexcept, and when using fortification the glibc headers declare tho

Make MicroBlaze support DWARF EH (old Xilinx patch, needed for glibc build)

This patch, taken from and with a few formatting cleanups and an update for the removal of gen_rtx_raw_REG, enables DWARF EH support for MicroBlaze. This is needed for building glibc with a comp

Re: [PATCH] Avoid ICEs with throwing calls with -fprintf-return-value (PR middle-end/78901)

On Mon, Jan 02, 2017 at 04:38:03PM -0700, Martin Sebor wrote: > Thanks for taking care of this bug! Punting on this case sounds > fine. > > I was not familiar with the stmt_ends_bb_p() function or how it > relates to exceptions so I looked it up. It looks to be a wrapper > around is_ctrl_stmt()

Re: [PATCH] Optimize away useless snprintf calls with -fprintf-return-value

On 01/02/2017 01:04 PM, Jakub Jelinek wrote: Hi! As mentioned in PR78901, the current -fprintf-return-value optimization will remove (replace with constant) calls like: int foo (void) { return snprintf (0, 0, "%s%d", "abcde", 5); } but not void bar (void) { snprintf (0, 0, "%s%d", "abcde", 5

[-fcompare-debug] find jump before debug insns in expand

A debug insn after the final jump of a basic block may cause the expander to emit a dummy move where the non-debug compile won't because it finds the jump insn at the end of the insn stream. Fix the condition so that, instead of requiring the jump as the last insn, it also matches a jump followed

[bootstrap-O1] enlarge sprintf output buffer to avoid warning

In stage2 of bootstrap-O1, the code that warns if sprintf might overflow its output buffer cannot tell that an unsigned value narrowed to 16 bits will fit in 4 bytes with %4x. I couldn't find a better way to avoid the warning at -O1 than growing the buffer so that there's no doubt the output will

[bootstrap-O3,fortran] add a NULL initializer to avoid a warning at -O3

Building with the bootstrap-O3 configuration option fails to compile fortran/module.c due to an AFAICT false-positive warning about an uninitialized use of a variable. This patch adds a dummy initializer to silence it. Regstrapped on x86_64-linux-gnu and i686-linux-gnu. OK to install? for gcc/

[-fcompare-debug] skip more debug stmts in cleanup_empty_eh

Various Ada RTS files failed -fcompare-debug compilation because debug stmts prevented EH cleanups from taking place. Adjusting cleanup_empty_eh to skip them fixes it. Regstrapped on x86_64-linux-gnu and i686-linux-gnu. Ok to install? for gcc/ChangeLog * gimple-iterator.h (gsi_one_non

[bootstrap-O3] add a default initializer to avoid a warning at -O3

Building with the bootstrap-O3 configuration option fails to compile input.c due to an AFAICT false-positive warning about an uninitialized use of a variable. This patch adds a default initializer to silence it. Regstrapped on x86_64-linux-gnu and i686-linux-gnu. OK to install? for gcc/ChangeL

[bootstrap-O3] use unsigned type for regno in df-scan

This patch fixes a false-positive warning in df-scan, at bootstrap-O3 failed, and enables GCC to optimize out the code that leads to the warning. df_ref_create_structure was inlined into the else part of df_ref_record. Due to the condition of the corresponding if, In the else part, VRP deduced un

[bootstrap-O1] add initializers to avoid warnings at -O1

Building with the bootstrap-O1 configuration option fails to compile a number of files due to AFAICT false-positive warnings about uses of uninitialized variables. This patch adds dummy initializers to silence them all. Regstrapped on x86_64-linux-gnu and i686-linux-gnu. OK to install? for gcc

[bootstrap-O3,fortran] silence warning in simplify_transformation_to_array

simplify_transformation_to_array had the nested loop unrolled 7 times, which is reasonable given that it iterates over arrays of size GFC_MAX_DIMENSIONS == 7. The problem is that the last iteration increments the index, tests that it's less than result->rank, and then accesses the arrays with the

[-fcompare-debug] var tracking options are not optimization options

If we include them in the ICF hash, they may cause congruence_groups to be processed in a different order due to different hashes, which in turn causes different funcdef_nos to be assigned to functions. Since these numbers are included in -fcompare-debug dumps, they cause failures. Since these op

Const correctness fixes for darwin-driver.c

The various darwin ports in config-list.mk fail to build with a trunk compiler due to two minor const-correctness issues. With this patch installed all the darwin ports in config-list.mk build successfully. Installed on the trunk. Jeff diff --git a/gcc/ChangeLog b/gcc/ChangeLog index 31aa

Re: [PATCH] Avoid -fprintf-return-value from optimizing away snprintf (0, 0, "...%n...", ...) (PR tree-optimization/78965)

On January 2, 2017 8:36:34 PM GMT+01:00, Jakub Jelinek wrote: >Hi! > >Even when we know the exact return value of a snprintf call with 0 >length >(i.e. one that doesn't write anything into a buffer), there can be %n >directives in the format string that have side-effects that shouldn't >be >discar

Re: [PATCH] Avoid ICEs with throwing calls with -fprintf-return-value (PR middle-end/78901)

On January 2, 2017 8:54:03 PM GMT+01:00, Jakub Jelinek wrote: >Hi! > >As my earlier patch to adjust cfns.gperf for C99/C11 builtins has been >committed already, the non-__*_chk builtins (and when using >__builtin__*_chk >form even those) should be all noexcept, and when using fortification >the gl

Re: [PATCH] genmatch fix (PR tree-optimization/71563)

On January 2, 2017 8:55:45 AM GMT+01:00, Jakub Jelinek wrote: >On Thu, Dec 29, 2016 at 10:18:34PM +0100, Jakub Jelinek wrote: >> On Tue, Dec 20, 2016 at 09:45:03PM +0100, Jakub Jelinek wrote: >> > That is what I tried first, but there is some bug in genmatch.c >that >> > prevents it. The: >> > (