On 07/14/2009 09:17 PM, Benjamin Kosnik wrote:
Hey Ralf! Saw your message about updating gcc/src to current auto
tools, in favor. But, it looks like the autoconf 2.64 release is not
out, last I see is 2.63b at the end of March. This and
confirmation of --with-build-sysroot working seem to be the
Andrew Stubbs wrote:
I'm having trouble with an ICE, and I'm hoping somebody can enlighten me.
Given the following command:
cc1 -fpreprocessed ../pr34330.i -quiet -dumpbase pr34330.c -da -mb
-auxbase-strip pr34330.c -Os -version -ftree-parallelize-loops=4
-ftree-vectorize -o pr34330.s
We are a young studio from Argentina that specializes in motion
graphics productions in both 2D 3D for TV, films and web. We are very
interested to offer you our production services. I hope we can work
together soon, best!
check out our last reel http://www.bluna.tv
PATRICIO H. YAMUS
+5411 155
Hi Richard,
Maybe you could look into this thread and give us
some suggestion/confirmation.
Now we plan to use dr_may_alias_p (DR1, DR2) to partition
the alias set.
http://groups.google.de/group/gcc-graphite/browse_thread/thread/7bffbe9037b5adf4?hl=en
Thanks,
Li
On Wed, Jul 15, 2009 at 5:34 AM,
On Tue, 2009-07-14 at 23:34 +0200, Richard Guenther wrote:
On Tue, Jul 14, 2009 at 6:08 PM, Sebastian Popseb...@gmail.com wrote:
On Tue, Jul 14, 2009 at 11:03, Sebastian Popseb...@gmail.com wrote:
Why do you need alias-set numbers?
We want to represent the alias set information as an
On Wed, Jul 15, 2009 at 1:00 PM, Tobias
Grossergros...@fim.uni-passau.de wrote:
On Tue, 2009-07-14 at 23:34 +0200, Richard Guenther wrote:
On Tue, Jul 14, 2009 at 6:08 PM, Sebastian Popseb...@gmail.com wrote:
On Tue, Jul 14, 2009 at 11:03, Sebastian Popseb...@gmail.com wrote:
Why do you need
A first release candidate for GCC 4.4.1 is available from
ftp://gcc.gnu.org/pub/gcc/snapshots/4.4.1-RC-20090715
and shortly its mirrors. It has been generated from SVN revision 149684.
I have so far bootstrapped and tested the release candidate on
x86_64-linux and i686-linux. Please test
Status
==
GCC 4.4.1 Release Candidate 1 has been released, the branch is now
frozen until GCC 4.4.1 is released, all check-ins require explicit
approval from one of the RMs. Please report any 4.4.1 blockers
as soon as possible. If all goes well, 4.4.1 will be released next
week.
Quality
Status
==
The trunk is in Stage 1. We expect that Stage 1 will last through
at least July and August.
There are still large pending merges we are aware of, specifically
the VTA, LTO and Graphite branches will be considered when deciding
when to go to Stage 3.
Quality Data
Ah ok, so I can see why it would not be able to perform that
optimization around the loop but I changed the code to simply have
this:
uint64_t foo (void)
{
return data[0] + data[1] + data[2];
}
And this generates :
la r9,data
la r7,data+8
ldd r6,0(r7)
ldd r8,0(r9)
ldd
I agree. I've actually pretty much finished that change and it seems
to be stable. I think it will be more maintainable in the
constraints.md state than it was before,
Thanks again,
Jc
On Wed, Jul 15, 2009 at 1:30 AM, Paolo Bonzinibonz...@gnu.org wrote:
On 07/14/2009 10:31 PM, Jean Christophe
Jean Christophe Beyler jean.christophe.bey...@gmail.com writes:
uint64_t foo (void)
{
return data[0] + data[1] + data[2];
}
And this generates :
la r9,data
la r7,data+8
ldd r6,0(r7)
ldd r8,0(r9)
ldd r7,16(r9)
I'm trying to see if there is a problem with my
The subreg pass has this :
(insn 5 2 6 2 ex1b.c:8 (set (reg/f:DI 74)
(const:DI (plus:DI (symbol_ref:DI (data) var_decl 0xb7d35058 data)
(const_int 8 [0x8] 71 {movdi_internal} (nil))
(insn 6 5 7 2 ex1b.c:8 (set (reg/f:DI 75)
(symbol_ref:DI (data) var_decl
On 07/12/2009 12:30 PM, Douglas B Rupp wrote:
I've been working on bringing the VMS patches up to date. The VMS
Debugger requires a label at end prologue and begin_epilogue, and the
fact that final_scan_insn makes multiple calls to NOTE_INSN_EPILOGUE_BEG
for the same function makes this
[ Moved to gcc@ ]
On Wed, Jul 15, 2009 at 14:30, Olatunji Ruwasetjruw...@google.com wrote:
Has any decision being made on how plugins will be distributed with
future releases. Is there going to be a plugins directory ?.
Thanks
We may want to produce some plugins that are useful for GCC
Sorry that I wasn't very specific with my question. I m currently
wrapping up the conversion of
mudflap into a plugin. Most of the required patches have being
approved and committed, so I was
thinking ahead as to where the the plugin code will reside.
Thanks for the information and the link
On 07/13/2009 07:35 AM, Mohamed Shafi wrote:
So i made both TARGET_STRICT_ARGUMENT_NAMING and
PRETEND_OUTGOING_VARARGS_NAMED to return false. Is this correct?
Yes.
How to make the varargs argument to be promoted to 32bits when the
normal argument don't require promotion as mentioned in point
On Wed, Jul 15, 2009 at 14:50, Olatunji Ruwasetjruw...@google.com wrote:
Sorry that I wasn't very specific with my question. I m currently
wrapping up the conversion of
mudflap into a plugin. Most of the required patches have being
approved and committed, so I was
thinking ahead as to
On Wed, 2009-07-15 at 13:26 +0200, Richard Guenther wrote:
On Wed, Jul 15, 2009 at 1:00 PM, Tobias
Grossergros...@fim.uni-passau.de wrote:
On Tue, 2009-07-14 at 23:34 +0200, Richard Guenther wrote:
On Tue, Jul 14, 2009 at 6:08 PM, Sebastian Popseb...@gmail.com wrote:
On Tue, Jul 14, 2009
On Wed, 15 Jul 2009, Diego Novillo wrote:
In general I think spinning off modules/passes that are not used very
frequently (e.g. the tree browser) is a good idea since it reduces the
size of our code base.
Before moving something out to a plugin (if we think that is technically
appropriate
Richard Henderson wrote:
On 07/12/2009 12:30 PM, Douglas B Rupp wrote:
There really are multiple epilogues. The compiler is quite happy to
generate those, and has been happy to do so for some time.
What has changed is that we're now bothering to tell the debug info
about these epilogue
After configuring
Target: x86_64-unknown-linux-gnu
gcc version 4.5.0 20090715 (experimental) [trunk revision 149654] (GCC)
with
../../mainline/configure --enable-checking=release
--prefix=/pkgs/gcc-mainline-mem-stats --enable-languages=c
--enable-gather-detailed-mem-stats
I get
On 07/15/2009 09:36 PM, Joseph S. Myers wrote:
Before moving something out to a plugin (if we think that is technically
appropriate for the particular code in question) we should have a way to
build code, set up to be built as a plugin, into the compiler so that the
-fplugin options find the
On Wed, Jul 15, 2009 at 9:15 PM, Tobias
Grossergros...@fim.uni-passau.de wrote:
A note on Lis final graph algorithm. I don't understand why you want
to allow data-references to be part of multiple alias-sets? (Of course
I don't know how you are going to use the alias-sets ...)
Just to pass
On Wed, Jul 15, 2009 at 10:46 PM, Richard
Guentherrichard.guent...@gmail.com wrote:
On Wed, Jul 15, 2009 at 9:15 PM, Tobias
Grossergros...@fim.uni-passau.de wrote:
A note on Lis final graph algorithm. I don't understand why you want
to allow data-references to be part of multiple alias-sets?
On Wed, 15 Jul 2009, Paolo Bonzini wrote:
On 07/15/2009 09:36 PM, Joseph S. Myers wrote:
Before moving something out to a plugin (if we think that is technically
appropriate for the particular code in question) we should have a way to
build code, set up to be built as a plugin, into the
Joseph S. Myers wrote:
On Wed, 15 Jul 2009, Paolo Bonzini wrote:
On 07/15/2009 09:36 PM, Joseph S. Myers wrote:
Before moving something out to a plugin (if we think that is technically
appropriate for the particular code in question) we should have a way to
build code, set up to be
On 07/15/2009 10:47 PM, Joseph S. Myers wrote:
Unless libltdl can be statically linked in, using it is a bad idea for
other reasons as previously discussed at length.
I know of no program that dynamically links to libltdl, actually.
Paolo
On Wed, 2009-07-15 at 22:48 +0200, Richard Guenther wrote:
On Wed, Jul 15, 2009 at 10:46 PM, Richard
Guentherrichard.guent...@gmail.com wrote:
On Wed, Jul 15, 2009 at 9:15 PM, Tobias
Grossergros...@fim.uni-passau.de wrote:
A note on Lis final graph algorithm. I don't understand why you
LEB0 and LEB1 are duplicated in the attached ivms assembly file from
libgcc2. Note the first occurrence of each is at the prologue end,
which makes no sense to me.
FYI: I'm emitting the LPE labels at NOTE_INSN_FUNCTION_BEG and the LEB
labels at NOTE_INSN_EPILOGUE_BEG. I can send you the
Hi. I started looking at what it would take to convert zlib to build
with c++.
First off, it's not GPL. Are there any issues with modifying the code
checked into the tree?
Next, it uses automake, which seems to assume that a .c file should be
compiled with CC, and not CXX. I get the
Jerry Quinn jlqu...@optonline.net writes:
Hi. I started looking at what it would take to convert zlib to build
with c++.
The zlib library in gcc is actually a copy of upstream sources, so I
don't think it would be a good idea to make this change. We should stay
as close to the upstream
On Wed, 2009-07-15 at 19:07 -0700, Ian Lance Taylor wrote:
Jerry Quinn jlqu...@optonline.net writes:
Hi. I started looking at what it would take to convert zlib to build
with c++.
The zlib library in gcc is actually a copy of upstream sources, so I
don't think it would be a good idea
Hello, I've been trying to write a program that links to static
libraries, and I've been having a lot of difficulties. Was wondering
if someone can help me identify what's going wrong.
The codebase is large, but is new to linux. It was originally
developed on windows and then ported to linux.
Jerry Quinn jlqu...@optonline.net writes:
It does mean that we will always have to have c++ and c available to
bootstrap. Was one of the goals to remove the need for a host C
compiler?
No, removing the need for a host C compiler was not a goal.
Meanwhile, I'm working on libdecnumber...
Zachary Turner divisorthe...@gmail.com writes:
The codebase is large, but is new to linux. It was originally
developed on windows and then ported to linux. It makes heavy use of
C++, STL, and boost and we'd like to (if possible) link *everything*
statically. This means libc, libgcc,
The testcase from PR/2161:
#define ONE else if (0) { }
#define TEN ONE ONE ONE ONE ONE ONE ONE ONE ONE ONE
#define HUN TEN TEN TEN TEN TEN TEN TEN TEN TEN TEN
#define THOUHUN HUN HUN HUN HUN HUN HUN HUN HUN HUN
void foo()
{
if (0) { }
/* 11,000 else if's. */
THOU THOU THOU
--- Comment #32 from bonzini at gnu dot org 2009-07-15 06:05 ---
Yes, but I don't think it's infinite recursion. There are 11,000 else ifs in
the testcase.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40597
--- Comment #1 from bonzini at gnu dot org 2009-07-15 06:06 ---
A regression from when, well, there was no gimplifier.
--
bonzini at gnu dot org changed:
What|Removed |Added
--- Comment #28 from burnus at gcc dot gnu dot org 2009-07-15 06:08 ---
In a quick scan of the patch, I note that the mpfr versions
of the simplifications weren't in the patch.
MPFR or MPC? The MPFR version should be there since years; the MPC version of
tan/sinh/cosh/tanh should be
#define ONE while (b())
#define TEN ONE ONE ONE ONE ONE ONE ONE ONE ONE ONE
#define HUN TEN TEN TEN TEN TEN TEN TEN TEN TEN TEN
#define THOUHUN HUN HUN HUN HUN HUN HUN HUN HUN HUN
void foo()
{
/* 11,000 nested whiles. */
THOU THOU THOU THOU THOU THOU THOU THOU THOU THOU THOU
--- Comment #2 from ebotcazou at gcc dot gnu dot org 2009-07-15 06:27
---
Thanks for the report, but we need a preprocessed testcase, see instructions at
http://gcc.gnu.org/bugs.html
--
ebotcazou at gcc dot gnu dot org changed:
What|Removed
Seen on Ubuntu Hardy. The -O2 result seems to be wrong. Also valgrind says
this about the -O2 compilation:
==6729== Conditional jump or move depends on uninitialised value(s)
==6729==at 0x84F22CB: solve_graph (tree-ssa-structalias.c:1570)
reg...@john-home:~/volatile/tmp174$ current-gcc
--- Comment #1 from steven at gcc dot gnu dot org 2009-07-15 07:21 ---
Ack.
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
Known to fail||4.5.0
Known to work||4.3.0
Target
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.5.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40500
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.5.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40543
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Last
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.5.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40596
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Last
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.5.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40660
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.5.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40671
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.5.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40700
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.5.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40701
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.5.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40743
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.4.2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39533
--- Comment #12 from steven at gcc dot gnu dot org 2009-07-15 07:30 ---
Tom, ping.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39533
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.4.2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40154
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.4.2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40714
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.4.2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40747
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.3.5
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40760
--- Comment #8 from steven at gcc dot gnu dot org 2009-07-15 07:34 ---
Does seem to be a real issue, somewhere.
When trunk builds again, can you please give it a try too?
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #3 from steven at gcc dot gnu dot org 2009-07-15 07:36 ---
Paul, ping. This is almost 3 years with zero progress. If this is not an
issue in GCC 4.3 or later, then please close this PR.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28547
--- Comment #8 from steven at gcc dot gnu dot org 2009-07-15 07:38 ---
The audit log for this PR is awfully quiet... Ping?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28457
--
burnus at gcc dot gnu dot org changed:
What|Removed |Added
GCC build triplet|sparc-unknown-linux-gnu |
GCC host triplet|sparc-unknown-linux-gnu |
GCC target
--- Comment #8 from burnus at gcc dot gnu dot org 2009-07-15 07:42 ---
I pointed this out to Paul already, but appearantly it is still stuck in his
whole-file patch queue.
Last incarnation of that patch (containing this fix) is at:
--- Comment #5 from dcb314 at hotmail dot com 2009-07-15 07:44 ---
(In reply to comment #4)
Fixed by the patch for PR debug/40705
I don't think so.
I tried the code on snapshot 20090709 and it still hangs.
By the way, how can a fix for a crash also fix a hang ?
I would have thought
--- Comment #1 from steven at gcc dot gnu dot org 2009-07-15 07:46 ---
Richi, this looks like it should go into your bucket of things to look at:
==6729== Conditional jump or move depends on uninitialised value(s)
==6729==at 0x84F22CB: solve_graph (tree-ssa-structalias.c:1570)
--
--- Comment #6 from photon at seznam dot cz 2009-07-15 07:50 ---
(In reply to comment #1)
Theses are not false warnings:
c = 1;
is really c = (int)c 1;
They are false warnings. The implicit conversion cannot alter the value.
--
--- Comment #6 from jason at redhat dot com 2009-07-15 07:51 ---
Subject: Re: [4.5 Regression] compiler hang for C++ code
On 07/15/2009 09:44 AM, dcb314 at hotmail dot com wrote:
I tried the code on snapshot 20090709 and it still hangs.
The patch wasn't in that snapshot; it wasn't
--- Comment #7 from photon at seznam dot cz 2009-07-15 07:54 ---
(In reply to comment #5)
Then, let's keep this around as an enhancement request.
I think this is actually a bug as the specification of the warning is: Warn for
implicit conversions that may alter a value. This is not
--- Comment #7 from carrot at google dot com 2009-07-15 08:07 ---
(In reply to comment #6)
Carrot, can you please try this test case with my patch
crossjump_abstract.diff from Bug 20070 applied?
I tried your patch. It did remove the redundant memory load. Following is the
output
--- Comment #8 from pinskia at gcc dot gnu dot org 2009-07-15 08:13 ---
For:
c += (char) 1;
The value can change as you have a wrapping if c is CHAR_MAX.
Likewise with:
c += c2;
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40752
--- Comment #1 from ubizjak at gmail dot com 2009-07-15 08:19 ---
Confirmed on i686 (x86_64 with -m32):
Program received signal SIGSEGV, Segmentation fault.
useless_type_conversion_p (outer_type=0x2ac18624b240, inner_type=0x0)
at ../../gcc-svn/trunk/gcc/tree-ssa.c:1003
1003 if
--- Comment #5 from sezeroz at gmail dot com 2009-07-15 08:19 ---
This bug may result in unreliable binary outputs, why is it targeted for fixing
in 4.4.2 and not in 4.4.1?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40747
--
ubizjak at gmail dot com changed:
What|Removed |Added
Target Milestone|--- |4.5.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40759
--- Comment #6 from jakub at gcc dot gnu dot org 2009-07-15 08:28 ---
I'm already bootstrapping/regtesting a fix, will post afterwards.
If it gets approved quickly, I'll include it in 4.4.1-rc1 I plan to roll today.
--
jakub at gcc dot gnu dot org changed:
What
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
Priority|P3 |P1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40747
--- Comment #17 from jakub at gcc dot gnu dot org 2009-07-15 08:32 ---
Retargetting to 4.4.2, this doesn't seem to get to resolution soon enough.
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #8 from janus at gcc dot gnu dot org 2009-07-15 08:41 ---
Subject: Bug 40743
Author: janus
Date: Wed Jul 15 08:41:29 2009
New Revision: 149662
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=149662
Log:
2009-07-15 Janus Weil ja...@gcc.gnu.org
PR
--- Comment #9 from janus at gcc dot gnu dot org 2009-07-15 08:47 ---
Fixed with r149662. Closing.
--
janus at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #3 from rguenth at gcc dot gnu dot org 2009-07-15 09:25 ---
Subject: Bug 40753
Author: rguenth
Date: Wed Jul 15 09:25:34 2009
New Revision: 149664
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=149664
Log:
2009-07-15 Richard Guenther rguent...@suse.de
PR
--- Comment #2 from rguenth at gcc dot gnu dot org 2009-07-15 09:34 ---
switch-conversion could try to handle this. Generally perfect hashing during
switch expansion is another thing.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #1 from rguenth at gcc dot gnu dot org 2009-07-15 09:37 ---
Confirmed. 4.2 reports
g++-4.2 -Wall t.C
t.C: In function const A a():
t.C:6: warning: control reaches end of non-void function
--
rguenth at gcc dot gnu dot org changed:
What|Removed
--- Comment #1 from rguenth at gcc dot gnu dot org 2009-07-15 09:41 ---
Confirmed.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #28 from burnus at gcc dot gnu dot org 2009-07-15 09:41 ---
(In reply to comment #24)
So maybe approach the question differently. Which element in an array of NaNs
is the smallest one and what is its value? If I pick any one element, its
value is NaN. It does not
--- Comment #4 from rguenth at gcc dot gnu dot org 2009-07-15 09:43 ---
Fixed.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #9 from rguenth at gcc dot gnu dot org 2009-07-15 09:44 ---
DF time on this testcase is already big, and the testcase has lots of function
calls which would explain the difference between targets (DF needs to track all
call-used/clobbered regs).
--
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.5.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40755
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Severity|normal |enhancement
Keywords|
--- Comment #8 from steven at gcc dot gnu dot org 2009-07-15 09:47 ---
That redundant move has to be a separate issue, indeed. I would expect the
register allocator to coalesce those registers.
I hadn't expected this. I thought the result would be just the removal of the
redundant
--- Comment #7 from jakub at gcc dot gnu dot org 2009-07-15 09:48 ---
Patch posted: http://gcc.gnu.org/ml/gcc-patches/2009-07/msg00842.html
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from rguenth at gcc dot gnu dot org 2009-07-15 09:53 ---
Program received signal SIGSEGV, Segmentation fault.
0x086e621a in useless_type_conversion_p (outer_type=0xb7cd43f0, inner_type=0x0)
at /home/richard/src/trunk/gcc/tree-ssa.c:1003
1003 if (POINTER_TYPE_P
--- Comment #3 from rguenth at gcc dot gnu dot org 2009-07-15 09:55 ---
I would also recommend to try a newer snapshot from the gcc 4.4 release branch.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40757
--- Comment #2 from rguenth at gcc dot gnu dot org 2009-07-15 09:56 ---
Is it the nesting of loops or really the number of function calls that is
important?
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from rguenth at gcc dot gnu dot org 2009-07-15 10:09 ---
Confirmed. With -O2 -fno-inline we get in .optimized
func_36 ()
{
bb 2:
g_10 = 1;
func_53 ();
g_64 = 1;
return 1;
FRE does this. I'll check.
--
rguenth at gcc dot gnu dot org changed:
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |rguenth at gcc dot gnu dot
|dot org
--- Comment #3 from rguenth at gcc dot gnu dot org 2009-07-15 10:17 ---
We have wrong SSA form before FRE:
;; Function func_36 (func_36)
func_36 ()
{
uint8_t g_64.8;
int64_t g_10.5;
bb 2:
# .MEM_17 = VDEF .MEM_16(D)
g_10 = 1;
# VUSE .MEM_17
g_10.5_2 = g_10;
if (g_10.5_2
--- Comment #8 from jakub at gcc dot gnu dot org 2009-07-15 10:18 ---
Subject: Bug 40747
Author: jakub
Date: Wed Jul 15 10:17:54 2009
New Revision: 149675
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=149675
Log:
PR middle-end/40747
* fold-const.c
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |hubicka at gcc dot gnu dot
|dot org
1 - 100 of 160 matches
Mail list logo
