[Please keep me CCed, I'm not subscribed to gcc-patches. Thank you]
Hi,
the definition of psignal in libiberty is
void psignal (int, char *);
The correct definition per POSIX is
void psignal (int, const char *);
The below patch fixes that.
Thanks,
Corinna
* strsignal.c (psi
Hi,
this entirely removes the support for pending sizes from the compiler. The
prerequisite is Joseph's patch from yesterday.
Bootstrapped/regtested on x86_64-suse-linux, OK for the mainline?
2011-05-05 Eric Botcazou
* tree.h (get_pending_sizes): Remove prototype.
(put_pen
On Thu, May 5, 2011 at 12:30 AM, Corinna Vinschen wrote:
> Thanks,
> Corinna
>
>
> * strsignal.c (psignal): Change second parameter to const char *.
> Fix comment accordingly.
I don't think this is needed. What goes wrong without it?
Thanks,
Andrew Pinski
On May 5 00:40, Andrew Pinski wrote:
> On Thu, May 5, 2011 at 12:30 AM, Corinna Vinschen wrote:
> > Thanks,
> > Corinna
> >
> >
> > * strsignal.c (psignal): Change second parameter to const char *.
> > Fix comment accordingly.
>
>
> I don't think this is needed. What goes wrong w
On Wed, May 4, 2011 at 7:14 PM, Eric Botcazou wrote:
>> Actually it turns out that it doesn't matter. If we arrive here with
>> something that needs a SAVE_EXPR we have to be able to generate code
>> for it somewhere, where there would be obviously the possibility to
>> also generate code for a S
On Wed, May 4, 2011 at 10:26 PM, Diego Novillo wrote:
>
> This patch adds a new streamer hook to populate the streamer cache
> with common nodes.
>
> The nodes we populate for GIMPLE in lto_get_common_nodes is not
> sufficient for C++, unsurprisingly.
>
> The patch fixes these regressions in pph.e
Corinna Vinschen wrote:
> On May 4 05:52, Yaakov (Cygwin/X) wrote:
> > 2011-05-04 Yaakov Selkowitz
> >
> > * libc/include/signal.h (psignal): Declare.
> > * libc/sys/linux/psignal.c: Move from here...
> > * libc/signal/psignal.c: ... to here. Document.
> > * libc/sys/linux/Make
Hi Anatoly,
>
> I thought so, too, but you also need to include target.h in
> config/sol2.c. I'm currently testing such a patch; will commit tomorrow
> if bootstrap passes.
this is the patch I've checked in after it passed sparc-sun-solaris2.11
andi i386-pc-solaris2.11 bootstrap.
Rainer
On May 5 11:09, Ulrich Weigand wrote:
> Corinna Vinschen wrote:
> > On May 4 05:52, Yaakov (Cygwin/X) wrote:
> > > 2011-05-04 Yaakov Selkowitz
> > >
> > > * libc/include/signal.h (psignal): Declare.
> > > * libc/sys/linux/psignal.c: Move from here...
> > > * libc/signal/psignal.c: ... t
On Thu, May 5, 2011 at 12:19 AM, Xinliang David Li wrote:
>>
>> I can think of some more-or-less obvious high-level forms, one would
>> for example simply stick a new DISPATCH tree into gimple_call_fn
>> (similar to how we can have OBJ_TYPE_REF there), the DISPATCH
>> tree would be of variable len
Hi!
My typed DWARF stack changes apparently broke ia64-hpux and H.J.'s out of
tree x32 target. There are several issues:
1) for SUBREG mem_loc_descriptor's 3rd argument was wrong, found by code
inspection
2) CONST/SYMBOL_REF/LABEL_REF when in MEM addresses on POINTERS_EXTEND_UNSIGNED
target
On 05/05/2011 09:38 AM, Eric Botcazou wrote:
> Hi,
>
> this entirely removes the support for pending sizes from the compiler. The
> prerequisite is Joseph's patch from yesterday.
>
> Bootstrapped/regtested on x86_64-suse-linux, OK for the mainline?
OK.
Bernd
On May 5 11:09, Ulrich Weigand wrote:
> This list does not include psignal, which indeed newlib did not provide
> -- until yesterday, when that patch was committed ...
>
>
> I'm not quite sure how to fix this ... any suggestions? Did this problem
> occur in the past when newlib was extende
> Sure, but that's a limitation of out SAVE_EXPR handling (given that it
> would be ok to expand the SAVE_EXPR multiple times - once per
> "instantiation context").
You need to expand the initializer exactly once and you need to make sure that
this occurrence is invoked before all the others at r
Hi!
create_tmp_var_raw calls build_type_variant, but doesn't actually use
it in any way (other than set its TYPE_ATTRIBUTES, that's why
-Wunused-but-set-variable hasn't reported it.
2011-05-05 Jakub Jelinek
* gimplify.c (create_tmp_var_raw): Don't call build_type_variant.
--- gcc/gim
On Thu, May 5, 2011 at 1:57 AM, Mike Stump wrote:
> On May 4, 2011, at 11:40 AM, Gerald Pfeifer wrote:
>> Documentation may be a bit more relaxed, and if you have one doc
>> maintainer approve and the other abstain that may be more boring
>> that you might hope for. :-)
>
> Actually, I was aiming
On Thu, 2011-05-05 at 14:51 +0800, Guozhi Wei wrote:
> Hi
>
> This is the third part of the fixing for
>
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47855
>
> This patch contains the length computation/refinement for insn patterns
> "*thumb2_movsi_insn", "*thumb2_cbz" and "*thumb2_cbnz".
>
>
On Thu, May 5, 2011 at 11:23 AM, Eric Botcazou wrote:
>> Sure, but that's a limitation of out SAVE_EXPR handling (given that it
>> would be ok to expand the SAVE_EXPR multiple times - once per
>> "instantiation context").
>
> You need to expand the initializer exactly once and you need to make sur
Hello,
this patch fixes the long-standing failure:
FAIL: g++.old-deja/g++.jason/thunk3.C (test for excess errors)
by providing a TARGET_ASM_OUTPUT_MI_THUNK implementation for SPU.
Tested on spu-elf, committed to mainline.
Bye,
Ulrich
ChangeLog:
* config/spu/spu.c (TARGET_ASM_OUTPUT_MI
On Thu, May 5, 2011 at 11:25 AM, Jakub Jelinek wrote:
> Hi!
>
> create_tmp_var_raw calls build_type_variant, but doesn't actually use
> it in any way (other than set its TYPE_ATTRIBUTES, that's why
> -Wunused-but-set-variable hasn't reported it.
Ok.
Thanks,
Richard.
> 2011-05-05 Jakub Jelinek
> But where do you expand it without the SAVE_EXPR? The same
> restrictions apply there. So I suppose you expand it to a function
> in which case there is the context where the SAVE_EXPR can be
> expanded exactly once.
You don't have SAVE_EXPRs so you're precisely controlling what you're doing.
On Thu, May 5, 2011 at 12:07 PM, Eric Botcazou wrote:
>> But where do you expand it without the SAVE_EXPR? The same
>> restrictions apply there. So I suppose you expand it to a function
>> in which case there is the context where the SAVE_EXPR can be
>> expanded exactly once.
>
> You don't have
On Thu, May 5, 2011 at 05:06, Richard Guenther
wrote:
> I think we should move away from pre-loading the streamer cache, that
> has caused enough trouble when the common nodes are originating from
> different Frontends and when compiling units with different flags which
> happen to change those n
On Thu, May 5, 2011 at 1:03 PM, Diego Novillo wrote:
> On Thu, May 5, 2011 at 05:06, Richard Guenther
> wrote:
>
>> I think we should move away from pre-loading the streamer cache, that
>> has caused enough trouble when the common nodes are originating from
>> different Frontends and when compili
On Thu, May 5, 2011 at 07:07, Richard Guenther
wrote:
> For LTO we have type-merging for that, and we'd continue to pre-load
> the type merger with the (LTO frontend specific) common tree nodes.
OK. For LTO it may make sense to eventually make this hook a nop, then.
> I suppose you are not doi
Hello!
No functional change.
2011-05-05 Uros Bizjak
* config/i386/i386.md (*movdf_internal_rex64): Simplify nested "if"
conditions.
(*movdf_internal): Ditto.
(*movdf_internal_nointeger): Ditto.
(*movsf_internal): Ditto.
Tested on x86_64-pc-linux-gnu {,
Currently the bootstrap with --enable-build-with-cxx is broken due to compiler
errors of the form
"error: converting 'false' to pointer type 'varpool_node*'
[-Werror=conversion-null]". The attached
patch changes these instances of false to NULL and restores the
--enable-build-with-cxx bootstrap.
There is indeed more simplification possible (alpha-vms for example
caught my attention while reviewing), but proceeding incrementally
does not hurt.
This patch is okay, thanks.
Paolo
2011/5/4, Joseph S. Myers :
> This patch separates cases disabling newlib and libgloss for various
> target OSe
> Hm, ok. I was more looking at removing the calls from fold-const.c where
> it seems to protect things like folding x <= +Inf to x == x, stuff unlikely
> to appear in type sizes. I can imagine the Ada FE wanting to do
> things with type sizes and variable_size's wrapping looks like merely
> an o
Hi!
On the attached enhanced typeddwarf.c testcase there is no location
info for the 3 vars in f4 function with -O2 -m32 -g. The parameter
is unused during expansion except for debug stmts, but DECL_INCOMING_RTL
isn't a hard register or MEM with hard register as address that would be
represented
> Currently the bootstrap with --enable-build-with-cxx is broken due to
> compiler errors of the form "error: converting 'false' to pointer type
> 'varpool_node*' [-Werror=conversion-null]". The attached patch changes
> these instances of false to NULL and restores the --enable-build-with-cxx
> boo
Hi!
This PR has been fixed without testcase being added,
fixed thusly, regtested on x86_64-linux and i686-linux,
committed to trunk.
2011-05-05 Jakub Jelinek
PR rtl-optimization/48381
* gcc.c-torture/compile/pr48381.c: New test.
--- gcc/testsuite/gcc.c-torture/compile/pr48381
On Tue, 03 May 2011 15:49:38 +0100
Richard Earnshaw wrote:
>
> 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.
> >
>
Hello!
Add --param min-insn-to-prefetch-ratio=0 to avoid "Not prefetching --
instruction to prefetch ratio (6) too small" aprefetch pass rejection.
2011-05-05 Uros Bizjak
* gcc.target/i386/opt-1.c: Add --param min-insn-to-prefetch -ratio=0
to dg-options.
* gcc.target/i
On Wed, 4 May 2011, Richard Guenther wrote:
> On Wed, 4 May 2011, Eric Botcazou wrote:
>
> > > I think I did it that way because the old code tried to re-construct
> > > the type of the original amount. I can surely simply use op1 here
> > > if that is preferred.
> >
> > Right, but it used the
On Thu, 2011-05-05 at 13:08 +0100, Julian Brown wrote:
> On Tue, 03 May 2011 15:49:38 +0100
> Richard Earnshaw wrote:
>
> >
> > 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 typ
On Thu, May 05, 2011 at 02:02:19PM +0200, Eric Botcazou wrote:
> > Currently the bootstrap with --enable-build-with-cxx is broken due to
> > compiler errors of the form "error: converting 'false' to pointer type
> > 'varpool_node*' [-Werror=conversion-null]". The attached patch changes
> > these in
On Thu, May 5, 2011 at 7:55 AM, Jack Howarth wrote:
> On Thu, May 05, 2011 at 02:02:19PM +0200, Eric Botcazou wrote:
>> > Currently the bootstrap with --enable-build-with-cxx is broken due to
>> > compiler errors of the form "error: converting 'false' to pointer type
>> > 'varpool_node*' [-Werror=
Currently the bootstrap with --enable-build-with-cxx is broken due to compiler
errors of the form
"error: converting 'false' to pointer type 'varpool_node*'
[-Werror=conversion-null]". The attached
patch changes the last remaing instance of false to NULL and restores the
--enable-build-with-cxx
> The arm.opt change is OK, but 'Report' should stay; and it should also
> be added to the -marm case.
Ok with this change ? Rebuilt docs and built a cross with arm-linux-gnueabi ?
2011-05-05 Ramana Radhakrishnan
PR target/47930
* config/arm/arm.opt (marm): Document it.
(
On Thu, May 05, 2011 at 07:56:20AM -0500, Gabriel Dos Reis wrote:
> On Thu, May 5, 2011 at 7:55 AM, Jack Howarth wrote:
> > On Thu, May 05, 2011 at 02:02:19PM +0200, Eric Botcazou wrote:
> >> > Currently the bootstrap with --enable-build-with-cxx is broken due to
> >> > compiler errors of the form
>I didn't see that patch so just reduce mine down to the change for
> change for gcc/varpool.c. Odd that the gcc/varpool.c issue isn't seen on
> other targets besides darwin apparently.
No problem. Please install the entire patch (with Dmitry's name as second
name) as Dmitry hasn't got commi
On Thu, May 5, 2011 at 8:02 AM, Jack Howarth wrote:
> On Thu, May 05, 2011 at 07:56:20AM -0500, Gabriel Dos Reis wrote:
>> On Thu, May 5, 2011 at 7:55 AM, Jack Howarth
>> wrote:
>> > On Thu, May 05, 2011 at 02:02:19PM +0200, Eric Botcazou wrote:
>> >> > Currently the bootstrap with --enable-buil
>
> OK for trunk?
I have now committed this to trunk for you and will backport this to
release branches at some point in the next few days.
cheers
Ramana
>
> -- Michael
>
> gcc/
>
> 2011-05-02 Michael Hope
>
> PR pch/45979
> * config/host-linux.c (TRY_EMPTY_VM_SPACE): Define fo
Jerry,
> My goal is to completely not use any floating point operations for that
> section of code. We have a concept on how to do it. I am still working
> out tweaks to 48787, then I will turn my attention to this. Feel free to
> quiet that test case any way you wish in the meantime.
ok, I've
Tobias,
I know Mike already approved that patch. Just a few nits.
> # Test coarray support.
> #
> # For the compilation tests, all files are compiles with the
^ d
> # option -fcoarray=single and with -fcoarray=lib
On Thu, May 5, 2011 at 2:58 PM, Jack Howarth wrote:
> Currently the bootstrap with --enable-build-with-cxx is broken due to
> compiler errors of the form
> "error: converting 'false' to pointer type 'varpool_node*'
> [-Werror=conversion-null]". The attached
> patch changes the last remaing insta
On 05/04/2011 06:57 PM, Eric Botcazou wrote:
But you're unilaterally choosing one special handling (copying) among several
ones (copying, not copying, aborting) just because of one caller, for no good
reason IMO.
It seems pretty straightforward to me that a function named copy_tree_r
should co
Hi!
According to a clarification on OpenMP forums, if(0) which creates
an undeferred task doesn't mean if the implementation chooses to schedule
it right away that it is included task. Included tasks are thus only
the children tasks of some final task.
Fixed thusly:
2011-05-05 Jakub Jelinek
+ && (mode != Pmode
+ || GET_MODE_SIZE (ptr_mode) != DWARF2_ADDR_SIZE
This test seems overly cautious; it seems implausible to have
DWARF2_ADDR_SIZE smaller than GET_MODE_SIZE (ptr_mode), and having it be
larger doesn't seem like a problem.
+ || m
Here the issue was that build_new_1 wants to stabilize any constructor
arguments so that the EH region for deleting the allocated memory can be
as small as possible. But stabilize_expr was being over-eager, making a
copy of a class with trivial constructors, but a non-trivial (and indeed
non-c
On Thu, May 05, 2011 at 10:25:53AM -0400, Jason Merrill wrote:
> >+ && (mode != Pmode
> >+ || GET_MODE_SIZE (ptr_mode) != DWARF2_ADDR_SIZE
>
> This test seems overly cautious; it seems implausible to have
> DWARF2_ADDR_SIZE smaller than GET_MODE_SIZE (ptr_mode), and having
>
On Thu, 2011-05-05 at 14:00 +0100, Ramana Radhakrishnan wrote:
> > The arm.opt change is OK, but 'Report' should stay; and it should also
> > be added to the -marm case.
>
> Ok with this change ? Rebuilt docs and built a cross with arm-linux-gnueabi ?
>
> 2011-05-05 Ramana Radhakrishnan
>
>
On 05/05/2011 10:56 AM, Jakub Jelinek wrote:
We can't handle Pmode void* like other pointers?
mem_mode == VOIDmode doesn't mean a void* pointer, mem_mode != VOIDmode
means mem_loc_descriptor is called on some MEM's address and gives the
mode of the MEM, while VOIDmode mem_mode means it isn't a
On Wed, May 4, 2011 at 7:54 AM, Joseph S. Myers wrote:
> Two options, -mcmodel= and -mfpu=, had cases that fell through to the
> next case without comments to indicate if this was intended. I added
> comments to make the semantics explicit. Given the documentation, it
> may well be intentional
> I don't know how to avoid this problem in configure, other than by adding
> AC_LIBOBJ([psignal]).
Right, the correct solution is - libiberty shouldn't provide psignal
if newlib does. Making it match newlib is the wrong solution.
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
I should have included these in the last patch of infrastructure changes.
The main change is create_block_for_threading no longer calls
remove_ctrl_stmt_and_useless_edges and instead its callers are expected
to handle that, when needed. This will al
This is PR ada/48844, a regression present on the mainline and 4.6 branch.
The compiler aborts on an assignment of an aggregate to another object, if the
nominal subtype of the former is a discriminated record type with a variant
part for which the variants all have the same size and one of the v
On May 4, 2011, at 8:17 PM, Nathan Froyd wrote:
> The last remaining uses of build_function_type in the ObjC/C++ frontends
> comes from this pattern:
> OK to commit?
Ok.
>
On 05/05/2011 07:09 AM, Jason Merrill wrote:
> No, but the rationale isn't documented. It was added by the patch
> that introduced STATEMENT_LIST,
>
> http://gcc.gnu.org/ml/gcc-patches/2003-11/msg00879.html
>
> but doesn't appear in the ChangeLog entry. I notice that in that
> patch unsave_r c
On Thu, May 5, 2011 at 00:52, Hans-Peter Nilsson
wrote:
> Once or twice a year some regression results from changed I/O
> in libgfortran, such that some existing test-case starts
> calling libgfortran/io/unix.c:raw_truncate, which on
> limited-I/O-bare-iron targets will emit "required ftruncate or
DJ Delorie wrote:
> > I don't know how to avoid this problem in configure, other than by adding
> > AC_LIBOBJ([psignal]).
>
> Right, the correct solution is - libiberty shouldn't provide psignal
> if newlib does. Making it match newlib is the wrong solution.
I guess I agree, but the problem is e
On May 5 11:29, DJ Delorie wrote:
>
> > I don't know how to avoid this problem in configure, other than by adding
> > AC_LIBOBJ([psignal]).
>
> Right, the correct solution is - libiberty shouldn't provide psignal
> if newlib does. Making it match newlib is the wrong solution.
You don't mean th
On May 5 18:44, Ulrich Weigand wrote:
> DJ Delorie wrote:
> > > I don't know how to avoid this problem in configure, other than by adding
> > > AC_LIBOBJ([psignal]).
> >
> > Right, the correct solution is - libiberty shouldn't provide psignal
> > if newlib does. Making it match newlib is the wro
No, we've always hard-coded what newlib does to avoid the link
problems. I think we should continue with that for now.
I suspect we need to AC_DEFINE(HAVE_PSIGNAL)
> You don't mean the prototype, do you? IMHO the char * should still be
> changed to const char * to adhere to POSIX.
So far, it's served as a good tool for detecting when libiberty's
configure isn't doing its job :-)
At this point, we should avoid "fixing" it until the newlib/configure
issue i
On Thu, May 5, 2011 at 2:16 AM, Richard Guenther
wrote:
> On Thu, May 5, 2011 at 12:19 AM, Xinliang David Li wrote:
>>>
>>> I can think of some more-or-less obvious high-level forms, one would
>>> for example simply stick a new DISPATCH tree into gimple_call_fn
>>> (similar to how we can have OBJ
David Edelsohn wrote:
On Wed, May 4, 2011 at 7:54 AM, Joseph S. Myers wrote:
Two options, -mcmodel= and -mfpu=, had cases that fell through to the
next case without comments to indicate if this was intended. I added
comments to make the semantics explicit. Given the documentation, it
may wel
On Thu, May 5, 2011 at 12:54 AM, Corinna Vinschen wrote:
> On May 5 00:40, Andrew Pinski wrote:
>> On Thu, May 5, 2011 at 12:30 AM, Corinna Vinschen
>> wrote:
>> > Thanks,
>> > Corinna
>> >
>> >
>> > * strsignal.c (psignal): Change second parameter to const char *.
>> > Fix commen
DJ Delorie wrote:
> No, we've always hard-coded what newlib does to avoid the link
> problems. I think we should continue with that for now.
>
> I suspect we need to AC_DEFINE(HAVE_PSIGNAL)
Corinna Vinschen had the same suggestion:
> Sorry about that. I guess that should have been something alo
On May 5, 2011, at 9:36 AM, Janne Blomqvist wrote:
> The testsuite uses the process return value to determine
> success, right? But which values exactly constitute success
> vs. failure?
0 is success, and != 0 is failure.
On Thu, May 5, 2011 at 09:32, Richard Guenther
wrote:
> And yes, in "harm" I mostly refer to svn blame annoyances and to
> patch/branch merge conflicts where context that causes the conflict
> only changed in whitespace.
Your tools are limiting the quality of your work.
Are we not the toolmakers
IIRC there's a compile-time way to test for prototypes at least.
Diego,
I know this is a truly horrible and broken way to do this, but alternatives
(e.g., NLS) don't really work for us.
bootstrapped without new configuration (x86-64 ubuntu lucid, didn't bother
to run tests), bootstrapped with option (x86-64 ubuntu lucid, with full
tests, no regressions). Manu
> Date: Thu, 5 May 2011 19:36:47 +0300
> From: Janne Blomqvist
> On Thu, May 5, 2011 at 00:52, Hans-Peter Nilsson
> wrote:
> > This time, it happened in 173155:173168.
> >
> > Usually, there's also a brief question whether all changes were
> > intended, or perhaps that some of the regressing tes
On Thu, May 5, 2011 at 14:27, Chris Demetriou wrote:
> Diego,
>
> I know this is a truly horrible and broken way to do this, but alternatives
> (e.g., NLS) don't really work for us.
>
> bootstrapped without new configuration (x86-64 ubuntu lucid, didn't bother
> to run tests), bootstrapped with op
On Thu, May 05, 2011 at 10:08:24AM -0700, Michael Eager wrote:
> David Edelsohn wrote:
> >On Wed, May 4, 2011 at 7:54 AM, Joseph S. Myers
> >wrote:
> >
> >>Two options, -mcmodel= and -mfpu=, had cases that fell through to the
> >>next case without comments to indicate if this was intended. I add
Changes:
- Remove (not working) critical functions; a normal coarray of LOCK type
should be used instead. (Stub left in until it is removed the the front
end.)
- Added prototypes and stub implementations for
registering/deregistering coarray (currently unused).
- Small bug fixes.
OK for th
On Thu, May 5, 2011 at 11:47 AM, Diego Novillo wrote:
>> OK for google/main?
Is there a reason why this cannot be an option that someone passes on
the command line of GCC instead of a configure option? Also can you
show an example of why this message would be changed?
Thanks,
Andrew Pinski
This patch continues work on avoiding global state in
rs6000_handle_option by cleaning up the handling of -mabi= options.
The part using global state, a test for TARGET_SPE_ABI, is moved to
rs6000_option_override_internal (so now testing the state after all
options are applied). The -mabi= option
On Tue, May 03, 2011 at 10:51:51PM -0400, David Edelsohn wrote:
> What does this do to the ABI? Haven't we now broken the ABI and
> broken backwards compatibility?
In this case, GCC wasn't following the ABI. My patch will have GCC follow the
ABI. The XL compiler also follows the ABI. So we hav
On Wed, May 04, 2011 at 11:33:43AM +0200, Richard Guenther wrote:
> On Wed, May 4, 2011 at 4:51 AM, David Edelsohn wrote:
> > What does this do to the ABI? Haven't we now broken the ABI and
> > broken backwards compatibility?
>
> It at least looks like so. You need to add appropriate changes.ht
On Thu, 5 May 2011, Michael Eager wrote:
> David Edelsohn wrote:
> > On Wed, May 4, 2011 at 7:54 AM, Joseph S. Myers
> > wrote:
> >
> > > Two options, -mcmodel= and -mfpu=, had cases that fell through to the
> > > next case without comments to indicate if this was intended. I added
> > > commen
On Thu, May 5, 2011 at 01:36, David Li wrote:
> This patch improves cross module option mismatch handling in LIPO mode --
> will be commited to google/main.
>
> 1) Remove duplicates in the option list before comparison;
> 2) Force module incompatiblity when two modules disagree in -fexceptions
>
Hello,
Compilation of code containing pragma Assert fails if restriction
No_Implementation_Pragmas is used, even with -gnat2005 or -gnat2012
flags:
% cat test.adb
pragma Restrictions(No_Implementation_Pragmas);
procedure test(I : Integer) is
begin
pragma Assert(I /= 1);
null;
end;
% gcc -c t
Jason Merrill writes:
> I think using get_first_fn could make non_static_member_function_p a
> lot shorter.
Like this?
Tested like the previous patch.
gcc/cp
PR c++/48838
* cp-tree.h (non_static_member_function_p): Declare new function.
* tree.c (non_static_member_func
While working on something else I noticed that REFERENCE_REF_P was being
clobbered by stabilize_expr, so this patch changes it to just use the
type rather than a lang_flag.
Tested x86_64-pc-linux-gnu, applying to trunk.
commit f24566a2f2594c7d4c7d7d3e26a4341d87deaec6
Author: Jason Merrill
Date
Build and regtested on x86-64-linux
OK for the trunk?
I forgot to include a run-time test case. Find one attached.
Tobias
! { dg-do run }
! { dg-additional-sources bind_c_usage_24_c.c }
!
! PR fortran/48858
! PR fortran/48820
!
! TR 29113: BIND(C) with OPTIONAL
!
module m
use iso_c_binding
On 05/05/2011 03:52 PM, Dodji Seketeli wrote:
+ if (is_overloaded_fn (fn))
+fn = get_first_fn (fn);
+ else if (BASELINK_P (fn))
is_overloaded_fn should be true for a BASELINK.
Jason
Hello!
> In this case, GCC wasn't following the ABI. My patch will have GCC follow the
> ABI. The XL compiler also follows the ABI. So we have to decide whether to
> keep the current calling sequence which violates the ABI, or change the
> compiler to follow the ABI, and break backwards compati
Joseph S. Myers wrote:
On Thu, 5 May 2011, Michael Eager wrote:
David Edelsohn wrote:
On Wed, May 4, 2011 at 7:54 AM, Joseph S. Myers
wrote:
Two options, -mcmodel= and -mfpu=, had cases that fell through to the
next case without comments to indicate if this was intended. I added
comments t
Hi,
I just merged the changes from trunk into the graphite branch:
2010-05-05 Sebastian Pop
* Merge from mainline (170411:173446).
Save and restored globals keyed_classes and unemitted_tinfo_decls.
Save and restore member TYPE_BINFO.
Index: gcc/cp/ChangeLog.pph
2011-05-05 Lawrence Crowl
* pph.c (pph_write_file_contents): Save keyed_classes and
unemitted_tinfo_decls.
(pph_read_file_contents): Restor
It's a good check to add, but if it returns true we should abort
rather than
just returning 0.
I couldn't convince myself that a subprogram definition inside a type
declaration would never happen, so I took the defensive approach. If
you're confident that it can't (or shouldn't) ever happen, t
On 05/05/2011 05:33 PM, ccout...@google.com wrote:
I couldn't convince myself that a subprogram definition inside a type
declaration would never happen, so I took the defensive approach. If
you're confident that it can't (or shouldn't) ever happen, then what if
I leave the predicate contains_subp
http://codereview.appspot.com/4486042/diff/1/gcc/cp/pph-streamer.h
File gcc/cp/pph-streamer.h (right):
http://codereview.appspot.com/4486042/diff/1/gcc/cp/pph-streamer.h#newcode152
gcc/cp/pph-streamer.h:152: for (i = 0; i < c; ++i)
+#if 0
+static inline void
+pph_output_tree_array (pph_stream *s
On Thu, May 05, 2011 at 03:08:43PM -0400, Michael Meissner wrote:
> Yes, it was an error on my part. Sorry. I will fix the GCC 4.6 branch. I
> will hold off fixing the on trunk, on the assumption this patch will go in. I
> can fix it if desired.
I committed the following patch on the GCC 4.6 b
On 5/5/11, dnovi...@google.com wrote:
> http://codereview.appspot.com/4486042/diff/1/gcc/cp/pph-streamer.h
> File gcc/cp/pph-streamer.h (right):
>
> http://codereview.appspot.com/4486042/diff/1/gcc/cp/pph-streamer.h#newcode152
> gcc/cp/pph-streamer.h:152: for (i = 0; i < c; ++i)
> +#if 0
> +static
Jason Merrill writes:
> On 05/05/2011 03:52 PM, Dodji Seketeli wrote:
>> + if (is_overloaded_fn (fn))
>> +fn = get_first_fn (fn);
>> + else if (BASELINK_P (fn))
>
> is_overloaded_fn should be true for a BASELINK.
Correct. I should have seen that. I have bootstrapped the patch below
then.
On Thu, May 05, 2011 at 11:29:13AM -0400, David Edelsohn wrote:
> Alan, is mcmodel suppose to set m64?
No, that was an accident.
--
Alan Modra
Australia Development Lab, IBM
1 - 100 of 110 matches
Mail list logo
