On Thu, 19 Jan 2012, Jakub Jelinek wrote:
Hi!
It isn't clear why mudflap doesn't instrument DECL_ARTIFICIAL functions,
if it couldn't avoid instrumenting just a subset of them.
But there is certainly no reason why it shouldn't instrument normal clones
of user functions (OpenMP, TM, ISRA,
It's definitely not ok at this stage but at most for next stage1.
OK. I may wait until next stage1.
This is a very narrow pattern-match. It doesn't allow for a[i].x for
example,
even if a[i] is a one-element structure. I think the canonical way of
handling
ADDR_EXPR is to use sth like
This is what I finally committed to trunk. I'll backport this to 4.6
once I have finished testing it there.
2012-01-20 Ramana Radhakrishnan ramana.radhakrish...@linaro.org
PR target/50313
* config/arm/arm.c (arm_load_pic_register): Use
gen_pic_load_addr_unified.
Ping:
Any other opinions on this ?
http://gcc.gnu.org/ml/gcc-patches/2012-01/msg00666.html
Ramana
Kai,
I think there is a typo in the test g++.dg/torture/pr51344.C causing
a regression:
FAIL: g++.dg/torture/pr51344.C -O0 (test for excess errors)
FAIL: g++.dg/torture/pr51344.C -O1 (test for excess errors)
FAIL: g++.dg/torture/pr51344.C -O2 (test for excess errors)
FAIL:
On Fri, Jan 20, 2012 at 12:39 AM, Ian Lance Taylor i...@google.com wrote:
Attached patch adds -mieee to tests that need full IEEE compliance to
pass. While working on patch, I have noticed that go-test.exp doesn't
pass DEFAULT_GOCFLAGS to go_target_compile procedure in expected
format (so,
This fixes PR51903, bootstrapped and tested on x86_64-unknown-linnux-gnu,
installed.
Richard.
2012-01-20 Richard Guenther rguent...@suse.de
PR tree-optimization/51903
* tree-ssa-pre.c (eliminate): Properly purging of EH edges
when removing stmts.
*
2012/1/20 Dominique Dhumieres domi...@lps.ens.fr:
Kai,
I think there is a typo in the test g++.dg/torture/pr51344.C causing
a regression:
FAIL: g++.dg/torture/pr51344.C -O0 (test for excess errors)
FAIL: g++.dg/torture/pr51344.C -O1 (test for excess errors)
FAIL:
2012/1/20 Kai Tietz ktiet...@googlemail.com:
2012/1/20 Dominique Dhumieres domi...@lps.ens.fr:
Kai,
I think there is a typo in the test g++.dg/torture/pr51344.C causing
a regression:
FAIL: g++.dg/torture/pr51344.C -O0 (test for excess errors)
FAIL: g++.dg/torture/pr51344.C -O1 (test
Hi,
Here's a different, partial fix for PR 49204, changing the timed
waiting functions to return future_status, but not returning
future_status::deferred, as that requires the ABI change detailed
above. This doesn't change the library ABI, but might still be too big
a change for 4.7 at this
Hi,
a small diagnostic regression, pretty easy to fix: checking the value
returned by tsubst avoids crashing later in the template_class_depth
loop. Tested x86_64-linux.
Thanks,
Paolo.
/cp
2012-01-20 Paolo Carlini paolo.carl...@oracle.com
PR c++/51402
The following patch fixes the problem.
The test fails on *-apple-darwin*: pr51916.
TIA
Dominique
Hi,
PR51819 is a case where we were actually putting out alignment hints
for the wrong memory size. The attached patch corrects this and
another latent issue that I spotted.
Committed after testing on arm-linux-gnueabi with Neon configurations.
cheers
Ramana
2012-01-20 Ramana Radhakrishnan
Uros Bizjak ubiz...@gmail.com writes:
OK, I agree. But please note that the patch also includes a fix to
pass correctly formatted options to go_target_compile. I guess this
part should be installed anyway, otherwise go_target_compile simply
ignores passed extra options.
Good point, that part
Ian == Ian Lance Taylor i...@google.com writes:
Ian And I just have to repeat that this patch is an ugly ugly hack, since
Ian -mieee should be the default. Perhaps we should investigate having
Ian gcc/go/gospec.c or gcc/go/lang-specs.h somehow add -mieee for those
Ian targets which require it.
Tom Tromey tro...@redhat.com writes:
Ian == Ian Lance Taylor i...@google.com writes:
Ian And I just have to repeat that this patch is an ugly ugly hack, since
Ian -mieee should be the default. Perhaps we should investigate having
Ian gcc/go/gospec.c or gcc/go/lang-specs.h somehow add -mieee
It turns out that in Go interface types can be recursive without
directly referencing a named type, after inherited methods are
finalized. This happens for code like this:
type I {
F() interface { I }
}
The key here is that method F of interface I has a return type which is
an interface
Andreas Krebbel wrote:
2012-01-19 Andreas Krebbel andreas.kreb...@de.ibm.com
PR rtl-optimization/51856
* reload.c (find_reloads_subreg_address): Set the address_reloaded
flag to reloaded.
if (reloaded address_reloaded)
! *address_reloaded = 1;
OK.
Jason
PING!
http://gcc.gnu.org/ml/gcc-patches/2011-11/msg01813.html
-Original Message-
From: Greta Yorsh [mailto:greta.yo...@arm.com]
Sent: 17 November 2011 10:36
To: gcc-patches@gcc.gnu.org
Cc: 'ni...@redhat.com'; Richard Earnshaw; 'p...@codesourcery.com';
'al...@redhat.com'
Subject:
g++.dg/ext/visibility/template9.C is currently failing on targets
without visibility support, like Solaris 8 and 9 with Sun as:
FAIL: g++.dg/ext/visibility/template9.C -std=gnu++98 (test for excess errors)
Excess errors:
Hi!
Unlike narrowing conversion that needs cvt_type, when widening conversion
needs cvt_type, we want to actually convert stuff (possibly using multiple
steps) to cvt_type and only at the end convert to the vectype_out type.
Without this patch we'd attempt on the vect testcases mentioned in the
gcc.misc-tests/gcov-14.c FAILs on Tru64 UNIX for the same reason as on
some HP-UX versions: lack of weak definitions:
Executing on host: /var/gcc/regression/trunk/5.1b-gcc/build/gcc/xgcc
-B/var/gcc/regression/trunk/5.1b-gcc/build/gcc/
Hi!
As detailed in the PR, output_move_double sometimes modifies the
operands array it is called on (when it intends to return a template
string that should be output by the caller). Unfortunately, since
arm_count_output_move_double_insns has been added, this can lead into
clobbering of
Fixed thusly, ok for trunk?
OK.
Thanks,
Ramana
2012-01-20 Jakub Jelinek ja...@redhat.com
PR target/51915
* config/arm/arm.c (arm_count_output_move_double_insns): Call
output_move_double on a copy of operands array.
* gcc.target/arm/pr51915.c: New test.
On 01/19/2012 03:52 PM, Vladimir Makarov wrote:
On 01/18/2012 02:30 PM, Zamyatin, Igor wrote:
Yes, we use Atom for EEMBC measurements.
We'll be glad to help you with your findings.
Thanks.
Unfortunately I tried several alternative patches but I did not find a
better solution (it is mostly
Adding AVR-specific release notes to wwwdocs/htdocs/gcc-4.7/changes.html
Ok?
Johann
Index: changes.html
===
RCS file: /cvs/gcc/wwwdocs/htdocs/gcc-4.7/changes.html,v
retrieving revision 1.73
diff -u -r1.73 changes.html
---
Correct construction of bindings for overloaded symbols.
Index: gcc/testsuite/ChangeLog.pph
2011-01-20 Lawrence Crowl cr...@google.com
* g++.dg/pph/x4overset1.cc: Make passing.
* g++.dg/pph/x4overset2.cc: Make wanted assembly diff.
* g++.dg/pph/x4overset3.cc: Make
For the record...
My LGTM bounced from gcc-patches because I sent it from my phone,
which has no way to send plain text email. grrr.
-cary
On Thu, Jan 19, 2012 at 3:33 PM, Cary Coutant ccout...@google.com wrote:
LGTM
-cary
On Jan 19, 2012 2:45 PM, Sterling Augustine saugust...@google.com
Need to update the comment to cover the return value. OK for 4.7 with that
change.
Thanks, committed as r183348. Here's the final patch...
-cary
2012-01-20 Cary Coutant ccout...@google.com
Dodji Seketeli do...@redhat.com
gcc/ChangeLog:
PR debug/45682
*
On 01/20/12 11:04, Greta Yorsh wrote:
PING!
http://gcc.gnu.org/ml/gcc-patches/2011-11/msg01813.html
This looks like an obviously correct patch, but I'll defer to the Arm
maintainers.
As a result of my recent mangling work, any code that uses variadic
templates will use the forward-compatibility aliases because the
mangling of argument packs has changed. This exposed an issue that we
weren't copying DECL_EXTERNAL from decl to alias along with other
linkage flags in
On Fri, Jan 20, 2012 at 05:04:41PM -, Greta Yorsh wrote:
PING!
http://gcc.gnu.org/ml/gcc-patches/2011-11/msg01813.html
This is ok for trunk. Thanks.
Jakub
I've committed (r183305) a slightly changed variant that merges the two
outer bitmap loops again, like so:
+ EXECUTE_IF_AND_COMPL_IN_BITMAP (work, old_conflicts, 0, i,
bi) {
unsigned j;
bitmap_iterator bj;
-
Long overdue, and regression from when ENTRY_BLOCK and EXIT_BLOCK were handled
differently so applied on mainline/4.6/4.5 branches after testing on x86-linux.
2012-01-20 Eric Botcazou ebotca...@adacore.com
* cfgrtl.c (rtl_dump_bb): Do not dump insns for {ENTRY|EXIT}_BLOCK.
--
Eric
On Fri, 20 Jan 2012, Jakub Jelinek wrote:
Hi!
Unlike narrowing conversion that needs cvt_type, when widening conversion
needs cvt_type, we want to actually convert stuff (possibly using multiple
steps) to cvt_type and only at the end convert to the vectype_out type.
Without this patch we'd
Nathan, I just noticed this path. This is a good improvement over the
existing scheme.
I see one potential problem with the patch -- different instances of
the same comdat function can potentially have different control flows
(due to differences in early inline, early optimizations in different
This is a bit of a hack. All the PPH data is short-lived, and explicitly
managed on the heap. However, we store some GC'd objects in them and the
parser will sometimes run garbage collection.
This was causing problems when we tried to write out the symbol table.
Some trees in it had been GC'd
On Wednesday 11 January 2012 10:06:42 Richard Guenther wrote:
On Tue, Jan 10, 2012 at 8:50 PM, Tijl Coosemans t...@freebsd.org wrote:
On Tuesday 10 January 2012 15:40:15 Richard Guenther wrote:
On Tue, Jan 10, 2012 at 3:38 PM, Richard Guenther
richard.guent...@gmail.com wrote:
On Tue, Jan 10,
On Thu, Jan 5, 2012 at 6:17 PM, Jonathan Wakely jwakely@gmail.com wrote:
Ping.
I think this is a useful improvement to the docs and could prevent the
most commonly-encountered bootstrap failure for inexpert users
building GCC.
OK for trunk?
On 30 December 2011 13:29, Jonathan Wakely
unsigned builtins don't always work, as the type matching code can ignore the
signed/unsigned variants when searching for a type with a particular mode.
This patch fixes this problem. If a type with same unsignededness exists, we
prefer it over a type with the same mode, but different
In Go code like
var _ T = F()
(in Go, _ is an unnamed variable which can not be referenced) the
compiler should check whether a value with the return type of F() can be
assigned to a variable of type T. The compiler was not doing this
check--it was just throwing away the type. This patch
If a Go program used a receiver named _ (which indicates an unnamed
variable), the gccgo frontend would crash. This patch fixes the
problem. Bootstrapped and ran Go testsuite on
x86_64-unknown-linux-gnu. Committed to mainline.
Ian
diff -r 576165e10507 go/gogo.cc
--- a/go/gogo.cc Fri Jan 20
On 20 January 2012 23:08, Quentin Neill wrote:
My 2c - I heartily recommend this patch.
Thanks. I'm a bit surprised noone else has commented - I hoped this
would be a no-brainer, or at least get some constructive feedback for
further improvement.
May I suggest updating
Hi,
On Fri, 20 Jan 2012, Eric Botcazou wrote:
Is it supposed to change the generated code or...?
It was supposed to not change the set of conflicts, no. But I made a
thinko, and sometimes too many conflicts are generated. On the testcases
I tried that wasn't the case, so thanks for finding
This patch fixes an ICE in build_int_cst_wide. We were not writing
out TYPE_MODE for types, causing RTL generation to try to emit an
offset using VOIDmode.
This is not the only problem in this test case. We are also failing
to mark something needed, because with PPH enabled, a whole function
This patch fixes a wrong-code bug in store_bit_field. When storing a
multi-word BLKmode value (such as from a RECORD_TYPE), the last word
is trashed on big-endian targets. See the PR for the gory details.
Bootstrapped and regression tested powerpc64-linux. Fixes 74
testsuite failures. OK for
Hi,
I was looking a bit into PR51398 and noticed this opportunity. It seems
also not a bad idea performance-wise, given in particular that the
function is called in a loop. But maybe it's more suited for Stage 1,
just let me know. Tested x86_64-linux.
Thanks,
Paolo.
//
Looks like the change to put fn_info and counter vars into comdat
section is reverted due to regression.
Assuming the comdat changes are kept, I don't see the point of doing
fn data buffering -- it is certainly important to compare the key with
the current gcov_info to avoid merging to happen
Yep, OK for stage 1.
Jason
On Wed, Jan 18, 2012 at 12:48:45PM +0100, Aurelien Buhrig wrote:
The problem occurs when value is a REG and bitsize BITS_PER_WORD. This
is because wordnum, which is used to get the subword of value, is
incorrectly computed, in BIG_ENDIAN, wrt the number of words needed by
bitsize instead of
51 matches
Mail list logo
