On 06/08/2010 10:37 PM, Ian Lance Taylor wrote:
Are there ways that we can adjust our e-mail messages to make this
work better?
Two things: 1) we should make the [bracket] prefixes more standard for
patches destined to feature branches; 2) we should likely not send
multiple patches in one
On 9 June 2010 02:21, Jeremy Kerr j...@ozlabs.org wrote:
There is one header you can add to emails:
X-Patchwork-Hint: ignore
I am not sure how to add headers with gmail which is what I use for
GCC development. I would rather have patchwork recognize something
like:
:patchwork: ignore:
in
On 9 June 2010 02:21, Jeremy Kerr j...@ozlabs.org wrote:
Hi Ian,
I can see already that to be useful for gcc today it will need some
curating. E.g., http://patchwork.ozlabs.org/patch/54974/ is both 1)
committed; 2) on a branch. This one
http://patchwork.ozlabs.org/patch/54958/ is committed
Hi Manuel,
2) Use the command-line patchwork client to update patch state when a
patch is committed. People have done this with a git post-commit hook to
update the state of the patch in patchwork; I'm not sure if svn has
something equivalent.
Yes it does. If you tell us how the git
Hi,
On Wed, Jun 09, 2010 at 08:21:17AM +0800, Jeremy Kerr wrote:
There is one header you can add to emails:
X-Patchwork-Hint: ignore
- this will tell patchwork to ignore the patch completely. I use this when
sending a this is the stuff I'm merging for the next release email, as all
of
Hi Martin,
There is one header you can add to emails:
X-Patchwork-Hint: ignore
- this will tell patchwork to ignore the patch completely. I use this
when sending a this is the stuff I'm merging for the next release
email, as all of the patches have already been through the list.
Hi :
I am studying ira right now, there is following code in change_loop
if (parent_allocno == NULL
|| REGNO (ALLOCNO_REG (parent_allocno)) == REGNO (original_reg))
{
if (internal_flag_ira_verbose 3 ira_dump_file)
fprintf
I have a problem with recent builds of GCC4.6 (trunk)
on Cygwin 1.7. The compiler itself builds correctly, but
when I run it on even the simplest input, e.g.
gcc in.c -o a.exe
with in.c = int main() {}, no executable file is created.
No oputput is created even with the -S and -E options.
The
Yes it does. If you tell us how the git pots-commit hook works, we
could try to implement a version for svn and GCC.
This is what I've used for git:
[...@pororo helloworld]$ cat .git/hooks/post-applypatch
#!/bin/bash
sha=$(git rev-parse HEAD)
hash=$(git show $sha
Two things: 1) we should make the [bracket] prefixes more standard for
patches destined to feature branches;
Another point about (1): I believe patchwork should *not* track most of
the branch patches, and the commit detection shouldn't care about
release branch commits, only trunk. This is
On Wed, Jun 9, 2010 at 11:51 AM, Piotr Wyderski
piotr.wyder...@gmail.com wrote:
I have a problem with recent builds of GCC4.6 (trunk)
on Cygwin 1.7. The compiler itself builds correctly, but
when I run it on even the simplest input, e.g.
gcc in.c -o a.exe
with in.c = int main() {}, no
Wojciech Meyer wrote:
Maybe a mismatched cygwin1.dll. Do you have the right version of
cygwin1.dll on path? e.g the one against which gcc was compiled?.
Cygwin fails silently to execute the image in case of a mismatched
dll.
I am not 100% sure that my Cygwin installation is OK, as
it has
Hi,
I'm working on the vector subscription patch in terms of GSoC 2010 project.
The patch basically does the following, if we have a vector subscription like:
#define vector __attribute__((vector_size(16)))
vector int a;
a[1] = 10;
then the code a[1] = 10 is transformed into the code *((int *)a
On 09/06/2010 11:51, Piotr Wyderski wrote:
I have a problem with recent builds of GCC4.6 (trunk)
on Cygwin 1.7. The compiler itself builds correctly, but
when I run it on even the simplest input, e.g.
gcc in.c -o a.exe
with in.c = int main() {}, no executable file is created.
No
On 09/06/2010 17:10, Dave Korn wrote:
Oh, and an afterthought:
On 09/06/2010 11:51, Piotr Wyderski wrote:
I have a problem with recent builds of GCC4.6 (trunk)
on Cygwin 1.7. The compiler itself builds correctly, but
when I run it on even the simplest input, e.g.
gcc in.c -o a.exe
Dave,
Are you sure you're picking up the newest version of cyggcc_s-1.dll
(and all the other language runtimes) that got built with the compiler,
rather than the standard system one(s)?
How can I check that?
You did a full make install and put the new $prefix/bin (if not
using the standard
On 09/06/2010 17:31, Piotr Wyderski wrote:
Are you sure you're picking up the newest version of cyggcc_s-1.dll
(and all the other language runtimes) that got built with the compiler,
rather than the standard system one(s)?
How can I check that?
Well, verifying your path is correct should
Yes, this is also what I saw without plugin. I just wonder why v
is linked with plugin if resolution file is not used to eliminate need
of externally_visible attribute here.
Probably because of the same linker-plugin bug that causes bar
to be resolved.
Just to make sure I understand the
On Wed, 9 Jun 2010, Artem Shinkarov wrote:
It should be addressable, but register keyword disallows it. To solve
this problem I modify c-decl.c:start_decl like this:
I think that's too early, since you still want vector (explicitly
taking the address) to be rejected for a vector with register
On Wed, Jun 09, 2010 at 12:11:01PM -0700, Mark Mitchell wrote:
I think that literate programming approaches (whether the full Knuth
version, or the more mild JavaDoc version, or auto-extraction of
command-line options or whatever) are valuable. RMS, based on my
communications with him, is
Basile Starynkevitch wrote:
Meanwhile, I think we should try to make use of the fact that RMS is
permitting auto-generated reference documentation (which I have been
instructed not to call a manual) using JavaDoc/Doxygen tools. If we use
those tools, and demonstrate their value, we're then
On Wed, Jun 09, 2010 at 10:46:26PM +0200, Basile Starynkevitch wrote:
Please also explain who should I contact, and how? Please also explain
how the GNU Emacs is generated. I guess it is by a software of the GNU
emacs package.
Sorry for the typo, I mean
how the GNU emacs documentation is
Still, we'll see...
Apparently not :(
Why not? At most, you just need not to make sure nothing ever send
mail to people who think that kind of thing is bozoid...
M
On Wed, Jun 09, 2010 at 01:57:03PM -0700, Mark Mitchell wrote:
Basile Starynkevitch wrote:
Meanwhile, I think we should try to make use of the fact that RMS is
permitting auto-generated reference documentation (which I have been
instructed not to call a manual) using JavaDoc/Doxygen
Basile Starynkevitch wrote:
So I still don't understand why generating cross-reference
documentation with Doxygen for C++ code is permitted, while
generating cross-reference documentation witb ÂMELT for MELT code is
prohibited.
As far as I know, nobody said that.
On Wed, Jun 9, 2010 at 7:43 PM, Cary Coutant ccout...@google.com wrote:
Yes, this is also what I saw without plugin. I just wonder why v
is linked with plugin if resolution file is not used to eliminate need
of externally_visible attribute here.
Probably because of the same linker-plugin
On 06/09/2010 10:03 AM, Jeremy Kerr wrote:
Hi Manuel,
2) Use the command-line patchwork client to update patch state when a
patch is committed. People have done this with a git post-commit hook to
update the state of the patch in patchwork; I'm not sure if svn has
something equivalent.
Yes
On 06/09/2010 06:45 AM, Amker.Cheng wrote:
Hi :
I am studying ira right now, there is following code in change_loop
if (parent_allocno == NULL
|| REGNO (ALLOCNO_REG (parent_allocno)) == REGNO (original_reg))
{
if (internal_flag_ira_verbose 3
Yes, I think it can be NULL in some complicated cases when a loop exit edge
comes not in the parent loop.
By that, you mean the case an regno lives on edges which transfer
between adjacent loops,
and not lives in parent loop?
So, the fprintf would access null pointer in this case.
Thanks for
Hi Paolo,
The hash would be different for git diff and svn diff due to the
different headers.
The headers are not included in the hash. However, the filenames will need to
be the same - patchwork expects '-p1' patches, but normalises the top-level
directory.
For example, at
--- Comment #4 from ubizjak at gmail dot com 2010-06-09 06:27 ---
(In reply to comment #1)
It may be broken by revision 160394:
http://gcc.gnu.org/ml/gcc-cvs/2010-06/msg00307.html
The add-lea transformation doesn't even trigger in this testcase... You still
have normal add
bash-4.1$ gcc -v
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/home/jayk/libexec/gcc/alphaev67-dec-osf5.1/4.5.0/lto-wrapper
Target: alphaev67-dec-osf5.1
Configured with: /home/jayk/src/gcc-4.5.0/configure -disable-nls
-disable-bootstrap -with-gmp=/home/jayk -prefix=/home/jayk
Thread
I'll probably have to debug this myself..but compiling Tcl 8.5.8's tclStrToD.c
on alphaev67-dec-osf5.1 takes an inordinately long time. I've left it running
for many minutes. Everything else in Tcl compiled fairly rapidly, just this one
file is going and going. I tried without optimizing too.
--- Comment #1 from jay dot krell at cornell dot edu 2010-06-09 07:28
---
It is hung here:
#0 0x0001206feb24 in __gmpn_invert_limb ()
#1 0x0001206fd9b0 in __gmpn_divrem_2 ()
#2 0x0001206f1f84 in __gmpn_divrem ()
#3 0x0001206d0e20 in mpfr_div ()
#4
--- Comment #5 from ubizjak at gmail dot com 2010-06-09 07:46 ---
Looking into it.
--
ubizjak at gmail dot com changed:
What|Removed |Added
AssignedTo|unassigned
--- Comment #37 from gcc at breakpoint dot cc 2010-06-09 07:50 ---
Created an attachment (id=20873)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20873action=view)
this fails to compile in -O2 with the fix
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44364
--- Comment #38 from gcc at breakpoint dot cc 2010-06-09 07:54 ---
(In reply to comment #28)
Please bootstrap and test this addition to e500.h
/* When setting up caller-save slots (MODE == VOIDmode) ensure we
allocate space for DFmode. Save gprs in the correct mode too. */
Based on
http://groups.google.com/group/comp.lang.fortran/browse_thread/thread/cfb5f9dca46d5114#
After ENDFILE for non-streams, the current file position should be at the
endfile record. Thus, running the program below with NAG gives:
READ/WRITE attempted after ENDFILE on unit 10
Program
--- Comment #3 from paolo dot carlini at oracle dot com 2010-06-09 08:27
---
Janis, this doesn't make sense to me, and for sure happens only with decimal.
Can you have a look?
--
paolo dot carlini at oracle dot com changed:
What|Removed |Added
--- Comment #1 from paolo dot carlini at oracle dot com 2010-06-09 08:32
---
Rainer, can you help me on this? I don't even know how to categorize it, if
it's purely an ar issue or what else, I think you know this target...
--
paolo dot carlini at oracle dot com changed:
--- Comment #2 from jay dot krell at cornell dot edu 2010-06-09 08:42
---
Two line repro, no repro with 4.3.5, hangs with 4.5.0.
I'll rebuild the compiler though.
Seem like a gmp bug.
bash-4.1$ alphaev67-dec-osf5.1-gcc-4.3.5 -c 1.c
bash-4.1$ alphaev67-dec-osf5.1-gcc-4.5.0 -c 1.c
--- Comment #7 from paolo dot carlini at oracle dot com 2010-06-09 08:54
---
Non pre-processed testcase. Apparently some buffer is overflowed.
#include cxxabi.h
namespace abcdefgxyzzzabb
{
class Aaa { };
namespace klmn
{
class Baaa { };
}
}
namespace
--- Comment #39 from harry dot he at freescale dot com 2010-06-09 08:59
---
Hi, Kyle Moffett,
in testall.c, r9 is used by a register variable, however, in E500ABI guide,
r9 should be used for parameter passing, this test case seems not reasonable.
Harry He
--
--- Comment #11 from jamborm at gcc dot gnu dot org 2010-06-09 09:02
---
(In reply to comment #10)
(In reply to comment #9)
(In reply to comment #8)
I don't think you need flow-sensitivity.
Basically when you have only aggregate uses (as in this case)
Vectors are
--- Comment #12 from jamborm at gcc dot gnu dot org 2010-06-09 09:05
---
(In reply to comment #11)
D.2464.m[0] = D.2473_20;
D.2464.m[1] = D.2472_19;
D.2464.m[2] = D.2471_18;
*b_1(D) = D.2464;
D.2464 will be dead after scalarization.
If D.2464 was larger than
--- Comment #3 from rguenther at suse dot de 2010-06-09 09:10 ---
Subject: Re: Redundant looping pure functions
whose return value is dead are not optimized out
On Tue, 8 Jun 2010, pinskia at gcc dot gnu dot org wrote:
--- Comment #2 from pinskia at gcc dot gnu dot org
--- Comment #4 from mschulze at ivs dot cs dot ovgu dot de 2010-06-09
09:16 ---
I found a way to place data in program memory for C++ without producing the
annoying warnings. The trick is omiting __attribute__((__progmem__)) and
instead always use
--- Comment #6 from paolo at gcc dot gnu dot org 2010-06-09 09:16 ---
Subject: Bug 44413
Author: paolo
Date: Wed Jun 9 09:15:51 2010
New Revision: 160456
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=160456
Log:
2010-06-09 Paolo Carlini paolo.carl...@oracle.com
PR
--- Comment #40 from harry dot he at freescale dot com 2010-06-09 09:23
---
with my toolchain (From CodeSourcery, 4.4-78), o1test gives correct behavior
with built-in flags(-te500v2), but wrong behaviors with -fcaller-saves -O
-fno-omit-frame-pointer -fno-dce -fno-split-wide-types.
--- Comment #75 from iains at gcc dot gnu dot org 2010-06-09 09:27 ---
Subject: Bug 43170
Author: iains
Date: Wed Jun 9 09:27:04 2010
New Revision: 160457
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=160457
Log:
config:
PR bootstrap/43170
* tls.m4
--- Comment #3 from rguenth at gcc dot gnu dot org 2010-06-09 09:29 ---
Please report it to mpfr developers.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44476
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Severity|normal |enhancement
Component|c |target
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.6.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44470
--- Comment #8 from paolo dot carlini at oracle dot com 2010-06-09 09:37
---
Recategorizing as other (like 42230)... and maybe HJ is interested in playing a
bit with this one too.
--
paolo dot carlini at oracle dot com changed:
What|Removed
--- Comment #19 from jakub at gcc dot gnu dot org 2010-06-09 09:39 ---
Created an attachment (id=20874)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20874action=view)
CVE-2010-0831.patch
Just for the record, the patch that went in leaves fastjar still vulnerable.
The main issue
When building a Linux kernel the new default of having
-Wunused-but-set-variable is incredibly noisy in kernel build. I get hundreds
of new warnings from that.
I looked at some of the circumstances and it's typically
int var = VALUE;
#ifdef SYMBOL
if (do something)
var = other value
#endif
--- Comment #1 from paolo dot carlini at oracle dot com 2010-06-09 09:49
---
I'm sure you are right, but I don't understand your explanation: even when
SYMBOL
is undefined, why no code actually uses (roughly speaking, reads) var? That's
the point of the warning and your example doesn't
--- Comment #2 from jakub at gcc dot gnu dot org 2010-06-09 09:53 ---
The warning is useful and can find (and already found) several real bugs e.g.
in gcc itself. Icc has similar warning.
If kernel has lots of useless code like that and doesn't wish to use this
warning, it can add
--- Comment #3 from andi-gcc at firstfloor dot org 2010-06-09 10:13 ---
Sorry my example was not very good.
Anyways this typically happens with #ifdefs, so the some ifdef path
is actually using the variable, it's just not enabled in the current build.
In theory the ifdefs could be put
--- Comment #7 from zsojka at seznam dot cz 2010-06-09 10:14 ---
I have just finished bootstrap of r160198 with valgrind checking, the problem
is no longer reproducible there. I am sorry for the delay, make check with
valgrind checking takes about a month there (1.3GHz), bootstrap about
--- Comment #7 from fxcoudert at gcc dot gnu dot org 2010-06-09 10:18
---
Subject: Bug 43040
Author: fxcoudert
Date: Wed Jun 9 10:17:56 2010
New Revision: 160459
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=160459
Log:
PR fortran/43040
* f95-lang.c
--- Comment #8 from fxcoudert at gcc dot gnu dot org 2010-06-09 10:20
---
Checked that it is not an issue.
--
fxcoudert at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #4 from redi at gcc dot gnu dot org 2010-06-09 10:22 ---
(From update of attachment 20871)
attachment's mimetype changed to text/plain
--
redi at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #4 from hubicka at ucw dot cz 2010-06-09 10:29 ---
Subject: Re: Redundant looping pure functions
whose return value is dead are not optimized out
Why do we remove register LHS in DCE again?
Because it reduces the amount of garbage produced by expand :).
--- Comment #2 from amylaar at gcc dot gnu dot org 2010-06-09 10:32 ---
Subject: Bug 44432
Author: amylaar
Date: Wed Jun 9 10:32:23 2010
New Revision: 160460
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=160460
Log:
PR bootstrap/44432
* configure.ac: Before
--- Comment #4 from amylaar at gcc dot gnu dot org 2010-06-09 10:40 ---
Subject: Bug 42843
Author: amylaar
Date: Wed Jun 9 10:40:28 2010
New Revision: 160461
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=160461
Log:
gcc:
PR testsuite/42843
* gcc-plugin.h (int
--- Comment #3 from amylaar at gcc dot gnu dot org 2010-06-09 10:47 ---
Fixed in trunk by revision 160460.
--
amylaar at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #5 from amylaar at gcc dot gnu dot org 2010-06-09 10:49 ---
Fixed in trunk by revision 160461.
--
amylaar at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #4 from jakub at gcc dot gnu dot org 2010-06-09 10:52 ---
We don't warn on
void foo (void)
{
int dummy;
asm ( : =r (dummy));
}
- the use in the asm is considered as a use, not just set.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44478
--- Comment #4 from andi-gcc at firstfloor dot org 2010-06-09 10:55 ---
I was told that the whopr link step would inherit the optimization
flags from the build step. Is that not true?
Here's a reduced test case with only a single input file (reduced too)
gcc46 -O2 -fwhopr -c
--- Comment #5 from andi-gcc at firstfloor dot org 2010-06-09 10:56 ---
Created an attachment (id=20875)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20875action=view)
reduced input file
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44464
--- Comment #5 from zsojka at seznam dot cz 2010-06-09 11:02 ---
The testcase also fails when it is changed to:
...
{
extern void *bar(void) __attribute__((malloc));
int **pp = bar(), *p = bar();
...
so there isn't any access through NULL pointer.
--
--- Comment #5 from andi-gcc at firstfloor dot org 2010-06-09 11:08 ---
Hmm yes there was another temporary and a inline inbetween
unsigned inlinefunc(void)
{
unsigned var;
asm( ... : =r (var));
return var;
}
#define macro(x,y)
{
unsigned var = inlinefunc();
x = var;
y =
--- Comment #3 from andi-gcc at firstfloor dot org 2010-06-09 11:09 ---
Jakub, for this example: how would you suggest to work around this warning?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16427
--- Comment #20 from marcus at jet dot franken dot de 2010-06-09 11:20
---
Jakubs patch looks good to me.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28359
--- Comment #13 from jamborm at gcc dot gnu dot org 2010-06-09 11:20
---
Subject: Bug 44423
Author: jamborm
Date: Wed Jun 9 11:20:03 2010
New Revision: 160462
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=160462
Log:
2010-06-09 Martin Jambor mjam...@suse.cz
PR
--- Comment #16 from andi-gcc at firstfloor dot org 2010-06-09 11:21
---
I don't need a backport to 4.4 and I double checked it works as expected
in gcc 4.5. Closing.
--
andi-gcc at firstfloor dot org changed:
What|Removed |Added
--
andi-gcc at firstfloor dot org changed:
What|Removed |Added
Status|WAITING |UNCONFIRMED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44464
When compiling function:
void xxx(short* __restrict__ a, short* __restrict__ b)
{
int i;
for (i = 0; i 8; i++)
{
a[i] = b[i];
}
}
before sched2 we have:
(note 13 12 14 3 [bb 3] NOTE_INSN_BASIC_BLOCK)
(insn 14 13 15 3 ./a.c:6 (set (reg:SI 2 cx [orig:106 *vect_p.14_18 ] [106])
--- Comment #1 from roy dot 1rosen at gmail dot com 2010-06-09 11:28
---
Created an attachment (id=20876)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20876action=view)
preprocessed file
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44479
--- Comment #6 from jakub at gcc dot gnu dot org 2010-06-09 11:36 ---
Then it has nothing to do with the asm.
If the macro is widely used and very often sets a var that isn't used, all
you can do is add (void) cast to shut the warning up.
(void) (y = var 16);
in this case.
--
--- Comment #5 from ktietz at gcc dot gnu dot org 2010-06-09 11:53 ---
Fixed by patch at revision 159965.
--
ktietz at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from rguenth at gcc dot gnu dot org 2010-06-09 11:56 ---
I will have a look at some point.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Known to fail|4.0.0 |4.0.0 4.3.5 4.4.3
Target Milestone|4.3.6
--- Comment #4 from rguenth at gcc dot gnu dot org 2010-06-09 11:59 ---
It's now optimized by RTL DSE but we keep the stack allocated.
Re-confirmed on the tree-level. Should be easy to extend DSE to handle this.
--
rguenth at gcc dot gnu dot org changed:
What
--- Comment #1 from fxcoudert at gcc dot gnu dot org 2010-06-09 12:01
---
I don't understand what you mean by that: currently, we have the following
typedefs on platforms which support a 128-bit int type:
typedef __int128_t GFC_INTEGER_16;
typedef __uint128_t GFC_UINTEGER_16;
I
--- Comment #14 from martin at mpa-garching dot mpg dot de 2010-06-09
12:06 ---
SSE performance is fine again, thanks a lot!
One more question, if that's OK...
Depending on ARRSZ the testcase uses wildly varying amounts of CPU time; it's
about half a second for ARRSZ=1024, but almost
--- Comment #3 from fxcoudert at gcc dot gnu dot org 2010-06-09 12:07
---
Hey, I actually have the answer to this one: yes, it is intended as is, and
not, it is a bit more complicated that Jerry says.
We maintain a hash table of identifiers, so that when we have multiple times
the
--- Comment #6 from rguenth at gcc dot gnu dot org 2010-06-09 12:08 ---
(In reply to comment #4)
I was told that the whopr link step would inherit the optimization
flags from the build step. Is that not true?
That's not true.
Here's a reduced test case with only a single input file
--- Comment #7 from rguenth at gcc dot gnu dot org 2010-06-09 12:15 ---
Actually - we seem to get IPA SRA parm repacements done but the original
parameter SSA names are not released.
(gdb) call debug_function (cfun-decl, 0)
igmp_mc_get_next (unnamed type * ISRA.14, struct ip_mc_list *
--- Comment #6 from ubizjak at gmail dot com 2010-06-09 12:15 ---
Following patch is also needed to fix conditional splitting (it does not fix
original uncovered problem where BLOCK_FOR_INSN returns null):
Index: i386.md
--- Comment #8 from rguenth at gcc dot gnu dot org 2010-06-09 12:16 ---
CC'ing martin even.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #9 from andi-gcc at firstfloor dot org 2010-06-09 12:16 ---
Unfortunate. Fixing that in the makefiles would be major effort for all the -f
and -m flags, which sometimes vary by target.
I thought LTO was designed to minimize makefile changes?
--
--- Comment #10 from andi-gcc at firstfloor dot org 2010-06-09 12:18
---
The tree input that leads to the NULL annotation is a error_mark
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44464
--- Comment #2 from burnus at gcc dot gnu dot org 2010-06-09 12:41 ---
Close as WONTFIX.
The int128 changes still do not offer to enter the integer directly (instead of
using 123L with shifts)
And one issue was fixed as part of
--- Comment #2 from jakub at gcc dot gnu dot org 2010-06-09 12:51 ---
I guess for empty bbs with no successor where the predecessor ends in an
conditional jump without side-effects try_optimize_cfg can't do just
delete_basic_block, but needs to call some function to actually adjust the
--- Comment #11 from rguenth at gcc dot gnu dot org 2010-06-09 13:01
---
(In reply to comment #10)
The tree input that leads to the NULL annotation is a error_mark
Not for me.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44464
--- Comment #12 from rguenth at gcc dot gnu dot org 2010-06-09 13:03
---
(In reply to comment #9)
Unfortunate. Fixing that in the makefiles would be major effort for all the
-f
and -m flags, which sometimes vary by target.
I thought LTO was designed to minimize makefile
--- Comment #41 from amodra at gmail dot com 2010-06-09 13:26 ---
Created an attachment (id=20877)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20877action=view)
e500.h and caller-save.c patch
The ICE in #38 is due to a bug in caller-save.c
--
--- Comment #13 from andi-gcc at firstfloor dot org 2010-06-09 13:35
---
What happens then when some files need different options that other files?
This sounds more and more like a showstopper if you're right.
I was not prepared to redesign the Makefiles
--
1 - 100 of 196 matches
Mail list logo
