Hello,
I'd like to get more helpful information from the final .S file, such
as basic block info, so that I can draw a cfg graph through a script.
Perhaps the -fverbose-asm option is the right way to open this
functionality. Here's a simple patch based on the current trunk svn.
Index:
On 3/14/09, Paolo Bonzini bonz...@gnu.org wrote:
Hans-Peter Nilsson wrote:
The answer to the question is no, but I'd guess the more
useful answer is yes, for different definitions of truncate.
Ok, after my patches you will be able to teach GCC about this definition
of truncate.
I
Martin Guy wrote:
On 3/14/09, Paolo Bonzini bonz...@gnu.org wrote:
Hans-Peter Nilsson wrote:
The answer to the question is no, but I'd guess the more
useful answer is yes, for different definitions of truncate.
Ok, after my patches you will be able to teach GCC about this definition
of
Philipp Marek philipp at marek.priv.at writes:
gcc -S tmp.S for some reason prints to stdout, so gcc -S tmp.S tmp.s
is what you need
Thank you very much, I'll take a look.
I tried very hard to achieve that; and one time it seemed to work, but I cannot
make it work again.
As an example I'm
Hi,
Timothy Madden terminato...@gmail.com 写入消息
news:5078d8af0903120218i23b69a4bma28ad9b3f1bd4...@mail.gmail.com...
On Thu, Mar 12, 2009 at 1:15 AM, Jan Hubicka hubi...@ucw.cz wrote:
Timothy Madden wrote:
Hello
Is -mfpmath=both for i386 and x86-64 still experimental in gcc 4.3, as
the in
NightStrike wrote:
On Fri, Mar 13, 2009 at 1:58 PM, Joseph S. Myers
jos...@codesourcery.com wrote:
Given the SC request we need to stay in Stage 4 rather than trying to work
around it.
What if GCC went back to stage 3 until the issue is resolved, thus
opening the door for a number of
On 3/16/09, Paolo Bonzini bonz...@gnu.org wrote:
AND R1, R0, #31
MOV R2, R2, SHIFT R1
ANDS R1, R0, #32
MOVNE R2, R2, SHIFT #31
MOVNE R2, R2, SHIFT #1
or
ANDS R1, R0, #32
MOVNE R2, R2, SHIFT #-32
SUB R1, R1, R0 ; R1 = (x = 32 ? 32 - x : -x)
MOV
Zuxy Meng wrote:
Hi,
Timothy Madden terminato...@gmail.com 写入消息
!
I am sure having twice the number of registers (sse+387) would make a
big difference.
You're not counting the rename registers, you're talking about 32-bit mode
only, and you're discounting the different mode of accessing the
[Resent because of account funnies. Apologies to those who get this twice]
Hi,
This problem is reported every once in a while, all targets with
small
load-immediate instructions suffer from this, especially since GCC
4.0
(i.e. since tree-ssa). But it seems there is just not enough
hi
now i'm trying to construct def-use chain after the PASS_LEAF_REGS.
for the ssa form structure has been destoried during the former
passes.
I have found that gcc provides a way to build the def-use chain in the
PASS_REGRENAME, but it only contains the defs and uses all in one
basic block.
so
villa gogh wrote:
hi
now i'm trying to construct def-use chain after the PASS_LEAF_REGS.
for the ssa form structure has been destoried during the former
passes.
I have found that gcc provides a way to build the def-use chain in the
PASS_REGRENAME, but it only contains the defs and uses all
What about allowing for more backports from the graphite
branch if this drags out for an extended period of time? In
particular, I am thinking of those changes in graphite branch
that might reduce those cases where -fgraphite-identity
degrades the performance of the resulting code.
I got mixed results with icc
for
--
short a;
void g(short);
void f(void)
{ g(a); }
--
it produces a movswl. For
---
void g(int);
void f(short a) {
g(a);
}
--
it produces a movswq.
For the original
Bingfeng Mei wrote:
I just updated our porting to include last 2-3 weeks of GCC
developments. I noticed a large number of test failures at -O1 that
use a user-defined data type (based on a special register file of
our processor). All variables of such type are now spilled to memory
which we
Ramana Radhakrishnan writes:
[Resent because of account funnies. Apologies to those who get this twice]
Hi,
This problem is reported every once in a while, all targets with
small
load-immediate instructions suffer from this, especially since GCC
4.0
(i.e. since tree-ssa). But
Hello,
I just updated our porting to include last 2-3 weeks of GCC developments. I
noticed a large number of test failures at -O1 that use a user-defined data
type (based on a special register file of our processor). All variables of such
type are now spilled to memory which we don't allow at
On Mon, Mar 16, 2009 at 2:52 PM, Ramana Radhakrishnan
ramana.radhakrish...@arm.com wrote:
Wouldn't doing this in CSE only solve the problem within an extended basic
block and not necessarily across the program ? Surely you'd want to do it
globally or am I missing something very basic here ?
On Mon, Mar 16, 2009 at 12:11 PM, Adam Nemet ane...@caviumnetworks.com wrote:
Ramana Radhakrishnan writes:
[Resent because of account funnies. Apologies to those who get this twice]
Hi,
This problem is reported every once in a while, all targets with
small
load-immediate instructions
2009/3/12 Daniel Jacobowitz d...@false.org:
On Thu, Mar 12, 2009 at 02:02:36PM +0100, Joel Porquet wrote:
Check what symbol is at, or near, 0x4003 + 22368. It's probably
the GOT plus a constant bias.
It seems there is nothing at this address. Here is the program header:
Don't know
On Mon, Mar 16, 2009 at 06:19:01PM +0100, Joel Porquet wrote:
2009/3/12 Daniel Jacobowitz d...@false.org:
On Thu, Mar 12, 2009 at 02:02:36PM +0100, Joel Porquet wrote:
Check what symbol is at, or near, 0x4003 + 22368. It's probably
the GOT plus a constant bias.
It seems there is
[ Perhaps we need a somewhat larger audience for this one, as it isn't a
gfortran specific issue (despite the COMMONs). ]
The reporter of this problem (perhaps it's necessary to open a bugzilla
PR) uses:
It is GNU/linux on x86_64, fedora 10
kernel 2.6.27.12-170.2.5.fc10.x86_64
On Mon, Mar 16, 2009 at 7:06 PM, Toon Moene t...@moene.org wrote:
[ Perhaps we need a somewhat larger audience for this one, as it isn't a
gfortran specific issue (despite the COMMONs). ]
The reporter of this problem (perhaps it's necessary to open a bugzilla PR)
uses:
It is GNU/linux on
Eric Fisher joefoxr...@gmail.com writes:
I'd like to get more helpful information from the final .S file, such
as basic block info, so that I can draw a cfg graph through a script.
The basic block information and the CFG graph is not reliable at that
point in the compilation. Your patch will
Ph. Marek phil...@marek.priv.at writes:
Philipp Marek philipp at marek.priv.at writes:
gcc -S tmp.S for some reason prints to stdout, so gcc -S tmp.S tmp.s
is what you need
Thank you very much, I'll take a look.
I tried very hard to achieve that; and one time it seemed to work, but I
Dear all,
I've been working on explaining to GCC the cost of loads/stores on my
target and I arrived to this problem. Consider the following code:
uint64_t sum = 0;
for(i=0; iN; i += 2) { /* N is defined by a macro */
z0 = buff[i];
z1 = buff[i+1];
sum += z0 + z1;
Bingfeng Mei b...@broadcom.com writes:
In foo function, compute_record_mode function will set the mode for
struct COMPLEX as BLKmode partly because STRICT_ALIGNMENT is 1 on my
target. In TARGET_RETURN_IN_MEMORY hook, I return 1 for BLKmode type
and 0 otherwise for small size (8) (like MIPS).
Hi,
I think I found a generic problem for fixed point constant folding.
In fold-const.c:11872 gcc tries to apply:
/* Transform (x c) c into x (-1c), or transform (x
c) c
into x ((unsigned)-1 c) for unsigned types. */
I attached a simple patch which fixes the problem by
--- Comment #2 from ayers at gcc dot gnu dot org 2009-03-16 07:27 ---
So the situation seems to be:
- libobjc is a static library.
- libfoo is a dll statically linked against libobjc.
- test is program which is linked both against libfoo and libobjc.
I'm guessing here since I have no
--- Comment #25 from jakub at gcc dot gnu dot org 2009-03-16 07:52 ---
I'd say first try to add noinline attribute on all callers of num_positive, if
it fails even with those, add also __attribute__((__optimize__(0))) to them one
by one. If the noinline attribute to those makes the
--- Comment #7 from jakub at gcc dot gnu dot org 2009-03-16 08:15 ---
Reduced testcase:
/* { dg-do compile } */
/* { dg-options -O2 -fprefetch-loop-arrays } */
void
foo (char *x, unsigned long y, unsigned char *z)
{
unsigned int c[256], *d;
for (d = c + 1; d c + 256; ++d)
*d
--- Comment #8 from pinskia at gmail dot com 2009-03-16 08:28 ---
Subject: Re: [4.3/4.4 Regression] ICE : in compare_values_warnv, at
tree-vrp.c:1073
Sent from my iPhone
On Mar 16, 2009, at 1:15 AM, jakub at gcc dot gnu dot org
gcc-bugzi...@gcc.gnu.org
wrote:
--- Comment
--- Comment #5 from steven at gcc dot gnu dot org 2009-03-16 08:46 ---
Can someone point me to the IA64 optimiation manuals mentioned in comment #0?
I'm looking for some answers, for example:
* Which branch registers can I use? bt-load can actually perform register
renaming. It has
--- Comment #9 from jakub at gcc dot gnu dot org 2009-03-16 08:49 ---
No, this seems to be aprefetch's pass fault, at least in quick skim
*.cunroll seems to be ok typewise, while *.aprefetch has:
D.1649_44 = c + 1024;
D.1650_43 = (long unsigned int) D.1649_44;
if (c[2] =
--- Comment #9 from ktietz at gcc dot gnu dot org 2009-03-16 09:15 ---
(In reply to comment #8)
(In reply to comment #7)
The following patch solves this problem and prevents the name collision for
32
and 64 bits win32 systems.
ChangeLog
* config/i386/i386.md
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Known to fail||4.3.3
Known to work|4.2.4 |4.2.4 4.4.0
--- Comment #10 from jakub at gcc dot gnu dot org 2009-03-16 09:43 ---
Seems tree-ssa-loop-niter.c has a lot of p+ issues. The following untested
patch fixes just the number_of_iterations_lt_to_ne bugs and fixes this
testcase:
--- gcc/tree-ssa-loop-niter.c.jj2009-03-04
--- Comment #19 from falk at debian dot org 2009-03-16 10:24 ---
(In reply to comment #18)
Well, I've got bad news for you anyway:
it seems that the problem affects gcc-4.3.2 too:
it seems it's reproducible in another app,
however one potentially much harder to debug.
Please read
--- Comment #3 from js-gcc at webkeks dot org 2009-03-16 11:24 ---
When the target is mingw32, it seems that libobjc is only built as a static
library. This isn't a bad idea after all, because I guess no win32 user has a
libobjc.so installed somewhere, so you would need to ship that
--- Comment #2 from mkuvyrkov at gcc dot gnu dot org 2009-03-16 11:35
---
Would you please attach a preprocessed testcase so one can reproduce the
problem.
--
mkuvyrkov at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #4 from ayers at gcc dot gnu dot org 2009-03-16 11:41 ---
Well, consider me a GNUstep guy yet I'm definitely not a GNUstep on MinGW32
guy. (Or anything on MinGW32... which is why this a bit difficult, yet I'm
trying to help maintain libobjc so I'll see what I can do.)
Could
--- Comment #5 from js-gcc at webkeks dot org 2009-03-16 11:46 ---
It would be hard to link to that discussion as that was IRL on FOSDEM in the
GNUstep Dev Room :).
I reported that bug once on the mingw32 list, but they wouldn't really care
about it. After speaking to Nicola Pero on
--- Comment #1 from jan dot kratochvil at redhat dot com 2009-03-16 14:24
---
Verified as the problem exists on GNU C++ 4.4.0 20090315 (experimental).
Tried also non-main function and slightly complicated function.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37890
Regression from g++-4.3 for GNU C++ 4.4.0 20090315 (experimental)
(+also for 4.4.0 20090313 (Red Hat 4.4.0-0.26))
For full namespace import one should use DW_TAG_imported_module.
1:namespace A
2:{
3: int i = 1;
4:}
5:
6:int
7:main ()
8:{
9: using namespace A;
10: i = 2;
11: return 0;
12:}
--- Comment #11 from jakub at gcc dot gnu dot org 2009-03-16 16:07 ---
Subject: Bug 39455
Author: jakub
Date: Mon Mar 16 16:07:07 2009
New Revision: 144885
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=144885
Log:
PR tree-optimization/39455
*
--- Comment #12 from jakub at gcc dot gnu dot org 2009-03-16 16:27 ---
Fixed on the trunk so far.
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
Known
UEFI uses MS x64 calling convention. It will be nice to
support -mabi=ms on Linux so that we can use gcc 4.4
to build UEFI applications on Linux.
--
Summary: Add -mabi=[ms|sysv]
Product: gcc
Version: 4.4.0
Status: UNCONFIRMED
Severity:
--- Comment #4 from balrogg at gmail dot com 2009-03-16 16:53 ---
Reopening because
int params; __asm__ (xxx : =X (params));
and
int params[1]; __asm__ (xxx : =X (params[0]));
still produce different output in a way that is undocumented.
--
balrogg at gmail dot com changed:
--- Comment #5 from pinskia at gcc dot gnu dot org 2009-03-16 17:02 ---
(In reply to comment #4)
Reopening because
int params; __asm__ (xxx : =X (params));
and
int params[1]; __asm__ (xxx : =X (params[0]));
still produce different output in a way that is undocumented.
How so? =X
--- Comment #26 from dave at hiauly1 dot hia dot nrc dot ca 2009-03-16
17:20 ---
Subject: Re: [4.4 Regression] Revision 144529 miscompiled libcpp/expr.c
Since revision 144529:
http://gcc.gnu.org/ml/gcc-patches/2009-03/msg0.html
is the cause and it is inline related, I
--- Comment #27 from hjl dot tools at gmail dot com 2009-03-16 17:26
---
(In reply to comment #26)
Probably, I should rebuild 144529 and try Jakub's suggestions.
You need the fix for PR 39345 on top of revision 144529.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39355
untyped_call in i386.md has
ix86_expand_call ((TARGET_FLOAT_RETURNS_IN_80387
? gen_rtx_REG (XCmode, FIRST_FLOAT_REG) : NULL),
operands[0], const0_rtx,
GEN_INT ((DEFAULT_ABI == SYSV_ABI ? X86_64_SSE_REGPARM_MAX
--- Comment #1 from hjl dot tools at gmail dot com 2009-03-16 18:26 ---
Also
void
ix86_expand_call (rtx retval, rtx fnaddr, rtx callarg1,
rtx callarg2,
rtx pop, int sibcall)
{
rtx use = NULL, call;
enum calling_abi function_call_abi;
if
--- Comment #2 from hjl dot tools at gmail dot com 2009-03-16 18:40 ---
(In reply to comment #1)
Also
void
ix86_expand_call (rtx retval, rtx fnaddr, rtx callarg1,
rtx callarg2,
rtx pop, int sibcall)
{
rtx use = NULL, call;
enum
--- Comment #3 from hjl dot tools at gmail dot com 2009-03-16 18:47 ---
(In reply to comment #0)
untyped_call in i386.md has
ix86_expand_call ((TARGET_FLOAT_RETURNS_IN_80387
? gen_rtx_REG (XCmode, FIRST_FLOAT_REG) : NULL),
operands[0],
It is a regression since gcc-4.3 but it was found only at artificial (GDB)
testcase. Also at -O2 such behavior is even expected.
The variable is considered as optimized-out which should not happen on -O0.
Testcase:
--
The current implementation returns misleading results if used the wrong way. A
simple example is:
#include iostream
struct X;
int main()
{
std::cout __is_abstract(X) std::endl;
}
compiles and prints 0. Things get worse when templates are involved. PR
libstdc++/39405 shows why this can be a
--- Comment #1 from d dot frey at gmx dot de 2009-03-16 19:05 ---
Created an attachment (id=17468)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17468action=view)
show inconsistency for is_abstract
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39475
--- Comment #6 from wilson at codesourcery dot com 2009-03-16 19:07 ---
Subject: Re: Branch registers loaded too late
on ia64
steven at gcc dot gnu dot org wrote:
--- Comment #5 from steven at gcc dot gnu dot org 2009-03-16 08:46
---
Can someone point me to the IA64
--- Comment #27 from d dot frey at gmx dot de 2009-03-16 19:08 ---
Thanks Paolo. I've opened PR c++/39475 for the type traits intrinsics.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39405
--- Comment #2 from paolo dot carlini at oracle dot com 2009-03-16 19:20
---
Indeed, ICC errors out.
--
paolo dot carlini at oracle dot com changed:
What|Removed |Added
--- Comment #4 from hjl dot tools at gmail dot com 2009-03-16 19:21 ---
A patch is posed at
http://gcc.gnu.org/ml/gcc-patches/2009-03/msg00749.html
--
hjl dot tools at gmail dot com changed:
What|Removed |Added
--- Comment #1 from janis at gcc dot gnu dot org 2009-03-16 19:58 ---
Subject: Bug 37628
Author: janis
Date: Mon Mar 16 19:58:32 2009
New Revision: 144890
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=144890
Log:
PR testsuite/37628
*
--- Comment #2 from janis at gcc dot gnu dot org 2009-03-16 19:59 ---
Subject: Bug 37630
Author: janis
Date: Mon Mar 16 19:59:37 2009
New Revision: 144891
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=144891
Log:
PR testsuite/37630
* lib/target-supports.exp
--- Comment #10 from janis at gcc dot gnu dot org 2009-03-16 20:01 ---
Subject: Bug 37960
Author: janis
Date: Mon Mar 16 20:01:15 2009
New Revision: 144892
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=144892
Log:
PR testsuite/37960
* gcc.dg/pr11492.c: Replace
--- Comment #1 from jakub at gcc dot gnu dot org 2009-03-16 20:55 ---
Created an attachment (id=17469)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17469action=view)
gcc44-pr39471.patch
Untested patch. Dodji, any reason why you started emitting
DW_TAG_imported_declaration for
--- Comment #5 from hjl dot tools at gmail dot com 2009-03-16 21:00 ---
An updated patch is posted at
http://gcc.gnu.org/ml/gcc-patches/2009-03/msg00754.html
--
hjl dot tools at gmail dot com changed:
What|Removed |Added
--- Comment #3 from janis at gcc dot gnu dot org 2009-03-16 21:12 ---
Subject: Bug 37630
Author: janis
Date: Mon Mar 16 21:11:57 2009
New Revision: 144893
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=144893
Log:
Revert patch for PR testsuite/37630.
Modified:
--- Comment #6 from pluto at agmk dot net 2009-03-16 21:24 ---
i've tested u-dw2.exe on wine and got more info.
$ ./u-dw2.exe
err:process:start_wineboot failed to start wineboot, err 2
err:process:__wine_kernel_init boot event wait timed out
fixme:msvcrt:__lconv_init stub
foo:enter
--- Comment #2 from jan dot kratochvil at redhat dot com 2009-03-16 21:37
---
Thanks although there is still excessive DW_AT_name:
3422: Abbrev Number: 12 (DW_TAG_imported_module)
425 DW_AT_name: A
427 DW_AT_import : 0x113 [Abbrev Number: 2 (DW_TAG_namespace)]
ix86_function_regparm in i386.c has
if (TARGET_64BIT)
{
if (ix86_function_type_abi (type) == ix86_abi)
return regparm;
return ix86_abi != SYSV_ABI ? X86_64_REGPARM_MAX : X64_REGPARM_MAX;
}
Shouldn't it be
return ix86_abi == SYSV_ABI ? X86_64_REGPARM_MAX :
--- Comment #1 from hjl dot tools at gmail dot com 2009-03-16 21:59 ---
It is
if (TARGET_64BIT)
{
if (ix86_function_type_abi (type) == DEFAULT_ABI)
return regparm;
return DEFAULT_ABI != SYSV_ABI ? X86_64_REGPARM_MAX : X64_REGPARM_MAX;
}
Shouldn't it be
--- Comment #2 from rob1weld at aol dot com 2009-03-16 22:08 ---
My next difficulty (on OpenSolaris) is the lack of a fopencookie()
function (and the related support in FILE). I'm now building melt
on i686-pc-linux-gnu and running into a few other errors; thus melt
does need some
--- Comment #2 from hjl dot tools at gmail dot com 2009-03-16 22:09 ---
We never change regparm for 64bit. Does this patch
Index: gcc/config/i386/i386.c
===
--- gcc/config/i386/i386.c (revision 144817)
+++
--- Comment #3 from il dot basso dot buffo at gmail dot com 2009-03-16
22:21 ---
Here's a further reduction:
struct Point
{
int line, col;
Point( int l = -1, int c = 0 ) throw() : line( l ), col( c ) {}
bool operator==( const Point p ) const throw()
{ return ( line ==
--- Comment #4 from il dot basso dot buffo at gmail dot com 2009-03-16
22:24 ---
Bah, here's an even smaller example:
struct Point
{
int line, col;
Point( int l = -1, int c = 0 ) throw() : line( l ), col( c ) {}
bool operator==( const Point p ) const throw()
{ return (
Thanks for the reduced testcase, it completely went out of my radar
(by now my delta script should have finished reducing it as well on
the gcc-farm, but I won't even look at it).
Thanks again for the reduced case. I will look at the bug now.
Sebastian
--- Comment #5 from sebpop at gmail dot com 2009-03-16 22:34 ---
Subject: Re: ICE in create_data_ref with -O1
-floop-interchange
Thanks for the reduced testcase, it completely went out of my radar
(by now my delta script should have finished reducing it as well on
the
--- Comment #1 from rguenth at gcc dot gnu dot org 2009-03-16 22:59 ---
Well, it doesn't even have a value assigned. So I consider this a valid
optimization for -O0. Does the variable have a location once you inintialize
it?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39474
--- Comment #2 from rearnsha at gcc dot gnu dot org 2009-03-16 22:53
---
Confirmed. This is a bug in the arith_adjacent_mem pattern that only triggers
when the offset to the memory from the base pointer exceeds the range of a
simple add instruction (ie more than 1024 bytes). In that
--
rearnsha at gcc dot gnu dot org changed:
What|Removed |Added
Keywords||wrong-code
Priority|P3 |P2
Hi,
I don't know who coded the overly complicated exclude_component_ref.
In the graphite branch we already cleaned up all this code, but in
trunk we still have it.
Attached is a patch that fixes the problem by looking at whether the
operand contains COMPONENT_REFs before calling the data
--- Comment #6 from sebpop at gmail dot com 2009-03-16 23:18 ---
Subject: Re: ICE in create_data_ref with -O1
-floop-interchange
Hi,
I don't know who coded the overly complicated exclude_component_ref.
In the graphite branch we already cleaned up all this code, but in
trunk
--- Comment #2 from rearnsha at gcc dot gnu dot org 2009-03-16 23:27
---
I believe this is a bug in the way we expand local reg vars. The manual says:
Local register variables in specific registers do not reserve the
registers, except at the point where they are used as input or
--- Comment #2 from rearnsha at gcc dot gnu dot org 2009-03-16 23:38
---
Confirmed. We need a way to represent an early-clobber between a register and
a memory-address with side-effects.
--
rearnsha at gcc dot gnu dot org changed:
What|Removed
--
rearnsha at gcc dot gnu dot org changed:
What|Removed |Added
Keywords||wrong-code
Priority|P3 |P2
--- Comment #3 from d dot frey at gmx dot de 2009-03-16 23:49 ---
One more thought on the diagnostics: There are two cases: Incomplete types
(like in the initial example in the description of this PR) and recursive
template instantiations (see attachment). I think the latter produces a
--- Comment #6 from ayers at gcc dot gnu dot org 2009-03-16 23:51 ---
I've played a bit with creating a trivial static library and linking into an
dynamic library and into an executable. After tweaking back and forth it seems
that at least on GNU/Linux the static version linked into
--- Comment #2 from rearnsha at gcc dot gnu dot org 2009-03-17 00:03
---
Confirmed, this is a nasty bug that might silently bite users after a long
period of apparently correct operation.
--
rearnsha at gcc dot gnu dot org changed:
What|Removed
--- Comment #4 from ramana dot r at gmail dot com 2009-03-17 00:05 ---
Still present with 4.4 mainline as on 20090312 revision. It looks like some
sort of relic left behind with the calculations of the soft frame pointer.
Maybe a peephole will help.
--
ramana dot r at gmail dot com
--- Comment #10 from ramana dot r at gmail dot com 2009-03-17 00:11 ---
This should be a target bug. Also with mainline the testcase empty described in
comment #9 appears fixed.
--
ramana dot r at gmail dot com changed:
What|Removed |Added
--- Comment #5 from rearnsha at gcc dot gnu dot org 2009-03-17 00:15
---
This is a case where early splitting (before register allocation) of a constant
in a plus expression leads to poor code. We should try disabling the split of
a plus when combined with the internal frame pointer.
extend.texi has
---
@item regparm (@var{number})
@cindex @code{regparm} attribute
@cindex functions that are passed arguments in registers on the 386
On the Intel 386, the @code{regparm} attribute causes the compiler to
pass arguments number one to @var{number} if they are of integral type
in
--
hjl dot tools at gmail dot com changed:
What|Removed |Added
GCC target triplet||i686-pc-linux-gnu
Target Milestone|---
--- Comment #4 from paolo dot carlini at oracle dot com 2009-03-17 00:34
---
Maybe Daniel, but this is a completely separate issue.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39475
--- Comment #1 from hjl dot tools at gmail dot com 2009-03-17 00:45 ---
A patch is posted at
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39477
--
hjl dot tools at gmail dot com changed:
What|Removed |Added
--- Comment #3 from hjl dot tools at gmail dot com 2009-03-17 01:24 ---
A patch is posted at
http://gcc.gnu.org/ml/gcc-patches/2009-03/msg00761.html
--
hjl dot tools at gmail dot com changed:
What|Removed |Added
--
hjl dot tools at gmail dot com changed:
What|Removed |Added
Target Milestone|--- |4.4.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39473
--- Comment #1 from hp at gcc dot gnu dot org 2009-03-17 04:18 ---
Does this still happen? See also PR38609.
--
hp at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #9 from hp at gcc dot gnu dot org 2009-03-17 05:35 ---
(In reply to comment #8)
Guess it probably won't be TARGET_BUILTIN_SETJMP_FRAME_VALUE then.
At any rate, changing it to hard_frame_pointer_rtx doesn't help by itself.
(Resulting diffs in RTL dumps are gone after
99 matches
Mail list logo
