On 2/26/2016 7:09 AM, Bernd Schmidt wrote:
On 02/21/2016 11:27 AM, David Wohlferd wrote:
So now what? I have one Bernd who likes the sample, and one who
doesn't. Obviously I think what I'm proposing is better than what's
there now and I've done my best to say why. But me believing it to be
be
On 02/28/2016 02:11 PM, H.J. Lu wrote:
On Sun, Feb 28, 2016 at 9:48 AM, H.J. Lu wrote:
On Sat, Feb 27, 2016 at 3:59 PM, H.J. Lu wrote:
On Thu, Feb 25, 2016 at 11:50 PM, Jeff Law wrote:
On 02/25/2016 03:00 AM, Richard Biener wrote:
So I fail to see how only successor edges are relevant.
This patches address PR 70008, where a reverse subtract with carry
instruction can be generated in thumb2 mode. It was tested with no
regressions in arm and thumb modes on the following targets:
arm-none-linux-gnueabi
arm-none-linux-gnuabihf
armeb-none-linux-gnuabihf
arm-none-eabi
Okay for tru
That looks better, but I think the unordered_remove will break operand sorting
and thus you probably don't handle x + x + x + x + y + y + y + y + y +
y + z + z + z + z
optimally.
I'd say you simply want to avoid the recursion and collect a vector of
[start, end] pairs
before doing any modificat
OK.
Jason
On 22-02-16 11:57, Jakub Jelinek wrote:
On Mon, Feb 22, 2016 at 11:54:46AM +0100, Tom de Vries wrote:
Following up on your suggestion to implement this during gimplification, I
wrote attached patch.
I'll put it through some openacc testing and add testcases. Is this approach
acceptable for stag
From: Trevor Saunders
when run in repos other than gcc mklog fails to find ChangeLog files
because it looks for $0/../$dir/ChangeLog, but of course if the diff is
for a project other than gcc that might not exist. It should be fine to
also look for $cwd/$dir/ChangeLog, and use that if we find i
On February 28, 2016 3:20:24 PM CST, Gerald Pfeifer wrote:
>On Wed, 24 Feb 2016, Richard Earnshaw (lists) wrote:
>> I propose to commit this patch later this week.
>
>+ Support for revisions of the ARM architecture prior to ARMv4t
>has
>+ been deprecated and will be removed in a futu
On Sun, 28 Feb 2016, NOC wrote:
> Due to reorganization of the mirror servers we will be taking the
> following mirror offline. Could you please remove it from the list?
>
> http://mirror2.babylon.network/gcc/ | ftp://mirror2.babylon.network/gcc/
> | rsync://mirror2.babylon.network/gcc/
Thank you
Somehow X86 apparently was changed to x86 at one point, breaking
this link.
Fixed thusly.
Gerald
Index: gcc-4.8/changes.html
===
RCS file: /cvs/gcc/wwwdocs/htdocs/gcc-4.8/changes.html,v
retrieving revision 1.136
diff -u -r1.136 cha
On Thu, 25 Feb 2016, Martin Liška wrote:
> That's a suggestion for changes.html.
>
> Ready to be installed?
Works for me, Martin, but please give Jason a day or two to comment.
Thanks,
Gerald
On Wed, 24 Feb 2016, Richard Earnshaw (lists) wrote:
> I propose to commit this patch later this week.
+ Support for revisions of the ARM architecture prior to ARMv4t has
+ been deprecated and will be removed in a future GCC release.
+ This affects ARM6, ARM7 (but not ARM7TDMI),
On Sun, Feb 28, 2016 at 9:48 AM, H.J. Lu wrote:
> On Sat, Feb 27, 2016 at 3:59 PM, H.J. Lu wrote:
>> On Thu, Feb 25, 2016 at 11:50 PM, Jeff Law wrote:
>>> On 02/25/2016 03:00 AM, Richard Biener wrote:
So I fail to see how only successor edges are relevant. Isn't the
importan
Committed.
Gerald
Index: readings.html
===
RCS file: /cvs/gcc/wwwdocs/htdocs/readings.html,v
retrieving revision 1.244
diff -u -r1.244 readings.html
--- readings.html 28 Feb 2016 19:55:15 - 1.244
+++ readings.html
On Fri, Jan 15, 2016 at 2:32 PM, Jeff Law wrote:
> On 01/14/2016 11:14 AM, Jeff Law wrote:
>>
>> On 01/14/2016 12:49 AM, Jakub Jelinek wrote:
>>>
>>> On Thu, Jan 14, 2016 at 08:46:43AM +0100, Jakub Jelinek wrote:
On Thu, Jan 14, 2016 at 12:38:52AM -0700, Jeff Law wrote:
>
> + /*
Not sure we should carry anything PDP-11 these days, I doubt
anyone is really using this or spending time. Anyway, this
link is gone and I couldn't find what appears to be an immediate
replacement.
Committed.
Gerald
Index: readings.html
=
Applied.
Gerald
Index: extensions.html
===
RCS file: /cvs/gcc/wwwdocs/htdocs/extensions.html,v
retrieving revision 1.56
diff -u -r1.56 extensions.html
--- extensions.html 28 Jun 2015 16:02:25 - 1.56
+++ extensions.html
This is the only reference to lists.fedoraproject.org that I
found via http; all others already are https.
Committed.
Index: gcc-4.6/porting_to.html
===
RCS file: /cvs/gcc/wwwdocs/htdocs/gcc-4.6/porting_to.html,v
retrieving revision
This wasn't strictly broken, but redirects to a new address;
still makes sense to follow that.
Applied.
Gerald
Index: gcc-4.8/changes.html
===
RCS file: /cvs/gcc/wwwdocs/htdocs/gcc-4.8/changes.html,v
retrieving revision 1.135
diff
In r233563 (where I applied the 2nd version of the fix for PR c++/68948)
I shouldn't have reverted the original fix because it is still required
for diagnosing an invalid constructor call with dependent arguments
(because in that case we delay further processing of the call until
instantiation). O
On 02/28/2016 03:42 AM, Thomas Koenig wrote:
> I wrote:
>
> Patch at
>
> https://gcc.gnu.org/ml/gcc-patches/2016-02/msg00941.html
>
>> OK for trunk?
>>
>> Regards
>>
>> Thomas
>>
>> 2016-02-14 Thomas Koenig
>>
>> * dump-parse-tree.c (show_code_node): Print association
>>
On 02/28/2016 03:39 AM, Thomas Koenig wrote:
> I wrote:
>
>> So, OK for these branches?
>
> Patch at
>
> https://gcc.gnu.org/ml/gcc-patches/2016-02/msg01364.html
>
> Regards
>
> Thomas
>>
>> 2016-02-18 Thomas Koenig
>>
>> PR fortran/68147
>> PR fortran/47674
>>
> In sparc systems glibc uses libgcc's unwinder to implement the
> backtrace(3) function, defaulting to a simple non-dwarf unwinder if
> libgcc_s doesn't provide a working _Unwind_Backtrace.
>
> However, libgcc's unwinder uses .eh_frame instead of .frame_debug, and
> .eh_frame is fully populated o
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 Swedish team of translators. The file is available at:
http://translationproject.org/latest/gcc/sv.po
(This file, 'gcc-6.1-b20160131.sv.po',
On Sat, Feb 27, 2016 at 3:59 PM, H.J. Lu wrote:
> On Thu, Feb 25, 2016 at 11:50 PM, Jeff Law wrote:
>> On 02/25/2016 03:00 AM, Richard Biener wrote:
>>>
>>>
>>> So I fail to see how only successor edges are relevant. Isn't the
>>> important
>>> case to catch whether we remove an edge marked EDGE
On Wed, Feb 10, 2016 at 2:26 AM, Yuri Rumyantsev wrote:
> Thanks Richard for your comments.
> I changes algorithm to remove dead scalar statements as you proposed.
>
> Bootstrap and regression testing did not show any new failures on x86-64.
> Is it OK for trunk?
>
> Changelog:
> 2016-02-10 Yuri
> No idea. To me it sounds that -mincoming-stack-boundary=2 would allow to do
> -mstackrealign in those functions where it is necessary rather than in all.
That's not my reading of ix86_minimum_incoming_stack_boundary:
/* Prefer the one specified at command line. */
if (ix86_user_incoming_st
I wrote:
Patch at
https://gcc.gnu.org/ml/gcc-patches/2016-02/msg00941.html
OK for trunk?
Regards
Thomas
2016-02-14 Thomas Koenig
* dump-parse-tree.c (show_code_node): Print association
list of a block if present. Handle EXEC_END_BLOCK.
I wrote:
So, OK for these branches?
Patch at
https://gcc.gnu.org/ml/gcc-patches/2016-02/msg01364.html
Regards
Thomas
2016-02-18 Thomas Koenig
PR fortran/68147
PR fortran/47674
* frontend-passes.c (realloc_string_callbac): Don't set
walk_subtree
29 matches
Mail list logo
