> 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 va
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 up
---
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);
- TYPE_N
From: abutcher
* 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 avoid adding template result to symbol table.
From: abutcher
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 extension, in plain functions.
* type-utils.h:
Richard Biener writes:
> On Fri, Sep 13, 2013 at 10:33 AM, Richard Sandiford
> wrote:
>> Richard Biener writes:
Yeah. I don't think it makes sense to canonise PSI to 32 bits when we
know it has fewer than 32 bits. It's still going to be wrong, and will
still defeat one of the ma
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 [=] (T&& ... ts) // OK: ts is a function
par
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
On Sun, Sep 15, 2013 at 09:08:00PM +0200, Jan Hubicka wrote:
> > 2013-09-13 Jakub Jelinek
> >
> > * 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 edges
> ---
> 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 (TEMPLA
> 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 comparis
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 = c
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
>> wrote:
>>> Now I think this is good opportunity for a simple heuristic:
>>>
>>> If a statement is at loop level 1 we can move it
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
* gengtype.c (file_rules): Added rule for *.cc files.
(get_output_file_with_visibility): Give fatal messa
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
* plugin.c (parse_plugin_arg_opt):
On 13/09/13 19:39, James Greenhalgh wrote:
Hi,
This patch adds intrinsics for vcopy_lane_<8,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.
OK?
Th
On 13/09/13 19:28, James Greenhalgh wrote:
Hi,
This patch converts the vmul_lane_<16,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 vml_lane and the fm
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 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
>>> wrote:
There are 2 parts of tre-ssa-ter.c to address.
is_repl
Adding Eric and Steven in the loop as it is RTL related.
Thanks
Yvan
On 11 September 2013 21:08, Yvan Roux wrote:
> Here is the new patch discussed in the other thread.
>
> Thanks
> Yvan
>
> 2013-09-11 Yvan Roux
> Vladimir Makarov
>
> * rtlanal.c (lsb_bitfield_op_p): New
On 06/09/13 16:06, James Greenhalgh wrote:
gcc/
2013-09-06 James Greenhalgh
* 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 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 function which
On Sat, Sep 14, 2013 at 12:41 PM, Jan-Benedict Glaw 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,
> num_ssa_names, ssa_
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 wrote:
> On Sep 13, 2013, at 1:08 AM, Richard Sandiford
> wrote:
We don't really model that properly yet. Partial modes are just defined
using something like:
PARTIAL_INT_MODE (SI);
>
> True, but, all ports are trivial to fix so t
Any comment/review on this patch ?
On Sep 3, 2013, at 4:08 PM, Tristan Gingold 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 region number)
On Fri, Sep 13, 2013 at 4:36 PM, H.J. Lu 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 "*_mk"
>>> + [(set (match_operand:BND 0 "register_operand" "=B")
>>> +(un
On Fri, Sep 13, 2013 at 12:18 PM, Ilya Enkovich wrote:
> 2013/9/11 Uros Bizjak :
>> On Tue, Sep 10, 2013 at 1:38 PM, Ilya Enkovich
>> wrote:
>>> Ping^4
>>>
>>> Could please someone look at this patch? It is mostly i386 target
>>> specific and is basic for further MPX based features.
>>>
>>> Than
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 alternativ
On Fri, Sep 13, 2013 at 4:29 PM, Eric Botcazou 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 -fnon-call-exceptions, which
On Fri, Sep 13, 2013 at 10:47:01PM +0100, Andrew Pinski wrote:
> On Fri, Sep 13, 2013 at 11:57 AM, James Greenhalgh
> 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
> > where this goes wrong
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
> >
> > PR sanitizer/58413
> > c-family/
> > * c-ubsan.c (ubsan_instrumen
On Fri, Sep 13, 2013 at 4:56 PM, Eric Botcazou 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, which will lead to
On Fri, Sep 13, 2013 at 6:45 PM, Joseph S. Myers
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 (!opts_set->x
On Fri, Sep 13, 2013 at 6:56 PM, Xinliang David Li 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
- && global_options_set.x_flag_t
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 wrote:
> On Fri, Sep 13, 2013 at 1:30 AM, Richard Biener
> wrote:
>> On Thu, Sep 12, 2013 at 10:31 PM, Xinliang David Li
>> wrote:
>>> Currently -ftree-vectorize turns on both loop and slp vectorizations,
>>> but there is no simple way to turn
On Fri, Sep 13, 2013 at 8:06 PM, Cong Hou 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 with short
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 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 ob
On Mon, Sep 16, 2013 at 11:06 AM, Uros Bizjak 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 tree-ssanames.h +
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 expr
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 de
On Mon, 2013-09-16 13:01:40 +0200, Uros Bizjak wrote:
> On Mon, Sep 16, 2013 at 11:06 AM, Uros Bizjak 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.
>
> Howe
On Mon, 16 Sep 2013, Uros Bizjak wrote:
> On Mon, Sep 16, 2013 at 11:06 AM, Uros Bizjak 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,
>
On Mon, Sep 16, 2013 at 1:36 PM, Jan-Benedict Glaw wrote:
> On Mon, 2013-09-16 13:01:40 +0200, Uros Bizjak wrote:
>> On Mon, Sep 16, 2013 at 11:06 AM, Uros Bizjak wrote:
>> > > My Build Robot[1] found this recent commit to break Alpha:
>>
>> I think you can remove the tree-flow.h include and 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 make
On Mon, 16 Sep 2013, Uros Bizjak wrote:
> On Mon, Sep 16, 2013 at 1:36 PM, Jan-Benedict Glaw wrote:
> > On Mon, 2013-09-16 13:01:40 +0200, Uros Bizjak wrote:
> >> On Mon, Sep 16, 2013 at 11:06 AM, Uros Bizjak wrote:
> >> > > My Build Robot[1] found this recent commit to break Alpha:
> >>
> >> I
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).
O
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,
> _Vector_base::_Ve
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
* config/i38
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
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
PR tree-optimization/58432
* tree-loop-distribution.c (tree_loop_distributi
On Mon, Sep 16, 2013 at 1:57 PM, Richard Biener 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,
On Fri, Sep 13, 2013 at 11:25 AM, Diego Novillo wrote:
> On Fri, Sep 13, 2013 at 11:07 AM, Jakub Jelinek 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 into tree-core.h.
>
> Sorry
On Mon, Sep 16, 2013 at 09:39:27AM -0400, Diego Novillo wrote:
> On Fri, Sep 13, 2013 at 11:25 AM, Diego Novillo wrote:
> > On Fri, Sep 13, 2013 at 11:07 AM, Jakub Jelinek wrote:
> >
> >> E.g. today I've noticed you've lost OMP_CLAUSE_LINEAR_NO_COPYIN
> >> comment that has been added to tree.h re
On Mon, Sep 16, 2013 at 2:50 PM, Yuri Rumyantsev 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 x86-64.
>
> Is i
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_LIN
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 yo
Uros,
Thanks for your review.
I attached modified patch - is it OK for you now?
2013/9/16 Uros Bizjak :
> On Mon, Sep 16, 2013 at 2:50 PM, Yuri Rumyantsev wrote:
>> Hi All,
>>
>> Here is 1-line fix which improves Atom performance by better distance
>> estimation. We got ~20% speedup on one of b
On 09/16/2013 05:05 AM, Richard Biener wrote:
On Sat, Sep 14, 2013 at 12:41 PM, Jan-Benedict Glaw 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, pt
On Mon, Sep 16, 2013 at 4:20 PM, Michael Matz 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
>> ign
On Mon, Sep 16, 2013 at 4:26 PM, Yuri Rumyantsev 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.
Thanks,
Uros.
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 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 far the most
sensible
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,
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
PR middle-end/58418
* lra-cons
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
* config/alpha.c: Include tree-ssa.h.
diff --git a/gcc/config/alpha/alpha.c b/gcc/config/alpha/alpha.c
index a8fb929..3759205 100644
---
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)
> (COMPI
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, c-
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, t
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.
>
> * Makefil
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(-)
>
> d
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 cha
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
Il 26/08/2013 18:09, Tom Tromey ha scritto:
>> "Ian" == Ian Lance Taylor 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, pass-ins
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 generate
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 t
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
> > >
> > > PR sanitizer/5
On Mon, Sep 16, 2013 at 8:12 AM, Vladimir Makarov 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 bootstrapped on x86
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 is
> "Paolo" == Paolo Bonzini 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.
I'll s
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
* config/alpha/t-alpha: New.
* config.gcc (alpha*-*-linux*): Add alpha/t-alpha to tmake_file.
(alpha*-*-freebsd*): Ditto.
(alpha*-*-netbsd*): Ditto.
(alpha*-*-openbsd*): 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, whe
On 13-09-16 11:39 AM, H.J. Lu wrote:
On Mon, Sep 16, 2013 at 8:12 AM, Vladimir Makarov 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 checked the test and
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.
>
> *
Hi Christian,
Christian Bruel writes:
> @@ -6893,11 +6894,14 @@ label:
> ;; reloading MAC subregs otherwise. For that probably special patterns
> ;; would be required.
> (define_insn "*mov_reg_reg"
> - [(set (match_operand:QIHI 0 "arith_reg_dest" "=r")
> - (match_operand:QIHI 1 "register
> Apologies if this was out of context. This was a change suggested and
> reviewed by Jason
> (http://gcc.gnu.org/ml/gcc-patches/2013-09/msg01114.html).
Then don't repost it on gcc-patches, it is already available on gcc-cvs:
http://gcc.gnu.org/ml/gcc-cvs/2013-09/msg00473.html
--
Eric Botcazo
Tom> I can try a test build using a setting for CC that rejects -c -o.
I did this and the build died pretty early on:
/home/tromey/Space/Trunk/Git/bin/my-cc -c -DHAVE_CONFIG_H -g -g -I.
-I../../gcc/libiberty/../include -W -Wall -Wwrite-strings -Wc++-compat
-Wstrict-prototypes -pedantic -fpi
1 - 100 of 140 matches
Mail list logo
