About -fstack-protector in mips
Hello I would like to use -fstack-protector in mips. But mips stack protector seems not to be supported. I think that the macro FRAME_GROWS_DOWNWARD should be defined for stack protector working. And mips does'nt define this macro. To define this macro, the addresses of local variable slots are at negative offsets from the frame pointer. (This info is from gccint.pdf) Although mips cpu seems to meet this requirement, just defining this macro doesn't makes stack-protector work certainly on mips. (This definition makes lots of testsuite fail on mips...) Could you tell me why it doesn't work well around FRAME_GROWS_DOWNWARD on mips ? Thank you. --- Yoriko Komatsuzaki (yor...@sm.sony.co.jp)
Re: Plugin API Comments (was Re: GCC Plug-in Framework ready to port)
On Tue, 2009-02-03 at 01:59 -0500, Sean Callanan wrote: Our plugins do not break when switching compiler binaries. In fact, I have had plug-in binaries that perform very simple tasks work fine when switching (minor!) compiler releases. Thinking about this made me realise that the plugin framework will require special consideration for utilities like ccache and distcc. ccache checksums (or at least stats) the cc1 binary to decide whether a cached object file is valid. If you change a plugin, the cc1 binary won't change, but the generated code probably will. Ben
Re: ARM compiler generating never-used constant data structures
On Wed, Feb 4, 2009 at 11:05 PM, Zoltán Kócsi zol...@bendor.com.au wrote: [cut] If I compile the above with -O2 or -Os, then if the target is AVR or x86_64 then the result is what I expected, func() just loads 3 or 12345 then returns and that's all. There is no .rodata generated. However, compiling for the ARM generates the same function code, but it also generates the image of things in the .rodata segment. Twice. Even when it stores 12345 separatelly. The code never actually references any of them and they are not global thus it is just wasted memory: I think it's relevant to ask this: Are you comparing against the same gcc release on all the three architectures you mention?
Re: ARM compiler generating never-used constant data structures
On Thu, 5 Feb 2009 10:58:40 -0200 Alexandre Pereira Nunes alexandre.nu...@gmail.com wrote: On Wed, Feb 4, 2009 at 11:05 PM, Zoltán Kócsi zol...@bendor.com.au wrote: [cut] If I compile the above with -O2 or -Os, then if the target is AVR or x86_64 then the result is what I expected, func() just loads 3 or 12345 then returns and that's all. There is no .rodata generated. However, compiling for the ARM generates the same function code, but it also generates the image of things in the .rodata segment. Twice. Even when it stores 12345 separatelly. The code never actually references any of them and they are not global thus it is just wasted memory: I think it's relevant to ask this: Are you comparing against the same gcc release on all the three architectures you mention? Almost the same: x86_64: 4.0.2 AVR:4.0.1 ARM:4.0.2 So, at least the Intel and the ARM are the same yet the Intel version omits the .rodata, the ARM keeps it. I'll check it with the newer version next week. However, I tend to use the 4.0.x because at least for the ARM it generates smaller code from the same source than the newer versions when optimising with -Os. Zoltan
Re: Inline limits
For -Os it should be enough to set PARAM_STACK_FRAME_GROWTH to zero. Inlining at -Os should already only happen if it decreases (overall!) code-size. Thus, inlining a function that is called once and that does not need to be emitted will always be an overall code-size win. A side question... Are 'static' single call-site functions always inlined? I would hope not (under -Os), but just checking. Yes. This is always a code-size win. Should be, but in practice isn't. On Thumb-2 we found that the overhead of a function call was often smaller than the cost of lengthening branches in the caller. It turns out that, over a fair selection of applications, programmers tend to write nice sized functions. After inlining we have big nasty blocks of code that exceed the range of a short branch instruction. Of course a sufficiently smart reordering pass should be able to fix this by out-of-lining the big block of code. I'm pretty sure gcc can't currently do this. Paul
Re: Inline limits
On Thumb-2 we found that the overhead of a function call was often smaller than the cost of lengthening branches in the caller. It turns out that, over a fair selection of applications, programmers tend to write nice sized functions. After inlining we have big nasty blocks of code that exceed the range of a short branch instruction. Of course a sufficiently smart reordering pass should be able to fix this by out-of-lining the big block of code. I'm pretty sure gcc can't currently do this. Hmm, we should be able to model this counting the number of edges bypassing the call, right? Something like that, yes. Ideally you'd want to factor in the size of the function, and the current length of those edges, at which point you've probably got sufficient information to make bb-reorder fix the problem once and for all ;-) Paul
Re: Inline limits
On Thu, Feb 5, 2009 at 3:04 PM, Paul Brook p...@codesourcery.com wrote: Hmm, we should be able to model this counting the number of edges bypassing the call, right? Something like that, yes. Ideally you'd want to factor in the size of the function, and the current length of those edges, at which point you've probably got sufficient information to make bb-reorder fix the problem once and for all ;-) I haven't read the thread in full, so maybe someone already mentioned it... You do know bb-reorder is completely disabled for -Os, right? Gr. Steven
Re: ARM compiler generating never-used constant data structures
On Fri, Feb 06, 2009 at 12:30:13AM +1100, Zoltán Kócsi wrote: Almost the same: x86_64: 4.0.2 AVR:4.0.1 ARM:4.0.2 So, at least the Intel and the ARM are the same yet the Intel version omits the .rodata, the ARM keeps it. I'll check it with the newer version next week. However, I tend to use the 4.0.x because at least for the ARM it generates smaller code from the same source than the newer versions when optimising with -Os. Still, there's not much help people can give you with old versions. If you have any test cases where 4.0.2 gives smaller code with -Os than a 4.4 snapshot, please, file them in bugzilla. -- Daniel Jacobowitz CodeSourcery
Re: Plugin API Comments (was Re: GCC Plug-in Framework ready to port)
On Thu, Feb 5, 2009 at 5:59 AM, Ben Elliston b...@au1.ibm.com wrote: On Tue, 2009-02-03 at 01:59 -0500, Sean Callanan wrote: Our plugins do not break when switching compiler binaries. In fact, I have had plug-in binaries that perform very simple tasks work fine when switching (minor!) compiler releases. Thinking about this made me realise that the plugin framework will require special consideration for utilities like ccache and distcc. ccache checksums (or at least stats) the cc1 binary to decide whether a cached object file is valid. If you change a plugin, the cc1 binary won't change, but the generated code probably will. Why not use the output of cc1 --version, and then have the loaded plugins listed there. (This also means bug reports should have the plugins listed assuming the user uses the same command line with --version tacked on)
Re: About -fstack-protector in mips
Yoriko Komatsuzaki yor...@sm.sony.co.jp writes:
Could you tell me why it doesn't work well around FRAME_GROWS_DOWNWARD
on mips ?
I have a WIP patch for this but was holding back mostly because of stage3/4
and that I was trying to make FRAME_GROWS_DOWNWARD the default and I was
running into performance issues.
The patch below enables FRAME_GROWS_DOWNWARD with -mframe-grows-downward
(mostly for testing) and with -fstack-protector.
Adam
Index: config/mips/mips.opt
===
--- config/mips/mips.opt(revision 142249)
+++ config/mips/mips.opt(working copy)
@@ -283,3 +283,6 @@ Perform VR4130-specific alignment optimi
mxgot
Target Report Var(TARGET_XGOT)
Lift restrictions on GOT size
+
+mframe-grows-downward
+Target Var(flag_frame_grows_downward) Init(1)
Index: config/mips/mips.c
===
--- config/mips/mips.c (revision 142249)
+++ config/mips/mips.c (working copy)
@@ -274,10 +274,10 @@ struct mips_frame_info GTY(()) {
HOST_WIDE_INT gp_sp_offset;
HOST_WIDE_INT fp_sp_offset;
- /* The offset of arg_pointer_rtx from frame_pointer_rtx. */
+ /* The offset of arg_pointer_rtx from the bottom of the frame. */
HOST_WIDE_INT arg_pointer_offset;
- /* The offset of hard_frame_pointer_rtx from frame_pointer_rtx. */
+ /* The offset of hard_frame_pointer_rtx from the bottom of the frame. */
HOST_WIDE_INT hard_frame_pointer_offset;
};
@@ -8593,10 +8593,9 @@ mips_compute_frame_info (void)
cfun-machine-global_pointer = mips_global_pointer ();
- /* The first STARTING_FRAME_OFFSET bytes contain the outgoing argument
- area and the $gp save slot. This area isn't needed in leaf functions,
- but if the target-independent frame size is nonzero, we're committed
- to allocating it anyway. */
+ /* The first bytes contain the outgoing argument area and the $gp save slot.
+ This area isn't needed in leaf functions, but if the target-independent
+ frame size is nonzero, we're committed to allocating it anyway. */
if (size == 0 current_function_is_leaf)
{
/* The MIPS 3.0 linker does not like functions that dynamically
@@ -8612,7 +8611,7 @@ mips_compute_frame_info (void)
else
{
frame-args_size = crtl-outgoing_args_size;
- frame-cprestore_size = STARTING_FRAME_OFFSET - frame-args_size;
+ frame-cprestore_size = MIPS_GP_SAVE_AREA_SIZE;
}
offset = frame-args_size + frame-cprestore_size;
@@ -8746,12 +8745,16 @@ mips_initial_elimination_offset (int fro
mips_compute_frame_info ();
- /* Set OFFSET to the offset from the soft frame pointer, which is also
- the offset from the end-of-prologue stack pointer. */
+ /* Set OFFSET to the offset from the end-of-prologue stack pointer. */
switch (from)
{
case FRAME_POINTER_REGNUM:
- offset = 0;
+ if (FRAME_GROWS_DOWNWARD)
+ offset = (cfun-machine-frame.args_size
+ + cfun-machine-frame.cprestore_size
+ + cfun-machine-frame.var_size);
+ else
+ offset = 0;
break;
case ARG_POINTER_REGNUM:
Index: config/mips/mips.h
===
--- config/mips/mips.h (revision 142249)
+++ config/mips/mips.h (working copy)
@@ -2035,14 +2035,20 @@ enum reg_class
/* Stack layout; function entry, exit and calling. */
+#define FRAME_GROWS_DOWNWARD (flag_frame_grows_downward || flag_stack_protect)
+
#define STACK_GROWS_DOWNWARD
-/* The offset of the first local variable from the beginning of the frame.
- See mips_compute_frame_info for details about the frame layout. */
+#define MIPS_GP_SAVE_AREA_SIZE \
+ (TARGET_CALL_CLOBBERED_GP ? MIPS_STACK_ALIGN (UNITS_PER_WORD) : 0)
+
+/* The offset of the first local variable from the frame pointer. See
+ mips_compute_frame_info for details about the frame layout. */
-#define STARTING_FRAME_OFFSET \
- (crtl-outgoing_args_size\
- + (TARGET_CALL_CLOBBERED_GP ? MIPS_STACK_ALIGN (UNITS_PER_WORD) : 0))
+#define STARTING_FRAME_OFFSET \
+ (FRAME_GROWS_DOWNWARD\
+ ? 0 \
+ : crtl-outgoing_args_size + MIPS_GP_SAVE_AREA_SIZE)
#define RETURN_ADDR_RTX mips_return_addr
Re: GCC for mipsel-unknown-linux-gnu state on 4.3 and 4.4?
On Sun, 2009-02-01 at 22:45 +0100, Laurent GUERBY wrote: Thanks for the link! This confirms that all pch test fail on mipsel, from the first to the last log available on your site: http://people.debian.org/~doko/tmp/gcc-mips/gcc-snapshot_20080523-1_mipsel.bz2 http://people.debian.org/~doko/tmp/gcc-mips/gcc-snapshot_20090107-1_mipsel.bz2 FAIL: ./common-1.h -O0 -g (test for excess errors) FAIL: gcc.dg/pch/common-1.c -O0 -g FAIL: gcc.dg/pch/common-1.c -O0 -g assembly comparison FAIL: ./common-1.h -O0 (test for excess errors) FAIL: gcc.dg/pch/common-1.c -O0 FAIL: gcc.dg/pch/common-1.c -O0 assembly comparison ... Whereas they don't fail for 4.3. I opened: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39071 I just closed it, something between 143818 and 143942 fixed it: http://gcc.gnu.org/ml/gcc-testresults/2009-02/msg00541.html I assume this will show up on your build soon. Laurent
Constant folding and Constant propagation
Dear all, I'm currently working on removing the constant folding and constant propagation because, on the architecture I'm working on, it is highly costly to move a constant into a register if the number is big (we can say over 16 bits). Currently, I've been looking into this and it seems that I have to hack into the fold-const.c file, CCP, SCCVN and probably the propagate passes to tell the compiler to be careful if the number is too big. But I'm sure there are many other places I'll have to hack and slash to tell him to stop the folding and propagation. Is there an easier way to do this ? I've been looking at what happens for the Itanium since you'd have the same problem if you had to use big numbers. You would in theory prefer to not use too many move long instructions since they use two slots in the bundle. But I fail to see if anything is really done in that respect. Thanks for your help, Jean Christophe Beyler
Re: Constant folding and Constant propagation
On Thu, Feb 05, 2009 at 12:34:14PM -0800, Jean Christophe Beyler wrote: I'm currently working on removing the constant folding and constant propagation because, on the architecture I'm working on, it is highly costly to move a constant into a register if the number is big (we can say over 16 bits). But in practice most constants that cprop deals with are values like -1, 0, 1, or 2. Wouldn't it be better to be able to constrain cprop based on the values of the constants, than to eliminate it altogether?
Re: Constant folding and Constant propagation
On Thu, Feb 05, 2009 at 12:46:01PM -0800, Joe Buck wrote: On Thu, Feb 05, 2009 at 12:34:14PM -0800, Jean Christophe Beyler wrote: I'm currently working on removing the constant folding and constant propagation because, on the architecture I'm working on, it is highly costly to move a constant into a register if the number is big (we can say over 16 bits). But in practice most constants that cprop deals with are values like -1, 0, 1, or 2. Wouldn't it be better to be able to constrain cprop based on the values of the constants, than to eliminate it altogether? I shouldn't have said most, but small constants are common.
Re: Constant folding and Constant propagation
True but what I've noticed with GCC 4.3.2 is that with this code:
#include stdio.h
#include stdlib.h
int main(void)
{
long a = 0xcafecafe;
printf(Final: %lx %lx %lx\n, a, a+5, a+15);
return EXIT_SUCCESS;
}
Whether I compile it with a big number like here or a smaller number,
I'll get something like:
la r8,$LC0 #Loading the address of
Final: %lx %lx %lx\n
lid r9,0xcafecafe#Loading the first immediate
lid r10,0xcafecb03 #Loading the second immediate
lid r11,0xcafecb0d #Loading the third immediate
But in my case, the lid is very costly for this large number. It would
be more efficient to have:
la r8,$LC0 #Loading the address of
Final: %lx %lx %lx\n
lid r9,0xcafecafe#Loading the first immediate
addi r10,r9,0x5 #Loading the second immediate
addi r11,r9,0xf #Loading the third immediate
So my question is, can I explain this in the machine description alone
and if so, does anybody know where?
Thanks again,
Jean Christophe Beyler
On Thu, Feb 5, 2009 at 4:02 PM, Joe Buck joe.b...@synopsys.com wrote:
On Thu, Feb 05, 2009 at 12:46:01PM -0800, Joe Buck wrote:
On Thu, Feb 05, 2009 at 12:34:14PM -0800, Jean Christophe Beyler wrote:
I'm currently working on removing the constant folding and constant
propagation because, on the architecture I'm working on, it is highly
costly to move a constant into a register if the number is big (we can
say over 16 bits).
But in practice most constants that cprop deals with are values like
-1, 0, 1, or 2. Wouldn't it be better to be able to constrain cprop
based on the values of the constants, than to eliminate it altogether?
I shouldn't have said most, but small constants are common.
Re: Constant folding and Constant propagation
Jean Christophe Beyler jean.christophe.bey...@gmail.com writes: I'm currently working on removing the constant folding and constant propagation because, on the architecture I'm working on, it is highly costly to move a constant into a register if the number is big (we can say over 16 bits). Currently, I've been looking into this and it seems that I have to hack into the fold-const.c file, CCP, SCCVN and probably the propagate passes to tell the compiler to be careful if the number is too big. But I'm sure there are many other places I'll have to hack and slash to tell him to stop the folding and propagation. Is there an easier way to do this ? This type of thing is normally controlled by the TARGET_RTX_COSTS hook. E.g., see the handling of CONST_INT mips_rtx_costs in config/mips/mips.c. Ian
gcc-4.3-20090205 is now available
Snapshot gcc-4.3-20090205 is now available on ftp://gcc.gnu.org/pub/gcc/snapshots/4.3-20090205/ and on various mirrors, see http://gcc.gnu.org/mirrors.html for details. This snapshot has been generated from the GCC 4.3 SVN branch with the following options: svn://gcc.gnu.org/svn/gcc/branches/gcc-4_3-branch revision 143973 You'll find: gcc-4.3-20090205.tar.bz2 Complete GCC (includes all of below) gcc-core-4.3-20090205.tar.bz2 C front end and core compiler gcc-ada-4.3-20090205.tar.bz2 Ada front end and runtime gcc-fortran-4.3-20090205.tar.bz2 Fortran front end and runtime gcc-g++-4.3-20090205.tar.bz2 C++ front end and runtime gcc-java-4.3-20090205.tar.bz2 Java front end and runtime gcc-objc-4.3-20090205.tar.bz2 Objective-C front end and runtime gcc-testsuite-4.3-20090205.tar.bz2The GCC testsuite Diffs from 4.3-20090129 are available in the diffs/ subdirectory. When a particular snapshot is ready for public consumption the LATEST-4.3 link is updated and a message is sent to the gcc list. Please do not use a snapshot before it has been announced that way.
Re: Plugin API Comments (was Re: GCC Plug-in Framework ready to port)
Le-Chun Wu wrote:
Hi Sean,
It's great that you updated the wiki page with the latest and more
detailed API design.
We (at Google) also started to look at the GCC plugin support a couple
of weeks ago. We had a quick prototype implemented based on the
original APIs that Taras put together in the old wiki. (I can send out
the patch later for people's reference.) The updated APIs in general
look good to me. I do have some comments based on our experience with
the initial prototyping:
Neat! I'd love to see that.
void register_callbacks(int nregistrations, struct plugin_registration
*registrations);
Instead of passing in an array of plugin_registration objects with a
single register_callbacks call, it's probably better to have the
plugin call a sequence of register_callback with the necessary
information, as shown in the following example:
void plugin_register_callback (const char *plugin_name, enum
plugin_event event, plugin_callback_func callback, void *user_data);
/* In plugin code */
void
plugin_init()
{
...
register_callback (plugin_name, PLUGIN_FINISH_STRUCT, handle_struct, NULL);
register_callback (plugin_name, PLUGIN_FINISH_UNIT,
handle_end_of_compilation_unit, NULL);
...
}
In the function body of register_callback, GCC can then create the
plugin_registration objects and chain them together based on the event
type. Because GCC will need to maintain a list of plugin_registration
objects for each event anyway, we might as well let it create (and
destroy if necessary) the objects instead of leaving the task to the
plugins.
Note that in my example an additional parameter, plugin_name, is added
in register_callback. We found it useful to have the name around when
emitting error messages if something goes wrong during the callback
registration process.
Sean,
I agree with Le-Chun that separate register_callback calls would be
better. Would you change that(in the interest of not having too many
people modify the api), or should I? By the way, reformatting made the
page much more readable, thanks.
I think having a plugin-name parameter is something we can decide on
later ( just like the version stuff). I can see it being useful for
debugging a situation with multiple loaded plugins, but I'm not
convinced that it will be a common problem.
-fplugin=/path/to/plugin.so;arg1=value;arg2=value;...
I am not sure if it is GCC's responsibility to understand key-value
(or any other types of) arguments to plugins. I think GCC should
simply take a string (which, of course, can be something like
arg1=value arg2=value) and pass it (unparsed) to the plugin. It is
plugin's job to parse/process the given arguments (whatever way it
likes). So the prototype of the plugin_init would look like this:
void plugin_init (const char *plugin_name, const char *plugin_arg);
In our current prototype, we implemented the originally proposed flag
-fplugin-arg=, which is associated with the plugin specified in the
most recently parsed -fplugin flag. If a -fplugin-arg flag is used
in the command-line without any preceding -fplugin, an error message
is emitted. Having the plugin name and its arguments concatenated as
currently proposed is also fine, but I would prefer a simple string
(like below) to a series of key-value pairs.
-fplugin=/path/to/plugin.so;arguments
(Note that the double quotes may not needed if the arguments doesn't
contain characters such as spaces.)
I agree with Daniel Jacobowitz's comment that letting every plugin to
parse command-lines will lead to insanity. I'd be nice to let GCC take
care of as much as possible there.
From my brief encounter with the complexity of parameter handling code
in GCC I would be tempted to start with the simplest possible proposal:
either use -fplugin-arg as I described or stuffing everything into
-fplugin and using a semi-colon separator.
Infact, I would prefer not using -fplugin-arg as that leaves more room
for future implementations to use -fplugin-name-whatever to do
plugin arguments.
Pass Manager
We think it would be quite daunting (and probably open up a can of
worms) to allow plugins to re-order passes. So to get things moving
quickly, in our initial prototype we only support insertion of a new
pass and replacing an existing pass. When registering a new pass with
GCC, the plugin uses the normal register_callback call with the
PLUGIN_PASS_MANAGER_SETUP event. However, instead of registering a
callback function, it passes in a plugin_pass object (see below) that
specifies the opt_pass object of the new pass, the name of the
reference pass, the static instance number of the reference pass, and
whether to insert before/after or replacing the reference pass.
enum pass_positioning_ops
{
PASS_POS_INSERT_AFTER,
PASS_POS_INSERT_BEFORE,
PASS_POS_REPLACE
};
struct plugin_pass
{
struct opt_pass *pass;
const char *reference_pass_name;
/* Insert the pass at the specified instance of the reference
Re: Plugin API Comments (was Re: GCC Plug-in Framework ready to port)
Attached please find the patch of our initial prototype of GCC plugin
support based on the APIs described in the (old) wiki page. I also
attached a sample plugin program (dumb-example.c) that shows how a
plugin uses the APIs.
Sean and Taras (and others),
Diego will be creating a branch for the plugin support soon. I know we
still have some issues that have yet to converge (such as flags for
plugin arguments). But in order to get things moving, what do you
think if we start with this patch and move from there? Or if you have
other patches available that implement the currently proposed APIs,
we can start with those too. Thanks.
Le-chun
On Thu, Feb 5, 2009 at 3:27 PM, Taras Glek tg...@mozilla.com wrote:
Le-Chun Wu wrote:
Hi Sean,
It's great that you updated the wiki page with the latest and more
detailed API design.
We (at Google) also started to look at the GCC plugin support a couple
of weeks ago. We had a quick prototype implemented based on the
original APIs that Taras put together in the old wiki. (I can send out
the patch later for people's reference.) The updated APIs in general
look good to me. I do have some comments based on our experience with
the initial prototyping:
Neat! I'd love to see that.
void register_callbacks(int nregistrations, struct plugin_registration
*registrations);
Instead of passing in an array of plugin_registration objects with a
single register_callbacks call, it's probably better to have the
plugin call a sequence of register_callback with the necessary
information, as shown in the following example:
void plugin_register_callback (const char *plugin_name, enum
plugin_event event, plugin_callback_func callback, void *user_data);
/* In plugin code */
void
plugin_init()
{
...
register_callback (plugin_name, PLUGIN_FINISH_STRUCT, handle_struct,
NULL);
register_callback (plugin_name, PLUGIN_FINISH_UNIT,
handle_end_of_compilation_unit, NULL);
...
}
In the function body of register_callback, GCC can then create the
plugin_registration objects and chain them together based on the event
type. Because GCC will need to maintain a list of plugin_registration
objects for each event anyway, we might as well let it create (and
destroy if necessary) the objects instead of leaving the task to the
plugins.
Note that in my example an additional parameter, plugin_name, is added
in register_callback. We found it useful to have the name around when
emitting error messages if something goes wrong during the callback
registration process.
Sean,
I agree with Le-Chun that separate register_callback calls would be better.
Would you change that(in the interest of not having too many people modify
the api), or should I? By the way, reformatting made the page much more
readable, thanks.
I think having a plugin-name parameter is something we can decide on later (
just like the version stuff). I can see it being useful for debugging a
situation with multiple loaded plugins, but I'm not convinced that it will
be a common problem.
-fplugin=/path/to/plugin.so;arg1=value;arg2=value;...
I am not sure if it is GCC's responsibility to understand key-value
(or any other types of) arguments to plugins. I think GCC should
simply take a string (which, of course, can be something like
arg1=value arg2=value) and pass it (unparsed) to the plugin. It is
plugin's job to parse/process the given arguments (whatever way it
likes). So the prototype of the plugin_init would look like this:
void plugin_init (const char *plugin_name, const char *plugin_arg);
In our current prototype, we implemented the originally proposed flag
-fplugin-arg=, which is associated with the plugin specified in the
most recently parsed -fplugin flag. If a -fplugin-arg flag is used
in the command-line without any preceding -fplugin, an error message
is emitted. Having the plugin name and its arguments concatenated as
currently proposed is also fine, but I would prefer a simple string
(like below) to a series of key-value pairs.
-fplugin=/path/to/plugin.so;arguments
(Note that the double quotes may not needed if the arguments doesn't
contain characters such as spaces.)
I agree with Daniel Jacobowitz's comment that letting every plugin to parse
command-lines will lead to insanity. I'd be nice to let GCC take care of as
much as possible there.
From my brief encounter with the complexity of parameter handling code in
GCC I would be tempted to start with the simplest possible proposal: either
use -fplugin-arg as I described or stuffing everything into -fplugin and
using a semi-colon separator.
Infact, I would prefer not using -fplugin-arg as that leaves more room for
future implementations to use -fplugin-name-whatever to do plugin
arguments.
Pass Manager
We think it would be quite daunting (and probably open up a can of
worms) to allow plugins to re-order passes. So to get things moving
quickly, in our initial prototype we only
[Bug tree-optimization/21676] [4.2/4.3/4.4 Regression] Optimizer regression: SciMark sparse matrix benchmark
--- Comment #17 from bonzini at gnu dot org 2009-02-05 08:03 --- Confirmed: 3.3 -O2 3.11s 4.1 -O2 3.44s 4.4 -O2 3.36s 4.4 -O2 -fno-ivopts 3.00s -- bonzini at gnu dot org changed: What|Removed |Added CC||bonzini at gnu dot org Component|rtl-optimization|tree-optimization Last reconfirmed|2006-08-16 12:15:56 |2009-02-05 08:03:22 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21676
[Bug c++/39043] C++ compiler doesn't optimize inlined function call for PIE
--- Comment #1 from hp at gcc dot gnu dot org 2009-02-05 08:17 --- Isn't the answer an obvious no? Lots of s/flag_pic/flag_shlib/ remaining to do? -- hp at gcc dot gnu dot org changed: What|Removed |Added CC||hp at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39043
[Bug tree-optimization/36905] [4.2/4.3/4.4 Regression] IV-opts needs a little help with a[i+1]
--- Comment #4 from bonzini at gnu dot org 2009-02-05 08:26 ---
We miss that out1_5+2 could be hoisted out of the loop and used as a base
object
use 0
address
in statement *D.1259_6 = in_7(D);
at position *D.1259_6
type short unsigned int *
base out1_5(D) + 2
step 2
base object (void *) out1_5(D)
related candidates
I also tried disabling DOM and PRE/FRE so that we get code that is supposedly
easier to optimize, but then IVopts produces
D.1281_16 = out1_5(D) + ivtmp.17_13;
MEM[base: D.1281_16, offset: 2]{*D.1259} = in_7(D);
and again does not recognize that it can be reassociated and moved out of the
loop.
--
bonzini at gnu dot org changed:
What|Removed |Added
CC||bonzini at gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36905
[Bug c/39102] New: gcc generating multiple stack stores in optimised code
Test code:
#include stdint.h
struct u64x2_t {
uint64_t u64a;
uint64_t u64b;
};
union u64_u {
uint64_t u64;
uint64_t *ptr_u64;
};
struct u64x2_t multiple_stack_stores(struct u64x2_t in) {
struct u64x2_t out;
out.u64a=in.u64a+1;
out.u64b=in.u64b;
if ((out.u64a 63)==0) {
union u64_u u;
u.u64=(out.u64a 6) 3;
out.u64b=u.ptr_u64[0];
}
return out;
}
struct u64x2_t no_stack_stores(uint64_t u64a, uint64_t u64b) {
struct u64x2_t out;
out.u64a=u64a+1;
out.u64b=u64b;
if ((out.u64a 63)==0) {
union u64_u u;
u.u64=(out.u64a 6) 3;
out.u64b=u.ptr_u64[0];
}
return out;
}
int main() {
return 0;
}
$ gcc-4.3 -O3 gcc-stack-stores-bug.c objdump -d -m i386:x86-64:intel a.out
generates in part:
00400480 multiple_stack_stores:
400480: 48 8d 4f 01 learcx,[rdi+0x1]
400484: 48 89 7c 24 d8 movQWORD PTR [rsp-0x28],rdi
400489: 48 89 74 24 e0 movQWORD PTR [rsp-0x20],rsi
40048e: f6 c1 3ftest cl,0x3f
400491: 75 0f jne4004a2
multiple_stack_stores+0x22
400493: 48 89 c8movrax,rcx
400496: 48 c1 e8 06 shrrax,0x6
40049a: 48 8b 34 c5 00 00 00movrsi,QWORD PTR [rax*8+0x0]
4004a1: 00
4004a2: 48 89 f2movrdx,rsi
4004a5: 48 89 c8movrax,rcx
4004a8: c3 ret
4004a9: 0f 1f 80 00 00 00 00nopDWORD PTR [rax+0x0]
004004b0 no_stack_stores:
4004b0: 48 8d 4f 01 learcx,[rdi+0x1]
4004b4: f6 c1 3ftest cl,0x3f
4004b7: 75 0f jne4004c8 no_stack_stores+0x18
4004b9: 48 89 c8movrax,rcx
4004bc: 48 c1 e8 06 shrrax,0x6
4004c0: 48 8b 34 c5 00 00 00movrsi,QWORD PTR [rax*8+0x0]
4004c7: 00
4004c8: 48 89 f2movrdx,rsi
4004cb: 48 89 c8movrax,rcx
4004ce: c3 ret
4004cf: 90 nop
With the better-designed x86-64 ABI this struct is passed and returned in
registers. So why is gcc generating this code:
400484: 48 89 7c 24 d8 movQWORD PTR [rsp-0x28],rdi
400489: 48 89 74 24 e0 movQWORD PTR [rsp-0x20],rsi
Similar output is observed with gcc-4.1, gcc-4.2 and gcc-snapshot (Debian
20090129-1) 4.4.0 20090129 (experimental) [trunk revision 143770]
--
Summary: gcc generating multiple stack stores in optimised code
Product: gcc
Version: 4.3.3
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: adam at consulting dot net dot nz
GCC host triplet: Debian Linux
GCC target triplet: x86-84 core2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39102
[Bug c/35634] [4.2/4.3/4.4 Regression] operand of pre-/postin-/decrement not promoted
--- Comment #20 from bonzini at gnu dot org 2009-02-05 08:52 --- How much of the fallout (especially the scev-related failures) goes away with -funsafe-loop-optimizations? I'm thinking that it is unavoidable. :-( -- bonzini at gnu dot org changed: What|Removed |Added CC||bonzini at gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35634
[Bug tree-optimization/35639] [4.3/4.4 Regression] -fprofile-generate = huge SCCs for PRE
--- Comment #10 from bonzini at gnu dot org 2009-02-05 09:01 --- I get some SCCs that have 1500+ values in them. That is quite expensive to maintain. 345,334,000 iterative_hash_hashval_t 199,259,509 ???:??? 151,133,289 iterative_hash_expr 111,911,577 bitmap_bit_p 96,901,657 htab_find_slot_with_hash 93,662,766 get_expr_value_id 64,328,952 bitmap_set_bit -- bonzini at gnu dot org changed: What|Removed |Added Summary|[4.3/4.4 Regression] - |[4.3/4.4 Regression] - |fprofile-generate + PRE = |fprofile-generate = huge |big compile-time|SCCs for PRE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35639
[Bug tree-optimization/35639] [4.3/4.4 Regression] -fprofile-generate = huge SCCs for PRE
--- Comment #11 from rguenth at gcc dot gnu dot org 2009-02-05 09:14 --- I get tree PRE : 1.57 (50%) usr 0.09 (29%) sys 1.68 (29%) wall 295 kB ( 3%) ggc on current trunk (w/o checking). While 50% is quite high the absolute time is low. Though I wonder why FRE is so much better. tree FRE : 0.03 ( 1%) usr 0.01 ( 3%) sys 0.05 ( 1%) wall 85 kB ( 1%) ggc Danny, does your recent hacking around SCCVN improve this testcase? -- rguenth at gcc dot gnu dot org changed: What|Removed |Added CC||dberlin at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35639
[Bug tree-optimization/39100] [4.4 Regression] -fstrict-aliasing miscompilation
--- Comment #10 from rguenth at gcc dot gnu dot org 2009-02-05 09:42 --- Fixed. I'm going to do a backport to the 4.3 branch. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39100
[Bug libgcj/8995] race cases in interpreter
--- Comment #9 from aph at gcc dot gnu dot org 2009-02-05 09:42 --- . -- aph at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=8995
[Bug java/39103] New: Deadlock in AWT
gcc 4.3 branch needs this patch: http://article.gmane.org/gmane.comp.java.classpath.patches/12149 -- Summary: Deadlock in AWT Product: gcc Version: 4.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: java AssignedTo: aph at gcc dot gnu dot org ReportedBy: aph at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39103
[Bug middle-end/39101] [4.4 Regression] Null pointer dereference in delay slot
--- Comment #3 from rguenth at gcc dot gnu dot org 2009-02-05 10:10 --- Can you see which revision caused this? -- rguenth at gcc dot gnu dot org changed: What|Removed |Added GCC build triplet|hppa-unknown-linux-gnu | GCC host triplet|hppa-unknown-linux-gnu | GCC target triplet|hppa-unknown-linux-gnu |hppa64-hp-hpux11.11, hppa- ||unknown-linux-gnu Keywords||build, wrong-code Target Milestone|--- |4.4.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39101
[Bug rtl-optimization/39076] internal compiler error when cross-compiling flac
--- Comment #8 from s dot neumann at phase-zero dot de 2009-02-05 10:06 --- I have applied this patch and the problem is gone. Thanks a lot. -- s dot neumann at phase-zero dot de changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39076
[Bug tree-optimization/39100] [4.4 Regression] -fstrict-aliasing miscompilation
--- Comment #11 from rguenth at gcc dot gnu dot org 2009-02-05 11:10 --- Subject: Bug 39100 Author: rguenth Date: Thu Feb 5 11:10:02 2009 New Revision: 143961 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=143961 Log: 2009-02-05 Daniel Berlin dber...@dberlin.org Richard Guenther rguent...@suse.de PR tree-optimization/39100 * tree-ssa-structalias.c (do_ds_constraint): Actually do what the comment says and add edges. Added: branches/gcc-4_3-branch/gcc/testsuite/gcc.c-torture/execute/pr39100.c - copied unchanged from r143951, trunk/gcc/testsuite/gcc.c-torture/execute/pr39100.c Modified: branches/gcc-4_3-branch/gcc/ChangeLog branches/gcc-4_3-branch/gcc/testsuite/ChangeLog branches/gcc-4_3-branch/gcc/tree-ssa-structalias.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39100
[Bug target/39105] New: Warning about unused libgcc.a when using SGI linker
Compiling the the most trivial program with GCC (using the SGI linker) results in warnings : $ gcc -o hello hello.c ld: WARNING 84: /usr/local/gnu/lib/gcc/mips-sgi-irix5.3/4.3.3/libgcc.a is not used for resolving any symbol. ld: WARNING 84: /usr/local/gnu/lib/gcc/mips-sgi-irix5.3/4.3.3/libgcc.a is not used for resolving any symbol. ld: WARNING 84: /usr/local/gnu/lib/gcc/mips-sgi-irix5.3/4.3.3/libgcc_eh.a is not used for resolving any symbol. In IRIX6, this is prevented by setting the linker option '-dont_warn_unused' before linking libgcc, and unsetting it again afterward. -- Summary: Warning about unused libgcc.a when using SGI linker Product: gcc Version: 4.4.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: J dot J dot vanderHeijden at gmail dot com GCC build triplet: mips-sgi-irix5.3 GCC host triplet: mips-sgi-irix5.3 GCC target triplet: mips-sgi-irix5.3 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39105
[Bug debug/39104] stabs debug info fails onIRIX 5.3
--- Comment #1 from J dot J dot vanderHeijden at gmail dot com 2009-02-05 11:36 --- Created an attachment (id=17244) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17244action=view) Call GAS with -mdebug when using stabs, do not emit .stabd directives With this patch applied, stabs related failures al go away, === g++ Summary === # of expected passes18090 # of unexpected failures13 # of unexpected successes 1 # of expected failures 141 # of unsupported tests 225 /build53/gcc/gcc-trunk/obj-quick/gcc/testsuite/g++/../../g++ version 4.4.0 20090202 (experimental) [trunk revision 143874] (GCC) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39104
[Bug tree-optimization/35639] [4.3/4.4 Regression] -fprofile-generate = huge SCCs for PRE
--- Comment #13 from rguenther at suse dot de 2009-02-05 10:31 ---
Subject: Re: [4.3/4.4 Regression] -fprofile-generate
= huge SCCs for PRE
On Thu, 5 Feb 2009, bonzini at gnu dot org wrote:
--- Comment #12 from bonzini at gnu dot org 2009-02-05 10:26 ---
FRE is not a problem because all the time (93%) is spent computing ANTIC; of
this, half is phi_translate and the other half is bitmap_set operations.
I get a relatively good (15%) improvement from
Index: tree-ssa-sccvn.c
===
--- tree-ssa-sccvn.c (revision 143938)
+++ tree-ssa-sccvn.c (working copy)
@@ -398,9 +398,14 @@ vn_reference_op_eq (const void *p1, cons
static hashval_t
vn_reference_op_compute_hash (const vn_reference_op_t vro1)
{
- return iterative_hash_expr (vro1-op0, vro1-opcode)
-+ iterative_hash_expr (vro1-op1, vro1-opcode)
-+ iterative_hash_expr (vro1-op2, vro1-opcode);
+ hashval_t result = 0;
+ if (vro1-op0)
+result += iterative_hash_expr (vro1-op0, vro1-opcode);
+ if (vro1-op1)
+result += iterative_hash_expr (vro1-op1, vro1-opcode);
+ if (vro1-op2)
+result += iterative_hash_expr (vro1-op2, vro1-opcode);
+ return result;
}
/* Return the hashcode for a given reference operation P1. */
and another 8% from this:
Index: tree-ssa-pre.c
===
--- tree-ssa-pre.c (revision 143938)
+++ tree-ssa-pre.c (working copy)
@@ -216,11 +216,11 @@ pre_expr_hash (const void *p1)
case CONSTANT:
return vn_hash_constant_with_type (PRE_EXPR_CONSTANT (e));
case NAME:
- return iterative_hash_expr (PRE_EXPR_NAME (e), 0);
+ return iterative_hash_hashval_t (SSA_NAME_VERSION (PRE_EXPR_NAME (e)),
0);
case NARY:
- return vn_nary_op_compute_hash (PRE_EXPR_NARY (e));
+ return PRE_EXPR_NARY (e)-hashcode;
case REFERENCE:
- return vn_reference_compute_hash (PRE_EXPR_REFERENCE (e));
+ return PRE_EXPR_REFERENCE (e)-hashcode;
default:
abort ();
}
(Tested with make check RUNTESTFLAGS=tree-ssa.exp=*[pf]re*). At least these
two kick hashing almost out of the profile and bring PRE down from 50% to 40%
of the compilation time. They also speedup a bit the bitmap_sets since
get_or_alloc_expression_id was also doing hashing.
The remaining main offenders are phi_translate_set and phi_translate_1. Apart
from some bitmap_sets, their profile is quite flat so no more
microoptimization
I guess.
I'll bootstrap/regtest the above.
Ah, can you test in addition to the above
--- ../trunk/gcc/tree-ssa-sccvn.c 2009-01-28 13:11:34.0
+0100
+++ gcc/tree-ssa-sccvn.c2009-02-01 12:26:36.0 +0100
@@ -316,6 +316,10 @@
const struct vn_constant_s *vc1 = (const struct vn_constant_s *) p1;
const struct vn_constant_s *vc2 = (const struct vn_constant_s *) p2;
+ /* Early out if this is not a hash collision. */
+ if (vc1-hashcode != vc2-hashcode)
+return false;
+
return vn_constant_eq_with_type (vc1-constant, vc2-constant);
}
and similar in the other hash compare fns?
Richard.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35639
[Bug c/35435] [4.2/4.3/4.4 regression] ICE with attribute tls_model in typedef
--- Comment #5 from jsm28 at gcc dot gnu dot org 2009-02-05 12:14 --- Subject: Bug 35435 Author: jsm28 Date: Thu Feb 5 12:13:52 2009 New Revision: 143963 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=143963 Log: PR c/35435 * c-common.c (handle_tls_model_attribute): Ignore attribute for non-VAR_DECLs without checking DECL_THREAD_LOCAL_P. testsuite: * gcc.dg/tls/diag-6.c: New test. Added: branches/gcc-4_3-branch/gcc/testsuite/gcc.dg/tls/diag-6.c Modified: branches/gcc-4_3-branch/gcc/ChangeLog branches/gcc-4_3-branch/gcc/c-common.c branches/gcc-4_3-branch/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35435
[Bug c/35435] [4.2 regression] ICE with attribute tls_model in typedef
--- Comment #6 from jsm28 at gcc dot gnu dot org 2009-02-05 12:18 --- Fixed for 4.4.0 and 4.3.4. I don't plan to work on a backport to 4.2. -- jsm28 at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|jsm28 at gcc dot gnu dot org|unassigned at gcc dot gnu ||dot org Status|ASSIGNED|NEW Known to fail||4.2.4 4.3.3 Known to work||4.3.4 4.4.0 Summary|[4.2/4.3/4.4 regression] ICE|[4.2 regression] ICE with |with attribute tls_model in |attribute tls_model in |typedef |typedef http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35435
[Bug c++/34397] [4.2/4.3/4.4 regression] ICE on invalid default template parameter
--- Comment #20 from paolo dot carlini at oracle dot com 2009-02-05 12:48 --- Created an attachment (id=17246) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17246action=view) draft, showing that the missing NULL_TREEs are indeed an issue -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34397
[Bug c++/34397] [4.2/4.3/4.4 regression] ICE on invalid default template parameter
--- Comment #19 from paolo dot carlini at oracle dot com 2009-02-05 12:47 --- Indeed, in my experiments the problem seems due to build_min_nt not passing NULL_TREEs as called by build_x_binary_op. The patch I'm going to attach then works, in the sense that the testcase compiles (and then an error is emitted in case of instantiation). I also tried calling directly grok_array_decl from tsubst_copy_and_build, and indeed that largely works (but note that, for some reason, the grok_* functions, called by the parser, are not called often in pt.c, many build_x_* functions instead), but there are subtle issues, like sfinae7.C failing... -- paolo dot carlini at oracle dot com changed: What|Removed |Added CC||paolo dot carlini at oracle ||dot com, mark at ||codesourcery dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34397
[Bug target/39105] Warning about unused libgcc.a when using SGI linker
--- Comment #1 from J dot J dot vanderHeijden at gmail dot com 2009-02-05 11:55 --- Created an attachment (id=17245) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17245action=view) Fix unnecessary wanings about libgcc.a from SGI linker This trivial patch assumes the patch for PR39104 has also been applied, but they are otherwise unrelated. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39105
[Bug c++/39106] New: [4.4 Regression] aliased to undefined symbol error with thunks
extern C void abort ();
struct A
{
A (bool x = true);
};
class B
{
virtual bool bar (A , int) const =0;
};
class C : virtual public B
{
};
struct D : virtual public B
{
bool bar (A , int) const;
};
template int N
struct E : public D
{
bool bar (A x, int y) const
{
return baz().bar (x, y);
}
const D baz () const;
};
extern template class E0;
void
foo ()
{
try
{
A a;
abort ();
} catch (...)
{
}
A b;
E0 c;
c.bar (b, 3);
E0 d;
d.bar (b, 3);
}
fails to compile at -O2 and above on x86_64-linux (both -m32 and -m64), with
error: âbool A::*.LTHUNK0(A, int) constâ aliased to undefined symbol
â_ZNK1EILi0EE3barER1Aiâ
--
Summary: [4.4 Regression] aliased to undefined symbol error with
thunks
Product: gcc
Version: 4.4.0
Status: UNCONFIRMED
Keywords: rejects-valid
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: jakub at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39106
[Bug c++/39106] [4.4 Regression] aliased to undefined symbol error with thunks
-- jakub at gcc dot gnu dot org changed: What|Removed |Added Priority|P3 |P1 Target Milestone|--- |4.4.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39106
[Bug tree-optimization/35639] [4.3/4.4 Regression] -fprofile-generate = huge SCCs for PRE
--- Comment #12 from bonzini at gnu dot org 2009-02-05 10:26 ---
FRE is not a problem because all the time (93%) is spent computing ANTIC; of
this, half is phi_translate and the other half is bitmap_set operations.
I get a relatively good (15%) improvement from
Index: tree-ssa-sccvn.c
===
--- tree-ssa-sccvn.c (revision 143938)
+++ tree-ssa-sccvn.c (working copy)
@@ -398,9 +398,14 @@ vn_reference_op_eq (const void *p1, cons
static hashval_t
vn_reference_op_compute_hash (const vn_reference_op_t vro1)
{
- return iterative_hash_expr (vro1-op0, vro1-opcode)
-+ iterative_hash_expr (vro1-op1, vro1-opcode)
-+ iterative_hash_expr (vro1-op2, vro1-opcode);
+ hashval_t result = 0;
+ if (vro1-op0)
+result += iterative_hash_expr (vro1-op0, vro1-opcode);
+ if (vro1-op1)
+result += iterative_hash_expr (vro1-op1, vro1-opcode);
+ if (vro1-op2)
+result += iterative_hash_expr (vro1-op2, vro1-opcode);
+ return result;
}
/* Return the hashcode for a given reference operation P1. */
and another 8% from this:
Index: tree-ssa-pre.c
===
--- tree-ssa-pre.c (revision 143938)
+++ tree-ssa-pre.c (working copy)
@@ -216,11 +216,11 @@ pre_expr_hash (const void *p1)
case CONSTANT:
return vn_hash_constant_with_type (PRE_EXPR_CONSTANT (e));
case NAME:
- return iterative_hash_expr (PRE_EXPR_NAME (e), 0);
+ return iterative_hash_hashval_t (SSA_NAME_VERSION (PRE_EXPR_NAME (e)),
0);
case NARY:
- return vn_nary_op_compute_hash (PRE_EXPR_NARY (e));
+ return PRE_EXPR_NARY (e)-hashcode;
case REFERENCE:
- return vn_reference_compute_hash (PRE_EXPR_REFERENCE (e));
+ return PRE_EXPR_REFERENCE (e)-hashcode;
default:
abort ();
}
(Tested with make check RUNTESTFLAGS=tree-ssa.exp=*[pf]re*). At least these
two kick hashing almost out of the profile and bring PRE down from 50% to 40%
of the compilation time. They also speedup a bit the bitmap_sets since
get_or_alloc_expression_id was also doing hashing.
The remaining main offenders are phi_translate_set and phi_translate_1. Apart
from some bitmap_sets, their profile is quite flat so no more microoptimization
I guess.
I'll bootstrap/regtest the above.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35639
[Bug tree-optimization/35639] [4.3/4.4 Regression] -fprofile-generate = huge SCCs for PRE
--- Comment #14 from bonzini at gnu dot org 2009-02-05 13:02 ---
20% of PRE time is spent in qsort via sorted_array_from_bitmap_set. Rewriting
it like this makes it a bit faster (it shaves 12% more of PRE time):
FOR_EACH_VALUE_ID_IN_SET (set, i, bi)
{
/* The number of expressions having a given value is usually
relatively small. Thus, rather than making a vector of all the
expressions and sorting it by value id, we walk the values and
check in the reverse mapping that tells us what expressions have
a given value, to filter those in our set. If this is somehow
a significant lose for some cases, we can choose which set to
walk based on the set size. */
bitmap_set_t exprset = VEC_index (bitmap_set_t, value_expressions, i);
FOR_EACH_EXPR_ID_IN_SET (exprset, j, bj)
{
if (bitmap_bit_p (set-expressions, j))
VEC_safe_push (pre_expr, heap, result, expression_for_id (j));
}
}
I'll add this to the bootstrap/regtest.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35639
[Bug debug/39104] New: stabs debug info fails onIRIX 5.3
On IRIX 5.3, stabs debug info is embedded in ECOFF. Beginning with gas 2.13,
-mdebug must be passed to correctly handle COFF debugging info. GCC does not do
this.
The result is a lot of stabs related failures:
http://gcc.gnu.org/ml/gcc-testresults/2009-01/msg02896.html
A possible solution is to add %{gstabs*:-mdebug} %{!gstabs*:-no-mdebug} to
SUBTARGET_ASM_DEBUGGING_SPEC, but only for an IRIX5 target, and only when using
GAS.
--
Summary: stabs debug info fails onIRIX 5.3
Product: gcc
Version: 4.4.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: debug
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: J dot J dot vanderHeijden at gmail dot com
GCC build triplet: mips-sgi-irix5.3
GCC host triplet: mips-sgi-irix5.3
GCC target triplet: mips-sgi-irix5.3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39104
[Bug tree-optimization/38977] [4.4 Regression] bash no longer builds with profile-feedback
--- Comment #17 from rguenth at gcc dot gnu dot org 2009-02-05 13:37 --- Testing for fork as well doesn't fix it either. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38977
[Bug libstdc++/39107] New: Building an i686-pc-linux-gnu - i686-pc-mingw32 crosscompiler fails on libstdc++ configure
configuring libstdc++ in an i686-pc-linux-gnu-i686-pc-mingw32 crosscompiler fails with checking for ld that supports -Wl,--gc-sections... configure: error: Link tests are not allowed after GCC_NO_EXECUTABLES. make[1]: *** [configure-target-libstdc++-v3] Error 1 -- Summary: Building an i686-pc-linux-gnu - i686-pc-mingw32 crosscompiler fails on libstdc++ configure Product: gcc Version: 4.3.3 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libstdc++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: bero at arklinux dot org GCC build triplet: i686-pc-linux-gnu GCC host triplet: i686-pc-linux-gnu GCC target triplet: i686-pc-mingw32 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39107
[Bug tree-optimization/35639] [4.3/4.4 Regression] -fprofile-generate = huge SCCs for PRE
--- Comment #15 from rguenth at gcc dot gnu dot org 2009-02-05 13:40 --- pre-allocating the VEC with some reasonable defaults (add some stats for this testcase) should make it even more fast. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35639
[Bug libstdc++/39107] Building an i686-pc-linux-gnu - i686-pc-mingw32 crosscompiler fails on libstdc++ configure
--- Comment #2 from bero at arklinux dot org 2009-02-05 13:52 --- A bit below the check for --gc-sections, GLIBCXX_CHECK_LINKER_FEATURES actually checks for another linker feature in a way that doesn't break crosscompiling: cxx_z_relo=`$LD -v --help 2/dev/null | grep z relro` if test -n $cxx_z_relo; then OPT_LDFLAGS=-Wl,-z,relro ac_ld_relro=yes fi AC_MSG_RESULT($ac_ld_relro) The same trick will work for gc-sections as well. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39107
[Bug libstdc++/39107] Building an i686-pc-linux-gnu - i686-pc-mingw32 crosscompiler fails on libstdc++ configure
--- Comment #3 from bero at arklinux dot org 2009-02-05 13:58 --- Created an attachment (id=17247) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17247action=view) Proposed patch -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39107
[Bug libstdc++/39107] Building an i686-pc-linux-gnu - i686-pc-mingw32 crosscompiler fails on libstdc++ configure
--- Comment #4 from paolo dot carlini at oracle dot com 2009-02-05 14:09 --- But, isn't GLIBCXX_CHECK_LINKER_FEATURES called *only* when $GLIBCXX_IS_NATIVE? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39107
[Bug rtl-optimization/39077] [4.3/4.4 Regression] GCSE-optimization causes enormous binary size increase (~20 times !)
--- Comment #4 from steven at gcc dot gnu dot org 2009-02-05 14:23 --- Investigating... -- steven at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |steven at gcc dot gnu dot |dot org |org Status|NEW |ASSIGNED Last reconfirmed|2009-02-03 09:54:50 |2009-02-05 14:23:43 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39077
[Bug bootstrap/39108] New: LTO fails to bootstrap on Alpha
when configuring libgcc:
configure:2611: /home/falk/lto/build/./gcc/xgcc -B/home/falk/lto/build/./gcc/
-B/usr/local/alphaev68-unknown-linux-gnu/bin/
-B/usr/local/alphaev68-unknown-linux-gnu/lib/ -isystem
/usr/local/alphaev68-unknown-linux-gnu/include -isystem
/usr/local/alphaev68-unknown-linux-gnu/sys-include -c -g -O2 -mieee
conftest.c 5
conftest.c:16: internal compiler error: tree check: expected function_decl,
have error_mark in get_personality_function, at expr.h:806
Please submit a full bug report,
with preprocessed source if appropriate.
See http://gcc.gnu.org/bugs.html for instructions.
configure:2614: $? = 1
configure: failed program was:
| /* confdefs.h. */
|
| #define PACKAGE_NAME GNU C Runtime Library
| #define PACKAGE_TARNAME libgcc
| #define PACKAGE_VERSION 1.0
| #define PACKAGE_STRING GNU C Runtime Library 1.0
| #define PACKAGE_BUGREPORT
| /* end confdefs.h. */
|
| int
| main ()
| {
|
| ;
| return 0;
| }
--
Summary: LTO fails to bootstrap on Alpha
Product: gcc
Version: lto
Status: UNCONFIRMED
Keywords: ice-on-valid-code
Severity: normal
Priority: P3
Component: bootstrap
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: falk at debian dot org
GCC build triplet: alphaev68-linux-gnu
GCC host triplet: alphaev68-linux-gnu
GCC target triplet: alphaev68-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39108
[Bug c++/39109] New: [4.4 Regression] Accessible constructor required for new
struct N
{
private:
virtual ~N ();
};
N *
foo ()
{
return new N ();
}
used to compile until http://gcc.gnu.org/viewcvs?root=gccview=revrev=138355
Does it really need to have an accessible destructor if it is never deleted?
Dodji cited [basic.life]/4 which could mean this is valid.
Distilled from thunderbird.
--
Summary: [4.4 Regression] Accessible constructor required for new
Product: gcc
Version: 4.4.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: jakub at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39109
[Bug c++/39109] [4.4 Regression] Accessible constructor required for new
-- jakub at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|--- |4.4.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39109
[Bug tree-optimization/38977] [4.4 Regression] bash no longer builds with profile-feedback
--- Comment #18 from rguenth at gcc dot gnu dot org 2009-02-05 15:31 --- Some more details: jobs.c: In function 'make_child': jobs.c:4121: error: corrupted profile info: profile data is not flow-consistent jobs.c:4121: error: corrupted profile info: number of executions for edge 10-11 thought to be -1726 jobs.c:4121: error: corrupted profile info: number of executions for edge 10-12 thought to be 1745 jobs.c:4121: error: corrupted profile info: number of iterations for basic block 11 thought to be -120 ;; basic block 8, loop depth 0, count 1745 ;; prev block 7, next block 9 ;; pred: 7 [100.0%] count:1745 (fallthru) ;; succ: 9 count:1625 (true) 12 count:120 (false) bb 8: default_buffered_input.139 = default_buffered_input; if (default_buffered_input.139 != -1) goto bb 9; else goto bb 12; ;; basic block 9, loop depth 0, count 1625 ;; prev block 8, next block 10 ;; pred: 8 count:1625 (true) ;; succ: 11 count:1606 (true) 10 count:19 (false) bb 9: if (async_p == 0) goto bb 11; else goto bb 10; ;; basic block 10, loop depth 0, count 19 ;; prev block 9, next block 11 ;; pred: 9 count:19 (false) ;; succ: 11 count:-1726 (true) 12 count:1745 (false) bb 10: default_buffered_input.139 = default_buffered_input; if (default_buffered_input.139 0) goto bb 11; else goto bb 12; ;; basic block 11, loop depth 0, count -120 ;; prev block 10, next block 12 ;; pred: 9 count:1606 (true) 10 count:-1726 (true) ;; succ: 12 count:1625 (fallthru) EXIT count:-1745 (fake) bb 11: default_buffered_input.139 = default_buffered_input; sync_buffered_stream (default_buffered_input.139); ;; basic block 12, loop depth 0, count 3490 ;; prev block 11, next block 13 ;; pred: 8 count:120 (false) 10 count:1745 (false) 11 count:1625 (fallthru) ;; succ: 13 (true) 18 count:3490 (false) bb 12: pid.140 = fork (); pid = pid.140; if (pid 0) goto bb 13; else goto bb 18; ;; basic block 13, loop depth 0, count 0 ;; prev block 12, next block 14 ;; pred: 12 (true) ;; succ: 14 [100.0%] (fallthru) EXIT (fake) bb 13: sys_error (fork[0]); ;; basic block 18, loop depth 0, count 3490 ;; prev block 17, next block 19 ;; pred: 12 count:3490 (false) 17 (fallthru) ;; succ: 19 count:1745 (true) 48 count:1745 (false) bb 18: if (pid == 0) goto bb 19; else goto bb 48; -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38977
[Bug c++/36406] [4.2/4.3/4.4 regression] ICE with template delete operator
--- Comment #4 from paolo dot carlini at oracle dot com 2009-02-05 15:36 --- Note the first snippet only triggers a warning with ICC / Comeau in strict mode, the second one, compiles just fine... -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36406
[Bug tree-optimization/38977] [4.4 Regression] bash no longer builds with profile-feedback
--- Comment #19 from rguenth at gcc dot gnu dot org 2009-02-05 15:36
---
Relevant source snippet:
if (default_buffered_input != -1
(!async_p || default_buffered_input 0))
sync_buffered_stream (default_buffered_input);
if ((pid = fork ()) 0)
{
sys_error (fork);
...
throw_to_top_level ();
}
if (pid == 0)
{
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38977
[Bug c++/39106] [4.4 Regression] aliased to undefined symbol error with thunks
--- Comment #1 from jakub at gcc dot gnu dot org 2009-02-05 15:55 --- Created an attachment (id=17248) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17248action=view) gcc44-pr39106.patch Patch I'm going to bootstrap/regtest. The problem is that cgraph_function_versioning copies the whole FUNCTION_DECL node, including DECL_LANG_SPECIFIC etc. and then the original bar function doesn't need to be emitted (so emit_associated_thunks langhook isn't called for it), but when it is called on the versioned bar function, it will emit thunks for non-existing function. As emit_associated_thunks langhook does nothing if !DECL_VIRTUAL_P, I think the easiest fix is to clear this bit. -- jakub at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |jakub at gcc dot gnu dot org |dot org | Status|UNCONFIRMED |ASSIGNED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39106
[Bug libstdc++/39107] Building an i686-pc-linux-gnu - i686-pc-mingw32 crosscompiler fails on libstdc++ configure
--- Comment #5 from bero at arklinux dot org 2009-02-05 15:56 --- It does get called when building that i686-pc-linux-gnu - i686-pc-mingw32 crosscompiler -- but maybe the fact that it does indicates a bug elsewhere in the build system -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39107
[Bug rtl-optimization/39110] New: [4.4 Regression] Revision 143939 breaks bootstrap on Linux/ia64
Revision 143939: http://gcc.gnu.org/ml/gcc-cvs/2009-02/msg00105.html caused miscompilation of the fortran compiler on ia64. -- Summary: [4.4 Regression] Revision 143939 breaks bootstrap on Linux/ia64 Product: gcc Version: 4.4.0 Status: UNCONFIRMED Severity: major Priority: P3 Component: rtl-optimization AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: hjl dot tools at gmail dot com GCC target triplet: ia64-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39110
[Bug rtl-optimization/39110] [4.4 Regression] Revision 143939 breaks bootstrap on Linux/ia64
-- hjl dot tools at gmail dot com changed: What|Removed |Added Priority|P3 |P1 Target Milestone|--- |4.4.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39110
[Bug rtl-optimization/39110] [4.4 Regression] Revision 143939 breaks bootstrap on Linux/ia64
--- Comment #1 from bonzini at gnu dot org 2009-02-05 16:28 --- Can you please attach .i files for the fortran compiler? thanks -- bonzini at gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2009-02-05 16:28:00 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39110
[Bug tree-optimization/35639] [4.3/4.4 Regression] -fprofile-generate = huge SCCs for PRE
--- Comment #16 from bonzini at gnu dot org 2009-02-05 16:30 --- Not much. The remaining compile-time hogs (~25%) are the pre_expr and expr_pred_trans hash tables. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35639
[Bug libstdc++/39107] Building an i686-pc-linux-gnu - i686-pc-mingw32 crosscompiler fails on libstdc++ configure
--- Comment #6 from r dot emrich at de dot tecosim dot com 2009-02-05 16:34 --- (In reply to comment #5) It does get called when building that i686-pc-linux-gnu - i686-pc-mingw32 crosscompiler -- but maybe the fact that it does indicates a bug elsewhere in the build system The cross build x86_64-unknown-linux-gnu - i686-pc-mingw32 works fine for me. Last build trunk revision 143920, but I also have a successful build of 4.3.3. Indeed it indicates a wrong build setup. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39107
[Bug middle-end/39101] [4.4 Regression] Null pointer dereference in delay slot
--- Comment #4 from bonzini at gnu dot org 2009-02-05 16:37 --- Maybe a dup of 39110 -- try revision 143938. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39101
[Bug tree-optimization/35639] [4.3/4.4 Regression] -fprofile-generate = huge SCCs for PRE
--- Comment #17 from dberlin at gcc dot gnu dot org 2009-02-05 16:41 --- Subject: Re: [4.3/4.4 Regression] -fprofile-generate = huge SCCs for PRE Ugh. It might make sense to just replace the hash table implementation we use with something better (simple power of 2, key-value stuff instead of what we have now) I've found in my testing that it can be quite a time sink. On Thu, Feb 5, 2009 at 11:30 AM, bonzini at gnu dot org gcc-bugzi...@gcc.gnu.org wrote: --- Comment #16 from bonzini at gnu dot org 2009-02-05 16:30 --- Not much. The remaining compile-time hogs (~25%) are the pre_expr and expr_pred_trans hash tables. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35639 --- You are receiving this mail because: --- You are on the CC list for the bug, or are watching someone who is. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35639
[Bug middle-end/39101] [4.4 Regression] Null pointer dereference in delay slot
--- Comment #5 from dave at hiauly1 dot hia dot nrc dot ca 2009-02-05 16:53 --- Subject: Re: [4.4 Regression] Null pointer dereference in delay slot Maybe a dup of 39110 -- try revision 143938. I'm reconfirming, but I believe 143938 is ok. The problem is present with 143939. Dave -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39101
[Bug middle-end/39101] [4.4 Regression] Null pointer dereference in delay slot
--- Comment #6 from bonzini at gnu dot org 2009-02-05 17:05 --- That would indeed make it a dup. (I meant 143938 would be the last good build). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39101
[Bug tree-optimization/35639] [4.3/4.4 Regression] -fprofile-generate = huge SCCs for PRE
--- Comment #18 from dberlin at gcc dot gnu dot org 2009-02-05 17:43 --- Subject: Re: [4.3/4.4 Regression] -fprofile-generate = huge SCCs for PRE My hacking will seriously improve this, since it doesn't iterate over pieces of the SCC that aren't changing (which often is most of it). On large SCC's, most of the time is actually being spent revisiting things that can't possibly have changed. (IE out of 5000 members of the SCC, 200 could have changed but we visit all 5000 anyway). On Thu, Feb 5, 2009 at 4:14 AM, rguenth at gcc dot gnu dot org gcc-bugzi...@gcc.gnu.org wrote: --- Comment #11 from rguenth at gcc dot gnu dot org 2009-02-05 09:14 --- I get tree PRE : 1.57 (50%) usr 0.09 (29%) sys 1.68 (29%) wall 295 kB ( 3%) ggc on current trunk (w/o checking). While 50% is quite high the absolute time is low. Though I wonder why FRE is so much better. tree FRE : 0.03 ( 1%) usr 0.01 ( 3%) sys 0.05 ( 1%) wall 85 kB ( 1%) ggc Danny, does your recent hacking around SCCVN improve this testcase? -- rguenth at gcc dot gnu dot org changed: What|Removed |Added CC||dberlin at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35639 --- You are receiving this mail because: --- You are on the CC list for the bug, or are watching someone who is. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35639
[Bug rtl-optimization/39110] [4.4 Regression] Revision 143939 breaks bootstrap on Linux/ia64
--- Comment #2 from hjl dot tools at gmail dot com 2009-02-05 17:49 --- Program received signal SIGSEGV, Segmentation fault. 0x4006ac11 in gfc_check_interfaces (ns=0x602b05c0) at /net/gnu-13/export/gnu/src/gcc/gcc/gcc/fortran/interface.c:1301 1301 switch (i) (gdb) bt #0 0x4006ac11 in gfc_check_interfaces (ns=0x602b05c0) at /net/gnu-13/export/gnu/src/gcc/gcc/gcc/fortran/interface.c:1301 #1 0x40109330 in resolve_types (ns=0x602b05c0) at /net/gnu-13/export/gnu/src/gcc/gcc/gcc/fortran/resolve.c:10409 #2 0x40111a00 in gfc_resolve (ns=0x602b05c0) at /net/gnu-13/export/gnu/src/gcc/gcc/gcc/fortran/resolve.c:10475 #3 0x400e31b0 in gfc_parse_file () at /net/gnu-13/export/gnu/src/gcc/gcc/gcc/fortran/parse.c:3844 #4 0x40161160 in gfc_be_parse_file (set_yydebug=0) at /net/gnu-13/export/gnu/src/gcc/gcc/gcc/fortran/f95-lang.c:236 #5 0x406c29a0 in toplev_main (argc=value optimized out, argv=value optimized out) at /net/gnu-13/export/gnu/src/gcc/gcc/gcc/toplev.c:970 #6 0x401f2f70 in main (argc=12, argv=0x6fffb718) at /net/gnu-13/export/gnu/src/gcc/gcc/gcc/main.c:36 (gdb) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39110
[Bug rtl-optimization/39110] [4.4 Regression] Revision 143939 breaks bootstrap on Linux/ia64
--- Comment #3 from hjl dot tools at gmail dot com 2009-02-05 17:54 --- Created an attachment (id=17249) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17249action=view) Processed gcc/fortran/interface.c This file is miscompiled with -DUSE_LIBUNWIND_EXCEPTIONS -g -O2 -DIN_GCC -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -Wcast-qual -Wold-style-definition -Wc++-compat -Wmissing-format-attribute -pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -Werror -DHAVE_CONFIG_H -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39110
[Bug rtl-optimization/39110] [4.4 Regression] Revision 143939 breaks bootstrap on Linux/ia64
--- Comment #4 from bonzini at gnu dot org 2009-02-05 18:14 --- *** Bug 39101 has been marked as a duplicate of this bug. *** -- bonzini at gnu dot org changed: What|Removed |Added CC||danglin at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39110
[Bug middle-end/39101] [4.4 Regression] Null pointer dereference in delay slot
--- Comment #7 from bonzini at gnu dot org 2009-02-05 18:14 --- every strict alignment platform is broken. *** This bug has been marked as a duplicate of 39110 *** -- bonzini at gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39101
[Bug libgcj/38861] gcjwebplugin.cc doesn't compile against latest xulrunner 1.9.1 sdk
--- Comment #2 from aph at gcc dot gnu dot org 2009-02-05 18:18 --- Created an attachment (id=17250) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17250action=view) This should do it -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38861
[Bug rtl-optimization/39110] [4.4 Regression] Revision 143939 breaks bootstrap on Linux/ia64
--- Comment #5 from hjl dot tools at gmail dot com 2009-02-05 18:25 --- Every strict alignment platform is broken. -- hjl dot tools at gmail dot com changed: What|Removed |Added Severity|major |critical GCC target triplet|ia64-linux-gnu | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39110
[Bug rtl-optimization/39110] [4.4 Regression] Revision 143939 breaks bootstrap on Linux/ia64
--- Comment #6 from bonzini at gnu dot org 2009-02-05 18:29 --- Subject: Bug 39110 Author: bonzini Date: Thu Feb 5 18:29:11 2009 New Revision: 143971 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=143971 Log: 2009-02-05 Paolo Bonzini bonz...@gnu.org PR rtl-optimization/39110 * rtlanal.c (rtx_addr_can_trap_p_1): Shortcut unaligned addresses, not aligned ones. Modified: trunk/gcc/ChangeLog trunk/gcc/rtlanal.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39110
[Bug rtl-optimization/39110] [4.4 Regression] Revision 143939 breaks bootstrap on Linux/ia64
--- Comment #7 from bonzini at gnu dot org 2009-02-05 18:30 --- patch committed, please close it as soon as you can confirm it is fixed. -- bonzini at gnu dot org changed: What|Removed |Added Severity|critical|major Status|NEW |WAITING Priority|P1 |P3 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39110
[Bug bootstrap/39111] New: gcc 4.4.0 20090204 - Configury from GNU linker to Operating System's Linker broke (reverse works OK)
On Solaris (and HPUX, other ...) Operating Systems the OS's Manufacturer has their own Linker and recommends it be used for all linking. The OpenSolaris default gcc supplied by Sun is: # /usr/sfw/bin/gcc -v Reading specs from /usr/sfw/lib/gcc/i386-pc-solaris2.11/3.4.3/specs Configured with: /builds2/sfwnv-gate/usr/src/cmd/gcc/gcc-3.4.3/configure --prefix=/usr/sfw --with-as=/usr/sfw/bin/gas --with-gnu-as --with-ld=/usr/ccs/bin/ld --without-gnu-ld --enable-languages=c,c++,f77,objc --enable-shared Thread model: posix gcc version 3.4.3 (csl-sol210-3_4-20050802) Note that the enable-languages lacks Ada so if you desire to build the Trunk with Ada you would need a different compiler, here is BlastWave's: # /opt/csw/gcc3/bin/gcc -v Reading specs from /opt/csw/gcc3/lib/gcc/i386-pc-solaris2.8/3.4.5/specs Configured with: ../sources/gcc-3.4.5/configure --prefix=/opt/csw/gcc3 --with-local-prefix=/opt/csw --with-gnu-as --with-as=/opt/csw/bin/gas --without-gnu-ld --with-ld=/usr/ccs/bin/ld --enable-threads=posix --enable-shared --enable-multilib --enable-nls --with-included-gettext --with-libiconv-prefix=/opt/csw --with-x --enable-java-awt=xlib --enable-languages=all Thread model: posix gcc version 3.4.5 Note that in both of the commonly available compilers for Solaris the person who built gcc used Sun's linker. It is dated Nov 19 2008. # /usr/ccs/bin/ld -V ld: Software Generation Utilities - Solaris Link Editors: 5.11-1.1624 While Sun (and other OS Manufacturers) may recommend you use their Linker it is not required by GNU that you do so. You can use GNU's Linker. If you use GNU's Linker on Solaris then you have slightly newer features from Binutils and you can enable Mudflaps. That might be useful for some. The BUG is this: If you compile gcc (using a gcc that uses Sun's Linker) to make a gcc Toolchain that uses GNU's Linker the resulting gcc Toolchain will WORK reasonably well and passes most make -i check tests. If you compile gcc (using a gcc that uses GNU's Linker) to make a gcc Toolchain that uses Sun's Linker the resulting gcc Toolchain will WORK reasonably well and passes most make -i check tests. This problem seems to start with the configure during the build, little things seem to be getting detected differently. It would seem that these small oddities make little difference but they eventually will accumulate to a point where the gcc configure scripts _overestimate_ the TARGET Linker's capabilities and mistake them for the HOST Linker's capabilities. If you build gcc, save a log of the build going in each direction, and then diff the two logs _MANY_ of the differences make sense but some make little sense at all: # ../gcc_trunk/configure ... --with-gnu-as --with-as=/usr/local/bin/as --without-gnu-ld --with-ld=/usr/ccs/bin/ld # gmake 21 | tee made_16a_log.txt # ../gcc_trunk/configure ... --with-gnu-as --with-as=/opt/csw/bin/gas --without-gnu-ld --with-ld=/usr/ccs/bin/ld # gmake 21 | tee made_17a_log.txt gdiff -Naur made_16a_log.txt made_17a_log.txt --- made_16a_log.txt2009-02-03 15:05:11.445270964 -0800 +++ made_17a_log.txt2009-02-05 08:16:22.532336517 -0800 ... -checking for catalogs to be installed... be da de el es fi fr ja nl ru sr sv tr zh_CN zh_TW +checking for catalogs to be installed... be da de el es fi fr id ja nl ru sr sv tr zh_CN zh_TW ... checking what objdump to use... /usr/local/i386-pc-solaris2.11/bin/objdump +checking for readelf... /usr/local/bin/readelf +checking what readelf to use... /usr/local/bin/readelf checking assembler for .balign and .p2align... yes ... checking assembler for .hidden... yes -checking linker for .hidden support... no +checking linker for .hidden support... yes +checking linker read-only and read-write section mixing... read-only checking assembler for .sleb128 and .uleb128... yes checking assembler for cfi directives... yes +checking assembler for working cfi advance... yes checking assembler for cfi personality directive... yes ... checking assembler for --debug-prefix-map option... yes +checking assembler for .lcomm with alignment... no checking assembler for tolerance to line number 0... yes -checking linker read-only and read-write section mixing... read-only checking linker PT_GNU_EH_FRAME support... no checking linker position independent executable support... no checking linker EH-compatible garbage collection of sections... /usr/local/i386-pc-solaris2.11/bin/objdump: 'conftest': No such file ... Lets see how that going to work out ... When you use an installed gcc compiler configured with: ../gcc_trunk/configure ... --with-gnu-as --with-as=/usr/local/bin/as --without-gnu-ld --with-ld=/usr/ccs/bin/ld to build gcc when it is ./configured with: # ../gcc_trunk/configure ... --with-gnu-as --with-as=/opt/csw/bin/gas --without-gnu-ld --with-ld=/usr/ccs/bin/ld will cause the build to break here: chmod a-wx rts/*.ali touch ../stamp-gnatlib-rts gmake[6]: Leaving directory `/usr/share/src/gcc_build/gcc/ada'
[Bug bootstrap/39111] gcc 4.4.0 20090204 - Configury from GNU linker to Operating System's Linker broke (reverse works OK)
--- Comment #1 from rob1weld at aol dot com 2009-02-05 18:36 --- Correction (not careful enough with the cut-and-pasting): The BUG is this: If you compile gcc (using a gcc that uses Sun's Linker) to make a gcc Toolchain that uses GNU's Linker the resulting gcc Toolchain will WORK reasonably well and passes most make -i check tests. If you compile gcc (using a gcc that uses GNU's Linker) to make a gcc Toolchain that uses Sun's Linker the resulting gcc Toolchain will _NOT_ WORK since it can't be built without a few fixes to the scripts. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39111
[Bug pch/39071] [4.4 regression] All gcc.dg/pch tests FAIL on mipsel-linux
--- Comment #1 from laurent at guerby dot net 2009-02-05 19:25 --- At rev 143942 on trunk the test now PASS http://gcc.gnu.org/ml/gcc-testresults/2009-02/msg00541.html Executing on host: /mnt/LG500/home/guerby/build-143942/gcc/xgcc -B/mnt/LG500/home/guerby/build-143942/gcc/ ./common-1.h -O0 -g -o common-1.h.gch(timeout = 300) PASS: ./common-1.h -O0 -g (test for excess errors) Executing on host: /mnt/LG500/home/guerby/build-143942/gcc/xgcc -B/mnt/LG500/home/guerby/build-143942/gcc/ /home/guerby/work2/trunk/gcc/testsuite/gcc.dg/pch/common-1.c -O0 -g -I. -S -o common-1.s(time out = 300) PASS: gcc.dg/pch/common-1.c -O0 -g -I. (test for excess errors) Executing on host: /mnt/LG500/home/guerby/build-143942/gcc/xgcc -B/mnt/LG500/home/guerby/build-143942/gcc/ /home/guerby/work2/trunk/gcc/testsuite/gcc.dg/pch/common-1.c -O0 -g -I. -S -o common-1.s(timeo ut = 300) PASS: gcc.dg/pch/common-1.c -O0 -g (test for excess errors) PASS: gcc.dg/pch/common-1.c -O0 -g assembly comparison I wonder what fixed this issue between 143818 and 143942 but well... -- laurent at guerby dot net changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39071
[Bug c/39031] HUGE_VAL_D32, HUGE_VAL_D64, HUGE_VAL_D128 missing from math.h
--- Comment #4 from rsa at us dot ibm dot com 2009-02-05 19:28 --- This situation is a little bit muddy. The position of the GLIBC maintainer is that requirements of the DFP Technical Report will NEVER be added to GLIBC proper. There is indeed currently a EGLIBC branch that is hosting a 'dfp' add-on which will build a powerpc version of libdfp. Libdfp provides math.h. Ultimately libdfp will be a standalone library and math.h will be provided via a #include_next header file forwarding mechanism. When you compile your app you will indicate where the math.h is located that provides dfp prototypes: -I /usr/include/dfp/math.h /* /usr/include/dfp/math.h */ /* dfp specific additions and definitions. */ #include_next math.h In the meantime you can look use the eglibc dfp branch at: eglibc/dfp/sysdeps/dfp/math/math.h I hope to have a prototype standalone libdfp very soon. Unfortunately I don't have the time to do the libbid backend work to support x86. I believe there's currently a wrapper layer to allow it to be inserted into libdfp as a valid backend but someone else needs to help integrate and test that. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39031
[Bug c/39031] HUGE_VAL_D32, HUGE_VAL_D64, HUGE_VAL_D128 missing from math.h
--- Comment #5 from rsa at us dot ibm dot com 2009-02-05 19:32 --- From the libdfp math.h: #if __STDC_WANT_DEC_FP__ # define DEC_INFINITY---__builtin_infd32() # define DEC_NAN---(0.0DF * DEC_INFINITY) # define HUGE_VAL_D64--__builtin_infd64() # define HUGE_VAL_D64 (9.999E384DD + 1.E384dd) */ # define HUGE_VAL_D32--HUGE_VAL_D64 # define HUGE_VAL_D128-HUGE_VAL_D64 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39031
[Bug libstdc++/39107] Building an i686-pc-linux-gnu - i686-pc-mingw32 crosscompiler fails on libstdc++ configure
--- Comment #7 from paolo dot carlini at oracle dot com 2009-02-05 19:36 --- Yes. Please add details about the way you are setting up your build, give people a chance to analyse it. -- paolo dot carlini at oracle dot com changed: What|Removed |Added Status|UNCONFIRMED |WAITING http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39107
[Bug c++/15097] code generator problem with ::delete and multiple inheritance and virtual deconstructs
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added Known to work|4.3.0 |4.3.0 4.2.2 Target Milestone|--- |4.2.2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15097
[Bug libstdc++/39107] Building an i686-pc-linux-gnu - i686-pc-mingw32 crosscompiler fails on libstdc++ configure
--- Comment #8 from bero at arklinux dot org 2009-02-05 20:14 --- mkdir build cd build ../configure --prefix=/usr --enable-static --enable-shared --enable-fast-install --enable-c99 --enable-wchar_t --disable-gconf-peer --target=i686-pc-mingw32 --enable-threads --enable-tls --with-tls --enable-libstdcxx-pch --enable-__cxa_atexit --enable-languages=c,c++,objc,obj-c++,java,fortran,ada --enable-libada --program-prefix=i686-pc-mingw32- make -j4 -- bero at arklinux dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |bero at arklinux dot org |dot org | Status|WAITING |UNCONFIRMED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39107
[Bug c++/39112] New: incorrect value of a static const double class member
there is a class with a static const double member:
struct Foobar{
static const double var;
};
In one translation unit variable 'var' is defined and initialized as 1.0:
const double Foobar::var = 1.0;
When I access Foobar::var from another translation unit, it's value is 0
instead of 1.0 !
Interestingly, the initialization itself works correctly, if I print bytes
at Foobar::var, they are
00.00.00.00.00.00.f0.3f, however when dereferencing them with '*' I still
get zero !
This code
const char * ptr = (const char *)(Foobar::var);
for (int i=0; i 8; ++i){
if (i) fprintf(stderr, .);
fprintf(stderr, %.2x, 0xFF ptr[i]);
}
fprintf(stderr, = %g : %g\n, Foobar::var, *((double*)ptr));
produces
00.00.00.00.00.00.f0.3f = 0 : 0
instead of
00.00.00.00.00.00.f0.3f = 1 : 1
Attached is a complete example.
THIS BUG SHOWS UP WITH OPTIMIZATION LEVELS OTHER THAN -O0
With -O0 it works correctly.
Versions tried:
4.4.0 20090110 (i686-linux)
4.4.0 20090201 (i686-linux)
from Mingw-W64 project site
https://sourceforge.net/project/showfiles.php?group_id=202880package_id=245516
P.S. Intially I reported this bug to Mingw-W64 people
(https://sourceforge.net/tracker2/?func=detailatid=983354aid=2567355group_id=202880),
however they responded that it's a GCC bug that should
be reported here.
Below is the output from g++ -v:
x86_64-pc-mingw32-g++ -O2 -v -save-temps -c -o main.o main.cpp
Using built-in specs.
Target: x86_64-pc-mingw32
Configured with: ../gcc/configure --target=x86_64-pc-mingw32
--prefix=/opt/buildbot/mingw-w64/slave-linux/linux-i386/build/root
--with-sysroot=/opt/buildbot/mingw-w64/slave-linux/linux-i386/build/root
--enable-languages=all,obj-c++ --disable-multilib
Thread model: win32
gcc version 4.4.0 20090201 (experimental) (GCC)
COLLECT_GCC_OPTIONS='-O2' '-v' '-save-temps' '-c' '-o' 'main.o'
'-shared-libgcc' '-mtune=generic'
/usr/local/opt/mingw64/bin/../libexec/gcc/x86_64-pc-mingw32/4.4.0/cc1plus -E
-quiet -v -iprefix
/usr/local/opt/mingw64/bin/../lib/gcc/x86_64-pc-mingw32/4.4.0/ main.cpp
-mtune=generic -O2 -fpch-preprocess -o main.ii
ignoring duplicate directory
/usr/local/opt/mingw64/bin/../lib/gcc/../../lib/gcc/x86_64-pc-mingw32/4.4.0/../../../../x86_64-pc-mingw32/include/c++/4.4.0
ignoring duplicate directory
/usr/local/opt/mingw64/bin/../lib/gcc/../../lib/gcc/x86_64-pc-mingw32/4.4.0/../../../../x86_64-pc-mingw32/include/c++/4.4.0/x86_64-pc-mingw32
ignoring duplicate directory
/usr/local/opt/mingw64/bin/../lib/gcc/../../lib/gcc/x86_64-pc-mingw32/4.4.0/../../../../x86_64-pc-mingw32/include/c++/4.4.0/backward
ignoring nonexistent directory
/opt/buildbot/mingw-w64/slave-linux/linux-i386/build/root/usr/local/include
ignoring duplicate directory
/usr/local/opt/mingw64/bin/../lib/gcc/../../lib/gcc/x86_64-pc-mingw32/4.4.0/include
ignoring duplicate directory
/usr/local/opt/mingw64/bin/../lib/gcc/../../lib/gcc/x86_64-pc-mingw32/4.4.0/include-fixed
ignoring duplicate directory
/usr/local/opt/mingw64/bin/../lib/gcc/../../lib/gcc/x86_64-pc-mingw32/4.4.0/../../../../x86_64-pc-mingw32/include
ignoring nonexistent directory
/opt/buildbot/mingw-w64/slave-linux/linux-i386/build/root/mingw/include64
#include ... search starts here:
#include ... search starts here:
/usr/local/opt/mingw64/bin/../lib/gcc/x86_64-pc-mingw32/4.4.0/../../../../x86_64-pc-mingw32/include/c++/4.4.0
/usr/local/opt/mingw64/bin/../lib/gcc/x86_64-pc-mingw32/4.4.0/../../../../x86_64-pc-mingw32/include/c++/4.4.0/x86_64-pc-mingw32
/usr/local/opt/mingw64/bin/../lib/gcc/x86_64-pc-mingw32/4.4.0/../../../../x86_64-pc-mingw32/include/c++/4.4.0/backward
/usr/local/opt/mingw64/bin/../lib/gcc/x86_64-pc-mingw32/4.4.0/include
/usr/local/opt/mingw64/bin/../lib/gcc/x86_64-pc-mingw32/4.4.0/include-fixed
/usr/local/opt/mingw64/bin/../lib/gcc/x86_64-pc-mingw32/4.4.0/../../../../x86_64-pc-mingw32/include
End of search list.
COLLECT_GCC_OPTIONS='-O2' '-v' '-save-temps' '-c' '-o' 'main.o'
'-shared-libgcc' '-mtune=generic'
/usr/local/opt/mingw64/bin/../libexec/gcc/x86_64-pc-mingw32/4.4.0/cc1plus
-fpreprocessed main.ii -quiet -dumpbase main.cpp -mtune=generic -auxbase-strip
main.o -O2 -version -o main.s
GNU C++ (GCC) version 4.4.0 20090201 (experimental) (x86_64-pc-mingw32)
compiled by GNU C version 4.3.2 20081105 (Red Hat 4.3.2-7), GMP version
4.2.2, MPFR version 2.3.2.
GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096
Compiler executable checksum: 687eedcb9489aad6b91e300931a51b03
COLLECT_GCC_OPTIONS='-O2' '-v' '-save-temps' '-c' '-o' 'main.o'
'-shared-libgcc' '-mtune=generic'
/usr/local/opt/mingw64/bin/../lib/gcc/x86_64-pc-mingw32/4.4.0/../../../../x86_64-pc-mingw32/bin/as
-o main.o main.s
[Bug c++/39112] incorrect value of a static const double class member
--- Comment #1 from alexey dot pushkin at mererand dot com 2009-02-05 20:27 --- Created an attachment (id=17251) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17251action=view) example -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39112
[Bug rtl-optimization/39110] [4.4 Regression] Revision 143939 breaks bootstrap on Linux/ia64
--- Comment #8 from sje at cup dot hp dot com 2009-02-05 20:41 --- My IA64 HP-UX bootstrap worked but my IA64 Linux bootstrap failed. When building libgfortran the configure script tried to compile: | program foo | real, parameter :: bar = sin (12.34 / 2.5) | end program foo and the Fortran compiler gave a seg fault. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39110
[Bug rtl-optimization/39110] [4.4 Regression] Revision 143939 breaks bootstrap on Linux/ia64
--- Comment #9 from sje at cup dot hp dot com 2009-02-05 20:45 --- Ack, my HP-UX and Linux builds were from two different source trees. The HP-UX build that worked had the patch, the Linux build that failed did not have the patch applied. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39110
[Bug c/39113] New: no warning that a variable may be used uninitialized
$gcc -O -Wextra -save-temps um3.c
$
um3.c
#include stdio.h
main()
{
char *J;
if (rand())
J = NULL;
printf(\ntest %s\n,J);
}
In this example, J could be used uninitialized but the compiler is not giving
that warning.
--
Summary: no warning that a variable may be used uninitialized
Product: gcc
Version: 4.3.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: dhill at clusterresources dot com
GCC build triplet: --build=x86_64-linux-gnu
GCC host triplet: --host=x86_64-linux-gnu
GCC target triplet: --target=x86_64-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39113
[Bug rtl-optimization/39110] [4.4 Regression] Revision 143939 breaks bootstrap on Linux/ia64
--- Comment #10 from hjl dot tools at gmail dot com 2009-02-05 20:50 --- Linux/ia64 is OK now: http://gcc.gnu.org/ml/gcc-testresults/2009-02/msg00543.html -- hjl dot tools at gmail dot com changed: What|Removed |Added Severity|major |critical Status|WAITING |RESOLVED Priority|P3 |P1 Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39110
[Bug c/39113] no warning that a variable may be used uninitialized
--- Comment #1 from dhill at clusterresources dot com 2009-02-05 20:51 --- Created an attachment (id=17252) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17252action=view) .i file -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39113
[Bug c/39113] no warning that a variable may be used uninitialized
--- Comment #2 from dhill at clusterresources dot com 2009-02-05 21:04 --- Here is the gcc -v output if that is helpful $ gcc -v Using built-in specs. Target: x86_64-linux-gnu Configured with: ../src/configure -v --with-pkgversion='Ubuntu 4.3.2-1ubuntu12' --with-bugurl=file:///usr/share/doc/gcc-4.3/README.Bugs --enable-languages=c,c++,fortran,objc,obj-c++ --prefix=/usr --enable-shared --with-system-zlib --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --enable-nls --with-gxx-include-dir=/usr/include/c++/4.3 --program-suffix=-4.3 --enable-clocale=gnu --enable-libstdcxx-debug --enable-objc-gc --enable-mpfr --enable-checking=release --build=x86_64-linux-gnu --host=x86_64-linux-gnu --target=x86_64-linux-gnu Thread model: posix gcc version 4.3.2 (Ubuntu 4.3.2-1ubuntu12) -- dhill at clusterresources dot com changed: What|Removed |Added CC||dhill at clusterresources ||dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39113
[Bug tree-optimization/38953] [graphite] loop closed SSA not maintained by graphite code generation
--- Comment #4 from spop at gcc dot gnu dot org 2009-02-05 21:45 --- Subject: Bug 38953 Author: spop Date: Thu Feb 5 21:44:57 2009 New Revision: 143972 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=143972 Log: 2009-02-05 Sebastian Pop sebastian@amd.com PR middle-end/38953 * graphite.c (if_region_set_false_region): After moving a region in the false branch of a condition, remove the empty dummy basic block. (gloog): Remove wrong fix for PR38953. Modified: branches/graphite/gcc/ChangeLog.graphite branches/graphite/gcc/graphite.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38953
gfortran warnings about unused dummy argument
I am using gcc 4.3.2 on a Linux x86_64 system, compiling *.f and *.f90 source code files with gfortran and using the -Wall option. I am getting several warnings about unused dummy arguments in my code. The warnings are valid, but I would like to suppress them because they are non-trivial to correct in the code. The gcc 4.3 gfortran manual seems to imply that gfortran, unlike the gcc compiler, does not warn about unused dummy arguments. -Wunused-parameter Contrary to gcc's meaning of -Wunused-parameter, gfortran's implementation of this option does not warn about unused dummy arguments, but about unused PARAMETER values. -Wunused-parameter is not included in -Wall but is implied by -Wall -Wextra. In any event, is there a gfortran option to specifically suppress warnings about unused dummy arguments? I still want to receive warnings about unused local variables. Thanks, Julian C. --- Dr. Julian C. Cummings Staff Scientist, Caltech/CACR cummi...@cacr.caltech.edu
[Bug c++/39106] [4.4 Regression] aliased to undefined symbol error with thunks
--- Comment #2 from jakub at gcc dot gnu dot org 2009-02-05 21:54 --- Subject: Bug 39106 Author: jakub Date: Thu Feb 5 21:54:06 2009 New Revision: 143973 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=143973 Log: PR c++/39106 * cgraphunit.c (cgraph_function_versioning): Clear also DECL_VIRTUAL_P on the copied decl. * g++.dg/opt/thunk3.C: New test. Added: trunk/gcc/testsuite/g++.dg/opt/thunk3.C Modified: trunk/gcc/ChangeLog trunk/gcc/cgraphunit.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39106
[Bug tree-optimization/18501] [4.2/4.3/4.4 Regression] Missing 'used uninitialized' warning (CCP)
--- Comment #22 from pinskia at gcc dot gnu dot org 2009-02-05 21:57 --- *** Bug 39113 has been marked as a duplicate of this bug. *** -- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||dhill at clusterresources ||dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18501
[Bug target/37367] [4.4 Regression] gcc-4.4 speed regression
--- Comment #4 from rguenth at gcc dot gnu dot org 2009-02-05 22:03 --- 5% is way below our release criteria threshold. P4. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Priority|P3 |P4 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37367
[Bug c/39113] no warning that a variable may be used uninitialized
--- Comment #4 from pinskia at gcc dot gnu dot org 2009-02-05 21:57 --- *** This bug has been marked as a duplicate of 18501 *** *** This bug has been marked as a duplicate of 18501 *** -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39113
