Re: [PATCH, rs6000] Use direct moves for __builtin_signbit for 128-bit floating-point

Hi, I've revised the patch to address the previous concerns. rs6000_split_signbit has been greatly simplified since SF and DF modes are not currently of interest. The use of -static-libgcc did indeed turn out to be leftover from long-ago necessity and is no longer needed. I also updated the

[PATCH] doc fix for c/71560 - union compound literal initializes wrong union field

The bug points out a couple of conformance problems in the GCC manual where is discusses compound literals and casts to unions and says that a compound literal is equivalent to a cast. It isn't because a compound literal is an lvalue but a cast yields an rvalue. The attached patch corrects this

[PATCH] simplify-rtx.c: start adding selftests

This patch starts adding selftests to simplify-rtx.c, to ensure that RTL expressions are simplified as we expect. It adds a new ASSERT_RTX_EQ macro that checks for pointer equality of two rtx values. If they're non-equal, it aborts, printing both expressions. For example:

Re: [PATCH, rs6000] Use direct moves for __builtin_signbit for 128-bit floating-point

On Fri, Jul 01, 2016 at 04:37:35PM -0500, Bill Schmidt wrote: > Hi Segher, > > > On Jun 29, 2016, at 4:43 PM, Segher Boessenkool > > wrote: > > > > Why does this need -static-libgcc? > > Mike, can you please respond to this? I was curious about this also > but

Re: [PATCH, rs6000] Use direct moves for __builtin_signbit for 128-bit floating-point

Hi Segher, > On Jun 29, 2016, at 4:43 PM, Segher Boessenkool > wrote: > > Hi, > > On Tue, Jun 28, 2016 at 04:44:08PM -0500, Bill Schmidt wrote: >> +void >> +rs6000_split_signbit (rtx dest, rtx src) >> +{ >> + machine_mode d_mode = GET_MODE (dest); >> +

Re: [PATCH PR70729] The second part of patch.

On Thu, Jun 30, 2016 at 7:51 AM, Yuri Rumyantsev wrote: > Richard, > > Could you please review additional simple fix for 70729 - we need to > nullify safelen field of loops containing simduid intrinsics like > GOMP_SIMD_LANE (introduced e.g. for private variables). I checked

[C PATCH] Fix -Wunused-but-set-* regression with vector indexing (PR c/71719)

Hi! In r236630 we started using VCE for vector indexing, but * expr.c (mark_exp_read): Handle VIEW_CONVERT_EXPR. has been changed in C++ FE only, not C FE, while it is needed in C FE too as the

[PATCH] OpenACC routines in fortran modules

It turns out that the acc routine parallelism isn't being recorded in fortran .mod files. This is a problem because then the ME can't validate if a routine has compatible parallelism with the call site. This patch does two things: 1. Encode gang, worker, vector and seq level parallelism in

PING^6: [PATCH] PR target/70454: Build x86 libgomp with -march=i486 or better

On Tue, Jun 7, 2016 at 9:03 AM, H.J. Lu wrote: > On Sun, May 29, 2016 at 3:14 PM, H.J. Lu wrote: >> On Fri, May 20, 2016 at 8:04 AM, H.J. Lu wrote: >>> On Mon, May 9, 2016 at 5:52 AM, H.J. Lu wrote: On

Re: [PATCHv3, testsuite] Enable some existing __float128 tests for powerpc

> On Jul 1, 2016, at 2:49 PM, Joseph Myers wrote: > > On Fri, 1 Jul 2016, Bill Schmidt wrote: > >> +/* { dg-additional-options "-mfloat128 -mvsx" { target powerpc*-*-* } } */ > > I still think you should be using { dg-add-options float128 }, via > defining

Re: [PATCHv3, testsuite] Enable some existing __float128 tests for powerpc

On Fri, Jul 1, 2016 at 3:39 PM, Bill Schmidt wrote: > Hi, > > This changes my previous patch to use a separate base_quadfloat_support > effective target that can be used in conjunction with either the float128 > or __float128 effective targets, and modifies the tests

Re: [PATCHv3, testsuite] Enable some existing __float128 tests for powerpc

On Fri, 1 Jul 2016, Bill Schmidt wrote: > +/* { dg-additional-options "-mfloat128 -mvsx" { target powerpc*-*-* } } */ I still think you should be using { dg-add-options float128 }, via defining add_options_for_float128, rather than hardcoding these options in individual tests. -- Joseph S.

[PATCHv3, testsuite] Enable some existing __float128 tests for powerpc

Hi, This changes my previous patch to use a separate base_quadfloat_support effective target that can be used in conjunction with either the float128 or __float128 effective targets, and modifies the tests accordingly. I dropped adding support for float128-exact-underflow.c for now; that can be

Re: [PATCH][ARM] -mpure-code option for ARM

On 06/30/2016 08:32 AM, Andre Vieira (lists) wrote: @@ -14498,6 +14499,14 @@ Print CPU tuning information as comment in assembler file. This is an option used only for regression testing of the compiler and not intended for ordinary use in compiling code. This option is disabled by

[PATCH] - improve sprintf buffer overflow detection (middle-end/49905)

The attached patch enhances compile-time checking for buffer overflow and output truncation in non-trivial calls to the sprintf family of functions under a new option -Wformat-length=[12]. This initial patch handles printf directives with string, integer, and simple floating arguments but

Re: [PATCH, rs6000] Fix PR target 71656, reload ICE when -mcpu=power9 -mpower9-dform-vector

On 6/27/16 8:30 PM, Peter Bergner wrote: On 6/27/16 3:21 PM, Segher Boessenkool wrote: On Sat, Jun 25, 2016 at 07:14:01PM -0500, Peter Bergner wrote: Okay for trunk, okay for 6 later. One comment: + if (VECTOR_MODE_P (mode) + && !mode_supports_vsx_dform_quad (mode)) +return false;

Re: [RFC] Change order of Fortran BLOCK_VARS (PR fortran/71687, take 2)

Le 01/07/2016 16:58, Jakub Jelinek a écrit : On Thu, Jun 30, 2016 at 08:06:54PM +0200, Jakub Jelinek wrote: So, is it intentional that pushdecl / getdecls acts like a LIFO? Though, it seems user vars are pushdecled in the reverse order of declarations, but gfc_add_decl_to_function is called in

Re: [PATCH 2/4] PR c++/62314: add fixit hint for "expected ';' after class definition"

On Mon, 2016-05-02 at 12:40 +0200, Bernd Schmidt wrote: > On 04/28/2016 04:28 PM, David Malcolm wrote: > > whereas clang reportedly emits: > > > > test.c:2:12: error: expected ';' after struct > > struct a {} > > ^ > > ; > > > > (note the offset of the location, and

Re: [PATCH, rs6000] Fix PR target/71698, ICE in reload copying TDmode values to GPR regs

On 6/30/16 6:21 PM, Segher Boessenkool wrote: On Thu, Jun 30, 2016 at 05:55:04PM -0500, Peter Bergner wrote: We currently don't allow TDmode values to use direct moves, since they live in register pairs and the most significant word is always in the even-numbered register which does not match

Re: Improve insert/emplace robustness to self insertion

On 01/07/16 10:54 +0100, Jonathan Wakely wrote: On 30/06/16 21:51 +0200, François Dumont wrote: On 29/06/2016 23:30, Jonathan Wakely wrote: iterator insert(const_iterator __position, value_type&& __x) { return emplace(__position, std::move(__x)); } That's suboptimal, since in the

Re: [PATCH] fix interaction of -S and -x {c,c++}-header

>>> On 01.07.16 at 17:17, wrote: > On 07/01/2016 10:22 AM, Jan Beulich wrote: >> Irrespective of the use of -o this so far resulted in "error: output >> filename specified twice", since cc1_options already produces a -o >> option when -S was specified. >> >> gcc/ >>

[C++ PATCH] Fix ICE with PTRMEM_CST (PR c++/70869)

Hi! As mentioned in the PR, we ICE on these testcases because PTRMEM_CST for non-static var DECL_INITIAL is now supposed to be replaced during genericization, but for some artifical vars the initializers are actually never genericized. For user variables, the VAR_DECLs should appear in

[gomp4] backport fortran FE error handling changes

I've applied this patch to gomp-4_0-branch which backports the recent error handling changes I made to the fortran FE. The discussion for the original patch for trunk can be found in this thread . 2016-07-01 Cesar Philippidis

Re: [PATCH] fix interaction of -S and -x {c,c++}-header

On 07/01/2016 10:22 AM, Jan Beulich wrote: Irrespective of the use of -o this so far resulted in "error: output filename specified twice", since cc1_options already produces a -o option when -S was specified. gcc/ 2016-07-01 Jan Beulich * varasm.c

[committed] Re: A gfortran silent "wrong code" bug in the transition from 4.9.0 -> 4.9.1, using OpenMP. (PR fortran/71717)

On Thu, Jun 30, 2016 at 10:00:23PM +0200, Toon Moene wrote: > On 06/30/2016 08:43 PM, Jakub Jelinek wrote: > > >On Thu, Jun 30, 2016 at 07:33:53PM +0200, Toon Moene wrote: > > >>A colleague of mine at Meteo France, Toulouse, managed to reduce a problem > >>he had with our common weather

[PATCH] Fix hangs with long double atomics (PR middle-end/71716)

Hi! As mentioned in the PR, atomics on types that contain some inner padding (e.g. long double type on x86_64) have various issues. Before my ATOMIC_COMPARE_EXCHANGE internal-fn addition, unless the user uses atomic_compare_exchange* APIs and changes (e.g. copies elsewhere) the expected variable,

[RFC] Change order of Fortran BLOCK_VARS (PR fortran/71687, take 2)

On Thu, Jun 30, 2016 at 08:06:54PM +0200, Jakub Jelinek wrote: > So, is it intentional that pushdecl / getdecls acts like a LIFO? > Though, it seems user vars are pushdecled in the reverse order of > declarations, but gfc_add_decl_to_function is called in the user declared > order, so perhaps for

[PATCH] error on missing LTO symbols

Both OpenMP and OpenACC allow the user to call functions and access global variables. Usually, the user needs to explicitly mark those functions and variables as offloadable. However, for certain functions, such as those in libc, libm, etc., it makes sense to allow the user call functions and use

[PATCH] S/390: Add support for z13 instructions lochi and locghi.

The attached patch adds patterns to make use of the z13 LOCHI and LOCGHI instructions. Tested on s390x biarch and s390, regression tested on s390x. Ciao Dominik ^_^ ^_^ -- Dominik Vogt IBM Germany gcc/ChangeLog * config/s390/s390.md: Add "z13" cpu_facility. ("*movcc"): Add

[PATCH v2] extend shift count warnings to vector types

gcc/c/ 2016-07-01 Jan Beulich * c-fold.c (c_fully_fold_internal): Also emit shift count warnings for vector types. * c-typeck.c (build_binary_op): Likewise. gcc/testsuite/ 2016-07-01 Jan Beulich * gcc.dg/vshift-6.c,

Re: [PATCH v2] check initializer to be zero in .bss-like sections

On 07/01/2016 03:57 PM, Jan Beulich wrote: Do I need to re-submit, or can I take the above as approved-with- that-change? Ok with that change. Bernd

Re: [PATCH v2] check initializer to be zero in .bss-like sections

>>> On 01.07.16 at 15:44, wrote: > On 07/01/2016 03:42 PM, Jan Beulich wrote: > On 01.07.16 at 15:36, wrote: > >>> Looks ok, except why the empty dg-options string in the testcase? >> >> Because I've seen in it that way in various other test cases

Re: [PATCH v2] check initializer to be zero in .bss-like sections

On 07/01/2016 03:42 PM, Jan Beulich wrote: On 01.07.16 at 15:36, wrote: Looks ok, except why the empty dg-options string in the testcase? Because I've seen in it that way in various other test cases (and yes, yet others don't have it). I had to decide for one of the

Re: [PATCH v2] check initializer to be zero in .bss-like sections

>>> On 01.07.16 at 15:36, wrote: > On 07/01/2016 10:21 AM, Jan Beulich wrote: >> Just like gas, which has recently learned to reject such initializers, >> gcc shouldn't accept such either. >> --- >> v2: Use dg-require-named-sections. >> >> gcc/ >> 2016-07-01 Jan Beulich

Re: [PATCHv2, ARM, libgcc] New aeabi_idiv function for armv6-m

On 13/10/15 18:01, Andre Vieira wrote: > This patch ports the aeabi_idiv routine from Linaro Cortex-Strings > (https://git.linaro.org/toolchain/cortex-strings.git), which was contributed > by ARM under Free BSD license. > > The new aeabi_idiv routine is used to replace the one in >

Re: [PATCH v2] check initializer to be zero in .bss-like sections

On 07/01/2016 10:21 AM, Jan Beulich wrote: Just like gas, which has recently learned to reject such initializers, gcc shouldn't accept such either. --- v2: Use dg-require-named-sections. gcc/ 2016-07-01 Jan Beulich * varasm.c (get_variable_section): Validate

Re: [PATCH 0/6] remove some usage of rtx_{insn,expr}_list

On 06/21/2016 04:47 PM, Trevor Saunders wrote: On Mon, Jun 20, 2016 at 06:52:35PM +0200, Bernd Schmidt wrote: So that's a second more in real time - was the machine very busy at the time you ran these tests so that these aren't meaningful, or is there a need to investigate this? Well, it

unrecognized non-alpha-numeric characters in asm() constraints

Hello, is there a reason why in output constraints such gets accepted silently (by parse_output_constraint()) while parse_input_constraint() issues an error if it encounters any? The latter behavior seems more forward compatible to me (such that if any such characters acquire meaning, one can

Re: Determine more IVs to be non-overflowing

> > Index: tree-scalar-evolution.c > > === > > --- tree-scalar-evolution.c (revision 237856) > > +++ tree-scalar-evolution.c (working copy) > > @@ -280,6 +280,7 @@ along with GCC; see the file COPYING3. > > #include "params.h" > >

Re: [PATCH PR c/71699] Handle pointer arithmetic in nonzero tree checks

Added a test: gcc/ChangeLog: PR c/71699 * fold-const.c (tree_binary_nonzero_warnv_p): Allow pointer addition to also be considered nonzero. gcc/testsuite/ChangeLog: PR c/71699 * c-c++-common/pointer-addition-nonnull.c: New test for pointer addition. --- gcc/fold-const.c

Re: [Patch] Disable text mode translation in ada for Cygwin

On 7/1/2016 20:00, Arnaud Charlet wrote: >> >> ping2? Is there a dedicated list for ADA patches? > > This list is for submitting patches, which you have done, it is not > really about pinging for commits, which should preferably be done by > the submitter, after proper testing. > > I do not

Re: [PATCH GCC]Resolve compilation time known alias checks in vectorizer

On Tue, Jun 28, 2016 at 8:18 AM, Bin.Cheng wrote: > On Tue, Jun 14, 2016 at 1:57 PM, Richard Biener > wrote: >> On Mon, Jun 13, 2016 at 12:01 PM, Bin Cheng wrote: >>> Hi, >>> GCC vectorizer generates many unnecessary runtime

Re: [PATCH][vectorizer][2/2] Hook up mult synthesis logic into vectorisation of mult-by-constant

On Thu, 30 Jun 2016, Kyrill Tkachov wrote: > > On 28/06/16 08:54, Richard Biener wrote: > > On Thu, 16 Jun 2016, Kyrill Tkachov wrote: > > > > > On 15/06/16 22:53, Marc Glisse wrote: > > > > On Wed, 15 Jun 2016, Kyrill Tkachov wrote: > > > > > > > > > This is a respin of > > > > >

Re: [Patch] Disable text mode translation in ada for Cygwin

> Text mode translation should not be done for Cygwin, especially since it > does not > support unicode setmode calls. This also fixes ada builds for Cygwin. > > OK for trunk? OK, thanks. >>> >>> Can someone please commit this? I don't have SVN write access. >>>

Re: [Patch] Disable text mode translation in ada for Cygwin

On 6/1/2016 18:27, JonY wrote: > On 5/27/2016 06:25, JonY wrote: >> On 5/26/2016 21:55, Arnaud Charlet wrote: Text mode translation should not be done for Cygwin, especially since it does not support unicode setmode calls. This also fixes ada builds for Cygwin. OK for

Re: Determine more IVs to be non-overflowing

On Thu, 30 Jun 2016, Jan Hubicka wrote: > Hi, > i sent the email before, but it seems it never left my machine. Sorry for > possible duplicates. This is updated version which does not overflow (by > capping nit), but still using widest_int for the calculatoins. It seems more > readable to do so

Re: [PATCH testsuite]XFAIL tests for -funsafe-loop-optimizations

On Tue, Jun 28, 2016 at 8:18 AM, Bin Cheng wrote: > Hi, > The previous patch removes support for -funsafe-loop-optimizations on GIMPLE, > as a follow up, this one marks related tests as XFAIL for the moment. I > would like to either remove/rewrite the case after

Re: [PATCH GCC]Improve loop-niter to handle possible infinite loop.

On Tue, Jun 28, 2016 at 8:18 AM, Bin Cheng wrote: > Hi, > At the moment, loop niter analyzer depends on simple_iv to understand control > induction variable in order to do further niter analysis. For cases reported > in PR57558 (comment #4), the control variable is not an

Re: [PATCH] Do not emit SAVE_EXPR for already assigned SSA_NAMEs (PR71606).

On Thu, Jun 23, 2016 at 1:14 PM, Eric Botcazou wrote: >> The gimplifier has been changed recently to use anonymous SSA_NAMEs instead >> of temporary decls. > > But the PR is a regression present since GCC 4.7... > >> And the gimplifier uses save_expr (which is a gimplifier

Re: [6/7] Explicitly classify vector loads and stores

On Wed, Jun 15, 2016 at 10:52 AM, Richard Sandiford wrote: > This is the main patch in the series. It adds a new enum and routines > for classifying a vector load or store implementation. > > Tested on aarch64-linux-gnu and x86_64-linux-gnu. OK to install? Why's the

Re: Problem in cxx_fundamental_alignment_p?

On 07/01/2016 10:34 AM, Dodji Seketeli wrote: The patch below was bootstrapped and tested on x86_64-linux, without issues, The patch looks good to me, thanks. Alright. I think we need a C frontend maintainer or maybe Jason to approve it. Attaching again. but I'm not convinced this code

Re: Improve insert/emplace robustness to self insertion

On 30/06/16 21:51 +0200, François Dumont wrote: On 29/06/2016 23:30, Jonathan Wakely wrote: iterator insert(const_iterator __position, value_type&& __x) { return emplace(__position, std::move(__x)); } That's suboptimal, since in the general case we need an extra construction for

Re: [PATCH] rtl-optimization/71709, strcpy arg optimised out

On 07/01/2016 09:19 AM, Alan Modra wrote: PR rtl-optimization/71709 * ira-lives.c (find_call_crossed_cheap_reg): Exit loop on arg reg being set, not referenced. Looks OK. Bernd

[PATCH][expr.c] PR middle-end/71700: zero-extend sub-word value when widening constructor element

Hi all, In this arm wrong-code PR the struct assignment goes wrong when expanding constructor elements to a register destination when the constructor elements are signed bitfields less than a word wide. In this testcase we're intialising a struct with a 16-bit signed bitfield to -1 followed by

Re: [PATCH][ARM] Delete thumb_reload_in_h

On 10/06/16 15:55, Kyrill Tkachov wrote: > Hi all, > > This function just ICEs and isn't actually called from anywhere. > It was introduced back in 2000 as part of a large merge introducing > Thumb support > and was aborting even then. I don't think having it around is of any > benefit. > >

Re: [PATCH] ix86: fix PR/65105 testcase 2

On Fri, Jul 1, 2016 at 10:19 AM, Jan Beulich wrote: > I cannot see how without allowing the compiler to use SSE2 instructions > (as is done by all other tests for this PR scanning for particular > instructions) this test could ever have succeeded anywhere. Well, most of 32bit

Re: Problem in cxx_fundamental_alignment_p?

Hello Bernd, Bernd Schmidt writes: > I came across what I think is a bug in cxx_fundamental_alignment_p. > > User alignments are specified in units of bytes. This is documented, > and we can also see the following in handle_aligned_attribute, for the > case when we have no

[PATCH] fix interaction of -S and -x {c,c++}-header

Irrespective of the use of -o this so far resulted in "error: output filename specified twice", since cc1_options already produces a -o option when -S was specified. gcc/ 2016-07-01 Jan Beulich * varasm.c (get_variable_section): Validate initializer in named

[PATCH v2] check initializer to be zero in .bss-like sections

Just like gas, which has recently learned to reject such initializers, gcc shouldn't accept such either. --- v2: Use dg-require-named-sections. gcc/ 2016-07-01 Jan Beulich * varasm.c (get_variable_section): Validate initializer in named .bss-like sections.

[PATCH] ix86: fix PR/65105 testcase 2

I cannot see how without allowing the compiler to use SSE2 instructions (as is done by all other tests for this PR scanning for particular instructions) this test could ever have succeeded anywhere. gcc/testsuite/ 2016-07-01 Jan Beulich *

Re: [PATCH PR c/71699] Handle pointer arithmetic in nonzero tree checks

On Thu, Jun 30, 2016 at 5:14 PM, Marc Glisse wrote: > On Thu, 30 Jun 2016, Richard Biener wrote: > >> points-to analysis already has the constraint that POINTER_PLUS_EXPR >> cannot leave the object op0 points to. Of course currently nothing uses the >> fact whether

Re: [PATCH PR70729] The second part of patch.

On Thu, Jun 30, 2016 at 4:51 PM, Yuri Rumyantsev wrote: > Richard, > > Could you please review additional simple fix for 70729 - we need to > nullify safelen field of loops containing simduid intrinsics like > GOMP_SIMD_LANE (introduced e.g. for private variables). I checked

Re: [PATCH][RFC] Fix PR71632, remove parts of TER

On Fri, 1 Jul 2016, Jakub Jelinek wrote: > On Thu, Jun 30, 2016 at 03:51:20PM +0200, Richard Biener wrote: > > The following patch fixes PR71632 by removing delayed expansion of > > TERed defs. Instead it adds code to apply the scheduling effect > > to the GIMPLE IL (so you also get better

Re: [PATCH][RFC] Fix PR71632, remove parts of TER

On Thu, 30 Jun 2016, Richard Biener wrote: > > The following patch fixes PR71632 by removing delayed expansion of > TERed defs. Instead it adds code to apply the scheduling effect > to the GIMPLE IL (so you also get better interleaved GIMPLE stmt > / generated RTL dumps in .expand). > > This

[ARM] Minor fix in arm_function_ok_for_sibcall

Several tests in the function were updated with a guard for a NULL decl but not the VxWorks-specific one, which results in a segfault building libgcc. Tested on ARM/VxWorks, applied on mainline, 6 and 5 branches as obvious. 2016-07-01 Eric Botcazou *

Re: [PATCH][RFC] Fix PR71632, remove parts of TER

On Thu, Jun 30, 2016 at 03:51:20PM +0200, Richard Biener wrote: > The following patch fixes PR71632 by removing delayed expansion of > TERed defs. Instead it adds code to apply the scheduling effect > to the GIMPLE IL (so you also get better interleaved GIMPLE stmt > / generated RTL dumps in

[PATCH] rtl-optimization/71709, strcpy arg optimised out

This patch fixes a thinko in find_call_crossed_cheap_reg. For functions that return an argument unchanged, like strcat, find_call_crossed_cheap_reg attempts to find an assignment between a pseudo reg and the arg reg before the call, so that uses of the pseudo after the call can instead use the

Re: [PATCH] Handle undefined extern vars in output_in_order

On Thu, 23 Jun 2016, Alexander Monakov wrote: > Hi, > > I've discovered that this assert in my patch was too restrictive: > > + if (DECL_HAS_VALUE_EXPR_P (pv->decl)) > + { > + gcc_checking_assert (lookup_attribute ("omp declare target link", > +