Il 21/05/2012 19:21, Andrew Jenner ha scritto:
Hi Paolo,
On 5/21/2012 10:12 AM, Paolo Bonzini wrote:
That's pretty heavy-weight. Perhaps you can try the usual algorithm of
looking at x-next and x-next-next?
That would only detect cycles of length 1 and 2 though. While that would
cover
Il 21/05/2012 19:49, Dimitrios Apostolou ha scritto:
Thanks for reviewing, in the meantime I'll try to figure out why this
patch doesn't offer any speed-up on ppc64 (doesn't break anything
though), so expect a followup by tomorrow.
Perhaps you hit this?
else if (GET_CODE (XEXP (note,
Il 20/05/2012 20:50, Dimitrios Apostolou ha scritto:
+static void
+df_find_hard_reg_defs_1 (rtx *loc, basic_block bb,
+ int flags, HARD_REG_SET *defs)
BB and FLAGS are not needed here, I am changing this and rebootstrapping.
Paolo
Jason Merrill ja...@redhat.com writes:
On 05/21/2012 10:07 AM, Dodji Seketeli wrote:
Jason Merrillja...@redhat.com writes:
When do we not want to set invocation_location if we're beginning to
expand a macro?
If M itself involves expanding another macro M', we are supposed to call
the
Hi,
This appears to fix the problem with PR53334 and deals with the
fallout of not validating properly operands to movsicc. In addition I
took the opportunity of merging all the other places where we
validized such transforms into a single function and dealt with the
fallout accordingly. It also
On Mon, 21 May 2012, Michael Matz wrote:
Hi,
On Mon, 21 May 2012, Richard Guenther wrote:
This removes the code that makes us walk DECL_INITIAL (recursively)
on add_referenced_var - one source of compile-time hogs in the past
and not strictly necessary.
For this to be a compile
Dear all,
an --enable-maintainers-build fails here with:
configure.ac:99: error: possibly undefined macro: gcc_AC_FUNC_MMAP_BLACKLIST
If this token and others are legitimate, please use m4_pattern_allow.
See the Autoconf documentation.
make[3]: *** [fixincludes/configure] Error 1
This fixes PR53437, at -O0 as we are not having debug stmts there,
we need a dummy init stmt.
Bootstrapped and tested on x86_64-unknown-linux-gnu applied.
Richard.
2012-05-21 Richard Guenther rguent...@suse.de
PR middle-end/53437
* tree-inline.c (setup_one_parameter): Create
On May 22, 2012, at 11:20 AM, Tobias Burnus wrote:
Dear all,
an --enable-maintainers-build fails here with:
configure.ac:99: error: possibly undefined macro: gcc_AC_FUNC_MMAP_BLACKLIST
If this token and others are legitimate, please use m4_pattern_allow.
See the Autoconf
Dear Tobias,
OK for trunk. As you say, the testcase does no harm and so should be retained.
Thanks for the patch.
Cheers
Paul
On 21 May 2012 19:51, Tobias Burnus bur...@net-b.de wrote:
First: I have another rather simple patch, which still needs to be reviewed:
On 05/16/2012 11:43 AM, Richard Guenther wrote:
On Wed, May 16, 2012 at 9:19 AM, Paolo Bonzinibonz...@gnu.org wrote:
OFFSET_TYPE is treated as an integral type for the purpose of conversion
in fold-const.c. However, the GIMPLE verifier disagrees, leading to
verification errors when a cast
On Tue, May 22, 2012 at 12:26 PM, Paolo Carlini
paolo.carl...@oracle.com wrote:
On 05/16/2012 11:43 AM, Richard Guenther wrote:
On Wed, May 16, 2012 at 9:19 AM, Paolo Bonzinibonz...@gnu.org wrote:
OFFSET_TYPE is treated as an integral type for the purpose of conversion
in fold-const.c.
On 05/22/2012 12:38 PM, Richard Guenther wrote:
Can't be this patch though, it only lets more things pass the verifier.
Unless
- /* Allow conversion from integer to offset type and vice versa. */
+ /* Allow conversion from integral to offset type and vice versa. */
if
On Fri, May 18, 2012 at 10:27 PM, Ulrich Weigand uweig...@de.ibm.com wrote:
Richard Guenther wrote:
On Thu, Mar 8, 2012 at 3:29 PM, Ulrich Weigand uweig...@de.ibm.com wrote:
- Should I try to improve forwprop to handle casts and additional re-
association cases until it handles the above
On Tue, May 22, 2012 at 1:09 PM, Paolo Carlini paolo.carl...@oracle.com wrote:
On 05/22/2012 12:38 PM, Richard Guenther wrote:
Can't be this patch though, it only lets more things pass the verifier.
Unless
- /* Allow conversion from integer to offset type and vice versa.
*/
+
This is the next patch in the series to move us to the state not
having global variables in referenced-vars but restricting the
reverse lookup UID - DECL to automatic variables (the main
consumer is the SSA rewriter - which obviously only needs autos).
It introduces a DECL flag to mark virtual
Richard Guenther wrote:
On Fri, May 18, 2012 at 10:27 PM, Ulrich Weigand uweig...@de.ibm.com wrote:
The following patch rewrites associate_plusminus to remove all the
explicitly coded special cases, and instead performs a scan of the
plus/minus tree similar to what is done in
On Tue, May 22, 2012 at 1:58 PM, Ulrich Weigand uweig...@de.ibm.com wrote:
Richard Guenther wrote:
On Fri, May 18, 2012 at 10:27 PM, Ulrich Weigand uweig...@de.ibm.com wrote:
The following patch rewrites associate_plusminus to remove all the
explicitly coded special cases, and instead
On Tue, May 22, 2012 at 2:04 PM, Richard Guenther
richard.guent...@gmail.com wrote:
On Tue, May 22, 2012 at 1:58 PM, Ulrich Weigand uweig...@de.ibm.com wrote:
Richard Guenther wrote:
On Fri, May 18, 2012 at 10:27 PM, Ulrich Weigand uweig...@de.ibm.com
wrote:
The following patch rewrites
Hi,
On 05/17/2012 10:29 PM, Iain Sandoe wrote:
On 17 May 2012, at 21:16, Mike Stump wrote:
On May 17, 2012, at 12:53 PM, Paolo Carlini wrote:
On 05/17/2012 09:47 PM, Jason Merrill wrote:
On 05/17/2012 05:06 AM, Paolo Carlini wrote:
On 05/17/2012 10:33 AM, Gabriel Dos Reis wrote:
I am
Hi,
On Tue, 22 May 2012, Richard Guenther wrote:
I had thought of that as well. But it is not quite that simple -- the
problem is that tree-ssa-reassoc.c as part of its core algorithm
reassociates
expressions all the time while even still building up the tree, see e.g.
linearize_expr
Richard Guenther wrote:
Btw, reassoc (and your patch?) would have the issue that for
a + (b + c) - a it would yield b + c as result which is not an atom
(but still ok, since it is a pre-existing value that is computed in the IL
already). The simple forwprop matching catches this as it
On Tue, May 22, 2012 at 2:50 PM, Ulrich Weigand uweig...@de.ibm.com wrote:
Richard Guenther wrote:
Btw, reassoc (and your patch?) would have the issue that for
a + (b + c) - a it would yield b + c as result which is not an atom
(but still ok, since it is a pre-existing value that is computed
The attached patches fix compilation issues on VxWorks.
a) VxWorks has strerror_r but contrary to POSIX, the function in VxWorks
(at least in older versions) takes only two arguments: errnum and buf
and not also the buffer length. I added a configure check for that variant.
b) There is no
On 05/21/12 11:03, Richard Guenther wrote:
Hmm - I think this papers over the issue that the CONSTRUCTOR is not
properly gimplified - it still contains a TARGET_EXPR which is not valid GIMPLE.
Why is that TARGET_EXPR not gimplified?
As far as I can make out, it just doesn't look inside the
On Mon, 21 May 2012, Christian Bruel wrote:
1) Lazily check the flag validation until all command line spec files
are read. For this purpose, 'read_specs' records specs, to be analyzed
with 'file_spec_p'. Such flags have 'live_cond' = SWITCH_USER
I like the idea of allowing flags mentioned in
Hi,
Here is the new version of the patch
I have fixed two errors in the previous version,
on mips32 the compiler could not expand division and terminated
with ICE, this change fixed the issue:
/* Extrating the higher part of the sum */
tmp = gen_highpart (SImode, tmp);
tmp
On Tue, May 22, 2012 at 3:24 PM, Nathan Sidwell nat...@acm.org wrote:
On 05/21/12 11:03, Richard Guenther wrote:
Hmm - I think this papers over the issue that the CONSTRUCTOR is not
properly gimplified - it still contains a TARGET_EXPR which is not valid
GIMPLE.
Why is that TARGET_EXPR not
During one of the target hook conversions,
rs6000_aix_asm_output_dwarf_table_ref() retained a use of
TARGET_STRIP_NAME_ENCODING macro instead of the target hook, which
broke when Alan cleaned up rs6000.c. Fixed thusly.
- David
* config/rs6000/rs6000.c (rs6000_aix_asm_output_dwarf_table_ref):
On 05/22/2012 03:06 PM, Tobias Burnus wrote:
The attached patches fix compilation issues on VxWorks.
a) VxWorks has strerror_r but contrary to POSIX, the function in
VxWorks (at least in older versions) takes only two arguments: errnum
and buf and not also the buffer length. I added a
On 05/22/2012 05:04 AM, Dodji Seketeli wrote:
The problem is that cpp_get_token_1 can be called when we are at the
beginning of a macro expansion (inside enter_macro_expansion, called
from cpp_get_token_1), *before* context-c.macro is set. This happens
e.g, when we call funlike_invocation_p to
On 05/22/12 15:12, Richard Guenther wrote:
thanks!
But I wonder why CONSTRUCTORs do not inherit TREE_SIDE_EFFECTS
properly ...
yeah, that would seem to be the error. Looking ...
On Fri, 27 Apr 2012, Steven Drake wrote:
2012-04-27 Steven Drake s...@netbsd.org
* gcc.c (do_spec_1): Add %M spec token to output multilib_os_dir.
Thanks, I've committed this patch with the addition of %M to the comment
in gcc.c that documents specs.
--
Joseph S. Myers
On 05/22/2012 08:22 AM, Paolo Carlini wrote:
Ok, thanks. Today I wanted to concretely test and post a patch but I
noticed this other objc bit in objc-next-runtime-abi-01.c which I don't
know how to handle due to the OPT_Wall gate:
warning_at (UNKNOWN_LOCATION, OPT_Wall,
%-fobjc-sjlj-exceptions%
On 05/22/12 07:05, Dinar Temirbulatov wrote:
+ if ((size - 1 BITS_PER_WORD
+BITS_PER_WORD == 32 mode == DImode)
Do note that this patch will not go in with hard-coded
SImode and DImode references.
Which, really, you do not even need.
GET_MODE_BITSIZE (mode) == 2*BITS_PER_WORD
On 05/22/2012 05:42 PM, Jason Merrill wrote:
On 05/22/2012 08:22 AM, Paolo Carlini wrote:
Ok, thanks. Today I wanted to concretely test and post a patch but I
noticed this other objc bit in objc-next-runtime-abi-01.c which I don't
know how to handle due to the OPT_Wall gate:
warning_at
On 05/22/2012 05:49 PM, Paolo Carlini wrote:
On 05/22/2012 05:42 PM, Jason Merrill wrote:
On 05/22/2012 08:22 AM, Paolo Carlini wrote:
Ok, thanks. Today I wanted to concretely test and post a patch but I
noticed this other objc bit in objc-next-runtime-abi-01.c which I don't
know how to handle
On Tue, 22 May 2012, Paolo Bonzini wrote:
Il 21/05/2012 19:49, Dimitrios Apostolou ha scritto:
Thanks for reviewing, in the meantime I'll try to figure out why this
patch doesn't offer any speed-up on ppc64 (doesn't break anything
though), so expect a followup by tomorrow.
Perhaps you hit
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 tests to make sure there are no regressions when
opening
On 05/22/2012 11:55 AM, Paolo Carlini wrote:
FAIL: gcc.dg/opts-1.c (internal compiler error)
FAIL: gcc.dg/opts-1.c -fno-abi-version (test for errors, line )
FAIL: gcc.dg/opts-1.c -fno-lto-compression-level (test for errors, line )
FAIL: gcc.dg/opts-1.c -fno-tree-parallelize-loops (test for
On 05/22/2012 06:42 PM, Jason Merrill wrote:
On 05/22/2012 11:55 AM, Paolo Carlini wrote:
FAIL: gcc.dg/opts-1.c (internal compiler error)
FAIL: gcc.dg/opts-1.c -fno-abi-version (test for errors, line )
FAIL: gcc.dg/opts-1.c -fno-lto-compression-level (test for errors,
line )
FAIL:
Hi,
On 05/22/2012 12:53 AM, Jason Merrill wrote:
On 05/21/2012 04:18 PM, Paolo Carlini wrote:
-check_narrowing (type, init);
+check_narrowing (type, perform_implicit_conversion
+ (type, tinit, tf_none));
Any changes should go inside check_narrowing rather than
When starting a system call, the libgo library needs to save the
registers in a place where the garbage collector can see them, so that
if the registers happen to be pointers the objects to which they point
will not be collected. I thought that I could simply use setjmp for
that. Unfortunately,
On 05/22/2012 12:52 PM, Paolo Carlini wrote:
Let's see if I understand in detail the structure of the new function
(beyond all the simplifications possible because the target is a scalar,
etc): we want something quite similar to implicit_conversion, but at the
end of it, instead of using
Hi Dave.
Without this patch we generate calls to TM_GETTMCLONE for functions
called indirectly, but we don't actually store the clone mapping in
the clone table because we think the functions are not needed.
Compiles fine, dies at runtime. See GCC Bugzilla – Bug 53008
Have you taken a look
On 05/15/12 02:10, Tristan Gingold wrote:
2012-05-15 Tristan Gingold ging...@adacore.com
* config/i386/i386.c (struct ix86_frame): Remove unused frame field.
(ix86_compute_frame_layout): Fix type of stack_alignment_needed
and preferred_alignment.
Ok with a test case.
On 05/15/12 01:52, Tristan Gingold wrote:
2012-05-14 Tristan Gingold ging...@adacore.com
* common/config/ia64/ia64-common.c (ia64_except_unwind_info): Fix typo.
Ok.
r~
On 05/21/2012 02:39 PM, Cary Coutant wrote:
The DW_AT_GNU_pubnames/pubtypes attributes serve two purposes: (1)
they let the linker know which CUs have pubnames pubtypes sections,
and (2) they let us know that the pubnames and pubtypes are reliable
(relative to the incomplete sections that GCC
On Tue, May 22, 2012 at 10:19 AM, Jason Merrill ja...@redhat.com wrote:
I'll let Cary handle the other questions.
Yes, I agree that we want to put some_function in pubnames. I still don't
see how putting the anonymous namespace itself in pubnames helps at all. As
far as pubnames is
On 05/22/2012 07:02 PM, Jason Merrill wrote:
On 05/22/2012 12:52 PM, Paolo Carlini wrote:
Let's see if I understand in detail the structure of the new function
(beyond all the simplifications possible because the target is a scalar,
etc): we want something quite similar to implicit_conversion,
On 05/19/12 14:25, John David Anglin wrote:
2012-05-19 John David Anglin dave.ang...@nrc-cnrc.gc.ca
PR other/53231
* tas_n.c (libat_test_and_set): Correct return. Remove unused variable.
Ok.
r~
On May 22, 2012, at 7:15 AM, David Edelsohn wrote:
* config/rs6000/rs6000.c (rs6000_aix_asm_output_dwarf_table_ref): Use
strip_name_encoding target hook.
Index: rs6000.c
===
--- rs6000.c(revision 187756)
+++ rs6000.c
On 05/18/12 03:48, Chung-Lin Tang wrote:
Hi,
I found a few changes were needed to the dwarf2 pass when trying to
implement epilogue unwind for SH, mainly that the current handling of
annulled-taken branches does not seem correct; the delay slot insn
should be handled in a manner similar to
I've merged gcc-4_7-branch revision 187778 to the gccgo branch.
Ian
On 05/18/12 03:48, Chung-Lin Tang wrote:
@@ -2401,6 +2401,7 @@ scan_trace (dw_trace_info *trace)
{
/* Propagate across fallthru edges. */
dwarf2out_flush_queued_reg_saves ();
+ def_cfa_1 (this_cfa);
maybe_record_trace_start (insn, NULL);
break;
I would expect the linker to start by processing the pubnames/pubtypes
sections, and then if it wants to look through the CUs as well it already
knows which ones it can skip.
The presence or absence of an attribute seems like a fragile way to
determine whether or not particular debug info is
On May 22, 2012, at 8:42 AM, Jason Merrill wrote:
On 05/22/2012 08:22 AM, Paolo Carlini wrote:
Ok, thanks. Today I wanted to concretely test and post a patch but I
noticed this other objc bit in objc-next-runtime-abi-01.c which I don't
know how to handle due to the OPT_Wall gate:
warning_at
On 05/22/2012 08:03 PM, Mike Stump wrote:
On May 22, 2012, at 8:42 AM, Jason Merrill wrote:
On 05/22/2012 08:22 AM, Paolo Carlini wrote:
Ok, thanks. Today I wanted to concretely test and post a patch but I
noticed this other objc bit in objc-next-runtime-abi-01.c which I don't
know how to
On 05/22/2012 01:27 PM, Sterling Augustine wrote:
Anonymous namespaces are funky in general, but gdb would like to be
able to do things like tab completion on:
(gdb) b '(anonymous namespace)::
(gdb) b 'foo::(anonymous namespace)::
Without being able to lookup anonymous namespaces, gdb has no
On Tue, May 22, 2012 at 5:57 PM, Tobias Burnus bur...@net-b.de wrote:
On 05/22/2012 03:06 PM, Tobias Burnus wrote:
The attached patches fix compilation issues on VxWorks.
a) VxWorks has strerror_r but contrary to POSIX, the function in VxWorks
(at least in older versions) takes only two
On Tue, May 22, 2012 at 10:33 PM, Janne Blomqvist
blomqvist.ja...@gmail.com wrote:
On Tue, May 22, 2012 at 5:57 PM, Tobias Burnus bur...@net-b.de wrote:
On 05/22/2012 03:06 PM, Tobias Burnus wrote:
The attached patches fix compilation issues on VxWorks.
a) VxWorks has strerror_r but contrary
Il 22/05/2012 18:26, Dimitrios Apostolou ha scritto:
You are right, and I noticed that if we reverse (actually put straight)
the loop for the PARALLEL defs inside df_defs_record() then the speedup
stands for both x86 and ppc64.
The following patch was tested on x86, do you think it is
Yes, but I would expect this table lookup to be faster than going to the
disk to read the CU DIE and abbrev in order to check for the attribute.
OTOH, I suppose you need to read it anyway if you want to check somehow
whether you should trust the pub* information.
Right. I also need to read
On 05/22/2012 03:42 PM, Janne Blomqvist wrote:
On Tue, May 22, 2012 at 10:33 PM, Janne Blomqvist
blomqvist.ja...@gmail.com wrote:
On Tue, May 22, 2012 at 5:57 PM, Tobias Burnusbur...@net-b.de wrote:
On 05/22/2012 03:06 PM, Tobias Burnus wrote:
The attached patches fix compilation issues on
On Tue, 22 May 2012, Paolo Bonzini wrote:
Il 22/05/2012 18:26, Dimitrios Apostolou ha scritto:
You are right, and I noticed that if we reverse (actually put straight)
the loop for the PARALLEL defs inside df_defs_record() then the speedup
stands for both x86 and ppc64.
The following patch
On 05/16/2012 12:48 PM, Andrew Pinski wrote:
+ /* Handle 0/1 specially because boolean types and precision of one types,
+ will cause the diff to always be 1. Note this really should have
+ simplified before reaching here. */
+ /* A ? 1 : 0 is just (type)(A!=0). */
+ if
This patch adds an AC_ARG_ENABLE option to build/not build
libstdc++-v3. I wrote the patch in order to allow the user to override
the automatic disable for libstdc++-v3 for certain targets.
Patch is against configure.ac in trunk.
Robert Mason
From 69c085f3742e94501f4a202d1321e143afe9a115 Mon
On 12-05-18 17:38 , Cary Coutant wrote:
@@ -5820,6 +5825,14 @@ const struct gcc_debug_hooks dwarf2_debu
representation is done after the entire program has been compiled.
The types below are used to describe the internal representation. */
+/* Whether to generate the DWARF
Hi again,
On 05/22/2012 06:42 PM, Jason Merrill wrote:
On 05/22/2012 11:55 AM, Paolo Carlini wrote:
FAIL: gcc.dg/opts-1.c (internal compiler error)
FAIL: gcc.dg/opts-1.c -fno-abi-version (test for errors, line )
FAIL: gcc.dg/opts-1.c -fno-lto-compression-level (test for errors,
line )
FAIL:
On 12-05-21 20:15 , Cary Coutant wrote:
This patch is for the google/gcc-4_6 branch.
Fission improvements and bug fixes. Adds new DW_OP_GNU_const_index to
handle TLS offsets in debug info. Adds -gpubnames/-gno-pubnames options
to explicitly request .debug_pubnames/pubtypes sections. Adds
In the Go 1 release of the other Go compiler, runtime.Callers had what I
would describe as an off-by-one error. We can't change it now, because
that would break Go 1 backward compatibility. This patch changes libgo
to have the same off-by-one error. Bootstrapped and ran Go testsuite on
On Tue, May 22, 2012 at 01:04:15PM -0700, Cary Coutant wrote:
That might be workable. Let me take a look at the gold changes I'd
need to make for that.
They don't have to be relocations, though -- since they're only used
by the linker, a raw section-relative offset would be sufficient.
But
+/* Whether to generate the DWARF accelerator tables in .debug_pubnames
+ and .debug_pubtypes. This is configured per-target, but can be
+ overridden by the -gpubnames or -gno-pubnames options. */
+
+#define want_pubnames (debug_generate_pub_sections != -1 \
+ ?
On Tue, May 22, 2012 at 1:31 PM, Mike Stump mikest...@comcast.net wrote:
fprintf (asm_out_file, \t.ref %s\n,
- TARGET_STRIP_NAME_ENCODING (frame_table_label));
+ (* targetm.strip_name_encoding) (frame_table_label));
Any reason to not remove (* and )?
I wanted to be
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 to change D to E
because dump_decl cannot cope with COMPONENT_REFs.
Thanks,
Paolo.
[Revised to address review comments and to fix a bug we found late:
We've changed want_pubnames to a static inline function, and changed
the pubnames output to include (ironically enough) inline functions.]
This patch is for the google/gcc-4_6 branch.
Fission improvements and bug fixes. Adds
On Tue, May 22, 2012 at 8:25 PM, Paolo Carlini paolo.carl...@oracle.com 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 to change D to E
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-value1.C:
syntax error in target selector
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, but the question led me to thinking about only
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 is questionable.
Jason
From: Hans-Peter Nilsson h...@axis.com
Date: Wed, 16 May 2012 08:24:41 +0200
From: Hans-Peter Nilsson h...@axis.com
Date: Wed, 9 May 2012 08:02:25 +0200
Ping. I missed the PR number decoration on the ChangeLog entry:
PR rtl-optimization/53176
* rtlanal.c (rtx_cost):
81 matches
Mail list logo
