Re: [PATCH 1/5] x86: Add -mindirect-branch=

On 2018.01.14 at 11:46 +0100, Jan Hubicka wrote: > > gcc/ > > > > * config/i386/i386-opts.h (indirect_branch): New. > > * config/i386/i386-protos.h (ix86_output_indirect_jmp): Likewise. > > * config/i386/i386.c (ix86_using_red_zone): Disallow red-zone > > with local indirect jump

Re: [PATCH] Fix failure building LLVM with location wrapper nodes (PR c++/83799)

On 2018.01.12 at 09:07 +0100, Markus Trippelsdorf wrote: > On 2018.01.11 at 18:21 -0500, David Malcolm wrote: > > diff --git a/gcc/testsuite/g++.dg/wrappers/pr83799.C > > b/gcc/testsuite/g++.dg/wrappers/pr83799.C > > new file mode 100644 > > index 000..f93c0ae >

Re: [PATCH] Fix failure building LLVM with location wrapper nodes (PR c++/83799)

On 2018.01.11 at 18:21 -0500, David Malcolm wrote: > diff --git a/gcc/testsuite/g++.dg/wrappers/pr83799.C > b/gcc/testsuite/g++.dg/wrappers/pr83799.C > new file mode 100644 > index 000..f93c0ae > --- /dev/null > +++ b/gcc/testsuite/g++.dg/wrappers/pr83799.C > @@ -0,0 +1,18 @@ > +class

Re: [PATCH 0/5] x86: CVE-2017-5715, aka Spectre

On 2018.01.07 at 21:07 -0700, Sandra Loosemore wrote: > On 01/07/2018 03:58 PM, H.J. Lu wrote: > > This set of patches for GCC 8 mitigates variant #2 of the speculative > > execution > > vulnerabilities on x86 processors identified by CVE-2017-5715, aka Spectre. > > They > > convert indirect

Re: Announce: GNU MPFR 4.0.0 is released

On 2017.12.25 at 13:27 +0100, Vincent Lefevre wrote: > GNU MPFR 4.0.0 ("dinde aux marrons"), a C library for > multiple-precision floating-point computations with correct rounding, > is now available for download from the MPFR web site: > > http://www.mpfr.org/mpfr-4.0.0/ Unfortunately it is

Re: [PATCH][i386] Correct imul (r64) latency for modern Intel CPUs

On 2017.12.17 at 12:26 +0100, Jan Hubicka wrote: > > Since Nehalem the 64bit multiplication latency is three cycles, not > > four. So update the costs to reflect reality. > > I looked into the imul latencies and was a bit confused, decided to look > into it later and forgot. > > Agner Fog's

[PATCH][i386] Correct imul (r64) latency for modern Intel CPUs

Since Nehalem the 64bit multiplication latency is three cycles, not four. So update the costs to reflect reality. Tested on X86_64. OK for trunk? Thanks. * x86-tune-costs.h (skylake_cost, core_cost): Decrease r64 multiply latencies. * gcc.target/i386/wmul-3.c: New test.

Re: GCC Buildbot Update

On 2017.12.15 at 10:21 +0100, Paulo Matos wrote: > > > On 15/12/17 08:42, Markus Trippelsdorf wrote: > > > > I don't think this is good news at all. > > > > As I pointed out in a reply to Chris, I haven't seeked permission but I > am pretty sure something

Re: GCC Buildbot Update

On 2017.12.14 at 21:32 +0100, Christophe Lyon wrote: > On 14 December 2017 at 09:56, Paulo Matos wrote: > > I got an email suggesting I add some aarch64 workers so I did: > > 4 workers from CF (gcc113, gcc114, gcc115 and gcc116); > > > Great, I thought the CF machines were

[PATCH][i386] Fix PR83358 - increase divide/mod latencies a bit

As the testcase shows, trunk currently generates horrible code for divisions used in tight loops. This happens because the algorithm expanding div/mod doesn't take parallelism into account and this makes the cost model unrealistic. Fix the issue by increasing the estimated latencies a bit. Tested

[PATCH] Fix PR82488 - signed integer overflow in expr.c

bootstrap-ubsan shows: gcc/expr.c:4103:17: runtime error: signed integer overflow: 0 - -9223372036854775808 cannot be represented in type 'long int' Fix by handling the saw_unknown case earlier. bootstrap-ubsan on X86_64 and ppc64le. Tested on ppc64le. OK for trunk? PR

[PATCH] Fix UB in hash-map.h

bootstrap-ubsan shows: gcc/hash-map.h:277:19: runtime error: member access within null pointer of type 'struct hash_map' Fix the issue by returning early. bootstrap-ubsan on X86_64 and ppc64le. Tested on ppc64le. OK for trunk? gcc/ * hash-map.h (gt_cleare_cache): Avoid UB. diff

Re: RFA (hash-map): PATCH to support GTY((cache)) with hash_map

On 2017.11.14 at 13:32 +0100, Richard Biener wrote: > On Fri, Sep 15, 2017 at 11:45 PM, Jason Merrill wrote: > > The hash_map interface is a lot more convenient than that of > > hash_table for cases where it makes sense, but there hasn't been a way > > to get the

Re: Fix IPA profile updates in inlining and ipa-split

On 2017.11.18 at 00:39 +0100, Jan Hubicka wrote: > Hi, > this patch fixes remaining IPA profile updating issues I am aware of. With > this change there is 1 profile mismatch after inlining for tramp3d -Ofast > and 112 of them in .optimized dump which is about 10 times less than before. > I did

Re: Drop frequencies from basic blocks

On 2017.11.07 at 00:12 +0100, Jan Hubicka wrote: > > On 2017.11.05 at 11:55 +0100, Jan Hubicka wrote: > > > > On 2017.11.03 at 16:48 +0100, Jan Hubicka wrote: > > > > > this is updated patch which I have comitted after > > > > > profiledbootstrapping x86-64 > > > > > > > > Unfortunately,

Re: Drop frequencies from basic blocks

On 2017.11.05 at 11:55 +0100, Jan Hubicka wrote: > > On 2017.11.03 at 16:48 +0100, Jan Hubicka wrote: > > > this is updated patch which I have comitted after profiledbootstrapping > > > x86-64 > > > > Unfortunately, compiling tramp3d-v4.cpp is 6-7% slower after this patch. > > This happens with

Re: Drop frequencies from basic blocks

On 2017.11.03 at 16:48 +0100, Jan Hubicka wrote: > this is updated patch which I have comitted after profiledbootstrapping x86-64 Unfortunately, compiling tramp3d-v4.cpp is 6-7% slower after this patch. This happens with an LTO/PGO bootstrapped gcc using --enable-checking=release. On X86_64:

Re: [committed][PATCH] Trivial cleanups to new classes

On 2017.11.02 at 08:55 -0600, Jeff Law wrote: > > As has been discussed on-list. This patch adds a virtual destructor to > the new classes in tree-ssa-propagate.h per our coding conventions and > what are considered best practices. It doesn't matter for any code I'm > aware of today -- it's

Re: [RFC] Make 4-stage PGO bootstrap really working

On 2017.10.27 at 15:03 +0200, Martin Liška wrote: > > And BTW would it make sense to add -gtoggle to stage2 in bootstrap-lto? > > Why do you want to have it there? Am I right that we do not do a stage > comparison with LTO bootstrap? The idea was to trigger -g -flto at least during one stage,

Re: [RFC] Make 4-stage PGO bootstrap really working

On 2017.08.30 at 11:45 +0200, Martin Liška wrote: > diff --git a/Makefile.in b/Makefile.in > index 78db0982ba2..16b76906ad0 100644 > --- a/Makefile.in > +++ b/Makefile.in > @@ -529,13 +529,14 @@ STAGE1_CONFIGURE_FLAGS = --disable-intermodule > $(STAGE1_CHECKING) \ > --disable-coverage

Re: [RFC] Make 4-stage PGO bootstrap really working

On 2017.10.19 at 14:56 +0200, Martin Liška wrote: > PING^2 > So far so good with a small exception: conftest.gcda files that > trigger -Wcoverage-mismatch. Can we remove these before a stage? Do we > do a similar thing somewhere? I think you should simply remove all these conftest.gcda files

Re: [PATCH C++] Fix PR82357 - bogus "cannot bind bitfield" error

On 2017.10.13 at 12:02 -0400, Jason Merrill wrote: > On Fri, Oct 13, 2017 at 5:40 AM, Markus Trippelsdorf > <mar...@trippelsdorf.de> wrote: > > r253266 introduced a bogus "cannot bind bitfield" error that breaks > > building Chromium and Node.js. > > Fix b

[PATCH C++] Fix PR82357 - bogus "cannot bind bitfield" error

r253266 introduced a bogus "cannot bind bitfield" error that breaks building Chromium and Node.js. Fix by removing the ugly goto. Tested on ppc64le. Ok for trunk? Thanks. PR c++/82357 * typeck.c (build_static_cast): Handle processing_template_decl without using goto.

Re: [PATCH] Do not error for no_sanitize attributes (PR sanitizer/82490).

On 2017.10.11 at 09:39 +0200, Jakub Jelinek wrote: > On Wed, Oct 11, 2017 at 08:24:28AM +0200, Martin Liška wrote: > > Hi. > > > > This changes error to a warning: > > warning: ‘foobar’ attribute directive ignored [-Wattributes] > > > > Patch can bootstrap on ppc64le-redhat-linux and survives

Re: GCC Buildbot Update - Definition of regression

On 2017.10.11 at 08:22 +0200, Paulo Matos wrote: > > > On 11/10/17 06:17, Markus Trippelsdorf wrote: > > On 2017.10.10 at 21:45 +0200, Paulo Matos wrote: > >> Hi all, > >> > >> It's almost 3 weeks since I last posted on GCC Buildbot. Here's an update: &g

Re: GCC Buildbot Update - Definition of regression

On 2017.10.10 at 21:45 +0200, Paulo Matos wrote: > Hi all, > > It's almost 3 weeks since I last posted on GCC Buildbot. Here's an update: > > * 3 x86_64 workers from CF are now installed; > * There's one scheduler for trunk doing fresh builds for every Daily bump; > * One scheduler doing

Re: RFC: Update top level libtool files

On 2017.10.10 at 12:45 +0100, Nick Clifton wrote: > Hi Guys, > > I would like to update the top level libtool files (libtool.m4, > ltoptions.m4, ltsugar.m4, ltversion.m4 and lt~obsolete.m4) used by > gcc, gdb and binutils. Currently we have version 2.2.7a installed in > the source trees

Re: GCC Buildbot

On 2017.09.20 at 18:01 -0500, Segher Boessenkool wrote: > Hi! > > On Wed, Sep 20, 2017 at 05:01:55PM +0200, Paulo Matos wrote: > > This mail's intention is to gauge the interest of having a buildbot for > > GCC. > > +1. Or no, +100. > > > - which machines we can use as workers: we certainly

Re: [PATCH] Bump downloaded ISL version to 0.18

On 2017.09.18 at 09:41 +0200, Richard Biener wrote: > > Committed. > > Richard. > > 2017-09-18 Richard Biener > > * download_prerequisites (isl): Bump version to 0.18. > > Index: contrib/download_prerequisites >

Re: [PATCH, i386] Enable option -mprefer-avx256 added for Intel AVX512 configuration

On 2017.09.14 at 14:36 +0200, Jakub Jelinek wrote: > On Thu, Sep 14, 2017 at 12:10:50PM +, Shalnov, Sergey wrote: > > GCC has the option "mprefer-avx128" to use 128-bit AVX registers instead > > of 256-bit AVX registers in the auto-vectorizer. > > > This patch enables the command line option

Re: RFC: Improving GCC8 default option settings

wrote: > >>> On Thu, Sep 14, 2017 at 12:18 PM, Martin Liška <mli...@suse.cz> wrote: > >>>> On 09/14/2017 12:07 PM, Markus Trippelsdorf wrote: > >>>>> On 2017.09.14 at 11:57 +0200, Richard Biener wrote: > >>>>>> On Wed, Se

Re: RFC: Improving GCC8 default option settings

On 2017.09.14 at 11:57 +0200, Richard Biener wrote: > On Wed, Sep 13, 2017 at 6:11 PM, Nikos Chantziaras wrote: > > On 12/09/17 16:57, Wilco Dijkstra wrote: > >> > >> [...] As a result users are > >> required to enable several additional optimizations by hand to get good > >>

Re: [PATCH] Add -static-pie to GCC driver to create static PIE

On 2017.09.12 at 13:48 -0500, Aaron Sawdey wrote: > On Tue, 2017-09-12 at 16:20 +, Joseph Myers wrote: > > On Mon, 28 Aug 2017, H.J. Lu wrote: > > > > > Here is the updated patch.   OK for trunk? > > > > OK. > > This seems to be causing an issue for me on powerpc: > >

Re: Building on gcc112 is stuck in msgfmt

On 2017.08.29 at 15:22 +, Jason Mancini wrote: > Been doing stability testing on my x86_64 Ryzen cpu using openSUSE's > (Tumbleweed) "gcc7.1.1 20170802" + compiling Linux kernel source. > Every so often, the build curiously stalls on a futex between cc1 and > as. cc1 is on the futex. as is

Re: Building on gcc112 is stuck in msgfmt

On 2017.08.29 at 12:53 +0200, Martin Liška wrote: > On 08/29/2017 12:47 PM, Markus Trippelsdorf wrote: > > On 2017.08.29 at 12:42 +0200, Martin Liška wrote: > >> On 08/29/2017 12:39 PM, Martin Liška wrote: > >>> (gdb) bt > >>> #0 0x3fff950e58e4 in

Re: Building on gcc112 is stuck in msgfmt

On 2017.08.29 at 12:42 +0200, Martin Liška wrote: > On 08/29/2017 12:39 PM, Martin Liška wrote: > > (gdb) bt > > #0 0x3fff950e58e4 in syscall () from /lib64/libc.so.6 > > #1 0x3fff94dbbdc4 in __cxxabiv1::__cxa_guard_acquire (g=0x3fff94f26d40 > > >

Re: Segfault generated by gcc-7

On 2017.08.29 at 12:35 +0200, Markus Trippelsdorf wrote: > On 2017.08.29 at 12:31 +0200, Marco Varlese wrote: > > Hi, > > > > I got a SEGFAULT in my program when compiling it with gcc-7 but it > > is/was all good when using gcc-6. > > > > The SEGFAULT hap

Re: Segfault generated by gcc-7

On 2017.08.29 at 12:31 +0200, Marco Varlese wrote: > Hi, > > I got a SEGFAULT in my program when compiling it with gcc-7 but it > is/was all good when using gcc-6. > > The SEGFAULT happens due to the line below: > d_point = *p; > > And a fix for it (with gcc-7) has been: > memcpy(_point, >

Re: Regression with gcc 7.2 ? Undefined references ?

On 2017.08.26 at 17:18 +0200, Sylvestre Ledru wrote: > > > On 26/08/2017 13:10, Markus Trippelsdorf wrote: > > On 2017.08.26 at 13:04 +0200, Sylvestre Ledru wrote: > >> Hello, > >> > >> I have been trying to build the llvm toolchain with gcc 7.2 us

Re: Regression with gcc 7.2 ? Undefined references ?

On 2017.08.26 at 13:04 +0200, Sylvestre Ledru wrote: > Hello, > > I have been trying to build the llvm toolchain with gcc 7.2 using the > Debian packages. > However, it is currently failing with some undefined reference. > Seems that some symbols are removed during the build phase (too strong >

Re: Quantitative analysis of -Os vs -O3

On 2017.08.26 at 12:40 +0200, Allan Sandfeld Jensen wrote: > On Samstag, 26. August 2017 10:56:16 CEST Markus Trippelsdorf wrote: > > On 2017.08.26 at 01:39 -0700, Andrew Pinski wrote: > > > First let me put into some perspective on -Os usage and some history: > > > 1

Re: Quantitative analysis of -Os vs -O3

On 2017.08.26 at 01:39 -0700, Andrew Pinski wrote: > > First let me put into some perspective on -Os usage and some history: > 1) -Os is not useful for non-embedded users > 2) the embedded folks really need the smallest code possible and > usually will be willing to afford the performance hit >

Re: C++ PATCH for c++/81359, Unparsed NSDMI error in SFINAE context

On 2017.08.09 at 14:30 -0400, Jason Merrill wrote: > The issue here is that we try to determine the EH specification of > B::C::C() from within SFINAE context, and we can't determine it yet > because the NSDMI for B::C::i hasn't been parsed yet. This patch > allows that determination to fail

Re: gcc behavior on memory exhaustion

On 2017.08.09 at 14:05 +0100, Andrew Roberts wrote: > I routinely build the weekly snapshots and RC's, on x64, arm and aarch64. > > The last gcc 8 snapshot and the two recent 7.2 RC's have failed to build on > aarch64 (Raspberry Pi 3, running Arch Linux ARM). I have finally traced this > to the

Re: [PATCH] Add -std=c++2a

On 2017.07.20 at 19:04 +0200, Markus Trippelsdorf wrote: > On 2017.07.20 at 09:33 -0400, Andrew Sutton wrote: > > This adds a new C++ dialect, enabled by -std=c++2a. > > > > libcpp/ > > Add support for C++2a. > > * include/cpplib.h

Re: [PATCH] Add -std=c++2a

On 2017.07.20 at 09:33 -0400, Andrew Sutton wrote: > This adds a new C++ dialect, enabled by -std=c++2a. > > libcpp/ > Add support for C++2a. > * include/cpplib.h (c_lang): Add CXX2A and GNUCXX2A. > * init.c (lang_defaults): Add rows for CXX2A and GNUCXX2A. >

Re: Fix ICE in estimate_bb_frequencies

On 2017.07.18 at 09:54 +0200, Jan Hubicka wrote: > Hi, > this patch fixes ICE in estimate_bb_frequencies which triggers because we > forget > to compute probability for blocks whose count is earlier statically > determined to be > 0. > > Bootstrapped/regtested x86_64-linux, will commit it

Re: [PATCH] Speed-up indirect-call instrumentation

On 2017.06.09 at 14:17 +0200, Martin Liška wrote: > Hello. > > I discussed with Honza possibility to speed-up instrumentation that we do for > indirect call target tracking. By direct emission of: > > if (__gcov_indirect_call_callee != NULL) >__gcov_indirect_call_profiler_v2

Re: [PATCH][GCC][PATCHv3] Improve fpclassify w.r.t IEEE like numbers in GIMPLE.

On 2017.01.19 at 18:20 +, Joseph Myers wrote: > On Thu, 19 Jan 2017, Tamar Christina wrote: > > > Hi Joseph, > > > > I made the requested changes and did a quick pass over the rest > > of the fp cases. > > I've no further comments, but watch out for any related test failures > being

Re: [Patch, fortran] PR35339 Optimize implied do loops in io statements

On 2017.06.05 at 22:39 +0200, Nicolas Koenig wrote: > With all the style fixes committed as r248877. 171_swim fails now. I didn't bisect, but I suspect your revision. -- Markus

Re: [PATCH] Introduce 4-stages profiledbootstrap to get a better profile.

On 2017.05.25 at 11:55 +0200, Martin Liška wrote: > Hi. > > As I spoke about the PGO with Honza and Richi, current 3-stage is not ideal > for following > 2 reasons: > > 1) stageprofile compiler is train just on libraries that are built during > stage2 > 2) apart from that, as the compiler is

Re: [PATCH] Introduce 4-stages profiledbootstrap to get a better profile.

On 2017.05.25 at 11:55 +0200, Martin Liška wrote: > Hi. > > As I spoke about the PGO with Honza and Richi, current 3-stage is not ideal > for following > 2 reasons: > > 1) stageprofile compiler is train just on libraries that are built during > stage2 > 2) apart from that, as the compiler is

Re: git-svn error due to out-of-sync changes?

On 2017.05.23 at 05:26 -0400, Aldy Hernandez wrote: > Jason Merrill writes: > > > Yes, the git mirror can lag the SVN repo by a few minutes, that's why > > you need to 'git svn rebase' to pull directly from SVN before a > > commit. > > > > Jason > > Markus just said upthread

Re: git-svn error due to out-of-sync changes?

On 2017.05.18 at 13:42 -0600, Martin Sebor wrote: > On 05/18/2017 12:55 PM, Markus Trippelsdorf wrote: > > On 2017.05.18 at 12:41 -0600, Martin Sebor wrote: > > > On 05/18/2017 11:59 AM, Jeff Law wrote: > > > > On 05/18/2017 11:41 AM, Martin Sebor wrote: > >

Re: git-svn error due to out-of-sync changes?

On 2017.05.18 at 12:41 -0600, Martin Sebor wrote: > On 05/18/2017 11:59 AM, Jeff Law wrote: > > On 05/18/2017 11:41 AM, Martin Sebor wrote: > > > I just tried to push a change and got the error below. git > > > pull says my tree is up to date. I wonder if it's caused by > > > my commit

Re: [PATCH] Add -dB option to disable backtraces

On 2017.05.16 at 19:16 -0700, Andi Kleen wrote: > From: Andi Kleen > > When running creduce on an ICE substantial amounts of the total > CPU time go to backtrace_qsort() (sorting dwarf of the compiler) for > printing the backtrace of the ICE. When running a reduction we

Re: [patch] build xz (instead of bz2) compressed tarballs and diffs

On 2017.05.15 at 16:24 +0200, Jakub Jelinek wrote: > On Mon, May 15, 2017 at 04:13:44PM +0200, Markus Trippelsdorf wrote: > > On 2017.05.15 at 14:02 +, Joseph Myers wrote: > > > The xz manpage warns against blindly using -9 (for which --best is a > > >

Re: [patch] build xz (instead of bz2) compressed tarballs and diffs

On 2017.05.15 at 14:02 +, Joseph Myers wrote: > The xz manpage warns against blindly using -9 (for which --best is a > deprecated alias) because of the implications for memory requirements for > decompressing. If there's a reason it's considered appropriate here, I > think it needs an

Re: [RFC PATCH, i386]: Enable post-reload compare elimination pass

On 2017.05.12 at 21:09 +0200, Uros Bizjak wrote: > On Fri, May 12, 2017 at 8:34 PM, Jeff Law wrote: > > On 05/10/2017 01:05 PM, Uros Bizjak wrote: > >> > >> On Wed, May 10, 2017 at 5:18 PM, Uros Bizjak wrote: > >>> > >>> On Wed, May 10, 2017 at 4:27 PM, Jakub

Re: Missing git tags for released GCC

On 2017.05.03 at 09:30 +0200, Martin Liška wrote: > Can you someone add 7.1 release to git tags. I guess it's following revision: > f9105a38249fb57f7778acf3008025f2dcac2b1f Everyone can add it: % git tag gcc-7_1_0-release f9105a38249fb57f7778acf3008025f2dcac2b1f % git push origin

Re: Machine problems at gcc.gnu.org?

On 2017.04.21 at 09:17 -0700, Steve Ellcey wrote: > > I am having problems getting to https://gcc.gnu.org this morning and > I have also had problems getting to the glibc mail archives though the > main web page for glibc seem available. Anyone else having problems? > Of course if this email

Re: [PATCH, i386]: Fix PR79804, ICE in print_reg

On 2017.04.20 at 22:29 +0200, Uros Bizjak wrote: > > PR target/79804 > * gcc.target/i386/pr79804.c: New test. > > Bootstrapped and regression tested on x86_64-linux-gnu {,-m32}. > > Committed to mainline SVN. > --- testsuite/gcc.target/i386/pr79804.c (nonexistent) > +++

Re: [P1] [PATCH] [PR tree-optimization/80374] Do not try to convert integer_zero_node to undesirable types

On 2017.04.10 at 13:20 -0600, Jeff Law wrote: > > fold_convert can fail for certain types. It can fail either by returning a > error_mark_node or triggering a gcc_assert depending on the exact situation. > > Both are problematical. This patch checks that we can convert > integer_zero_node to

Re: [RFA] update ggc_min_heapsize_heuristic()

On 2017.04.10 at 13:14 +0100, Richard Earnshaw (lists) wrote: > On 10/04/17 12:06, Segher Boessenkool wrote: > > On Mon, Apr 10, 2017 at 12:52:15PM +0200, Markus Trippelsdorf wrote: > >>> --param ggc-min-heapsize=131072 > >>> 11264.89user 311.88system 24:18.69e

Re: [RFA] update ggc_min_heapsize_heuristic()

On 2017.04.10 at 12:15 +0200, Markus Trippelsdorf wrote: > On 2017.04.10 at 10:56 +0100, Richard Earnshaw (lists) wrote: > > > > What are the numbers with 256M? > > Here are the numbers from a 4core/8thread 16GB RAM Skylake machine. > They look less stellar than the p

Re: [RFA] update ggc_min_heapsize_heuristic()

On 2017.04.10 at 10:56 +0100, Richard Earnshaw (lists) wrote: > On 09/04/17 21:06, Markus Trippelsdorf wrote: > > On 2017.04.09 at 21:10 +0200, Markus Trippelsdorf wrote: > >> On 2017.04.09 at 21:25 +0300, Alexander Monakov wrote: > >>> On Sun, 9 Apr 2

Re: [RFA] update ggc_min_heapsize_heuristic()

On 2017.04.09 at 21:10 +0200, Markus Trippelsdorf wrote: > On 2017.04.09 at 21:25 +0300, Alexander Monakov wrote: > > On Sun, 9 Apr 2017, Markus Trippelsdorf wrote: > > > > > The minimum size heuristic for the garbage collector's heap, before it > > > starts coll

Re: [RFA] update ggc_min_heapsize_heuristic()

On 2017.04.09 at 20:23 +0200, Richard Biener wrote: > On Sun, Apr 9, 2017 at 4:41 PM, Markus Trippelsdorf > <mar...@trippelsdorf.de> wrote: > > The minimum size heuristic for the garbage collector's heap, before it > > starts collecting, was last updated over ten years a

Re: [RFA] update ggc_min_heapsize_heuristic()

On 2017.04.09 at 21:25 +0300, Alexander Monakov wrote: > On Sun, 9 Apr 2017, Markus Trippelsdorf wrote: > > > The minimum size heuristic for the garbage collector's heap, before it > > starts collecting, was last updated over ten years ago. > > It currently has a h

[RFA] update ggc_min_heapsize_heuristic()

The minimum size heuristic for the garbage collector's heap, before it starts collecting, was last updated over ten years ago. It currently has a hard upper limit of 128MB. This is too low for current machines where 8GB of RAM is normal. So, it seems to me, a new upper bound of 1GB would be

Re: [PATCH] Fix PR80281

On 2017.04.03 at 15:20 +0200, Richard Biener wrote: > I'm re-testing the following variant. > > Richard. > > 2017-04-03 Richard Biener > > PR middle-end/80281 > * match.pd (A + (-B) -> A - B): Make sure to preserve unsigned > arithmetic done for the

[C++ PATCH] Fix PR80294 -- Segfault in constexpr.c (reduced_constant_expression_p)

As the testcase shows, elt can become a NULL tree during FOR_EACH_CONSTRUCTOR_VALUE. So guard against this possibility before calling reduced_constant_expression_p() recursively. Tested on ppc64le. OK for trunk? PR c++/80294 * constexpr.c (reduced_constant_expression_p): Guard

Re: [PATCH] Fix PR80275

On 2017.04.03 at 11:16 +0200, Richard Biener wrote: > > The following extends split_address_to_core_and_offset to handle > POINTER_PLUS_EXPR to be able to simplify > (unsigned long) [(void *) + 12B] - (unsigned long) ((const int > *) + 4) which appears during niter analysis. > > We seem to

Re: [PATCH] gcc 8: Implement -felide-function-bodies

On 2017.04.01 at 01:00 -0400, David Malcolm wrote: > The following patch implements a new function-body-elision > optimization, which can dramatically improve performance, > especially under certain benchmarks. > > gcc/ChangeLog: > * common.opt (felide-function-bodies): New option. >

Re: [PATCH][RFC] Fix P1 PR77498

On 2017.03.31 at 11:16 +0200, Richard Biener wrote: > On Fri, 31 Mar 2017, Richard Biener wrote: > > > On Fri, 31 Mar 2017, Rainer Orth wrote: > > > > > Hi Christophe, > > > > > > > With this patch, the following testcase now fails on arm* targets: > > > > gcc.dg/tree-ssa/pr71347.c

[PATCH committed] avoid name lookup warning in tree.c

In stage1 with -std=gnu++98 I see: /home/markus/gcc/gcc/tree.c: In function ‘void inchash::add_expr(const_tree, inchash::hash&, unsigned int)’: /home/markus/gcc/gcc/tree.c:8013:11: warning: name lookup of ‘i’ changed for (i = TREE_OPERAND_LENGTH (t) - 1; i >= 0; --i) ^

Re: Warning annoyances in list_read.c

On 2017.03.27 at 06:49 -0700, Steve Kargl wrote: > On Mon, Mar 27, 2017 at 02:36:27PM +0100, Jonathan Wakely wrote: > > On 27 March 2017 at 14:26, Steve Kargl wrote: > > > I completely disagree with your viewpoint here. If someone turns > > > on a silly warning, that someone should fix all places

Re: Warning annoyances in list_read.c

On 2017.03.27 at 07:44 -0700, Steve Kargl wrote: > On Mon, Mar 27, 2017 at 03:39:37PM +0200, Markus Trippelsdorf wrote: > > > > Well, a missing break is a bug. No? > > Every 'case' statement without exception must be accompanied by > a 'break' statement? Wasting other

Re: Warning annoyances in list_read.c

On 2017.03.27 at 06:26 -0700, Steve Kargl wrote: > On Mon, Mar 27, 2017 at 08:58:43AM +0200, Markus Trippelsdorf wrote: > > On 2017.03.26 at 19:30 -0700, Steve Kargl wrote: > > > On Sun, Mar 26, 2017 at 06:45:07PM -0700, Jerry DeLisle wrote: > > > > On 03/26/20

Re: Warning annoyances in list_read.c

On 2017.03.26 at 19:30 -0700, Steve Kargl wrote: > On Sun, Mar 26, 2017 at 06:45:07PM -0700, Jerry DeLisle wrote: > > On 03/26/2017 11:45 AM, Steve Kargl wrote: > > > On Sun, Mar 26, 2017 at 11:27:59AM -0700, Jerry DeLisle wrote: > > >> > > >> +#pragma GCC diagnostic push > > >> +#pragma GCC

[PATCH] Fix PR80183 : _M_color not moved

clang-format stopped working when compiled with gcc-7. It turned out that an uninitialized _M_color is responsible. The fix is easy, just copy _M_color in the move case, too. Tested on ppc64le. OK for trunk? Thanks. PR libstdc++/80183 * include/bits/stl_tree.h:

[PATCH] Fix memory leak in identify_jump_threads()

Valgrind shows: ==553== 391,488 bytes in 24 blocks are possibly lost in loss record 4,339 of 4,342 ==553==at 0x4030C15: calloc (vg_replace_malloc.c:711) ==553==by 0x1607CA0: xcalloc (xmalloc.c:162) ==553==by 0x1004A81: data_alloc (hash-table.h:263) ==553==by 0x1004A81:

Re: C++ backports to 6

On 2017.03.14 at 17:08 +0100, Marek Polacek wrote: > I've backported the attached patches gcc-6. The PR79264 backport caused: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80091 -- Markus

Re: patch, libfortran] [patch, fortran] Fix PR 79956, part two, attempt 3

On 2017.03.15 at 00:01 +0100, Thomas Koenig wrote: > Hello world, > > well, here is the third attempt at fixing the second part of the PR. > Glancing over the source, I think there are quite a few places where > we currently issue a runtime error which we could replace by an > assert, but that's

Re: [PATCH] Remove dead stores and initializations

On 2017.03.16 at 14:40 +0100, Bernd Schmidt wrote: > On 03/16/2017 01:31 PM, Markus Trippelsdorf wrote: > > clang --analyze pointed out a number of dead stores and initializations. > > > > Tested on ppc64le. Ok for trunk? > > I'd say - not now. > > Ideally so

[PATCH] Remove dead stores and initializations

clang --analyze pointed out a number of dead stores and initializations. Tested on ppc64le. Ok for trunk? Thanks. gcc/c-family/ChangeLog: * c-ada-spec.c (to_ada_name): Remove dead store. gcc/c/ChangeLog: * c-array-notation.c (build_array_notation_expr): Remove dead stores.

Re: [patch, libfortran] [patch, fortran] Fix PR 79956, part two, attempt 2

On 2017.03.13 at 23:24 +0100, Thomas Koenig wrote: > Hello world, > > Following Richard's suggestion, I have implemented the GFC_ASSERT macro > and used it to (hopefully) silence the ominous warning and allow > further optimization. Unfortunately the single GFC_ASSERT isn't enough:

Re: [PATCH] libiberty: Initialize d_printing in all cplus_demangle_* functions.

On 2017.03.12 at 23:05 +0100, Mark Wielaard wrote: > While integrating the d_printing recursion guard change into gdb I > noticed we forgot to initialize the demangle_component d_printing > field in cplus_demangle_fill_{name,extended_operator,ctor,dtor}. > As is done in

[RFC PATCH libiberty] Fix infinite recursion in demangler

The following patch from Mark Wielaard fixes many (all?) open demangler bugs that happen because we overflow the stack due to infinite recursion. I'm not sure why Mark didn't post the patch himself. Anyway here it is. Any comments? Thanks. diff --git a/include/demangle.h b/include/demangle.h

Re: [wwwdocs] Add a case to porting_to + a question wrt validity of another one

On 2017.02.08 at 13:56 +0100, Marek Polacek wrote: > On Wed, Feb 08, 2017 at 12:54:44PM +0100, Markus Trippelsdorf wrote: > > On 2017.02.08 at 12:05 +0100, Marek Polacek wrote: > > > On Tue, Feb 07, 2017 at 04:17:48PM -0500, Jason Merrill wrote: > > > > On Tue, Fe

Re: [wwwdocs] Add a case to porting_to + a question wrt validity of another one

On 2017.02.08 at 12:05 +0100, Marek Polacek wrote: > On Tue, Feb 07, 2017 at 04:17:48PM -0500, Jason Merrill wrote: > > On Tue, Feb 7, 2017 at 9:13 AM, Jonathan Wakely wrote: > > > On 07/02/17 15:04 +0100, Marek Polacek wrote: > > >> > > >> Thanks much for the review. Looks

Re: [wwwdocs] Add a case to porting_to + a question wrt validity of another one

On 2017.02.06 at 18:13 +0100, Marek Polacek wrote: > This patch adds a description of something I noticed while doing the > Fedora mass rebuild. Do we want to say more about the invalidity of > the incomplete type case? > + > +GCC 7 no longer accepts ill-formed code involving use of an

Re: gcc.css colors

On 2017.02.01 at 12:41 +0100, Jakub Jelinek wrote: > Hi! > > On Wed, Feb 01, 2017 at 12:27:05PM +0100, Markus Trippelsdorf wrote: > > > I've tried various color settings of gnome-terminal (both white on black > > > and > > > black on white plus the differen

Re: gcc.css colors

On 2017.02.01 at 12:14 +0100, Jakub Jelinek wrote: > On Wed, Feb 01, 2017 at 11:55:53AM +0100, Markus Trippelsdorf wrote: > > On 2017.02.01 at 11:48 +0100, Jakub Jelinek wrote: > > > On Wed, Feb 01, 2017 at 11:45:14AM +0100, Markus Trippelsdorf wrote: > > >

Re: gcc.css colors

On 2017.02.01 at 11:48 +0100, Jakub Jelinek wrote: > On Wed, Feb 01, 2017 at 11:45:14AM +0100, Markus Trippelsdorf wrote: > > Some colors on e.g. https://gcc.gnu.org/gcc-7/changes.html are nearly > > unreadable. So what about the following patch? > > > > --- gcc_o

gcc.css colors

Some colors on e.g. https://gcc.gnu.org/gcc-7/changes.html are nearly unreadable. So what about the following patch? --- gcc_orig.css2017-02-01 11:39:17.634017498 +0100 +++ gcc.css 2017-02-01 11:40:23.979244263 +0100 @@ -58,8 +58,8 @@ } div.copyright p:nth-child(3) { margin-bottom:

Re: [PATCH 5/5] add support for width and precision ranges (PR 78703)

On 2017.01.27 at 08:45 -0700, Martin Sebor wrote: > On 01/27/2017 12:44 AM, Markus Trippelsdorf wrote: > > On 2017.01.22 at 16:53 -0700, Martin Sebor wrote: > > > This is the last patch in the series. It adds logic to handle > > > non-constant width and precision wit

Re: [PATCH committed] Fix build failure with MPFR 2.4.x (gimple-ssa-sprintf.c)

On 2017.01.27 at 08:41 +0100, Rainer Orth wrote: > Hi Martin, > > > On 01/24/2017 02:37 AM, Markus Trippelsdorf wrote: > >> MPFR_RNDx was introduced in MPFR 3.0.0. Since the minimal version that > >> gcc checks for is 2.4.0, this leads to a build failure. > &

Re: [PATCH 5/5] add support for width and precision ranges (PR 78703)

On 2017.01.22 at 16:53 -0700, Martin Sebor wrote: > This is the last patch in the series. It adds logic to handle > non-constant width and precision with range information to help > reduce both false positives false negatives. The patch replaces > the scalar width and precision with two element

Re: Unable to create an account at gcc/bugzilla

On 2017.01.25 at 15:43 +0200, Oren Twaig wrote: > Hi, > > I would like to report a bug in GCC. However, can't create a user in > the bug report system. > Any suggestions? > > Here are some more details: > > i can't create a new account here: > https://gcc.gnu.org/bugzilla/createaccount.cgi > >

  1   2   3   4   5   >