Hi,
value_replacement in PHIOPT currently works only when there is one
PHI (which is non virtual).
http://gcc.gnu.org/ml/gcc-patches/2012-01/msg01195.html improves the
situation but we can improve it even more as replacing a PHI argument
with a SSA_NAME is almost always a benefit.
This patch imp
> this breaks builds configured with --enable-libstdcxx-debug.
confirmed
> Tried
> the following (not yet working) fix.
OK. The attached is closer, but still not quite there.
-benjamindiff --git a/libstdc++-v3/src/Makefile.am b/libstdc++-v3/src/Makefile.am
index 87b2a16..59cc57d 100644
--- a
As it turns out, this bug depended on vector allocation size.
xref_basetypes asks for space for a certain number of bases, then fills
up the vector, and assumes that if there's any space left we must have
hit a shared virtual base, i.e. diamond-shaped inheritance. But since
my vec.c patch for
> While we can change it, it is certainly valid as is, #pragma GCC visibility
> can happen in lots of places and just marks where the default visibility
> is adjusted. If clang errors on this, it is broken.
Sorry, one more case that gcc accepts where it is not clear what the
result should be:
--
> While we can change it, it is certainly valid as is, #pragma GCC visibility
> can happen in lots of places and just marks where the default visibility
> is adjusted. If clang errors on this, it is broken.
It doesn't. As far as I can tell, in the absence of templates clang
produces the same resu
On 01/24/2012 08:32 PM, Andi Kleen wrote:
Hi,
>
> I found that all thread local variables are instrumented with
> _ITM_W/R* calls whereas they should not be shared with other
> threads. This patch takes care of thread locals into requires_barrier
> and also adds the local save/restore for the
> The issue that I'm trying to solve is that we will have at least two
> targets whose test-and-set insn does not define "set" as 1, as a
> variable of type "bool" would expect. In the case of Sparc we
> *could* make the test-and-set implementation test for any non-zero
> value, but in the case o
The issue that I'm trying to solve is that we will have at least two targets
whose test-and-set insn does not define "set" as 1, as a variable of type
"bool" would expect. In the case of Sparc we *could* make the test-and-set
implementation test for any non-zero value, but in the case of m68k t
On 01/24/2012 07:32 PM, Torvald Riegel wrote:
* Remove ITM_REGPARM from _ITM_beginTransaction since on x86-32, a
> variadic function ignores regparm.
> * Add ITM_PURE to _ITM_addUserCommitAction and _ITM_addUserUndoAction to
> be usable inside transactions.
Those should be called from transac
Patrick Marlier writes:
> Hi,
>
> I found that all thread local variables are instrumented with
> _ITM_W/R* calls whereas they should not be shared with other
> threads. This patch takes care of thread locals into requires_barrier
> and also adds the local save/restore for them. This patch also
>
On Tue, 2012-01-24 at 19:12 -0500, Patrick Marlier wrote:
> I propose some minor modifications to libitm.h:
> * Add a link to current TM-ABI document.
We should link to libitm.texi instead because this describes the
interface that we implement.
> * Remove ITM_REGPARM from _ITM_beginTransaction si
Hi,
I propose some minor modifications to libitm.h:
* Add a link to current TM-ABI document.
* Remove ITM_REGPARM from _ITM_beginTransaction since on x86-32, a
variadic function ignores regparm.
* Add ITM_PURE to _ITM_addUserCommitAction and _ITM_addUserUndoAction to
be usable inside transactio
I have committed a patch to update the testsuite under
gcc/testsuite/go.test/test to the current Go testsuite. This overall
patch is too large to include in this e-mail message. There were some
changes to the testsuite driver, which I have included here. Ran Go
testsuite on x86_64-unknown-linux-
Merge unemitted_tinfo_decls and keyed_classes. We do not have a test
case failing for keyed_classes, so the latter is anticipatory.
Add a 'pph asm xokay' test marker for assembly differences that are
benign. We would rather have identical assembly, but it is just not
important right now. These
This patch to the Go frontend adds in an error if a case in a type
switch can not match the type of the switch value, because the case type
does not implement methods of the switch value. Bootstrapped and ran Go
testsuite on x86_64-unknown-linux-gnu. Committed to mainline.
Ian
diff -r b4d67f01b
On 01/25/2012 10:16 AM, Aldy Hernandez wrote:
> The attached patch fixes the ICE in the PR, though it won't do what
> the user ultimately wants to do, given the limitations described.
> Perhaps we could create another PR and tag it with an enhancement
> request.
An enhancement request pr sounds go
On Tue, Jan 24, 2012 at 10:26 PM, Eric Botcazou wrote:
> Starting with the 4.5.x series, we have pathological cases (Ada code generated
> by a code generator from a model) where FWPROP takes 80% of the compilation
> time at -O1 (for essentially no benefits). There are very few basic blocks
> (typ
The problem here is that -flto cannot equate the instrumentation
functions being generated with a user supplied version of the library
functions. This would happen if the user tried to link a transactional
program with libitm with -flto (as in -fwhole-program, etc).
This is an easy problem to
Go does not permit taking a slice of an array literal. This patch
implements that in the gccgo frontend, and cleans up a bit of the
surrounding code. One now-obsolete test case is removed. Bootstrapped
and ran Go testsuite on x86_64-unknown-linux-gnu. Committed to
mainline.
Ian
Index: gcc/go/
Also need to update doc/invoke.texi file for the new option.
http://codereview.appspot.com/5461043/diff/16001/gcc/cfgexpand.c
File gcc/cfgexpand.c (right):
http://codereview.appspot.com/5461043/diff/16001/gcc/cfgexpand.c#newcode1531
gcc/cfgexpand.c:1531: record_or_union_type_has_array (const
OK for google branches.
http://codereview.appspot.com/5461043/diff/16001/gcc/cfgexpand.c
File gcc/cfgexpand.c (right):
http://codereview.appspot.com/5461043/diff/16001/gcc/cfgexpand.c#newcode1597
gcc/cfgexpand.c:1597: contain an array or are arrays. */
"," before "or", and
two spaces before "*/
On Tue, Jan 24, 2012 at 10:26:28PM +0100, Eric Botcazou wrote:
> +static bool
> +is_too_expensive (const char *pass)
> +{
> + int ratio = DF_USES_TABLE_SIZE () / (n_basic_blocks - NUM_FIXED_BLOCKS);
> +
> + /* Trying to propagate into uses in functions with gigantic basic blocks
> + will take
Starting with the 4.5.x series, we have pathological cases (Ada code generated
by a code generator from a model) where FWPROP takes 80% of the compilation
time at -O1 (for essentially no benefits). There are very few basic blocks
(typically 1) and tens of thousands of uses registered with DF, s
2012/1/19 Jason Merrill :
> When we have a class-scope using-declaration that nominates functions, we
> want to insert those functions into the derived class' CLASSTYPE_METHOD_VEC.
> In non-template code we do this in handle_using_decl, which is called from
> check_bases_and_members. But we don't
In Go, in a type switch like
switch t := 0; t := x.(type)
the two variables named 't' are in different blocks; they are not a
redefinition. This patch implements that in gccgo. Bootstrapped and
ran Go testsuite on x86_64-unknown-linux-gnu. Committed to mainline.
Ian
diff -r 725daf468f1
I thought there was a PR for this, but I can't find it.
A report about problems using the atomic_test_and_set pattern for SH
showed that we weren't being completely sane with the mode handling
of the boolean output. Further investigation showed that the docs
didn't match the implementation (or vi
This patch factors out some code, which was making debugging
unnecessarily confusing.
When we read the header of a tree, we first read an LTO tag marker to
identify what kind of tree we are reading. However, we were doing
this *outside* of pph_in_tree_header, which resulted in code
duplication i
If the target doesn't have an atomic_test_and_set pattern, we'd warn
about "mode" being unused.
Tested on mips64-linux-gnu and applied as obvious.
Richard
gcc/
* optabs.c (gen_atomic_test_and_set): Use each argument.
Index: gcc/optabs.c
=
...for -mpaired-single at least. Although the patch shows the intention
of making this specific to -mpaired-single, we don't distinguish between
integer and float capabilities, so the condition effectively triggers
for Loongson integer vectors too.
The patch is still correct for floats on Loongso
Ping 4...
> Ping 3? It's been months with no feedback...
>
> > Ping 2 ?
> >
> > http://gcc.gnu.org/ml/gcc-patches/2011-07/msg01889.html
> > http://gcc.gnu.org/ml/gcc-patches/2011-07/msg02555.html
http://gcc.gnu.org/ml/gcc-patches/2012-01/msg00529.html
All the MIPS3D patterns were testing the wrong condition:
TARGET_PAIRED_SINGLE_FLOAT rather than TARGET_MIPS3D. I think this
has been latent since the MIPS3D support was added, but it was shielded
by the definitions of the built-in functions, which require TARGET_MIPS3D.
We now use these patterns
This patch to the Go compiler corrects the type of expressions involving
untyped character constants. An expression like 'a' + 1 should take on
the type rune, not the type int. Bootstrapped and ran Go testsuite on
x86_64-unknown-linux-gnu. Committed to mainline.
Ian
diff -r cffcfa23a3b4 go/exp
Mike Stump writes:
> On Jan 23, 2012, at 11:13 AM, Richard Sandiford wrote:
>> One fix is attached. Another would be to read from a volatile variable
>> that has been initialised to 1. Other possibilities exist too of course.
>>
>> Tested on mipsisa64-elf. OK to install?
>
> Ok. I have a pref
On Mon, 16 Jan 2012, Richard Guenther wrote:
> + /* Do not merge an extern inline decl with any other decl either. */
> + if ((DECL_DECLARED_INLINE_P (newdecl)
> +&& DECL_EXTERNAL (newdecl))
> + || (!flag_gnu89_inline
> + && (DECL_DECLARED_INLINE_P (newdecl)
>
On 01/25/2012 04:43 AM, Torvald Riegel wrote:
> libitm: Fix wake-up of readers in futex-based serial lock.
>
> libitm/
> * config/linux/rwlock.cc (GTM::gtm_rwlock::write_unlock): Fix reader
> wake-up.
Ok.
r~
On 01/25/2012 12:03 AM, Rainer Orth wrote:
>> Er.. how did we get two copies?
>
> The link line boils down to
>
> ld -o eh-1.exe crt1.o crti.o crtbegin.o eh-1.o -litm -lstdc++ -lm -lgcc
> -lgcc_eh -lc -lgcc -lgcc_eh crtend.o crtn.o
>
> The eh-1.o reference to _Unwind_Resume drags in one copy of
Hi all,
first: I am still looking for someone to review my patch at
http://gcc.gnu.org/ml/fortran/2012-01/msg00197.html
* * *
In PR 44857, a patch was added which changed:
= dt_constructor ( character_parameter_array )
to
= dt_constructor ( (/ character(len=n) :: character_parameter_ar
On Jan 24, 2012, at 7:55 AM, Greta Yorsh wrote:
> The test gcc.dg/pr50908-2.c fails on arm and other targets where short enums
> is the default.
> * gcc.dg/pr50908-2.c (dg-options): Add -fno-short-enums.
Ok.
This patch makes gccgo verify the types of sink variables, so that we
issue an error as required for code like
var _ map[[]int]bool
Bootstrapped and ran Go testsuite on x86_64-unknown-linux-gnu.
Committed to mainline.
Ian
diff -r 411e398e3e68 go/gogo.cc
--- a/go/gogo.cc Tue Jan 24 09:20:5
While investigating atomic-test-and-set problems, I found
that sparc v7 wasn't matching the memory barrier as desired.
The problem turned out to be that the lack of a match_code
containing const_int meant that genpreds generated the wrong
mode test within the predicate. Which meant that no values
This patch fixes a lost wake-up bug in the futex-based serial lock
implementation. The previous code lacked some pieces of synchronization
(a seq_cst barrier and resetting a flag that is checked by the
respective futex_wait()), which led to those lost wake-ups when waking
and waiting were racing a
When I re-arranged the vconcat support for vec_perm, I forgot
that one must emit *something* in order to effect a split;
failure is equated with nothing being emitted.
Tested with qemu-arm, with more testing by the PR reporter.
Committed.
r~
PR target/51968
* config/arm/arm.c (ne
This patch to the Go frontend improves the handling of erroneous
function signatures, avoiding knock-on errors in various different ways.
It has no effect on correct programs. Bootstrapped and ran Go testsuite
on x86_64-unknown-linux-gnu. Committed to mainline.
Ian
Index: gcc/go/gofrontend/gogo
When we compare dependent names, we need to compare any explicit
template args as well.
Tested x86_64-pc-linux-gnu, applying to trunk.
commit 7446bd5c430bab0ea5b496b93d92d298bb023572
Author: Jason Merrill
Date: Tue Jan 24 10:42:22 2012 -0500
PR c++/51973
* tree.c (called_fns_equal)
On 24.01.2012 00:27, Benjamin Kosnik wrote:
This modularizes the libstdc++ sources such that the resulting library
binaries are now composed of three convenience libraries. In short:
this breaks builds configured with --enable-libstdcxx-debug. Tried the following
(not yet working) fix.
Ma
Hi,
Please find attached the patch fixing bug 49069.
This patch is tested with check-gcc on trunk and 4.6 without regression.
OK for trunk?
Is it fine to backport to 4.6 branch?
ChangeLog:
2012-01-24 Sameera Deshpande
PR target/49069
gcc/config/arm/arm.md (cstoredi4): Handle t
The test gcc.dg/pr50908-2.c fails on arm and other targets where short enums
is the default.
arm-none-eabi-gcc
/work/local-checkouts/main/gcc-fsf/gcc/testsuite/gcc.dg/pr50908-2.c
/work/local-checkouts/main/gcc-fsf/gcc/testsuite/gcc.dg/pr50908-2.c:39:8:
error: width of 'code' exceeds its type
The
This addresses a defect in handling movmisalign-handled stores
when they are wrapped in component-references (think of a
vector mode aggregate containing a single vector, wrapped with
a BIT_FIELD_REF to store a single vector element). I ran into
this issue while trying to fix PR50444 (and made SR
On Tue, Jan 24, 2012 at 6:20 AM, Alan Modra wrote:
> On Mon, Dec 05, 2011 at 07:25:35PM -0500, David Edelsohn wrote:
>> Is this fixed or is someone writing a follow-up patch?
>
> This does the trick. You could also use
> case ${host}:${with_multisubdir} in
> *:*32*)
>
On 01/24/2012 08:32 AM, Aldy Hernandez wrote:
On 01/23/12 18:34, Patrick Marlier wrote:
Hi,
In this PR51928, it tries to look_for_tm_attr_overrides on a thunk but
there is no DECL_NAME for thunk. So it fails in
lookup_fnfields_idx_nolazy because name is NULL.
#0 0x00764b5a in lookup_fn
This creates a get_pointer_alignment_1 function, similar to
get_object_alignment_1 for use by SRA (and for consistency).
SRA needs to be conservative with its alignment assertions when
building MEM_REFs. The following patch changes the single place
where we build them. Together with the posted
On Tue, Jan 24, 2012 at 12:31:46PM +0100, Matthias Klose wrote:
> Ok to remove these three empty directories?
>
> libgo/go/exp/template
> libstdc++-v3/testsuite/30_threads/condition_variable_any/requirements
> libgomp/config/linux/arm
The libgomp one only if you also remove linux/arm path from
li
On 01/24/12 01:34, Richard Henderson wrote:
On 01/24/2012 09:59 AM, Patrick Marlier wrote:
2012-01-23 Patrick Marlier
* trans-mem.c (requires_barrier): Do not instrument thread local
variables and emit save/restore for them.
testsuite/ChangeLog
2012-01-23 Patrick Marlier
On 01/23/12 18:34, Patrick Marlier wrote:
Hi,
In this PR51928, it tries to look_for_tm_attr_overrides on a thunk but
there is no DECL_NAME for thunk. So it fails in
lookup_fnfields_idx_nolazy because name is NULL.
#0 0x00764b5a in lookup_fnfields_idx_nolazy
(type=0x769f77e0, name=0x
Richard Henderson writes:
> On 01/17/2012 04:07 AM, Rainer Orth wrote:
>> * The 32-bit failures on Solaris 8 to 10 have a different root cause:
>> _Unwind_Find_FDE returns NULL for an address in _ZGTtL2f1v (f1()). It
>> turns out that there are two copies of the unwinder in eh-1.exe: one
>>
On Tue, 24 Jan 2012, Richard Guenther wrote:
> One issue that I am running into now is that we need to robustify/change
> expand_assignment quite a bit. I have a patch for SRA that makes sure
> to create properly aligned MEM_REFs but then we have, for example
>
> MEM[p].m = ...
>
> and in the
On 24 January 2012 11:31, Matthias Klose wrote:
> Ok to remove these three empty directories?
>
> libgo/go/exp/template
> libstdc++-v3/testsuite/30_threads/condition_variable_any/requirements
> libgomp/config/linux/arm
OK for the libstdc++ dir, I should have removed it in rev 180454
Thanks.
On Fri, 6 Jan 2012, Martin Jambor wrote:
> Hi,
>
> I'm trying to teach our expander how to deal with misaligned MEM_REFs
> on strict alignment targets. We currently generate code which leads
> to bus error signals due to misaligned accesses.
>
> I admit my motivation is not any target in partic
Alan Modra writes:
> On Mon, Dec 05, 2011 at 07:25:35PM -0500, David Edelsohn wrote:
>> Is this fixed or is someone writing a follow-up patch?
>
> This does the trick. You could also use
> case ${host}:${with_multisubdir} in
> *:*32*)
> ;;
> powerpc64-*:*
Ok to remove these three empty directories?
libgo/go/exp/template
libstdc++-v3/testsuite/30_threads/condition_variable_any/requirements
libgomp/config/linux/arm
On 01/24/2012 12:20 PM, Alan Modra wrote:
On Mon, Dec 05, 2011 at 07:25:35PM -0500, David Edelsohn wrote:
Is this fixed or is someone writing a follow-up patch?
This does the trick. You could also use
case ${host}:${with_multisubdir} in
*:*32*)
;;
On Mon, Dec 05, 2011 at 07:25:35PM -0500, David Edelsohn wrote:
> Is this fixed or is someone writing a follow-up patch?
This does the trick. You could also use
case ${host}:${with_multisubdir} in
*:*32*)
;;
powerpc64-*:* | *:*64*)
t
Thanks for raising the issue. To me the above looks like a
straightforward typo, which we should fix as soon as possible (not
sure whether we could also diagnose it).
Jason, Jakub, can you confirm?
While we can change it, it is certainly valid as is, #pragma GCC visibility
can happen in lots of
On Tue, Jan 24, 2012 at 11:28 AM, Jakub Jelinek wrote:
> Hi!
>
> I'd like to ping following patch:
>
> - http://gcc.gnu.org/ml/gcc-patches/2012-01/msg00819.html
> P2 option handling ICE with -Wp,-pie or -Wp,-shared
Ok.
Thanks,
Richard.
> Jakub
On Tue, Jan 24, 2012 at 11:45:55AM +0100, Paolo Carlini wrote:
> Hi,
> >While trying to improve clang's handling of "#pragma GCC visibility" I
> >found out that libstdc++-v3/libsupc++/typeinfo looks like
> >
> >#pragma GCC visibility push(default)
> >extern "C++" {
> >#pragma GCC visibility pop
> >
On Tue, Jan 24, 2012 at 7:34 AM, Andrew Pinski
wrote:
> Hi,
> Right now PHI-OPT does try to handle the case where we have multiple
> PHIs but the other PHIs have the same value for the edges we care
> about.
> This fixes the issue and allows PHI-OPT to handle a few more cases and
> it removes the
Hi,
While trying to improve clang's handling of "#pragma GCC visibility" I
found out that libstdc++-v3/libsupc++/typeinfo looks like
#pragma GCC visibility push(default)
extern "C++" {
#pragma GCC visibility pop
}
Is that supposed to work or just happens to? If desired, the attached
patch moves
On Mon, Jan 23, 2012 at 10:27 PM, Tom de Vries wrote:
> Richard,
> Jakub,
>
> the following patch fixes PR51879.
>
> Consider the following test-case:
> ...
> int bar (int);
> void baz (int);
>
> void
> foo (int y)
> {
> int a;
> if (y == 6)
> a = bar (7);
> else
> a = bar (7);
> baz (a)
On Tue, Jan 24, 2012 at 11:29:12AM +0100, Richard Guenther wrote:
> We're technically in regression-fixes-only mode. We give target/language
> maintainers some extra freedom though - while C++/libstdc++ are considered
> release critical and thus should not regress at this point I'm less sure
> abo
On Mon, Jan 23, 2012 at 8:36 PM, Tom Tromey wrote:
> This patch fixes some pretty-printer bugs pointed out in PR 51649.
>
> The bug in the PR is that the pretty-printers don't work if you build
> with --enable-symvers=gnu-versioned-namespace.
>
> This patch adds test cases for all the changes I ma
Hi!
I'd like to ping following patch:
- http://gcc.gnu.org/ml/gcc-patches/2012-01/msg00819.html
P2 option handling ICE with -Wp,-pie or -Wp,-shared
Jakub
On Mon, Jan 23, 2012 at 7:03 PM, Jason Merrill wrote:
> In this testcase, main doesn't call anything, so the inline functions in the
> classes can be optimized away, and we don't need the vtables or the virtual
> functions they refer to. But cgraph_decide_is_function_needed wants to
> write out a
On Mon, Jan 23, 2012 at 6:12 PM, Mike Stump wrote:
> On Jan 23, 2012, at 3:00 AM, Richard Guenther wrote:
>> So, yes, please have only one loop.
>
> Updated patch included.
>
> Ok?
Ok.
Thanks,
Richard.
On Mon, Jan 23, 2012 at 6:01 PM, Michael Matz wrote:
> Hi,
>
> On Sat, 21 Jan 2012, Eric Botcazou wrote:
>
>> > Trivially fixing the thinko (iterating over (work bit-and
>> > old_conflict) in the first inner loop) would fix the testcase but in
>> > general create too few conflicts, i.e. generate w
> How about if we just store a pointer to the template parameter list
> and do comp_template_parms?
I tried a variation of this approach below. My understanding is that
comp_template_parms wouldn't work as is, at least because it can lead to
an endless recursion:
Suppose we start comparing the f
On Tue, Jan 24, 2012 at 08:36:11AM +0100, Jakub Jelinek wrote:
> If you relax the checking too much, don't you risk that something other than
> the TOC register value is being added to the UNSPEC_TOCREL? Say, if you
> have an 8byte object in .toc, and some loop body uses
> ((char *) &object)[1 + i
76 matches
Mail list logo
