Re: [RFC][PR64946] "abs" vectorization fails for char/short types

On Fri, May 18, 2018 at 4:37 AM Kugan Vivekanandarajah < kugan.vivekanandara...@linaro.org> wrote: > Hi Richard, > Thanks for the review. I am revising the patch based on Andrew's comments too. > On 17 May 2018 at 20:36, Richard Biener wrote: > > On Thu, May 17,

[PING^2][RFC] Use gfc_decl_attributes in fortran frontend

On 01/13/2016 05:21 PM, Tom de Vries wrote: On 17/12/15 13:08, Tom de Vries wrote: Hi, Consider this patch, which reduces max_len of the oacc function attribute to 0: ... diff --git a/gcc/fortran/f95-lang.c b/gcc/fortran/f95-lang.c index 8556b70..60f4ad3 100644 --- a/gcc/fortran/f95-lang.c +++

Re: [patch] Improve support for up-level references (1/n)

On Fri, May 18, 2018 at 9:43 AM Eric Botcazou wrote: > Hi, > the compiler has had built-in support for nested functions for a long time, > which makes it possible to support them in GNU C (as an extension) and in Ada; > Fortran uses them too but marginally. The support

Re: [PATCH GCC][2/6]Compute available register for each register classes

On Fri, May 4, 2018 at 5:21 PM, Bin Cheng wrote: > Hi, > This is the second patch computing available/clobber registers for register > classes. > It's the same as the original patch posted > @https://gcc.gnu.org/ml/gcc-patches/2017-05/msg01022.html > > Bootstrap and test on

[patch] Improve support for up-level references (1/n)

Hi, the compiler has had built-in support for nested functions for a long time, which makes it possible to support them in GNU C (as an extension) and in Ada; Fortran uses them too but marginally. The support was entirely rewritten for GCC 4 and a few rough edges have remained since then,

Re: PR85817

On Fri, 18 May 2018, Prathamesh Kulkarni wrote: > Hi, > In r260250, the condition > > if (integer_zerop (retval)) > continue; > > was added before checking retval was of pointer type which caused > functions having return type apart from void *, to be marked as > malloc. The attached patch

Re: [PATCH] libstdc++/85184 remove __glibcxx_assert assertions from

On 15/05/2018 18:56, Jonathan Wakely wrote: As I said in the bugzilla PR, these assertions are all to catch our own mistakes, not user error. If we're comfortable the code is correct then we should remove them. Should we wait until near the end of stage 1, to get more time with these checks in

Re: Documentation patch for -floop-interchange and -floop-unroll-and-jam.

On Thu, May 17, 2018 at 8:36 PM Toon Moene wrote: > The documentation of both options is still inconsistent, in both the > trunk and the gcc-8 branch. > The following is my suggestion to clear this up (and move > -floop-unroll-and-jam close to -floop-interchange. > ChangeLog:

Fix tree-ssa-strlen handling of partial clobber (PR85814)

In this PR we have: c_5 = c_4(D) + 4; c_12 = c_5 + 1; *c_5 = 2; a = 2;// A c_21 = c_12 + 1; *c_12 = 2; a = 2;// B c_28 = c_21 + 1; *c_21 = 2; a = 2; c_7 = c_28 + 1; *c_28 = 2; where a is a global int. We decide that A can't clobber *c_5 ==

Re: [C++ Patch] PR 84588 ("[8 Regression] internal compiler error: Segmentation fault (contains_struct_check())")​ (Take 2)

Hi, On 18/05/2018 01:21, Jason Merrill wrote: On Thu, May 17, 2018 at 5:54 PM, Paolo Carlini wrote: On 17/05/2018 16:58, Jason Merrill wrote: On Thu, May 17, 2018 at 10:27 AM, Paolo Carlini wrote: PS: maybe better using

Re: [PATCH GCC][1/6]Compute type mode and register class mapping

On Fri, May 4, 2018 at 5:21 PM, Bin Cheng wrote: > Hi, > This is the updated version patch set computing register pressure on TREE SSA > and use that information to direct other loop optimizers (predcom only for > now). > This version of change is to follow Jeff's comment that

Re: GCC 6 backports

On 04/25/2018 03:16 PM, Jan Hubicka wrote: >> Hi. >> >> Sending GCC 6 branch backports. >> Patches can bootstrap on ppc64le-redhat-linux and survives regression tests. >> I'm going to install the patches. >> >> Martin > >> >From e0d32b1f9e0dd0486e63040e1ab8f5d8e9f0fbd5 Mon Sep 17 00:00:00 2001 >>

PR85817

Hi, In r260250, the condition if (integer_zerop (retval)) continue; was added before checking retval was of pointer type which caused functions having return type apart from void *, to be marked as malloc. The attached patch gets rid of the above check since we do not wish to mark function

Re: [PATCH GCC][4/6]Support regional coalesce and live range computation

On Thu, May 17, 2018 at 5:49 PM Bin.Cheng wrote: > On Thu, May 17, 2018 at 3:04 PM, Richard Biener > wrote: > > On Tue, May 15, 2018 at 5:44 PM Bin.Cheng wrote: > > > >> On Fri, May 11, 2018 at 1:53 PM, Richard Biener >

Re: [PATCH][arm][1/2] Remove support for deprecated -march=armv5 and armv5e

On 17/05/18 11:26, Kyrill Tkachov wrote: > Hi all, > > The -march=armv5 and armv5e options have been deprecated in GCC 7 [1]. > This patch removes support for them. > It's mostly mechanical stuff. The functionality that was previously > gated on arm_arch5 is now gated on arm_arch5t and the

[PATCH] Add VRP stmt folding to EVRP

While working on somehow re-ordering the first VRP pass after loop-header copying I noticed that EVRP doesn't do VRP stmt simplifications. The following adds this alongside the usual testsuite adjustments. Bootstrapped and tested on x86_64-unknown-linux-gnu, applied. Richard. 2018-05-18

Re: [PATCH][arm][2/2] Remove support for -march=armv3 and older

On 17/05/18 11:26, Kyrill Tkachov wrote: > Hi all, > > We deprecated architecture versions earlier than Armv4T in GCC 6 [1]. > This patch removes support for architectures lower than Armv4. > That is the -march values armv2, armv2a, armv3, armv3m are removed > with this patch.  I did not remove

[PATCH][RFC] Add dynamic edge/bb flag allocation

The following adds a simple alloc/free_flag machinery allocating bits from an int typed pool and applies that to bb->flags and edge->flags. This should allow infrastructure pieces to use egde/bb flags temporarily without worrying that users might already use it as for example BB_VISITED and

[PATCH] Support variables in expansion of -fprofile-generate option (PR gcov-profile/47618).

Hi. Following patch enables to generate more parallel profiles for applications that do intensive # of invocations. There's some discussion in the PR. So one example: $ gcc -fprofile-generate=/tmp/slavia/%p/%q{CPU}/ empty.c -O2 && ./a.out $ l /tmp/slavia/22234/x86_64/empty.gcda -rw-r--r-- 1

Aliasing 'this' in a C++ constructor

Hello, this lets alias analysis handle the implicit 'this' parameter in C++ constructors as if it was restrict. Bootstrap+regtest on powerpc64le-unknown-linux-gnu. 2018-05-18 Marc Glisse PR c++/82899 gcc/ * tree-ssa-structalias.c

Re: [PATCH] Improve get_ref_base_and_extent with range-info

On Thu, 17 May 2018, Richard Biener wrote: > > The following makes use of range-info to improve the basic building > block of the alias-oracle so we can tell that in > > a[0] = 1; > for (int i = 5; i < 17; ++i) > a[i] = i; > a[0] = 2; > > the ao_ref for a[i] does not alias the a[0]

[PATCH v2] C/C++: Add -Waddress-of-packed-member

On Thu, May 17, 2018 at 10:32:56AM -0700, H.J. Lu wrote: > On Mon, May 14, 2018 at 8:00 PM, Martin Sebor wrote: > > On 05/14/2018 01:10 PM, H.J. Lu wrote: > >> > >> On Mon, May 14, 2018 at 10:40 AM, H.J. Lu wrote: > >> > >> $ cat c.i > >> struct B {

Re: [PATCH GCC][5/6]implement live range, reg pressure computation class

On Fri, May 4, 2018 at 5:23 PM, Bin Cheng wrote: > Hi, > Based on previous patch, this one implements live range, reg pressure > computation > class in tree-ssa-live.c. The user would only need to instantiate the class > and > call the computation interface as in next patch.

[COMMITTED, AARCH64, SVE TESTSUITE] Remove a couple of xfail from slp_5.c

Hi Since Richard Biener's commit from 16th May: commit 2f05c3c7324cd293b7b2ba197e0a88d9749361cc Author: rguenth Date:   Wed May 16 13:08:04 2018 + the test case slp_5.c had started showing a couple of XPASS failures. XPASS:

Re: Aliasing 'this' in a C++ constructor

On Fri, May 18, 2018 at 09:02:08AM -0400, Nathan Sidwell wrote: > On 05/18/2018 08:53 AM, Marc Glisse wrote: > > > As long as you do not dereference ptr in the constructor, that shouldn't > > contradict 'restrict'. The PR gives this quote from the standard: > > > > "During the construction of an

Re: Aliasing 'this' in a C++ constructor

On 05/18/2018 09:21 AM, Marc Glisse wrote: what about comparisons to this?  I thought restrict implied such a comparison was 'never the same'? ie. if the ctor was:  selfie (selfie *ptr) : me (ptr==this ? 0 : ptr) {} It is tempting to think so, but I don't see any language to that effect.

Re: Aliasing 'this' in a C++ constructor

On Fri, May 18, 2018 at 09:57:42AM -0400, Jason Merrill wrote: > > But what is invalid on: > > struct S { int foo (S *); int a; } s { 2 }; > > int S::foo (S *x) > > { > > int b = this->a; > > x->a = 5; > > b += this->a; > > return b; > > } > > int main () > > { > > if (s.foo () != 7) > >

Re: PR85817

On 05/18/2018 02:49 AM, Prathamesh Kulkarni wrote: > Hi, > In r260250, the condition > > if (integer_zerop (retval)) > continue; > > was added before checking retval was of pointer type which caused > functions having return type apart from void *, to be marked as > malloc. The attached patch

Re: RFC (libstdc++): C++ PATCH for c++/58407, C++11 deprecation of implicit copy

On Fri, May 18, 2018 at 10:51 AM, Jonathan Wakely wrote: > On 18/05/18 10:29 -0400, Jason Merrill wrote: >> >> The second patch is some libstdc++ changes to avoid warnings from uses >> of the standard library when this warning is on. More are almost >> certainly needed.

[PATCH] PR libstdc++/85098 add missing definitions for static constants

In C++11 and C++14 any odr-use of these constants requires a definition at namespace-scope. In C++17 they are implicitly inline and so the namespace-scope redeclarations are redundant (and allowing them is deprecated). PR libstdc++/85098 * include/bits/regex.h [__cplusplus <

Re: [PATCH] PR libstdc++/85098 add missing definitions for static constants

On 18 May 2018 at 19:13, Jonathan Wakely wrote: > In C++11 and C++14 any odr-use of these constants requires a definition > at namespace-scope. In C++17 they are implicitly inline and so the > namespace-scope redeclarations are redundant (and allowing them is > deprecated). >

Re: RFC (libstdc++): C++ PATCH for c++/58407, C++11 deprecation of implicit copy

On 18/05/18 11:58 -0400, Jason Merrill wrote: On Fri, May 18, 2018 at 11:55 AM, Jason Merrill wrote: On Fri, May 18, 2018 at 10:51 AM, Jonathan Wakely wrote: On 18/05/18 10:29 -0400, Jason Merrill wrote: The second patch is some libstdc++ changes to

Re: Fix PR85782: C++ ICE with continue statements inside acc loops

Ping. For reference, I've attached the patch for gcc7. Cesar On 05/15/2018 07:11 AM, Cesar Philippidis wrote: > This patch resolves the issue in PR85782, which involves a C++ ICE > caused by OpenACC loops which contain continue statements. The problem > is that genericize_continue_stmt expects

Re: Fix PR85782: C++ ICE with continue statements inside acc loops

On Fri, May 18, 2018 at 08:30:44AM -0700, Cesar Philippidis wrote: > Ping. Ok. > For reference, I've attached the patch for gcc7. Jakub

Re: RFC (libstdc++): C++ PATCH for c++/58407, C++11 deprecation of implicit copy

On Fri, May 18, 2018 at 11:55 AM, Jason Merrill wrote: > On Fri, May 18, 2018 at 10:51 AM, Jonathan Wakely wrote: >> On 18/05/18 10:29 -0400, Jason Merrill wrote: >>> >>> The second patch is some libstdc++ changes to avoid warnings from uses >>> of the

Re: [PATCH] gcov: add new option -t that prints output to stdout (PR gcov-profile/84846).

On 05/18/2018 08:29 AM, Martin Liška wrote: Hi. It's requested by LCOV folks, they want to be able to print to stdout instead of into a file. Survives make check -k -j10 RUNTESTFLAGS="gcov.exp" I guess you looked at abstracting the output file a bit earlier, and passing in a FILE* to the

Re: [PATCH][RFC] Radically simplify emission of balanced tree for switch statements.

Hi Martin, > So the patch looks fine, only very very slightly binary is produced. I'm > going to install the patch so that > I can carry on more complex patches based on this one. it seems you didn't properly test the testsuite part: I see +UNRESOLVED: gcc.dg/tree-prof/update-loopch.c

Re: RFC (libstdc++): C++ PATCH for c++/58407, C++11 deprecation of implicit copy

On 18/05/18 10:29 -0400, Jason Merrill wrote: The second patch is some libstdc++ changes to avoid warnings from uses of the standard library when this warning is on. More are almost certainly needed. Jonathan, how would you like me to handle this WRT the library? Check in both patches and let

Re: [PATCH] gcov: add new option -t that prints output to stdout (PR gcov-profile/84846).

I forgot to document the option. Fixed that. Martin >From 81236af4d1fac4c278b29e65162b3f73593a7d08 Mon Sep 17 00:00:00 2001 From: marxin Date: Fri, 18 May 2018 14:22:06 +0200 Subject: [PATCH] gcov: add new option -t that prints output to stdout (PR gcov-profile/84846).

Re: Aliasing 'this' in a C++ constructor

On Fri, 18 May 2018, Nathan Sidwell wrote: On 05/18/2018 08:34 AM, Marc Glisse wrote: (Cc: said C++ folks) On Fri, 18 May 2018, Richard Biener wrote: On Fri, May 18, 2018 at 2:25 PM Marc Glisse wrote: Hello, this lets alias analysis handle the implicit 'this'

Re: [PATCH] gcov: add new option -t that prints output to stdout (PR gcov-profile/84846).

On 05/18/2018 02:46 PM, Nathan Sidwell wrote: > On 05/18/2018 08:29 AM, Martin Liška wrote: >> Hi. >> >> It's requested by LCOV folks, they want to be able to print to stdout >> instead of into a file. >> >> Survives make check -k -j10 RUNTESTFLAGS="gcov.exp" > > I guess you looked at abstracting

Re: [PATCH][RFC] Add dynamic edge/bb flag allocation

On Fri, 2018-05-18 at 13:11 +0200, Richard Biener wrote: > The following adds a simple alloc/free_flag machinery allocating > bits from an int typed pool and applies that to bb->flags and edge- > >flags. > This should allow infrastructure pieces to use egde/bb flags > temporarily > without

Re: PR85817

On 05/18/2018 02:49 AM, Prathamesh Kulkarni wrote: > Hi, > In r260250, the condition > > if (integer_zerop (retval)) > continue; > > was added before checking retval was of pointer type which caused > functions having return type apart from void *, to be marked as > malloc. The attached patch

Re: Aliasing 'this' in a C++ constructor

On Fri, 18 May 2018, Jakub Jelinek wrote: On Fri, May 18, 2018 at 09:02:08AM -0400, Nathan Sidwell wrote: On 05/18/2018 08:53 AM, Marc Glisse wrote: As long as you do not dereference ptr in the constructor, that shouldn't contradict 'restrict'. The PR gives this quote from the standard:

Re: [C++ Patch] PR 84588 ("[8 Regression] internal compiler error: Segmentation fault (contains_struct_check())")​ (Take 2)

Hi, On 18/05/2018 15:56, Jason Merrill wrote: I had in mind moving the call to cp_parser_check_condition_declarator into the block controlled by cp_parser_parse_definitely; this is a semantic check that should follow the syntactic checks. If there's no initializer, it doesn't parse as a

Re: [PATCH][AARCH64][PR target/84882] Add mno-strict-align

On 27/03/18 13:58, Sudakshina Das wrote: > Hi > > This patch adds the no variant to -mstrict-align and the corresponding > function attribute. To enable the function attribute, I have modified > aarch64_can_inline_p () to allow checks even when the callee function > has no attribute. The need for

[PATCH] gcov: add new option -t that prints output to stdout (PR gcov-profile/84846).

Hi. It's requested by LCOV folks, they want to be able to print to stdout instead of into a file. Survives make check -k -j10 RUNTESTFLAGS="gcov.exp" Ready for trunk? Thanks, Martin gcc/ChangeLog: 2018-05-18 Martin Liska PR gcov-profile/84846 * gcov.c

Re: Aliasing 'this' in a C++ constructor

On Fri, May 18, 2018 at 2:25 PM Marc Glisse wrote: > Hello, > this lets alias analysis handle the implicit 'this' parameter in C++ > constructors as if it was restrict. > Bootstrap+regtest on powerpc64le-unknown-linux-gnu. OK. Please give C++ folks the chance to chime

Re: [PATCH] Print working directory to gcov files (PR gcov-profile/84846).

V2: pwd is renamed to cwd, which is a better name. Martin >From a42365bc6987fc13d3a3cd4b98d7d64d94f7f318 Mon Sep 17 00:00:00 2001 From: marxin Date: Fri, 18 May 2018 13:58:58 +0200 Subject: [PATCH] Print working directory to gcov files (PR gcov-profile/84846). gcc/ChangeLog:

Re: Aliasing 'this' in a C++ constructor

On 05/18/2018 08:34 AM, Marc Glisse wrote: (Cc: said C++ folks) On Fri, 18 May 2018, Richard Biener wrote: On Fri, May 18, 2018 at 2:25 PM Marc Glisse wrote: Hello, this lets alias analysis handle the implicit 'this' parameter in C++ constructors as if it was

Re: [PATCH] Print working directory to gcov files (PR gcov-profile/84846).

On 05/18/2018 08:42 AM, Martin Liška wrote: V2: pwd is renamed to cwd, which is a better name. Martin ok thanks. nathan -- Nathan Sidwell

Re: [PATCH] Support lower and upper limit for -fdbg-cnt flag.

Hi Martin, > On 05/16/2018 03:39 PM, Alexander Monakov wrote: >> On Wed, 16 May 2018, Martin Liška wrote: Hm, is the off-by-one in the new explanatory text really intended? I think the previous text was accurate, and the new text should say "9th and 10th" and then "first 10

Re: Aliasing 'this' in a C++ constructor

On 05/18/2018 08:53 AM, Marc Glisse wrote: As long as you do not dereference ptr in the constructor, that shouldn't contradict 'restrict'. The PR gives this quote from the standard: "During the construction of an object, if the value of the object or any of its subobjects is accessed through

Re: Aliasing 'this' in a C++ constructor

On Fri, May 18, 2018 at 8:34 AM, Marc Glisse wrote: > On Fri, 18 May 2018, Richard Biener wrote: >> On Fri, May 18, 2018 at 2:25 PM Marc Glisse wrote: >> >>> this lets alias analysis handle the implicit 'this' parameter in C++ >>> constructors as if it

Re: [C++ Patch] PR 84588 ("[8 Regression] internal compiler error: Segmentation fault (contains_struct_check())")​ (Take 2)

On Fri, May 18, 2018 at 10:30 AM, Paolo Carlini wrote: > Hi, > > On 18/05/2018 16:19, Jason Merrill wrote: >> >> On Fri, May 18, 2018 at 10:05 AM, Paolo Carlini >> wrote: >>> >>> Hi, >>> >>> On 18/05/2018 15:56, Jason Merrill wrote: I

Re: [PATCH][GCC][AArch64] Correct 3 way XOR instructions adding missing patterns.

On 30/04/18 15:12, Tamar Christina wrote: > Hi All, > > This patch adds the missing neon intrinsics for all 128 bit vector Integer > modes for the > three-way XOR and negate and xor instructions for Arm8.2-a to Armv8.4-a. > > Bootstrapped and regtested on aarch64-none-linux-gnue and no issues.

Re: [C++ Patch] PR 84588 ("[8 Regression] internal compiler error: Segmentation fault (contains_struct_check())")​ (Take 2)

Hi, On 18/05/2018 16:45, Jason Merrill wrote: I guess it's desirable to also give this error when the declarator is followed by ) or ; rather than other tokens that could be more expression (like in A(a).x in the comment). I can certainly try to implement this, maybe just something minimal to

Re: [PATCH][RFC] Radically simplify emission of balanced tree for switch statements.

On 05/18/2018 03:55 PM, Rainer Orth wrote: > Hi Martin, > >> So the patch looks fine, only very very slightly binary is produced. I'm >> going to install the patch so that >> I can carry on more complex patches based on this one. > > it seems you didn't properly test the testsuite part: I see >

Re: [C++ Patch] PR 84588 ("[8 Regression] internal compiler error: Segmentation fault (contains_struct_check())")​ (Take 2)

On Fri, May 18, 2018 at 10:05 AM, Paolo Carlini wrote: > Hi, > > On 18/05/2018 15:56, Jason Merrill wrote: >> >> I had in mind moving the call to cp_parser_check_condition_declarator >> into the block controlled by cp_parser_parse_definitely; this is a >> semantic check

RFC (libstdc++): C++ PATCH for c++/58407, C++11 deprecation of implicit copy

C++11 specified that the implicitly-declared copy constructor and assignment operator are deprecated if one of them, or the destructor, is user-provided. This patch implements that; I've recently been fixing some uses in the compiler of those deprecated copies. Rather than bundle this into

Re: [C++ Patch] PR 84588 ("[8 Regression] internal compiler error: Segmentation fault (contains_struct_check())")​ (Take 2)

Hi, On 18/05/2018 16:19, Jason Merrill wrote: On Fri, May 18, 2018 at 10:05 AM, Paolo Carlini wrote: Hi, On 18/05/2018 15:56, Jason Merrill wrote: I had in mind moving the call to cp_parser_check_condition_declarator into the block controlled by

Re: Aliasing 'this' in a C++ constructor

(Cc: said C++ folks) On Fri, 18 May 2018, Richard Biener wrote: On Fri, May 18, 2018 at 2:25 PM Marc Glisse wrote: Hello, this lets alias analysis handle the implicit 'this' parameter in C++ constructors as if it was restrict. Bootstrap+regtest on

[PATCH] Print working directory to gcov files (PR gcov-profile/84846).

Hi. Simple format extension which prints working directory of TU when it was compiled. It's requested by LCOV folks. Survives make check -k -j10 RUNTESTFLAGS="gcov.exp" Ready for trunk? Thanks, Martin gcc/ChangeLog: 2018-05-18 Martin Liska PR gcov-profile/84846

Re: Aliasing 'this' in a C++ constructor

On Fri, 18 May 2018, Nathan Sidwell wrote: On 05/18/2018 08:53 AM, Marc Glisse wrote: As long as you do not dereference ptr in the constructor, that shouldn't contradict 'restrict'. The PR gives this quote from the standard: "During the construction of an object, if the value of the object

Re: [C++ Patch] PR 84588 ("[8 Regression] internal compiler error: Segmentation fault (contains_struct_check())")​ (Take 2)

On Fri, May 18, 2018 at 4:41 AM, Paolo Carlini wrote: > Hi, > >>> On 18/05/2018 01:21, Jason Merrill wrote: On Thu, May 17, 2018 at 5:54 PM, Paolo Carlini wrote: > > On 17/05/2018 16:58, Jason Merrill wrote: >> >>

Re: Aliasing 'this' in a C++ constructor

On Fri, May 18, 2018 at 9:53 AM, Jakub Jelinek wrote: > On Fri, May 18, 2018 at 09:02:08AM -0400, Nathan Sidwell wrote: >> On 05/18/2018 08:53 AM, Marc Glisse wrote: >> >> > As long as you do not dereference ptr in the constructor, that shouldn't >> > contradict 'restrict'. The

Re: Aliasing 'this' in a C++ constructor

On 05/18/2018 10:12 AM, Jakub Jelinek wrote: Or is it invalid to dereference s before it has been constructed? Yes, Marc found: "During the construction of an object, if the value of the object or any of its subobjects is accessed through a glvalue that is not obtained, directly or

[PATCH 1/2][Aarch64] Improve FP to int conversions

This patch improves additional cases of FP to integer conversions. Example 1: unsigned long f7 (double x) { return (unsigned) y; } At -O2 Trunk generates: f7: fcvtzu w0, d0 uxtwx0, w0 ret With the patch we can merge the zero-extend and reduce the sequence to

[PATCH 2/2][Aarch64] Improve FP to int conversions

This patch improves additional cases of FP to integer conversions with -ffast-math enabled. Example 1: double f5 (int x) { return (double)(float) x; } At -O2 with -ffast-math Trunk generates: f5: scvtf s0, w0 fcvtd0, s0 ret With the patch we can merge the

Re: [PATCH] Warn for ignored ASM labels on typdef declarations PR 85444 (v.3)

Hello again! Thanks to the feedback of Mr. Myers and those on the PR, I have created a version 3 of this patch. This version introduces a new warning flag (enabled at Wall) -Wignored-asm-name that will flag cases where the user specifies an ASM name that the compiler ignores. Test cases

Re: [PATCH] Support lower and upper limit for -fdbg-cnt flag.

On 05/18/2018 04:07 PM, Rainer Orth wrote: Please fix. Thanks for the report, will install obvious fix. Martin >From af8fbed777a1583fc2ac865e0e15cbb24fee6a81 Mon Sep 17 00:00:00 2001 From: marxin Date: Fri, 18 May 2018 16:27:22 +0200 Subject: [PATCH] Fix typo in test-case.

[PATCH] avoid assuming that a DECL necessarily has a constant size (PR 85826)

Under some apparently rare conditions a DECL can have a non- constant size that the fix for bug 85753 committed last week into trunk was not prepared for. The attached change removes the assumption to avoid the ICE that otherwise results. Martin PS The test case that triggers the ICE makes use

Re: [C++ Patch] PR 84588 ("[8 Regression] internal compiler error: Segmentation fault (contains_struct_check())")​ (Take 2)

Hi again, I'm playing with a wild, wild idea: would it make sense to try *first* an expression? Because, a quickly hacked draft appears to handle very elegantly all the possible cases of "junk" after the declarator, eg:     void foo()     {         if (void bar()JUNK); } and the

[PATCH] RISC-V: Add RV32E support.

This adds support for -march=rv32e and -mabi=ilp32e. This is mostly the work of Kito Cheng and Monk Chiang. I forward ported the patch to current sources, which needed a few fixes. I fixed the mask clearing/setting so that using multiple -march/-mabi options works right. I added some docs for

Re: [C++ Patch] PR 84588 ("[8 Regression] internal compiler error: Segmentation fault (contains_struct_check())")​ (Take 2)

Hi, On 19/05/2018 01:40, Jason Merrill wrote: On Fri, May 18, 2018 at 1:40 PM, Paolo Carlini wrote: Hi again, I'm playing with a wild, wild idea: would it make sense to try *first* an expression? Because, a quickly hacked draft appears to handle very elegantly all

Re: [PATCH][AArch64] Implement usadv16qi and ssadv16qi standard names

On Mon, May 14, 2018 at 08:38:40AM -0500, Kyrill Tkachov wrote: > Hi all, > > This patch implements the usadv16qi and ssadv16qi standard names. > See the thread at on g...@gcc.gnu.org [1] for background. > > The V16QImode variant is important to get right as it is the most commonly > used

Re: Rb_tree constructor optimization

On 17/05/18 16:10 +0100, Jonathan Wakely wrote: On 15/05/18 07:30 +0200, François Dumont wrote: Here it is again even more simplified. Should I backport the Debug mode fix to 8 branch ? Yes, please do backport the include/debug/* changes.     * include/bits/stl_tree.h    

[PATCH] Fix std::codecvt_utf8 for Mingw

While testing a series of patches to add Mingw support for std::filesystem I discovered that codecvt_utf8 was producing wchar_t values with the wrong endianness. This fixes it. * src/c++11/codecvt.cc (__codecvt_utf8_base::do_in) [__SIZEOF_WCHAR_T__==2 &&

Re: [Aarch64] PR target/83009: Relax strict address checking for store pair lanes

> On 8 May 2018, at 02:58, Andre Vieira (lists) > wrote: > > Hi Richard, >> On 07/05/18 11:14, Richard Sandiford wrote: >> "Andre Vieira (lists)" writes: >>> Hi, >>> >>> See below a patch to address PR 83009. >>> >>> Tested

Re: [patch] Improve support for up-level references (1/n)

> + /* If the next declaration is a PARM_DECL pointing to theDECL, > +we need to adjust its VALUE_EXPR directly, since chains of > +VALUE_EXPRs run afoul of garbage collection. This occurs > +in Ada for Out parameters that aren't copied

[PATCH] Make __ibm128 a distinct type, patch 1 of 2 (PR 85657)

This patch is the first of two patches to make the __ibm128 type a distict type. Previously, when I impemented __ibm128, I had defined it to be long double on systems where long double used the IBM extended double format. Segher asked that I always create the type as a distinct type. For C++, I

Re: [PATCH] Make __ibm128 a distinct type, patch 2 of 2 (PR 85657)

Here is patch 2 of 2 to make __ibm128 a distinct type. This patch makes the long double pack and unpack builtins only work if the long double type is IBM extended double. It adds two new builtins to pack and unpack __ibm128 types. This has been tested on a little endian power8 system with

Re: [C++ Patch] PR 84588 ("[8 Regression] internal compiler error: Segmentation fault (contains_struct_check())")​ (Take 2)

On Fri, May 18, 2018 at 1:40 PM, Paolo Carlini wrote: > Hi again, > > I'm playing with a wild, wild idea: would it make sense to try *first* an > expression? Because, a quickly hacked draft appears to handle very elegantly > all the possible cases of "junk" after the

[PATCH] correct/improve handling of -Walloc-size-larger-than (PR 82063)

The -Walloc-size-larger-than= option is supposed make it possible to disable the warning by specifying a limit that's larger than the default of PTRDIFF_MAX (the handler for the option argument gets around the INT_MAX maximum for numeric arguments by accepting suffixes like MB or GB).

Re: [PATCH , rs6000] Add missing builtin test cases, fix arguments to match specifications.

On Thu, May 17, 2018 at 02:40:11PM -0700, Carl Love wrote: > On Thu, 2018-05-17 at 15:31 -0500, Segher Boessenkool wrote: > > On Wed, May 16, 2018 at 12:53:13PM -0700, Carl Love wrote: > > > diff --git a/gcc/testsuite/gcc.target/powerpc/altivec-12.c > > >