Re: [PATCH] FMA_EXPR can cause -fnon-call-exceptions with floating point args (PR middle-end/79396)
On Sat, Feb 25, 2017 at 08:42:33AM +0100, Richard Biener wrote:
> On February 24, 2017 9:56:25 PM GMT+01:00, Jakub Jelinek
> wrote:
> >Hi!
> >
> >On the following testcase we replace a PLUS_EXPR (which is considered
> >throwing with -fnon-call-exceptions when it has floating point
> >arguments
> >and FP exceptions or sNaNs are enabled) with a FMA_EXPR; I believe it
> >can throw the same, but stmt_could_throw_1_p doesn't think so (as it is
> >not unary/binary/comparison). While we could tweak the widen_mul patch
> >to deal with dropping EH from gsi_replace and cleaning up cfg etc., I
> >believe the right fix is to fix stmt_could_throw_1_p.
> >
> >Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?
>
> OK. Can you make sure this is then consistent with the other throw
> predicates?.
may_trap_p_1 handles FMA right, no idea what other predicates could cover
that on RTL. But you're right, operation_could_trap_p used by
tree_could_trap_p needs the same treatment:
2017-02-25 Jakub Jelinek
PR middle-end/79396
* tree-eh.c (operation_could_trap_p, stmt_could_throw_1_p): Handle
FMA_EXPR like tcc_binary or tcc_unary.
* g++.dg/opt/pr79396.C: New test.
--- gcc/tree-eh.c.jj2017-02-24 21:39:01.240088691 +0100
+++ gcc/tree-eh.c 2017-02-25 09:21:06.017859379 +0100
@@ -2513,7 +2513,8 @@ operation_could_trap_p (enum tree_code o
if (TREE_CODE_CLASS (op) != tcc_comparison
&& TREE_CODE_CLASS (op) != tcc_unary
- && TREE_CODE_CLASS (op) != tcc_binary)
+ && TREE_CODE_CLASS (op) != tcc_binary
+ && op != FMA_EXPR)
return false;
return operation_could_trap_helper_p (op, fp_operation, honor_trapv,
@@ -2738,7 +2739,8 @@ stmt_could_throw_1_p (gimple *stmt)
if (TREE_CODE_CLASS (code) == tcc_comparison
|| TREE_CODE_CLASS (code) == tcc_unary
- || TREE_CODE_CLASS (code) == tcc_binary)
+ || TREE_CODE_CLASS (code) == tcc_binary
+ || code == FMA_EXPR)
{
if (is_gimple_assign (stmt)
&& TREE_CODE_CLASS (code) == tcc_comparison)
--- gcc/testsuite/g++.dg/opt/pr79396.C.jj 2017-02-25 09:20:03.608706718
+0100
+++ gcc/testsuite/g++.dg/opt/pr79396.C 2017-02-25 09:20:03.607706732 +0100
@@ -0,0 +1,13 @@
+// PR middle-end/79396
+// { dg-do compile }
+// { dg-options "-fnon-call-exceptions -O2" }
+// { dg-additional-options "-mfma" { target i?86-*-* x86_64-*-* } }
+
+struct A { A (); ~A (); };
+
+float
+foo (float x)
+{
+ A a;
+ return __builtin_pow (x, 2) + 2;
+}
Jakub
Re: [PATCH] Two small translation related tweaks
On Fri, Feb 24, 2017 at 09:44:44PM +0100, Jakub Jelinek wrote: > After hinting Marek to use const char *const in his G_ addition patch, > I've grepped for other similar cases. The number_of_iterations_exit > code doesn't make sense after we ended up (change from 6.x) with > only a single wording, and in the C++ FE the addition of const allows > -Wformat to see those format strings. > > Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk? > > 2017-02-24 Jakub Jelinek > > * tree-ssa-loop-niter.c (number_of_iterations_exit): Simplify warning. > cp/ > * call.c (build_op_delete_call): Make msg1 and msg2 const. Committed as obvious. Jakub
PR79697: Delete calls to strdup, strndup, realloc if there is no lhs
Hi,
The attached patch deletes calls to strdup, strndup if it's
return-value is unused,
and same for realloc if the first arg is NULL.
Bootstrap+tested on x86_64-unknown-linux-gnu.
OK for GCC 8 ?
Thanks,
Prathamesh
2017-02-25 Prathamesh Kulkarni
PR tree-optimization/79697
* tree-ssa-dce.c (mark_stmt_if_obviously_necessary): Check if callee
is BUILT_IN_STRDUP, BUILT_IN_STRNDUP, BUILT_IN_REALLOC.
testsuite/
* gcc.dg/tree-ssa/pr79697.c: New test.
diff --git a/gcc/testsuite/gcc.dg/tree-ssa/pr79697.c
b/gcc/testsuite/gcc.dg/tree-ssa/pr79697.c
new file mode 100644
index 000..a6e75a6
--- /dev/null
+++ b/gcc/testsuite/gcc.dg/tree-ssa/pr79697.c
@@ -0,0 +1,21 @@
+/* { dg-do compile } */
+/* { dg-options "-O2 -fdump-tree-cddce-details" } */
+
+void f(void)
+{
+ __builtin_strdup ("abc");
+}
+
+void g(void)
+{
+ __builtin_strndup ("abc", 3);
+}
+
+void h(void)
+{
+ __builtin_realloc (0, 10);
+}
+
+/* { dg-final { scan-tree-dump "Deleting : __builtin_strdup" "cddce1" } } */
+/* { dg-final { scan-tree-dump "Deleting : __builtin_strndup" "cddce1" } } */
+/* { dg-final { scan-tree-dump "Deleting : __builtin_realloc" "cddce1" } } */
diff --git a/gcc/tree-ssa-dce.c b/gcc/tree-ssa-dce.c
index 5ebe57b..b0f62b0 100644
--- a/gcc/tree-ssa-dce.c
+++ b/gcc/tree-ssa-dce.c
@@ -233,8 +233,17 @@ mark_stmt_if_obviously_necessary (gimple *stmt, bool
aggressive)
case BUILT_IN_CALLOC:
case BUILT_IN_ALLOCA:
case BUILT_IN_ALLOCA_WITH_ALIGN:
+ case BUILT_IN_STRDUP:
+ case BUILT_IN_STRNDUP:
return;
+ case BUILT_IN_REALLOC:
+ {
+ tree arg0 = gimple_call_arg (stmt, 0);
+ if (operand_equal_p (arg0, null_pointer_node, 0))
+ return;
+ break;
+ }
default:;
}
/* Most, but not all function calls are required. Function calls that
Re: PR79697: Delete calls to strdup, strndup, realloc if there is no lhs
On Sat, 25 Feb 2017, Prathamesh Kulkarni wrote: Hi, The attached patch deletes calls to strdup, strndup if it's return-value is unused, and same for realloc if the first arg is NULL. Bootstrap+tested on x86_64-unknown-linux-gnu. OK for GCC 8 ? Instead of specializing realloc(0,*) wherever we can perform the same optimization as with malloc, wouldn't it be better to optimize: realloc(0,n) -> malloc(n) and let the malloc optimizations happen? (realloc(p,0)->free(p) is more tricky because of the return value, like malloc(0)) -- Marc Glisse
Re: [PATCH][x86_64] Enable AVX512 VPOPCNTD/VPOPCNTQ instructions
On Fri, Feb 24, 2017 at 8:29 PM, Andrew Senkevich wrote: >> Also, could you pls implement runtime test cases for new intrinsics. > > Hi, > > those tests are attached, are they Ok? > ChangLog: > > gcc/testsuite/ > > * gcc.target/i386/avx512vpopcntdq-check.h: New. > * gcc.target/i386/avx512vpopcntdq-vpopcntd-1.c: Ditto. > * gcc.target/i386/avx512vpopcntdq-vpopcntq-1.c: Ditto. > * gcc.target/i386/avx512f-helper.h: Add avx512vpopcntdq-check.h. > * gcc.target/i386/i386.exp (check_effective_target_avx512vpopcntdq): New. OK. Thanks, Uros.
[wwwdocs] Convert navigation table to CSS
While converting the web pages to CSS last year -- not the least due
to the strict Content-Security-Policy put in place for gcc.gnu.org --
this was the last item on my list.
With the change below, https://www.gnu.org/software/gcc/ (which does
not have a strict Content-Security-Policy) and https://gcc.gnu.org/
now look the same again.
On the way I also slightly reduced padding left of the navigation bar,
and converted one instance of cellspacing="0" to the corresponding CSS.
Applied.
Gerald
Index: gcc.css
===
RCS file: /cvs/gcc/wwwdocs/htdocs/gcc.css,v
retrieving revision 1.46
diff -u -r1.46 gcc.css
--- gcc.css 27 Jan 2017 16:21:40 - 1.46
+++ gcc.css 25 Feb 2017 11:33:09 -
@@ -32,6 +32,11 @@
td.status .regress { font-size: 80%; }
td.status dd { margin-left:3ex; }
+table.nav {
+ padding-left: 32px;
+ border-spacing: 0pt;
+}
+
table.navitem tr:nth-child(1) {
border-color: #3366cc;
border-style: solid;
Index: style.mhtml
===
RCS file: /cvs/gcc/wwwdocs/htdocs/style.mhtml,v
retrieving revision 1.132
diff -u -r1.132 style.mhtml
--- style.mhtml 4 Dec 2016 23:21:06 - 1.132
+++ style.mhtml 25 Feb 2017 11:33:09 -
@@ -93,8 +93,8 @@
-
-
+
+
About GCC
Re: [wwwdocs] Convert navigation table to CSS (part 2)
On Sat, 25 Feb 2017, Gerald Pfeifer wrote:
> On the way I also slightly reduced padding left of the navigation bar,
> and converted one instance of cellspacing="0" to the corresponding CSS.
This is the second part of this. Again, nice to notice how CSS
reduces complexity inside the pages -- one central definition versus
six local instances.
Applied.
Gerald
Index: gcc.css
===
RCS file: /cvs/gcc/wwwdocs/htdocs/gcc.css,v
retrieving revision 1.47
diff -u -r1.47 gcc.css
--- gcc.css 25 Feb 2017 11:41:17 - 1.47
+++ gcc.css 25 Feb 2017 11:45:12 -
@@ -37,6 +37,10 @@
border-spacing: 0pt;
}
+table.navitem {
+ border-spacing: 0pt;
+}
+
table.navitem tr:nth-child(1) {
border-color: #3366cc;
border-style: solid;
Index: style.mhtml
===
RCS file: /cvs/gcc/wwwdocs/htdocs/style.mhtml,v
retrieving revision 1.133
diff -u -r1.133 style.mhtml
--- style.mhtml 25 Feb 2017 11:41:18 - 1.133
+++ style.mhtml 25 Feb 2017 11:45:12 -
@@ -96,7 +96,7 @@
-
+
About GCC
Mission Statement
@@ -118,7 +118,7 @@
-
+
Documentation
https://gcc.gnu.org/install/";>Installation
@@ -130,7 +130,7 @@
-
+
Download
Mirrors
@@ -138,7 +138,7 @@
-
+
Sources
SVN read access
@@ -148,7 +148,7 @@
-
+
Development
Development Plan
@@ -165,7 +165,7 @@
-
+
Bugs
Known bugs
[wwwdocs] style.html - tweak social media links in navigation
Also center-align Twitter (not just Google+) and remove no-ops style="border:0px" attributes for Twitter and Google+ icons. Gerald Index: style.mhtml === RCS file: /cvs/gcc/wwwdocs/htdocs/style.mhtml,v retrieving revision 1.134 diff -u -r1.134 style.mhtml --- style.mhtml 25 Feb 2017 11:46:22 - 1.134 +++ style.mhtml 25 Feb 2017 13:14:51 - @@ -105,15 +105,17 @@ Mailing lists https://gcc.gnu.org/onlinedocs/gcc/Contributors.html";>Contributors Steering Committee + https://twitter.com/gnutools";> @gnutools + />@gnutools + https://plus.google.com/108467477471815191158";> gnutools + /> gnutools
gcc.gnu.org and Content-Security-Policy (was: gcc-6/changes.html: diagnostics, Levenshtein, -Wmisleading-indentation, jit (v2))
On Wed, 20 Jan 2016, Jakub Jelinek wrote: >>> It seems gcc.gnu.org enforces a strict Content Security Policy >>> (cf. >>> http://www.html5rocks.com/en/tutorials/security/content-security-policy/ >>> for example) which does not allow for inline CSS styles. >>> >>> Content-Security-Policy: default-src 'self' http: https: > BTW, is that also the reason why very recently the gcc.gnu.org homepage > changed layout (the News column is much wider than the Release Series and > Status > column), at least with Firefox 43.0? The page has: > Yes, exactly! I had addressed most of that back then last year, and now finally completed the last missing pieces. (There are only two bits of local "style=" left on our web site, in projects/gupc.html.) Gerald
[patch, fortran] Set default inline matmul limit to 30
Hello world,
there still was one piece missing for the new matmul library
version. To make sure that users (usually) benefit, we need
to call the library by default up from a certain limit.
The attached patch does that, with a limit of 30, which seems
to be reasonable given a few benchmarks.
Some test cases had to be changed to scan the optimized tree
instead of the original because the version still had some
if (0) statement in them.
Regeression-tested. OK for trunk?
Regards
Thomas
2017-02-25 Thomas Koenig
PR fortran/51119
* options.c (gfc_post_options): Set default limit for matmul
inlining to 30.
* invoke.texi: Document change.
2017-02-25 Thomas Koenig
PR fortran/51119
* gfortran.dg/inline_matmul_1.f90: Scan optimized dump instead
of original.
* gfortran.dg/inline_matmul_11.f90: Likewise.
* gfortran.dg/inline_matmul_9.f90: Likewise.
* gfortran.dg/matmul_13.f90: New test.
* gfortran.dg/matmul_14.f90: New test.
Index: fortran/invoke.texi
===
--- fortran/invoke.texi (Revision 245564)
+++ fortran/invoke.texi (Arbeitskopie)
@@ -1630,7 +1630,7 @@ square, the size comparison is performed using the
the dimensions of the argument and result matrices.
The default value for @var{n} is the value specified for
-@code{-fblas-matmul-limit} if this option is specified, or unlimitited
+@code{-fblas-matmul-limit} if this option is specified, or 30
otherwise.
@item -frecursive
Index: fortran/options.c
===
--- fortran/options.c (Revision 245564)
+++ fortran/options.c (Arbeitskopie)
@@ -388,10 +388,16 @@ gfc_post_options (const char **pfilename)
if (!flag_automatic)
flag_max_stack_var_size = 0;
- /* If we call BLAS directly, only inline up to the BLAS limit. */
+ /* If the user did not specify an inline matmul limit, inline up to the BLAS
+ limit or up to 30 if no external BLAS is specified. */
- if (flag_external_blas && flag_inline_matmul_limit < 0)
-flag_inline_matmul_limit = flag_blas_matmul_limit;
+ if (flag_inline_matmul_limit < 0)
+{
+ if (flag_external_blas)
+ flag_inline_matmul_limit = flag_blas_matmul_limit;
+ else
+ flag_inline_matmul_limit = 30;
+}
/* Optimization implies front end optimization, unless the user
specified it directly. */
Index: testsuite/gfortran.dg/inline_matmul_1.f90
===
--- testsuite/gfortran.dg/inline_matmul_1.f90 (Revision 245564)
+++ testsuite/gfortran.dg/inline_matmul_1.f90 (Arbeitskopie)
@@ -1,5 +1,5 @@
! { dg-do run }
-! { dg-options "-ffrontend-optimize -fdump-tree-original -Wrealloc-lhs" }
+! { dg-options "-ffrontend-optimize -fdump-tree-optimized -Wrealloc-lhs" }
! PR 37131 - check basic functionality of inlined matmul, making
! sure that the library is not called, with and without reallocation.
@@ -149,4 +149,4 @@ program main
end program main
-! { dg-final { scan-tree-dump-times "_gfortran_matmul" 0 "original" } }
+! { dg-final { scan-tree-dump-times "_gfortran_matmul" 0 "optimized" } }
Index: testsuite/gfortran.dg/inline_matmul_11.f90
===
--- testsuite/gfortran.dg/inline_matmul_11.f90 (Revision 245564)
+++ testsuite/gfortran.dg/inline_matmul_11.f90 (Arbeitskopie)
@@ -1,5 +1,5 @@
! { dg-do run }
-! { dg-additional-options "-ffrontend-optimize -fdump-tree-original" }
+! { dg-additional-options "-ffrontend-optimize -fdump-tree-optimized" }
! PR fortran/66176 - inline conjg for matml.
program main
complex, dimension(3,2) :: a
@@ -29,4 +29,4 @@ program main
c = matmul(conjg(a), b)
if (any(conjg(c) /= res2)) call abort
end program main
-! { dg-final { scan-tree-dump-times "_gfortran_matmul" 0 "original" } }
+! { dg-final { scan-tree-dump-times "_gfortran_matmul" 0 "optimized" } }
Index: testsuite/gfortran.dg/inline_matmul_9.f90
===
--- testsuite/gfortran.dg/inline_matmul_9.f90 (Revision 245564)
+++ testsuite/gfortran.dg/inline_matmul_9.f90 (Arbeitskopie)
@@ -1,5 +1,5 @@
! { dg-do run }
-! { dg-options "-ffrontend-optimize -fdump-tree-original" }
+! { dg-options "-ffrontend-optimize -fdump-tree-optimized" }
! PR 66041 - this used to ICE with an incomplete fix for the PR.
program main
implicit none
@@ -21,4 +21,4 @@ program main
if (any (c2-reshape([248., -749.],shape(c2)) /= 0.)) call abort
end program main
-! { dg-final { scan-tree-dump-times "_gfortran_matmul" 0 "original" } }
+! { dg-final { scan-tree-dump-times "_gfortran_matmul" 0 "optimized" } }
! { dg-do compile }
! { dg-options "-O3 -fdump-tree-optimized" }
! Check that the default limit of 30 for inlining matmul applies.
program main
integer, parameter :: n = 31
real, dimension(n,n) :: a, b,
[wwwdocs] gcc-4.3/porting_to.html -- fix link into libstdc++ manual
Applied, and while I was at it, also changed the link text from "here" to "libstdc++ manual". Gerald Index: gcc-4.3/porting_to.html === RCS file: /cvs/gcc/wwwdocs/htdocs/gcc-4.3/porting_to.html,v retrieving revision 1.13 diff -u -r1.13 porting_to.html --- gcc-4.3/porting_to.html 14 Nov 2015 20:53:58 - 1.13 +++ gcc-4.3/porting_to.html 25 Feb 2017 15:36:44 - @@ -314,7 +314,9 @@ -For future reference, available headers are listed https://gcc.gnu.org/onlinedocs/libstdc++/manual/bk01pt01ch03s02.html";>here. +For future reference, available headers are listed in the https://gcc.gnu.org/onlinedocs/libstdc++/manual/using_headers.html";>libstdc++ +manual. An example.
[wwwdocs] readings.html - link maintenance for renesas.com
Applied. (Let's see how long this lasts...) Gerald Index: readings.html === RCS file: /cvs/gcc/wwwdocs/htdocs/readings.html,v retrieving revision 1.262 diff -u -r1.262 readings.html --- readings.html 23 Feb 2017 14:21:12 - 1.262 +++ readings.html 25 Feb 2017 15:59:33 - @@ -159,7 +159,7 @@ m32c Manufacturer: Renesas - http://www.renesas.com/products/mpumcu/m16c/";>Renesas M16C Family (R32C/M32C/M16C) Site + https://www.renesas.com/en-us/products/microcontrollers-microprocessors/m16c.html";>Renesas M16C Family (R32C/M32C/M16C) Site GDB includes a simulator. @@ -260,13 +260,13 @@ rx Manufacturer: Renesas - http://documentation.renesas.com/eng/products/mpumcu/rej09b0460_rx610hm.pdf";>RX610 Hardware Manual + https://www.renesas.com/en-us/doc/products/mpumcu/doc/rx_family/r01uh0032ej0120_rx610.pdf";>RX610 Hardware Manual sh Manufacturer: Renesas, various licensees. CPUs include: SH1, SH2, SH2-DSP, SH3, SH3-DSP, SH4, SH4A, SH5 series. - http://www.renesas.com/products/mpumcu/superh/";>Renesas SuperH Processors + https://www.renesas.com/en-us/products/microcontrollers-microprocessors/superh.html";>Renesas SuperH Processors http://shared-ptr.com/sh_insns.html";>SuperH Instruction Set Summary GDB includes a simulator.
[wwwdocs] Redirect to www.gnu.org for the GNU Coding Standards
In doc/sourcebuild.texi we have @xref{Standard Targets, , Standard Targets
for...} which leads to a broken link in
https://gcc.gnu.org/onlinedocs/gccint/Front-End-Makefile.html since
gcc.gnu.org does not carry a copy of the GNU Coding Standards.
Instead let's refer to the version on www.gnu.org via a redirect.
Gerald
Index: .htaccess
===
RCS file: /cvs/gcc/wwwdocs/htdocs/.htaccess,v
retrieving revision 1.42
diff -u -r1.42 .htaccess
--- .htaccess 5 Feb 2017 21:40:40 - 1.42
+++ .htaccess 25 Feb 2017 16:13:28 -
@@ -71,5 +71,6 @@
Redirect permanent /web.html https://gcc.gnu.org/about.html
Redirect /onlinedocs/libc
https://www.gnu.org/software/libc/manual/html_node/
+Redirect /onlinedocs/standards
https://www.gnu.org/prep/standards/html_node/
Redirect /onlinedocs/ref
https://gcc.gnu.org/onlinedocs/gcc-4.3.2/
[wwwdocs] readings.html: use refspecs.linux-foundation.org instead of refspecs.freestandards.org
...which apparently has gone the way of the dodo. Applied. Gerald Index: readings.html === RCS file: /cvs/gcc/wwwdocs/htdocs/readings.html,v retrieving revision 1.263 diff -u -r1.263 readings.html --- readings.html 25 Feb 2017 16:01:18 - 1.263 +++ readings.html 25 Feb 2017 16:19:56 - @@ -629,7 +629,7 @@ http://researchweb.watson.ibm.com/journal/";>IBM Journal of Research and Development - http://refspecs.freestandards.org/elf/elfspec_ppc.pdf";>System + http://refspecs.linux-foundation.org/elf/elfspec_ppc.pdf";>System V PowerPC ABI http://www.arm.com/products/DevTools/ABI.html";>Application Binary Interface for the ARM Architecture (EABI)
Re: A new branch 'ira-select' created
Hi Vladimir On Mon, 31 Oct 2016, Vladimir N Makarov wrote: > I've created a new branch ira-select for work on experimental > algorithm of calculations of pseudo register classes. did you mean to also add this to gcc.gnu.org/svn.html ? That's where we generally document such branches. Thanks, Gerald
New French PO file for 'gcc' (version 7.1-b20170101)
Hello, gentle maintainer. This is a message from the Translation Project robot. A revised PO file for textual domain 'gcc' has been submitted by the French team of translators. The file is available at: http://translationproject.org/latest/gcc/fr.po (This file, 'gcc-7.1-b20170101.fr.po', has just now been sent to you in a separate email.) All other PO files for your package are available in: http://translationproject.org/latest/gcc/ Please consider including all of these in your next release, whether official or a pretest. Whenever you have a new distribution with a new version number ready, containing a newer POT file, please send the URL of that distribution tarball to the address below. The tarball may be just a pretest or a snapshot, it does not even have to compile. It is just used by the translators when they need some extra translation context. The following HTML page has been updated: http://translationproject.org/domain/gcc.html If any question arises, please contact the translation coordinator. Thank you for all your work, The Translation Project robot, in the name of your translation coordinator.
Re: [PATCH] Remove x86 pcommit instruction
On Wed, 7 Dec 2016, Andrew Senkevich wrote: >>> But how to update changes for upcoming GCC 6.3 (and future GCC 5.5)? >> There are corresponding documents at [1] and [2], please add a "GCC >> 6.3" or "GCC 5.5" entry with "Target Specific Changes" at the end of >> the documents. >> >> [1] https://gcc.gnu.org/gcc-6/changes.html >> [2] https://gcc.gnu.org/gcc-5/changes.html > Attached patches, who will apply them? I noticed nobody so far, so I took this. The patch for GCC 6 required some tweaking (and you can't use the some id for two different headings). Below is what I just applied. Gerald Index: gcc-6/changes.html === RCS file: /cvs/gcc/wwwdocs/htdocs/gcc-6/changes.html,v retrieving revision 1.93 diff -u -r1.93 changes.html --- gcc-6/changes.html 18 Feb 2017 22:15:41 - 1.93 +++ gcc-6/changes.html 25 Feb 2017 17:06:27 - @@ -879,5 +879,15 @@ complete (that is, it is possible that some PRs that have been fixed are not listed here). +Target Specific Changes + +IA-32/x86-64 + +Support for the https://software.intel.com/en-us/blogs/2016/09/12/deprecate-pcommit-instruction";>deprecated +pcommit instruction has been removed. + + +
Re: [PATCH] Properly deprecate -fipa-cp-alignment
On Tue, 21 Feb 2017, Martin Jambor wrote: > I see, I suppose we should be consistent, I will commit the following, > which I have included in a bootstrap and test run on x86_64-linux. Do you also plan to add a note to gcc-7/changes.html? I think that would make sense. Gerald
Re: [patch, fortran] Set default inline matmul limit to 30
On Sat, Feb 25, 2017 at 02:29:12PM +0100, Thomas Koenig wrote:
>
> there still was one piece missing for the new matmul library
> version. To make sure that users (usually) benefit, we need
> to call the library by default up from a certain limit.
> The attached patch does that, with a limit of 30, which seems
> to be reasonable given a few benchmarks.
>
> Some test cases had to be changed to scan the optimized tree
> instead of the original because the version still had some
> if (0) statement in them.
>
> Regeression-tested. OK for trunk?
Looks ok to me with one comment below.
> Index: fortran/invoke.texi
> ===
> --- fortran/invoke.texi (Revision 245564)
> +++ fortran/invoke.texi (Arbeitskopie)
> @@ -1630,7 +1630,7 @@ square, the size comparison is performed using the
> the dimensions of the argument and result matrices.
>
> The default value for @var{n} is the value specified for
> -@code{-fblas-matmul-limit} if this option is specified, or unlimitited
> +@code{-fblas-matmul-limit} if this option is specified, or 30
> otherwise.
This description looks a little muddled. I think something like
The default value for N is 30. The @code{-fblas-matmul-limit}
can be used to change this value.
--
Steve
Re: [PATCH 4/5] Document warning option -Wstring-plus-int
On Wed, 22 Feb 2017, Xi Ruoyao wrote:
> 2017-02-22 Xi Ruoyao
>
> * doc/invoke.texi (Warning Options): Document -Wstring-plus-int
In principle this looks fine, but...
> +@item -Wstring-plus-int
> +@opindex Wstring-plus-int
> +@opindex Wno-string-plus-int
> +Warn for adding an integer to a string pointer or string literal,
> +which seems an ill-formed attempt to append to the string.
...I will say this may not give people too much of an idea of what
it is about.
I.e., after reading the above, I was wondering who'd do "abc" + 1.
Of course, once I looked at your good additions to the testsuite,
I realized that this is really more about "abc" + '1'. Technically
the description is correct, since character constants are integers.
Perhaps add something like
"A typical example this warns about is @samp{"abc" + 'd'}."
?
Gerald
Re: [PATCH] Implement new hook for max_align_t_align
On Wed, 12 Oct 2016, John David Anglin wrote: >> It's really hard to make an argument to do anything other than deprecate >> that platform. Given John's ongoing involvement it's much harder to >> deprecate 64bit linux (and consequently 64bit hpux). > I believe that deprecating the 32-bit HP-UX platform makes sense. There > is no HP involvement in hppa, ia64 or alpha open source that I am aware > of, so deprecating gcc platforms with HP systems is reasonable. > > My primary focus is open source and one less platform will free some time. Sooo, why not deprecate 32-bit HP-UX with GCC 7? Now is still a good time doing so, from the release perspective, and if you as the maintainer (and pretty much only person active here) are in favor... Gerald
[wwwdocs] Adjust (heading) levels of GCC 6 releases in the release notes
After applying the change to document removal of the pcommit instruction with GCC 6.3, I noticed the levels of headings were inconsistent, that is, subheadings had the same level () as their parent. In the past we did not run into this since we usually did not have much to document for minor releases. My recommendation, implemented and applied with the patch below, is to use for minor releases as we do for the first heading on the page. That allows us to keep any children at the same level. Gerald Index: changes.html === RCS file: /cvs/gcc/wwwdocs/htdocs/gcc-6/changes.html,v retrieving revision 1.94 diff -u -r1.94 changes.html --- changes.html25 Feb 2017 17:10:32 - 1.94 +++ changes.html25 Feb 2017 17:40:45 - @@ -835,9 +835,6 @@ in 32-bit mode whenever the use of SSE instructions is requested. - - - Other significant improvements @@ -853,7 +850,8 @@ generation of PIE by default. -GCC 6.2 + +GCC 6.2 This is the https://gcc.gnu.org/bugzilla/buglist.cgi?bug_status=RESOLVED&resolution=FIXED&target_milestone=6.2";>list of problem reports (PRs) from GCC's bug tracking system that are @@ -871,7 +869,7 @@ Support for the VIS 4.0 instruction set has been added. -GCC 6.3 +GCC 6.3 This is the https://gcc.gnu.org/bugzilla/buglist.cgi?bug_status=RESOLVED&resolution=FIXED&target_milestone=6.3";>list of problem reports (PRs) from GCC's bug tracking system that are @@ -888,6 +886,5 @@ pcommit instruction has been removed. -
Re: [wwwdocs] Add a case to porting_to + a question wrt validity of another one
On Tue, 7 Feb 2017, Marek Polacek wrote:
> Fixed.
Here is a small follow-up patch that I applied on top of this.
It uses , improves markup, and simplifies language a bit.
(Note that if we have "member" is a meta-variable, then we also need
to mark it up as "member" whenever we refer to it.)
Gerald
Index: gcc-7/porting_to.html
===
RCS file: /cvs/gcc/wwwdocs/htdocs/gcc-7/porting_to.html,v
retrieving revision 1.8
diff -u -r1.8 porting_to.html
--- gcc-7/porting_to.html 13 Feb 2017 13:43:29 - 1.8
+++ gcc-7/porting_to.html 25 Feb 2017 16:38:14 -
@@ -36,11 +36,11 @@
Stricter rules when using templates
-GCC 7 no longer accepts various ill-formed code involving use of templates.
-The C++ standard says:
+GCC 7 no longer accepts various ill-formed constructs involving the use
+of templates. The C++ standard says:
-
+
14.6/8: "If a hypothetical instantiation of a template immediately
following its definition would be ill-formed due to a construct that
does not depend on a template parameter, the program is ill-formed; no
@@ -48,12 +48,13 @@
the hypothetical instantiation is different from the interpretation of
the corresponding construct in any actual instantiation of the
template, the program is ill-formed; no diagnostic is required."
-
+
As a consequence, the following examples are invalid and G++ will no longer
-compile them, because G++ used to treat this->member
-where member has a non-dependent type, as type-dependent, and now it doesn't.
+compile them. G++ used to treat this->member,
+where member has a non-dependent type, as type-dependent and
+no longer does.
@@ -65,7 +66,7 @@
void fn2() { fn1().x; }
};
-will result in
+results in
error: invalid use of incomplete type 'struct
C'
@@ -78,7 +79,7 @@
void fn1() { foo (this->x); }
};
-will result in
+results in
error: there are no arguments to 'foo'
that depend on a template parameter, so a declaration of 'foo' must be
available
@@ -91,12 +92,12 @@
void fn1() { this->a[0]; }
};
-will result in
+results in
error: 'void*' is not a pointer-to-object
type
-because there's no instantiation of that template that can be valid, it will
-always dereference a void*.
+because there is no instantiation of that template that can be valid; it
+will always dereference a void*.
Mangling change for conversion operators
Re: PR79697: Delete calls to strdup, strndup, realloc if there is no lhs
On 25 February 2017 at 14:43, Marc Glisse wrote:
> On Sat, 25 Feb 2017, Prathamesh Kulkarni wrote:
>
>> Hi,
>> The attached patch deletes calls to strdup, strndup if it's
>> return-value is unused,
>> and same for realloc if the first arg is NULL.
>> Bootstrap+tested on x86_64-unknown-linux-gnu.
>> OK for GCC 8 ?
>
>
> Instead of specializing realloc(0,*) wherever we can perform the same
> optimization as with malloc, wouldn't it be better to optimize:
> realloc(0,n) -> malloc(n)
> and let the malloc optimizations happen?
Thanks for the suggestions. In the attached patch, realloc (0, n) is
folded to malloc (n).
Bootstrap+test in progress on x86_64-unknown-linux-gnu.
Does the patch look OK ?
Thanks,
Prathamesh
>
> (realloc(p,0)->free(p) is more tricky because of the return value, like
> malloc(0))
>
> --
> Marc Glisse
diff --git a/gcc/gimple-fold.c b/gcc/gimple-fold.c
index a75dd91..e6eceea 100644
--- a/gcc/gimple-fold.c
+++ b/gcc/gimple-fold.c
@@ -3251,6 +3251,28 @@ gimple_fold_builtin_acc_on_device (gimple_stmt_iterator
*gsi, tree arg0)
return true;
}
+/* Fold realloc (0, n) -> malloc (n). */
+
+static bool
+gimple_fold_builtin_realloc (gimple_stmt_iterator *gsi)
+{
+ gimple *stmt = gsi_stmt (*gsi);
+ tree arg = gimple_call_arg (stmt, 0);
+ tree size = gimple_call_arg (stmt, 1);
+
+ if (operand_equal_p (arg, null_pointer_node, 0))
+{
+ tree fn_malloc = builtin_decl_implicit (BUILT_IN_MALLOC);
+ if (fn_malloc)
+ {
+ gcall *repl = gimple_build_call (fn_malloc, 1, size);
+ replace_call_with_call_and_fold (gsi, repl);
+ return true;
+ }
+}
+ return false;
+}
+
/* Fold the non-target builtin at *GSI and return whether any simplification
was made. */
@@ -3409,6 +3431,9 @@ gimple_fold_builtin (gimple_stmt_iterator *gsi)
case BUILT_IN_ACC_ON_DEVICE:
return gimple_fold_builtin_acc_on_device (gsi,
gimple_call_arg (stmt, 0));
+case BUILT_IN_REALLOC:
+ return gimple_fold_builtin_realloc (gsi);
+
default:;
}
diff --git a/gcc/testsuite/gcc.dg/tree-ssa/pr79697.c
b/gcc/testsuite/gcc.dg/tree-ssa/pr79697.c
new file mode 100644
index 000..8219289
--- /dev/null
+++ b/gcc/testsuite/gcc.dg/tree-ssa/pr79697.c
@@ -0,0 +1,21 @@
+/* { dg-do compile } */
+/* { dg-options "-O2 -fdump-tree-gimple -fdump-tree-cddce-details" } */
+
+void f(void)
+{
+ __builtin_strdup ("abc");
+}
+
+void g(void)
+{
+ __builtin_strndup ("abc", 3);
+}
+
+void h(void)
+{
+ __builtin_realloc (0, 10);
+}
+
+/* { dg-final { scan-tree-dump "Deleting : __builtin_strdup" "cddce1" } } */
+/* { dg-final { scan-tree-dump "Deleting : __builtin_strndup" "cddce1" } } */
+/* { dg-final { scan-tree-dump "__builtin_malloc" "gimple" } } */
diff --git a/gcc/tree-ssa-dce.c b/gcc/tree-ssa-dce.c
index 5ebe57b..4225c3c 100644
--- a/gcc/tree-ssa-dce.c
+++ b/gcc/tree-ssa-dce.c
@@ -233,6 +233,8 @@ mark_stmt_if_obviously_necessary (gimple *stmt, bool
aggressive)
case BUILT_IN_CALLOC:
case BUILT_IN_ALLOCA:
case BUILT_IN_ALLOCA_WITH_ALIGN:
+ case BUILT_IN_STRDUP:
+ case BUILT_IN_STRNDUP:
return;
default:;
Re: [PATCH] Remove x86 pcommit instruction
On Sat, 25 Feb 2017, Gerald Pfeifer wrote: > Below is what I just applied. And here is what I applied for GCC 5. Gerald Index: changes.html === RCS file: /cvs/gcc/wwwdocs/htdocs/gcc-5/changes.html,v retrieving revision 1.143 diff -u -r1.143 changes.html --- changes.html6 Feb 2017 17:43:33 - 1.143 +++ changes.html25 Feb 2017 20:47:27 - @@ -982,7 +982,8 @@ whenever an internal compiler error is encountered. -GCC 5.2 + +GCC 5.2 This is the https://gcc.gnu.org/bugzilla/buglist.cgi?bug_status=RESOLVED&resolution=FIXED&target_milestone=5.2";>list of problem reports (PRs) from GCC's bug tracking system that are @@ -1035,7 +1036,7 @@ header file needs to be included. -GCC 5.3 +GCC 5.3 This is the https://gcc.gnu.org/bugzilla/buglist.cgi?bug_status=RESOLVED&resolution=FIXED&target_milestone=5.3";>list of problem reports (PRs) from GCC's bug tracking system that are @@ -1060,7 +1061,7 @@ compile larger GO applications on IBM z Systems. -GCC 5.4 +GCC 5.4 This is the https://gcc.gnu.org/bugzilla/buglist.cgi?bug_status=RESOLVED&resolution=FIXED&target_milestone=5.4";>list of problem reports (PRs) from GCC's bug tracking system that are @@ -1068,7 +1069,7 @@ complete (that is, it is possible that some PRs that have been fixed are not listed here). -(Pending) GCC 5.5 +(Pending) GCC 5.5 This is the https://gcc.gnu.org/bugzilla/buglist.cgi?bug_status=RESOLVED&resolution=FIXED&target_milestone=5.5";>list of problem reports (PRs) from GCC's bug tracking system that are @@ -1076,5 +1077,14 @@ complete (that is, it is possible that some PRs that have been fixed are not listed here). +Target Specific Changes + +IA-32/x86-64 + +Support for the https://software.intel.com/en-us/blogs/2016/09/12/deprecate-pcommit-instruction";>deprecated +pcommit instruction has been removed. + +
[committed] New hppa-hpux11 pthread.h fix
The attached change fixes PR target/68739. As noted in comment #2, the
standard for libstdc++
requires a constexpr constructor for mutexes. On hpux, we don't have a
constexpr constructor because of
of the void * casts in the PTHREAD_MUTEX_INITIALIZER define and the void *
element in the pthread_mutex
struct.
The attached patch changes the void * element to long in the pthread_mutex
struct and removes the void *
cast from the initializer. This keeps the layout the same as before. As far
as I can tell, this field is only used
internally so the type change shouldn't affect application code.
Tested on hppa2.0w-hp-hpux11.11 and hppa64-hp-hpux11.11. Committed to trunk.
Dave
--
John David Anglin dave.ang...@bell.net
2017-02-25 John David Anglin
PR target/68739
* inclhack.def (hpux11_pthread_pointer): New fix.
(hpux11_pthread_const): Adjust to remove void * cast from define.
* fixincl.x: Regenerate.
Index: inclhack.def
===
--- inclhack.def(revision 245737)
+++ inclhack.def(working copy)
@@ -2366,16 +2366,34 @@
};
/*
- * Fix C99 constant in __POINTER_SET define.
+ * The definitions for PTHREAD_MUTEX_INITIALIZER and similar initializers
+ * in pthread.h need to be constant expressions to be standard complient.
+ * As a result, we need to remove the void * casts in the initializers
+ * (see hpux11_pthread_const) and to change the __(M|C|RW)POINTER defines
+ * to use the long type.
*/
fix = {
+hackname = hpux11_pthread_pointer;
+mach = "*-hp-hpux11.[0-3]*";
+files = sys/pthread.h;
+select= "(void[ \t]*\\*)(m|c|rw)(_ptr)";
+
+c_fix = format;
+c_fix_arg = "long\t%2%3";
+test_text = "#define __MPOINTER\t\tvoid\t *m_ptr";
+};
+
+/*
+ * Remove void pointer cast and fix C99 constant in __POINTER_SET defines.
+ */
+fix = {
hackname = hpux11_pthread_const;
mach = "*-hp-hpux11.[0-3]*";
files = sys/pthread.h;
-select= "^#define[ \t]*__POINTER_SET[ \t]*\\(\\(void \\*\\) 1LL\\)";
+select= "^(#define[ \t]+__POINTER_SET[ \t0,]*)(.*\\))";
c_fix = format;
-c_fix_arg = "#define __POINTER_SET\t\t((void *) 1L)";
+c_fix_arg = "%11";
test_text = "#define __POINTER_SET\t\t((void *) 1LL)";
};
Index: tests/base/sys/pthread.h
===
--- tests/base/sys/pthread.h(revision 245737)
+++ tests/base/sys/pthread.h(working copy)
@@ -14,8 +14,13 @@
#endif /* HPUX11_LWP_RWLOCK_VALID_CHECK */
+#if defined( HPUX11_PTHREAD_POINTER_CHECK )
+#define __MPOINTER longm_ptr
+#endif /* HPUX11_PTHREAD_POINTER_CHECK */
+
+
#if defined( HPUX11_PTHREAD_CONST_CHECK )
-#define __POINTER_SET ((void *) 1L)
+#define __POINTER_SET 1
#endif /* HPUX11_PTHREAD_CONST_CHECK */
[wwwdocs] readings.html - streamline C historical information a bit
HTML and PDF formats should be sufficient, and the early C Reference Manual is just one of many other document on Dennis Ritchie's page, for anyone interested. Applied. Gerald Index: readings.html === RCS file: /cvs/gcc/wwwdocs/htdocs/readings.html,v retrieving revision 1.264 diff -u -r1.264 readings.html --- readings.html 25 Feb 2017 16:21:37 - 1.264 +++ readings.html 25 Feb 2017 21:03:31 - @@ -353,17 +353,12 @@ http://www.open-std.org/jtc1/sc22/wg14/www/docs/n927.htm";> Another formalism for sequence points by D. Hugh Redelmeier - C historical information: + C historical information: - https://www.bell-labs.com/usr/dmr/www/chist.html";>The Development of the C Language, by Dennis M. Ritchie (also in -https://www.bell-labs.com/usr/dmr/www/chist.ps";>PostScript -and https://www.bell-labs.com/usr/dmr/www/chist.pdf";>PDF). -An early https://www.bell-labs.com/usr/dmr/www/cman.ps";>C -Reference Manual. - +https://www.bell-labs.com/usr/dmr/www/chist.pdf";>PDF).
[wwwdocs] readings.html - update link to Blackfin information
With this, the number of problematic links on readings.html is down to a single digit -- a first in many, many years... :-) Applied. Gerald Index: readings.html === RCS file: /cvs/gcc/wwwdocs/htdocs/readings.html,v retrieving revision 1.265 diff -u -r1.265 readings.html --- readings.html 25 Feb 2017 21:05:42 - 1.265 +++ readings.html 25 Feb 2017 21:09:00 - @@ -94,7 +94,7 @@ Manufacturer: Analog Devices https://blackfin.uclinux.org/doku.php?id=toolchain";>uClinux and GNU toolchains for the Blackfin - http://www.analog.com/en/processors-dsp/blackfin/products/index.html";>Blackfin Documentation + http://www.analog.com/en/products/processors-dsp/blackfin.html";>Blackfin Documentation c4x
Re: [PATCH] Remove x86 pcommit instruction
On Sat, 25 Feb 2017, Gerald Pfeifer wrote: > And here is what I applied for GCC 5. Except that I fixed some things, but failed to remove the duplicate id. Applied as a follow-up. Gerald Index: gcc-5/changes.html === RCS file: /cvs/gcc/wwwdocs/htdocs/gcc-5/changes.html,v retrieving revision 1.144 diff -u -r1.144 changes.html --- gcc-5/changes.html 25 Feb 2017 20:52:55 - 1.144 +++ gcc-5/changes.html 25 Feb 2017 21:14:09 - @@ -1079,7 +1079,7 @@ Target Specific Changes -IA-32/x86-64 +IA-32/x86-64 Support for the https://software.intel.com/en-us/blogs/2016/09/12/deprecate-pcommit-instruction";>deprecated
Re: [wwwdocs] readings.html link maintenance
On Wed, 8 Feb 2017, Rainer Orth wrote: >> - > href="http://www.tru64unix.compaq.com/docs/base_doc/DOCUMENTATION/V51_HTML/SUPPDOCS/OBJSPEC/TITLE.HTM";> >> - Information on the Digital UNIX/Compaq Tru64 UNIX object file >> format >> - > while the HTML link on > http://h41361.www4.hpe.com/docs/pub_page/V51B_DOCS/v51b_doclist.htm is > dangling, the PDF link there is still valid. Ah, thanks! Tru64 UNIX V5.1 was deprecated with 4.7. Is there any version of Tru64 a current release of GCC still supports? In particular if we have support in trunk, I'd restore the bit above with the new link. Gerald
Re: [PATCH] Implement new hook for max_align_t_align
On 2017-02-25, at 12:25 PM, Gerald Pfeifer wrote: > On Wed, 12 Oct 2016, John David Anglin wrote: >>> It's really hard to make an argument to do anything other than deprecate >>> that platform. Given John's ongoing involvement it's much harder to >>> deprecate 64bit linux (and consequently 64bit hpux). >> I believe that deprecating the 32-bit HP-UX platform makes sense. There >> is no HP involvement in hppa, ia64 or alpha open source that I am aware >> of, so deprecating gcc platforms with HP systems is reasonable. >> >> My primary focus is open source and one less platform will free some time. > > Sooo, why not deprecate 32-bit HP-UX with GCC 7? GCC 7 is in reasonable shape on 32-bit HP-UX. I'll do it after it is released. Dave -- John David Anglin dave.ang...@bell.net
Re: [wwwdocs] readings.html link maintenance
Hi Gerald, > On Wed, 8 Feb 2017, Rainer Orth wrote: >>> - >> href="http://www.tru64unix.compaq.com/docs/base_doc/DOCUMENTATION/V51_HTML/SUPPDOCS/OBJSPEC/TITLE.HTM";> >>> - Information on the Digital UNIX/Compaq Tru64 UNIX object file >>> format >>> - >> while the HTML link on >> http://h41361.www4.hpe.com/docs/pub_page/V51B_DOCS/v51b_doclist.htm is >> dangling, the PDF link there is still valid. > > Ah, thanks! > > Tru64 UNIX V5.1 was deprecated with 4.7. Is there any version > of Tru64 a current release of GCC still supports? In particular > if we have support in trunk, I'd restore the bit above with the > new link. no, V5.1B was the last Tru64 UNIX release ever made, so the support is gone completely after 4.7. I've real idea if there's any other target that could profit from ECOFF info (which started on MIPS, I believe). Rainer -- - Rainer Orth, Center for Biotechnology, Bielefeld University
Re: [PATCH] Implement new hook for max_align_t_align
On Sat, 25 Feb 2017, John David Anglin wrote: >> Sooo, why not deprecate 32-bit HP-UX with GCC 7? > GCC 7 is in reasonable shape on 32-bit HP-UX. I'll do it after it is > released. If you deprecate it with GCC 7, it'd be only removed with GCC 8. On the other hand, if you deprecate it past GCC 7, removal would happen with GCC 9 (by default). Gerald
[PATCH] avoid using upper bound of width and precision in -Wformat-overlow (PR 79692)
In an arithmetic directive with the width or precision specified
by an argument to the asterisk (e.g., "%*x") and where the argument
range is unknown, for the purposes of the return value optimization
the pass must assume it's potentially as large as INT_MAX. But for
the purposes of issuing a warning, that assumption leads to false
positives because the value of the argument can and in reality
usually is much smaller.
The attached patch adjusts the checker to use the lower bound in
this case to avoid these false positives. It does that for both
integer and floating directives (for the latter it uses the lesser
of 3 and the lower bound in this case).
In addition, the patch corrects the handling of the pound flag ('#')
in "%#.*g" directives which makes it keep as many trailing zeros after
the radix character as specified by the precision. (Without the '#',
"%.*g" trims trailing zeros.)
Martin
PR middle-end/79692 - [7 Regression] -Wformat-overflow false positive
gcc/ChangeLog:
PR c/79692
* gimple-ssa-sprintf.c
(directive::known_width_and_precision): New function.
(format_integer): Use it.
(get_mpfr_format_length): Consider the full range of precision
when computing %g output with the # flag. Set the likely byte
count to 3 rather than 1 when precision is indeterminate.
(format_floating): Correct the lower bound of precision.
gcc/testsuite/ChangeLog:
PR c/79692
* gcc.dg/tree-ssa/builtin-sprintf-2.c: Add test cases.
* gcc.dg/tree-ssa/builtin-sprintf-warn-10.c: Correct %#g.
* gcc.dg/tree-ssa/builtin-sprintf-warn-15.c: New test.
diff --git a/gcc/gimple-ssa-sprintf.c b/gcc/gimple-ssa-sprintf.c
index 7688439..6777092 100644
--- a/gcc/gimple-ssa-sprintf.c
+++ b/gcc/gimple-ssa-sprintf.c
@@ -692,6 +692,16 @@ struct directive
{
get_int_range (arg, integer_type_node, prec, prec + 1, false, -1);
}
+
+ /* Return true if both width and precision are known to be
+ either constant or in some range, false otherwise. */
+ bool known_width_and_precision () const
+ {
+return ((width[1] < 0
+ || (unsigned HOST_WIDE_INT)width[1] <= target_int_max ())
+ && (prec[1] < 0
+ || (unsigned HOST_WIDE_INT)prec[1] < target_int_max ()));
+ }
};
/* Return the logarithm of X in BASE. */
@@ -1180,10 +1190,10 @@ format_integer (const directive &dir, tree arg)
/* As a special case, a precision of zero with a zero argument
results in zero bytes except in base 8 when the '#' flag is
specified, and for signed conversions in base 8 and 10 when
- flags when either the space or '+' flag has been specified
- when it results in just one byte (with width having the normal
- effect). This must extend to the case of a specified precision
- with an unknown value because it can be zero. */
+ either the space or '+' flag has been specified and it results
+ in just one byte (with width having the normal effect). This
+ must extend to the case of a specified precision with
+ an unknown value because it can be zero. */
res.range.min = ((base == 8 && dir.get_flag ('#')) || maybesign);
if (res.range.min == 0 && dir.prec[0] != dir.prec[1])
{
@@ -1254,10 +1264,12 @@ format_integer (const directive &dir, tree arg)
argmax = wide_int_to_tree (argtype, max);
/* Set KNOWNRANGE if the argument is in a known subrange
- of the directive's type (KNOWNRANGE may be reset below). */
+ of the directive's type and neither width nor precision
+ is unknown. (KNOWNRANGE may be reset below). */
res.knownrange
- = (!tree_int_cst_equal (TYPE_MIN_VALUE (dirtype), argmin)
- || !tree_int_cst_equal (TYPE_MAX_VALUE (dirtype), argmax));
+ = ((!tree_int_cst_equal (TYPE_MIN_VALUE (dirtype), argmin)
+ || !tree_int_cst_equal (TYPE_MAX_VALUE (dirtype), argmax))
+ && dir.known_width_and_precision ());
res.argmin = argmin;
res.argmax = argmax;
@@ -1421,12 +1433,12 @@ get_mpfr_format_length (mpfr_ptr x, const char *flags, HOST_WIDE_INT prec,
HOST_WIDE_INT p = prec;
- if (spec == 'G')
+ if (spec == 'G' && !strchr (flags, '#'))
{
- /* For G/g, precision gives the maximum number of significant
- digits which is bounded by LDBL_MAX_10_EXP, or, for a 128
- bit IEEE extended precision, 4932. Using twice as much
- here should be more than sufficient for any real format. */
+ /* For G/g without the pound flag, precision gives the maximum number
+ of significant digits which is bounded by LDBL_MAX_10_EXP, or, for
+ a 128 bit IEEE extended precision, 4932. Using twice as much here
+ should be more than sufficient for any real format. */
if ((IEEE_MAX_10_EXP * 2) < prec)
prec = IEEE_MAX_10_EXP * 2;
p = prec;
@@ -1609,7 +1621,12 @@ format_floating (const directive &dir)
/* Compute the upper bound for -TYPE_MAX. */
res.range.max = format_floating_max (type, 'f', dir.prec[1]);
- res.range.likely = res.range.min;
+ /* The minimum output with unknown precisi
Re: [PATCH] Implement new hook for max_align_t_align
On 2017-02-25, at 5:32 PM, Gerald Pfeifer wrote: > On Sat, 25 Feb 2017, John David Anglin wrote: >>> Sooo, why not deprecate 32-bit HP-UX with GCC 7? >> GCC 7 is in reasonable shape on 32-bit HP-UX. I'll do it after it is >> released. > > If you deprecate it with GCC 7, it'd be only removed with GCC 8. > > On the other hand, if you deprecate it past GCC 7, removal would > happen with GCC 9 (by default). Exactly. I'm happy with that and don't want to require --enable-obsolete to build GCC 7. Dave -- John David Anglin dave.ang...@bell.net
Re: PR79697: Delete calls to strdup, strndup, realloc if there is no lhs
On 02/25/2017 11:54 AM, Prathamesh Kulkarni wrote:
On 25 February 2017 at 14:43, Marc Glisse wrote:
On Sat, 25 Feb 2017, Prathamesh Kulkarni wrote:
Hi,
The attached patch deletes calls to strdup, strndup if it's
return-value is unused,
and same for realloc if the first arg is NULL.
Bootstrap+tested on x86_64-unknown-linux-gnu.
OK for GCC 8 ?
Instead of specializing realloc(0,*) wherever we can perform the same
optimization as with malloc, wouldn't it be better to optimize:
realloc(0,n) -> malloc(n)
and let the malloc optimizations happen?
Thanks for the suggestions. In the attached patch, realloc (0, n) is
folded to malloc (n).
Bootstrap+test in progress on x86_64-unknown-linux-gnu.
Does the patch look OK ?
Although it's not part of the bug report, I wonder if a complete
patch should also extend the malloc/free DCE to str{,n}dup/free
calls and eliminate pairs like these:
void f (const char *s)
{
char *p = strdup (src);
free (p);
}
(That seems to be just a matter of adding a couple of conditionals
for BUILT_IN_STR{,N}DUP in propagate_necessity).
Martin
PS Another optimization, though one that's most likely outside
the scope of this patch, is to eliminate all of the following:
void f (const char *s, char *s2)
{
char *p = strdup (s);
strcpy (p, s2);
free (p);
}
as is done in:
void f (unsigned n, const char *s)
{
char *p = malloc (n);
memcpy (p, s, n);
free (p);
}
