PING 3: For review
Hi,
Please review the attached patch and you can view the
explanations for the earlier communication below.
NOTE: From now on , Jayant (jayant.so...@kpitcummins.com) will be
posting the patches related to CR16. Please feel free to contact him
if you need any information
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
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
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 doomed
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:
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
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,
Rainer Orth r...@cebitec.uni-bielefeld.de 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
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
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
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 full
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
On Fri, Jul 15, 2011 at 2:44 AM, Bernd Schmidt ber...@codesourcery.com 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
On 07/15/11 14:06, H.J. Lu wrote:
On Fri, Jul 15, 2011 at 2:44 AM, Bernd Schmidt ber...@codesourcery.com
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,
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
On Sun, Jul 10, 2011 at 12:20 AM, H.J. Lu hongjiu...@intel.com 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.
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 going to
On Fri, Jul 15, 2011 at 5:49 AM, Uros Bizjak ubiz...@gmail.com wrote:
On Sun, Jul 10, 2011 at 12:20 AM, H.J. Lu hongjiu...@intel.com 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
2011/7/6 Basile Starynkevitch bas...@starynkevitch.net:
* 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 unistd.h, which, according to
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?
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
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
On Fri, Jul 15, 2011 at 3:03 PM, H.J. Lu hjl.to...@gmail.com wrote:
On Fri, Jul 15, 2011 at 5:49 AM, Uros Bizjak ubiz...@gmail.com wrote:
On Sun, Jul 10, 2011 at 12:20 AM, H.J. Lu hongjiu...@intel.com wrote:
TARGET_MEM_REF only works on ptr_mode. That means base and index parts
of x86
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
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
On Fri, Jul 15, 2011 at 8:25 AM, Uros Bizjak ubiz...@gmail.com wrote:
On Fri, Jul 15, 2011 at 3:03 PM, H.J. Lu hjl.to...@gmail.com wrote:
On Fri, Jul 15, 2011 at 5:49 AM, Uros Bizjak ubiz...@gmail.com wrote:
On Sun, Jul 10, 2011 at 12:20 AM, H.J. Lu hongjiu...@intel.com wrote:
TARGET_MEM_REF
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 ja...@redhat.com
* config/linux/wait.h (do_spin): New inline, largely copied
from do_wait, just don't do futex_wait here, instead
Corresponding the the NetWare obsoletion and removal (upcoming,
currently being tested) patches, here's the wwwdocs change.
Ok?
Rainer
2011-07-15 Rainer Orth r...@cebitec.uni-bielefeld.de
* htdocs/gcc-4.6/changes.html: Document Netware x86 obsoletion.
*
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_save
On Fri, Jul 15, 2011 at 5:44 PM, H.J. Lu hjl.to...@gmail.com 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.
---
On Fri, Jul 15, 2011 at 9:01 AM, Uros Bizjak ubiz...@gmail.com wrote:
On Fri, Jul 15, 2011 at 5:44 PM, H.J. Lu hjl.to...@gmail.com 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
On Fri, Jul 15, 2011 at 6:07 PM, H.J. Lu hjl.to...@gmail.com 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
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 ubiz...@gmail.com wrote:
On Fri, Jul 15, 2011 at 6:07 PM, H.J. Lu hjl.to...@gmail.com 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
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
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
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
On Fri, Jul 15, 2011 at 9:09 AM, Uros Bizjak ubiz...@gmail.com wrote:
On Fri, Jul 15, 2011 at 6:07 PM, H.J. Lu hjl.to...@gmail.com 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
Paolo Bonzini bonz...@gnu.org 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 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, comparison
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
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 newlib
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
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
Jakub == Jakub Jelinek ja...@redhat.com 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
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
On Fri, Jul 15, 2011 at 12:15:48PM -0600, Tom Tromey wrote:
Jakub == Jakub Jelinek ja...@redhat.com 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
Dodji == Dodji Seketeli do...@redhat.com writes:
Dodji libcpp/
Dodji * directives.c (struct if_stack): Use source_location as type
Dodji here.
Dodji * include/cpplib.h (struct cpp_callbacks)include, define, undef,
Dodji indent, def_pragma, used_define, used_undef: Properly use
Dodji
Jakub == Jakub Jelinek ja...@redhat.com 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
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
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
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
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 ~
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 long byte
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 dcarr...@gmail.com
* caf/mpi.c (caf_runtime_error):
On Fri, Jul 15, 2011 at 16:02, Gabriel Charette gch...@google.com 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
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.
OK
On Fri, Jul 8, 2011 at 03:32, Richard Guenther rguent...@suse.de 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
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 gch...@google.com
* g++.dg/pph/c1builtin-integral.cc: Add expected
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 gch...@google.com 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
On 7/15/11, Lawrence Crowl cr...@google.com wrote:
On 7/15/11, Gabriel Charette gch...@google.com 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
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's
On Fri, Jul 15, 2011 at 19:21, gch...@google.com 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
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
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~
*
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
83 matches
Mail list logo
