On Wed, May 16, 2012 at 7:46 AM, Olivier Hainque wrote:
> 2012-05-16 Olivier Hainque
>
> libgcc/
> * Makefile.in (install-unwind_h): Rename into ...
> (install-unwind_h-forbuild): New target.
> (all): Use it instead of the former install-unwind_h.
> (install
On Wed, 2012-05-23 at 13:25 +0200, Richard Guenther wrote:
> On Tue, 22 May 2012, William J. Schmidt wrote:
>
> > Here's a revision of the hoist-adjacent-loads patch. Besides hopefully
> > addressing all your comments, I added a gate of at least -O2 for this
> > transformation. Let me know if yo
On Wednesday 23 May 2012 17:11:53 Michael Hope wrote:
> On 24 May 2012 02:16, Mike Frysinger wrote:
> > On Wednesday 23 May 2012 04:17:51 Richard Guenther wrote:
> >> On Wed, 23 May 2012, Andreas Jaeger wrote:
> >> > On Wednesday, May 23, 2012 09:56:31 Richard Earnshaw wrote:
> >> > > [...]
> >> >
On Fri, Jul 29, 2011 at 1:46 AM, Richard Guenther wrote:
>
> I noticed that for binary expressions VRP contains the same bugs
> that CCP once did (it treats UNDEFINED * 0 as UNDEFINED). Then
> I noticed we never hit this bug because we never end up with
> any range being UNDEFINED - which is bad,
On Wed, May 23, 2012 at 7:25 AM, H.J. Lu wrote:
> On Wed, May 23, 2012 at 5:00 AM, Richard Guenther wrote:
>>
>> This finally switches us to not record global vars in referenced-vars.
>> For this to work I had to re-engineer how we handle global var removal
>> from local-decls in remove_unused_lo
On 05/23/2012 04:52 AM, Dodji Seketeli wrote:
I tried to do what the C FE seems to do, which is to consider that the
default location (the global input_location variable) is on the LHS of
the assignment (on the usi variable), rather than on the token that
comes from DEC32_MAX.
That makes sense.
On May 23, 2012, at 3:36 PM, Lawrence Crowl wrote:
> For variables that are not optimized out of memory, I think this
> can work. But if you need to go for registers,
Also trivial... Just one has to generate the context correctly. One has to
save off the registers and then in the context gener
On Wed, 23 May 2012, Michael Meissner wrote:
> An alternative would be for the powerpc64-linux case, should we just delete
> the
> software floating emulation multilib and stop using the -mstrict-align, since
> Linux only runs in big endian mode. The software emulation multilib would be
> built
On powerpc64-linux systems that run on IBM servers, the 32-bit software
emulation library is not built with the Red Hat and SUSE distributions, but the
FSF sources still list it as a multilib. This patch adds a configuration
option (--disable-ppc64-swfloat) to disable building this library.
We've
On 5/21/12, Tom Tromey wrote:
>> "Alexander" == Alexander Monakov writes:
>
> Alexander> Hm, isn't GDB's 'set unwindonsignal on' enough to fix it?
> Alexander> It's useful to have that in your .gdbinit anyway, because the
> Alexander> same issue arises when calling debug_* functions in cc1 fr
On 5/21/12, Mike Stump wrote:
> On May 18, 2012, at 7:48 PM, Lawrence Crowl wrote:
>> On 5/17/12, Mike Stump wrote:
>>> On May 17, 2012, at 2:41 PM, Lawrence Crowl wrote:
> Reusing the compiler for this seems like the only way to go.
> But, we did look at using g++ to parse C++ expression
On 5/23/12, Diego Novillo wrote:
> Part 3 of the VEC C++ conversion. This patch implements all the
> client code changes needed by the API changes made by the first patch.
LGTM.
--
Lawrence Crowl
On 5/23/12, Diego Novillo wrote:
> Part 2 of the VEC C++ conversion. This patch implements the gengtype
> changes.
LGTM.
--
Lawrence Crowl
On 5/23/12, Diego Novillo wrote:
> OK for cxx-conversion branch?
LGTM.
--
Lawrence Crowl
On 24 May 2012 00:27, Paolo Carlini wrote:
> On 05/23/2012 05:39 AM, Michael Hope wrote:
>>
>> On 21/05/12 21:14, Paolo Carlini wrote:
>>>
>>> On 05/21/2012 01:45 AM, Michael Hope wrote:
The testsuite for PR52796 uses the 'target c++11' selector which doesn't
exist in 4.6.
This
On 24 May 2012 02:16, Mike Frysinger wrote:
> On Wednesday 23 May 2012 04:17:51 Richard Guenther wrote:
>> On Wed, 23 May 2012, Andreas Jaeger wrote:
>> > On Wednesday, May 23, 2012 09:56:31 Richard Earnshaw wrote:
>> > > [...]
>> > > This is a behaviour change. It would need RM approval for a re
Hi,
the attached patch allows the use of clock_gettime() with
CLOCK_PROCESS_CPUTIME_ID or CLOCK_THREAD_CPUTIME_ID if the target
doesn't have getrusage() or times(). Such a target is apparently
VxWorks 6.something, see
http://www-ad.fnal.gov/controls/micro_p/manuals/vxworks_application_programmers_
2012/5/7 Jason Merrill :
> On 05/06/2012 04:06 PM, Fabien Chêne wrote:
>>
>> + if (late_enum_values)
>> + VEC_safe_push (tree, gc, late_enum_values, decl);
>
> I would think you could walk the TYPE_VALUES list directly, rather than copy
> it into a temporary VEC.
Indeed, let's use go
On Wed, May 23, 2012 at 9:49 PM, Tobias Burnus wrote:
> *ping*
>
> On 20 May 2012 10:34, Tobias Burnus wrote:
>>
>> *ping*
>>
>> On Tue, 15 May 2012 12:26, Tobias Burnus wrote:
>>>
>>> A rather simple patch.
>>>
>>> Build and regtested on x86-64-linux.
>>> OK for the trunk?
Looks obvious to me :
*ping*
On 20 May 2012 10:34, Tobias Burnus wrote:
*ping*
On Tue, 15 May 2012 12:26, Tobias Burnus wrote:
A rather simple patch.
Build and regtested on x86-64-linux.
OK for the trunk?
I think that is the last patch required for commonly used code.
Remaining are issues with array constructo
Part 2 of the VEC C++ conversion. This patch implements the gengtype
changes.
I extended gengtype to understand templated types. These changes are
not as ugly as I thought they would be. Gengtype has some hardwired
knowledge of VEC_*, which I renamed to vec_t. I'm not even sure why
gengtype n
On Wed, May 23, 2012 at 10:18 AM, Edmar wrote:
> David, Michael,
>
> Thanks for the feedback.
> If you don't object, I will relay the message to the designers.
>
> Meanwhile I have to work with the cards I have, so...
> I will break the patch in three parts:
> - One that includes the very basic, s
On 05/22/12 15:12, Richard Guenther wrote:
But I wonder why CONSTRUCTORs do not inherit TREE_SIDE_EFFECTS
properly ...
the attached patch fixes the ICE and causes no regressions on i686-pc-linux-gnu.
ok?
nathan
2012-05-23 Nathan Sidwell
* tree.c (build_constructor): Propagate TREE_SIDE_
> 2005-11-14 Thomas Quinot
> Olivier Hainque
> Eric Botcazou
> ...
> (create_var_decl): call expand_decl for CONST_DECLs, to set MODE,
> ALIGN SIZE and SIZE_UNIT which we need for later back-annotations.
>
> I don't understand the reference to "back-annotation
On Wed, May 23, 2012 at 6:36 PM, Tobias Burnus wrote:
> Hi Janne,
>
>
> On 05/23/2012 04:44 PM, Janne Blomqvist wrote:
>>
>> some targets such as VXWorks don't provide gettimeofday but do provide
>> clock_gettime. The attached patch allows such targets to get better
>> resolution for the DATE_AND_
The following patch fixes existing code that tried to prevent load-hit-store
(LHS) from being in the same dispatch group. The main problem was use of the
wrong dependency list in is_costly_group(), but I also added code to verify the
memory refs overlap and to emit group ending nops for those I
Hi Janne,
On 05/23/2012 04:44 PM, Janne Blomqvist wrote:
some targets such as VXWorks don't provide gettimeofday but do provide
clock_gettime. The attached patch allows such targets to get better
resolution for the DATE_AND_TIME (up to the 1 millisecond limit of the
API) intrinsic than the 1 sec
David, Michael,
Thanks for the feedback.
If you don't object, I will relay the message to the designers.
Meanwhile I have to work with the cards I have, so...
I will break the patch in three parts:
- One that includes the very basic, scheduling etc.
- One for the Altivec builtins, which I will h
2012/5/23 Georg-Johann Lay :
> Sometimes, even on AVR there is the need to align data.
>
> However, alignments of 2 are ignored at the moment because of
>
> #define ASM_OUTPUT_ALIGN(STREAM, POWER) \
> do { \
> if ((POWER) > 1)
Sometimes, even on AVR there is the need to align data.
However, alignments of 2 are ignored at the moment because of
#define ASM_OUTPUT_ALIGN(STREAM, POWER) \
do { \
if ((POWER) > 1)\
Hi,
some targets such as VXWorks don't provide gettimeofday but do provide
clock_gettime. The attached patch allows such targets to get better
resolution for the DATE_AND_TIME (up to the 1 millisecond limit of the
API) intrinsic than the 1 second resolution provided by the current
fallback of usin
On Wed, May 23, 2012 at 5:00 AM, Richard Guenther wrote:
>
> This finally switches us to not record global vars in referenced-vars.
> For this to work I had to re-engineer how we handle global var removal
> from local-decls in remove_unused_locals. Incidentially that code
> already had some sort
On Wednesday 23 May 2012 04:17:51 Richard Guenther wrote:
> On Wed, 23 May 2012, Andreas Jaeger wrote:
> > On Wednesday, May 23, 2012 09:56:31 Richard Earnshaw wrote:
> > > [...]
> > > This is a behaviour change. It would need RM approval for a release
> > > branch.
> > >
> > > R.
> >
> > There
On Wed, May 23, 2012 at 5:24 AM, Paolo Carlini wrote:
> On 05/23/2012 04:54 AM, Gabriel Dos Reis wrote:
>>
>> On Tue, May 22, 2012 at 8:25 PM, Paolo Carlini
>> wrote:
>>>
>>> Hi,
>>>
>>> some years ago Martin lamented that we weren't consistently warning about
>>> deleting member arrays vs arrays
OK. We shouldn't need to worry about null type, since templates are
handled at the top of the function.
Jason
On 05/23/2012 05:39 AM, Michael Hope wrote:
On 21/05/12 21:14, Paolo Carlini wrote:
On 05/21/2012 01:45 AM, Michael Hope wrote:
The testsuite for PR52796 uses the 'target c++11' selector which
doesn't exist in 4.6.
This patch backports the selector, clearing the 'ERROR:
g++.dg/cpp0x/variadic-v
This finally switches us to not record global vars in referenced-vars.
For this to work I had to re-engineer how we handle global var removal
from local-decls in remove_unused_locals. Incidentially that code
already had some sort of a bitmap (for some weird reason even), thus
I borrowed that and
On 05/23/2012 12:30 PM, Paolo Carlini wrote:
On 05/23/2012 06:30 AM, Jason Merrill wrote:
On 05/22/2012 05:18 PM, Paolo Carlini wrote:
Uhhm, I have an "out of the blue" idea, so please excuse me if for some
"obvious" reason doesn't make sense: don't we have a global variable
saying "where we ar
On Tue, 22 May 2012, William J. Schmidt wrote:
> Here's a revision of the hoist-adjacent-loads patch. Besides hopefully
> addressing all your comments, I added a gate of at least -O2 for this
> transformation. Let me know if you prefer a different minimum opt
> level.
>
> I'm still running SPEC
On Wed, May 23, 2012 at 1:02 PM, Martin Jambor wrote:
> Hi,
>
> the vector operand_map is not freed in inline_merge_summary, this
> patch fixes it. It looks fairly obvious and I also have talked about
> the problem on IRC with Honza yesterday so I will commit it after
> bootstrap and testing on x
Hi,
the vector operand_map is not freed in inline_merge_summary, this
patch fixes it. It looks fairly obvious and I also have talked about
the problem on IRC with Honza yesterday so I will commit it after
bootstrap and testing on x86_64-linux.
I suppose I should then test and commit it to the 4.
On 05/23/2012 06:34 AM, Jason Merrill wrote:
On 05/22/2012 09:25 PM, Paolo Carlini wrote:
some years ago Martin lamented that we weren't consistently warning
about deleting member arrays vs arrays.
I wonder why we look at the code of exp at all. Surely deleting any
expression with array type
On 05/23/2012 06:30 AM, Jason Merrill wrote:
On 05/22/2012 05:18 PM, Paolo Carlini wrote:
Uhhm, I have an "out of the blue" idea, so please excuse me if for some
"obvious" reason doesn't make sense: don't we have a global variable
saying "where we are" in the compiler pipeline?
I'm not sure, b
On 05/23/2012 04:54 AM, Gabriel Dos Reis wrote:
On Tue, May 22, 2012 at 8:25 PM, Paolo Carlini wrote:
Hi,
some years ago Martin lamented that we weren't consistently warning about
deleting member arrays vs arrays. A fix seems simple and passes bootstrap
and testing on x86_64-linux. Note I have
On Wed, May 23, 2012 at 12:13 PM, Jakub Jelinek wrote:
> On Wed, May 23, 2012 at 06:27:21AM -0300, Alexandre Oliva wrote:
>> +static int
>> +drop_overlapping_mem_locs (void **slot, void *data)
>> +{
>> + struct overlapping_mems *coms = (struct overlapping_mems *)data;
>> + dataflow_set *set = co
The current 4.7 branch fails to build on IRIX 6.5:
/vol/gcc/src/hg/gcc-4.7-branch/local/libgo/runtime/go-caller.c:51:1: error:
conflicting types for '__go_file_line'
In file included from
/vol/gcc/src/hg/gcc-4.7-branch/local/libgo/runtime/go-caller.c:11:0:
/vol/gcc/src/hg/gcc-4.7-branch/local/li
On Wed, May 23, 2012 at 06:27:21AM -0300, Alexandre Oliva wrote:
> +static int
> +drop_overlapping_mem_locs (void **slot, void *data)
> +{
> + struct overlapping_mems *coms = (struct overlapping_mems *)data;
> + dataflow_set *set = coms->set;
> + rtx mloc = coms->loc;
> + variable var = (variab
Nothing in var-tracking was prepared to drop MEMs from bindings upon
writes that might modify the MEM contents. That was correct, back when
it was variables (rather than values) that were bound to MEMs, and we
wanted the binding to remain even if the value stored in the variables
changed.
VTA cha
Hi,
the testcase bellow manages to corrupt IPA-REF reference lists.
The problem is that C++ FE creates new symtab node while another is in
construction
via DECL_ASSEMBLER_NAME hook.
Bootstrapped/regtested/comitted x86_64-linux.
Honza
Index: ChangeLog
=
Jason Merrill writes:
> What if the built-in macro appears in a macro defined in a system
> header but used in user code? This would resolve the location all the
> way to the user code, and warn. I think we only want to step out
> until we reach a non-built-in macro, not all the way to the oute
On Wed, 23 May 2012, Andreas Jaeger wrote:
> On Wednesday, May 23, 2012 09:56:31 Richard Earnshaw wrote:
> > [...]
> > This is a behaviour change. It would need RM approval for a release
> > branch.
> >
> > R.
>
> There was agreement by all pushing for the change to use it. So, let's ask
> the
On Wednesday, May 23, 2012 09:56:31 Richard Earnshaw wrote:
> [...]
> This is a behaviour change. It would need RM approval for a release
> branch.
>
> R.
There was agreement by all pushing for the change to use it. So, let's ask
the release managers about their opinion,
Andreas
--
Andreas J
On 23/05/12 08:12, Andreas Jaeger wrote:
> On 05/01/2012 10:52 AM, Richard Earnshaw wrote:
>> On 30/04/12 22:47, Michael Hope wrote:
>>> On 1 May 2012 03:24, Richard Earnshaw wrote:
On 27/04/12 00:27, Michael Hope wrote:
> On 27 April 2012 08:20, Carlos O'Donell wrote:
>> On Mon, Apr
On 05/01/2012 10:52 AM, Richard Earnshaw wrote:
On 30/04/12 22:47, Michael Hope wrote:
On 1 May 2012 03:24, Richard Earnshaw wrote:
On 27/04/12 00:27, Michael Hope wrote:
On 27 April 2012 08:20, Carlos O'Donell wrote:
On Mon, Apr 23, 2012 at 5:36 PM, Michael Hope wrote:
2012-04-24 Michae
54 matches
Mail list logo
