Hi Tobias,
As testing showed, it didn't fix the real-world code: ForTrilinos's
ForTrilinos_ADT_3D_Burgers_6th_Pade did still fail as it has:
*_F.DA65 = matrix_diff_x (parm.621);
_F.DA66 = ax-epetra_rowmatrix.universal; // Deref of ax!
Build and regtested on
On Sun, Sep 15, 2013 at 07:41:24PM +0400, Michael V. Zolotukhin wrote:
Libgomp will start N-1 new threads, and all of them would want to look up
mappings for i1,i2,...iK in the splay tree. The first one wouldn't find
anything and would map and insert all the values to the tree. But the
Thomas Koenig wrote:
Build and regtested on x86-64-gnu-linux.
OK?
The patch is OK, also for 4.8. Please add a test case which also
checks for the ForTrilinos failure.
Thanks for the review. I have now committed the current patch as Rev.
202609.
I will later try to create a test case,
Yes, splay tree can get totally unbalanced and you can have a linear lookup
time, the O(log n) lookup time is amortized. But, if you e.g. really do
lookup sorted keys (which is not given, the compiler puts vars into the
clauses based on the user order or in the order references to those vars
I guess I can't really expect to gain an approval to import the
upstream libtool into gcc. Even *I* don't really trust me, although
having looked at it a little I think I could even update
libjava/libltdl. So how about just continuing the status quo and
applying a libtool patch that is already
---
gcc/cp/pt.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/gcc/cp/pt.c b/gcc/cp/pt.c
index 2ef160a..ed08dca 100644
--- a/gcc/cp/pt.c
+++ b/gcc/cp/pt.c
@@ -21041,7 +21041,7 @@ static tree
make_auto_1 (tree name)
{
tree au = cxx_make_type (TEMPLATE_TYPE_PARM);
-
From: abutcher abutcher@138bc75d-0d04-0410-961f-82ee72b054a4
* parser.c (cp_parser_lambda_declarator_opt): Accept template parameter
list with std=c++1y or std=gnu++1y.
(cp_parser_lambda_body): Don't call 'expand_or_defer_fn' for lambda call
operator template to
From: abutcher abutcher@138bc75d-0d04-0410-961f-82ee72b054a4
gcc/cp/
* cp-tree.h (type_uses_auto_or_concept): Declare.
(is_auto_or_concept): Declare.
* decl.c (grokdeclarator): Allow 'auto' parameters in lambdas with
-std=gnu++1y or -std=c++1y or, as a GNU
Richard Biener richard.guent...@gmail.com writes:
On Fri, Sep 13, 2013 at 10:33 AM, Richard Sandiford
rdsandif...@googlemail.com wrote:
Richard Biener richard.guent...@gmail.com writes:
Yeah. I don't think it makes sense to canonise PSI to 32 bits when we
know it has fewer than 32 bits.
Excellent. This now supports the variadic generic lambda from the spec
(albeit without the auto parameter pack)
auto vglambda = [](auto printer)
{
// TODO: return [=](auto ... ts) // OK: ts is a function
parameter pack
return [=] typename... T (T ... ts) // OK: ts is a
On Mon, Sep 16, 2013 at 11:15:16AM +0400, Michael V. Zolotukhin wrote:
Yes, splay tree can get totally unbalanced and you can have a linear lookup
time, the O(log n) lookup time is amortized. But, if you e.g. really do
lookup sorted keys (which is not given, the compiler puts vars into the
On Sun, Sep 15, 2013 at 09:08:00PM +0200, Jan Hubicka wrote:
2013-09-13 Jakub Jelinek ja...@redhat.com
* ipa-prop.c (ipa_compute_jump_functions_for_edge): Return early
for internal calls.
That seems resonable. I wonder if we want to consider internal calls to form
callgarph
---
gcc/cp/pt.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/gcc/cp/pt.c b/gcc/cp/pt.c
index 2ef160a..ed08dca 100644
--- a/gcc/cp/pt.c
+++ b/gcc/cp/pt.c
@@ -21041,7 +21041,7 @@ static tree
make_auto_1 (tree name)
{
tree au = cxx_make_type
No. If you insert 1 to 100 into a splay tree in ascending order (that will
give you a totally unbalanced tree), and then lookup 1 to 100 in the
ascending order again, then the lookup of 1 will be expensive (100
comparisons), but then for each following lookup it
will cost just 2 comparisons,
On 16.09.2013 09:02, Eric Botcazou wrote:
---
gcc/cp/pt.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/gcc/cp/pt.c b/gcc/cp/pt.c
index 2ef160a..ed08dca 100644
--- a/gcc/cp/pt.c
+++ b/gcc/cp/pt.c
@@ -21041,7 +21041,7 @@ static tree
make_auto_1 (tree name)
{
tree au =
ping...
On Wed, 4 Sep 2013 18:45:39, Bernd Edlinger wrote:
On Tue, 3 Sep 2013 12:31:50, Richard Biener wrote:
On Fri, Aug 30, 2013 at 6:43 PM, Bernd Edlinger
bernd.edlin...@hotmail.de wrote:
Now I think this is good opportunity for a simple heuristic:
If a statement is at loop level 1 we
Hello all,
I'm pinging the patch (of september 2nd) on
http://gcc.gnu.org/ml/gcc-patches/2013-09/msg00036.html
gcc/ChangeLog entry
2013-09-16 Basile Starynkevitch bas...@starynkevitch.net
* gengtype.c (file_rules): Added rule for *.cc files.
Hello All,
I'm pinging again my small patch to accept = inside plugin arguments
http://gcc.gnu.org/ml/gcc-patches/2013-08/msg00382.html
http://gcc.gnu.org/ml/gcc-patches/2013-09/msg00037.html
# gcc/ChangeLog entry
2013-09-16 Basile Starynkevitch bas...@starynkevitch.net
*
On 13/09/13 19:39, James Greenhalgh wrote:
Hi,
This patch adds intrinsics for vcopyq_laneq_pfsu8,16,32,64.
These are implemented in an optimal way using the vget_lane and vset_lane
intrinsics and a combine pattern.
I've added a testcase and run a full regression run for aarch64-none-elf.
On 13/09/13 19:28, James Greenhalgh wrote:
Hi,
This patch converts the vmulq_laneq_fsu16,32,64 intrinsics
in arm_neon.h to a C implementation.
OK
/Marcus
On 13/09/13 19:31, James Greenhalgh wrote:
Hi,
This patch reimpliments the vmlas_lane and the fmas
intrinsics in C, and adds new combiner patterns to support
this.
OK
/Marcus
*ping*
Cheers,
James
On Fri, Sep 06, 2013 at 04:06:08PM +0100, James Greenhalgh wrote:
Hi,
vcvtx_high_f32_f64 should have two parameters, a float32x2 which
provides the lower half of the target vector, and a float64x2
which will be converted to the higher half of the target vector.
On Fri, Sep 13, 2013 at 9:15 PM, Andrew MacLeod amacl...@redhat.com wrote:
On 09/13/2013 11:11 AM, Andrew MacLeod wrote:
On 09/13/2013 03:54 AM, Richard Biener wrote:
On Thu, Sep 12, 2013 at 11:09 PM, Andrew MacLeod amacl...@redhat.com
wrote:
There are 2 parts of tre-ssa-ter.c to address.
Adding Eric and Steven in the loop as it is RTL related.
Thanks
Yvan
On 11 September 2013 21:08, Yvan Roux yvan.r...@linaro.org wrote:
Here is the new patch discussed in the other thread.
Thanks
Yvan
2013-09-11 Yvan Roux yvan.r...@linaro.org
Vladimir Makarov
On 06/09/13 16:06, James Greenhalgh wrote:
gcc/
2013-09-06 James Greenhalgh james.greenha...@arm.com
* config/aarch64/arm_neon.h
(vcvtx_high_f32_f64): Fix parameters.
OK
/Marcus
On Sat, Sep 14, 2013 at 8:10 AM, Xinliang David Li davi...@google.com wrote:
tree if conversion is an enabler pass for vectorization, so by
default, it is only turned on when vectorization is on, but may also
depend on the optimization level. Currently, the logic to handle this
is in the gate
On Sat, Sep 14, 2013 at 12:41 PM, Jan-Benedict Glaw jbg...@lug-owl.de wrote:
Hi!
My Build Robot[1] found this recent commit to break Alpha:
* tree-flow.h (FREE_SSANAMES): Move to tree-ssanames.c
(SSANAMES, MODIFIED_NORETURN_CALLS, DEFAULT_DEFS, ptr_info_def,
Hello!
My Build Robot[1] found this recent commit to break Alpha:
* tree-flow.h (FREE_SSANAMES): Move to tree-ssanames.c
(SSANAMES, MODIFIED_NORETURN_CALLS, DEFAULT_DEFS, ptr_info_def,
num_ssa_names, ssa_name): Move to tree-ssanames.h + prototypes.
* tree-flow-inline.h (make_ssa_name,
On Fri, Sep 13, 2013 at 10:23 PM, Mike Stump mikest...@comcast.net wrote:
On Sep 13, 2013, at 1:08 AM, Richard Sandiford rdsandif...@googlemail.com
wrote:
We don't really model that properly yet. Partial modes are just defined
using something like:
PARTIAL_INT_MODE (SI);
True, but, all
Any comment/review on this patch ?
On Sep 3, 2013, at 4:08 PM, Tristan Gingold ging...@adacore.com wrote:
Hi,
The field state-ehp_region wasn't updated before lowering constructs in the
eh
path of EH_ELSE. As a consequence, __builtin_eh_pointer is lowered to 0 (or
possibly to a wrong
On Fri, Sep 13, 2013 at 4:36 PM, H.J. Lu hjl.to...@gmail.com wrote:
Did you check the above with x32, where Pmode != word_mode on x86_64?
The inner UNSPEC will be generated in SImode, but the matching pattern
+(define_insn *mode_mk
+ [(set (match_operand:BND 0 register_operand =B)
+
On Fri, Sep 13, 2013 at 12:18 PM, Ilya Enkovich enkovich@gmail.com wrote:
2013/9/11 Uros Bizjak ubiz...@gmail.com:
On Tue, Sep 10, 2013 at 1:38 PM, Ilya Enkovich enkovich@gmail.com
wrote:
Ping^4
Could please someone look at this patch? It is mostly i386 target
specific and is basic
Hi Marc,
On 09/15/2013 11:12 AM, Marc Glisse wrote:
I had to separate the constructor that takes an allocator from the
default constructor in debug/profile, since in release the noexcept
only applies to one of them (and the testsuite asserts that release
and debug agree on this). An
On Fri, Sep 13, 2013 at 4:29 PM, Eric Botcazou ebotca...@adacore.com wrote:
Hi,
in Ada parameters can be passed by reference: in this case, the address of the
argument is directly passed to the callee, which dereferences it to access the
argument; now Ada also enables -fexceptions
On Fri, Sep 13, 2013 at 10:47:01PM +0100, Andrew Pinski wrote:
On Fri, Sep 13, 2013 at 11:57 AM, James Greenhalgh
james.greenha...@arm.com wrote:
Should return '1' whatever your endianness. Throwing together a quick
test case, that is the case for current trunk. Do you have a testcase
On Mon, Sep 16, 2013 at 10:29:37AM +0100, James Greenhalgh wrote:
The little endian compiler would lay memory out as:
0x0 ...0x8
| 0b | 0a | 1b | 1a | 2b | 2a | 3b | 3a |
And the big endian compiler would lay out memory as:
0x0 ...
On Fri, Sep 13, 2013 at 07:18:24PM +, Joseph S. Myers wrote:
On Fri, 13 Sep 2013, Marek Polacek wrote:
This is kind of fugly, but don't have anything better at the moment.
2013-09-13 Marek Polacek pola...@redhat.com
PR sanitizer/58413
c-family/
* c-ubsan.c
On Fri, Sep 13, 2013 at 4:56 PM, Eric Botcazou ebotca...@adacore.com wrote:
Hi,
in Ada we can have misaligned array components in record types, that is to say
object with BLKmode whose alignment is lower than that of their type. In this
case IVOPTS can generate misaligned TARGET_MEM_REFs,
On Fri, Sep 13, 2013 at 6:45 PM, Joseph S. Myers
jos...@codesourcery.com wrote:
On Fri, 13 Sep 2013, Richard Biener wrote:
@@ -1691,6 +1695,12 @@ common_handle_option (struct gcc_options
opts-x_flag_ipa_reference = false;
break;
+case OPT_ftree_vectorize:
+ if
On Fri, Sep 13, 2013 at 6:56 PM, Xinliang David Li davi...@google.com wrote:
Updated patch implementing the logic that more specific option wins.
Ok for trunk?
@@ -2305,8 +2305,8 @@ omp_max_vf (void)
{
if (!optimize
|| optimize_debug
- || (!flag_tree_vectorize
-
Hi all,
The test g++.dg/debug/ra1.C now gives an extra warning on arm:
warning: width of 'tree_base::code' exceeds its type [enabled by default]
which causes the test to fail.
This patch adds -fno-short-enums to it to fix the warning for targets
with short enums (including arm)
Tested to
On Fri, Sep 13, 2013 at 5:16 PM, Xinliang David Li davi...@google.com wrote:
On Fri, Sep 13, 2013 at 1:30 AM, Richard Biener
richard.guent...@gmail.com wrote:
On Thu, Sep 12, 2013 at 10:31 PM, Xinliang David Li davi...@google.com
wrote:
Currently -ftree-vectorize turns on both loop and slp
On Fri, Sep 13, 2013 at 8:06 PM, Cong Hou co...@google.com wrote:
A new test case is added to testsuite/gcc.dg/vect, which will fail
without this patch and pass with it. Bootstrap also get passed. No
additional test failure is introduced.
The new test case includes a dot product on two arrays
On Mon, Sep 16, 2013 at 12:07:37PM +0200, Richard Biener wrote:
On Fri, Sep 13, 2013 at 6:56 PM, Xinliang David Li davi...@google.com wrote:
Updated patch implementing the logic that more specific option wins.
Ok for trunk?
@@ -2305,8 +2305,8 @@ omp_max_vf (void)
{
if (!optimize
On Thu, Sep 12, 2013 at 04:05:48PM +, Joseph S. Myers wrote:
On Thu, 12 Sep 2013, Joseph S. Myers wrote:
(Actually, I believe sizes (in bytes) greater than target PTRDIFF_MAX, not
just SIZE_MAX, should be caught, because pointer subtraction cannot work
reliably with larger objects.
On Mon, Sep 16, 2013 at 11:06 AM, Uros Bizjak ubiz...@gmail.com wrote:
My Build Robot[1] found this recent commit to break Alpha:
* tree-flow.h (FREE_SSANAMES): Move to tree-ssanames.c
(SSANAMES, MODIFIED_NORETURN_CALLS, DEFAULT_DEFS, ptr_info_def,
num_ssa_names, ssa_name): Move to
Ping.
On 09/09/13 10:56, Kyrylo Tkachov wrote:
[Resending, since I was away and not pinging it]
Hi all,
In PR58088 the constant folder goes into an infinite recursion and runs out of
stack space because of two conflicting optimisations:
(X * C1) C2 plays dirty when nested inside an IOR
On Mon, 16 Sep 2013, Paolo Carlini wrote:
On 09/15/2013 11:12 AM, Marc Glisse wrote:
I had to separate the constructor that takes an allocator from the default
constructor in debug/profile, since in release the noexcept only applies to
one of them (and the testsuite asserts that release and
On Mon, 2013-09-16 13:01:40 +0200, Uros Bizjak ubiz...@gmail.com wrote:
On Mon, Sep 16, 2013 at 11:06 AM, Uros Bizjak ubiz...@gmail.com wrote:
My Build Robot[1] found this recent commit to break Alpha:
I think you can remove the tree-flow.h include and you need to update the
dependencies
On Mon, 16 Sep 2013, Uros Bizjak wrote:
On Mon, Sep 16, 2013 at 11:06 AM, Uros Bizjak ubiz...@gmail.com wrote:
My Build Robot[1] found this recent commit to break Alpha:
* tree-flow.h (FREE_SSANAMES): Move to tree-ssanames.c
(SSANAMES, MODIFIED_NORETURN_CALLS, DEFAULT_DEFS,
On Mon, Sep 16, 2013 at 1:36 PM, Jan-Benedict Glaw jbg...@lug-owl.de wrote:
On Mon, 2013-09-16 13:01:40 +0200, Uros Bizjak ubiz...@gmail.com wrote:
On Mon, Sep 16, 2013 at 11:06 AM, Uros Bizjak ubiz...@gmail.com wrote:
My Build Robot[1] found this recent commit to break Alpha:
I think you
Hi,
this patch solves problem with can_refer_decl_in_current_unit_p always
returning true for static functions. The devirtualization code can look
up a method in anonymous namespace that has been optimized out due to
lack of references to any of vtables mentioning it. In this case we need
to
On Mon, 16 Sep 2013, Uros Bizjak wrote:
On Mon, Sep 16, 2013 at 1:36 PM, Jan-Benedict Glaw jbg...@lug-owl.de wrote:
On Mon, 2013-09-16 13:01:40 +0200, Uros Bizjak ubiz...@gmail.com wrote:
On Mon, Sep 16, 2013 at 11:06 AM, Uros Bizjak ubiz...@gmail.com wrote:
My Build Robot[1] found this
Hi Guys,
The new MSP430 target has a few limitations which show up as
unexpected failures in the GCC testsuite. I would like to apply the
patch below to update target-supports.exp with this information.
Applying the patch results in a drop of 133 unexpected failures (per
multilib).
On 15 September 2013 10:12, Marc Glisse wrote:
PR libstdc++/58338
* include/bits/stl_vector.h
(_Vector_impl::_Vector_impl(_Tp_alloc_type const),
_Vector_impl::_Vector_impl(_Tp_alloc_type),
_Vector_impl::_M_swap_data,
On Mon, 16 Sep 2013, Jonathan Wakely wrote:
Are you sure the noexcept on the destructors is useless?
Ok, I am putting it back in.
--
Marc Glisse
A rather obvious patch.
Build and regtested on x86-64-gnu-linux.
OK for the trunk?
Looks good to me!
Thanks,
Janus
Hi All,
Here is 1-line fix which improves Atom performance by better distance
estimation. We got ~20% speedup on one of bench from eembc2.0 with
this fix.
Bootstrapping and regression testing were successful for x86-64.
Is it OK for trunk?
ChangeLog:
2013-09-16 Yuri Rumyantsev
On 09/12/2013 06:05 PM, Joseph S. Myers wrote:
On Thu, 12 Sep 2013, Joseph S. Myers wrote:
(Actually, I believe sizes (in bytes) greater than target PTRDIFF_MAX, not
just SIZE_MAX, should be caught, because pointer subtraction cannot work
reliably with larger objects. So it's not just when
The following fixes PR58432 - I forgot to seed partitions from
PHI nodes that have uses on the exit edge.
Bootstrap and regtest running on x86_64-unknown-linux-gnu.
Richard.
2013-09-16 Richard Biener rguent...@suse.de
PR tree-optimization/58432
* tree-loop-distribution.c
On Mon, Sep 16, 2013 at 1:57 PM, Richard Biener rguent...@suse.de wrote:
My Build Robot[1] found this recent commit to break Alpha:
I think you can remove the tree-flow.h include and you need to update the
dependencies in gcc/Makefile.in.
However, we still need tree-flow.h, but
On Fri, Sep 13, 2013 at 11:25 AM, Diego Novillo dnovi...@google.com wrote:
On Fri, Sep 13, 2013 at 11:07 AM, Jakub Jelinek ja...@redhat.com wrote:
E.g. today I've noticed you've lost OMP_CLAUSE_LINEAR_NO_COPYIN
comment that has been added to tree.h recently, but you haven't
actually moved it
On Mon, Sep 16, 2013 at 09:39:27AM -0400, Diego Novillo wrote:
On Fri, Sep 13, 2013 at 11:25 AM, Diego Novillo dnovi...@google.com wrote:
On Fri, Sep 13, 2013 at 11:07 AM, Jakub Jelinek ja...@redhat.com wrote:
E.g. today I've noticed you've lost OMP_CLAUSE_LINEAR_NO_COPYIN
comment that
On Mon, Sep 16, 2013 at 2:50 PM, Yuri Rumyantsev ysrum...@gmail.com wrote:
Hi All,
Here is 1-line fix which improves Atom performance by better distance
estimation. We got ~20% speedup on one of bench from eembc2.0 with
this fix.
Bootstrapping and regression testing were successful for
On Mon, 16 Sep 2013, Kugan wrote:
Hi,
Updated the patch to the latest changes in trunk that splits tree.h. I also
noticed an error in printing double_int and fixed it.
Is this OK?
print_gimple_stmt (dump_file, stmt, 0,
-TDF_SLIM | (dump_flags TDF_LINENO));
Hi,
On Mon, 16 Sep 2013, Uros Bizjak wrote:
Where? I don't see config/alpha.c listed anywhere.
Must be in one of the fragments in config/ or config/alpha. For
i386 it's config/i386/t-i386
Well, we have a problem here. The dependencies from t-* files are
ignored
Why do you think so?
Uros,
Thanks for your review.
I attached modified patch - is it OK for you now?
2013/9/16 Uros Bizjak ubiz...@gmail.com:
On Mon, Sep 16, 2013 at 2:50 PM, Yuri Rumyantsev ysrum...@gmail.com wrote:
Hi All,
Here is 1-line fix which improves Atom performance by better distance
estimation. We
On 09/16/2013 05:05 AM, Richard Biener wrote:
On Sat, Sep 14, 2013 at 12:41 PM, Jan-Benedict Glaw jbg...@lug-owl.de wrote:
Hi!
My Build Robot[1] found this recent commit to break Alpha:
* tree-flow.h (FREE_SSANAMES): Move to tree-ssanames.c
(SSANAMES,
On Mon, Sep 16, 2013 at 4:20 PM, Michael Matz m...@suse.de wrote:
Where? I don't see config/alpha.c listed anywhere.
Must be in one of the fragments in config/ or config/alpha. For
i386 it's config/i386/t-i386
Well, we have a problem here. The dependencies from t-* files are
ignored
On Mon, Sep 16, 2013 at 4:26 PM, Yuri Rumyantsev ysrum...@gmail.com wrote:
Thanks for your review.
I attached modified patch - is it OK for you now?
I can't understand the comment, so perhaps a native English speaking
person could help here.
The patch with a fixed comment is OK otherwise.
Richard Where's that automatic dependency patch blocked ...
No build machinery maintainer has reviewed it.
Tom
On 09/16/2013 04:55 AM, Richard Biener wrote:
On Fri, Sep 13, 2013 at 9:15 PM, Andrew MacLeod amacl...@redhat.com wrote:
OK, a slightly different take..
I realized that I should be adding tree-outof-ssa.h to handle the 3 exports
from tree-outof-ssa.c that are in ssaexpand.h... In fact, by
Il 20/08/2013 15:58, Tom Tromey ha scritto:
This changes the handling of SHLIB so that it is inlined into
DRIVER_DEFINES. This is ok because SHLIB is defined in a Makefile
fragment that is included by the generated Makefile.
The rationale for this is that it simplifies some .o targets, so
The following patch fixes
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58418
The patch also fixes a duplicated bug PR58419.
The patch was successfully tested and bootstrapped on x86/x86-64.
Committed as rev. 202630.
2013-09-16 Vladimir Makarov vmaka...@redhat.com
PR
Il 16/09/2013 16:39, Tom Tromey ha scritto:
Richard Where's that automatic dependency patch blocked ...
No build machinery maintainer has reviewed it.
/me gets out of coma...
Someone said automatic dependency and build machinery maintainer in
the same sentence???
Paolo
Il 20/08/2013 15:59, Tom Tromey ha scritto:
There is an order-only dependency in gcc/Makefile.in that tries to
build the generated files before compiling regular objects. However,
this appears too early, and so at the time it is seen by make,
GCOV_OBJS and GCOV_DUMP_OBJS have not yet been
On 09/14/2013 06:41 AM, Jan-Benedict Glaw wrote:
Hi!
I suggest this patch, which fixes an alpha-linux build for me:
2013-09-13 Jan-Benedict Glaw jbg...@lug-owl.de
* config/alpha.c: Include tree-ssa.h.
diff --git a/gcc/config/alpha/alpha.c b/gcc/config/alpha/alpha.c
index
Il 20/08/2013 15:59, Tom Tromey ha scritto:
This adds the configury needed for automatic dependency tracking. It
also adds some bits to the Makefile so we can begin converting
(removing) explicit dependencies.
* Makefile.in (CCDEPMODE, DEPDIR, depcomp, COMPILE.base)
(COMPILE,
Il 20/08/2013 15:59, Tom Tromey ha scritto:
This removes manual dependencies for the c-family .o files.
* Makefile.in (c-family/cppspec.o, c-family/c-common.o)
(c-family/c-cppbuiltin.o, c-family/c-dump.o, c-family/c-format.o)
(c-family/c-gimplify.o, c-family/c-lex.o,
Il 20/08/2013 15:59, Tom Tromey ha scritto:
This converts LTO.
This also fixes a latent buglet in lto/Make-lang.in. lto_OBJS should
hold all the objects for a language, but LTO never defined this.
* Make-lang.in (LTO_H, LINKER_PLUGIN_API_H, LTO_TREE_H)
(lto/lto-lang.o,
Hi,
On Mon, 16 Sep 2013, Uros Bizjak wrote:
Why do you think so? The t-* frags are includes via
...
tmake_file=...$(srcdir)/config/i386/t-i386
...
ifneq ($(tmake_file),)
include $(tmake_file)
endif
...
It's just that there's no t-alpha frag yet.
No, there is no problem
Il 20/08/2013 15:59, Tom Tromey ha scritto:
This removes most of the explicit dependencies for host objects.
It also fixes a few rules to use $(COMPILE) in the process.
build objects are not affected, and are one reason that the various _H
macros are not yet removed.
* Makefile.in
Il 20/08/2013 15:59, Tom Tromey ha scritto:
This is a small change to make out_object_file use automatic
dependencies.
* Makefile.in ($(out_object_file)): Use COMPILE and POSTCOMPILE.
---
gcc/Makefile.in | 12 +++-
1 file changed, 3 insertions(+), 9 deletions(-)
diff
Il 20/08/2013 15:59, Tom Tromey ha scritto:
There is a single reference to TREE_GIMPLE_H in the source tree.
Since it is not defined anywhere, we might as well remove the use.
* config/i386/t-i386 (i386.o): Don't use TREE_GIMPLE_H.
---
gcc/config/i386/t-i386 | 2 +-
1 file changed,
Il 20/08/2013 15:59, Tom Tromey ha scritto:
There is a single definition of CROSS_FLOAT_H in the source.
As far as I can tell, this is never used anywhere.
So, this patch removes it.
* config/mcore/t-mcore (CROSS_FLOAT_H): Remove.
---
gcc/config/mcore/t-mcore | 3 ---
1 file
Il 20/08/2013 15:59, Tom Tromey ha scritto:
I used this perl script to find unused _H macros in the Makefile. I
deleted the definitions it reported and re-ran the script, until there
was no more output.
The script also makes note of _H variables which are used but never
defined. That is
Il 26/08/2013 18:09, Tom Tromey ha scritto:
Ian == Ian Lance Taylor i...@google.com writes:
Ian I assume that dropping $(OUTPUT_OPTION) is correct--I haven't looked
Ian at the new definition of $(COMPILE).
I believe the depcomp script takes care of this.
I think that would be the compile
Il 20/08/2013 15:59, Tom Tromey ha scritto:
A few generated files were not mentioned in the generated_files
variable. This fixes the problem.
* Makefile.in (generated_files): Add options.h,
target-hooks-def.h, insn-opinit.h,
common/common-target-hooks-def.h,
Paolo You are listed as the author of the compile script in Automake, do you
Paolo remember which compilers need it? I'm too young for that (that's
Paolo something I can say less and less :))...
I have no idea any more.
I can try a test build using a setting for CC that rejects -c -o.
Tom
On Mon, Sep 16, 2013 at 05:59:28PM +0200, Marek Polacek wrote:
Regtested/ran bootstrap-ubsan on x86_64-linux.
That looks wrong. ubsan_type_descriptor shouldn't change TYPE_PRECISION of
the type it has been called with, whether type is a bitfield or not can
change what typedescriptor is
Tom There is a single reference to TREE_GIMPLE_H in the source tree.
Tom Since it is not defined anywhere, we might as well remove the use.
Paolo Could it be for gimple.h?
Good catch, it seems to be.
Rather than fix that, it is simple to just drop all these dependencies
from t-i386. I'll do
On Mon, 16 Sep 2013, Marek Polacek wrote:
On Fri, Sep 13, 2013 at 07:18:24PM +, Joseph S. Myers wrote:
On Fri, 13 Sep 2013, Marek Polacek wrote:
This is kind of fugly, but don't have anything better at the moment.
2013-09-13 Marek Polacek pola...@redhat.com
PR
On Mon, Sep 16, 2013 at 8:12 AM, Vladimir Makarov vmaka...@redhat.com wrote:
The following patch fixes
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58418
The patch also fixes a duplicated bug PR58419.
Shouldn't we also add a testcase from PR58419?
The patch was successfully tested and
This patch ought to fix the unexpected size of type 'long long unsigned int:40'
issue in PR58413. Since libubsan will fail when the precision of a type
is not 32/64/128, we can't pass the width of a bitfield, instead we should pass
the TYPE_SIZE of the base type, I guess.
What is not very nice
Paolo == Paolo Bonzini bonz...@gnu.org writes:
Paolo Can you put before patch 4 another that defines OUTPUT_OPTION to -o $@
Paolo unconditionally and removes all traces of NO_MINUS_C_MINUS_O?
Sure thing.
Paolo The series looks okay to me with that change.
Thanks very much for your reviews.
This patch amends the chunk of code where we are determining the
type name; I haven't consider that IDENTIFIER_NODEs require special
handling, since we need to omit the DECL_NAME. I had something similar
in http://gcc.gnu.org/ml/gcc-patches/2013-09/msg00917.html patch, but
there I had a thinko: I
Hello!
Attached patch decleres dependecies for config/alpha/alpha.o.
2013-09-16 Uros Bizjak ubiz...@gmail.com
* config/alpha/t-alpha: New.
* config.gcc (alpha*-*-linux*): Add alpha/t-alpha to tmake_file.
(alpha*-*-freebsd*): Ditto.
(alpha*-*-netbsd*): Ditto.
On Mon, Sep 16, 2013 at 06:04:23PM +0200, Jakub Jelinek wrote:
On Mon, Sep 16, 2013 at 05:59:28PM +0200, Marek Polacek wrote:
Regtested/ran bootstrap-ubsan on x86_64-linux.
That looks wrong. ubsan_type_descriptor shouldn't change TYPE_PRECISION of
the type it has been called with, whether
On 13-09-16 11:39 AM, H.J. Lu wrote:
On Mon, Sep 16, 2013 at 8:12 AM, Vladimir Makarov vmaka...@redhat.com wrote:
The following patch fixes
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58418
The patch also fixes a duplicated bug PR58419.
Shouldn't we also add a testcase from PR58419?
I've
Il 20/08/2013 15:59, Tom Tromey ha scritto:
This converts the C front end.
Note that this fixes a latent bug in gcc/Makefile.in's definition of
C_TREE_H. This is needed to avoid breaking this build with this
patch.
* Makefile.in (C_TREE_H): Reference c/c-tree.h.
*
1 - 100 of 142 matches
Mail list logo
