On Fri, Oct 7, 2011 at 6:34 PM, Michael Matz wrote:
> Hi,
>
> tree-emutls.c missed to called add_referenced_var for a variable that is
> referenced. That always was a bug, but meanwhile is fatal (causing a
> segfault). This fixes the problem. Okay for trunk if regstrapping
> succeeds?
Ok (qual
> Thanks! What's about the .texi change for -fwhole-file?
Will do. Should I include a note about deprecation? And if yes, do you
have a suggestion for the wording?
Cheers,
Janus
On 10/08/2011 12:56 AM, Paolo Carlini wrote:
The fix seems easy: output a cloned destructor only once (+ output any
other member functions normally).
+ static bool done_cloned_dest = false;
This seems like it will only complain once per translation unit about
virtual destructors. H
> I'm hoping the graphite people have an even a better idea... If not, Ok.
I have filed pr50023 two month ago CCing Sebastian Pop asking the question:
"Why not on powerpc?" and I have the patch (comment#2) since over a month.
I think that if "the graphite people have an even a better idea", they
Hi,
> This seems like it will only complain once per translation unit about virtual
> destructors.
Oops, sorry, but this specific issue could be solved rather easily by not using
a static, right?
> How about instead of this flag, we look at which variant it is and only
> complain about one o
This patch records the compiler command-line flags to a .note section,
which could be used by FDO/LIPO.
Bootstrapped on x86_64, no regressions.
Is it ok for google/gcc-4_6 and google/main branches?
Thanks,
Dehao
gcc/ChangeLog.google-4_6:
2011-10-08 Dehao Chen
Add a flag (-frecord-op
> Yes, isn't simply not using a static a rather straightforward alternative?
Ok, now I see: since it's easy, better avoid using *any* sort of flag, I'll do
it.
Paolo
On Sat, Oct 08, 2011 at 06:43:47PM +0800, Dehao Chen wrote:
> This patch records the compiler command-line flags to a .note section,
> which could be used by FDO/LIPO.
>
> Bootstrapped on x86_64, no regressions.
>
> Is it ok for google/gcc-4_6 and google/main branches?
Why yet another record swi
Ok, fixed it, I made a very dumb mistake in configure.host, new patch
attached.
Changelog:
2011-10-08 Jonathan Yong
* configure.host: Use config/os/mingw32-w64 instead of
config/os/mingw32 if vendor key is "w64".
* config/os/mingw32-w64: Duplicate from config/os/mingw32
Greetings,
Here are the revised changes for the tree portions of the patch. I've
attempted to resolve all comments to date on those portions. Per
Steven's comment, I moved copy_ref_info into tree-ssa-address.c; let me
know if there's a better place, or whether you'd prefer to leave it
where it w
Hi!
The AVX2 docs say that the insns will #UD if any of the mask, src and index
registers are the same, but e.g. on
#include
__m256 m;
float f[1024];
__m256
foo (void)
{
__m256i mi = (__m256i) m;
return _mm256_mask_i32gather_ps (m, f, mi, m, 4);
}
which is IMHO valid and should for m being
Hi,
> Ok, fixed it, I made a very dumb mistake in configure.host, new patch
> attached.
Patch is still ok with me, if Kai is ok with it (remember for next time:
regenerated files are not posted, are just a distraction)
Paolo
>
2011/10/8 Paolo Carlini :
> Hi,
>
>> Ok, fixed it, I made a very dumb mistake in configure.host, new patch
>> attached.
>
> Patch is still ok with me, if Kai is ok with it (remember for next time:
> regenerated files are not posted, are just a distraction)
>
> Paolo
Ok, by me, too.
Thanks,
Kai
On Fri, 7 Oct 2011, Ian Lance Taylor wrote:
> The uses in DJGPP and Mingw support all match. config/gnu.h is only
> used on i[34567]86-*-gnu* while config/t-gnu is used on *-*-gnu*; this
> mismatch appears to be an error. The use of STANDARD_INCLUDE_DIR in
There are no other *-*-gnu* targets (t
This patch implements the change discussed in libobjc/50428. Traditionally,
the Apple runtime "inherits" +initialize,
meaning that if a class doesn't implement it, but the superclass does, the
superclass's implementation gets executed
the first time a method of the class is invoked. Instead, th
Hi again,
today I had a look to clone_function_decl & co, and came up with the
below. I understand DECL_DELETING_DESTRUCTOR_P would work as well...
Tested x86_64-linux.
Thanks,
Paolo.
///
2011-10-08 Paolo Carlini
PR c++/34927
* typeck2.c (abstract_virtuals
On Wed, 28 Sep 2011, Andi Kleen wrote:
> ld -r is now supported with LTO. When using assembler files or non
> LTOed objects inside ld -r objects together with LTO then the Linux
> binutils 2.21.51.0.3 or later are needed.
I think this should be GNU/Linux, if anything, but then I also think
we sh
On Sat, Oct 08, 2011 at 05:38:07PM -0400, Gerald Pfeifer wrote:
> On Wed, 28 Sep 2011, Andi Kleen wrote:
> > ld -r is now supported with LTO. When using assembler files or non
> > LTOed objects inside ld -r objects together with LTO then the Linux
> > binutils 2.21.51.0.3 or later are needed.
>
Hello all,
I received my GSOC t-shirt yesterday which reminded me I have a promise to
keep... After realising that it can take forever to find enough free time
to work on GCC, I decided to work a couple of hours whenever I can and
post updates to my patches as time permits. Hopefully some of t
On Fri, Oct 7, 2011 at 3:49 PM, Richard Henderson wrote:
> Our existing vector permutation support uses the name vec_perm.
> The new support added for __builtin_shuffle used a variety of
> names. This brings all the internals into line with vec_perm.
>
> I've added documentation for the (existing
On Sat, Oct 8, 2011 at 3:56 PM, H.J. Lu wrote:
> On Fri, Oct 7, 2011 at 3:49 PM, Richard Henderson wrote:
>> Our existing vector permutation support uses the name vec_perm.
>> The new support added for __builtin_shuffle used a variety of
>> names. This brings all the internals into line with vec
OK.
Jason
On 10/08/2011 07:25 PM, Ed Smith-Rowland wrote:
Also, In spite of the documentation cp_parser_template_parameter_list
returns a TREE_VEC not a TREE_LIST. This happens inside
end_template_parm_list called inside the former. So parameter_list is a
TREE_VEC, parm_list is a TREE_LIST, parm is a PARM_
On 10/07/2011 12:14 PM, Jakub Jelinek wrote:
Here is a modified patch then, bootstrapped/regtested on x86_64-linux
and i686-linux, ok for trunk? Would just the reregister_specialization
change be ok for 4.6 too?
Yes and yes.
Jason
Unfortunately -frecord-gcc-switches cannot serve our purpose because
the recorded switches are mergable, i.e. the linker will merge all
options to a set of strings. However, object files may have distinct
compile options. We want to preserve every object file's compile
options when doing LIPO build
25 matches
Mail list logo
