On 12/19/2014 03:46 PM, Michael Collison wrote:
The reason I included tree-core.h in all the .c files was the
requirement in tree.h (now flattened to the .c files) for
fold-const.h. In tree.h there are inline functions such as
fold_build_pointer_plus_hwi_loc which reference functions in
On 12/08/2014 11:23 AM, Jan-Benedict Glaw wrote:
On Fri, 2014-11-21 08:45:11 -0500, Andrew MacLeod amacl...@redhat.com wrote:
During the flattening of optabs.h, I updated all the config/* files
which were affected. I've been getting spurious failures with
config-list.mk where my changes would
Changes a few files where ttype is used as a variable. The next patch
changes the branch to use ttype as the name instead of tree_type_ptr.
bootstraps, run tests, etc.
checked into branch.
Andrew
* builtins.c (fold_builtin_atomic_always_lock_free): Don't use ttype as
a variable name.
*
Changes 'tree_type_ptr' to 'ttype' everywhere. The second attachment
is the updated patch which converts the branch to a segregated tree-type
for compilation testing. (remembering that this patch is maintained as
'tree-type.patch' in the source directory).
Andrew
* fold-const.c
While going through the attribute tables to sort out separation or trees
and types, I'm seeing a couple of ports with similar handlers that look
a little odd.
the code sequence in the handler looks like:
if (TREE_CODE (*node) != VAR_DECL
TREE_CODE (*node) != POINTER_TYPE
ever see whatever their actual type is...I've removed those checks
on my x86 box and have no failures.
Andrew
On 11/28/2014 10:46 AM, Andrew MacLeod wrote:
While going through the attribute tables to sort out separation or
trees and types, I'm seeing a couple of ports with similar
On 11/20/2014 03:14 PM, Andrew MacLeod wrote:
On 11/20/2014 03:05 PM, Michael Collison wrote:
This is a part one of two part patch that flattens gimple-streamer.h,
lto-streamer.h and tree-streamer.h. This work is part of the GCC
Re-Architecture effort being led by Andrew MacLeod.
In gimple
First independent infrastructure patch for the branch. These sort of
patches I will commit to the branch without any tree-type specific
changes so I can maintain it as a patch to submit in stage 1 independent
of the overall larger change. I'll make the tree-type specific changes
last.
During the flattening of optabs.h, I updated all the config/* files
which were affected. I've been getting spurious failures with
config-list.mk where my changes would disappear and tracked down why.
I was blissfully unaware that the tilepro ports mul-tables.c file is
actually generated
I've been trying to sort out how to proceed with the gimple_type work,
and the first step always come back to figuring out all the places types
are used. This has turned out to be non-trivial and is difficult to do
in an iterative way. I believe I've found a reasonable way to proceed.
Over
On 11/21/2014 02:45 PM, Diego Novillo wrote:
On Fri, Nov 21, 2014 at 1:48 PM, Andrew MacLeod amacl...@redhat.com wrote:
1 - introduce a TYPE_REF tree node, which is effectively just a 'typed' tree
node, and the TREE_TYPE() field of a TYPE_REF node would point to the type
node. Any routines
On 11/21/2014 03:13 PM, Richard Biener wrote:
On November 21, 2014 8:45:09 PM CET, Diego Novillo dnovi...@google.com wrote:
On Fri, Nov 21, 2014 at 1:48 PM, Andrew MacLeod amacl...@redhat.com
wrote:
1 - introduce a TYPE_REF tree node, which is effectively just a
'typed' tree
node
On 11/21/2014 05:39 PM, Jeff Law wrote:
On 11/21/14 11:48, Andrew MacLeod wrote:
There are a few issues, of course :-)
The biggest issue is what to do with fields which can be either a type
or a tree... ie TREE_VALUE() of a TREE_LIST can be a type, as can a
TREE_VEC element
On 11/20/2014 08:08 AM, Richard Biener wrote:
On Thu, Nov 20, 2014 at 12:05 AM, Andrew MacLeod amacl...@redhat.com wrote:
On 11/19/2014 05:24 PM, David Malcolm wrote:
On Wed, 2014-11-19 at 22:36 +0100, Richard Biener wrote:
On November 19, 2014 10:09:56 PM CET, Andrew MacLeod
amacl
On 11/20/2014 03:05 PM, Michael Collison wrote:
This is a part one of two part patch that flattens gimple-streamer.h,
lto-streamer.h and tree-streamer.h. This work is part of the GCC
Re-Architecture effort being led by Andrew MacLeod.
In gimple-streamer.h I moved all exports for gimple
On 11/19/2014 01:12 PM, David Malcolm wrote:
(A) could become:
greturn *stmt = gsi-as_a_greturn ();
(B) could become:
stmt = gsi-dyn_cast gcall * ();
if (!stmt)
or:
stmt = gsi-dyn_cast_gcall ();
if (!stmt)
or maybe:
stmt = gsi-is_a_gcall ();
if (!stmt)
An earlier
On 11/19/2014 03:43 PM, Richard Biener wrote:
On November 19, 2014 8:26:23 PM CET, Andrew MacLeod amacl...@redhat.com wrote:
On 11/19/2014 01:12 PM, David Malcolm wrote:
(A) could become:
greturn *stmt = gsi-as_a_greturn ();
(B) could become:
stmt = gsi-dyn_cast gcall
On 11/19/2014 05:28 PM, David Malcolm wrote:
On Wed, 2014-11-19 at 17:24 -0500, David Malcolm wrote:
On Wed, 2014-11-19 at 22:36 +0100, Richard Biener wrote:
On November 19, 2014 10:09:56 PM CET, Andrew MacLeod amacl...@redhat.com
wrote:
On 11/19/2014 03:43 PM, Richard Biener wrote
On 11/19/2014 05:24 PM, David Malcolm wrote:
On Wed, 2014-11-19 at 22:36 +0100, Richard Biener wrote:
On November 19, 2014 10:09:56 PM CET, Andrew MacLeod amacl...@redhat.com
wrote:
On 11/19/2014 03:43 PM, Richard Biener wrote:
On November 19, 2014 8:26:23 PM CET, Andrew MacLeod
amacl
On 11/18/2014 09:52 AM, Andrew MacLeod wrote:
On 11/18/2014 09:40 AM, Jason Merrill wrote:
On 11/18/2014 09:26 AM, Andrew MacLeod wrote:
I was poking around attribs.c while trial running my tree-type-safety
stuff, and it triggered something in decl_attributes() that seems fishy
to me
On 11/18/2014 01:36 PM, Jeff Law wrote:
On 11/18/14 09:30, Andrew MacLeod wrote:
I tried doing the if before chaning to TREE_TYPE... absolutely no
effect on the testsuite or anything else :-)
What do you think, should I check this in? What is there is clearly
incorrect.we could also
On 11/13/2014 05:45 AM, Richard Biener wrote:
On Thu, Nov 13, 2014 at 2:41 AM, David Malcolm dmalc...@redhat.com wrote:
On Tue, 2014-11-11 at 11:43 +0100, Richard Biener wrote:
On Tue, Nov 11, 2014 at 8:26 AM, Jakub Jelinek ja...@redhat.com wrote:
On Mon, Nov 10, 2014 at 05:27:50PM -0500,
On 11/13/2014 09:34 AM, Richard Biener wrote:
On Thu, Nov 13, 2014 at 3:24 PM, Andrew MacLeod amacl...@redhat.com wrote:
On 11/13/2014 05:45 AM, Richard Biener wrote:
On Thu, Nov 13, 2014 at 2:41 AM, David Malcolm dmalc...@redhat.com
wrote:
On Tue, 2014-11-11 at 11:43 +0100, Richard Biener
On 11/07/2014 04:31 AM, Andrew Haley wrote:
On 06/11/14 19:05, Andrew MacLeod wrote:
1) Given that the compiler *always* provides support via libatomic now
(even if it is via locks), does that mean that VMSupportsCS8_builtin()
should always return true?
or should we map to that a call
On 11/04/2014 03:13 PM, Andrew MacLeod wrote:
from targhooks.c:
bool
default_builtin_support_vector_misalignment (machine_mode mode,
const_tree type, ...)
{
if (optab_handler (movmisalign_optab, mode) != CODE_FOR_nothing)
return true;
return false;
}
the idea is to move all
On 11/06/2014 01:23 PM, Andrew Haley wrote:
On 11/06/2014 05:57 PM, Andrew MacLeod wrote:
It looks like java is deciding whether or not GCC can inline atomic
operations or not, and if it can't, doesn't want the atomic
operations... which presumably means there is no dependency on
libatomic
java/builtins.c needs to call can_compare_and_swap, which happens to be
provided via optabs.h.
As a result, we see the following in java/builtins.c:
/* FIXME: All these headers are necessary for sync_compare_and_swap.
Front ends should never have to look at that. */
#include rtl.h
#include
On 11/04/2014 12:25 PM, Richard Henderson wrote:
On 11/04/2014 05:28 PM, Andrew MacLeod wrote:
+ bool
+ default_can_compare_and_swap_p (machine_mode mode, bool allow_libcall)
+ {
+ return can_compare_and_swap_p (mode, allow_libcall);
+ }
This is silly. I think the problem you point out can
On 11/04/2014 12:57 PM, Richard Henderson wrote:
On 11/04/2014 06:56 PM, Andrew MacLeod wrote:
On 11/04/2014 12:25 PM, Richard Henderson wrote:
On 11/04/2014 05:28 PM, Andrew MacLeod wrote:
+ bool
+ default_can_compare_and_swap_p (machine_mode mode, bool allow_libcall)
+ {
+ return
On 11/04/2014 02:53 PM, Richard Biener wrote:
On November 4, 2014 7:30:18 PM CET, Andrew MacLeod amacl...@redhat.com wrote:
On 11/04/2014 12:57 PM, Richard Henderson wrote:
On 11/04/2014 06:56 PM, Andrew MacLeod wrote:
On 11/04/2014 12:25 PM, Richard Henderson wrote:
On 11/04/2014 05:28 PM
This patch adjusts optabs.h. which was really sub-work of looking at
expr.h.
I moved the prototypes from expr.h to optabs.h that belong there, and
realigned the stuff in optabs.h to be in the same order as the .c file.
I also moved gen_move_insn from optabs.c to expr.c... a number of new
No so much preamble for this one since cgraph.h is already
representative of only things in cgraph.c. So this is mostly shuffling
of include files.
One short 'interesting' patch, and a couple of longer boring mechanical
ones.
symbol_table::initialize() was moved to cgraph.c. The use of
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 files and
On 10/21/2014 11:48 AM, Jiong Wang wrote:
bootstraps on x86_64-unknown-linux-gnu, and regressions are running... I
expect no regressions because of the nature of the changes. OK to
check in assuming everything is OK?
Happen to start a fresh build
../gcc/configure
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,
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
Rather than trying to flatten basic-block.h and do all the work
associated in one big patch, I'll try to do it in smaller steps :-)
This patch creates cfgrtl.h to maintain the prototypes for functions
exported from cfgrtl.c. For the moment, basic-block.h includes
cfgrtl.h, keeping
Just updated to trunk and I have a compilation error:
/gcc/2014-10-14/gcc/gcc/cp/constexpr.c:3391:29: fatal error:
gt-cp-constexpr.h: No such file or directory
#include gt-cp-constexpr.h
^
I presume its due to :
2014-10-15 Paolo Carlini
On 10/16/2014 10:16 AM, Jakub Jelinek wrote:
On Thu, Oct 16, 2014 at 10:11:33AM -0400, Andrew MacLeod wrote:
Just updated to trunk and I have a compilation error:
/gcc/2014-10-14/gcc/gcc/cp/constexpr.c:3391:29: fatal error:
gt-cp-constexpr.h: No such file or directory
#include gt-cp
In an attempt to not screw up every plugin user again this release, I'll
try to add any flattened includes and any pre-requiresites into
gcc-plugin.h, as discussed here:
https://gcc.gnu.org/ml/gcc/2014-10/msg00127.html
This patch adds those includes to gcc-plugin.h, and also adds tm.h since
On 10/10/2014 04:51 PM, Jeff Law wrote:
On 09/29/14 11:23, Andrew MacLeod wrote:
OK, here's take 2.. I left all the include files except ones which were
duplicated as a result of the flattening. The first one was left, and
any subsequent #Includes of the files were removed. we'll address
Ping... anyone want to take a look?
Andrew
On 09/29/2014 01:23 PM, Andrew MacLeod wrote:
On 09/16/2014 05:23 PM, Andrew MacLeod wrote:
On 09/16/2014 05:12 PM, Joseph S. Myers wrote:
On Tue, 16 Sep 2014, Andrew MacLeod wrote:
I did an include file reduction on all the language/*.[ch
On 10/02/2014 02:14 PM, Segher Boessenkool wrote:
On Thu, Oct 02, 2014 at 06:46:19PM +0100, Richard Sandiford wrote:
Segher Boessenkool seg...@kernel.crashing.org writes:
On Wed, Sep 24, 2014 at 10:54:57AM -0400, Andrew MacLeod wrote:
Is this suppose to be resolved now? I'm still seeing some
On 09/16/2014 05:23 PM, Andrew MacLeod wrote:
On 09/16/2014 05:12 PM, Joseph S. Myers wrote:
On Tue, 16 Sep 2014, Andrew MacLeod wrote:
I did an include file reduction on all the language/*.[ch] and core
*.[ch]
files, but left the target files with the full complement of 7
includes
On 09/24/2014 01:58 PM, Andrew MacLeod wrote:
On 09/24/2014 12:29 PM, Andrew MacLeod wrote:
AH. interesting.
The third run has a gcc.sum that is exactly the same as the first run.
so only the second run differs, and it seems to be from an
alphabetical sort. So run 3 and 1 match
On 09/23/2014 11:33 AM, Richard Sandiford wrote:
Segher Boessenkoolseg...@kernel.crashing.org writes:
On Thu, Sep 18, 2014 at 01:44:55PM -0500, Segher Boessenkool wrote:
I am testing a patch that is just
diff --git a/contrib/dg-extract-results.py b/contrib/dg-extract-results.py
index
On 09/24/2014 12:10 PM, Segher Boessenkool wrote:
On Wed, Sep 24, 2014 at 10:54:57AM -0400, Andrew MacLeod wrote:
On 09/23/2014 11:33 AM, Richard Sandiford wrote:
Your patch instead sorts based on the full test name, including options,
which means that the output no longer matches what you'd
On 09/24/2014 12:29 PM, Andrew MacLeod wrote:
On 09/24/2014 12:10 PM, Segher Boessenkool wrote:
On Wed, Sep 24, 2014 at 10:54:57AM -0400, Andrew MacLeod wrote:
On 09/23/2014 11:33 AM, Richard Sandiford wrote:
Your patch instead sorts based on the full test name, including
options,
which
On 09/22/2014 01:02 PM, Joseph S. Myers wrote:
On Mon, 22 Sep 2014, Andrew MacLeod wrote:
Josephs solution was to identify these and instead put a default definition in
default.h ... then change all the uses to #if instead.. ie,
#if BLAH
This way we can ensure that the definition has been
After being reminded of the tm.h issues brought up last november (here:
https://gcc.gnu.org/ml/gcc-patches/2013-11/msg01731.html ), I started
looking back into it.
The general summary is the any header file which has a conditional on a
target macro could be affected by include file
Has the changes that have gone into the check parallelization made the
.sum file non-deterministic?
I'm seeing a lot of small hunks in different orders which cause my
comparison scripts to show big differences.
I haven't been paying attention to the nature of the make check changes
so Im not
On 09/18/2014 09:01 AM, Jakub Jelinek wrote:
On Thu, Sep 18, 2014 at 08:56:50AM -0400, Andrew MacLeod wrote:
Has the changes that have gone into the check parallelization made the .sum
file non-deterministic?
I'm seeing a lot of small hunks in different orders which cause my
comparison scripts
On 09/18/2014 09:05 AM, Andrew MacLeod wrote:
On 09/18/2014 09:01 AM, Jakub Jelinek wrote:
On Thu, Sep 18, 2014 at 08:56:50AM -0400, Andrew MacLeod wrote:
Has the changes that have gone into the check parallelization made
the .sum
file non-deterministic?
I'm seeing a lot of small hunks
Im currently focusing on flattening middle/backend files which are
included from front-ends files so we can clean up the include interface
a bit.
This flattens function.h. It wasn't too bad, there were a few
prototypes and defines in expr.h and rtl.h that belong in function.h,
and a couple
On 09/16/2014 05:12 PM, Joseph S. Myers wrote:
On Tue, 16 Sep 2014, Andrew MacLeod wrote:
I did an include file reduction on all the language/*.[ch] and core *.[ch]
files, but left the target files with the full complement of 7 includes that
function.h use to have. Its probably easier when
On 07/17/2014 07:10 AM, Richard Biener wrote:
Just to mention - the regimplification removal and a gimple-building
facility is provided on the match-and-simplify branch worked on by
me and Prathamesh (a GSoC student this year). I'll present about
this during the Cauldron with the title Unifying
I don't have the time I'd like to since I'm running about a month behind
schedule, but I wanted to make the code I've been experimenting with
available a bit before cauldron so we can discuss it both here and in
the upcoming BOF.
I created a quick overview document, and managed to keep it to
I'd like to move this rather large inline function out of the header
file and into the .c file. The function has the following comment:
/* ??? This is a static inline here to avoid the overhead of the
indirect calls
+to VALUEIZE. But is this overhead really that significant? And
should
Furthering the include file restructuring, this patch fixes the header
files for builtins.h. The prototypes were spread between tree.h, expr.h
and fold-const.h.
* There were 5 build_* routines in builtins.c that really should be in
tree.c. They are used all over the place. The prototypes
This is the second set of patches which updates the #includes required
for compilation. I've reduced it to the base required set, except for
the target config files... Most seem to require it, so in the interest
of not breaking a target, I simply include builtins.h in all target
config files
On 06/02/2014 01:30 PM, Jeff Law wrote:
* Finally, fortran/trans.c was calling fold_builtin_call_array directly.
That means it would have needed builtins.h which caused issues since
builtins.h defines struct target_builtins and uses
FIRST_PSEUDO_REGISTER... which is defined within the target
On 04/24/2014 04:33 AM, Richard Biener wrote:
On Wed, Apr 23, 2014 at 11:23 PM, Jeff Law l...@redhat.com wrote:
On 04/23/14 15:13, David Malcolm wrote:
On Wed, 2014-04-23 at 15:04 -0600, Jeff Law wrote:
On 04/21/14 10:56, David Malcolm wrote:
This updates all of the gimple_bind_* accessors
On 04/23/2014 10:42 AM, Michael Matz wrote:
Hi,
On Mon, 21 Apr 2014, David Malcolm wrote:
case GIMPLE_SWITCH:
dump_gimple_switch (buffer, gs-as_a_gimple_switch (), spc, flags);
break;
where the -as_a_gimple_switch is a no-op cast from gimple to the more
concrete
On 04/23/2014 10:19 AM, Richard Biener wrote:
On Tue, Apr 22, 2014 at 9:42 PM, Richard Biener
richard.guent...@gmail.com wrote:
On April 22, 2014 8:56:56 PM CEST, Richard Sandiford
rdsandif...@googlemail.com wrote:
David Malcolm dmalc...@redhat.com writes:
Alternatively we could change the
On 04/22/2014 04:03 AM, Richard Sandiford wrote:
First of all, thanks a lot for doing this. Maybe one day we'll have
the same in rtl :-)
But...
David Malcolm dmalc...@redhat.com writes:
In doing the checked downcasts I ran into the verbosity of the as_a
API (in our is-a.h). I first tried
On 04/22/2014 01:50 PM, David Malcolm wrote:
On Tue, 2014-04-22 at 09:05 -0400, Andrew MacLeod wrote:
Of course, it would be ideal if we could use 'gimple' as the namespace,
but that is currently taken by the gimple statement type... I'd even go
so far as to propose that 'gimple' should
On 04/22/2014 02:56 PM, Richard Sandiford wrote:
David Malcolm dmalc...@redhat.com writes:
Alternatively we could change the is-a.h API to eliminate this
discrepancy, and keep the typedefs; giving something like the following:
static void
dump_gimple_switch (pretty_printer *buffer,
On 01/07/2014 06:47 PM, Xinliang David Li wrote:
A related question. I have not followed the header file restructuring
discussion. Is there a documentation on header file structure and how
they are organized? In a new .c file, simply including gimple.h would
require many rounds of iterations to
On 12/22/2013 01:27 PM, Jan Hubicka wrote:
I believe when the code was created by moving it from elsehwre, the copyright
should say
original date of gcov-io.h.
+
+#include tconfig.h
+#include tsystem.h
+#include coretypes.h
+#include tm.h
+#include libgcc_tm.h
I would really like
On 01/06/2014 09:37 AM, Jan Hubicka wrote:
On 12/22/2013 01:27 PM, Jan Hubicka wrote:
I believe when the code was created by moving it from elsehwre, the copyright
should say
original date of gcov-io.h.
+
+#include tconfig.h
+#include tsystem.h
+#include coretypes.h
+#include tm.h
+#include
On 12/13/2013 10:58 AM, David Malcolm wrote:
{
gimple stmt = SSA_NAME_DEF_STMT (x);
@@ -2162,7 +2162,7 @@ chain_of_csts_start (struct loop *loop, tree x)
if (gimple_code (stmt) == GIMPLE_PHI)
{
if (bb == loop-header)
- return stmt;
+ return
On 11/27/2013 05:51 PM, Jeff Law wrote:
On 11/27/13 15:30, Andrew MacLeod wrote:
On 11/27/2013 05:16 PM, Jeff Law wrote:
On 11/27/13 14:30, Andrew MacLeod wrote:
mailer added html again...
When trying some of my updated prototype changes on trunk
mailer added html again...
When trying some of my updated prototype changes on trunk, the code
tripped over this segment in ipa-prop.c :
lhs = gimple_assign_lhs (stmt);
rhs = gimple_assign_rhs1 (stmt);
if (!is_gimple_reg_type (rhs)
On 11/27/2013 05:16 PM, Jeff Law wrote:
On 11/27/13 14:30, Andrew MacLeod wrote:
mailer added html again...
When trying some of my updated prototype changes on trunk, the code
tripped over this segment in ipa-prop.c :
lhs = gimple_assign_lhs
On 11/27/2013 05:30 PM, Andrew MacLeod wrote:
On 11/27/2013 05:16 PM, Jeff Law wrote:
On 11/27/13 14:30, Andrew MacLeod wrote:
mailer added html again...
When trying some of my updated prototype changes on trunk, the code
tripped over this segment
On 11/22/2013 06:21 AM, Richard Biener wrote:
On Thu, Nov 21, 2013 at 11:46 PM, Andrew MacLeod amacl...@redhat.com wrote:
I'd like to check in this code from the C11 branch so that it is present in
4.9.
Its adds a target hook which can be used to override the default alignment
of an atomic
On 11/21/2013 02:31 PM, Jeff Law wrote:
On 11/21/13 11:15, Andrew MacLeod wrote:
This bootstraps on x86_64-unknown-linux-gnu, and regressions are
currently running. Assuming it passes fine, OK?
patch#1 in the series is fine too.
Checked in as revision 205272.
Ian, here is the go
On 11/21/2013 06:40 PM, Hans-Peter Nilsson wrote:
On Thu, 21 Nov 2013, Hans-Peter Nilsson wrote:
with this/these patches
at least I'll be able to tell people that _Atomic for C11 works.
Oh right, gcc still doesn't remove target-introduced manual
alignment checks (when expanding atomic
I'd like to check in this code from the C11 branch so that it is present
in 4.9.
Its adds a target hook which can be used to override the default
alignment of an atomic type when used with C11's _Atomic qualifier.
There are a couple of ports which have stricter alignment requirements
for an
On 11/21/2013 05:42 PM, Jakub Jelinek wrote:
On Thu, Nov 21, 2013 at 03:24:55PM -0700, Jeff Law wrote:
On 11/21/13 15:19, Jakub Jelinek wrote:
On Mon, Nov 18, 2013 at 03:25:52PM -0500, David Malcolm wrote:
So is there some reason the GIMPLE_CHECK was left in here rather than
doing the
On 11/21/2013 03:07 PM, Jeff Law wrote:
On 11/21/13 13:04, Andrew MacLeod wrote:
On 11/21/2013 02:26 PM, Jeff Law wrote:
On 11/21/13 11:15, Andrew MacLeod wrote:
Is there anything in particular one needs to do for plugins? I
thought I
saw a patch somewhere that changed something
On 11/21/2013 06:23 PM, Hans-Peter Nilsson wrote:
On Thu, 21 Nov 2013, Andrew MacLeod wrote:
I can bootstrap and check this on x86 to make sure it doesnt affect anything,
and you can fool with it and see if you can get your desired results with your
port.
Success!
For the record, tested
On 11/21/2013 05:46 PM, Andrew MacLeod wrote:
I'd like to check in this code from the C11 branch so that it is
present in 4.9.
Its adds a target hook which can be used to override the default
alignment of an atomic type when used with C11's _Atomic qualifier.
There are a couple of ports
The final gimple re-org patch!
These patches move the #includes out of gimple.h and into the .c files
which include gimple.h. They are:
#include pointer-set.h
#include hash-table.h
#include vec.h
#include ggc.h
#include basic-block.h
#include tree-ssa-alias.h
#include internal-fn.h
#include
On 11/21/2013 06:05 AM, Hans-Peter Nilsson wrote:
On Tue, 5 Nov 2013, Joseph S. Myers wrote:
Thanks for doing this! However, without examples I have trouble
reading out the bits I need as a target maintainer, and I can't
read out the answers from the patch, so pardon a few questions.
On 11/21/2013 10:20 AM, Hans-Peter Nilsson wrote:
On Thu, 21 Nov 2013, Andrew MacLeod wrote:
Or is that part also required for
anything-other-than-ordinary-C-type alignment for the target;
say, natural 4-byte alignment of 4-byte-types for targets where
alignment is otherwise packed; where only
On 11/21/2013 11:32 AM, Joseph S. Myers wrote:
On Thu, 21 Nov 2013, Andrew MacLeod wrote:
I'm trying to avoid ABI breakage of course. I'd rather not have
to ask people not to use _Atomic with 4.9 for CRIS ports using
official releases or have ABI breakage with the next release.
Maybe there's
On 11/21/2013 01:15 PM, Andrew MacLeod wrote:
The third patch has the config/* target changes, as well as a few
testcases. I did *not* trim out includes for the targets since I
got caught earlier with targets requiring some files on only some
configurations. I did go through an remove any
On 11/21/2013 01:15 PM, Andrew MacLeod wrote:
The second patch has the language front end changes. its only the
${language}-gimplify.c files which now actually require gimple.h
itself (yay). I also trimmed out the #includes which were introduced
but not required there as well.
* ada
On 11/21/2013 02:26 PM, Jeff Law wrote:
On 11/21/13 11:15, Andrew MacLeod wrote:
Is there anything in particular one needs to do for plugins? I thought I
saw a patch somewhere that changed something in the Makefile, but don't
know if that is actually required since I never did that for any
This has been bugging me since I moved it out of gimple.h to gimplify.h.
The gimplify context structure was exposed in the header file to allow a
few other files to push and pop contexts off the gimplification stack.
Unfortunately, the struct contains a hash-table template, which means it
On 11/20/2013 08:35 AM, Andrew MacLeod wrote:
Bootstraps on x86_64-unknown-linux-gnu with no new regressions. OK for
mainline?
Andrew
And I've already fixed the typo in the changelog :-) I had it open in a
window but hadn't saved it when I created the patch.
Andrew
On 11/20/2013 08:44 AM, Jakub Jelinek wrote:
On Wed, Nov 20, 2013 at 08:35:28AM -0500, Andrew MacLeod wrote:
I also hacked up the compiler to report what the 'top' of the stack
was for a compilation unit. I then ran it through a bootstrap and
full testsuite run of all languages, and looked
On 11/20/2013 09:12 AM, Richard Biener wrote:
On Wed, Nov 20, 2013 at 2:35 PM, Andrew MacLeod amacl...@redhat.com wrote:
This has been bugging me since I moved it out of gimple.h to gimplify.h.
The gimplify context structure was exposed in the header file to allow a few
other files to push
On 11/20/2013 10:51 AM, Richard Biener wrote:
On Wed, Nov 20, 2013 at 4:06 PM, Trevor Saunders tsaund...@mozilla.com wrote:
On Wed, Nov 20, 2013 at 03:18:07PM +0100, Richard Biener wrote:
On Wed, Nov 20, 2013 at 3:16 PM, Jakub Jelinek ja...@redhat.com wrote:
On Wed, Nov 20, 2013 at 03:12:34PM
On 11/20/2013 11:30 AM, Andrew MacLeod wrote:
On 11/20/2013 10:51 AM, Richard Biener wrote:
On Wed, Nov 20, 2013 at 4:06 PM, Trevor Saunders
tsaund...@mozilla.com wrote:
On Wed, Nov 20, 2013 at 03:18:07PM +0100, Richard Biener wrote:
On Wed, Nov 20, 2013 at 3:16 PM, Jakub Jelinek ja
On 11/20/2013 01:40 PM, Jeff Law wrote:
On 11/20/13 09:47, Andrew MacLeod wrote:
* gimplify.h (gimplify_hasher : typed_free_remove, struct
gimplify_ctx):
Move to gimplify.c.
* gimplify.c (gimplify_hasher:typed_free_remove): Relocate here.
(struct gimplify_ctx): Relocate here
On 11/20/2013 02:58 PM, Jeff Law wrote:
On 11/20/13 12:18, Andrew MacLeod wrote:
And per Jakubs suggestion, I'll use XNEW... along with the changelog
oversite.
Assuming that all works, and no regressions, OK?
Yup.
jeff
Bootstrapped on x86_64-unknown-linux-gnu with no new regressions
graphite-sese-to-poly.c needs expr.h to compile. Fixed thusly and
checked in as revision 205027.
Andrew
* graphite-sese-to-poly.c: Include expr.h.
Index: graphite-sese-to-poly.c
===
*** graphite-sese-to-poly.c (revision 205024)
On 11/18/2013 01:54 PM, David Malcolm wrote:
On Thu, 2013-11-14 at 00:37 -0700, Jeff Law wrote:
On 10/31/13 10:26, David Malcolm wrote:
* gimple.h (is_a_helper const gimple_statement_with_ops::test): New.
(is_a_helper gimple_statement_with_ops::test): New.
(is_a_helper
901 - 1000 of 1326 matches
Mail list logo
