Hello,
This patch removes from tree-vrp the use of TRUTH-bitwise expression codes. Also
it merges the handling for boolean compatible and non-boolean typed
bitwise-binary
expressions.
Additional it adds primitive checks for bitwise-not expression on
boolean-compatible
types.
In substitute_and_fold
On 07/14/2011 08:40 PM, Rainer Orth wrote:
I've got a preliminary NetWare removal patch ready (yet untested), but
have a couple of questions:
* Given that there's a considerable amount of NetWare support still in
src, toplevel support has to stay. On the other hand, the reference
in confi
On 07/14/2011 11:40 AM, Richard Guenther wrote:
> (look how the vectorizer
> for example uses new target hooks instead of generating vectorized RTL
> and then using rtx_cost).
But wouldn't we then end up with just a bunch of special purpose tree_cost
functions
again?! Then we would again be doome
On 07/11/2011 08:16 PM, Daniel Carrera wrote:
This patch improves support for the ALLOCATE statement when using the
coarray library. Specifically, it adds support for the stat= and
errmsg= attributes:
Thanks for the patch - and sorry for the slow review.
Some comments below.
Index: gcc/fort
Steve,
> I have successfully bootstrapped and tested the toplevel libgcc patch on
> IA64 HP-UX. When trying to build IA64 Linux the bootstrap failed with:
great, thanks.
> /bin/sh /wsp/sje/gcc_git/src/gcc/libgcc/../mkinstalldirs
> ./wsp/sje/gcc_git/build-ia64-debian-linux-gnu-gcc/obj_gcc/./gcc
Hi!
If lock contention is high, but all locks are held for relatively short time
and no threads actually goes into futex_wait, we still completely
unnecessarily do lots of futex_wake syscalls.
On Linux with futex, our mutexes have 3 states:
0 - unlocked
1 - locked, uncontended
2 - locked, contend
Rainer Orth writes:
> Installed on mainline, will backport to the 4.6 branch after testing.
Here's the 4.6 branch version I've just installed after
i386-pc-solaris2.8 and sparc-sun-solaris2.8 testing by Eric and myself.
Rainer
2011-07-15 Rainer Orth
Backport from mainline:
On 05/10/11 17:51, Bernd Schmidt wrote:
> This contains the testsuite changes for the C6X port.
Committed this version. No one commented about the changes outside
gcc.target/tic6x, but I think they are reasonably obvious. I'm open to
suggestions for other names for the check_effective_target funct
On 07/15/2011 11:37 AM, Jakub Jelinek wrote:
While __sync_lock_test_and_set isn't a full barrier on all targets,
I hope it doesn't matter, because the inline caller has already done one
__sync_val_compare_and_swap which is a full barrier.
Why not take the occasion to add the __sync_swap extensi
On Fri, Jul 15, 2011 at 12:02:06PM +0200, Paolo Bonzini wrote:
> On 07/15/2011 11:37 AM, Jakub Jelinek wrote:
> >While __sync_lock_test_and_set isn't a full barrier on all targets,
> >I hope it doesn't matter, because the inline caller has already done one
> >__sync_val_compare_and_swap which is a
On 07/15/2011 10:03 AM, Tobias Burnus wrote:
+ /* ERRMSG= */
+ errmsg = null_pointer_node;
+ errlen = build_int_cst (gfc_charlen_type_node, 0);
+ if (code->expr2)
+ {
[...]
+ errlen = gfc_get_expr_charlen (code->expr2);
+ errmsg = gfc_build_addr_expr (pchar_type_node, se.expr);
+ }
While build_
Hello,
To compile the last revision of the MELT branch, I have been obliged to
do the following change in the Makefile:
We were trying to install the file gcc/melt-default-modules which
doesn't exist, we now install melt-default-modules.modlis.
The loops installing the different /melt-default
This fixes a number of testsuite failures on C6X for targets with
floating point hardware. The hardware has the following quirks:
* Divide is implemented using reciprocals; TI requested a default of
-freciprocal-math
* Multiply, comparison and conversion instructions treat denormal
inputs as z
On Fri, Jul 15, 2011 at 2:44 AM, Bernd Schmidt wrote:
> On 05/10/11 17:51, Bernd Schmidt wrote:
>> This contains the testsuite changes for the C6X port.
>
> Committed this version. No one commented about the changes outside
> gcc.target/tic6x, but I think they are reasonably obvious. I'm open to
>
On 07/15/11 14:06, H.J. Lu wrote:
> On Fri, Jul 15, 2011 at 2:44 AM, Bernd Schmidt
> wrote:
>> On 05/10/11 17:51, Bernd Schmidt wrote:
>>> This contains the testsuite changes for the C6X port.
>>
>> Committed this version. No one commented about the changes outside
>> gcc.target/tic6x, but I thin
On 07/15/2011 12:58 PM, Daniel Carrera wrote:
+ label_errmsg = gfc_build_label_decl (NULL_TREE);
+ label_finish = gfc_build_label_decl (NULL_TREE);
There seems to be a goto missing.
This is strange. The problem is definitely in the following if branch
in gfc_trans_array:
if (code->expr1
Hi,
this is what I did in terms of implementing Jon's and Jakub's
suggestions: many thanks to both of you!
The patch should be in general quite conservative and safe, in
particular, the gthr-posix.h changes, which I cannot approve myself,
touch bits only used by libstdc++-v3 + the macro avoi
On Sun, Jul 10, 2011 at 12:20 AM, H.J. Lu wrote:
> TARGET_MEM_REF only works on ptr_mode. That means base and index parts
> of x86 address operand in x32 mode may be in ptr_mode. This patch
> supports 32bit base and index parts in x32 mode. OK for trunk?
>
> Thanks.
>
>
> H.J.
> ---
> 2011-07-
Ira Rosen wrote:
> * gcc.dg/vect/pr49038.c: New test.
> Index: testsuite/gcc.dg/vect/pr49038.c
> ===
> --- testsuite/gcc.dg/vect/pr49038.c (revision 0)
> +++ testsuite/gcc.dg/vect/pr49038.c (revision 0)
> @@ -0,0 +1,38 @@
>
Hi,
On Thu, Jul 14, 2011 at 11:28:32PM +0200, Jan Hubicka wrote:
> >
> > Well, technically they survive until after inlining (because of
> > indirect inlining which also derives information from the lattices
> > corresponding to node->inlined_to node. Results of arithmetic
> > functions are not
On Fri, Jul 15, 2011 at 5:49 AM, Uros Bizjak wrote:
> On Sun, Jul 10, 2011 at 12:20 AM, H.J. Lu wrote:
>
>> TARGET_MEM_REF only works on ptr_mode. That means base and index parts
>> of x86 address operand in x32 mode may be in ptr_mode. This patch
>> supports 32bit base and index parts in x32 m
2011/7/6 Basile Starynkevitch :
> * doc/plugins.texi (Building GCC plugins): gengtype needs its
> gtype.state
Replace "than" in the patch with "as".
I assume it passes make info?
OK with that change, thank you.
--
Laurynas
On 07/15/2011 08:47 AM, Paolo Carlini wrote:
The patch should be in general quite conservative and safe, in
particular, the gthr-posix.h changes, which I cannot approve myself,
touch bits only used by libstdc++-v3 + the macro avoiding the
unconditional inclusion of , which, according to Jakub's
a
> Thanks, however, I'm not confident committing this on Friday when I'm
> going to be offline until Monday noon :-) Moreover, I already have a
I will be flying back to Europe, so you even can't push responsibility to me :)
> newer version that should handle aliases to thunks. The changes since
>
On 07/15/2011 03:36 PM, Jason Merrill wrote:
I'm a little uncomfortable with defining a macro in libstdc++ to be
used by the gthr files in gcc. I would lean more toward a
gthr-posix-conf.h generated by GCC configure.
For sure, I gonna need some help for that... or maybe Jakub can do it?
Paolo
On Fri, Jul 15, 2011 at 09:36:48AM -0400, Jason Merrill wrote:
> On 07/15/2011 08:47 AM, Paolo Carlini wrote:
> >The patch should be in general quite conservative and safe, in
> >particular, the gthr-posix.h changes, which I cannot approve myself,
> >touch bits only used by libstdc++-v3 + the macro
Uros Bizjak writes:
> Alpha needs the same fix. I need following patch to bootstrap the compiler:
>
> --cut here--
> Index: gcc/config.gcc
> ===
> --- gcc/config.gcc(revision 176282)
> +++ gcc/config.gcc(working copy)
> @@ -7
Hi,
gthr-posix.h already uses other macros defined by other library
headers, like _LIBOBJC. gthr-posix-conf.h looks like an overkill to me,
but if e.g. libstdc++ headers defined a 0/1 macro always
(_GTHREAD_USE_TIMEDLOCK 0 would mean don't define it, _GTHREAD_USE_TIMEDLOCK 1
would mean you can s
On Fri, Jul 15, 2011 at 3:03 PM, H.J. Lu wrote:
> On Fri, Jul 15, 2011 at 5:49 AM, Uros Bizjak wrote:
>> On Sun, Jul 10, 2011 at 12:20 AM, H.J. Lu wrote:
>>
>>> TARGET_MEM_REF only works on ptr_mode. That means base and index parts
>>> of x86 address operand in x32 mode may be in ptr_mode. Thi
Hello, gentle maintainer.
This is a message from the Translation Project robot.
A revised PO file for textual domain 'gcc' has been submitted
by the Swedish team of translators. The file is available at:
http://translationproject.org/latest/gcc/sv.po
(This file, 'gcc-4.6.1.sv.po', has just
On Wed, Jul 13, 2011 at 07:00:53PM +0200, Jakub Jelinek wrote:
The patch below implements that slight change, in particular the "4"
suffixes from the op names were dropped, DW_MACINFO_GNU_*_indirect
have DW_FORM_udata and DW_FORM_strp arguments now (i.e. DWARF_OFFSET_SIZE
large) and DW_MACINFO_GNU_
On Fri, Jul 15, 2011 at 8:25 AM, Uros Bizjak wrote:
> On Fri, Jul 15, 2011 at 3:03 PM, H.J. Lu wrote:
>> On Fri, Jul 15, 2011 at 5:49 AM, Uros Bizjak wrote:
>>> On Sun, Jul 10, 2011 at 12:20 AM, H.J. Lu wrote:
>>>
TARGET_MEM_REF only works on ptr_mode. That means base and index parts
As discussed, here's the patch that obsoletes NetWare x86 on the 4.6
branch.
Tested by configuring/building on i386-pc-solaris2.11 with --target
i386-pc-netware. As expected, without --enable-obsolete, the build
fails in gcc, with --enable-obsolete, it continues.
Ok for the 4.6 branch?
On 07/15/2011 02:37 AM, Jakub Jelinek wrote:
> Any comments? Can anyone see meassurable differences on some benchmark?
>
> 2011-07-15 Jakub Jelinek
>
> * config/linux/wait.h (do_spin): New inline, largely copied
> from do_wait, just don't do futex_wait here, instead return true if
Corresponding the the NetWare obsoletion and removal (upcoming,
currently being tested) patches, here's the wwwdocs change.
Ok?
Rainer
2011-07-15 Rainer Orth
* htdocs/gcc-4.6/changes.html: Document Netware x86 obsoletion.
* htdocs/gcc-4.7/changes.html: Document NetWar
On 07/14/2011 02:42 PM, Eric Botcazou wrote:
> PR target/48220
> * doc/md.texi (Standard Names): Document window_save.
> * cfgexpand.c (expand_debug_parm_decl): New function extracted from
> expand_debug_expr and expand_debug_source_expr. If the target has
> a window_
On Fri, Jul 15, 2011 at 5:44 PM, H.J. Lu wrote:
> TARGET_MEM_REF only works on ptr_mode. That means base and index parts
> of x86 address operand in x32 mode may be in ptr_mode. This patch
> supports 32bit base and index parts in x32 mode. OK for trunk?
>
> Thanks.
>
>>
On Fri, Jul 15, 2011 at 9:01 AM, Uros Bizjak wrote:
> On Fri, Jul 15, 2011 at 5:44 PM, H.J. Lu wrote:
>
>> TARGET_MEM_REF only works on ptr_mode. That means base and index parts
>> of x86 address operand in x32 mode may be in ptr_mode. This patch
>> supports 32bit base and index par
On Fri, Jul 15, 2011 at 6:07 PM, H.J. Lu wrote:
If the first form of the address is not OK (it does not represent the
hardware operation), then it should not enter into the insn stream.
This means, that it should be fixed ("legitimized") to second form by
appropriate function
On Mon, 11 Jul 2011, harsha.jaga...@amd.com wrote:
> Is it OK to commit to trunk?
Please also think of updating the release notes for GCC 4.7. :-)
Gerald
On Fri, Jul 15, 2011 at 9:09 AM, Uros Bizjak wrote:
> On Fri, Jul 15, 2011 at 6:07 PM, H.J. Lu wrote:
>
> If the first form of the address is not OK (it does not represent the
> hardware operation), then it should not enter into the insn stream.
> This means, that it should be fixed (
Hello,
The following patch add support for PLUGIN_PRE_GENERICIZE callback.
The add_sysdata_pre_genericize patch add a field
(sysdata_pre_genericize) in initial system data, allowing to register a
closure to be called on PLUGIN_PRE_GENERICIZE event. This patch must be
first applied and a make
Hello,
This is a [I believe obvious] cleanup patch that was done while
looking at libcpp. It just uses the source_location typedef in some
function declarations in lieu of unsigned int.
Tested on x86_64-unknown-linux-gnu against trunk.
libcpp/
* directives.c (struct if_stack): Use sourc
On 07/15/2011 08:42 AM, Jakub Jelinek wrote:
> The newly added opcodes:
> DW_MACINFO_GNU_define_indirect0xe0
> This opcode has two arguments, one is uleb128 lineno and the
> other is offset size long byte offset into .debug_str. Except
> for the encoding of the s
Le 15 juil. 2011 à 18:17, Pierre Vittet a écrit :
> Hello,
>
> The following patch add support for PLUGIN_PRE_GENERICIZE callback.
>
> The add_sysdata_pre_genericize patch add a field (sysdata_pre_genericize) in
> initial system data, allowing to register a closure to be called on
> PLUGIN_PRE
On Fri, Jul 15, 2011 at 9:09 AM, Uros Bizjak wrote:
> On Fri, Jul 15, 2011 at 6:07 PM, H.J. Lu wrote:
>
> If the first form of the address is not OK (it does not represent the
> hardware operation), then it should not enter into the insn stream.
> This means, that it should be fixed (
Paolo Bonzini writes:
> On 07/14/2011 08:40 PM, Rainer Orth wrote:
>> I've got a preliminary NetWare removal patch ready (yet untested), but
>> have a couple of questions:
>>
>> * Given that there's a considerable amount of NetWare support still in
>>src, toplevel support has to stay. On the
On Jul 15, 2011, at 4:09 AM, Bernd Schmidt wrote:
> This fixes a number of testsuite failures on C6X for targets with
> floating point hardware. The hardware has the following quirks:
>
> * Divide is implemented using reciprocals; TI requested a default of
> -freciprocal-math
> * Multiply, compar
Hello,
Here is a little patch that fix build on my red hat system. It should work for
both the plugin and the branch version (although i could not generate the new
plugin because upgrade-warmelt require unifdef that i don't have on my system,
so the plugin version has not been tested directly f
Le 15 juil. 2011 à 19:25, Romain Geissler a écrit :
> Please check if it still work for you, i may have broken things !
Please try with clean installs (ie install gcc in a whole new directory for the
branch or remove any previous melt related files for a plugin install).
> (this includes
This
Hi Paolo,
> -Original Message-
> From: gcc-patches-ow...@gcc.gnu.org [mailto:gcc-patches-
> ow...@gcc.gnu.org] On Behalf Of Yufeng Zhang
> Sent: 01 July 2011 18:00
> To: 'Paolo Carlini'
> Cc: gcc-patches@gcc.gnu.org; libstd...@gcc.gnu.org
> Subject: RE: [PING] [PATCH, libstdc++-v3] Add new
On 07/15/2011 07:30 PM, Yufeng Zhang wrote:
There is no more comment received. I wonder if it is OK to get the
patch committed.
What else? I thought you had already committed it ;)
Paolo.
On Jul 15, 2011, at 2:44 AM, Bernd Schmidt wrote:
> Committed this version. No one commented about the changes outside
> gcc.target/tic6x, but I think they are reasonably obvious. I'm open to
> suggestions for other names for the check_effective_target functions.
They look fine. For gcc.dg/tortur
On 07/15/2011 10:19 AM, Rainer Orth wrote:
> After this patch, the only netware references in-tree are from toplevel
> configure.ac (still needed for the netware support in src), config.sub
> (from upstream), and gcc/po/*.po for config/i386/netware.h.
>
> Bootstrapped without regressions on i386-p
> "Jakub" == Jakub Jelinek writes:
Jakub> The patch below implements that slight change, in particular the
Jakub> "4" suffixes from the op names were dropped,
Jakub> DW_MACINFO_GNU_*_indirect have DW_FORM_udata and DW_FORM_strp
Jakub> arguments now (i.e. DWARF_OFFSET_SIZE large) and
Jakub> DW
This fixes ICE in combine caused by an invalid constant for SImode.
We should have been using gen_int_mode. A similar fix was applied
on arm a few months ago.
This is a regression caused by my rewrite of casesi a few years ago.
Other uses of GEN_INT in pa.md need to be reviewed. I think there
a
On Fri, Jul 15, 2011 at 12:15:48PM -0600, Tom Tromey wrote:
> > "Jakub" == Jakub Jelinek writes:
>
> Jakub> The patch below implements that slight change, in particular the
> Jakub> "4" suffixes from the op names were dropped,
> Jakub> DW_MACINFO_GNU_*_indirect have DW_FORM_udata and DW_FORM_
> "Dodji" == Dodji Seketeli writes:
Dodji> libcpp/
Dodji> * directives.c (struct if_stack): Use source_location as type
Dodji> here.
Dodji> * include/cpplib.h (struct cpp_callbacks) indent, def_pragma, used_define, used_undef>: Properly use
Dodji> source_location as parameter type, rathe
> "Jakub" == Jakub Jelinek writes:
>> The .debug_macinfo section doesn't have any header describing its
>> contents. How would a consumer know which offset size to use?
Jakub> The same way as it knows how to interpret the second operands of
Jakub> DW_MACINFO_start_file.
Ok, duh.
I updated
On 07/15/2011 02:16 PM, Tobias Burnus wrote:
if (code->expr1 || code->expr2)
{
Side remark: One actually only needs to take care whether there is a
STAT=. If there is only an ERRMSG=, the code is unreachable as without
STAT= one gets a run-time error, when an error occurs - and if no error
occu
This is OK.
Jason
On 07/13/2011 04:28 PM, Jason Merrill wrote:
I'm using --tool_opts to pass the extra -std=c++0x argument to the
compiler. Previously in my own testing I've used
--target_board=unix/-std=c++0x, but that is problematic because options
from --target_board come after options from dg-options, leading
On Wed, Jul 13, 2011 at 01:37:22PM -0700, Andrew Pinski wrote:
> Hi,
> The problem here is that the type of the POINTER_PLUS_EXPR is
> incorrect and also the non folded version leaks to the IR. This patch
> fixes those two problems and fixes the ICE.
>
> OK? Bootstrapped and tested on x86_64-li
Nice solution :)! A few things inline below:
> + /* Read and process the symbol table. */
> + pph_in_symtab (stream);
> }
>
Why read the symbol table last? I would expect that we would read this
first, before reading the bindings, then we don't need to change the
actual pph_in_* functions to
On 7/9/2011 8:02 AM, Tobias Burnus wrote:
Tobias Burnus wrote:
This patch adds a run-time error function to mpi.c, which gives a
proper error message including the image number. Additionally, it
allows to clean up the error handling, avoiding the duplicated
declaration of strings.
+static void
Jakub Jelinek wrote:
Tested with libgomp testsuite and looked at performance numbers of Sho's
omp_fib.c and libgomp.c/sort-1.c, unfortunately the differences looked to be
in the noise. But, e.g. on omp_fib.c strace -f shows that the number of
futex FUTEX_WAKE syscalls went down a lot (from ~ 750
On 07/15/2011 10:34 PM, Nathan Froyd wrote:
+static void
+runtime_error (int error, const char *message, ...)
+{
+ va_list ap;
+ fprintf (stderr, "Fortran runtime error on image %d: ", caf_this_image);
+ va_start (ap, message);
+ fprintf (stderr, message, ap);
Did you mean to call vfprintf here?
On Fri, Jul 15, 2011 at 09:22:42AM -0700, Richard Henderson wrote:
> On 07/15/2011 08:42 AM, Jakub Jelinek wrote:
>
> > The newly added opcodes:
> > DW_MACINFO_GNU_define_indirect 0xe0
> > This opcode has two arguments, one is uleb128 lineno and the
> > other is offset size lo
Daniel Carrera wrote:
On 07/15/2011 10:34 PM, Nathan Froyd wrote:
+ va_start (ap, message);
+ fprintf (stderr, message, ap);
Did you mean to call vfprintf here?
Well spotted! Thanks for the report, Nathan!
2011-07-15 Daniel Carrera
* caf/mpi.c (caf_runtime_error): Change fprintf to v
On Fri, Jul 15, 2011 at 16:02, Gabriel Charette wrote:
>> + /* Read and process the symbol table. */
>> + pph_in_symtab (stream);
>> }
>>
>
> Why read the symbol table last?
Because the symbol identifiers need to be placed in the global
bindings, which are not read until later. This was my
Daniel Carrera wrote:
I propose this:
if (!gfc_array_allocate (&se, expr, stat, errmsg, errlen))
{
... allocate scalar ...
}
if (code->expr1)
{
/* The coarray library already sets the errmsg. */
if (gfc_option.coarray == GFC_FCOARRAY_LIB
&& gfc_expr_attr (expr).codimension)
ptr(10,1:) => target was accepted as for the check "(10,1:)" was seen as
equivalent to the valid "(10:, 1:)" - although the first dimension is
not a range but an element. (Side note: (10:, 1:) would be wrong as well
as one then needs to have the same rank.)
Build and regtested on x86-64-linux.
On Fri, Jul 8, 2011 at 03:32, Richard Guenther wrote:
> On Thu, 7 Jul 2011, Sebastian Pop wrote:
>
>> Hi,
>>
>> First there are two cleanup patches independent of the fix:
>>
>> Start counting nesting level from 0.
>> Do not compute twice type, lb, and ub.
>>
>> Then the patch that fixes PR476
This patch adds an expected checksum for the tests expecting an asm diff.
This way if we were expecting an asm diff, still get one, but a different one,
we know (before this patch we would ignore this, generating an XFAIL as usual,
as the status of "having an asm diff" itself hadn't changed).
I
Reviewed in person by Lawrence.
Shortened XFAIL message from previous patch.
Also, quick side note, in the first description of this patch I said I used
"exec grep", I meant "exec diff".
Gab
2011-07-15 Gabriel Charette
* g++.dg/pph/c1builtin-integral.cc: Add expected diff checksum.
OK with the change below.
Diego.
http://codereview.appspot.com/4744043/diff/3001/gcc/testsuite/lib/dg-pph.exp
File gcc/testsuite/lib/dg-pph.exp (right):
http://codereview.appspot.com/4744043/diff/3001/gcc/testsuite/lib/dg-pph.exp#newcode131
gcc/testsuite/lib/dg-pph.exp:131: set adiff [catch {
On 07/14/2011 04:07 PM, Richard Henderson wrote:
> This finally brings us to something that can support shrink-wrapping.
> As mentioned in the description of the last patch, this is 95% of
> what Bernd had in his last 007-dw2cfg patch, except for the remember/
> restore_state stuff. And hopefully
On 7/15/11, Gabriel Charette wrote:
> This patch adds an expected checksum for the tests expecting an asm diff.
>
> This way if we were expecting an asm diff, still get one, but a different
> one, we know (before this patch we would ignore this, generating an XFAIL as
> usual, as the status of "ha
On 7/15/11, Lawrence Crowl wrote:
> On 7/15/11, Gabriel Charette wrote:
>> This patch adds an expected checksum for the tests expecting an asm diff.
>>
>> This way if we were expecting an asm diff, still get one, but a different
>> one, we know (before this patch we would ignore this, generating
See below.
http://codereview.appspot.com/4744043/diff/3001/gcc/testsuite/lib/dg-pph.exp
File gcc/testsuite/lib/dg-pph.exp (right):
http://codereview.appspot.com/4744043/diff/3001/gcc/testsuite/lib/dg-pph.exp#newcode131
gcc/testsuite/lib/dg-pph.exp:131: set adiff [catch {exec diff
"$bname.s-pph"
> > New algorithm for move-mode selection is implemented for move_by_pieces,
> > store_by_pieces.
> > x86-specific ix86_expand_movmem and ix86_expand_setmem are also changed in
> > similar way, x86 cost-models parameters are slightly changed to support
> > this. This implementation checks if array'
On Fri, Jul 15, 2011 at 19:21, wrote:
> It's less affected by merges (in particular the merge timestamp doesn't
> show up in the diff, so unless a merge from trunk changes the actual
> assembly, the diff is the same as before)
Ah, good point.
> Also, the generation of checksums is not harder t
On 07/16/11 01:08, Richard Henderson wrote:
> On 07/14/2011 04:07 PM, Richard Henderson wrote:
>> This finally brings us to something that can support shrink-wrapping.
>> As mentioned in the description of the last patch, this is 95% of
>> what Bernd had in his last 007-dw2cfg patch, except for th
On 07/15/2011 04:24 PM, Bernd Schmidt wrote:
> What's wrong with -freorder-blocks-and-partition? Something preexisting,
> or introduced with these changes?
Pre-existing.
The .gcc_except_table format includes a encoded displacement from
a call site to a handler. We cannot represent this displacem
A simple conversion of reallocated array into a VEC.
More of the subroutines should actually use this VEC
rather than iterating over all blocks and edges, but
this patch only touches the direct users of the data
that became the VEC.
Tested on x86_64-linux and committed.
r~
* bb-reorder.
This patch adds 'make check-g++-strict-gc' for running the C++ testsuite
with aggressive GC tuning for catching GC issues that might otherwise
lie undetected for a while. And it fixes several current issues that I
found using it: the GTY markings I had put in except.c had no effect
because I h
* Matthias Klose wrote on Sat, Jul 09, 2011 at 05:37:46PM CEST:
> On 07/07/2011 10:35 PM, Ralf Wildenhues wrote:
> > On Thu, Jul 07, 2011 at 10:26:59PM +0200, Jakub Jelinek wrote:
> >> On Thu, Jul 07, 2011 at 10:22:37PM +0200, Matthias Klose wrote:
> >>> +AC_PROG_LIBTOOL
> >
> > This tests the wro
I would like to propose this patch as a step toward building gcc using a
C++ compiler. This patch builds stage1 with the C compiler as usual,
and defaults to building stages 2 and 3 with a C++ compiler built during
stage 1. This means that the gcc installed and used by most people will
be built b
On Fri, Jul 15, 2011 at 11:52 PM, Ian Lance Taylor wrote:
> I would like to propose this patch as a step toward building gcc using a
> C++ compiler. This patch builds stage1 with the C compiler as usual,
> and defaults to building stages 2 and 3 with a C++ compiler built during
> stage 1. This m
89 matches
Mail list logo
