As suggested by Jakub this adds the missing combination.
Bootstrapped / tested on x86_64-unknown-linux-gnu, applied.
Richard.
2016-03-01 Richard Biener
PR tree-optimization/69994
* tree-ssa-reassoc.c (ops_equal_values_p): Handle missing case.
Index: gcc/tree-ssa-reassoc.c
=
Here is another patch to reduce the differences between the 32 bit MIPS
and 64 bit MIPS configuration. This patch combines the two case entries
in config.gcc into one entry so the header file list and other settings
don't have to be handled twice.
This patch should not change the build fo
The attached patch removed an unused function.
OK to commit?
2018-05-10 Steven G. Kargl
* gfortran.h: Remove prototype.
* symbol.c (gfc_new_undo_checkpoint): Remove unused function.
--
Steve
Index: gcc/fortran/gfortran.h
Hi!
Now that we are back in stage 1, I'd like move on with the
entry_value/call_site debug info extensions.
Here is the http://gcc.gnu.org/ml/gcc-patches/2010-12/msg01793.html
patch updated to current trunk, bootstrapped/regtested on x86_64-linux
and i686-linux. Ok for trunk?
2011-03-15
On Fri, Mar 25, 2016 at 1:33 AM, Andrew Sutton
wrote:
> I'll just leave this here...
>
> This patch significantly improves performance with concepts (i.e.,
> makes it actually usable for real systems) and improves the
> specificity of diagnostics when constraints fail.
>
I've pushed my work-in-progress integration branch to jason/concepts-rewrite.
Jason
On Mon, Jun 20, 2016 at 4:28 PM, Jason Merrill wrote:
> On Fri, Mar 25, 2016 at 1:33 AM, Andrew Sutton
> wrote:
>> I'll just leave this here...
>>
>> This patch significantly
ew _CONSTR codes
>> > there? This is blocking me from checking in the patch.
>
> I wonder if those were the problems that I was running into, but hadn't
> diagnosed. I had thought it shouldn't be possible to get the full set of
> constraints in tsubst_constraint.
seems obviously untrue now. But still... that
gcc_unreachable isn't being triggered by any code in cmcstl.
I attached a patch that adds tsubsts for the missing constraints.
Unfortunately, I don't have time to test thoroughly today.
I did find another bug building cmcstl2, hence the attac
Ah sure. Jason has been vetting my post-Jacksonville concepts patch in
the branch jason/concepts-rewrite. I just pulled this off the github
GCC mirror this morning to look at an outstanding question. Resulted
in the previous 2 patches.
I tried building a fresh pull of your cmcstl2 and got an off
On Sun, Jul 10, 2016 at 11:20 AM, Andrew Sutton
wrote:
> I just tried building a fresh pull of cmcstl2, and I'm not seeing any
> errors as a result of not handling those missing codes in
> tsubst_constraint. At one point, I think it was not possible to get
> those other constraints in this context
On Sun, Jul 10, 2016 at 11:20 AM, Andrew Sutton
wrote:
> I did find another bug building cmcstl2, hence the attached
> disable-opt patch. For some reason, the memoization of concept
> satisfaction is giving momoized results for concept + args that have
> not yet been evaluated. Thi
This is an update from last years attempt to tame down vectorization
when it runs in to ABI inefficiencies at function return. I've
updated the patch to look for multi-reg returns instead of
!vector ones (due to word_mode vectorization) and handle a bit
more returns, esp. the common patte
> -Original Message-
> From: Steve Ellcey [mailto:sell...@imgtec.com]
> Sent: Thursday, October 23, 2014 4:37 PM
> To: matthew.fort...@imgtec.com; Moore, Catherine; gcc-
> patc...@gcc.gnu.org
> Subject: [Patch] MIPS configuration patch
>
> Here is another patch t
adjustment.
The adjustment is necessary because the AIX assembler inserts the
debug line section length, which causes the GCC generated label for
the beginning of the section to point to the incorrect location
expected by debuggers, such as GDB.
This patch mirrors the earlier patch to copy
Hi,
Per PR79941, we are folding the vec_mul{e,o}* operations improperly. Those
entries were added to the intrinsics-to-be-folded list where the generic
multiplies should have been instead. Test coverage in place was for the
generic multiplies, and this was missed by my testing.
Thusly, remove tho
Based on comments from Richi. This patch tweaks
has_abnormal_outgoing_edge to also check for EDGE_EH and changes the
name in the obvious way.
This allows part of patch for 59127 to go away -- specifically we don't
have to check stmt_ends_bb_p and explicitly filter out GIMPLE_R
Hello
This patch fixes a couple of issues with the latest patch series for
metadirectives.
Firstly, the changes to c_parser_skip_to_end_of_block_or_statement and
its C++ equivalent cause a couple of tests (e.g. gcc.dg/attr-malloc.c)
to regress.
This is because these tests cause the parser
On Thu, 10 May 2018 16:08:17 -0700
Steve Kargl wrote:
> The attached patch removed an unused function.
> OK to commit?
Removing unused code, can only make things easier. Ok to commit IMHO.
- Andre
>
> 2018-05-10 Steven G. Kargl
>
>* gfortran.h: Remove prototyp
sses.cc:2198
Aah, this smells a lot like the issue that François-Xavier reported,
that the following patch is expected to fix. I'm still regstrapping it
on x86_64-linux-gnu, after checking that it addressed the symptom on a
cross compiler to the target for which it had originally been reporte
I was asked to split V4 patch #4.2 into smaller chuncks. This patch is one of
8 patches that were broken out from 4.2. Another patch from 4.2 to use
SIGNED_16BIT_OFFSET_EXTRA_P has already been committed.
This patch adds some new predicates that will be used in future patches. It
also updates
After submitting the patch, I realized I had submitted a previous version of
the patch, that had the wq constraint that was initially for the quad memory
operations, and also had the changes for ChangeLog.ibm, that I keep on the
branch. However, the wq constraint was always equal to the r
On Mon, May 20, 2013 at 5:34 PM, Michael Meissner
wrote:
> After submitting the patch, I realized I had submitted a previous version of
> the patch, that had the wq constraint that was initially for the quad memory
> operations, and also had the changes for ChangeLog.ibm, that I ke
Now that Jim Meyering has remove the macro that prevented directly
calling free(), and replaced gfc_free() with free(), we can fix this.
Committed as obvious.
Index: frontend-passes.c
===
--- frontend-passes.c (revision 172727)
+++
On 03/15/2011 04:19 AM, Jakub Jelinek wrote:
> Hi!
>
> Now that we are back in stage 1, I'd like move on with the
> entry_value/call_site debug info extensions.
>
> Here is the http://gcc.gnu.org/ml/gcc-patches/2010-12/msg01793.html
> patch updated to current trunk,
On Tue, Mar 15, 2011 at 4:19 AM, Jakub Jelinek wrote:
> Hi!
>
> Now that we are back in stage 1, I'd like move on with the
> entry_value/call_site debug info extensions.
>
> Here is the http://gcc.gnu.org/ml/gcc-patches/2010-12/msg01793.html
> patch updated to c
On Wed, Mar 16, 2011 at 03:38:25PM -0700, H.J. Lu wrote:
IMNSHO you really should reconsider using Pmode != ptr_mode for your port.
That said, the patch looks good to me, though I can't approve it.
> diff --git a/gcc/ChangeLog.x32 b/gcc/ChangeLog.x32
> index 764e3de..45db256 100644
Its
stack operation is 64bit.
> That said, the patch looks good to me, though I can't approve it.
Richard, Jason, is this patch OK with PR debug/48160 in the ChangeLog entry.?
>> diff --git a/gcc/ChangeLog.x32 b/gcc/ChangeLog.x32
>> index 764e3de..45db256 100644
>> -
Hi.
There's forgotten patch for libsanitizer that was not listed
in LOCAL_PATCHES. I've just tested the patch on ppc64
(gcc110 compile farm machine) and I'm going to install the patch.
Martin
>From 82662f97b6bacf21eee1185bc116aa22c0c89b33 Mon Sep 17 00:00:00 2001
From: Marti
Richard Biener writes:
> This is an update from last years attempt to tame down vectorization
> when it runs in to ABI inefficiencies at function return. I've
> updated the patch to look for multi-reg returns instead of
> !vector ones (due to word_mode vectorization) and ha
On Mon, 1 Apr 2019, Richard Sandiford wrote:
> Richard Biener writes:
> > This is an update from last years attempt to tame down vectorization
> > when it runs in to ABI inefficiencies at function return. I've
> > updated the patch to look for multi-reg returns instea
Richard Biener writes:
> On Mon, 1 Apr 2019, Richard Sandiford wrote:
>
>> Richard Biener writes:
>> > This is an update from last years attempt to tame down vectorization
>> > when it runs in to ABI inefficiencies at function return. I've
>> > upd
runs in to ABI inefficiencies at function return. I've
> >> > updated the patch to look for multi-reg returns instead of
> >> > !vector ones (due to word_mode vectorization) and handle a bit
> >> > more returns, esp. the common pattern of
> >>
Richard Biener writes:
>> > So, may I go with the original patch?
>>
>> Still feels like we're counting spills on targets that shouldn't need them.
>> But going back to:
>>
>>/* Assume that a reg-reg move is possible and cheap,
>>
In a future patch, I plan to introduce a new function that says whether an
address is prefixed based on the address format (D-form, DS-form, DQ-form) used
by the instruction. I plan on naming the new function:
rs6000_prefixed_address_format
This means the existing function that takes a
Committed as obvious. I had inserted this line to check effects of the
-fdec flags and forgot to delete it before my previous commit.
Author: jvdelisle
Date: Fri Nov 9 17:29:33 2018
New Revision: 265979
URL: https://gcc.gnu.org/viewcvs?rev=265979&root=gcc&view=rev
Log:
2018-11-09 Jerry DeLisl
Hi all, I'm following up on some old work my colleague Mark Doffman did to try
and get support for the AUTOMATIC keyword into trunk. In the enclosed patch
I've addressed the problem with it accepting 'automatic' outside -std=gnu (it
will now only accept AUTOMATIC under -st
Hi,
This patch prevents arm_thumb1_ok XPASS in sibcall-3.c and sibcall-4.c
testcases. Sibcalls are not ok for Thumb1 and testcases need to be fixed.
Is patch ok?
gcc/testsuite
2015-05-20 Alex Velenko
* gcc.dg/sibcall-3.c (dg-skip-if): Skip if arm_thumb1_ok.
* gcc.dg/sibcall
Hi, Honza,
Sorry for the delay. I just picked up the original patch, and updated
it with your comments.
I've addressed most of your comments. Something else to discuss inlined.
I had refactored the patch to make it much less intrusive. New patch
is attached (ChangeLog will be added in the
artiuclar the EH cleanups) even without profile. That should
> > work
> > well with autofdo.
>
> This will cause bzip2 performance to degrade 6%. I haven't had time to
> triage the problem. Will investigate this later.
Still I would preffer to make this by
that incrementally, lets just drop
> this from initial patch.
Sure, I'll remove that for now.
>> >> Index: gcc/cgraphclones.c
>> >> ===
>> >> --- gcc/cgraphclones.c(revision 210
n AutoFDO, if edge count is larger than callee's entry block
> + count, we will not update the original callee because it may
> + mistakenly mark some hot function as cold. */
> + if (flag_auto_profile && gcov_count >= count)
> + update_original = fals
> + if (flag_auto_profile && gcov_count >= count)
>> +update_original = false;
>
> lets drop this from initial patch.
Done
>
>> Index: gcc/bb-reorder.c
>> ===
>> --- gcc/bb-reorder.c (re
The new patch is attached. I used clang-format for format auto-profile.{c|h}
Thanks,
Dehao
On Tue, Oct 14, 2014 at 2:05 PM, Dehao Chen wrote:
> On Tue, Oct 14, 2014 at 8:02 AM, Jan Hubicka wrote:
>>> Index: gcc/cg
Dehao Chen writes:
> +
> +@item -fauto-profile
> +@itemx -fauto-profile=@var{path}
> +@opindex fauto-profile
> +Enable sampling based feedback directed optimizations, and optimizations
> +generally profitable only with profile feedback available.
> +
> +The following options are enabled: @code{-fb
"not too reliable but better than
nothing" and we may want to introduce some kind of reliability metric on way
estimates are derived.
Lets handle this incrementally and drop this change from this patch.
> Index: gcc/doc/invoke.texi
> ==
Hi, Honza,
I've integrated all your comments to the patch. New patch attached.
Thanks,
Dehao
On Wed, Oct 15, 2014 at 7:28 AM, Jan Hubicka wrote:
>> Index: gcc/cfgloop.c
>> ===
>> --- gcc/cfgloop
(!opts_set->x_flag_vect_cost_model)
> - opts->x_flag_vect_cost_model = VECT_COST_MODEL_DYNAMIC;
> - if (!opts_set->x_flag_tree_loop_distribute_patterns)
> - opts->x_flag_tree_loop_distribute_patterns = value;
> - if (!opts_set->x_flag_profile_reo
creates cfg.h, cfganal.h, lcm.h, and loop-unroll.h to house the
prototypes for those .c files.
cfganal.h also gets "struct edge_list" and "class control_dependences"
definitions since that is where all the routines and manipulators are
declared.
loop-unroll.h only exports 2 routines, so ra
The updated patch attached. Will commit the patch in 2~3 hours if no
objection is received.
Thanks,
Dehao
On Sun, Oct 19, 2014 at 2:58 AM, Jan Hubicka wrote:
>> >> +/* Member functions for string_table. */
>> >> +
>> >> +string_table *
>> >> +str
The last of the restructuring stuff before flattening basic-block.h.
5 new files, cfgbuild.h, cfgcleanup.h, cfgloopmanip.h, dominance.h, and
ifcvt.h. MOstly prototypes, but a few enums, #defines and structs were
more appropriately located.
basic-block.h only includes cfgbuild.h, cfgcleanup.
On 2014.10.20 at 14:21 -0700, Dehao Chen wrote:
> >> +If @var{path} is specified, GCC looks at the @var{path} to find
> >> +the profile feedback data files.
> >> +
> >> +In order to collect AutoFDO profile, you need to have:
> >> +
> >> +1. A linux system with linux perf support
> >> +2. An Intel p
Everything will be the same on non-intel CPUs except for the perf command:
perf record -e instructions -- your program.
i.e. you need to drop "-b" and use instructions as event.
Note that the current algorithm is tuned for accurate instruction
level profile, which is not available on non-Intel C
On 2014.10.21 at 13:53 -0700, Dehao Chen wrote:
> Everything will be the same on non-intel CPUs except for the perf command:
>
> perf record -e instructions -- your program.
>
> i.e. you need to drop "-b" and use instructions as event.
>
> Note that the current algorithm is tuned for accurate in
Looks like the perf data type is incompatible with quipper (perf data
parser). Can you send me the perf.data file so that I can take a look.
Thanks,
Dehao
On Tue, Oct 21, 2014 at 2:25 PM, Markus Trippelsdorf
wrote:
> On 2014.10.21 at 13:53 -0700, Dehao Chen wrote:
>> Everything will be the same
On 2014.10.21 at 15:31 -0700, Dehao Chen wrote:
> Looks like the perf data type is incompatible with quipper (perf data
> parser). Can you send me the perf.data file so that I can take a look.
PERF_RECORD_MMAP2 (aka 10) was added in Linux 3.12 (commit 13d7a2410f).
So your autofdo tool simply doesn
Dehao Chen writes:
> The updated patch attached. Will commit the patch in 2~3 hours if no
> objection is received.
Apart from the AIX bootstrap failure your patch introduced, it also
breaks Solaris bootstrap:
In file included from ./config.h:6:0,
from /vol/gcc/src/hg
>>>>> Rainer Orth writes:
> As Joseph is repeating over and over again, *nothing* must be included
> before config.h, and auto-profile.c violates this.
>
> The following patch at least allows the file to compile without errors;
> no idea if this the best order f
Can someone pre-approve the patch so that Dehao can check it in after
basic testing?
David
On Wed, Oct 22, 2014 at 10:06 AM, David Edelsohn wrote:
>>>>>> Rainer Orth writes:
>
>> As Joseph is repeating over and over again, *nothing* must be included
>> be
The patch tested OK. And I think it's a trivial patch, and already
committed it to trunk.
About the perf parser. I'm syncing the toolchain to head which should
already have newer kernel support.
Thanks,
Dehao
On Wed, Oct 22, 2014 at 10:07 AM, Xinliang David Li wrote:
> Can someon
Don't let it's size scare you, this is actually fairly trivial now. I
split it into the more interesting patch and the big, boring, mechanical
one. all-in-all, it touches 351 files :-P.
This patch completely flattens basic-block.h. I manually adjusted some
of the remaining .h
Have you announced the autofdo profile tool to gcc list?
David
On Wed, May 7, 2014 at 2:24 PM, Dehao Chen wrote:
> Hi,
>
> I'm planning to port the AutoFDO patch upstream. Attached is the
> prepared patch. You can also find the patch in
> http://codereview.appspot.com/9901
> Hi,
>
> I'm planning to port the AutoFDO patch upstream. Attached is the
> prepared patch. You can also find the patch in
> http://codereview.appspot.com/99010043
>
> I've tested the patch with SPECCPU2006. For the CINT2006 benchmarks,
> the speedup comparison
gt; + num_unknown_succ ++;
> + else
> + total_count += e->count;
> + }
> + if (num_unknown_succ == 0 && total_count > 0)
> + {
> + FOR_EACH_EDGE (e, ei, bb->succs)
> + e->probability =
> + (double) e->count * REG_BR_PROB_BASE / total_count;
> + }
> +}
> + FOR_ALL_BB_FN (bb, cfun)
> +{
> + edge e;
> + edge_iterator ei;
> +
> + FOR_EACH_EDGE (e, ei, bb->succs)
> + e->count =
> + (double) bb->count * e->probability / REG_BR_PROB_BASE;
> + bb->aux = NULL;
> +}
> +
> + loop_optimizer_finalize ();
> + free_dominance_info (CDI_DOMINATORS);
> + free_dominance_info (CDI_POST_DOMINATORS);
> +}
I wonder if using the estimated profile to fill in the missing gaps would make
sense?
I.e. running the standard branch probabilities->freuqencies propagation code
bug this
time taking the determined counts as known values?
> +
> +/* Perform value profile transformation using AutoFDO profile. Add the
> + promoted stmts to PROMOTED_STMTS. Return TRUE if there is any
> + indirect call promoted. */
> +
> +static bool
> +afdo_vpt_for_early_inline (stmt_set *promoted_stmts)
What exactly this function does? It inlines according to the inline decisions
made at train run time and recorded to profile feedback?
The patch looks very resonable in general. Lets break it up to smaller chunks
and
get it merged. It is an interesting stuff!
Thanks a lot!
Honza
Early PING: https://gcc.gnu.org/ml/gcc-patches/2015-01/msg00090.html
Tobias Burnus wrote:
Attached is a regtested patch, which fixes the issue. Additionally,
the variable visibility (TREE_PUBLIC) is now depending on the private
attribute (copied from the module var generation) and I mark the
Paul Richard Thomas wrote:
It looks to me as if you had to do a fair amount of detective work
there! The patch is OK for trunk.
Thanks for the review - which didn't make it to mailing list for some
reasons (text+HTML email?).
Committed as Rev. 219354
Tobias
Thanks for your efforts
Hi,
this is my last and best try ;) Seriously, compared to the last posted
version:
1- I added a rather large comment explaining what's going on wrt error
recovery.
2- Took the occasion to clean-up a bit the code about bool vs int for
flags (we had a mix).
3- Cleaned-up a bit the code itself (
Hello Everyone,
This patch is for the Cilkplus branch affecting mainly the C compiler. This
patch will start the implementation of elemental functions in the branch. This
patch will parse the elemental function attributes in the C compiler
Thanking You,
Yours Sincerely,
Balaji V
Hi Jason,
I have a new patch for this issue, another SFINAE issue noticed by
Daniel. Compared to the last version, I extended the complain-ization ;)
to a few more functions in typeck.c (I think the set is more consistent
now) and thoroughly double checked that the return values of all the
On 07/22/2017 08:29 PM, David Edelsohn wrote:
This patch mirrors the earlier patch to copy debug_section_label into
dl_section_ref and append the adjustment when necessary. With this
patch, GDB is able to report correct macro information.
Bootstrapped on powerpc-ibm-aix7.2.0.0
Debug related
Hi.
I've just sketched a patch for the PR. Well I'm not fully happy about
complexity of emit_block_move_hints function and I need to add another
logic. Any ideas how to make it more transparent? Maybe split it into
analysis function that will return decision and second that will j
On Tue, Mar 07, 2017 at 03:36:38PM -0600, Will Schmidt wrote:
> Per PR79941, we are folding the vec_mul{e,o}* operations improperly. Those
> entries were added to the intrinsics-to-be-folded list where the generic
> multiplies should have been instead. Test coverage in place was for the
> generic
On Tue, 2017-03-07 at 22:52 +0100, Jakub Jelinek wrote:
> On Tue, Mar 07, 2017 at 03:36:38PM -0600, Will Schmidt wrote:
> > Per PR79941, we are folding the vec_mul{e,o}* operations improperly. Those
> > entries were added to the intrinsics-to-be-folded list where the generic
> > multiplies should h
Hi,
Per PR79941, we are folding the vec_mul{e,o}* operations improperly. Those
entries were added to the intrinsics-to-be-folded list where the generic
multiplies should have been instead. Test coverage in place was for the
generic multiplies, and this was missed by my testing.
The mul[eo]* unsig
On Tue, Mar 07, 2017 at 03:36:38PM -0600, Will Schmidt wrote:
> Per PR79941, we are folding the vec_mul{e,o}* operations improperly. Those
> entries were added to the intrinsics-to-be-folded list where the generic
> multiplies should have been instead. Test coverage in place was for the
> generic
On Tue, Aug 16, 2022 at 11:41:06AM +, Richard Biener wrote:
> I'm OK with the rest of the patch if Joseph doesn't have comments
> on the actual issignaling lowerings (which I didn't review for
> correctness due to lack of knowledge).
I'd like to ping this patc
Am 19.04.2011 20:17, schrieb Janne Blomqvist:
Now that Jim Meyering has remove the macro that prevented directly
calling free(), and replaced gfc_free() with free(), we can fix this.
Committed as obvious.
Thanks Janne. I had meant to do this, but hadn't gotten a round tuit.
Thomas
Hi,
The attached patch does some cleanup and a check for trailing zeros to decide
whether or not to round.
I have added the additional test cases posted on the bugzilla to the existing
test case round_3.f08.
Regression tested on x86-64.
OK for trunk and then I will back port the whole
Hi!
Here is http://gcc.gnu.org/ml/gcc-patches/2010-12/msg01794.html
patch updated to current trunk, bootstrapped/regtested on x86_64-linux and
i686-linux, ok for trunk?
2011-03-15 Jakub Jelinek
PR debug/45882
* rtl.def (ENTRY_VALUE): Change format from "e&q
Hi all,
attached you find a draft patch for implementing the run-time support
for THIS_IMAGE(coarray), LCOBOUND and UCOBOUND where the cobounds (or
the "dim=" argument) are not known at the compile time.
There are two cases where the bounds are not known:
a) For allocatabl
o just change the test
to expect it. The patch was tested on IA64 HP-UX and Linux. If I
don't hear any objections I will just check it in as an obvious fix.
Steve Ellcey
s...@cup.hp.com
2011-04-01 Steve Ellcey
* gcc.dg/mtune.c: Add expected note for target ia6
Hi All!
Here is the second part of patch to improve loop invariant code motion
for loop marked with pragma omp simd.
Bootstrapping and regression testing did not show any new failures.
Is it OK for trunk?
ChangeLog:
2016-06-28 Yuri Rumyantsev
PR tree-optimization/70729
* tree-ssa-loop-im.c
Hi,
Here is the new version of interrupt attribute patch. Bootstraped/regtested for
Linux/x86_64. Ok for trunk?
The interrupt and exception handlers are called by x86 processors. X86
hardware pushes information onto stack and calls the handler. The
requirements are
1. Both interrupt and
The following fixes the followup ICEs in the testcase for PR70725
where Markes patch only fixed the first one.
Bootstrapped on x86_64-unknown-linux-gnu, testing in progress.
Jakub - the patch should be safe in that any testcase running into
the changed paths now would have caused SSA
the nested include. The default value is
200.
Please check the attached patch.
I have done bootstrap and regression test on X86, no any issue.
thanks a lot.
Qing.
gcc/ChangeLog:
2019-05-30 qing zhao
* doc/cppopts.texi: Add document for -fmax-include-depth.
* doc/i
[ Please do not send patches as replies. ]
On Thu, Jul 11, 2019 at 08:11:52AM -0400, Michael Meissner wrote:
> In a future patch, I plan to introduce a new function that says whether an
> address is prefixed based on the address format (D-form, DS-form, DQ-form)
> used
> by the ins
In doing the patches, I noticed that mov_64bit_dm had two alternatives
combined together. This patch fixes the problem, before the next patch that
will need to modify mov_64bit_dm for prefixed addressing.
I have done a bootstrap build with all of the patches applied, and there were
no
On 09/24/2015 04:52 AM, Jim MacArthur wrote:
> Hi all, I'm following up on some old work my colleague Mark Doffman did to
> try
> and get support for the AUTOMATIC keyword into trunk. In the enclosed patch
> I've addressed the problem with it accepting 'automatic&#x
> I think I appreciate what you are trying to do here. I don't intend to sound
> negative here, but if the keyword AUTOMATIC does nothing
The testcase given is not an example of useful AUTOMATIC. I think it is meant
to be used to oppose an implied SAVE attribute, e.g. a variable with explicit
i
On Thu, Sep 24, 2015 at 10:58:41PM +0200, FX wrote:
> > I think I appreciate what you are trying to do here. I don't intend to
> > sound
> > negative here, but if the keyword AUTOMATIC does nothing
>
> The testcase given is not an example of useful AUTOMATIC. I think it is
> meant to be used to
it
> was in the spirit of open source to offer it in case it was useful.
>
> Thanks for taking the time to review it.
I definitely appreciate your contribution! And because it is now archived in
the mailing-list archives, if people are interested in the future they can
definitely
Dear Jim, FX and Jerry,
Frankly, I would accept the patch with the proviso that:
(i) It is hidden behand a gfc_notify_std (GFC_STD_GNU, "...;
(ii) The feature is set in conflict with the new features that FX
mentions, especially coarrays and bind C; and
(iii) As FX says, a good look a
On Fri, Sep 25, 2015 at 07:23:53PM +0200, Paul Richard Thomas wrote:
>
> Frankly, I would accept the patch with the proviso that:
> (i) It is hidden behand a gfc_notify_std (GFC_STD_GNU, "...;
> (ii) The feature is set in conflict with the new features that FX
> mentions,
Hi,
This patch prevents testcase pr63210.c from running with -march=armv4t.
Object size check should be skipped with explicit -march=armv4t, because
expected size is only correct using pop pc instruction which is unsafe for
armv4t. For arm_arch_v5t_ok cases, an explicit -march=armv5t flag is set
This is another intermediate patch to get IEEE 128-bit support on the PowerPC
into the GCC compiler. This patch adds a lot of the support to allow IEEE
128-bit support in VSX registers. Note, it will need future patches that
updates rs6000.c and rs6000.md to enable the basic IEEE 128-bit support
Hi,
This patch fix thumb-ltu.c to pass excess error test.
Without default -std=gnu90 flag, this testcase started failing
as some functions were called before being predefined.
Is patch ok?
gcc/testsuite
2015-06-01 Alex Velenko
* gcc.target/arm/thumb-ltu.c (foo): Predefined
On Wed, 20 May 2015, Alex Velenko wrote:
> Hi,
>
> This patch prevents arm_thumb1_ok XPASS in sibcall-3.c and sibcall-4.c
> testcases. Sibcalls are not ok for Thumb1 and testcases need to be fixed.
arm_thumb1_ok means "this is an ARM target where -mthumb causes Thumb-1 to
b
On Wed, May 20, 2015 at 9:11 PM, Joseph Myers wrote:
> On Wed, 20 May 2015, Alex Velenko wrote:
>
>> Hi,
>>
>> This patch prevents arm_thumb1_ok XPASS in sibcall-3.c and sibcall-4.c
>> testcases. Sibcalls are not ok for Thumb1 and testcases need to be fixed.
>
There are 3 patches left in the basic IEEE 128-bit floating point support for
the compiler. I will submit these at the same time. They are split to make the
review process similar. Patch #5 and #6 are indpendent of each other and can
be applied in either order. Patch #7 assumes that patches 1-6
There are 3 patches left in the basic IEEE 128-bit floating point support for
the compiler. I will submit these at the same time. They are split to make the
review process similar. Patch #5 and #6 are indpendent of each other and can
be applied in either order. Patch #7 assumes that patches 1-6
On 2015.08.31 at 16:44 +0200, Richard Biener wrote:
>
> So the state below now will pass LTO bootstrap (fingers crossing,
> stage3 running) as well as regular bootstrap. Iff I didn't break
> sth in the last minute. You need up-to-date trunk (watch out,
> fortran seems to be broken) to pull the f
1 - 100 of 3916 matches
Mail list logo
