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

2016-09-22 Thread Rainer Orth
Hi Martin, > your patch broke bootstrap with MPFR 2.4.2, which is still the > recommended (or perhaps minimal) version according to install.texi: [...] > The following patch (together with your other one to fix ILP32 targets) > allows a sparc-sun-solaris2.12 bootstrap to continue. I'm going to >

[PATCH] Fix PR77697

2016-09-22 Thread Richard Biener
This fixes PR77697, an ice-on-invalid for Fortran (varasm later errors). Bootstrapped and tested on x86_64-unknown-linux-gnu, applied to trunk. Richard. 2016-09-22 Richard Biener PR middle-end/77697 * gimple-fold.c (fold_array_ctor_reference): Turn

[PATCH] Fix PR77677

2016-09-22 Thread Richard Biener
This avoids some more TREE_OVERFLOWs in the IL (which now confuses IPA VRP). Bootstrapped and tested on x86_64-unknown-linux-gnu, applied to trunk. Richard. 2016-09-22 Richard Biener PR middle-end/77677 * gimple-match-head.c (gimple_resimplify1): Drop

[PATCH] Fix PR77678

2016-09-22 Thread Richard Biener
This fixes an ice-on-invalid for fortran. Bootstrapped/tested on x86_64-unknown-linux-gnu, applied to trunk. Richard. 2016-09-22 Richard Biener PR middle-end/77678 * expr.c (expand_expr_real_1): Guard array access against negative offset. Index:

[PATCH] Disable sim build for ARC in top-level configure.ac

2016-09-22 Thread Anton Kolesov
Hi, This disables "sim" build for ARC, otherwise it is required to pass --disable-sim to top-level configure. Anton 0001-Disable-sim-builds-for-ARC-in-top-level-configure.ac.patch Description: 0001-Disable-sim-builds-for-ARC-in-top-level-configure.ac.patch

Re: [RFC] Extend ipa-bitwise-cp with pointer alignment propagation

2016-09-22 Thread Jan Hubicka
> Hi, > The attached patch tries to extend ipa bits propagation to handle > pointer alignment propagation. > The patch just disables ipa-cp-alignment pass, I suppose we want to > eventually remove it ? Yes, can you please verify that alignments it computes are monotonously worse than those your

Re: Make regcprop to eliminate noop moves better

2016-09-22 Thread Jan Hubicka
> > while working on the GCN port I ended up with many redundant register copies > > of the form > > mov reg, exec > > do something > > mov reg, exec > > do something > > ... > > these copies are generated by LRA because exec is small register class and > > needs a lot of reloading (it could

Re: [PATCH] Fix PR ipa/77653

2016-09-22 Thread Richard Biener
On Thu, Sep 22, 2016 at 1:18 PM, Martin Liška wrote: > Hi. > > After some investigation, it shows that IPA ICF merges a pair of variables > where > for just one them address matters. Which is obvious error, fixed in attached > patch. > > Patch can bootstrap on

Correct module change introduced by DTIO patch.

2016-09-22 Thread Paul Richard Thomas
Dear All, This patch has just been committed to trunk as r240349, following an OK from Andre on #gfortran. This was urgently needed since the original DTIO patch, committed on 2016-31-08, added two extra pairs of parentheses, which are always empty, to the intrinsic operator list in module

[PATCH] Fix PR ipa/77653

2016-09-22 Thread Martin Liška
Hi. After some investigation, it shows that IPA ICF merges a pair of variables where for just one them address matters. Which is obvious error, fixed in attached patch. Patch can bootstrap on ppc64le-redhat-linux and survives regression tests. Ready to be installed? Martin >From

Re: [v3 PATCH] PR libstdc++/77288 and the newest proposed resolution for LWG 2756

2016-09-22 Thread Jonathan Wakely
On 22/09/16 11:16 +0100, Jonathan Wakely wrote: (Somebody should fix PR58938 so exception_ptr is portable). Christophe, would you be able to test this patch? It uses a single global mutex for exception_ptr objects, which doesn't scale well but that probably isn't a problem for processors

Re: [Patch] Fix variant::operator= on references

2016-09-22 Thread Jonathan Wakely
On 22/09/16 03:40 -0700, Tim Shen wrote: On Thu, Sep 22, 2016 at 3:36 AM, Tim Shen wrote: Then my question is, what about type traits uses like is_copy_constructible? I have seen non-qualified uses in std::any and std::optional and other places. Should all of them be

Re: [PATCH] [RTEMS] Always use atomic builtins for libstdc++

2016-09-22 Thread Jonathan Wakely
On 22/09/16 11:28 +0100, Jonathan Wakely wrote: On 22/09/16 10:49 +0200, Sebastian Huber wrote: On 22/09/16 10:47, Jonathan Wakely wrote: On 22/09/16 09:41 +0200, Sebastian Huber wrote: libstdc++-v3/ * config/cpu/m68k/atomicity.h: Adjust comment. * acinclude.m4

Re: [Patch] Fix variant::operator= on references

2016-09-22 Thread Tim Shen
On Thu, Sep 22, 2016 at 3:36 AM, Tim Shen wrote: > Then my question is, what about type traits uses like > is_copy_constructible? I have seen non-qualified uses in std::any and > std::optional and other places. Should all of them be qualified? Ah never mind, I realized that

[PATCH] Fix LTO with Java some more

2016-09-22 Thread Richard Biener
Ok, I know... (I'll eventually backport this and the earlier change) Thus, committed as obvious. Richard. 2016-09-22 Richard Biener java/ * class.c (push_super_field): Set DECL_CONTEXT. Index: gcc/java/class.c

Re: [Patch] Fix variant::operator= on references

2016-09-22 Thread Tim Shen
On Thu, Sep 22, 2016 at 3:03 AM, Jonathan Wakely wrote: > On 22/09/16 01:49 -0700, Tim Shen wrote: >> >> Done. When writing the initial version, I was trying to save as much >> qualifications as possible (as long as the semantic doesn't change) >> for readability, but that

Re: [PATCH] [RTEMS] Always use atomic builtins for libstdc++

2016-09-22 Thread Jonathan Wakely
On 22/09/16 10:49 +0200, Sebastian Huber wrote: On 22/09/16 10:47, Jonathan Wakely wrote: On 22/09/16 09:41 +0200, Sebastian Huber wrote: libstdc++-v3/ * config/cpu/m68k/atomicity.h: Adjust comment. * acinclude.m4 (GLIBCXX_ENABLE_ATOMIC_BUILTINS): Honor explicit atomicity_dir setup

Re: [v3 PATCH] PR libstdc++/77288 and the newest proposed resolution for LWG 2756

2016-09-22 Thread Jonathan Wakely
On 22/09/16 12:41 +0300, Ville Voutilainen wrote: On 22 September 2016 at 12:37, Christophe Lyon wrote: Does the attached patch fix the problem? Yes, thanks! Here be the changelog. Jonathan, ok for trunk? Patch attached again for convenience. OK, thanks.

Re: [PATCH GCC][v2]Simplify alias check code generation in vectorizer

2016-09-22 Thread Richard Biener
On Thu, Sep 22, 2016 at 11:43 AM, Bin.Cheng wrote: > On Wed, Sep 21, 2016 at 3:01 PM, Richard Biener > wrote: >> On Tue, Sep 20, 2016 at 5:25 PM, Bin Cheng wrote: >>> Hi, >>> I originally posted a patch improving code

Re: [PATCH] libstdc++/77641 fix std::variant for literal types

2016-09-22 Thread Jonathan Wakely
On 21/09/16 20:23 -0700, Tim Shen wrote: On Wed, Sep 21, 2016 at 1:52 AM, Jonathan Wakely wrote: THanks, OK for trunk. Committed. This fixes the pretty printer. Committed to trunk. commit 6b869af56fa80da5b746390ce5616ebebcc0bd5d Author: redi

Re: [Patch] Fix variant::operator= on references

2016-09-22 Thread Ville Voutilainen
On 22 September 2016 at 13:03, Jonathan Wakely wrote: > On 22/09/16 01:49 -0700, Tim Shen wrote: >> >> Done. When writing the initial version, I was trying to save as much >> qualifications as possible (as long as the semantic doesn't change) >> for readability, but that might

Re: [Patch] Fix variant::operator= on references

2016-09-22 Thread Jonathan Wakely
On 22/09/16 01:49 -0700, Tim Shen wrote: Done. When writing the initial version, I was trying to save as much qualifications as possible (as long as the semantic doesn't change) for readability, but that might not be a good idea. It does change the semantics, as forward<_Tp>(__tp) can find

Re: [PATCH GCC][v2]Simplify alias check code generation in vectorizer

2016-09-22 Thread Bin.Cheng
On Wed, Sep 21, 2016 at 3:01 PM, Richard Biener wrote: > On Tue, Sep 20, 2016 at 5:25 PM, Bin Cheng wrote: >> Hi, >> I originally posted a patch improving code generation for alias check in >> vectorizer at

Re: [v3 PATCH] PR libstdc++/77288 and the newest proposed resolution for LWG 2756

2016-09-22 Thread Ville Voutilainen
On 22 September 2016 at 12:37, Christophe Lyon wrote: >> Does the attached patch fix the problem? > > Yes, thanks! Here be the changelog. Jonathan, ok for trunk? Patch attached again for convenience. 2016-09-22 Ville Voutilainen

Re: [v3 PATCH] PR libstdc++/77288 and the newest proposed resolution for LWG 2756

2016-09-22 Thread Christophe Lyon
On 22 September 2016 at 11:05, Ville Voutilainen wrote: > On 22 September 2016 at 11:55, Christophe Lyon > wrote: >> The new test 77288.cc fails on old arm targets (armv5t): >>

Re: [RFC] Extend ipa-bitwise-cp with pointer alignment propagation

2016-09-22 Thread Richard Biener
On Thu, Sep 22, 2016 at 11:21 AM, Richard Biener wrote: > On Wed, Sep 21, 2016 at 6:44 PM, Prathamesh Kulkarni > wrote: >> Hi, >> The attached patch tries to extend ipa bits propagation to handle >> pointer alignment propagation. >> The

Re: [RFC] Extend ipa-bitwise-cp with pointer alignment propagation

2016-09-22 Thread Richard Biener
On Wed, Sep 21, 2016 at 6:44 PM, Prathamesh Kulkarni wrote: > Hi, > The attached patch tries to extend ipa bits propagation to handle > pointer alignment propagation. > The patch just disables ipa-cp-alignment pass, I suppose we want to > eventually remove it ? > >

Re: [PATCH v2] [RTEMS] Always use atomic builtins for libstdc++

2016-09-22 Thread Andreas Schwab
On Sep 22 2016, Sebastian Huber wrote: > diff --git a/libstdc++-v3/acinclude.m4 b/libstdc++-v3/acinclude.m4 > index 6d897be..d7db435 100644 > --- a/libstdc++-v3/acinclude.m4 > +++ b/libstdc++-v3/acinclude.m4 > @@ -3490,9 +3490,10 @@ EOF >AC_LANG_RESTORE >

Re: [v3 PATCH] PR libstdc++/77288 and the newest proposed resolution for LWG 2756

2016-09-22 Thread Ville Voutilainen
On 22 September 2016 at 11:55, Christophe Lyon wrote: > The new test 77288.cc fails on old arm targets (armv5t): > /aci-gcc-fsf/sources/gcc-fsf/gccsrc/libstdc++-v3/testsuite/20_util/optional/77288.cc: > In function 'void test01()': >

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

2016-09-22 Thread Rainer Orth
Hi Martin, >> Another nit, if I may: FWIW I'm not in love with the wording of the >> messages. Sorry to bikeshed, but how about: >> warning: buffer overflow will occur when writing terminating NUL >> and: >> note: formatted output of 2 bytes into a destination of size 1 >> or somesuch. > > I

Re: [gofrontend-dev] Go patch committed: Avoid warning by using a local var for std::ofstream

2016-09-22 Thread Torvald Riegel
On Wed, 2016-09-21 at 16:56 +0200, Florian Weimer wrote: > Torvald, would it be possible to align mutexes internally on hppa, to > avoid the 16-byte alignment of the entire struct (that is, store a > pointer to the actual mutex object, which points to a sub-region of > the struct which is suitably

Re: [C++ PATCH] Aligned new option handling fixes (PR c++/77651)

2016-09-22 Thread Christophe Lyon
Hi, On 21 September 2016 at 17:03, Jason Merrill wrote: > OK. > > On Wed, Sep 21, 2016 at 10:46 AM, Jakub Jelinek wrote: >> Hi! >> >> The following patch fixes some ICEs which were because of missing >> RejectNegative for the *aligned-new= options - they

Re: [v3 PATCH] PR libstdc++/77288 and the newest proposed resolution for LWG 2756

2016-09-22 Thread Christophe Lyon
Hi, On 21 September 2016 at 21:42, Ville Voutilainen wrote: > On 21 September 2016 at 12:31, Jonathan Wakely wrote: >> On 06/09/16 09:00 +0300, Ville Voutilainen wrote: >>> >>>PR libstdc++/77288 >>>* include/std/optional

Re: [PATCH] [RTEMS] Always use atomic builtins for libstdc++

2016-09-22 Thread Jonathan Wakely
On 22/09/16 09:47 +0100, Jonathan Wakely wrote: On 22/09/16 09:41 +0200, Sebastian Huber wrote: libstdc++-v3/ * config/cpu/m68k/atomicity.h: Adjust comment. * acinclude.m4 (GLIBCXX_ENABLE_ATOMIC_BUILTINS): Honor explicit atomicity_dir setup via configure.host. *

Re: [Patch] Fix variant::operator= on references

2016-09-22 Thread Tim Shen
On Thu, Sep 22, 2016 at 1:39 AM, Jonathan Wakely wrote: > Please qualify std::forward here. Done. When writing the initial version, I was trying to save as much qualifications as possible (as long as the semantic doesn't change) for readability, but that might not be a good

Re: [PATCH] [RTEMS] Always use atomic builtins for libstdc++

2016-09-22 Thread Sebastian Huber
On 22/09/16 10:47, Jonathan Wakely wrote: On 22/09/16 09:41 +0200, Sebastian Huber wrote: libstdc++-v3/ * config/cpu/m68k/atomicity.h: Adjust comment. * acinclude.m4 (GLIBCXX_ENABLE_ATOMIC_BUILTINS): Honor explicit atomicity_dir setup via configure.host. * configure.host

[PATCH v2] [RTEMS] Always use atomic builtins for libstdc++

2016-09-22 Thread Sebastian Huber
v2: Fix shell script part since shell grouping is expressed by { }. libstdc++-v3/ * config/cpu/m68k/atomicity.h: Adjust comment. * acinclude.m4 (GLIBCXX_ENABLE_ATOMIC_BUILTINS): Honor explicit atomicity_dir setup via configure.host. * configure.host (rtems-*): Set

Re: [PATCH] [RTEMS] Always use atomic builtins for libstdc++

2016-09-22 Thread Jonathan Wakely
On 22/09/16 09:41 +0200, Sebastian Huber wrote: libstdc++-v3/ * config/cpu/m68k/atomicity.h: Adjust comment. * acinclude.m4 (GLIBCXX_ENABLE_ATOMIC_BUILTINS): Honor explicit atomicity_dir setup via configure.host. * configure.host (rtems-*): Set atomicity_dir.

Re: [Patch] Fix variant::operator= on references

2016-09-22 Thread Jonathan Wakely
On 22/09/16 00:43 -0700, Tim Shen wrote: Hi, this patch fixes the following compilation failure: #include int main() { float f1 = 1.0f, f2 = 2.0f; std::variant v1(f1); v1 = f2; // #1 } The bug is caused by a misuse of __storage. I also examined other __storage usage, they all

Re: [PATCH] libstdc++/77641 fix std::variant for literal types

2016-09-22 Thread Jonathan Wakely
On 22/09/16 09:37 +0100, Jonathan Wakely wrote: On 22/09/16 09:45 +0300, Ville Voutilainen wrote: This problem is not introduced by the latest patch, but it's something that we should look at anyway. There's been recent discussion about what assignments do with variants that hold references.

Re: [PATCH] libstdc++/77641 fix std::variant for literal types

2016-09-22 Thread Jonathan Wakely
On 22/09/16 09:45 +0300, Ville Voutilainen wrote: This problem is not introduced by the latest patch, but it's something that we should look at anyway. There's been recent discussion about what assignments do with variants that hold references. Consider this: #include int main() { float f1

Re: [PATCH] [RTEMS] Always use atomic builtins for libstdc++

2016-09-22 Thread Andreas Schwab
On Sep 22 2016, Sebastian Huber wrote: > diff --git a/libstdc++-v3/acinclude.m4 b/libstdc++-v3/acinclude.m4 > index 6d897be..3256ce4 100644 > --- a/libstdc++-v3/acinclude.m4 > +++ b/libstdc++-v3/acinclude.m4 > @@ -3490,9 +3490,10 @@ EOF >AC_LANG_RESTORE >

Re: [Patch, fortran] Clean up of error recovery in DTIO procedures

2016-09-22 Thread Paul Richard Thomas
Committed as revision 240342. Paul On 21 September 2016 at 12:18, Paul Richard Thomas wrote: > Dear All, > > Please find attached a patch to clean up the various issues with > errors in DTIO procedures. The tests were all provided by Gerhard > Steinmetz for which

Re: [PATCH] Fix various minor gimple-ssa-sprintf.c issues

2016-09-22 Thread Marek Polacek
On Thu, Sep 22, 2016 at 09:24:11AM +0200, Jakub Jelinek wrote: > On Wed, Sep 21, 2016 at 06:38:54PM -0600, Martin Sebor wrote: > > On 09/21/2016 09:09 AM, Jakub Jelinek wrote: > > >When looking at PR77676, I've noticed various small formatting etc. > > >issues, like not using is_gimple_* APIs

Re: [Patch] Fix variant::operator= on references

2016-09-22 Thread Tim Shen
On Thu, Sep 22, 2016 at 12:43 AM, Tim Shen wrote: > Hi, this patch fixes the following compilation failure: For the record, the bug is found by Ville. Thank you Ville! :) -- Regards, Tim Shen

[Patch] Fix variant::operator= on references

2016-09-22 Thread Tim Shen
Hi, this patch fixes the following compilation failure: #include int main() { float f1 = 1.0f, f2 = 2.0f; std::variant v1(f1); v1 = f2; // #1 } The bug is caused by a misuse of __storage. I also examined other __storage usage, they all seem appropriate. Tested on

RE: [PATCH] Fix PR tree-optimization/77654

2016-09-22 Thread Richard Biener
On Wed, 21 Sep 2016, Doug Gilmore wrote: > > From: Richard Biener [rguent...@suse.de] > > Sent: Wednesday, September 21, 2016 12:48 AM > > To: Doug Gilmore > > Cc: gcc-patches@gcc.gnu.org; rgue...@gcc.gnu.org > > Subject: RE: [PATCH] Fix PR tree-optimization/77654 > > > > On Tue, 20 Sep 2016,

[PATCH] [RTEMS] Always use atomic builtins for libstdc++

2016-09-22 Thread Sebastian Huber
libstdc++-v3/ * config/cpu/m68k/atomicity.h: Adjust comment. * acinclude.m4 (GLIBCXX_ENABLE_ATOMIC_BUILTINS): Honor explicit atomicity_dir setup via configure.host. * configure.host (rtems-*): Set atomicity_dir. * configure: Regenerate. ---

Re: [PATCH] Fix PR tree-optimization/77550

2016-09-22 Thread Richard Biener
On Wed, 21 Sep 2016, Bernd Edlinger wrote: > On 09/21/16 21:57, Christophe Lyon wrote: > > Hi, > > > > The new testcase pr77550.C fails on arm: > > /testsuite/g++.dg/pr77550.C:39:43: error: 'operator new' takes type > > 'size_t' ('unsigned int') as first parameter [-fpermissive] > > compiler

Re: [PATCH] Fix ICE with inlining and #pragma omp simd (PR fortran/77665)

2016-09-22 Thread Richard Biener
On Wed, 21 Sep 2016, Alexander Monakov wrote: > On Wed, 21 Sep 2016, Jakub Jelinek wrote: > > The simduid pass uses the cfun->has_simduid_loops flag to determine if it > > needs to clean up any left-over GOMP_SIMD_* internal functions. > > During inlining, we set the flag if we inline some loop

Re: [Patch, avr] Provide correct LD offset bound in avr_address_cost

2016-09-22 Thread Denis Chertykov
2016-09-22 7:52 GMT+03:00 Senthil Kumar Selvaraj : > Hi, > > This patch fixes cost computation in avr_address_cost - instead of the > hardcoded 61, it uses the already existing MAX_LD_OFFSET(mode) macro. > > This showed up when investigating a code size

Re: [PATCH] Fix various minor gimple-ssa-sprintf.c issues

2016-09-22 Thread Jakub Jelinek
On Wed, Sep 21, 2016 at 06:38:54PM -0600, Martin Sebor wrote: > On 09/21/2016 09:09 AM, Jakub Jelinek wrote: > >When looking at PR77676, I've noticed various small formatting etc. > >issues, like not using is_gimple_* APIs where we have them, not using > >gimple_call_builtin_p/gimple_call_fndecl

Fortran, committed: ICE on missing parameter value for initialisation (segfault) (pr 66107)

2016-09-22 Thread Louis Krupp
Fixed in revision 240341.

Re: [PATCH] libstdc++/77641 fix std::variant for literal types

2016-09-22 Thread Ville Voutilainen
This problem is not introduced by the latest patch, but it's something that we should look at anyway. There's been recent discussion about what assignments do with variants that hold references. Consider this: #include int main() { float f1 = 1.0f, f2 = 2.0f; std::variant v1(f1);

Re: PR35503 - warn for restrict pointer

2016-09-22 Thread Prathamesh Kulkarni
On 20 September 2016 at 18:31, Joseph Myers wrote: > On Tue, 20 Sep 2016, Prathamesh Kulkarni wrote: > >> Could someone please take a look at the change to c-format.c, I am not sure >> if I have added that correctly. > > Any changes to these GCC formats also require tests

<    1   2