Thank you.
$ svn commit
Sendinggcc/ChangeLog
Sendinggcc/config/arm/thumb1.md
Sendinggcc/config/arm/thumb2.md
Transmitting file data ...
Committed revision 213695.
P.S.
Minor nit was reg. tested.
On 08/06/2014 06:44 PM, Richard Earnshaw wrote:
On 06/08/14 15:14, Ramana
This is a last spot I forgot that sill does GENERIC building/folding
in SCCVN.
Bootstrapped and tested on x86_64-unknown-linux-gnu, applied.
Richard.
2014-08-07 Richard Biener
* tree-ssa-sccvn.c (fully_constant_vn_reference_p): Use
gimple_simplify instead of building a GENER
On Wed, 6 Aug 2014, Marek Polacek wrote:
> As discussed in the other thread, I can't just remove folding from the
> C FE and implement it on GIMPLE level, because that regressed some of
> those not-really-kosher static initializers. Instead, fold-const.c
> has to be taught how to fold PTR0 - (PTR
On 05-08-14 13:51, Rainer Orth wrote:
Hi Mike,
Or do we go with the removal suggestion of Mike?
I’ll let others weigh in. I’m fine either way. Original author likely
prefers the xfail, so I’m fine with the above.
the test now XPASSes on Solaris, adding testsuite noise in the other
directi
On Thu, Aug 7, 2014 at 8:36 AM, Marat Zakirov wrote:
> Thank you.
>
> $ svn commit
> Sendinggcc/ChangeLog
> Sendinggcc/config/arm/thumb1.md
> Sendinggcc/config/arm/thumb2.md
> Transmitting file data ...
> Committed revision 213695.
>
> P.S.
>
> Minor nit was reg. tested.
A
On Wed, 6 Aug 2014, Mike Stump wrote:
> On Aug 6, 2014, at 12:56 AM, Richard Biener wrote:
> >> My concern is the code we're removing discusses the need to simplify when
> >> these expressions are in static initializers. What's going to ensure that
> >> we're still simplifying instances which ap
On Thu, Aug 7, 2014 at 7:24 AM, Kugan wrote:
> On 06/08/14 23:29, Richard Biener wrote:
>> On Wed, Aug 6, 2014 at 3:21 PM, Kugan
>> wrote:
>>> On 06/08/14 22:09, Richard Biener wrote:
On Tue, Aug 5, 2014 at 4:21 PM, Jakub Jelinek wrote:
> On Tue, Aug 05, 2014 at 04:17:41PM +0200, Richa
--Marat
On 08/07/2014 12:00 PM, Ramana Radhakrishnan wrote:
On Thu, Aug 7, 2014 at 8:36 AM, Marat Zakirov wrote:
Thank you.
$ svn commit
Sendinggcc/ChangeLog
Sendinggcc/config/arm/thumb1.md
Sendinggcc/config/arm/thumb2.md
Transmitting file data ...
Committed revision 21
On Thu, 31 Jul 2014, Richard Biener wrote:
>
> The following fixes PR61950 by properly initializing the _size field
> of the static constructor for the vtable init member. Previously
> gfortran would use a 64bit integer to initialize the 32bit size field
> (not sure why larger aggregates are not
Hi Mike,
On 01/08/14 01:00, Mike Stump wrote:
On Jul 31, 2014, at 3:55 PM, Ramana Radhakrishnan
wrote:
However if we have a situation where a port tries to ameliorate some
of these errors with linker veneering and the compiler testsuite peels
off such error messages and just marks them as UNS
Hi all,
As Bin pointed out, setting -march=armv5 explicitly on this test causing a FAIL
when testing with /-mthumb.
The bug fixed by the commit that added this test occured only on pre-SMP
architectures, i.e. ARMv5 and earlier.
I think it's best to just remove the -march option. If someone was
>>> On 08/06/2014 06:44 PM, Richard Earnshaw wrote:
Similarly for the movqi pattern.
You haven't updated the thumb1 QImode pattern in the same way.
R.
On 07/08/14 09:10, Marat Zakirov wrote:
> --Marat
> On 08/07/2014 12:00 PM, Ramana Radhakrishnan wrote:
>> On Thu, Aug 7, 2014 at 8:36 AM,
On 07/31/2014 04:08 PM, Marat Zakirov wrote:
On 07/24/2014 07:40 PM, Marat Zakirov wrote:
On 07/24/2014 04:27 PM, Marat Zakirov wrote:
On 07/23/2014 06:23 PM, Marat Zakirov wrote:
Hi there!
I made a patch which fixes regressions on ARM platforms with
disabled unaligned accesses. The prob
Sorry ;( Will test&fix it.
On 08/07/2014 12:50 PM, Richard Earnshaw wrote:
On 08/06/2014 06:44 PM, Richard Earnshaw wrote:
Similarly for the movqi pattern.
You haven't updated the thumb1 QImode pattern in the same way.
R.
On 07/08/14 09:10, Marat Zakirov wrote:
--Marat
On 08/07/2014 12:00
Hi,
The case depends on GCC inlining of global function, but the callee won't be
inlined because it's global function and considered over-writable during
run-time.
This patch fixes the failure by binding it to pic locally. Is it OK?
Thanks,
bin
gcc/testsuite/ChangeLog
2014-08-07 Bin Cheng
Hi,
Case pr61772.c scans specific string in assembly file, and it is run for
many different option combinations. When it's tested against different lto
option combinations on targets like ARM, the generated pr61772.s may only
contain lto object content, rather than assembly codes. The scanning ch
Hi,
As analyzed in PR62032, this patch fixes the latent lto bug by switching
arguments of lto_define_builtins, otherwise vsnprintf-chk.c would fail on
arm/aarch64 with lto options.
Is it ok if bootstrap and test pass?
2014-08-07 Bin Cheng
PR lto/62032
* lto/lto-lang.c (lto_in
On Thu, Aug 7, 2014 at 5:43 PM, Bin Cheng wrote:
> Hi,
>
> The case depends on GCC inlining of global function, but the callee won't be
> inlined because it's global function and considered over-writable during
> run-time.
It won't be inlined only if it's tested against -fpic/-fPIC.
> This patch
On Thu, Aug 07, 2014 at 09:53:13AM +0200, Richard Biener wrote:
> On Wed, 6 Aug 2014, Mike Stump wrote:
>
> > On Aug 6, 2014, at 12:56 AM, Richard Biener wrote:
> > >> My concern is the code we're removing discusses the need to simplify when
> > >> these expressions are in static initializers. W
Hi Tom,
>> the test now XPASSes on Solaris, adding testsuite noise in the other
>> direction on completely innocent systems.
>
> FWIW, I would be interested in understanding the details there.
easy once you get it ;-) The check_effective_target_* procs are
supposed to return 1 in the success cas
> >
> > Probably not ;)
> >
> > But seriously it's a matter of a) keeping constructors for each
> > variable separate and optimize them in GIMPLE, b) recognize
> > resulting code that can be expressed with a initializer
> >
> > a) can be done with delaying inlining to IPA time and hoping
> > tha
On Wed, Aug 06, 2014 at 01:19:39PM -0400, David Malcolm wrote:
> This is the patch series I spoke about at Cauldron in the talk
> "A proposal for typesafe RTL"; slides here:
> http://dmalcolm.fedorapeople.org/presentations/cauldron-2014/rtl
>
> They can also be seen at:
> https://dmalcolm.fedorape
> From: Andi Kleen
>
> gcc/:
>
> 2014-07-30 Andi Kleen
>
> * ipa-devirt.c (polymorphic_call_target_hasher::hash):
> Convert to inchash.
OK,
Honza
Hi,
this is a rejects valid issue with constexpr conversion operators and
enums, eg:
struct X0
{
constexpr operator int() const { return 1; }
};
enum E0 { e0 = X0() };
Given build_expr_type_conversion, we can handle the bug rather easily by
using it when the enum doesn't have an underlyin
On Thu, Aug 07, 2014 at 12:29:34PM +0200, Jan Hubicka wrote:
> > >
> > > Probably not ;)
> > >
> > > But seriously it's a matter of a) keeping constructors for each
> > > variable separate and optimize them in GIMPLE, b) recognize
> > > resulting code that can be expressed with a initializer
> >
Hi all,
Currently, when an expression doing manual load or bswap is detected, the
bswap optimization replace it by an actual load and/or bswap instruction
without considering whether the intermediate values computed in the
expressions are reused later. If that is the case, the construction of thes
While preparing the initial commit for the std::list ABI transition I
noticed the move constructor does unnecessary work, initializing the
object to an empty state, then calling _List_node_base::swap which
checks whether it's empty (but we already know it is) and then
initializes it again. The _Li
Hi all,
This patch arises from PR 62014 where apparently gcc generates usage of
FP registers with -mgeneral-regs-only. The PR turned out to be bogus in
the end that but an inspection of aarch64.md shows that there are some
patterns that don't have their usage of FP/SIMD registers properly
gua
Hi all,
During the great types rework this must have slipped through the cracks.
We had two different types to describe the fcsel (A64) and vsel (A32)
instructions: fcsel and f_sel[s,d].
In the A53 pipeline description we use fcsel, so the AArch32 version was
presumably scheduled improperly
Th
>
> err yeah, I guess we'd need to rework things so front end just creates
> functions for each variable and then middle end pass creates function
> that call all of them if necessary.
There is already code for that in cdtor optimization pass (ipa.c), but I think
C++ does its own wrapper to solve
On 16/05/14 13:35, Richard Earnshaw wrote:
On 08/05/14 18:36, Ian Bolton wrote:
Hi,
It currently takes 4 instructions to generate certain immediates on
AArch64 (unless we put them in the constant pool).
For example ...
long long
beefcafebabe ()
{
return 0xBEEFCAFEBABEll
On 08/06/2014 07:23 PM, David Malcolm wrote:
diff --git a/gcc/function.h b/gcc/function.h
index 28a20f3..ba7597c 100644
--- a/gcc/function.h
+++ b/gcc/function.h
@@ -135,7 +135,7 @@ struct GTY(()) expr_status {
rtx x_apply_args_value;
/* List of labels that must never be deleted. */
-
On Thu, 7 Aug 2014, Jan Hubicka wrote:
> > >
> > > Probably not ;)
> > >
> > > But seriously it's a matter of a) keeping constructors for each
> > > variable separate and optimize them in GIMPLE, b) recognize
> > > resulting code that can be expressed with a initializer
> > >
> > > a) can be do
> It's only important to not inline the static constructor into the
> one function calling all of them. And only not doing that during
> early inlining (but still inline into those constructors). That's
> because we eventually want to eliminate the body of the static
> constructor in favor of a D
The following are the non-cleanup parts. The patch moves us
to compress streams (what data-streamer thinks of "streams")
instead of whole sections. This enables us to only need
a single compressed and uncompressed block of data "live"
as opposed to a whole section (well, in theory - we still
do
The following moves memcpy, memmove and memset folding from builtins.c
to gimple-fold.c. This also drags in stringop foldings (at least
those that are done from gimple-fold.c) because otherwise we
may end up recursing into fold_stmt via gimplifying of builtin.c
folding results which ends up confu
On Thu, Aug 7, 2014 at 11:43 AM, Bin Cheng wrote:
> Hi,
> Case pr61772.c scans specific string in assembly file, and it is run for
> many different option combinations. When it's tested against different lto
> option combinations on targets like ARM, the generated pr61772.s may only
> contain lto
On Thu, Aug 7, 2014 at 11:46 AM, Bin Cheng wrote:
> Hi,
> As analyzed in PR62032, this patch fixes the latent lto bug by switching
> arguments of lto_define_builtins, otherwise vsnprintf-chk.c would fail on
> arm/aarch64 with lto options.
>
> Is it ok if bootstrap and test pass?
Ok (would be nice
> >
> > Changelog:
> >
> > gcc/c-family:
> >
> > 2014-07-31 Igor Zamyatin
> >
> > PR other/61962
> > * array-notation-common.c (find_rank): Added handling for other
> > types of references.
> >
> >
> > gcc/testsuite:
> >
> > 2014-07-31 Igor Zamyatin
> >
> > PR
On Thu, Aug 7, 2014 at 2:33 PM, Zamyatin, Igor wrote:
>> >
>> > Changelog:
>> >
>> > gcc/c-family:
>> >
>> > 2014-07-31 Igor Zamyatin
>> >
>> > PR other/61962
>> > * array-notation-common.c (find_rank): Added handling for other
>> > types of references.
>> >
>> >
>> > gc
On Thu, Aug 07, 2014 at 12:33:00PM +, Zamyatin, Igor wrote:
> --- a/gcc/c-family/array-notation-common.c
> +++ b/gcc/c-family/array-notation-common.c
> @@ -221,11 +221,15 @@ find_rank (location_t loc, tree orig_expr, tree expr,
> bool ignore_builtin_fn,
> current_rank++;
>
Hi,
On Thu, Aug 07, 2014 at 08:10:51AM +0200, Patrick Marlier wrote:
> Hi Martin,
>
> On Wed, Aug 6, 2014 at 4:02 PM, Martin Jambor wrote:
> > Hi,
> >
> > On Wed, Jul 30, 2014 at 06:56:05PM +0200, Martin Jambor wrote:
> >> Hi,
> >>
> >> IPA-CP can wreck havoc to transactional memory support as d
On 07/08/14 12:32, Kyrill Tkachov wrote:
>
> On 16/05/14 13:35, Richard Earnshaw wrote:
>> On 08/05/14 18:36, Ian Bolton wrote:
>>> Hi,
>>>
>>> It currently takes 4 instructions to generate certain immediates on
>>> AArch64 (unless we put them in the constant pool).
>>>
>>> For example ...
>>>
>>>
On 07/08/14 13:46, Richard Earnshaw wrote:
On 07/08/14 12:32, Kyrill Tkachov wrote:
On 16/05/14 13:35, Richard Earnshaw wrote:
On 08/05/14 18:36, Ian Bolton wrote:
Hi,
It currently takes 4 instructions to generate certain immediates on
AArch64 (unless we put them in the constant pool).
For
> To commit 2), I would like you to run a wider set of tests (e.g., the LLVM
> test suite). If this passes successful, we should give a headsup on the GCC
> mailing list and ask other people to try the new isl support.
> If now bugs have found, we switch.
I've tested the modified version of Graphi
This patch prevents the initializer from being checked when it is
dependent. It also sets the type of a dependent template-id referring
to a variable template to be unknown, making such expressions type
dependent.
2014-08-07 Andrew Sutton
* pt.c (lookup_template_variable): Make the typ
On 08/07/2014 06:49 AM, Paolo Carlini wrote:
+ if (ENUM_UNDERLYING_TYPE (enumtype))
+ value = perform_implicit_conversion_flags
+ (ENUM_UNDERLYING_TYPE (enumtype), value, tf_warning_or_error,
+ LOOKUP_IMPLICIT | LOOKUP_NO_NARROWING);
It seems like doin
On 08/07/2014 09:22 AM, Andrew Sutton wrote:
* pt.c (lookup_template_variable): Make the type unspecified if
any template arguments are dependent.
This hunk is OK.
* decl.c (cp_finish_decl): Don't check the initializer if it is
value-dependent.
Why is thi
On 07/08/14 13:57, Kyrill Tkachov wrote:
>
> On 07/08/14 13:46, Richard Earnshaw wrote:
>> On 07/08/14 12:32, Kyrill Tkachov wrote:
>>> On 16/05/14 13:35, Richard Earnshaw wrote:
On 08/05/14 18:36, Ian Bolton wrote:
> Hi,
>
> It currently takes 4 instructions to generate certain i
On 07/08/2014 15:18, Roman Gareev wrote:
To commit 2), I would like you to run a wider set of tests (e.g., the LLVM
test suite). If this passes successful, we should give a headsup on the GCC
mailing list and ask other people to try the new isl support.
If now bugs have found, we switch.
I've t
>> * decl.c (cp_finish_decl): Don't check the initializer if it is
>> value-dependent.
>
>
> Why is this needed?
I thought that check_initializer was evaluating the constant
expression, and was resulting in errors because a template-id
referring to a variable template with a conc
Hi,
in the bugtracker for PR60255 janus proposed to fix the bug by removing
the error and additionally checking if the character array length
declaration is deferred, which leaves the the charlen to be 0
(gcc/fortran/class.c (find_intrinsic_vtab) 2418-2420).
My contribution to that patch is the
On Thu, 7 Aug 2014, Richard Biener wrote:
>
> The following are the non-cleanup parts. The patch moves us
> to compress streams (what data-streamer thinks of "streams")
> instead of whole sections. This enables us to only need
> a single compressed and uncompressed block of data "live"
> as opp
Sendinggcc/ChangeLog
Sendinggcc/config/arm/thumb1.md
Transmitting file data ..
Committed revision 213710.
P.S. Sorry for inconvenience.
On 08/07/2014 01:02 PM, Marat Zakirov wrote:
Sorry ;( Will test&fix it.
On 08/07/2014 12:50 PM, Richard Earnshaw wrote:
On 08/06/2014 06:44 P
Hi,
On 08/07/2014 03:24 PM, Jason Merrill wrote:
On 08/07/2014 06:49 AM, Paolo Carlini wrote:
+ if (ENUM_UNDERLYING_TYPE (enumtype))
+value = perform_implicit_conversion_flags
+ (ENUM_UNDERLYING_TYPE (enumtype), value, tf_warning_or_error,
+ LOOKUP_IMPLICIT | LOO
On Tue, Aug 05, 2014 at 08:05:00AM +0100, Andrew Pinski wrote:
> On Fri, Aug 1, 2014 at 2:21 AM, wrote:
> >> On Jun 6, 2014, at 1:50 AM, James Greenhalgh
> >> wrote:
> >>
> >>
> >> Hi,
> >>
> >> The move_by_pieces infrastructure performs a copy by repeatedly trying
> >> the largest safe copy it
On 07/08/14 12:22, Kyrill Tkachov wrote:
> Hi all,
>
> This patch arises from PR 62014 where apparently gcc generates usage of
> FP registers with -mgeneral-regs-only. The PR turned out to be bogus in
> the end that but an inspection of aarch64.md shows that there are some
> patterns that don't
On 07/08/14 12:26, Kyrill Tkachov wrote:
> Hi all,
>
> During the great types rework this must have slipped through the cracks.
> We had two different types to describe the fcsel (A64) and vsel (A32)
> instructions: fcsel and f_sel[s,d].
> In the A53 pipeline description we use fcsel, so the AAr
On Thu, Aug 7, 2014 at 4:20 PM, James Greenhalgh
wrote:
> On Tue, Aug 05, 2014 at 08:05:00AM +0100, Andrew Pinski wrote:
>> On Fri, Aug 1, 2014 at 2:21 AM, wrote:
>> >> On Jun 6, 2014, at 1:50 AM, James Greenhalgh
>> >> wrote:
>> >>
>> >>
>> >> Hi,
>> >>
>> >> The move_by_pieces infrastructure
Hello,
On 25 Jul 20:55, Kirill Yukhin wrote:
> Hello,
> Branch was rebased on trunk.
>
> It contains fixes for several issues in the build system.
> Now 'configure' can be called using relative path.
>
> Also some options are now unnecessary, updated manual is posted
> on wiki: https://gcc.gnu.or
Hi all,
This test in the torture suite fails on -flto because it scans for a sentinel
string inside an asm block that it wants to make sure is not optimised away.
However, with -flto gcc uses slim LTO objects which contain a binary
representation of the structure of the program rather than out
Hi,
this patch adds logic for determining dynamic type of a memory location based
on constructor calls or vtable stores as discussed on the Cauldron. It is
based on existing code in ipa-prop that does look for type changes, but it
newly handles the ctor calls too and fills in the polymorphic_call_
On Thu, 2014-08-07 at 13:32 +0200, Bernd Schmidt wrote:
> On 08/06/2014 07:23 PM, David Malcolm wrote:
> > diff --git a/gcc/function.h b/gcc/function.h
> > index 28a20f3..ba7597c 100644
> > --- a/gcc/function.h
> > +++ b/gcc/function.h
> > @@ -135,7 +135,7 @@ struct GTY(()) expr_status {
> > rt
On 08/07/2014 09:58 AM, Paolo Carlini wrote:
Also, I was thinking earlier today that conceptually the check pasted
above should check cases different from the cases handled by
perform_implicit_conversion_flags, thus, eg, *not* handle enum27.C,
because it's an hard error, isn't our standard (and s
On Wed, 2014-08-06 at 21:29 -0400, Trevor Saunders wrote:
> On Wed, Aug 06, 2014 at 01:22:58PM -0400, David Malcolm wrote:
> > +class GTY(()) rtx_insn_list : public rtx_def
> > +{
> > + /* No extra fields, but adds invariant: (GET_CODE (X) == INSN_LIST).
>
> some nice future work would be to see
On 08/07/2014 11:28 AM, Jason Merrill wrote:
-Wno-narrowing should prevent an error on enum27
Er, should *not*.
Jason
Hi,
On 08/07/2014 06:32 PM, Jason Merrill wrote:
On 08/07/2014 11:28 AM, Jason Merrill wrote:
-Wno-narrowing should prevent an error on enum27
Er, should *not*.
Ok. Probably at some point I should review which kind of diagnostics the
various implementations emit: for example *for enum27.C* c
On Thu, 31 Jul 2014, Marek Polacek wrote:
> A few issues: currently we don't warn (in -std=c90 -pedantic mode)
> about the usage of __func__ and _Pragma (possible others - va_copy?).
> I'm hoping this is not that important though. For restrict/inline,
> in GNU90 mode we just don't compile the cod
Hi Bernd!
On Mon, 4 Aug 2014 23:00:07 +0200, Bernd Schmidt
wrote:
> On 07/23/2014 04:37 PM, Ilya Verbin wrote:
> > On 23 Jul 16:16, Bernd Schmidt wrote:
> >> Here's the latest version, which fixes some more issues and removes
> >> things that are now unnecessary.
> I've committed this version t
On 08/07/2014 12:41 PM, Paolo Carlini wrote:
Ok. Probably at some point I should review which kind of diagnostics the
various implementations emit: for example *for enum27.C* currently clang talks
about *narrowing*, the kind of of diagnostics we emit from chech_narrowing; EDG
instead produces
Tested on hppa2.0w-hp-hpux11.11 and hppa64-hp-hpux11.11. Both hunks
committed to trunk. First hunk committed to 4.9 branch.
Dave
--
John David Anglin dave.ang...@bell.net
2014-08-07 John David Anglin
* gcc.dg/pr57233.c: Add -fno-common option on hppa*-*-hpux*.
* c-c+
On Thu, Aug 07, 2014 at 01:44:02PM +0200, Jan Hubicka wrote:
> > It's only important to not inline the static constructor into the
> > one function calling all of them. And only not doing that during
> > early inlining (but still inline into those constructors). That's
> > because we eventually w
32-bit hppa-hpux doesn't support -fdata-sections causing the test to
fail.
Tested on hppa2.0w-hp-hpux11.11 and hppa64-hp-hpux11.11. Committed
to trunk and 4.9 branch.
Dave
--
John David Anglin dave.ang...@bell.net
2014-08-07 John David Anglin
* gcc.c-torture/compile/pr6065
I'm starting to look at updating my old address branch with an eye towards
getting the changes committed in GCC 4.10. The address branch is meant to
rewrite handling of addresses in the rs6000 backend, to generalize the
addresses before register allocation to allow more general forms, and then
wit
Tested on hppa2.0-hp-hpux11.11 and hppa64-hp-hpux11.11. Committed to
trunk.
Dave
--
John David Anglin dave.ang...@bell.net
2014-08-07 John David Anglin
* gcc.dg/memcpy-5.c: Add -fno-common option on hppa*-*-hpux*.
Index: gcc.dg/memcpy-5.c
==
Hi
I took a closer look to this PR and there is indeed a problem. My
comment on the PR is incorrect, I thought the problem was in the rehash
method but is it not. It is indeed wrong to shrink buckets when invoking
max_load_factor, it reverts the effect of preallocating buckets before a
bi
The attached change adds a requested comment regarding the xfail.
Tested on hppa2.0w-hp-hpux11.11 and hppa64-hp-hpux11.11. Committed to
trunk and 4.9 branch.
Dave
--
John David Anglin dave.ang...@bell.net
2014-08-07 John David Anglin
* gcc.dg/atomic/stdatomic-flag.c: Add xfa
On 07/08/14 20:56 +0200, François Dumont wrote:
Hi
I took a closer look to this PR and there is indeed a problem. My
comment on the PR is incorrect, I thought the problem was in the
rehash method but is it not. It is indeed wrong to shrink buckets when
invoking max_load_factor, it reverts
Is this
[1.cc : 179:64] Reader::~Reader (&version);
from an inline instance?
David
On Wed, Aug 6, 2014 at 10:18 AM, Wei Mi wrote:
> We saw bb like this in the IR dump after pass_build_cfg:
>
> :
> [1.cc : 205:45] D.332088 = table->_vptr.Table;
> [1.cc : 205:45] D.332134 = D.332088 + 104;
> static int
> -next_discriminator_for_locus (location_t locus)
> +increase_discriminator_for_locus (location_t locus, bool return_next)
> {
>struct locus_discrim_map item;
>struct locus_discrim_map **slot;
> @@ -934,8 +936,10 @@ next_discriminator_for_locus (location_t
>(*slot)->
_POSIX_C_SOURCE is predefined on hppa-hpux, so it needs to be
undefined before
it can be redefined.
Tested on hppa2.0-hp-hpux11.11 and hppa64-hp-hpux11.11. Committed to
trunk and
4.9 branch.
Dave
--
John David Anglin dave.ang...@bell.net
2014-08-07 John David Anglin
* g
On 08/07/2014 02:57 AM, Kyrill Tkachov wrote:
> + if (one_match > zero_match)
> +{
> + /* Set either first three quarters or all but the third.*/
> + mask = 0xll << (16 - first_not__match);
> + emit_insn (gen_rtx_SET (VOIDmode, dest,
> +
It seems that an empty base initializer can show up with an index of
POINTER_PLUS_EXPR as well.
Tested x86_64-pc-linux-gnu, applying to trunk, 4.8, 4.9.
commit 36db761e7a61c86d1c95dd6aa65bc325b6642966
Author: Jason Merrill
Date: Thu Aug 7 15:10:08 2014 -0400
PR c++/61959
* semantic
As pinskia suggested in a comment.
Tested x86_64-pc-linux-gnu, applying to trunk.
commit fb5be680f7e1c545bc13ccf603dfd99c9fd707a2
Author: Jason Merrill
Date: Thu Aug 7 15:14:49 2014 -0400
PR c++/62043
* parser.c (c_parse_file): Change sorry to fatal_error.
diff --git a/gcc
This is a followup fix for the patches from PR41857, which contained a
bug that is exposed by the ptx backend. The problem is finding the right
pointer type for a mem_ref during ivopts.
The original problem was that on spu-elf, __ea pointers are 64 bit while
sizetype is 32 bit. During ivopts,
This patch replaces some reference members with pointers, so that the
types containing them become trivial and are more efficient to pass as
function arguments and can use the small object optimization when
stored in a std::function, so that promise::set_value() doesn't need
to allocate any memory
The attached change fixes the build of libgfortran on hppa1.1-hp-
hpux10.20 (I know I'm going
for the oldest system that will build gfortran).
OK?
Dave
--
John David Anglin dave.ang...@bell.net
2014-08-08 John David Anglin
* configure.ac: Guard include of .
* configu
On 08/07/2014 09:50 PM, Bernd Schmidt wrote:
The following patch reworks this area - instead of trying to find a
proper pointer type, it just recognizes the case where an integer is
promoted to be the base, and performs all calculations in that type
rather than sizetype. That also seems to be an
Yes, that is intentional. It is to avoid assiging a discriminator for
the first call in the group of calls with the same source lineno.
Starting from the second call in the group, it will get a different
discriminator with previous call in the same group.
Thanks,
Wei.
On Thu, Aug 7, 2014 at 12:17
Hi, Mike.
Here is the patch which solves LRA SDmode problem which we discussed on
IRC on Friday.
The patch was successfully tested and bootstrapped on ppc64 with -mlra
switched on.
David, is it ok to commit it to the trunk?
2014-08-07 Vladimir Makarov
* config/rs6000/rs6000.c (rs600
No, it is not. This IR is dumped before early inline -- just after
pass_build_cfg. The line number of the deconstructor is marked
according to where its constructor is located, instead of where it is
inserted. This is also problematic.
Wei.
On Thu, Aug 7, 2014 at 12:11 PM, Xinliang David Li wrot
On Thu, Aug 7, 2014 at 2:20 PM, Wei Mi wrote:
> No, it is not. This IR is dumped before early inline -- just after
> pass_build_cfg. The line number of the deconstructor is marked
> according to where its constructor is located,
The definition location or the invocation location?
David
> instea
On Thu, Aug 7, 2014 at 2:40 PM, Xinliang David Li wrote:
> On Thu, Aug 7, 2014 at 2:20 PM, Wei Mi wrote:
>> No, it is not. This IR is dumped before early inline -- just after
>> pass_build_cfg. The line number of the deconstructor is marked
>> according to where its constructor is located,
>
> Th
Test fails on all 32-bit hppa systems.
Tested on hppa-unknown-linux-gnu. Committed to trunk, 4.9 and 4.8.
Dave
--
John David Anglin dave.ang...@bell.net
2014-08-07 John David Anglin
PR tree-optimization/60707
* gfortran.dg/pr45636.f90: xfail on 32-bit hppa*-*-*.
Ind
Hi!
Following patch adds necessary handling of the cases with incorrect type of an
array in ArrayNotation and thus avoids ICE.
Regtested on x86_64.
Ok for trunk/4.9?
Thanks,
Igor
gcc/c/ChangeLog:
2014-08-07 Igor Zamyatin
PR other/62008
* c-parser.c (c_parser_array_notation):
> This patch replaces some reference members with pointers, ...
> ...
> Tested x86_64-linux, committed to trunk.
This breaks bootstrap (see https://gcc.gnu.org/ml/gcc-regression/2014-08/):
...
libtool: compile: /opt/gcc/build_w/./gcc/xgcc -shared-libgcc
-B/opt/gcc/build_w/./gcc -nostdinc++
-L/
On 7 August 2014 23:07, Dominique Dhumieres wrote:
>> This patch replaces some reference members with pointers, ...
>> ...
>> Tested x86_64-linux, committed to trunk.
>
> This breaks bootstrap (see https://gcc.gnu.org/ml/gcc-regression/2014-08/):
Strange, I didn't see that - I'll fix it ASAP.
reject operator to be used as variable in for.
eg:
(for mult in plus minus)
* genmatch.c (get_operator): New function.
(e_operation::e_operation): Adjust to call get_operator.
(parse_for): Add call to get_operator.
Thanks,
Prathamesh
Index: genmatch.c
On 08/08/14 00:07 +0200, Dominique Dhumieres wrote:
This patch replaces some reference members with pointers, ...
...
Tested x86_64-linux, committed to trunk.
This breaks bootstrap (see https://gcc.gnu.org/ml/gcc-regression/2014-08/):
Fixed by this patch, sorry about that. I was caught out (a
Remove a redundant assignment "*predictor = PRED_BUILTIN_EXPECT;",
since six lines later *predictor is assigned again.
--
2014-08-07 Yi Yang
gcc:
* predict.c (expr_expected_value_1): Remove the redundant assignment.
diff --git gcc/predict.c gcc/predict.c
index 835c618..869fc5d 100644
---
1 - 100 of 104 matches
Mail list logo
