Re: invalid insn generated
I have already have both and it still does that.
It seems that after we get here, nothing would stop gcc from emiting
such an invalid insn (tem = emit_insn (gen_move_insn (out, in));). So
I think that maybe the problem is that I got there with these in and
out arguments.
2010/6/23, Ian Lance Taylor i...@google.com:
roy rosen roy.1ro...@gmail.com writes:
In my port I get to gen_reload to the lines
/* If IN is a simple operand, use gen_move_insn. */
else if (OBJECT_P (in) || GET_CODE (in) == SUBREG)
{
static int xxx;
xxx = OBJECT_P (in);
tem = emit_insn (gen_move_insn (out, in));
/* IN may contain a LABEL_REF, if so add a REG_LABEL_OPERAND note. */
mark_jump_label (in, tem, 0);
}
the emit_insn which should emit a move insn gets as out a register
from class D and as in the Stack pointer.
In my port there is no insn which can write directly from sp to d. so
the emitted insn is invalid and the compilation terminates.
What might be the problem?
Is it possible to arrive to this point with such arguments and later
to fix it or does the problem begin earlier somewhere.
This tends to mean that you haven't set REGISTER_MOVE_COST correctly.
You need to make sure that moves between register class D and the
stack pointer have a cost greater than 2. If you are unlucky you may
have to introduce a secondary reload.
Ian
Re: gengtype needs for C++?
On 06/29/2010 06:48 PM, Basile Starynkevitch wrote:
On Tue, 2010-06-29 at 11:40 +0200, Paolo Bonzini wrote:
On 06/29/2010 04:16 AM, Tom Tromey wrote:
Ian In Tom's interesting idea, we would write the mark function by hand for
Ian each C++ type that we use GTY with.
I think we should be clear that the need to write a mark function for a
new type is a drawback of this approach. Perhaps gengtype could still
write the functions for ordinary types in GCC, just not (templatized)
containers.
Yes, gengtype would emit template specializations instead of its own
mangled function names, and it would just call the same function (e.g.
gt_mark) instead of using mangled names. The C++ front-end would pick
up the correct function.
It seems very complicated to me (and apparently different from current
gengtype behavior), and I don't understand why should gengtype emit
template specializations instead of simple code. Of course, I am only
thinking of gengtype generated routines.
Or probably I did not understood what you mean. Could you give a simple
example please?
Now:
/* A zillion macros like this one: */
extern void gt_ggc_mx_throw_stmt_node (void *);
#define gt_ggc_m_20ssa_operand_memory_d(X) do { \
if (X != NULL) gt_ggc_mx_ssa_operand_memory_d (X);\
} while (0)
/* Many functions like this: */
void
gt_ggc_mx_eh_catch_d (void *x_p)
{
struct eh_catch_d * const x = (struct eh_catch_d *)x_p;
if (ggc_test_and_set_mark (x))
{
gt_ggc_m_10eh_catch_d ((*x).next_catch);
gt_ggc_m_10eh_catch_d ((*x).prev_catch);
gt_ggc_m_9tree_node ((*x).type_list);
gt_ggc_m_9tree_node ((*x).filter_list);
gt_ggc_m_9tree_node ((*x).label);
}
}
/* For each VEC, a function like this: */
void
gt_ggc_mx_VEC_eh_region_gc (void *x_p)
{
struct VEC_eh_region_gc * const x = (struct VEC_eh_region_gc *)x_p;
if (ggc_test_and_set_mark (x))
{
{
size_t i0;
size_t l0 = (size_t)(((*x).base).num);
for (i0 = 0; i0 != l0; i0++) {
gt_ggc_m_11eh_region_d ((*x).base.vec[i0]);
}
}
}
}
After:
/* Two templates like these: */
template class T static inline void
ggc_mark_all (T *const x)
{
if (x != NULL) ggc_mark_all_1 (x);
}
template class T static inline void
ggc_mark_all_1 (T *const x)
{
gcc_unreachable();
}
/* Many specializations like this (generated by gengtype). */
template void
ggc_mark_all_1 (struct eh_catch_d * const x)
{
if (ggc_test_and_set_mark (x))
{
ggc_mark_all ((*x).next_catch);
ggc_mark_all ((*x).prev_catch);
ggc_mark_all ((*x).type_list);
ggc_mark_all ((*x).filter_list);
ggc_mark_all ((*x).label);
}
}
/* A single specialization for all std::vectors, whose treatment
is simpler than VECs in gengtype: */
template std::vectorT, ggc_allocator void
ggc_mark_all_1 (std::vectorT, ggc_allocator * const x)
{
typedef typename std::vectorT, ggc_allocator vec_type;
typedef typename vec_type::iterator iterator;
for (iterator p = x.begin(), q = x.end(); p != q; ++p)
gcc_mark_all (*p);
}
Of course it may be too bad for compilation times, it may require other
changes (e.g. to the way roots are enumerated, or because templates
require stuff to be in header files that used to be in gtype-desc.c), it
may not work at all. No idea. :)
Paolo
Re: gengtype needs for C++?
On Wed, Jun 30, 2010 at 11:51:46AM +0200, Paolo Bonzini wrote:
Now:
/* A zillion macros like this one: */
[...]
After:
/* Two templates like these: */
template class T static inline void
ggc_mark_all (T *const x)
{
if (x != NULL) ggc_mark_all_1 (x);
}
template class T static inline void
ggc_mark_all_1 (T *const x)
{
gcc_unreachable();
}
/* Many specializations like this (generated by gengtype). */
template void
ggc_mark_all_1 (struct eh_catch_d * const x)
{
if (ggc_test_and_set_mark (x))
{
ggc_mark_all ((*x).next_catch);
ggc_mark_all ((*x).prev_catch);
ggc_mark_all ((*x).type_list);
ggc_mark_all ((*x).filter_list);
ggc_mark_all ((*x).label);
}
}
/* A single specialization for all std::vectors, whose treatment
is simpler than VECs in gengtype: */
template std::vectorT, ggc_allocator void
ggc_mark_all_1 (std::vectorT, ggc_allocator * const x)
{
typedef typename std::vectorT, ggc_allocator vec_type;
typedef typename vec_type::iterator iterator;
for (iterator p = x.begin(), q = x.end(); p != q; ++p)
gcc_mark_all (*p);
}
Of course it may be too bad for compilation times, it may require
other changes (e.g. to the way roots are enumerated, or because
templates require stuff to be in header files that used to be in
gtype-desc.c), it may not work at all. No idea. :)
Thanks for the nice explanations.
Cheers.
--
Basile STARYNKEVITCH http://starynkevitch.net/Basile/
email: basileatstarynkevitchdotnet mobile: +33 6 8501 2359
8, rue de la Faiencerie, 92340 Bourg La Reine, France
*** opinions {are only mines, sont seulement les miennes} ***
call_value problem: var = func() !?
Hello,
I'm working on a new gcc target and trying to implement call_value.
When compiling (-O0 -S) the following c code :
int f1(int a, int b)
{
int tmp = a + b;
return tmp;
}
void main()
{
int a = 10;
int b = 20;
int c;
c = f1(a,b);
}
I get the following error:
f1.c: In function 'f1':
f1.c:5:1: error: unrecognizable insn:
(insn 12 11 13 3 f1.c:4
(set (mem/c/i:SI (reg/f:SI 23 [ D.1964 ]) [0 retval+0 S4 A32])
(mem/c/i:SI (plus:SI (reg/f:SI 19 virtual-stack-vars)
(const_int -4 [0xfffc]))
[0 tmp+0 S4 A32])) -1 (nil))
I defined expanders and insns only for moving between registers, set
registers with immediate and moving from mem to register and vice versa.
Moving from mem to mem is not allowed. So shouldn't gcc try to force
one of the two mem addresses in a register? I don't even know if that's
what causing the error.
This is the call_value implementation in .md:
(define_expand call_value
[(parallel [(set (match_operand 0 register_operand )
(call (match_operand 1 general_operand )
(match_operand 2 )))
(clobber (reg:SI RETURN_ADDR_REGNUM))])]
{
rtx dest = XEXP(operands[1], 0);
if(!call_operand(dest, Pmode))
dest = force_reg(Pmode, dest);
emit_call_insn(gen_call_value_internal(operands[0], dest, operands[2]));
DONE;
})
(define_insn call_value_internal
[(parallel [(set (match_operand 0 register_operand )
(call (match_operand 1 general_operand )
(match_operand 2 )))
(clobber (reg:SI RETURN_ADDR_REGNUM))])]
bal\t%1)
And this is my function_value:
rtx
function_value(const_tree valtype, const_tree func, enum machine_mode mode)
{
/* first step is an integer-C compiler */
/*G_RET return value reg num = %r1 .*/
return gen_rtx_REG(SImode, G_RET);
}
I'd be grateful for any help.
Kind regards.
--
if [ $(uname) = Linux ];then echo
[q]sb[lv0=blv256%Plv256/svlcx]sc911084920508\
6363247337574050075032905184391195412274100697358608023133864165787933915045683\
432087129472907338347329339706073226139582008068077725378669120069632svlcxq|dc;fi;
Re: invalid insn generated
roy rosen roy.1ro...@gmail.com writes:
I have already have both and it still does that.
It seems that after we get here, nothing would stop gcc from emiting
such an invalid insn (tem = emit_insn (gen_move_insn (out, in));). So
I think that maybe the problem is that I got there with these in and
out arguments.
That's correct. You need to figure out how to make that not happen.
(That was the actually the goal of my suggestion, although I didn't say
it, and I guess it was not helpful in any case.)
Ian
2010/6/23, Ian Lance Taylor i...@google.com:
roy rosen roy.1ro...@gmail.com writes:
In my port I get to gen_reload to the lines
/* If IN is a simple operand, use gen_move_insn. */
else if (OBJECT_P (in) || GET_CODE (in) == SUBREG)
{
static int xxx;
xxx = OBJECT_P (in);
tem = emit_insn (gen_move_insn (out, in));
/* IN may contain a LABEL_REF, if so add a REG_LABEL_OPERAND note.
*/
mark_jump_label (in, tem, 0);
}
the emit_insn which should emit a move insn gets as out a register
from class D and as in the Stack pointer.
In my port there is no insn which can write directly from sp to d. so
the emitted insn is invalid and the compilation terminates.
What might be the problem?
Is it possible to arrive to this point with such arguments and later
to fix it or does the problem begin earlier somewhere.
This tends to mean that you haven't set REGISTER_MOVE_COST correctly.
You need to make sure that moves between register class D and the
stack pointer have a cost greater than 2. If you are unlucky you may
have to introduce a secondary reload.
Ian
Re: call_value problem: var = func() !?
On 06/30/2010 05:06 AM, M. -Eqbal Maraqa wrote:
f1.c:5:1: error: unrecognizable insn:
(insn 12 11 13 3 f1.c:4
(set (mem/c/i:SI (reg/f:SI 23 [ D.1964 ]) [0 retval+0 S4 A32])
(mem/c/i:SI (plus:SI (reg/f:SI 19 virtual-stack-vars)
(const_int -4 [0xfffc]))
[0 tmp+0 S4 A32])) -1 (nil))
I strongly suspect that your movsi expander is incorrect.
This is the call_value implementation in .md:
(define_expand call_value
[(parallel [(set (match_operand 0 register_operand )
(call (match_operand 1 general_operand )
(match_operand 2 )))
(clobber (reg:SI RETURN_ADDR_REGNUM))])]
{
rtx dest = XEXP(operands[1], 0);
if(!call_operand(dest, Pmode))
dest = force_reg(Pmode, dest);
emit_call_insn(gen_call_value_internal(operands[0], dest, operands[2]));
DONE;
})
(define_insn call_value_internal
[(parallel [(set (match_operand 0 register_operand )
(call (match_operand 1 general_operand )
(match_operand 2 )))
(clobber (reg:SI RETURN_ADDR_REGNUM))])]
bal\t%1)
You've missed that the operand to call is always a mem. Most
ports look through this mem immediately, e.g.
(call (mem (match_operand:P 1 register_operand r))
(match_operand 2 ))
Have another look at how the other ports expand and implement call.
r~
Re: Patch pinging
NightStrike nightstr...@gmail.com writes: [...] So who actually said no? The Frederic guy didn't like my fake-looking fake name, and wanted a real-looking-but-just-as-fake name, or he wouldn't create a account for me. In consultation with other overseers, I rejected your request. I did not ask for a real-looking-but-just-as-fake name, but a real name. You falsely presume zero vetting. He then ignored my followup emails asking for clarification. You said no. There was nothing further to discuss. - FChE
Re: Patch pinging
On Wed, Jun 30, 2010 at 1:13 PM, Frank Ch. Eigler f...@redhat.com wrote: NightStrike nightstr...@gmail.com writes: [...] So who actually said no? The Frederic guy didn't like my fake-looking fake name, and wanted a real-looking-but-just-as-fake name, or he wouldn't create a account for me. In consultation with other overseers, I rejected your request. I did not ask for a real-looking-but-just-as-fake name, but a real name. You falsely presume zero vetting. You missed my point, then. What's in a name? How would you know if what I told you was true or not? He then ignored my followup emails asking for clarification. You said no. There was nothing further to discuss. Not exactly. I offered you an alternative, and I asked you a question. You ignored both. You could very well have given me feedback, explained what was going on, let me know that I was rejected, or any of a dozen other things.
Re: Patch pinging
On 06/30/2010 07:32 PM, NightStrike wrote: In consultation with other overseers, I rejected your request. I did not ask for a real-looking-but-just-as-fake name, but a real name. You falsely presume zero vetting. You missed my point, then. What's in a name? How would you know if what I told you was true or not? How many liars do you think are actively contributing to GCC? Just a guess... Paolo.
Re: Patch pinging
On Wed, Jun 30, 2010 at 1:41 PM, Paolo Carlini paolo.carl...@oracle.com wrote: On 06/30/2010 07:32 PM, NightStrike wrote: In consultation with other overseers, I rejected your request. I did not ask for a real-looking-but-just-as-fake name, but a real name. You falsely presume zero vetting. You missed my point, then. What's in a name? How would you know if what I told you was true or not? How many liars do you think are actively contributing to GCC? Just a guess... Paolo. No idea. I've been emailed offlist by 3 people that used fake names. Or at least claimed to.
Re: Patch pinging
On 06/30/2010 07:44 PM, NightStrike wrote: No idea. I've been emailed offlist by 3 people that used fake names. Or at least claimed to. Personally, I have trouble believing that (unless we have independent evidence that they also sleep with a 44 Magnum under the napkin). In any case, personally I don't really mind which nickname people use in most of the day by day correspondence on the mailing lists, but I find entirely sensible for FSF to have on file genuine data about the contributors. Like any other profit or non-profit organization, as far as I know. Paolo.
Re: Patch pinging
I meant pillow of course ;) ;) Paolo.
Re: About gimple_body in gimple.h
On 28 June 2010 15:48, Diego Novillo dnovi...@google.com wrote: On Mon, Jun 28, 2010 at 09:38, jeremie.salvu...@free.fr wrote: Hello all, I would like to know why does gimple_body returns NULL pointer when I try to use it after the cfg pass ? Does someone have informations about the general use of it ? Because the body has been split up into the basic blocks of the CFG. You need to use the basic block iterators to traverse the CFG (e.g., FOR_EACH_BB_FN()). Because I am trying to traverse instructions from a C program thanks to MELT (cf MELT branch) and I don't know if I have to traverse basic blocks with FOR_EACH_BB_FN iterator or if there is another solution with gimple_body. Basile believes that gimple_body is nearly useless. It is once the CFG has been built, yes. Jeremie, it may help future users if you added this information to the comment above gimple_body. I think such a small patch wouldn't need any copyright assignment. Thanks, Manuel.
Re: Patch pinging
On Wed, Jun 30, 2010 at 1:32 PM, NightStrike nightstr...@gmail.com wrote: On Wed, Jun 30, 2010 at 1:13 PM, Frank Ch. Eigler f...@redhat.com wrote: NightStrike nightstr...@gmail.com writes: [...] So who actually said no? The Frederic guy didn't like my fake-looking fake name, and wanted a real-looking-but-just-as-fake name, or he wouldn't create a account for me. In consultation with other overseers, I rejected your request. I did not ask for a real-looking-but-just-as-fake name, but a real name. You falsely presume zero vetting. You missed my point, then. What's in a name? How would you know if what I told you was true or not? He understood your point very well. That is why Frank said, You falsely presume zero vetting. Do you realize that your email message convey a very smug tone? - David
Re: About gimple_body in gimple.h
On Wed, 2010-06-30 at 21:15 +0200, Manuel López-Ibáñez wrote:
On 28 June 2010 15:48, Diego Novillo dnovi...@google.com wrote:
On Mon, Jun 28, 2010 at 09:38, jeremie.salvu...@free.fr wrote:
Hello all,
I would like to know why does gimple_body returns NULL pointer when I try
to use it after the cfg pass ? Does someone have informations about the
general use of it ?
Because the body has been split up into the basic blocks of the CFG.
You needto use the basic block iterators to traverse the CFG (e.g.,
FOR_EACH_BB_FN()).
Because I am trying to traverse instructions from a C program thanks to
MELT (cf MELT branch) and I don't know if I have to traverse basic blocks
with FOR_EACH_BB_FN iterator or if there is another solution with
gimple_body. Basile believes that gimple_body is nearly useless.
It is once the CFG has been built, yes.
Jeremie, it may help future users if you added this information to the
comment above gimple_body. I think such a small patch wouldn't need
any copyright assignment.
Jeremie Salvucci (who is my intern, so we work each working day
together) did all the necessary legal work to be authorized to
contribute to GCC (see some previous messages for references : he is
authorized to commit as student of Université Paris Est [Marne la
Vallée] and as intern of CEA -LIST). So Jeremie is already covered by
copyright assignment (from CEA) disclaimer (from Univ Paris Est).
Legally as is ok (and this was checked by Paolo).
However, he still don't have any ssh account on gcc.gnu.org so he don't
not yet have in practice write (after approval) access to the Subversion
repository of GCC.
What are the concrete steps to get him such an account?
It would be much simpler (both for Jeremie for me Basile) if he [=
Jeremie Salvucci] had his own account. For the few patches he already
contributed to the MELT branch, I committed them for him. But it would
be much simpler for him to have the ability (that is the account) to
submit on Gcc's Svn.
For practical details (e.g. preferred logins, ssh keys) ask
jeremie.salvu...@free.fr
Cheers
--
Basile STARYNKEVITCH http://starynkevitch.net/Basile/
email: basileatstarynkevitchdotnet mobile: +33 6 8501 2359
8, rue de la Faiencerie, 92340 Bourg La Reine, France
*** opinions {are only mines, sont seulement les miennes} ***
Re: Patch pinging
On Wed, Jun 30, 2010 at 3:24 PM, David Edelsohn dje@gmail.com wrote: He understood your point very well. That is why Frank said, You falsely presume zero vetting. Maybe I didn't get the zero vetting part, then. I thought I did, but apparently not. What does that mean in this context? Google isn't telling me. Do you realize that your email message convey a very smug tone? No, I do not realize that. I was intending to speak matter-of-fact-ly.
Re: About gimple_body in gimple.h
On 30 June 2010 21:28, Basile Starynkevitch bas...@starynkevitch.net wrote: However, he still don't have any ssh account on gcc.gnu.org so he don't not yet have in practice write (after approval) access to the Subversion repository of GCC. What are the concrete steps to get him such an account? http://gcc.gnu.org/svnwrite.html (If you cannot find this information yourself, it would be extremely helpful to provide a website patch to improve its visibility) Until he has SVN write access, you (or I) can commit approved patches on Jeremie's behalf. That is not excuse to not submit patches. ;-) Cheers, Manuel.
The trunk is fronzen NOW for the mem-ref2 merge
The trunk is frozen now. I am in the process of committing a last trunk-to-branch merge and start testing of the merge (and the trunk for comparison) on x86_64-linux, ppc64-linux and ia64-linux including multilibs where appropriate. Thanks for your cooperation, Richard.
Plug-ins on Windows
Hello, I am playing around with a plug-in for gcc but recently ran into the road block that plug-ins aren't supported on Windows. Are there any plans to add support for the windows platform in the future? If not, what are the issues with supporting Windows and how much effort would it be to add support? I'm assuming that since it's not done already there has to be some difficulty somewhere... Would it be a lot faster/easier to create a custom gcc that has my plug-in compiled in directly for the windows platform? thanks, Kyle
Re: The trunk is fronzen NOW for the mem-ref2 merge
On 06/30/2010 09:59 PM, Richard Guenther wrote: The trunk is frozen now. I am in the process of committing a last trunk-to-branch merge and start testing of the merge (and the trunk for comparison) on x86_64-linux, ppc64-linux and ia64-linux including multilibs where appropriate. Apologies, I had troubles for a couple of hours fetching email, including this one, and committed by mistake a small C++ front-end patch. In case, let me know, and I'll take care of reverting and reapply at the end of the freeze. Paolo.
Re: The trunk is fronzen NOW for the mem-ref2 merge
On Wed, Jun 30, 2010 at 10:49 PM, Paolo Carlini paolo.carl...@oracle.com wrote: On 06/30/2010 09:59 PM, Richard Guenther wrote: The trunk is frozen now. I am in the process of committing a last trunk-to-branch merge and start testing of the merge (and the trunk for comparison) on x86_64-linux, ppc64-linux and ia64-linux including multilibs where appropriate. Apologies, I had troubles for a couple of hours fetching email, including this one, and committed by mistake a small C++ front-end patch. In case, let me know, and I'll take care of reverting and reapply at the end of the freeze. No need. It just won't get any testing for the merge. Richard. Paolo.
Re: Plug-ins on Windows
On Wed, 2010-06-30 at 16:38 -0400, Kyle Girard wrote: Hello, I am playing around with a plug-in for gcc but recently ran into the road block that plug-ins aren't supported on Windows. Are there any plans to add support for the windows platform in the future? If not, what are the issues with supporting Windows and how much effort would it be to add support? I'm assuming that since it's not done already there has to be some difficulty somewhere... Disclaimer: I know nothing about Windows I never used it (except twice a year to change a mandatory password). I absolutely know nothing about Windows programming in the WIN32 API. Back to GCC plugins. If I remember correctly, we did slightly consider using libtldl, a wrapper providing dlopen variant http://www.gnu.org/software/libtool/manual/html_node/Libltdl-interface.html but we later rejected that idea to avoid adding yet another library dependency to GCC. Apparently libltdl is supposed to work on Windows. Perhaps you could try to use it in your own variant of GCC. However, I would imagine that making the GCC trunk accept it is much more difficult ( personally I don't care that much anymore). Perhaps also they are some technical issues that makes using libltdl impractical. Maybe your concern should be to make sure that the -rdynamic functionality of Linux linker can be emulated on Windows. You really want most public symbols of GCC to be visible from your Windows GCC plugin. I heard it could be hard (i.e. boring) to achieve (perhaps requiring a dllexport on all public symbols of GCC). I'll be interested to know if you succeeded in making some GCC plugin work under Windows. In case you are very brave, you might even as an exercice port the MELT plugin http://gcc.gnu.org/wiki/MELT to Windows! But I am not sure it is worth the effort. Cheers.
installing with minimal sudo
Hello All,
Is there some trick so that the GCC trunk (or a branch like MELT) is
built under some user (e.g. basile) and is installed (in the
usual /usr/local prefix, which is writable by root, not by ordinary
users on most Linux systems)
My concrete need is the following
after a
make
and a
sudo make install
I sometimes have a few root-owned files in the build directory.
(eg ./gcc/b-header-vars or ./gcc/b-header-vars). I would like to avoid
that if possible (and I confess that the MELT branch Makefile.in are not
very good: I am bad at Makefile.in hacking).
Perhaps a make install INSTALL='sudo install' could be enough, but I
tend to remember I have tried that more than a year ago without success.
Or is there a mean to pass INSTALL='sudo install' at configure time?
How do you build install GCC (trunk or some other branch) without
having any root owned files in the build directory?
Trying a lot of times a make distclean make install is a very time
consuming process that I hate doing.
How do distributions makers achieve that?? IIRC they have a strict rule
that no compilation or build should run under root!
Practical advices welcome.
Cheers.
PS. On Debian, the make-kpkg command has a --rootcmd=sudo option. I am
trying to imagine the equivalent for GCC. Of course on my machine sudo
don't ask any password.
--
Basile STARYNKEVITCH http://starynkevitch.net/Basile/
email: basileatstarynkevitchdotnet mobile: +33 6 8501 2359
8, rue de la Faiencerie, 92340 Bourg La Reine, France
*** opinions {are only mines, sont seulement les miennes} ***
Re: Massive performance regression from switching to gcc 4.5
On 06/24/2010 12:06 PM, Andrew Pinski wrote: On Jun 24, 2010, at 11:50 AM, Taras Glek tg...@mozilla.com wrote: Hi, Just wanted to give a heads up on what might be the biggest compiler-upgrade-related performance difference we've seen at Mozilla. We switched gcc4.3 for gcc4.5 and our automated benchmarking infrastructure reported 4-19% slowdown on most of our performance metrics on 32 and 64bit Linux. A lone 8% speedup was measured on the Sunspider javascript benchmark on 64bit linux. Here are some of the slowdowns reported: http://groups.google.com/group/mozilla.dev.tree-management/browse_thread/thread/77951ccb76b5e630# http://groups.google.com/group/mozilla.dev.tree-management/browse_thread/thread/624246d7d900ed41# Most of the code is compiled with -fPIC -fno-rtti -fno-exceptions -Os Stop right there. You are compiling at -Os, that is tuned for size and not speed. So the question is did the size go down? Not the speed decreased. Try at -O2 and report back. I doubt we are going to do a tradeoff for speed at -Os at all. Thanks, Andrew Pinski Good point. Looks like the actual problem is that at -Os there is less inclining happening in 4.5 vs 4.3, which results in a bigger binary and slower code. I tried 4.5 -O2 and it's actually faster than 4.3 -Os. I am happy that -O2 performance is actually pretty good, but -Os regression is going to hurt on mobile. Taras
Re: Massive performance regression from switching to gcc 4.5
On Wed, 2010-06-30 at 14:23 -0700, Taras Glek wrote:
I tried 4.5 -O2 and it's actually faster than 4.3 -Os.
I am happy that -O2 performance is actually pretty good, but -Os
regression is going to hurt on mobile.
Did you try gcc-4.5 -flto -Os or gcc-4.5 -flto -O2?
It would be interesting to hear that GCC is able to LTO a program as big
as Mozilla! And figures (notably RAM, CPU time, wallclock time for
build) would be interesting.
Cheers.
--
Basile STARYNKEVITCH http://starynkevitch.net/Basile/
email: basileatstarynkevitchdotnet mobile: +33 6 8501 2359
8, rue de la Faiencerie, 92340 Bourg La Reine, France
*** opinions {are only mines, sont seulement les miennes} ***
Re: Massive performance regression from switching to gcc 4.5
On 06/30/2010 02:26 PM, Basile Starynkevitch wrote: On Wed, 2010-06-30 at 14:23 -0700, Taras Glek wrote: I tried 4.5 -O2 and it's actually faster than 4.3 -Os. I am happy that -O2 performance is actually pretty good, but -Os regression is going to hurt on mobile. Did you try gcc-4.5 -flto -Os or gcc-4.5 -flto -O2? It would be interesting to hear that GCC is able to LTO a program as big as Mozilla! And figures (notably RAM, CPU time, wallclock time for build) would be interesting. Both whopr and flto cause gcc to segfault while building Mozilla. Taras
Re: Massive performance regression from switching to gcc 4.5
On 06/30/2010 02:26 PM, Basile Starynkevitch wrote: On Wed, 2010-06-30 at 14:23 -0700, Taras Glek wrote: I tried 4.5 -O2 and it's actually faster than 4.3 -Os. I am happy that -O2 performance is actually pretty good, but -Os regression is going to hurt on mobile. Did you try gcc-4.5 -flto -Os or gcc-4.5 -flto -O2? It would be interesting to hear that GCC is able to LTO a program as big as Mozilla! And figures (notably RAM, CPU time, wallclock time for build) would be interesting. Both whopr and flto cause gcc to segfault while building Mozilla. 4.5 WHOPR is completely broken. LTO is in better shape but I am not sure if we can resonably expect it to build mozilla. However I would be very happy to help getting WHOPR working for 4.6. If you can find actual simple examples where -Os is losing size and speed we can try to do something about them. Honza Taras
Re: installing with minimal sudo
Quoting Basile Starynkevitch bas...@starynkevitch.net: Hello All, Is there some trick so that the GCC trunk (or a branch like MELT) is built under some user (e.g. basile) and is installed (in the usual /usr/local prefix, which is writable by root, not by ordinary users on most Linux systems) I usually install in more nonstandard locations - ones I can write to. So no sudo is required. How do you build install GCC (trunk or some other branch) without having any root owned files in the build directory? What's the problem? you could just change the owner of the files to yourself while you are root. Or afterwards, you can delete them, as long as you can write to the directory they reside in. find builddir -user root should find them all. Then you can use command substitution, xargs, or just find itself, to chown / rm these files.
Re: installing with minimal sudo
On 30/06/2010 22:18, Basile Starynkevitch wrote: How do you build install GCC (trunk or some other branch) without having any root owned files in the build directory? Run make install as the limited user, using a DESTDIR, then sudo cp -R (or similar) the installed tree into final destination. cheers, DaveK
Re: Plug-ins on Windows
Quoting Kyle Girard k...@kdmanalytics.com: Would it be a lot faster/easier to create a custom gcc that has my plug-in compiled in directly for the windows platform? Depends on how many plugins you use. The distgcc page says it's reported to work on cygwin. So you could use a cygwin distgcc to send the compile job to some other machine, or a virtual machine on the same machine, which runs a Unix or GNU system with elf object format.
Re: Plug-ins on Windows
On 30/06/2010 21:38, Kyle Girard wrote: Hello, I am playing around with a plug-in for gcc but recently ran into the road block that plug-ins aren't supported on Windows. Are there any plans to add support for the windows platform in the future? If not, what are the issues with supporting Windows and how much effort would it be to add support? I'm assuming that since it's not done already there has to be some difficulty somewhere... The main problem is that plugins rely on the property of the ELF format that you can leave undefined references in a shared library and have them filled in by symbols exported from the main exe at runtime; they use this to call the various functions exported from GCC, like register_callback, and to access global variables and so on. Although we could build plugins as Windows DLLs and have GCC load them at runtime, if those DLLs needed to refer to anything in the main GCC executable, it would have to be specifically linked to import it - and imports on Windows have to explicitly specify the name of the DLL (or executable) they are imported from. That means that the plugin would need to explicitly refer to cc1.exe or cc1plus.exe, etc; we'd need to build separate versions of the plugin for each of the different GCC language compilers. (Long term, we might be able to extend the toolchain and libltdl to co-operate to do this kind of deferred runtime linking for us, but that's not imminent.) Would it be a lot faster/easier to create a custom gcc that has my plug-in compiled in directly for the windows platform? Yes, much! At least for the foreseeable future. Sorry. cheers, DaveK
Re: installing with minimal sudo
On 30.06.2010 23:18, Basile Starynkevitch wrote: Practical advices welcome. Cheers. PS. On Debian, the make-kpkg command has a --rootcmd=sudo option. I am trying to imagine the equivalent for GCC. Of course on my machine sudo don't ask any password. unsure if I understand this correctly, but you could install setting DESTDIR to a temporary installation location and then copying the files later to the final location. Matthias
Re: Plug-ins on Windows
On 06/30/2010 03:46 PM, Dave Korn wrote: Although we could build plugins as Windows DLLs and have GCC load them at runtime, if those DLLs needed to refer to anything in the main GCC executable, it would have to be specifically linked to import it - and imports on Windows have to explicitly specify the name of the DLL (or executable) they are imported from. That means that the plugin would need to explicitly refer to cc1.exe or cc1plus.exe, etc; we'd need to build separate versions of the plugin for each of the different GCC language compilers. (Long term, we might be able to extend the toolchain and libltdl to co-operate to do this kind of deferred runtime linking for us, but that's not imminent.) Long term we could arrange for libbackend.a to become libbackend.dll and have that library be used for plugins. The existing practice of linking back into the main executable is more or less an efficiency hack that happens to work with ELF. r~
Re: Plug-ins on Windows
On 06/30/2010 03:46 PM, Dave Korn wrote: Although we could build plugins as Windows DLLs and have GCC load them at runtime, if those DLLs needed to refer to anything in the main GCC executable, it would have to be specifically linked to import it - and imports on Windows have to explicitly specify the name of the DLL (or executable) they are imported from. That means that the plugin would need to explicitly refer to cc1.exe or cc1plus.exe, etc; we'd need to build separate versions of the plugin for each of the different GCC language compilers. (Long term, we might be able to extend the toolchain and libltdl to co-operate to do this kind of deferred runtime linking for us, but that's not imminent.) Long term we could arrange for libbackend.a to become libbackend.dll and have that library be used for plugins. The existing practice of linking back into the main executable is more or less an efficiency hack that happens to work with ELF. It also makes WHOPR with -fwhole-program possible on GCC. If we will want to have dynamically linkable backend library, we would need to clean up our interfaces quite a lot so frontend does not link into backend other way than by langhooks. (or make other crosslinking explicit via externally_visible) Not that would be a bad thing. I made absolutely no measurements yet if linking frotned into backend improves performance in any sensible way. Honza r~
loop peeling vs TARGET_CASE_VALUES_THRESHOLD
In unroll_loop_runtime_iterations() we emit a sequence of n_peel compare/jump instructions. Why don't we honor TARGET_CASE_VALUES_THRESHOLD here, and use a tablejump when n_peel is too big?
Re: Patch pinging
Ian Lance Taylor wrote: Thanks for the info. So there is now a provenance, which is the point: there is a more-or-less real person associated with each contribution. I certainly would like the FSF to move to a similar model. I agree. I do understand the rationale for the FSF's desire to hold copyright, and have a paper trail. But, at this point, I think that's making it harder to people to participate, and with no real benefit. The FSF is clinging to an outmoded policy due to a single occurrence from long ago. However, I believe that there is nothing we can do about that; I don't imagine that this is something on which RMS or the SFLC would likely move. I think that means that our only pragmatic choice is whether to be an FSF project or not. If we don't want that, then, of course, we could adopt the Linux kernel's rules on contribution instead. (We'd also give up any ability to relicense code going forward (e.g., between GPL and GFDL) since we'd likely have many copyright holders, and no practical hope of getting them all to agree on any change.) But, as long as we do want to be an FSF project, we have to play by the FSF's rules. -- Mark Mitchell CodeSourcery m...@codesourcery.com (650) 331-3385 x713
[Bug debug/44694] [4.5/4.6 Regression] Long var tracking compile time of GiNaC tests
--- Comment #9 from jakub at gcc dot gnu dot org 2010-06-30 06:12 --- Subject: Bug 44694 Author: jakub Date: Wed Jun 30 06:12:22 2010 New Revision: 161587 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=161587 Log: PR debug/44694 * cselib.h (cselib_preserve_cfa_base_value): Add regno argument. * cselib.c (cfa_base_preserved_regno): New static variable. (cselib_reset_table): Don't reset cfa_base_preserved_regno instead of REGNO (cfa_base_preserved_val-locs-loc). (cselib_preserve_cfa_base_value): Add regno argument, set cfa_base_preserved_regno to it. (cselib_invalidate_regno): Allow removal of registers other than cfa_base_preserved_regno from cfa_base_preserved_val. (cselib_finish): Set cfa_base_preserved_regno to INVALID_REGNUM. * var-tracking.c (adjust_mems): Replace sp or hfp even outside of MEM addresses, if not on LHS. (reverse_op): Don't add reverse ops for cfa_base_rtx. (vt_init_cfa_base): Adjust cselib_preserve_cfa_base_value caller. Modified: trunk/gcc/ChangeLog trunk/gcc/cselib.c trunk/gcc/cselib.h trunk/gcc/var-tracking.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44694
[Bug bootstrap/44721] [4.6 regression] Failed to bootstrap
--- Comment #1 from jv244 at cam dot ac dot uk 2010-06-30 07:14 --- similar error compiling CP2K with rev 161570, (rev 161517 was still OK). /data/vondele/gcc_bench/cp2k/makefiles/../src/qs_rho0_methods.F:850:0: error: unrecognizable insn: (insn 6975 398 6976 13 /data/vondele/gcc_bench/cp2k/makefiles/../src/qs_rho0_methods.F:712 (set (reg:DI 1 dx) (mem/c/i:SI (plus:DI (reg/f:DI 7 sp) (const_int 4656 [0x1230])) [2 lmax_0+0 S4 A128])) -1 (nil)) /data/vondele/gcc_bench/cp2k/makefiles/../src/qs_rho0_methods.F:850:0: internal compiler error: in extract_insn, at recog.c:2127 Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html for instructions. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44721
[Bug debug/44694] [4.5 Regression] Long var tracking compile time of GiNaC tests
--- Comment #10 from jakub at gcc dot gnu dot org 2010-06-30 07:16 --- Fixed on the trunk so far. -- jakub at gcc dot gnu dot org changed: What|Removed |Added Summary|[4.5/4.6 Regression] Long |[4.5 Regression] Long var |var tracking compile time of|tracking compile time of |GiNaC tests |GiNaC tests http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44694
[Bug libfortran/43298] fortran library does not read in NaN -Inf or Inf
--- Comment #13 from burnus at gcc dot gnu dot org 2010-06-30 08:06 --- (In reply to comment #5) - convert_real needs to get the comment updated (assuming POSIX/C99 strtod) I think that's the only item left to do: Deleting the following TODO from read.c's convert_real - and then the bug can be closed: * argument is properly aligned for the type in question. TODO: * handle not-a-numbers and infinities. */ (The comment is wrong as strtod handles NAN/INF ...) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43298
[Bug fortran/44292] [libgfortran ABI breakage] Increase internal size of RECL= of the OPEN statement
--- Comment #4 from burnus at gcc dot gnu dot org 2010-06-30 08:08 --- See also: PR 29602 -- burnus at gcc dot gnu dot org changed: What|Removed |Added OtherBugsDependingO||29602 nThis|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44292
[Bug target/43958] FAIL: gcc.dg/ipa/ipa-pta-10.c scan-ipa-dump pta ESCAPED = { }
--- Comment #8 from rguenth at gcc dot gnu dot org 2010-06-30 08:27 --- Can you, instead of /* Copied from va-pa.h, but we probably don't need to align to word size, since we generate and preserve that invariant. */ u = size_int (size 4 ? -8 : -4); t = fold_convert (sizetype, t); t = build2 (BIT_AND_EXPR, sizetype, t, u); t = fold_convert (valist_type, t); use u = build_int_cst (TREE_TYPE (t), (HOST_WIDE_INT)(size 4 ? -8 : -4)); t = build2 (BIT_AND_EXPR, TREE_TYPE (t), t, u); t = fold_convert (valist_type, t); thus, perform the AND in pointer types? This is what I am going to do to replace REALIGN_INDIRECT_REF with and teach PTA about this (so to not pessimize hppa here). Mine for now - I'll ping you when infrastructure is ready to deal with pointer BIT_AND_EXPRs. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |rguenth at gcc dot gnu dot |dot org |org Status|NEW |ASSIGNED Last reconfirmed|2010-05-02 15:28:17 |2010-06-30 08:27:49 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43958
[Bug middle-end/44722] [4.6 Regression] Long compile time or infinite loop
-- rguenth at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|--- |4.6.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44722
[Bug bootstrap/44720] [4.6 Regression] Yet another bootstrap failure on x86_64-apple-darwin10
-- rguenth at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|--- |4.6.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44720
[Bug bootstrap/44719] [4.6 Regression] Make warning: overriding command
-- rguenth at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|--- |4.6.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44719
[Bug middle-end/44716] [4.6 Regression] Bootstrap fails with partial inlining (r161382)
-- rguenth at gcc dot gnu dot org changed: What|Removed |Added Keywords||build Summary|Bootstrap fails with partial|[4.6 Regression] Bootstrap |inlining (r161382) |fails with partial inlining ||(r161382) Target Milestone|--- |4.6.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44716
[Bug bootstrap/44699] [4.6 Regression] Bootstrap failure for x86_64-apple-darwin10: ICE while compiling genmodes.c
--- Comment #14 from iains at gcc dot gnu dot org 2010-06-30 08:39 --- (In reply to comment #13) @r161591 with this: The patch in http://gcc.gnu.org/ml/gcc-patches/2010-06/msg03011.html (and the patch to correct emit_unwind_label) === I no longer get the build_real fail - but this instead : /GCC/gcc-live-trunk/gcc/coverage.c: In function htab_counts_entry_hash: /GCC/gcc-live-trunk/gcc/coverage.c:151:1: error: unrecognizable insn: (insn 28 7 29 2 /GCC/gcc-live-trunk/gcc/coverage.c:150 (set (reg:DI 1 dx) (mem/s:SI (plus:DI (reg/v/f:DI 5 di [orig:64 of ] [64]) (const_int 4 [0x4])) [8 entry_2-ctr+0 S4 A32])) -1 (nil)) /GCC/gcc-live-trunk/gcc/coverage.c:151:1: internal compiler error: in extract_insn, at recog.c:2127 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44699
[Bug c/44723] New: unrecognizable insn during stage 2 compilation of gcc/coverage.c
On both SLE10 SP3 and SLE11 SP1, trying to bootstrap an unpatched snapshot of trunk (at 161589) using the system provided binutils, I get /home/jbeulich/cpp/gcc/trunk-svn/2010-06-30/gcc/coverage.c: In function htab_counts_entry_hash: /home/jbeulich/cpp/gcc/trunk-svn/2010-06-30/gcc/coverage.c:151:1: error: unrecognizable insn: (insn 25 7 26 2 /home/jbeulich/cpp/gcc/trunk-svn/2010-06-30/gcc/coverage.c:150 (set (reg:DI 1 dx) (mem/s:SI (plus:DI (reg/v/f:DI 5 di [orig:64 of ] [64]) (const_int 4 [0x4])) [15 entry_2-ctr+0 S4 A32])) -1 (nil)) /home/jbeulich/cpp/gcc/trunk-svn/2010-06-30/gcc/coverage.c:151:1: internal compiler error: in extract_insn, at recog.c:2127 Bootstrapping the same snapshot on i686-pc-linux-gnu is going fine. -- Summary: unrecognizable insn during stage 2 compilation of gcc/coverage.c Product: gcc Version: 4.6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: jbeulich at novell dot com GCC build triplet: x86_64-unknown-linux-gnu GCC host triplet: x86_64-unknown-linux-gnu GCC target triplet: x86_64-unknown-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44723
[Bug target/43603] gcc-4.4.3 ICE on ia64 with -O3
--- Comment #5 from abel at gcc dot gnu dot org 2010-06-30 08:44 ---
The below patch implements keeping dominance info up to date in the scheduler.
After discussions with Alexander, I think that it will be better to leave the
copy_rtx calls as is, so that if we'll see this problem once again, we fail
immediately instead of silently miscompiling code. The patch fixes both this
testcase and PR 44233's testcase.
(Also, Zdenek kindly provided a patch for the dominator tree infrastructure
that eases the development by failing immediately when the dominator data
structures become inconsistent, and I've made a cleanup patch in the scheduler.
I will also submit both of those patches.)
gcc/haifa-sched.c |2 +
gcc/sel-sched-ir.c | 53 +++
2 files changed, 50 insertions(+), 5 deletions(-)
diff --git a/gcc/haifa-sched.c b/gcc/haifa-sched.c
index 8d7149f..6bf526e 100644
--- a/gcc/haifa-sched.c
+++ b/gcc/haifa-sched.c
@@ -4452,6 +4452,8 @@ sched_create_recovery_edges (basic_block first_bb,
basic_block rec,
edge_flags = 0;
make_single_succ_edge (rec, second_bb, edge_flags);
+ if (dom_info_available_p (CDI_DOMINATORS))
+set_immediate_dominator (CDI_DOMINATORS, rec, first_bb);
}
/* This function creates recovery code for INSN. If MUTATE_P is nonzero,
diff --git a/gcc/sel-sched-ir.c b/gcc/sel-sched-ir.c
index 3146a26..f2be2df 100644
--- a/gcc/sel-sched-ir.c
+++ b/gcc/sel-sched-ir.c
@@ -3544,6 +3544,7 @@ static bool
maybe_tidy_empty_bb (basic_block bb, bool recompute_toporder_p)
{
basic_block succ_bb, pred_bb;
+ VEC (basic_block, heap) *dom_bbs;
edge e;
edge_iterator ei;
bool rescan_p;
@@ -3579,6 +3580,7 @@ maybe_tidy_empty_bb (basic_block bb, bool
recompute_toporder_p)
succ_bb = single_succ (bb);
rescan_p = true;
pred_bb = NULL;
+ dom_bbs = NULL;
/* Redirect all non-fallthru edges to the next bb. */
while (rescan_p)
@@ -3591,6 +3593,12 @@ maybe_tidy_empty_bb (basic_block bb, bool
recompute_toporder_p)
if (!(e-flags EDGE_FALLTHRU))
{
+ /* We will update dominators here only when we'll get
+ an unreachable block when redirecting, otherwise
+ sel_redirect_edge_and_branch will take care of it. */
+ if (e-dest != bb
+ single_pred_p (e-dest))
+VEC_safe_push (basic_block, heap, dom_bbs, e-dest);
recompute_toporder_p |= sel_redirect_edge_and_branch (e,
succ_bb);
rescan_p = true;
break;
@@ -3610,11 +3618,20 @@ maybe_tidy_empty_bb (basic_block bb, bool
recompute_toporder_p)
remove_empty_bb (bb, true);
}
+
+ if (!VEC_empty (basic_block, dom_bbs))
+{
+ VEC_safe_push (basic_block, heap, dom_bbs, succ_bb);
+ iterate_fix_dominators (CDI_DOMINATORS, dom_bbs, false);
+ VEC_free (basic_block, heap, dom_bbs);
+}
+
if (recompute_toporder_p)
sel_recompute_toporder ();
#ifdef ENABLE_CHECKING
verify_backedges ();
+ verify_dominators (CDI_DOMINATORS);
#endif
return true;
@@ -5026,7 +5043,12 @@ sel_remove_bb (basic_block bb, bool remove_from_cfg_p)
bitmap_clear_bit (blocks_to_reschedule, idx);
if (remove_from_cfg_p)
-delete_and_free_basic_block (bb);
+{
+ basic_block succ = single_succ (bb);
+ delete_and_free_basic_block (bb);
+ set_immediate_dominator (CDI_DOMINATORS, succ,
+ recompute_dominator (CDI_DOMINATORS, succ));
+}
rgn_setup_region (CONTAINING_RGN (idx));
}
@@ -5361,12 +5383,15 @@ sel_merge_blocks (basic_block a, basic_block b)
void
sel_redirect_edge_and_branch_force (edge e, basic_block to)
{
- basic_block jump_bb, src;
+ basic_block jump_bb, src, orig_dest = e-dest;
int prev_max_uid;
rtx jump;
- gcc_assert (!sel_bb_empty_p (e-src));
-
+ /* This function is now used only for bookkeeping code creation, where
+ we'll never get the single pred of orig_dest block and thus will not
+ hit unreachable blocks when updating dominator info. */
+ gcc_assert (!sel_bb_empty_p (e-src)
+ !single_pred_p (orig_dest));
src = e-src;
prev_max_uid = get_max_uid ();
jump_bb = redirect_edge_and_branch_force (e, to);
@@ -5383,6 +5408,10 @@ sel_redirect_edge_and_branch_force (edge e, basic_block
to)
jump = find_new_jump (src, jump_bb, prev_max_uid);
if (jump)
sel_init_new_insn (jump, INSN_INIT_TODO_LUID | INSN_INIT_TODO_SIMPLEJUMP);
+ set_immediate_dominator (CDI_DOMINATORS, orig_dest,
+ recompute_dominator (CDI_DOMINATORS, orig_dest));
+ set_immediate_dominator (CDI_DOMINATORS, to,
+ recompute_dominator (CDI_DOMINATORS, to));
}
/* A wrapper for redirect_edge_and_branch. Return TRUE if blocks connected by
@@ -5391,11 +5420,12 @@ bool
sel_redirect_edge_and_branch (edge e, basic_block to)
{
bool latch_edge_p;
- basic_block src;
+
[Bug rtl-optimization/44691] [4.6 Regression] ICE: RTL check: expected code 'reg', have 'plus' in rhs_regno, at rtl.h:1050
--- Comment #2 from abel at gcc dot gnu dot org 2010-06-30 08:49 ---
The below patch fixes the problem for me.
diff --git a/gcc/sel-sched.c b/gcc/sel-sched.c
index 8590b8a..15c4e51 100644
--- a/gcc/sel-sched.c
+++ b/gcc/sel-sched.c
@@ -837,7 +837,8 @@ count_occurrences_1 (rtx *cur_rtx, void *arg)
if (GET_CODE (*cur_rtx) == SUBREG
REG_P (p-x)
- REGNO (SUBREG_REG (*cur_rtx)) == REGNO (p-x))
+ (!REG_P (SUBREG_REG (*cur_rtx))
+ || REGNO (SUBREG_REG (*cur_rtx)) == REGNO (p-x)))
{
/* ??? Do not support substituting regs inside subregs. In that case,
simplify_subreg will be called by validate_replace_rtx, and
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44691
[Bug bootstrap/44699] [4.6 Regression] Bootstrap failure for x86_64-apple-darwin10: ICE while compiling genmodes.c
--- Comment #15 from iains at gcc dot gnu dot org 2010-06-30 08:59 --- (In reply to comment #14) (In reply to comment #13) @r161591 with this: The patch in http://gcc.gnu.org/ml/gcc-patches/2010-06/msg03011.html (and the patch to correct emit_unwind_label) === I no longer get the build_real fail - but this instead : /GCC/gcc-live-trunk/gcc/coverage.c: In function htab_counts_entry_hash: /GCC/gcc-live-trunk/gcc/coverage.c:151:1: error: unrecognizable insn: (insn 28 7 29 2 /GCC/gcc-live-trunk/gcc/coverage.c:150 (set (reg:DI 1 dx) (mem/s:SI (plus:DI (reg/v/f:DI 5 di [orig:64 of ] [64]) (const_int 4 [0x4])) [8 entry_2-ctr+0 S4 A32])) -1 (nil)) /GCC/gcc-live-trunk/gcc/coverage.c:151:1: internal compiler error: in extract_insn, at recog.c:2127 ah, that's PR44721 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44699
[Bug bootstrap/44721] [4.6 regression] Failed to bootstrap (ICE in extract_insn, at recog.c:2127)
--- Comment #2 from rguenth at gcc dot gnu dot org 2010-06-30 09:47 --- Subject: Bug 44721 Author: rguenth Date: Wed Jun 30 09:47:25 2010 New Revision: 161594 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=161594 Log: 2010-06-30 H.J. Lu hongjiu...@intel.com PR target/44721 * config/i386/i386.md (peephole2 for arithmetic ops with memory): Fix last commit. Modified: trunk/gcc/ChangeLog trunk/gcc/config/i386/i386.md -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44721
[Bug middle-end/44722] [4.6 Regression] Long compile time or infinite loop
--- Comment #1 from rguenth at gcc dot gnu dot org 2010-06-30 09:51 --- Same issue when building libjava. We run out of virtual memory. from gdb I can see we run amok in peephole2_optimize. So that's again bernds patch. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added CC||bernds at gcc dot gnu dot ||org Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2010-06-30 09:51:17 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44722
[Bug middle-end/44722] [4.6 Regression] Long compile time or infinite loop
--- Comment #2 from rguenth at gcc dot gnu dot org 2010-06-30 09:55 --- We're peepholing in circles I guess? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44722
[Bug bootstrap/44721] [4.6 regression] Failed to bootstrap (ICE in extract_insn, at recog.c:2127)
--- Comment #3 from rguenth at gcc dot gnu dot org 2010-06-30 10:15 --- *** Bug 44723 has been marked as a duplicate of this bug. *** -- rguenth at gcc dot gnu dot org changed: What|Removed |Added CC||jbeulich at novell dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44721
[Bug c/44723] unrecognizable insn during stage 2 compilation of gcc/coverage.c
--- Comment #1 from rguenth at gcc dot gnu dot org 2010-06-30 10:15 --- *** This bug has been marked as a duplicate of 44721 *** -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44723
[Bug bootstrap/44721] [4.6 regression] Failed to bootstrap (ICE in extract_insn, at recog.c:2127)
--- Comment #4 from rguenth at gcc dot gnu dot org 2010-06-30 10:16 --- Fixed. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44721
[Bug rtl-optimization/44722] [4.6 Regression] Bootstrap fails during libjava
--- Comment #3 from rguenth at gcc dot gnu dot org 2010-06-30 10:16 --- This issue causes a bootstrap fail in libjava on x86_64-linux. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Component|middle-end |rtl-optimization Keywords||build Summary|[4.6 Regression] Long |[4.6 Regression] Bootstrap |compile time or infinite|fails during libjava |loop| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44722
[Bug middle-end/44681] usage of macro in loop boundary leads to crash
--- Comment #3 from jd at cococo dot de 2010-06-30 10:32 --- You are right - it was a matter of bracketing. After having changed the macro to #define max(a,b)(ab?a:b) it works fine on MingW and Linux. The problem lies in an incompatibility between to Delphi 2010. Delphi processed it according to my intention and gcc interprets it differently. Thanks, Jens -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44681
[Bug rtl-optimization/44722] [4.6 Regression] Bootstrap fails during libjava
--- Comment #4 from rguenth at gcc dot gnu dot org 2010-06-30 10:32 --- Index: gcc/config/i386/i386.md === --- gcc/config/i386/i386.md (revision 161594) +++ gcc/config/i386/i386.md (working copy) @@ -4729,6 +4729,7 @@ (define_peephole2 (set (match_operand:SSEMODEI24 2 register_operand ) (fix:SSEMODEI24 (match_dup 0)))] TARGET_SHORTEN_X87_SSE +!(TARGET_AVOID_VECTOR_DECODE optimize_insn_for_speed_p ()) peep2_reg_dead_p (2, operands[0]) [(set (match_dup 2) (fix:SSEMODEI24 (match_dup 1)))] ) fixes array_reference_1.f90, checking bootstrap now. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44722
[Bug bootstrap/44714] libgcc configure: error: cannot compute suffix of object files
--- Comment #7 from jbare7 at gmail dot com 2010-06-30 10:36 --- I tried putting them in the gcc-4.5.0 directory and I tried installing them from my distro, but neither of these worked to fix the error. You need to rename them to just gmp instead of gmp-4.3.2 etc. I tried this, but now I get an error when running make for gcc that it can't find gmp-impl.h and longlong.h, even though these exist in the gmp directory which I made. But I really suggest you figure out how to install the libraries from Ubuntu's packages, it will save you a lot of effort. You could also try the gcc-help mailing list, since I'm fairly sure this is user error, not a bug in gcc. I really want to use the package manager to install this, but gcc-4.5.0 does not seem to be available as an upgrade for my version of gcc in the package manager I have. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44714
[Bug middle-end/44681] usage of macro in loop boundary leads to crash
--- Comment #4 from redi at gcc dot gnu dot org 2010-06-30 10:57 --- Delphi and C have different operator precedence -- redi at gcc dot gnu dot org changed: What|Removed |Added Status|WAITING |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44681
[Bug bootstrap/44714] libgcc configure: error: cannot compute suffix of object files
--- Comment #8 from redi at gcc dot gnu dot org 2010-06-30 11:08 --- (In reply to comment #7) I tried putting them in the gcc-4.5.0 directory and I tried installing them from my distro, but neither of these worked to fix the error. You need to rename them to just gmp instead of gmp-4.3.2 etc. I tried this, but now I get an error when running make for gcc that it can't find gmp-impl.h and longlong.h, even though these exist in the gmp directory which I made. Then you're doing something wrong. But I really suggest you figure out how to install the libraries from Ubuntu's packages, it will save you a lot of effort. You could also try the gcc-help mailing list, since I'm fairly sure this is user error, not a bug in gcc. I really want to use the package manager to install this, but gcc-4.5.0 does not seem to be available as an upgrade for my version of gcc in the package manager I have. No, but libgmp3-dev, libmpfr-dev and libmpc-dev are available, and if you had installed them then you would have been able to build gcc a lot more easily. It might be too late, if you've installed them yourself and didn't know what you were doing you might have various broken installations on your system. Or they might be fine and you just need to use LD_LIBRARY_PATH. I suggest you delete the whole gcc-4.5.0 directory, as you might have made a mess of it. Then either install the gmp, mpfr and mpc dev Ubuntu packages OR set LD_LIBRARY_PATH to find your existing installations (if you sure they're installed OK). Then unzip the gcc sources again, but this time follow the advice at http://gcc.gnu.org/install/configure.html and do not run configure and make in the gcc-4.5.0 directory: tar xzvf gcc-4.5.0.tar.gz mkdir build cd build ../gcc-4.5.0/configure Now if it goes wrong you can just remove the 'build' directory and leave the gcc-4.5.0 source directory untouched. I'm going to close this bug, since it does seem to be user error not a gcc bug. Either use LD_LIBRARY_PATH or re-install the gmp/mpfr/mpc libs from your package manager. If you still have problems, seek help on an Ubuntu forum or the gcc-help mailing list. -- redi at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44714
[Bug rtl-optimization/44722] [4.6 Regression] Bootstrap fails during libjava
--- Comment #5 from rguenth at gcc dot gnu dot org 2010-06-30 11:09 --- Fixed. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44722
[Bug rtl-optimization/44722] [4.6 Regression] Bootstrap fails during libjava
--- Comment #6 from rguenth at gcc dot gnu dot org 2010-06-30 11:10 --- Subject: Bug 44722 Author: rguenth Date: Wed Jun 30 11:09:37 2010 New Revision: 161597 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=161597 Log: 2010-06-30 Richard Guenther rguent...@suse.de PR target/44722 * config/i386/i386.md (peephole2 for fix:SSEMODEI24): Guard against oscillation with reverse peephole2. Modified: trunk/gcc/ChangeLog trunk/gcc/config/i386/i386.md -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44722
[Bug rtl-optimization/44695] [4.6 Regression] ice in simplify_subreg, at simplify-rtx.c:5117
--- Comment #5 from bonzini at gnu dot org 2010-06-30 11:51 --- I agree that the problem is a wrong pattern. Here you have non-matching mode between the udiv/umod and the first argument: (ior:HI (ashift:HI (zero_extend:HI (umod:QI (reg:HI 68) (reg:QI 61 [ D.2750 ]))) (const_int 8 [0x8])) (zero_extend:HI (udiv:QI (reg:HI 68) (reg:QI 61 [ D.2750 ] Instead you need to have this before reload: (set (match_operand:HI register_operand =a) (ior:HI (ashift:HI (zero_extend:HI (umod:QI (match_operand:QI register_operand 0) (match_operand:QI register_operand q))) (const_int 8 [0x8])) (zero_extend:HI (udiv:QI (match_dup 1) (match_dup 2 and after reload split it into a zero/sign extension of al into ax followed by (set (match_dup 0) (ior:HI (ashift:HI (umod:HI (match_dup 0) (zero_extend:HI (match_dup 2))) (const_int 8 [0x8])) (udiv:HI (match_dup 0) (zero_extend:HI (match_dup 2 (or maybe sign extend into eax? QImode-SImode is definitely cheaper for zero extension, I don't know about the cost of cbw because of partial register stalls). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44695
[Bug target/32219] optimizer causes wrong code in pic/hidden/weak symbol checking.
--- Comment #12 from ncopa at alpinelinux dot org 2010-06-30 11:52 --- whats the status on this bug? It still happens on gcc-4.4.4. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32219
[Bug lto/44724] New: LTO segfault
VICE Commodore emulator lto-build fails with a segfault in lto1. The code has both C and C++ source files so it is linked with g++. As compilation fails during lto, it is difficult to produce a self-contained testcase, but you should be able to reproduce the fault by downloading and building VICE http://www.zimmers.net/anonftp/pub/cbm/crossplatform/emulators/VICE/vice-2.2.tar.gz If there is a simple way to produce a smaller testcase for this bug, please let me know. I am using newest binutils from cvs, configured with --enable-gold --enable-plugins $ ld -v GNU gold (GNU Binutils 2.20.51.20100629) 1.9 and gcc from svn 4.5 branch revision 161539. $ g++ -v Using built-in specs. COLLECT_GCC=g++ COLLECT_LTO_WRAPPER=/home/misty/gcc/libexec/gcc/i686-pc-linux-gnu/4.5.1/lto-wrapper Target: i686-pc-linux-gnu Configured with: ../gcc-45branch/configure --prefix=/home/misty/gcc --enable-languages=c,c++ --enable-gold --enable-lto --enable-plugins Thread model: posix gcc version 4.5.1 20100629 (prerelease) (GCC) Link command: g++ -flto -fuse-linker-plugin -O3 -fomit-frame-pointer -march=pentium4 -o x64 alarm.o attach.o autostart.o autostart-prg.o charset.o clkguard.o clipboard.o cmdline.o cbmdos.o cbmimage.o color.o crc32.o datasette.o debug.o dma.o embedded.o emuid.o event.o findpath.o fliplist.o gcr.o info.o init.o initcmdline.o interrupt.o ioutil.o joystick.o kbdbuf.o keyboard.o lib.o libm_math.o lightpen.o log.o machine-bus.o machine.o main.o network.o opencbmlib.o palette.o ram.o rawfile.o resources.o romset.o screenshot.o snapshot.o socket.o sound.o sysfile.o translate.o traps.o util.o vsync.o zfile.o zipcode.o maincpu.o mouse.o midi.o ../src/c64/libc64.a ../src/c64/cart/libc64cart.a ../src/drive/iec/libdriveiec.a ../src/drive/iecieee/libdriveiecieee.a ../src/drive/iec/c64exp/libdriveiecc64exp.a ../src/drive/ieee/libdriveieee.a ../src/drive/libdrive.a ../src/iecbus/libiecbus.a ../src/parallel/libparallel.a ../src/vdrive/libvdrive.a ../src/sid/libsid.a ../src/monitor/libmonitor.a ../src/sounddrv/libsounddrv.a ../src/gfxoutputdrv/libgfxoutputdrv.a ../src/printerdrv/libprinterdrv.a ../src/rs232drv/librs232drv.a ../src/diskimage/libdiskimage.a ../src/fsdevice/libfsdevice.a ../src/tape/libtape.a ../src/imagecontents/libimagecontents.a ../src/fileio/libfileio.a ../src/serial/libserial.a ../src/core/libcore.a ../src/vicii/libvicii.a ../src/raster/libraster.a ../src/video/libvideo.a ../src/arch/unix/libarch.a ../src/arch/unix/gui/libarchgui.a ../src/arch/unix/x11/gnome/libgnomeui.a ../src/arch/unix/x11/libx11ui.a ../src/resid/libresid.a ../src/resid-fp/libresidfp.a -lXrandr -lXxf86vm -pthread -lgtk-x11-2.0 -lgdk-x11-2.0 -latk-1.0 -lgio-2.0 -lpangoft2-1.0 -lgdk_pixbuf-2.0 -lpangocairo-1.0 -lcairo -lpango-1.0 -lfreetype -lfontconfig -lgobject-2.0 -lgmodule-2.0 -lgthread-2.0 -lrt -lglib-2.0 -lasound -lreadline -ljpeg -lgif -lpng -lz -ldl -lbsd -lnsl -lbsd -lm resid-fp.h:32:21: warning: type of residfp_hooks does not match original declaration resid-fp.cc:282:14: note: previously declared here ../../src/interrupt.h:289:14: warning: type of drive_clk does not match original declaration drive.c:131:7: note: previously declared here fastsid.h:33:21: warning: type of fastsid_hooks does not match original declaration fastsid.c:1028:14: note: previously declared here lto1: internal compiler error: Segmentation fault Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html for instructions. lto-wrapper: g++ returned 1 exit status /home/misty/gcc/lib/gcc/i686-pc-linux-gnu/4.5.1/../../../../i686-pc-linux-gnu/bin/ld: fatal error: lto-wrapper failed collect2: ld returned 1 exit status -- Summary: LTO segfault Product: gcc Version: 4.5.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: lto AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: moonshine at kapsi dot fi GCC host triplet: i686-pc-linux-gnu GCC target triplet: i686-pc-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44724
[Bug lto/44724] LTO segfault
--- Comment #1 from moonshine at kapsi dot fi 2010-06-30 12:27 --- (In reply to comment #0) I forgot to add that I configured VICE with a following command: CFLAGS='-flto -fuse-linker-plugin -O3 -fomit-frame-pointer -march=pentium4' CXXFLAGS='-O3 -fomit-frame-pointer -funroll-loops -march=pentium4 -flto -fuse-linker-plugin' ./configure --prefix=/home/misty/gcc --enable-gnomeui --enable-fullscreen; make If you forget --enable-gnomeui, build will fail in my experience, so this is important. -- moonshine at kapsi dot fi changed: What|Removed |Added Summary|LTO segfault|LTO segfault http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44724
[Bug lto/44724] LTO segfault
--- Comment #2 from rguenth at gcc dot gnu dot org 2010-06-30 12:59 --- On the link command-line add -r -nostdlib and start removing as many objects and libraries from the command-line as possible (preserving the crash of course). If static libraries remain, open them up and add/remove individual object files. For the smallest set of object files we need preprocessed source and the command-lines to produce them. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |WAITING http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44724
[Bug tree-optimization/43905] [4.5 Regression] duplicate __PRETTY_FUNCTION__ symbol for functions differing in const-ness
--- Comment #10 from jamborm at gcc dot gnu dot org 2010-06-30 13:27 --- Subject: Bug 43905 Author: jamborm Date: Wed Jun 30 13:26:17 2010 New Revision: 161604 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=161604 Log: 2010-06-30 Martin Jambor mjam...@suse.cz PR tree-optimization/43905 * tree-sra.c (encountered_recursive_call): Removed with all its uses. (convert_callers): Do not handle recursive calls specially. (create_abstract_origin): Removed. (modify_function): Version the call graph node instead of creating abstract origins and dealing with same_body aliases. (ipa_sra_preliminary_function_checks): Check whether the function is versionable. * Makefile.in (tree-sra.o): Add TREE_INLINE_H to dependencies. * testsuite/g++.dg/torture/pr43905.C: New test. Added: branches/gcc-4_5-branch/gcc/testsuite/g++.dg/torture/pr43905.C Modified: branches/gcc-4_5-branch/gcc/ChangeLog branches/gcc-4_5-branch/gcc/Makefile.in branches/gcc-4_5-branch/gcc/testsuite/ChangeLog branches/gcc-4_5-branch/gcc/tree-sra.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43905
[Bug middle-end/44681] usage of macro in loop boundary leads to crash
--- Comment #5 from jd at cococo dot de 2010-06-30 13:43 --- Which is the standard C operator precedence? It should not depend on the dialect. Is there a pragma for it? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44681
[Bug target/43958] FAIL: gcc.dg/ipa/ipa-pta-10.c scan-ipa-dump pta ESCAPED = { }
--- Comment #9 from dave at hiauly1 dot hia dot nrc dot ca 2010-06-30
14:06 ---
Subject: Re: FAIL: gcc.dg/ipa/ipa-pta-10.c scan-ipa-dump pta ESCAPED = { }
Can you, instead of
/* Copied from va-pa.h, but we probably don't need to align to
word size, since we generate and preserve that invariant. */
u = size_int (size 4 ? -8 : -4);
t = fold_convert (sizetype, t);
t = build2 (BIT_AND_EXPR, sizetype, t, u);
t = fold_convert (valist_type, t);
use
u = build_int_cst (TREE_TYPE (t), (HOST_WIDE_INT)(size 4 ? -8 : -4));
t = build2 (BIT_AND_EXPR, TREE_TYPE (t), t, u);
t = fold_convert (valist_type, t);
thus, perform the AND in pointer types? This is what I am going to do
to replace REALIGN_INDIRECT_REF with and teach PTA about this (so to not
pessimize hppa here).
I'll test this change in my next build tonight.
Dave
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43958
[Bug target/43958] FAIL: gcc.dg/ipa/ipa-pta-10.c scan-ipa-dump pta ESCAPED = { }
--- Comment #10 from rguenth at gcc dot gnu dot org 2010-06-30 14:13 --- Created an attachment (id=21043) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21043action=view) additional patch You need the following additional patch. With that the testcase should pass. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43958
[Bug middle-end/44681] usage of macro in loop boundary leads to crash
--- Comment #6 from redi at gcc dot gnu dot org 2010-06-30 14:15 --- (In reply to comment #5) Which is the standard C operator precedence? You can find that for yourself on the web e.g. http://en.wikipedia.org/wiki/Operator_precedence_in_C GCC uses the standard precedence. It should not depend on the dialect. I don't know what you mean. Delphi is based on Pascal, isn't it? Pascal and C are different languages. Is there a pragma for it? Not in GCC. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44681
[Bug tree-optimization/39799] [4.3/4.4/4.5/4.6 Regression] missing 'may be used uninitialized' warning
--- Comment #6 from bernds at gcc dot gnu dot org 2010-06-30 14:17 --- Subject: Bug 39799 Author: bernds Date: Wed Jun 30 14:16:28 2010 New Revision: 161605 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=161605 Log: PR tree-optimization/39799 * tree-inline.c (remap_ssa_name): Initialize variable only if SSA_NAME_OCCURS_IN_ABNORMAL_PHI. testsuite/ PR tree-optimization/39799 * c-c++-common/uninit-17.c: New test. Added: trunk/gcc/testsuite/c-c++-common/uninit-17.c Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/tree-inline.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39799
[Bug other/44034] target hooks are hard to maintain
--- Comment #7 from iains at gcc dot gnu dot org 2010-06-30 14:34 --- Subject: Bug 44034 Author: iains Date: Wed Jun 30 14:33:40 2010 New Revision: 161606 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=161606 Log: PR other/44034 * config/darwin.c (darwin_override_options): Use renamed targetm.asm_out.emit_unwind_label. Modified: trunk/gcc/ChangeLog trunk/gcc/config/darwin.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44034
[Bug c++/44059] Static initializers executed more than once when using unique global symbols
--- Comment #10 from jakub at gcc dot gnu dot org 2010-06-30 15:17 ---
Subject: Bug 44059
Author: jakub
Date: Wed Jun 30 15:16:54 2010
New Revision: 161607
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=161607
Log:
Backport from mainline
2010-05-11 Jakub Jelinek ja...@redhat.com
PR c++/44059
* config/elfos.h (ASM_DECLARE_OBJECT_NAME): Use qnu_unique_object
even for DECL_ONE_ONLY DECL_ARTIFICIAL !TREE_READONLY decls.
* config/alpha/elf.h (ASM_DECLARE_OBJECT_NAME): Likewise.
* dwarf2asm.c (dw2_output_indirect_constant_1): Set TREE_READONLY
on DW.ref.* decls.
Modified:
branches/gcc-4_5-branch/gcc/ChangeLog
branches/gcc-4_5-branch/gcc/config/alpha/elf.h
branches/gcc-4_5-branch/gcc/config/elfos.h
branches/gcc-4_5-branch/gcc/dwarf2asm.c
branches/gcc-4_5-branch/gcc/testsuite/g++.dg/warn/Wconversion-null-2.C
(props changed)
Propchange:
branches/gcc-4_5-branch/gcc/testsuite/g++.dg/warn/Wconversion-null-2.C
('svn:mergeinfo' removed)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44059
[Bug debug/42278] [4.4/4.5 Regression] incorrect dwarf data gcc-4.4.2
--- Comment #4 from jakub at gcc dot gnu dot org 2010-06-30 15:23 --- Subject: Bug 42278 Author: jakub Date: Wed Jun 30 15:23:13 2010 New Revision: 161608 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=161608 Log: Backport from mainline 2010-05-12 Jakub Jelinek ja...@redhat.com PR debug/42278 * dwarf2out.c (base_type_die): Don't add name attribute here. (modified_type_die): Instead of sizetype use its underlying original type. If a DW_TAG_base_type doesn't have name added, add __unknown__. (dwarf2out_imported_module_or_decl_1): Don't call base_type_die, always call force_type_die instead. Modified: branches/gcc-4_5-branch/gcc/ChangeLog branches/gcc-4_5-branch/gcc/dwarf2out.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42278
[Bug c++/44725] New: -pedantic should report gcc extension
in the following example, gcc should report it is using a C++0x extension:
struct ValueInt
{
ValueInt(int v = 0) : ValueLength(v) {}
operator int () const { return ValueLength; }
private:
int ValueLength;
};
int main(int, char *[])
{
int *a = new int[ ValueInt(10) ];
return 0;
}
According to the 98 standard:
implicitly calling the conversion function operator int() is a g++ and C++0x
extension (see
http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_defects.html#299) that is not
in the current C++ standard.
Thanks !
--
Summary: -pedantic should report gcc extension
Product: gcc
Version: 4.6.0
Status: UNCONFIRMED
Severity: minor
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: mathieu dot malaterre at gmail dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44725
[Bug fortran/44702] ISO_C_BINDING does not allow multiple USE, ONLY local names.
--- Comment #1 from burnus at gcc dot gnu dot org 2010-06-30 15:30 --- Cf. also http://fortranwiki.org/fortran/show/c_interface_module (long example). Check that the fix also works with, e.g., IMPORT. (It should!) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44702
[Bug middle-end/43866] [4.3/4.4/4.5 Regression] wrong code with -fbounds-check -funswitch-loops
--- Comment #24 from jakub at gcc dot gnu dot org 2010-06-30 15:34 --- Subject: Bug 43866 Author: jakub Date: Wed Jun 30 15:34:09 2010 New Revision: 161609 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=161609 Log: Backport from mainline 2010-06-25 Jakub Jelinek ja...@redhat.com PR middle-end/43866 * tree-ssa-loop-unswitch.c (tree_may_unswitch_on): If stmt is always true or always false, return NULL_TREE. (tree_unswitch_single_loop): Optimize conditions even when reaching max-unswitch-level parameter. If num 0, optimize first all conditions using entry checks, then do still reachable block discovery and consider only conditions in still reachable basic blocks in the loop. * gfortran.dg/pr43866.f90: New test. Added: branches/gcc-4_5-branch/gcc/testsuite/gfortran.dg/pr43866.f90 - copied unchanged from r161375, trunk/gcc/testsuite/gfortran.dg/pr43866.f90 Modified: branches/gcc-4_5-branch/gcc/ChangeLog branches/gcc-4_5-branch/gcc/testsuite/ChangeLog branches/gcc-4_5-branch/gcc/tree-ssa-loop-unswitch.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43866
[Bug bootstrap/44726] New: [4.6 Regression] Yet another broken bootstrap
At revision 161606, bootstrap fails with:
...
/opt/gcc/build_w/./prev-gcc/xgcc -B/opt/gcc/build_w/./prev-gcc/
-B/opt/gcc/gcc4.6w/x86_64-apple-darwin10.4.0/bin/
-B/opt/gcc/gcc4.6w/x86_64-apple-darwin10.4.0/bin/
-B/opt/gcc/gcc4.6w/x86_64-apple-darwin10.4.0/lib/ -isystem
/opt/gcc/gcc4.6w/x86_64-apple-darwin10.4.0/include -isystem
/opt/gcc/gcc4.6w/x86_64-apple-darwin10.4.0/sys-include-c -g -O2 -gtoggle
-DIN_GCC -W -Wall -Wwrite-strings -Wcast-qual -Wstrict-prototypes
-Wmissing-prototypes -Wmissing-format-attribute -pedantic -Wno-long-long
-Wno-variadic-macros -Wno-overlength-strings -Werror -Wold-style-definition
-Wc++-compat -fno-common -DHAVE_CONFIG_H -I. -I. -I../../work/gcc
-I../../work/gcc/. -I../../work/gcc/../include
-I../../work/gcc/../libcpp/include -I/opt/sw64/include
-I../../work/gcc/../libdecnumber -I../../work/gcc/../libdecnumber/dpd
-I../libdecnumber -I/opt/sw64/include -DCLOOG_PPL_BACKEND
-I/opt/sw64/include ../../work/gcc/graphite-sese-to-poly.c -o
graphite-sese-to-poly.o
/opt/gcc/build_w/./prev-gcc/xgcc -B/opt/gcc/build_w/./prev-gcc/
-B/opt/gcc/gcc4.6w/x86_64-apple-darwin10.4.0/bin/
-B/opt/gcc/gcc4.6w/x86_64-apple-darwin10.4.0/bin/
-B/opt/gcc/gcc4.6w/x86_64-apple-darwin10.4.0/lib/ -isystem
/opt/gcc/gcc4.6w/x86_64-apple-darwin10.4.0/include -isystem
/opt/gcc/gcc4.6w/x86_64-apple-darwin10.4.0/sys-include-c -g -O2 -gtoggle
-DIN_GCC -W -Wall -Wwrite-strings -Wcast-qual -Wstrict-prototypes
-Wmissing-prototypes -Wmissing-format-attribute -pedantic -Wno-long-long
-Wno-variadic-macros -Wno-overlength-strings -Werror -Wold-style-definition
-Wc++-compat -fno-common -DHAVE_CONFIG_H -I. -I. -I../../work/gcc
-I../../work/gcc/. -I../../work/gcc/../include
-I../../work/gcc/../libcpp/include -I/opt/sw64/include
-I../../work/gcc/../libdecnumber -I../../work/gcc/../libdecnumber/dpd
-I../libdecnumber -I/opt/sw64/include -DCLOOG_PPL_BACKEND
-I/opt/sw64/include gtype-desc.c -o gtype-desc.o
../../work/gcc/graphite-sese-to-poly.c: In function 'build_scop_drs.isra.110':
../../work/gcc/graphite-sese-to-poly.c:1784:15: error: 'dr_base_object_set' may
be used uninitialized in this function [-Werror=uninitialized]
../../work/gcc/graphite-sese-to-poly.c:1765:7: note: 'dr_base_object_set' was
declared here
../../work/gcc/graphite-sese-to-poly.c:2008:25: error: 'bap' may be used
uninitialized in this function [-Werror=uninitialized]
../../work/gcc/graphite-sese-to-poly.c:2003:24: note: 'bap' was declared here
../../work/gcc/graphite-sese-to-poly.c:1929:22: error: 'bap' may be used
uninitialized in this function [-Werror=uninitialized]
../../work/gcc/graphite-sese-to-poly.c:1924:24: note: 'bap' was declared here
cc1: all warnings being treated as errors
I have reached stage 3 with the following uneducated patch:
--- /opt/gcc/_clean/gcc/graphite-sese-to-poly.c 2010-06-10 00:11:15.0
+0200
+++ /opt/gcc/work/gcc/graphite-sese-to-poly.c 2010-06-30 17:18:25.0
+0200
@@ -1762,7 +1762,7 @@ build_poly_dr (data_reference_p dr, poly
ppl_Pointset_Powerset_C_Polyhedron_t accesses_ps;
ppl_dimension_type dom_nb_dims;
ppl_dimension_type accessp_nb_dims;
- int dr_base_object_set;
+ int dr_base_object_set = 0;
ppl_Pointset_Powerset_C_Polyhedron_space_dimension (PBB_DOMAIN (pbb),
dom_nb_dims);
@@ -1921,7 +1921,7 @@ build_alias_set_optimal_p (VEC (data_ref
for (i = 0; i g-n_vertices; i++)
{
data_reference_p dr = VEC_index (data_reference_p, drs, i);
- base_alias_pair *bap;
+ base_alias_pair *bap = NULL;
if (dr-aux)
bap = (base_alias_pair *)(dr-aux);
@@ -2000,7 +2000,7 @@ build_base_obj_set_for_drs (VEC (data_re
for (i = 0; i g-n_vertices; i++)
{
data_reference_p dr = VEC_index (data_reference_p, drs, i);
- base_alias_pair *bap;
+ base_alias_pair *bap = NULL;
if (dr-aux)
bap = (base_alias_pair *)(dr-aux);
--
Summary: [4.6 Regression] Yet another broken bootstrap
Product: gcc
Version: 4.6.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: bootstrap
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: dominiq at lps dot ens dot fr
GCC build triplet: x86_64-apple-darwin10.4.0
GCC host triplet: x86_64-apple-darwin10.4.0
GCC target triplet: x86_64-apple-darwin10.4.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44726
[Bug debug/44694] [4.5 Regression] Long var tracking compile time of GiNaC tests
--- Comment #11 from jakub at gcc dot gnu dot org 2010-06-30 15:41 --- Subject: Bug 44694 Author: jakub Date: Wed Jun 30 15:40:53 2010 New Revision: 161610 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=161610 Log: Backport from mainline 2010-06-30 Jakub Jelinek ja...@redhat.com PR debug/44694 * cselib.h (cselib_preserve_cfa_base_value): Add regno argument. * cselib.c (cfa_base_preserved_regno): New static variable. (cselib_reset_table): Don't reset cfa_base_preserved_regno instead of REGNO (cfa_base_preserved_val-locs-loc). (cselib_preserve_cfa_base_value): Add regno argument, set cfa_base_preserved_regno to it. (cselib_invalidate_regno): Allow removal of registers other than cfa_base_preserved_regno from cfa_base_preserved_val. (cselib_finish): Set cfa_base_preserved_regno to INVALID_REGNUM. * var-tracking.c (adjust_mems): Replace sp or hfp even outside of MEM addresses, if not on LHS. (reverse_op): Don't add reverse ops for cfa_base_rtx. (vt_init_cfa_base): Adjust cselib_preserve_cfa_base_value caller. Modified: branches/gcc-4_5-branch/gcc/ChangeLog branches/gcc-4_5-branch/gcc/cselib.c branches/gcc-4_5-branch/gcc/cselib.h branches/gcc-4_5-branch/gcc/var-tracking.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44694
[Bug bootstrap/44727] New: [4.6 Regression] Failed to bootstrap with --with-cpu=atom
On Linux/x86-64, revision 161604 failed to bootstrap with --with-cpu=atom. I got Premature end of .class file ../../../../src-trunk/libjava/classpath/lib/java/lang/AbstractStringBuffer.class. Revision 161569 is OK. It could be related to peephole change. -- Summary: [4.6 Regression] Failed to bootstrap with --with- cpu=atom Product: gcc Version: 4.6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: bootstrap AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: hjl dot tools at gmail dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44727
[Bug bootstrap/44727] [4.6 Regression] Failed to bootstrap with --with-cpu=atom
-- hjl dot tools at gmail dot com changed: What|Removed |Added Target Milestone|--- |4.6.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44727
[Bug gcov-profile/44728] New: gcov chokes when . is present in DIR argument to -o flag
When trying to specify a directory that contains a . for gcov to look in for output files, gcov does not act as expected. Example: /home/test$ gcc-4.3 main.c -fprofile-arcs -ftest-coverage /home/test$ ./a.out /home/test$ gcov-4.3 -o/home/test/ main expected output /home/test$ mkdir 1.1; cp main.c 1.1; cd 1.1 /home/test/1.1$ gcc-4.3 main.c -fprofile-arcs -ftest-coverage /home/test/1.1$ ./a.out /home/test/1.1$ gcov-4.3 -o/home/test/1.1/ main /home/test/1.gcno:cannot open graph file I'm guessing that gcov is mistaking the DIR argument for the FILE argument to the -o flag. gcov-4.3 --help -o, --object-directory DIR|FILE Search for object files in DIR or called FILE -- Summary: gcov chokes when . is present in DIR argument to -o flag Product: gcc Version: 4.3.3 Status: UNCONFIRMED Severity: normal Priority: P3 Component: gcov-profile AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: ajshower at gmail dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44728
[Bug tree-optimization/44562] [4.6 Regression] ICE: in get_alias_set, at alias.c:716 with -flto -fstrict-aliasing -fgraphite-identity
--- Comment #4 from jamborm at gcc dot gnu dot org 2010-06-30 15:54 --- Created an attachment (id=21044) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21044action=view) Another testcase. I believe I ran into this bug when trying WHOPR bootstrap at -O3 (on x86_64-linux). I narrowed it down to this piece of preprocessed source. To reproduce, compile with: gcc -O3 -g -fuse-linker-plugin -fwhopr -c step2.i The bug does not occur at -O2. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44562
[Bug middle-end/44729] New: [4.5/4.6 regression] One bison 2.4.2 test failed
On Linux/x86, gcc 4.5/4.6 failed one bison 2.4.2 test: 81: Action synch line FAILED (synclines.at:144) Gcc 4.4 is OK. -- Summary: [4.5/4.6 regression] One bison 2.4.2 test failed Product: gcc Version: 4.5.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: middle-end AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: hjl dot tools at gmail dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44729
[Bug bootstrap/44730] New: [4.6 Regression] Failed to bootstrap due to uninitialized error
On Linux/x86-64, revision 161606 gave:
../../src-trunk/gcc/graphite-sese-to-poly.c: In function
'build_scop_drs.isra.110':
../../src-trunk/gcc/graphite-sese-to-poly.c:1784:15: error:
'dr_base_object_set' may be used uninitialized in this function
[-Werror=uninitialized]
../../src-trunk/gcc/graphite-sese-to-poly.c:1765:7: note: 'dr_base_object_set'
was declared here
../../src-trunk/gcc/graphite-sese-to-poly.c:2008:25: error: 'bap' may be used
uninitialized in this function [-Werror=uninitialized]
../../src-trunk/gcc/graphite-sese-to-poly.c:2003:24: note: 'bap' was declared
here
../../src-trunk/gcc/graphite-sese-to-poly.c:1929:22: error: 'bap' may be used
uninitialized in this function [-Werror=uninitialized]
../../src-trunk/gcc/graphite-sese-to-poly.c:1924:24: note: 'bap' was declared
here
cc1: all warnings being treated as errors
I saw
2000 for (i = 0; i g-n_vertices; i++)
2001 {
2002 data_reference_p dr = VEC_index (data_reference_p, drs, i);
2003 base_alias_pair *bap;
2004
2005 if (dr-aux)
2006 bap = (base_alias_pair *)(dr-aux);
2007
2008 bap-base_obj_set = g-vertices[i].component + 1;
2009 }
--
Summary: [4.6 Regression] Failed to bootstrap due to
uninitialized error
Product: gcc
Version: 4.5.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: bootstrap
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: hjl dot tools at gmail dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44730
[Bug bootstrap/44730] [4.6 Regression] Failed to bootstrap due to uninitialized error
-- hjl dot tools at gmail dot com changed: What|Removed |Added Target Milestone|--- |4.6.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44730
[Bug bootstrap/44726] [4.6 Regression] Yet another broken bootstrap
--- Comment #1 from spop at gcc dot gnu dot org 2010-06-30 16:11 --- Mine. Let's transform this code: base_alias_pair *bap; if (dr-aux) bap = (base_alias_pair *)(dr-aux); into: base_alias_pair *bap; gcc_assert (dr-aux); bap = (base_alias_pair *)(dr-aux); -- spop at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |spop at gcc dot gnu dot org |dot org | Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2010-06-30 16:11:19 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44726
[Bug bootstrap/44730] [4.6 Regression] Failed to bootstrap due to uninitialized error
--- Comment #1 from hjl dot tools at gmail dot com 2010-06-30 16:15 ---
This makes it to compile:
--
diff --git a/gcc/graphite-sese-to-poly.c b/gcc/graphite-sese-to-poly.c
index b73517d..c3890ec 100644
--- a/gcc/graphite-sese-to-poly.c
+++ b/gcc/graphite-sese-to-poly.c
@@ -1779,10 +1779,12 @@ build_poly_dr (data_reference_p dr, poly_bb_p pbb)
ppl_delete_Polyhedron (accesses);
if (dr-aux)
-dr_base_object_set = ((base_alias_pair *)(dr-aux))-base_obj_set;
-
- new_poly_dr (pbb, dr_base_object_set, accesses_ps, DR_IS_READ (dr) ?
PDR_READ : PDR_WRITE,
- dr, DR_NUM_DIMENSIONS (dr));
+{
+ dr_base_object_set = ((base_alias_pair *)(dr-aux))-base_obj_set;
+ new_poly_dr (pbb, dr_base_object_set, accesses_ps,
+ DR_IS_READ (dr) ? PDR_READ : PDR_WRITE,
+ dr, DR_NUM_DIMENSIONS (dr));
+}
}
/* Write to FILE the alias graph of data references in DIMACS format. */
@@ -1921,13 +1923,12 @@ build_alias_set_optimal_p (VEC (data_reference_p, heap)
*drs)
for (i = 0; i g-n_vertices; i++)
{
data_reference_p dr = VEC_index (data_reference_p, drs, i);
- base_alias_pair *bap;
-
if (dr-aux)
- bap = (base_alias_pair *)(dr-aux);
-
- bap-alias_set = XNEW (int);
- *(bap-alias_set) = g-vertices[i].component + 1;
+ {
+ base_alias_pair *bap = (base_alias_pair *)(dr-aux);
+ bap-alias_set = XNEW (int);
+ *(bap-alias_set) = g-vertices[i].component + 1;
+ }
}
/* Verify if the DFS numbering results in optimal solution. */
@@ -2000,12 +2001,11 @@ build_base_obj_set_for_drs (VEC (data_reference_p,
heap) *drs)
for (i = 0; i g-n_vertices; i++)
{
data_reference_p dr = VEC_index (data_reference_p, drs, i);
- base_alias_pair *bap;
-
if (dr-aux)
- bap = (base_alias_pair *)(dr-aux);
-
- bap-base_obj_set = g-vertices[i].component + 1;
+ {
+ base_alias_pair *bap = (base_alias_pair *)(dr-aux);
+ bap-base_obj_set = g-vertices[i].component + 1;
+ }
}
free (queue);
---
But I don't know if it is correct.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44730
[Bug bootstrap/44730] [4.6 Regression] Failed to bootstrap due to uninitialized error
--- Comment #2 from dominiq at lps dot ens dot fr 2010-06-30 16:16 --- This is a duplicate of pr44726. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44730
[Bug bootstrap/44726] [4.6 Regression] Yet another broken bootstrap
--- Comment #2 from hjl dot tools at gmail dot com 2010-06-30 16:19 --- *** Bug 44730 has been marked as a duplicate of this bug. *** -- hjl dot tools at gmail dot com changed: What|Removed |Added CC||hjl dot tools at gmail dot ||com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44726
[Bug bootstrap/44730] [4.6 Regression] Failed to bootstrap due to uninitialized error
--- Comment #3 from hjl dot tools at gmail dot com 2010-06-30 16:19 --- *** This bug has been marked as a duplicate of 44726 *** -- hjl dot tools at gmail dot com changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44730
[Bug bootstrap/44726] [4.6 Regression] Yet another broken bootstrap
-- hjl dot tools at gmail dot com changed: What|Removed |Added Target Milestone|--- |4.6.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44726
[Bug c++/44731] New: Return value optimization produces inaccurate debug info
Source file (no preprocessing required): (note, I made it C-compatible so I
could see if the bug is present in the C compiler as well, the answer being no,
for reasons that will become obvious immediately)
struct st{
int n;
};
struct st f(struct st x)
{
struct st z;
z=x;
z.n++;
return z;
}
int main()
{
struct st c;
c.n=1234;
f(c);
return 0;
}
Terminal session:
br...@bbi5291-laptop:~/programs/Other$ g++ -v
Using built-in specs.
COLLECT_GCC=g++
COLLECT_LTO_WRAPPER=/usr/local/libexec/gcc/i686-pc-linux-gnu/4.5.0/lto-wrapper
Target: i686-pc-linux-gnu
Configured with: ./configure
Thread model: posix
gcc version 4.5.0 (GCC)
br...@bbi5291-laptop:~/programs/Other$ g++ -g bug.c
br...@bbi5291-laptop:~/programs/Other$ gdb a.out
GNU gdb 6.8-debian
Copyright (C) 2008 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later http://gnu.org/licenses/gpl.html
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law. Type show copying
and show warranty for details.
This GDB was configured as i486-linux-gnu...
(gdb) break 8
Breakpoint 1 at 0x80483d2: file bug.c, line 8.
(gdb) run
Starting program: /home/brian/programs/Other/a.out
Breakpoint 1, f (x={n = 1234}) at bug.c:8
8 z.n++;
Current language: auto; currently c++
(gdb) print z.n
$1 = 2424820
(gdb) q
The program is running. Exit anyway? (y or n) y
br...@bbi5291-laptop:~/programs/Other$ g++ -g -fno-elide-constructors bug.c
br...@bbi5291-laptop:~/programs/Other$ gdb a.out
GNU gdb 6.8-debian
Copyright (C) 2008 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later http://gnu.org/licenses/gpl.html
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law. Type show copying
and show warranty for details.
This GDB was configured as i486-linux-gnu...
(gdb) break 8
Breakpoint 1 at 0x80483e0: file bug.c, line 8.
(gdb) run
Starting program: /home/brian/programs/Other/a.out
Breakpoint 1, f (x={n = 1234}) at bug.c:8
8 z.n++;
Current language: auto; currently c++
(gdb) print z.n
$1 = 1234
(gdb) q
The program is running. Exit anyway? (y or n) y
br...@bbi5291-laptop:~/programs/Other$
It is evident to me from these test runs that a bug in the return value
optimization is causing the wrong address for the variable z (since this is
presumably elided altogether when the optimization is used) to be reported in
the debug information. I first noticed this bug in g++ 4.4.1, and installed g++
4.5.0 and found that it was there too; it does not occur in g++ 4.3.4 or
earlier.
--
Summary: Return value optimization produces inaccurate debug info
Product: gcc
Version: 4.5.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: bbi5291 at gmail dot com
GCC build triplet: i686-pc-linux-gnu
GCC host triplet: i686-pc-linux-gnu
GCC target triplet: i686-pc-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44731
[Bug bootstrap/44699] [4.6 Regression] Bootstrap failure for x86_64-apple-darwin10: ICE while compiling genmodes.c
--- Comment #16 from matz at gcc dot gnu dot org 2010-06-30 16:34 --- Subject: Bug 44699 Author: matz Date: Wed Jun 30 16:34:22 2010 New Revision: 161614 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=161614 Log: PR bootstrap/44699 * tree-vrp.c (vrp_finalize): Deal with changing num_ssa_names. * gimple-fold.c (gimplify_and_update_call_from_tree): If LHS is a gimple reg, attach the original VDEF to the last store in the sequence. testsuite/ PR bootstrap/44699 * gcc.dg/pr44699.c: New test. Added: trunk/gcc/testsuite/gcc.dg/pr44699.c Modified: trunk/gcc/ChangeLog trunk/gcc/gimple-fold.c trunk/gcc/testsuite/ChangeLog trunk/gcc/tree-vrp.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44699
[Bug bootstrap/44720] [4.6 Regression] Yet another bootstrap failure on x86_64-apple-darwin10
--- Comment #2 from dominiq at lps dot ens dot fr 2010-06-30 16:41 --- Subject: Bug 44034 Author: iains Date: Wed Jun 30 14:33:40 2010 New Revision: 161606 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=161606 Log: PR other/44034 * config/darwin.c (darwin_override_options): Use renamed targetm.asm_out.emit_unwind_label. Modified: trunk/gcc/ChangeLog trunk/gcc/config/darwin.c -- dominiq at lps dot ens dot fr changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44720
