> How is it used in Ada?
The front-end doesn't use it directly, it's only used through the gimplifier
by the unsharing phase (unshare_body). We also have statement expressions.
--
Eric Botcazou
Hi Joseph,
I have seen no comments from the mn10300 maintainers.
I think
abbreviating const char * is actively bad. Cstar - defined for mn10300,
whose maintainers haven't commented
Whilst I am not a maintainer for the MN10300, I am the author of that
bit of code. I can say that I have no ob
On 05/02/11 23:24, Tobias Burnus wrote:
With this patch, now all coarray index intrinsics are implemented for
num_images() >= 1 - except for bugs.
Built and regtesting on x86-64-linux. The testcase was also tested with
-fcoarray=single and with -fcoarray=lib -lcaf_mpi with mpirun -n 8.
OK for th
On Mon, May 2, 2011 at 10:16 PM, Jakub Jelinek wrote:
> As written in the PR, the testcase in the patch is miscompiled on
> x86_64-linux, because during IRA a *btdi operand is changed from
> register to CONST_INT 1 (to which that register was initialized).
> Unfortunately when both 2nd and 3rd ZE
Jerry,
>> The failure vanishes with -ffloat-store, so I propose the following
>> patch, tested on i386-pc-solaris2.11 with the appropriate runtest
>> invocation.
>>
>> Ok for mainline?
>
> This is OK. We are working on a solution, so maybe it would be better to
> XFAIL it so that when it does get
On Mon, 2 May 2011, Joseph S. Myers wrote:
> On Mon, 2 May 2011, Richard Guenther wrote:
>
> > We do have similar testcases in gcc.dg/large-size-array*.c, but not
> > exactly testing the bound. The above testcase also complains with
> > -pedantic about
> >
> > t.c:3:13: error: size of array 'a'
On 04/15/2011 12:54 PM, Andrew Stubbs wrote:
> Ping.
Trying to unblock this...
I think the point is that both examples:
long long foolong (long long x, short *a, short *b)
{
return x + (long long)*a * (long long)*b;
}
and
long long foolong (long long x, short *a, short *b)
{
ping
The attached patch adds support for silicon revision 0.4 of the bf54x family.
2011-02-17 Mike Frysinger
* gcc.target/bfin/mcpu-bf542.c: Check SILICON_REVISION is 0x0004.
* gcc.target/bfin/mcpu-bf544.c, gcc.target/bfin/mcpu-bf547.c,
gcc.target/bfin/mcpu-bf548.c, gcc.target/bfin
On 03/05/11 10:07, Bernd Schmidt wrote:
I tried to fix it with the patch below, which unfortunately doesn't work
since during combine we don't see the SIGN_EXTEND operations inside the
MULT, but two shift operations instead. Maybe you can complete it from here?
I'll take a look.
Thanks for the
On Tue, 2011-04-26 at 11:10 +0200, Mark Wielaard wrote:
> This PR was put on hold for a while since gdb didn't immediately need
> it. But the consensus seemed that it was a good idea to always output
> the address ranges (.debug_arange section) information if a CU
> (.debug_info section) was emitte
On 05/03/2011 11:23 AM, Henderson, Stuart wrote:
> ping
>
>
> The attached patch adds support for silicon revision 0.4 of the bf54x family.
This is OK.
I'll also approve all the patches you posted that were originally from
either me or Jie and confined to config/bfin. Could you ping the ones
th
sounds good to me.
Thanks.
Stu
-Original Message-
From: Bernd Schmidt [mailto:ber...@codesourcery.com]
Sent: 03 May 2011 10:40
To: Henderson, Stuart
Cc: gcc-patches@gcc.gnu.org
Subject: Re: bf54x support
On 05/03/2011 11:23 AM, Henderson, Stuart wrote:
> ping
>
>
> The attached patch ad
On Tue, May 3, 2011 at 1:07 AM, Xinliang David Li wrote:
> On Mon, May 2, 2011 at 2:33 PM, Richard Guenther
> wrote:
>> On Mon, May 2, 2011 at 6:41 PM, Xinliang David Li wrote:
>>> On Mon, May 2, 2011 at 2:11 AM, Richard Guenther
>>> wrote:
On Fri, Apr 29, 2011 at 6:23 PM, Xinliang David L
On Tue, May 3, 2011 at 12:00 PM, Richard Guenther
wrote:
3) it limits the lowering into one form which may not be ideal --
with builtin_dispatch, after hoisting optimization, the lowering can
use more efficient IFUNC scheme, for instance.
>>>
>>> I see no reason why we cannot trans
On Tue, May 3, 2011 at 5:37 AM, Jeff Law wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> On 04/26/11 16:06, Easwaran Raman wrote:
>
>>
>>> You're right. The patch has correctness issues. It is not possible to
>>> simply not call add_wild_read because it also resets
>>> active_local_st
Rainer,
Rainer Orth wrote:
> Jerry DeLisle wrote:
> > This is OK. We are working on a solution, so maybe it would be better to
> > XFAIL it so that when it does get fixed it will be flagged. It also fails
> > on i686-pc-gnu.
>
> is this a solution for this particular case or for the general need
We are streaming DECL_OFFSET_ALIGN using 8 bits. That is bogus, as
DECL_OFFSET_ALIGN is 1 << decl_common.off_align which in turn is
a 8 bit bitfield. The solution is to stream decl_common.off_align
instead.
Bootstrapped and tested on x86_64-unknown-linux-gnu, applied to trunk
and the 4.6 branch
Hi,
While reading through the dwarf2out debug_str support I got confused by
some of the code dealing with debug_str_hash_forced. But after PR41404
was fixed nothing actually uses this anymore. So this patch just removes
the dead code and simplifies a check.
2011-05-03 Mark Wielaard
* dwar
> Is this one ok?
Hi,
we did quite some work on removing a langhooks for LTO, where they become quite
impossible
So I would like to know what testcase causes the problem and why.
Honza
>
> David
>
> On Fri, Apr 29, 2011 at 4:38 PM, Xinliang David Li wrote:
> > During function cloning, the lang
On 05/03/2011 03:14 AM, Tobias Burnus wrote:
Rainer,
Rainer Orth wrote:
Jerry DeLisle wrote:
This is OK. We are working on a solution, so maybe it would be better to
XFAIL it so that when it does get fixed it will be flagged. It also fails
on i686-pc-gnu.
is this a solution for this particu
On 03/31/2011 03:17 PM, Jeff Law wrote:
> On 03/23/11 08:47, Bernd Schmidt wrote:
>> We'll start putting "return" into JUMP_LABELS in a subsequent patch, so
>> I've decided to make it unique as a small cleanup.
>
>> There's already another macro called "return_rtx", so the new one goes
>> by the n
Hi Richard,
Thanks for the patch review. Sorry for not responding earlier, but
some other work got in the way.
I have attached a revised patch which addresses all of the points you
raised except one:
+ else if (loop->header != loop->latch
+ reason = "it is not a simp
On Tue, May 03, 2011 at 10:26:50AM +0200, Uros Bizjak wrote:
> On Mon, May 2, 2011 at 10:16 PM, Jakub Jelinek wrote:
> IMO, this problem arises due to wrong fix for PR target/37184 [1] that
> added CCA, CCC, CCO, CCS mode bypasses to ix86_match_ccmode.
Yeah, ix86_match_ccmode was the first place
On Tue, May 3, 2011 at 2:39 PM, Jakub Jelinek wrote:
> On Tue, May 03, 2011 at 10:26:50AM +0200, Uros Bizjak wrote:
>> On Mon, May 2, 2011 at 10:16 PM, Jakub Jelinek wrote:
>> IMO, this problem arises due to wrong fix for PR target/37184 [1] that
>> added CCA, CCC, CCO, CCS mode bypasses to ix86_
Hi,
This patch fixes vset_lane intrinsic variants for D-register sized
variables. A typo meant that the wrong lane would be set in many
circumstances.
Tested manually only. OK to apply?
Thanks,
Julian
ChangeLog
gcc/
* config/arm/neon.md (vec_set_internal): Fix misplaced
parenthesi
On Mon, 2011-05-02 at 09:21 +1200, Michael Hope wrote:
> Linux 2.6.35 and later on ARM randomise the address space, breaking
> precompiled header support in GCC. The fix is to use the support in
> GCC for mmap()ing into a fixed, likely to be free address. The ARM
> memory map is modeled on the i
On 04/14/2011 03:00 PM, Richard Guenther wrote:
> On Thu, Apr 14, 2011 at 2:40 PM, Bernd Schmidt
> wrote:
>> Ping. Contains only changes outside config/arm.
>>
>> http://gcc.gnu.org/m/gcc-patches/2011-03/msg01509.html
>
> Ok.
Committed this version on trunk (which has different code to initial
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 05/02/11 15:18, Richard Guenther wrote:
>
>> For (edge *)xmalloc (sizeof (edge) * 1) use XNEWVEC and friends.
>> I wonder if it makes sense to use a VEC instead (will the vector
>> be of variable size?). Maybe wrap accesses to e->aux with
>> a ma
Chung-Lin Tang writes:
> My fix here simply adds 'reload_completed' as an additional condition
> for EPILOGUE_USES to return true for LR_REGNUM. I think this should be
> valid, as correct LR save/restoring is handled by the epilogue/prologue
> code; it should be safe for IRA to treat it as a norma
Ping
---
The attached patch adds support for (and changes defaults to) the latest
silicon revisions for Blackfin parts.
2011-05-03 Stuart Henderson
* config/bfin/bfin.c (bfin_cpus): Update silicon revisions.
Thanks,
Stu
Index: gcc/config/bfin/bfin.c
=
Ping
---
The attached testsuite patch updates the blackfin part macro tests to expect
the latest silicon revision, as well as fixing up some duplication in the bf51x
parts.
2011-05-03 Stuart Henderson
* gcc.target/bfin/mcpu-bf542.c: Update to latest silicon revision.
* gcc.target/bf
Ping
---
The attached patch updates the blackfin ___divsi3 and ___udivsi3
implementations (and updates ___umodsi3 to match), as well as adding .size
directives to all functions in the file.
2011-03-24 Stuart Henderson
* gcc/config/bfin/lib1funcs.asm (___divsi3): New implementation,
On Sat, Apr 16, 2011 at 1:11 AM, Jakub Jelinek wrote:
> On Fri, Mar 25, 2011 at 12:32:37PM +0100, Jakub Jelinek wrote:
>> As I said in my GCC Summit talk, currently we just give up on
>> any floating point/_Decimal*/__int128 and for 32-bit targets even
>> long long expressions, as those can't be r
On 05/03/2011 03:26 PM, Henderson, Stuart wrote:
> Ping
> ---
>
> The attached testsuite patch updates the blackfin part macro tests to expect
> the latest silicon revision, as well as fixing up some duplication in the
> bf51x parts.
>
> 2011-05-03 Stuart Henderson
>
> * gcc.target/bfin
On 05/03/2011 03:25 PM, Henderson, Stuart wrote:
> Ping
> ---
>
> The attached patch adds support for (and changes defaults to) the latest
> silicon revisions for Blackfin parts.
>
> 2011-05-03 Stuart Henderson
>
> * config/bfin/bfin.c (bfin_cpus): Update silicon revisions.
Ok.
On 03/05/11 13:49, Julian Brown wrote:
Hi,
This patch fixes vset_lane intrinsic variants for D-register sized
variables. A typo meant that the wrong lane would be set in many
circumstances.
Tested manually only. OK to apply?
Ok - yes this looks almost obvious but please do a sanity regression
There are two callers left that call int_const_binop with a 1 notrunc
argument causing non-canonicalized INTEGER_CSTs to be built. One
is group_case_labels_stmt in tree-cfg.c which can simply use
double_ints (which is what all code using 1 notrunc should do,
similar to old code building INTEGER_C
Hi,
the below is what I ended up committing for this PR, very close to the
preliminary draft I recently attached to Bugzilla. All in all, in my
opinion the situation wrt the destructors was broken enough that we want
the patch in the release branch too, if we want to encourage people to
exper
Hi,
On Tue, 3 May 2011, Richard Guenther wrote:
> --- 5858,5890
>
> /* If these are the same operation types, we can associate them
>assuming no overflow. */
> ! if (tcode == code)
> ! {
> ! double_int mul;
> ! int overflow_p;
> ! mul = double_
This is the promised followup to the expand_shift reorg. The following
patch makes the worker take an RTL expanded shift amount and avoids
re-creating adjusted trees if it recurses for expanding rotates. Most
of the scary code (involving the conversions) originated from the
fix for PR27861 - but
On Tue, 3 May 2011, Michael Matz wrote:
> Hi,
>
> On Tue, 3 May 2011, Richard Guenther wrote:
>
> > --- 5858,5890
> >
> > /* If these are the same operation types, we can associate them
> > assuming no overflow. */
> > ! if (tcode == code)
> > ! {
> > ! double_i
On Tue, 2011-05-03 at 13:49 +0100, Julian Brown wrote:
> Hi,
>
> This patch fixes vset_lane intrinsic variants for D-register sized
> variables. A typo meant that the wrong lane would be set in many
> circumstances.
>
> Tested manually only. OK to apply?
>
> Thanks,
>
> Julian
>
> ChangeLog
>
I have no objections to this going into 4.5 and 4.6 since it corrects
the implementation of the neon intrinsics but please check with the
release managers.
OK to backport to 4.5 and 4.6 - both tested on arm-linux-gnueabi?
Ok. Please allow 24 hours for an RM (cc'd) to comment since this is
On Tue, 3 May 2011, Ramana Radhakrishnan wrote:
>
> > > I have no objections to this going into 4.5 and 4.6 since it corrects
> > > the implementation of the neon intrinsics but please check with the
> > > release managers.
> >
> > OK to backport to 4.5 and 4.6 - both tested on arm-linux-gnueabi
On Fri, 2011-04-29 at 11:18 +0800, Carrot Wei wrote:
> Yes, after porting it to google/main.
>
> Carrot
>
> On Thu, Apr 28, 2011 at 10:26 PM, Diego Novillo wrote:
> > Will you be proposing this patch for trunk as well?
> >
> >
> > Diego.
> >
At the very least a trunk version of this patch will
This patch implements the simpler parts of stopping mips_handle_option
from using global state. Three options are made to use the Enum
machinery instead of custom option handler code, while a fourth is
adjusted to set a field through the opts pointer. The remaining (and
rather more complicated) p
> "Joseph" == Joseph S Myers writes:
Joseph> arm*-elf are targets where libffi's configure thinks it is supported.
Thanks.
Joseph> So Java (and Go) should be disabled by default when libffi isn't
Joseph> supported, because they'd try by default to build libffi and so
Joseph> a default build
On Tue, 3 May 2011, Richard Earnshaw wrote:
> > gcc/
> > * config/arm/neon.md (vec_set_internal): Fix misplaced
> > parenthesis in D-register case.
>
> Presumably this is a silent 'wrong-code' bug. If so, what about
> released compilers?
And what about an execution testcase that fai
On May 3, 2011, at 3:07 AM, Richard Guenther wrote:
>>
>> There is no possibility for a high-level dispatch at the source level.
>> And if I'd have to design one I would use function overloading, like
>>
>> float compute_sth (float) __attribute__((version("sse4")))
>> {
>> ... sse4 code ...
>>
On 05/03/2011 03:00 AM, Eric Botcazou wrote:
How is it used in Ada?
The front-end doesn't use it directly, it's only used through the gimplifier
by the unsharing phase (unshare_body). We also have statement expressions.
In that case you wouldn't be affected by this patch; unshare_body uses
On May 3, 2011, at 3:14 AM, Tobias Burnus
wrote:
> PS: Especially as you are listed as testsuite maintainer, I would be
> happy if you could comment on the testsuite patch at
> http://gcc.gnu.org/ml/fortran/2011-04/msg00331.html
Ok.
Hi,
I always considered the cgrpah_node_set/varpool_node_set to be overengineered
but they also turned out to be quite ineffective since we do quite a lot of
queries into them during stremaing out.
This patch moves them to pointer_map, like I did for streamer cache. While
doing so I needed to get
On Tue, 3 May 2011, Mike Stump wrote:
> And to go one step further, if we had this, we could use this to define
> all data manipulation machine built-ins as generic functions, available
> to all compiles as normal c code, so portable code could use them
> everywhere, and on platforms that had i
> In that case you wouldn't be affected by this patch; unshare_body uses
> mostly_copy_tree_r, which has its own special case for STATEMENT_LIST.
Right, I added it precisely to support statement expressions in Ada (instead
of changing copy_tree_r) since we never want to copy them in the unsharing
On Tue, 3 May 2011, Jan Hubicka wrote:
> Hi,
> I always considered the cgrpah_node_set/varpool_node_set to be overengineered
> but they also turned out to be quite ineffective since we do quite a lot of
> queries into them during stremaing out.
>
> This patch moves them to pointer_map, like I did
On Tue, May 3, 2011 at 3:55 AM, Jan Hubicka wrote:
>> Is this one ok?
> Hi,
> we did quite some work on removing a langhooks for LTO, where they become
> quite impossible
> So I would like to know what testcase causes the problem and why.
In fold-const.c, there are many of calls to
lang_hooks.de
> Ping. http://gcc.gnu.org/ml/gcc-patches/2011-04/msg01675.html
Sorry for the delay. Moreover, I installed a patch in the meantime that badly
conflicts with yours, so I've adjusted it. There was an oversight related to
the number of integer_type_node in the first case of build_raise_check, bu
On Mon, May 2, 2011 at 8:37 PM, Jeff Law wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> On 04/26/11 16:06, Easwaran Raman wrote:
>
>>
>>> You're right. The patch has correctness issues. It is not possible to
>>> simply not call add_wild_read because it also resets
>>> active_local_st
> In fold-const.c, there are many of calls to
> lang_hooks.decls.global_bindings_p, and the implementation of this in
> name-lookup.h will look at the the cfun->language
>
>
> #define cp_function_chain (cfun->language)
>
> #define current_binding_level \
> (*(cfun && cp_functio
On May 3, 2011, at 8:34 AM, "Joseph S. Myers" wrote:.
> I don't think the forms in which some of the machine-specific built-in
> functions exist are particularly good for being available everywhere
I take it you've never just wanted something to compile, and hit one of these
yet. Let me know i
>
> We have both a vector and a pointer-map. Why not simply use a
> pointer-map only?! I see this may need more re-structuring, eventually
Well, pointer-maps would be randomly ordered (sensitive to pointer values)
and thus we would give different .o files depending on memory layout.
But yes, co
Hello!
2011-05-03 Uros Bizjak
* expmed.c (extract_bit_field_1): Remove write-only variable "icode".
Bootstrapped and regression tested on x86_64-pc-linux-gnu AVX target.
Committed to mainline SVN.
Uros.
Index: expmed.c
=
Hi!
I've backported 5 patches from the trunk to 4.5 branch after
bootstrapping/regtesting them on x86_64-linux and i686-linux.
Jakub
2011-05-03 Uros Bizjak
Jakub Jelinek
PR target/48774
* config/i386/i386.c (ix86_match_ccmode): For CC{A,C,O,S}mode
On 05/03/2011 11:52 AM, Eric Botcazou wrote:
In that case you wouldn't be affected by this patch; unshare_body uses
mostly_copy_tree_r, which has its own special case for STATEMENT_LIST.
Right, I added it precisely to support statement expressions in Ada (instead
of changing copy_tree_r) since
OK.
Jason
"Joseph S. Myers" writes:
> * config/mips/mips-opts.h: New.
> * config/mips/mips.c (enum mips_r10k_cache_barrier_setting): Move
> to mips-opts.h.
> (mips_abi, mips_code_readable, mips_r10k_cache_barriee): Remove.
> (mips_handle_option): Don't handle OPT_mabi_, OPT_mco
Tom,
>>> That also sounds reasonable. Is nm -S more portable than size?
>>
>> Neither Solaris nor IRIX nm have it. size isn't particularly portable,
>> either: there are many variations in output format.
[...]
> In case we ever need it, here's a patch to access nm -S.
sorry for the very late r
On 05/03/2011 01:28 PM, Jason Merrill wrote:
stor-layout.c (copy_self_referential_tree_r): Affected by the change.
Would you like me to add a gcc_unreachable() here?
tree-inline.c (copy_tree_body_r): already copies STATEMENT_LIST itself
(with a copy_statement_list function which I should use ins
Hi,
tested x86_64-linux, approved by Jason on the audit trail, committed to
mainline.
Thanks!
Paolo.
///
/cp
2011-05-03 Paolo Carlini
PR c++/28501
* call.c (add_builtin_candidate): Handle REALPART_EXPR and
IMAGPART_EXPR.
/testsuite
2011-05-03
On 04/28/2011 03:50 PM, Diego Novillo wrote:
This patch from Silvius Rus adds a new flag (-fstrict-enum-precision).
While porting the patch to 4.6, I noticed that the C++ FE now has a
similar flag that seems to have similar semantics (-fstrict-enums).
Silvius's patch is used to disable some swit
> I am however completely missing the point of this langhook and doc is not
> exactly informative either:
>
> /* Returns nonzero if we are in the global binding level. Ada
> returns -1 for an undocumented reason used in stor-layout.c. */
>
> What is the purpose of this hook?
I've seen thi
Richard Henderson writes:
> On 04/27/2011 11:13 AM, Anatoly Sokolov wrote:
>> * config/sparc/sparc.h (PRINT_OPERAND, PRINT_OPERAND_ADDRESS,
>> PRINT_OPERAND_PUNCT_VALID_P): Remove.
>> * config/sparc/sparc-protos.h (print_operand): Remove declaration.
>> * config/sp
On Tue, 3 May 2011, Eric Botcazou wrote:
> > I am however completely missing the point of this langhook and doc is not
> > exactly informative either:
> >
> > /* Returns nonzero if we are in the global binding level. Ada
> > returns -1 for an undocumented reason used in stor-layout.c. */
The patch below eliminates almost all cases of build_function_type in
the Fortran FE. (The last case uses TYPE_ARG_TYPES directly and will
need to be dealt with separately.) This is accomplished by introducing
two new functions, build_{,varargs_}function_type_array, which do what
you think, and t
On Tue, May 03, 2011 at 07:06:58PM +, Joseph S. Myers wrote:
> In my view we should require front ends to take responsibility for
> variable-size types, and get rid of this language-independent function
> (copying such parts as are needed into the front ends that need them). C
> for example
On Tue, 3 May 2011, Rainer Orth wrote:
> This patch broke Solaris 2/SPARC bootstrap which still uses
> print_operand in sparc/sol2.h (ASM_OUTPUT_CALL). A bootstrap with the
> obvious fix is currently running.
>
> What is so hard about running grep when removing/renaming symbols???
Generically,
On 05/03/2011 05:13 AM, Nick Clifton wrote:
> The problem I found here was that I did not know how to find all of
> the test-and-loop-back insns if the loop spanned multiple blocks.
> The revised patch includes a comment saying that loops spanning
> multiple blocks could be supported, but I would l
On Tue, 3 May 2011, Nathan Froyd wrote:
> On Tue, May 03, 2011 at 07:06:58PM +, Joseph S. Myers wrote:
> > In my view we should require front ends to take responsibility for
> > variable-size types, and get rid of this language-independent function
> > (copying such parts as are needed into
> In my view we should require front ends to take responsibility for
> variable-size types, and get rid of this language-independent function
> (copying such parts as are needed into the front ends that need them).
I don't really see the point here. GCC supports variable-sized types in the
middl
On Tue, May 03, 2011 at 07:27:24PM +, Joseph S. Myers wrote:
> On Tue, 3 May 2011, Nathan Froyd wrote:
> > The raft of changes/improvements enabled by this change would be most
> > welcome. *_SIZE becoming double_ints or HOST_WIDE_INT instead of trees
> > is the first thing that comes to mind;
On Tue, 3 May 2011, Eric Botcazou wrote:
> > In my view we should require front ends to take responsibility for
> > variable-size types, and get rid of this language-independent function
> > (copying such parts as are needed into the front ends that need them).
>
> I don't really see the point he
Hello,
This is another fallout of the fix for PR c++/47172, where we started
to make finish_call_expr make member function call expressions that
have a dependent "this" pointer be recognized by
type_dependent_expression_p as being type dependent.
The problem is that a node being a BASELINK is not
Am 01.05.2011 11:49, schrieb Thomas Koenig:
Hello world,
after Paul's fix for allocate on assignment (thanks Paul!), here is a
patch for the original test case from PR 22572, where the bounds of
the function are unknown at compile time. This uses an allocatable
temporary.
Ping?
Thomas
On 04/29/2011 10:59 AM, Diego Novillo wrote:
This patch from Le-Chun Wu adds a new warning flag "-Wreal-conversion"
that warns about implicit type conversions from real (double or float)
values to integral values.
Why do you want to use this flag rather than just use -Wconversion?
Jason
On 04/26/2011 06:57 PM, Cary Coutant wrote:
I considered just changing -g1 to do this, with the argument that
"enough for making backtraces" ought to include line numbers and
inlined function calls, but I wasn't familiar enough with existing
uses of -g1 to go with that alternative. I'm certainly
I think using get_first_fn could make non_static_member_function_p a lot
shorter.
Jason
> C returns -1 from global_bindings_p, as does Ada. That the languages that
> probably care most about variable-size types find aspects of the generic
> function need overriding like that should be a good indication that it
> isn't really that generic - as I said above, semantics for variable size
FWIW, this was posted to http://gcc.gnu.org/ml/gcc-patches/2011-03/msg00949.html
--- Begin Message ---
Hello,
This PR is an enhancement request to emit a DW_TAG_ptr_to_member_type
DIE for pointer-to-member-function types.
The patch below does add a new language hook to support this and
adapts th
OK.
Jason
Instead of this, let's use a more general hook, something like
"type_for_debug" that returns an OFFSET_TYPE for pointers to member
functions.
Jason
sed -i "s/[ $(printf '\t')]\{1,\}\$//" trunk/gcc/doc/extend.texi
I believe we usually don't do whitespace changes just for the sake
of cleaning up things.
Unless someone else indicates otherwise, I believe this patch is
rejected.
Gerald
On Tue, 3 May 2011, Eric Botcazou wrote:
> > C returns -1 from global_bindings_p, as does Ada. That the languages that
> > probably care most about variable-size types find aspects of the generic
> > function need overriding like that should be a good indication that it
> > isn't really that gene
When I added VSX support to the powerpc, I overlooked passing and return
V2DImode arguments, since the only machine operation that supports V2DI is
vector floating point conversion. Consequentally, V2DI types were passed and
returned in GPRs instead of the vector registers on power7.
This patch f
After I submitted
http://gcc.gnu.org/ml/gcc-patches/2011-04/msg02422.html, Rong Xu noted
that the resulting sources, if configured --with-pic, would not
actually build properly due to missing __i686.get_pc_thunk.bx (due to
my renaming that to __x86...).
While that issue was exposed by my change, i
On Tue, May 3, 2011 at 3:00 AM, Richard Guenther
wrote:
> On Tue, May 3, 2011 at 1:07 AM, Xinliang David Li wrote:
>> On Mon, May 2, 2011 at 2:33 PM, Richard Guenther
>> wrote:
>>> On Mon, May 2, 2011 at 6:41 PM, Xinliang David Li
>>> wrote:
On Mon, May 2, 2011 at 2:11 AM, Richard Guenthe
Chris Demetriou writes:
> 2011-05-03 Chris Demetriou
>
> * libgcc/config/i386/morestack.S (__i686.get_pc_thunk.bx): New.
No "libgcc" in libgcc/ChangeLog.
This is OK.
It is also OK if you s/__i686/__x86/ to correspond to your earlier
change. Either way is OK.
Thanks.
Ian
On 05/02/2011 09:53 PM, Diego Novillo wrote:
Since google/gcc-4_6 follows the 4.6 branch, changes in minor
revisions cause unnecessary churn in directory names.
Fixed with this. OK for google/gcc-4_6?
Google ref 4335466.
* BASE-VER: Change to 4.6.x-google.
diff --git a/gcc/BA
Hi,
tested x86_64-linux, committed to mainline.
As regards the move assignment operator, the only non-trivial bit of the
patch, per today's discussion on the reflector, essentially we want to
be consistent with the resolution of LWG 675, thus make sure first that
the move-assigned-to object r
On Tue, May 3, 2011 at 15:05, Ian Lance Taylor wrote:
>
> > 2011-05-03 Chris Demetriou
> >
> > * libgcc/config/i386/morestack.S (__i686.get_pc_thunk.bx): New.
>
> No "libgcc" in libgcc/ChangeLog.
Fixed, sorry. (That's what I get for pasting from svn status output. 8-)
> It is also O
Backport patches r17342, r173177, and r173147 from trunk to google/main + some
minor cleanups for problems found in test.
Tested: bootstrap + regression test + SPEC06 LIPO testing.
Backport r173177
2011-05-03 David Li
* tree-profile.c (init_ic_make_global_vars): Set
tls attri
1 - 100 of 109 matches
Mail list logo
