On Sun, Mar 12, 2017 at 11:45 PM, Gerald Pfeifer wrote:
> On Wed, 24 Aug 2016, Richard Biener wrote:
>> We've been creating those lazily over the last decade. We can change
>> that, an entry for releasing.html is appreciated then so we don't forget.
>
> And here we go, in time for the release of
On Mon, Mar 13, 2017 at 2:13 AM, Martin Sebor wrote:
> r243470 decorates standard allocation functions like alloca
> and malloc with attribute alloc_size. However, in applying
> the attribute to aligned_alloc I had overlooked that the size
> argument is the second one and not the first. That ove
On Fri, Mar 10, 2017 at 11:34 PM, Alexandre Oliva wrote:
> On Mar 10, 2017, Alexandre Oliva wrote:
>
>> Now, if there's something you dislike about maps, we could make it a
>> doubly-linked list, or maybe even a singly-linked list.
I indeed mis-matched std::map for hash_map but I also think we s
On Sun, Mar 12, 2017 at 10:46 PM, Janne Blomqvist
wrote:
> On Sun, Mar 12, 2017 at 7:26 PM, NightStrike wrote:
>> On Mon, Feb 27, 2017 at 6:15 AM, Janne Blomqvist
>> wrote:
>>> Don't try to use rand_s on CYGWIN
>>>
>>> CYGWIN seems to include _mingw.h and thus __MINGW64_VERSION_MAJOR is
>>> defi
On 10/03/17 23:36, David Malcolm wrote:
On Fri, 2017-03-10 at 09:24 +, Kyrill Tkachov wrote:
On 10/03/17 06:24, Jakub Jelinek wrote:
On Thu, Mar 09, 2017 at 12:45:25PM -0500, David Malcolm wrote:
gcc/ChangeLog:
PR translation/79923
* auto-profile.c (get_combined_location):
Built on x86_64-unknown-linux-gnu, applied.
Richard
2017-03-13 Richard Biener
PR other/79991
* params.def (vect-max-peeling-for-alignment): Fix typo.
Index: gcc/params.def
===
--- gcc/params.def (revision 2
On 12/03/17 11:31, Gerald Pfeifer wrote:
On Sun, 12 Mar 2017, Gerald Pfeifer wrote:
Also, I'm offering help around one particular aspect I noticed:
References to dependencies on really, really old versions of
binutils (talking 10+ years here) which I think we can remove.
Let me follow-up with
On 08/03/17 10:34, Kyrill Tkachov wrote:
> Hi all,
>
> This patch fixes the NEON patterns with Jakub's genrecog verification
> improvements:
> ../../gcc/config/arm/neon.md:1338:1: element mode mismatch between
> vec_select HImode and its operand QImode
> ../../gcc/config/arm/neon.md:1338:1: elemen
2017-03-12 15:32 GMT+04:00 Gerald Pfeifer :
> On Sun, 12 Mar 2017, Gerald Pfeifer wrote:
>> Also, I'm offering help around one particular aspect I noticed:
>>
>> References to dependencies on really, really old versions of
>> binutils (talking 10+ years here) which I think we can remove.
>> Let me
Hi Guys,
>>> References to dependencies on really, really old versions of
>>> binutils (talking 10+ years here) which I think we can remove.
>>ARM-family processors. Subtargets that use the ELF object format
>>require GNU binutils 2.13 or newer. Such subtargets include:
>> Okay to yank
The resolution to DR 1658 causes vbases of abstract classes to be
ignored when building the cdtors. That made sense for ctors, when there
might be no default ctor available. But for dtors, there is only oe
dtor and they can be virtual. That can break virtual overriding, as
79393 discovered.
On Thu, Mar 9, 2017 at 12:40 PM, Martin Liška wrote:
> On 03/08/2017 12:00 PM, Richard Biener wrote:
>> On Tue, Mar 7, 2017 at 5:01 PM, Martin Liška wrote:
>>> On 03/07/2017 03:53 PM, Richard Biener wrote:
On Tue, Mar 7, 2017 at 3:48 PM, Martin Liška wrote:
> On 03/07/2017 11:17 AM, Rai
On Thu, Mar 9, 2017 at 3:19 PM, Martin Liška wrote:
> Hello.
>
> Following patch fixes issue by checking original declaration instead
> of instrumentation clone.
>
> Patch can bootstrap on x86_64-linux-gnu and survives regression tests.
>
> Ready to be installed?
Ok.
RIchard.
> Martin
On Fri, 10 Mar 2017, Martin Jambor wrote:
> Hi,
>
> PR 77333 is a i686-windows target bug, which however has its root in
> our general mechanism of adjusting gimple statements when redirecting
> call graph edge. Basically, these three things trigger it:
>
> 1) IPA-CP figures out that the this p
On Fri, 10 Mar 2017, Martin Liška wrote:
> Hello.
>
> As briefly discussed in the PR, there are BB that do not correspond to a real
> line in source
> code. profile.c emits locations for all BBs that have a gimple statement
> belonging to a line.
> I hope these should be marked in gcov utility an
On Mon, 13 Mar 2017, Richard Biener wrote:
> On Fri, 10 Mar 2017, Martin Liška wrote:
>
> > Hello.
> >
> > As briefly discussed in the PR, there are BB that do not correspond to a
> > real
> > line in source
> > code. profile.c emits locations for all BBs that have a gimple statement
> > belong
Hi
>
> Sorry for the delay, both of these look fine.
>
No issue here :) All the last patches were successfully committed with the
specified mods.
Thank you for your review,
Claudiu
On 03/13/2017 01:28 PM, Richard Biener wrote:
> On Thu, Mar 9, 2017 at 12:40 PM, Martin Liška wrote:
>> On 03/08/2017 12:00 PM, Richard Biener wrote:
>>> On Tue, Mar 7, 2017 at 5:01 PM, Martin Liška wrote:
On 03/07/2017 03:53 PM, Richard Biener wrote:
> On Tue, Mar 7, 2017 at 3:48 PM, Ma
On Mon, Mar 13, 2017 at 2:02 PM, Martin Liška wrote:
> On 03/13/2017 01:28 PM, Richard Biener wrote:
>> On Thu, Mar 9, 2017 at 12:40 PM, Martin Liška wrote:
>>> On 03/08/2017 12:00 PM, Richard Biener wrote:
On Tue, Mar 7, 2017 at 5:01 PM, Martin Liška wrote:
> On 03/07/2017 03:53 PM, Ri
On 03/13/2017 02:01 PM, Richard Biener wrote:
> On Mon, 13 Mar 2017, Richard Biener wrote:
>
>> On Fri, 10 Mar 2017, Martin Liška wrote:
>>
>>> Hello.
>>>
>>> As briefly discussed in the PR, there are BB that do not correspond to a
>>> real
>>> line in source
>>> code. profile.c emits locations f
On 03/13/2017 02:07 PM, Richard Biener wrote:
> No, that can't happen. I said that for example for
>
> struct S { ... } s;
> foo (s);
>
> pass_by_reference may be true but on gimple you see a struct s as
> actual argument. I'm not sure
> what chkp_find_bounds does to 's' in this case. Like if
On Mon, 13 Mar 2017, Martin Liška wrote:
> On 03/13/2017 02:01 PM, Richard Biener wrote:
> > On Mon, 13 Mar 2017, Richard Biener wrote:
> >
> >> On Fri, 10 Mar 2017, Martin Liška wrote:
> >>
> >>> Hello.
> >>>
> >>> As briefly discussed in the PR, there are BB that do not correspond to a
> >>> r
On 03/13/2017 02:53 PM, Richard Biener wrote:
> On Mon, 13 Mar 2017, Martin Liška wrote:
>
>> On 03/13/2017 02:01 PM, Richard Biener wrote:
>>> On Mon, 13 Mar 2017, Richard Biener wrote:
>>>
On Fri, 10 Mar 2017, Martin Liška wrote:
> Hello.
>
> As briefly discussed in the PR,
On Mon, 13 Mar 2017, Martin Liška wrote:
> On 03/13/2017 02:53 PM, Richard Biener wrote:
> > On Mon, 13 Mar 2017, Martin Liška wrote:
> >
> >> On 03/13/2017 02:01 PM, Richard Biener wrote:
> >>> On Mon, 13 Mar 2017, Richard Biener wrote:
> >>>
> On Fri, 10 Mar 2017, Martin Liška wrote:
> >>>
Hello.
This is a small follow-up patch, where local.local flag should be also dropped
for a default implementation.
Patch can bootstrap on x86_64-linux-gnu and survives regression tests.
Ready to be installed?
Martin
>From 0d7b793b23e6dad738abaee32a9e0fbf0f4c70c5 Mon Sep 17 00:00:00 2001
From: m
Just skimmed over a pahole -I -H 1 report and came up with the following
(far from complete but should catch stuff that looked important).
Bootstrap / regtest running on x86_64-unknown-linux-gnu.
Richard.
2017-03-13 Richard Biener
* alias.c (struct alias_set_entry): Pack properly.
gcc/testsuite/ChangeLog:
2017-03-13 Martin Liska
* g++.dg/ext/mv8.C: Add aarch64* targets.
gcc/ChangeLog:
2017-03-13 Martin Liska
* config/aarch64/aarch64.c (aarch64_process_target_attr):
Show error message instead of an ICE.
---
gcc/config/aarch64/aarch64.c |
gcc/ChangeLog:
2017-03-13 Martin Liska
* multiple_target.c (create_dispatcher_calls): Check that
a target can create a function dispatcher.
---
gcc/multiple_target.c | 7 +++
1 file changed, 7 insertions(+)
diff --git a/gcc/multiple_target.c b/gcc/multiple_target.c
index
Hello.
There are various targets that support target attribute. However do ICE
when one passes a wrong value. I hope displaying an error message
(similar to what we do on i386) is the proper thing.
Apart from that, multiversioning should not rely on just target ifunc
support.
Patch can bootstrap
gcc/ChangeLog:
2017-03-13 Martin Liska
PR target/79906
* config/rs6000/rs6000.c (rs6000_inner_target_options): Show
error message instead of an ICE.
gcc/testsuite/ChangeLog:
2017-03-13 Martin Liska
PR target/79906
* g++.dg/ext/mv8.C: Add power* tar
On 03/07/2017 01:01 PM, Gerald Pfeifer wrote:
On Tue, 7 Mar 2017, Jeff Law wrote:
When/if this has been accepted, is it okay to pull the latest config.guess
into GCC even at this stage of the release process? (We're only looking
at this change and the addition of nsx-tandem compared to what we
Hello everyone, i have a patch for this issue.
List of implemented functionality:
1.Reading .gnu_debuglink section from ELF file:
a. Reading name of debug info file.
b. Verifying crc32 sum.
2. Searching for separate debug info file from paths:
a. /usr/lib/debug/path/to/executable
b. /path/t
Hi,
On 11/03/17 12:11, Arnaud Charlet wrote:
>> This patch fixes an error caused by my changing of the signal constants
>> on MIPS in r244026. While that patch worked on mipsel, ada fails to
>> bootstrap with it on mips64el with the error:
>>
>> s-osinte.ads:610:07: component "sa_flags" overlaps "
On 12/03/17 13:47 +0200, Ville Voutilainen wrote:
Tested on Linux-x64.
2017-03-12 Ville Voutilainen
Implement LWG 2806, Base class of bad_optional_access.
* include/std/optional (bad_optional_access):
Derive from std::exception.
(bad_optional_access::bad_optional_access): Adjust.
Additional checking of MD files has exposed a bug in the pdp11 backend.
Namely it has a scratch operand with a lower number than other operands.
This patch adjusts the operand numbers. I've verified this allows the
pdp11 backend to build again. Installed on the trunk.
Jeff
diff --git a/g
RISCV targets were failing to build due to implicit-fallthru warnings.
This changes comments which indicated expected fallthru to use the
attribute and the port builds again. I assume something about the use
of the cpp macro is causing the comment to not have the intended effect.
I didn't
On Sun, Mar 12, 2017 at 3:05 PM, 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_{com
Hi Joseph,
Thanks for the review! Re-sending this patch to gcc-patches as I ran
into MIME problems with my previous reply.
I've made corrections as suggested, and chosen to just remove the
paragraph describing machine modes. The typedef descriptions can stand
on their own well enough.
Revise
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
On Sun, 12 Mar 2017, Gerald Pfeifer wrote:
> On Fri, 10 Mar 2017, Manuel López-Ibáñez wrote:
> >> I am currently translating GCC into German. During that, I noticed that
> >> in some places the term "zero character" means '\0'. The official term
> >> though is "null character", as per the C standa
On Mon, 13 Mar 2017 10:50:28 PDT (-0700), l...@redhat.com wrote:
>
> RISCV targets were failing to build due to implicit-fallthru warnings.
>
> This changes comments which indicated expected fallthru to use the
> attribute and the port builds again. I assume something about the use
> of the cpp m
On Mon, Mar 13, 2017 at 07:11:50PM +0100, Markus Trippelsdorf wrote:
> 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_{na
Uros,
Testing on Cygwin only turns out to be a nightmare, but I've finally
gotten some test results that I'm calling "clean enough". I have only
done 64-bit Cygwin thus far, (still need 32-bit Cygwin as well as 32/64
MinGW), but I've hit a snag. The first patch set ("Use aligned SSE movs
for
On Sat, 11 Mar 2017, Gerald Pfeifer wrote:
> Joseph, Sandra,
>
> I am thinking about the patch below; what do you think?
I think that as far as possible we should just use "@node node-name"
without any of the subsequent arguments pointing to other nodes.
--
Joseph S. Myers
jos...@codesourcery
On 03/13/2017 06:29 PM, Mark Wielaard wrote:
> O, sorry. I should have let Nick known about the gdb regressions I found.
> Besides this patch gdb needs the following one-liner fix:
>
> diff --git a/gdb/cp-name-parser.y b/gdb/cp-name-parser.y
> index fd1e949..5278c05 100644
> --- a/gdb/cp-name-par
All branches tested on Linux-x64.
Changelogs for trunk, gcc-6-branch, gcc-5-branch (the last two are identical, as
are probably their patches).
2017-03-13 Ville Voutilainen
PR libstdc++/80034
* include/bits/list.tcc (merge(list&&)): Use const for the size_t
in the catch-block.
This is a series of patches to fix various bugs in the Unicode
character conversion facets.
Ther first patch fixes a silly < versus <= bug that meant that 0x
got written as a surrogate pair instead of as simply 0xff, and an
endianness bug for the internal representation of UTF-16 code units
s
On 13/03/17 20:57 +0200, Ville Voutilainen wrote:
All branches tested on Linux-x64.
Changelogs for trunk, gcc-6-branch, gcc-5-branch (the last two are identical, as
are probably their patches).
OK for all three, thanks.
On Mon, Mar 13, 2017 at 8:06 AM, Nathan Sidwell wrote:
> The resolution to DR 1658 causes vbases of abstract classes to be ignored
> when building the cdtors. That made sense for ctors, when there might be no
> default ctor available. But for dtors, there is only oe dtor and they can
> be virtua
On Mon, 13 Mar 2017, Denis Chertykov wrote:
>> The avr section currently has this:
>>
>> We @emph{strongly} recommend using binutils 2.13 or newer.
>>
>> Okay to yank it?
> We can remove this line.
Done thusly, thank you.
Gerald
2017-03-13 Gerald Pfeifer
* doc/install.texi (Specifi
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 Spanish team of translators. The file is available at:
http://translationproject.org/latest/gcc/es.po
(This file, 'gcc-7.1-b20170226.es.po',
On Mon, 13 Mar 2017, Joseph Myers wrote:
I am currently translating GCC into German. During that, I noticed that
in some places the term "zero character" means '\0'. The official term
though is "null character", as per the C standard.
>> Joseph, do you also agree (and with the patch
On 03/13/2017 05:05 PM, Jason Merrill wrote:
It looks like you're ignoring the access for all base destructors;
handling this in synthesized_method_base_walk would let you limit the
change to vbases with virtual destructors. That function also already
handles ignoring access control for an inhe
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.
OK for trunk?
Regards
Thomas
2017-03-12 Thomas Koenig
PR libfortran/79956
* libgfortran.h (GF
On 03/13/17 15:02, Gerald Pfeifer wrote:
> On Mon, 13 Mar 2017, Joseph Myers wrote:
> I am currently translating GCC into German. During that, I noticed that
> in some places the term "zero character" means '\0'. The official term
> though is "null character", as per the C standard.
>>>
Hi Bill,
On Mon, Mar 13, 2017 at 01:11:01PM -0500, Bill Schmidt wrote:
> Index: gcc/doc/extend.texi
> ===
> --- gcc/doc/extend.texi (revision 246014)
> +++ gcc/doc/extend.texi (working copy)
> @@ -948,10 +948,28 @@ names c
> On Mar 13, 2017, at 6:31 PM, Segher Boessenkool
> wrote:
>
> Hi Bill,
>
> On Mon, Mar 13, 2017 at 01:11:01PM -0500, Bill Schmidt wrote:
>> Index: gcc/doc/extend.texi
>> ===
>> --- gcc/doc/extend.texi (revision 246014)
>> ++
Hi,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79908 shows a case where
pass_stdarg ICEs attempting to gimplify a COMPLEX_EXPR with side
effects as an lvalue. The expression is not addressable, so the
gimplification fails. This patch says, hey, don't do that!
The resulting GIMPLE looks fine
The output of a floating point directive whose precision is
specified by an asterisk with an argument that's in a range
that includes both negative and positive values less than
six may include between zero and six fractional digits plus
a decimal point. For example,
printf ("%.*e", p, x);
re
Ping: this a P3 regression targeted at 7.0.1. It was found
on x86_64-apple-darwin10.8.0 but affects all targets (even
if it doesn't happen to manifest on them):
https://gcc.gnu.org/ml/gcc-patches/2017-03/msg00342.html
On 03/07/2017 06:03 PM, Martin Sebor wrote:
In bug 79936 - ICE with -Wallo
Hi Jeff:
It's make older gcc version can't build RISC-V port, how about use
gcc_fallthrough instead?
diff --git a/gcc/config/riscv/riscv.c b/gcc/config/riscv/riscv.c
index f4c1f23..d1af07f5 100644
--- a/gcc/config/riscv/riscv.c
+++ b/gcc/config/riscv/riscv.c
@@ -2089,13 +2089,13 @@ riscv_emit_flo
Thanks Kito -- this had broken my build too, I'd just gotten distracted by
another bug and had forgotten to commit it. It's now in as
commit 6ca48c85b40db96f01d49f37afb19100b4a6b75b
Author: palmer
Date: Tue Mar 14 03:51:24 2017 +
Use gcc_fallthrough() instead of __attribute__((fallthr
On Mon, Mar 13, 2017 at 5:01 AM, Janne Blomqvist
wrote:
> On Sun, Mar 12, 2017 at 10:46 PM, Janne Blomqvist
> wrote:
>> On Sun, Mar 12, 2017 at 7:26 PM, NightStrike wrote:
>>> On Mon, Feb 27, 2017 at 6:15 AM, Janne Blomqvist
>>> wrote:
Don't try to use rand_s on CYGWIN
CYGWIN see
63 matches
Mail list logo
