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 wh
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
>
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 DataLayo
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 bra
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 table
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.
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
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 rtl-optimizatio
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 --git
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 ggc_cache_remove behavior with a h
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 not
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, compiling
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 a
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:
Bef
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 a
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, jus
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 --en
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 befo
On 2017.10.13 at 12:02 -0400, Jason Merrill wrote:
> On Fri, Oct 13, 2017 at 5:40 AM, Markus Trippelsdorf
> wrote:
> > r253266 introduced a bogus "cannot bind bitfield" error that breaks
> > building Chromium and Node.js.
> > Fix by removing the ugly goto.
>
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.
diff
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 reg
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
> ===
> ---
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 "
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:
>
> ../../trunk/gcc/config
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 quiet
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
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.
>
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 shortl
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 (profile
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 reporte
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
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 al
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 also
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 don't need the
> backtrace
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
> > > depre
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 expla
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 Jelinek wrote:
>
> On Tue,
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)
> +++ testsuite/g
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 th
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 negate or the plus. Simp
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 aga
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) &MEM[(void *)&D.15512 + 12B] - (unsigned long) ((const int
> *) &D.15512 + 4) which appears during niter analysis.
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 scan-tree-dum
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)
^
/home/mark
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:
(_Rb_tree
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: alloc_entri
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
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 s
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.
>
> Ideal
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.
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:
libgfortran/i
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 cplus_demangle_fill_{compone
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
inde
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
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 ok now?
> >
> > I'd s
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 incomplete
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 dif
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:
> > >
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
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: 0
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
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.
> &
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 a
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.
The fix is straightforward.
Tested on x86_64-pc-linux-gnu. Committed to trunk as obvious.
* gimple-ssa-sprintf.c (format_floating): Change MPFR_RNDx to
On 2017.01.22 at 17:20 +0100, Gerald Pfeifer wrote:
> On Sun, 1 Jan 2017, Gerald Pfeifer wrote:
> > When I updated those URLs in June 2015, I must have missed these
> > references in libstdc++ land.
> >
> > Fixed thusly (via revision 244001), and I plan on backporting to
> > GCC 6 and possibly GC
On 2017.01.20 at 15:27 +0100, Jakub Jelinek wrote:
> On Fri, Jan 20, 2017 at 03:08:21PM +0100, Martin Liška wrote:
> > Unfortunately this way would not work as clobber marks content of the
> > memory as uninitialize
> > is different behavior that just marking a memory can be used (and maybe
> > a
On 2017.01.18 at 16:25 +0100, Jakub Jelinek wrote:
> On Wed, Jan 18, 2017 at 04:16:44PM +0100, Markus Trippelsdorf wrote:
> > No. It appears to work even without the additional condition:
> >
> > % g++ -fabi-version=10 -Wabi=11 -Wall -c gcc/testsuite/g++.dg/abi/pr77489.C
>
On 2017.01.18 at 10:03 -0500, Jason Merrill wrote:
> On Wed, Jan 18, 2017 at 9:23 AM, Markus Trippelsdorf
> wrote:
> > On 2017.01.18 at 09:11 -0500, Jason Merrill wrote:
> >> On Wed, Jan 18, 2017 at 3:55 AM, Markus Trippelsdorf
> >> wrote:
> >> > On 2017
On 2017.01.18 at 09:11 -0500, Jason Merrill wrote:
> On Wed, Jan 18, 2017 at 3:55 AM, Markus Trippelsdorf
> wrote:
> > On 2017.01.17 at 13:26 -0500, Jason Merrill wrote:
> >> On Thu, Jan 12, 2017 at 2:36 AM, Markus Trippelsdorf
> >> wrote:
> >
On 2017.01.18 at 09:55 +0100, Markus Trippelsdorf wrote:
> index cac3d8bc65e9..767c8f42fee9 100644
> --- a/gcc/doc/invoke.texi
> +++ b/gcc/doc/invoke.texi
> @@ -2252,7 +2252,9 @@ attributes that affect type identity, such as ia32
> calling convention
> attributes (
On 2017.01.17 at 13:26 -0500, Jason Merrill wrote:
> On Thu, Jan 12, 2017 at 2:36 AM, Markus Trippelsdorf
> wrote:
> > On 2017.01.11 at 13:03 +0100, Jakub Jelinek wrote:
> >> On Wed, Jan 11, 2017 at 12:48:29PM +0100, Markus Trippelsdorf wrote:
> >> > @@ -1965,
On 2017.01.11 at 08:21 -0500, Nathan Sidwell wrote:
> On 01/11/2017 08:16 AM, Markus Trippelsdorf wrote:
>
> > --- a/gcc/cp/mangle.c
> > +++ b/gcc/cp/mangle.c
> > @@ -2813,6 +2813,8 @@ write_template_args (tree args)
> > static void
> > write_member
On 2017.01.11 at 13:03 +0100, Jakub Jelinek wrote:
> On Wed, Jan 11, 2017 at 12:48:29PM +0100, Markus Trippelsdorf wrote:
> > @@ -1965,7 +1966,11 @@ write_discriminator (const int discriminator)
> >if (discriminator > 0)
> > {
> >w
The ABI says:
::= [gs]
::= sr
::= srN + E
::= [gs] sr + E
::=
::= on
::= on
::= dn int f ();
diff --git a/gcc/testsuite/g++.dg/abi/mangle37.C
b/gcc/testsuite/g++.dg/abi/mangle37.C
index 691566b384ba..4dd87e84c108 100644
--- a/gcc/testsuite/g++.dg/abi/mangle3
Currently gcc mangles symbols wrongly when the discriminator is greater
than ten. The fix is straightforward. The demangler now handles both the
old and the new correct mangling.
Tested on ppc64le. OK for trunk?
Thanks.
libiberty:
PR c++/77489
* cp-demangle.c (d_discriminator):
On 2016.12.23 at 14:25 -0700, Martin Sebor wrote:
> Bug 78703 points out that the decimal point character in floating
> directives can be longer than just one byte (in locales where the
> decimal point is a multibyte character). The decimal point can
> result in anywhere between 1 and MB_LEN_MAX b
On 2016.12.19 at 09:34 -0700, Martin Sebor wrote:
> On 12/19/2016 09:17 AM, Jakub Jelinek wrote:
> > Or apply the patch I've posted which doesn't suffer from this problem,
> > or revert the -Wnonnull changes and resolve somehow in GCC 8.
>
> I would prefer your patch if it solves the problem. In
On 2016.12.16 at 18:27 +0100, Jakub Jelinek wrote:
> On Fri, Dec 16, 2016 at 10:10:00AM -0700, Martin Sebor wrote:
> > > No. The first call to sm_read_sector just doesn't exit. So it is warning
> > > about dead code.
> >
> > If the code is dead then GCC should eliminate it. With it eliminated
>
On 2016.12.16 at 11:07 -0700, Martin Sebor wrote:
> On 12/16/2016 10:27 AM, Jakub Jelinek wrote:
> > On Fri, Dec 16, 2016 at 10:10:00AM -0700, Martin Sebor wrote:
> > > > No. The first call to sm_read_sector just doesn't exit. So it is
> > > > warning
> > > > about dead code.
> > >
> > > If the
On 2016.12.15 at 19:27 -0700, Martin Sebor wrote:
> On 12/14/2016 09:19 PM, Jeff Law wrote:
> > On 12/14/2016 03:56 PM, Martin Sebor wrote:
> > > The -Wnonnull warning improvement (PR c/17308 - nonnull attribute
> > > not as useful as it could be) causes a couple of false positives
> > > in a power
An -fsanitize=undefined instrumented compiler shows:
cp/parser.c:768:7: runtime error: member call on null pointer of type 'struct
vec'
760 static inline cp_token *
761 cp_lexer_previous_token (cp_lexer *lexer)
762 {
763 cp_token_position tp = cp_lexer_previous_token_position (lexer);
On 2016.11.30 at 08:17 +0100, Thomas Koenig wrote:
> Hello world,
>
> the patch at https://gcc.gnu.org/ml/fortran/2016-11/msg00246.html
> (the one going to gcc-patches was rejected due to size of
> regernerated files) contains one libgcc change, which exposes
> the __cpu_model interface fox i386 t
Using bootstrap-ubsan gcc to build mplayer shows:
tree-ssa-loop-prefetch.c:835:16: runtime error: signed integer overflow:
288230376151711743 * 64 cannot be represented in type 'long int'
Here signed und unsigned integers are mixed in a division resulting in
bogus results: (-83 + 64ULL -1) / 64UL
Hopefully one last patch for UB in combine.c:
combine.c:12561:14: runtime error: left shift of negative value -9
Fixed by casting to unsigned, as usual.
Tested on ppc64le.
OK for trunk?
Thanks.
PR rtl-optimization/78596
* combine.c (simplify_comparison): Cast to unsigned to av
On 2016.11.30 at 14:06 -0500, Nathan Sidwell wrote:
> This patch fixes a problem in libiberty's symbol demangler. With a
> templated forwarding function such as std::forward, we can end up emitting
> mangled function names that encode lambda information. Lambdas with auto
> argument types have a
On 2016.12.01 at 08:11 +0200, Ville Voutilainen wrote:
> On 1 December 2016 at 07:38, Markus Trippelsdorf
> wrote:
> > It breaks building Firefox:
>
> Sigh, when writing a trait, write a proper trait. Does this patch fix
> the problem?
Yes it does. Thank you.
--
Markus
On 2016.11.30 at 16:25 +, Jonathan Wakely wrote:
> On 30/11/16 17:58 +0200, Ville Voutilainen wrote:
> >Fix testsuite failures caused by the patch implementing LWG 2534.
> >* include/std/istream (__is_convertible_to_basic_istream):
> >Change the return types of __check, introduce st
bootstrap-ubsan gcc shows:
gcc/real.c:2890:25: runtime error: left shift of negative value -125
Fixed by casting to unsigned.
Tested on ppc64le. Committed as obvious.
PR ipa/78555
* real.c (real_hash): Add cast to avoid left
shifting of negative values.
diff --git a/gcc/re
On 2016.11.29 at 15:25 -0600, Segher Boessenkool wrote:
> On Tue, Nov 29, 2016 at 05:00:05PM +0100, Markus Trippelsdorf wrote:
> > Building gcc with -fsanitize=undefined shows:
> > rtlanal.c:5210:38: runtime error: shift exponent 4294967295 is too large
> > for 64-bit ty
Here is v2 of the fix.
Building gcc with -fsanitize=undefined shows:
rtlanal.c:5210:38: runtime error: shift exponent 4294967295 is too large for
64-bit type 'long unsigned int'
This happens because if_then_else_cond() in combine.c calls
num_sign_bit_copies() in rtlanal.c with mode==BLKmode.
5
On 2016.11.29 at 16:01 +0100, Markus Trippelsdorf wrote:
> On 2016.11.29 at 15:21 +0100, Markus Trippelsdorf wrote:
> > On 2016.11.29 at 15:14 +0100, Jakub Jelinek wrote:
> > > On Tue, Nov 29, 2016 at 03:08:15PM +0100, Markus Trippelsdorf wrote:
> > > > Building gcc w
On 2016.11.29 at 15:21 +0100, Markus Trippelsdorf wrote:
> On 2016.11.29 at 15:14 +0100, Jakub Jelinek wrote:
> > On Tue, Nov 29, 2016 at 03:08:15PM +0100, Markus Trippelsdorf wrote:
> > > Building gcc with -fsanitize=undefined shows:
> > > rtlanal.c:5210:38: ru
On 2016.11.29 at 15:14 +0100, Jakub Jelinek wrote:
> On Tue, Nov 29, 2016 at 03:08:15PM +0100, Markus Trippelsdorf wrote:
> > Building gcc with -fsanitize=undefined shows:
> > rtlanal.c:5210:38: runtime error: shift exponent 4294967295 is too
> > large for 64-bit ty
Building gcc with -fsanitize=undefined shows:
rtlanal.c:5210:38: runtime error: shift exponent 4294967295 is too
large for 64-bit type 'long unsigned int'
5210 return nonzero & (HOST_WIDE_INT_1U << (bitwidth - 1))
5211 ? 1 : bitwidth - floor_log2 (nonzero) - 1;
Here (bitwidth - 1) wr
On 2016.11.28 at 12:02 -0600, Segher Boessenkool wrote:
> Hi Markus,
>
> On Mon, Nov 28, 2016 at 02:58:19PM +0100, Markus Trippelsdorf wrote:
> > Running bootstrap-ubsan on ppc64le shows many instances of e.g.:
> > config/rs6000/rs6000.c:6217:36: runtime error: left shift o
Running bootstrap-ubsan on ppc64le shows many instances of e.g.:
config/rs6000/rs6000.c:6217:36: runtime error: left shift of negative value
-12301
The attached patch fixes the issue and was tested on ppc64le.
OK for trunk?
Thanks.
PR target/78556
* config/rs6000/rs6000.h (vsp
On 2016.11.22 at 20:02 -0700, Martin Sebor wrote:
>
> gcc/ChangeLog:
>
> PR tree-optimization/78476
> * gimple-ssa-sprintf.c (struct pass_sprintf_length::call_info):
> Add a member.
> (handle_gimple_call): Adjust signature.
> (try_substitute_return_value): Remove cal
On 2016.11.18 at 10:27 -0600, Bill Schmidt wrote:
> ===
> --- gcc/testsuite/gcc.dg/tree-ssa/pr78413.c (revision 0)
> +++ gcc/testsuite/gcc.dg/tree-ssa/pr78413.c (working copy)
> @@ -0,0 +1,35 @@
> +/* PR78413. These previously fai
When one uses ld.gold to build gcc, the thread sanitizer doesn't work,
because gold is more conservative when applying TLS relaxations than
ld.bfd. In this case a missing initial-exec attribute on a declaration
causes gcc to assume the general dynamic model. With ld.bfd this gets
relaxed to initial
On 2016.11.03 at 14:57 +0100, Jakub Jelinek wrote:
> On Thu, Nov 03, 2016 at 02:55:03PM +0100, Markus Trippelsdorf wrote:
> > On 2016.11.03 at 14:47 +0100, Jakub Jelinek wrote:
> > > On Thu, Nov 03, 2016 at 02:35:57PM +0100, Markus Trippelsdorf wrote:
> > > >
1 - 100 of 392 matches
Mail list logo