Looks like the new toplevel bootstrap infrastructure broke
bootstrapping on OpenBSD. I get a bootstrap comparison which is
caused by differences in the compilation directory encoded in the
object files from different stages.
Forcing the coplevel configure to use mv instead of ln -s by setting
Because the whole point of this process is to remove all the bootstrap
logic from the gcc subdirectory, which is exactly where it doesn't
belong. This will let us take major steps forward in our build process
How does *removing* something take major steps forward? The whole
Richard Guenther [EMAIL PROTECTED] wrote on 15/12/2005 14:52:27:
On 12/15/05, Dorit Naishlos [EMAIL PROTECTED] wrote:
So, in short - when can we assume that pointer types have the minimum
alignment required by their underlying type?
I think the C standard always guarantees this.
As far
On 12/18/05, Dorit Naishlos [EMAIL PROTECTED] wrote:
Richard Guenther [EMAIL PROTECTED] wrote on 15/12/2005 14:52:27:
On 12/15/05, Dorit Naishlos [EMAIL PROTECTED] wrote:
So, in short - when can we assume that pointer types have the minimum
alignment required by their underlying type?
I recently had to build gcc 3.2.2 on an FC4 box. This failed using gcc
4.0.2 as the bootstrap compiler since gcc 3.2.2 uses no-longer-accepted
extensions. So I built gcc 3.4.5 using 4.0.2, and used that to bootstrap
3.2.2.
Now, if it is part of the release criteria that release N-1 must be
On Sun, Dec 18, 2005 at 08:28:13AM -0500, Richard Kenner wrote:
Because the whole point of this process is to remove all the bootstrap
logic from the gcc subdirectory, which is exactly where it doesn't
belong. This will let us take major steps forward in our build process
How
On Sun, Dec 18, 2005 at 01:28:48PM +0100, Mark Kettenis wrote:
Looks like the new toplevel bootstrap infrastructure broke
bootstrapping on OpenBSD. I get a bootstrap comparison which is
caused by differences in the compilation directory encoded in the
object files from different stages.
On Sun, Dec 18, 2005 at 12:12:17PM -0500, Richard Kenner wrote:
Backwards compatibility is indeed expensive, but is critical. All vendors
do it and we need to as well. You can be certain that if there were six
ways of specifying something in VMS on a VAX in 1979, all six will still
work
(From http://gcc.gnu.org/ml/gcc-patches/2005-11/msg01283.html)
This patch is okay.
(Though please try to watch the sniping in the future, there is no need
to be uncivil).
And don't you think that talking about compatibility expected by our
users is just a little bit disingenuous, when you're talking about
running make inside the gcc subdirectory? Users don't do that!
Only developers of GCC do. It's only useful for incremental builds; a
full
On Sun, Dec 18, 2005 at 01:01:11PM -0500, Richard Kenner wrote:
Because it would have to recurse to the parent directory,
Why do you have to recurse to the parent directory to bootstrap GCC?
If the desire was to make pieces elsewhere, the command would have been
issued from elsewhere.
The answer to both of these questions is the same. Toplevel bootstrap
deliberately - as a design decision, and in my opinion, a very good
one - puts every stage in its own directory.
Of course: we've always had each stage living in a different directory.
You're not going to get any
On Sun, Dec 18, 2005 at 01:25:36PM -0500, Richard Kenner wrote:
The answer to both of these questions is the same. Toplevel bootstrap
deliberately - as a design decision, and in my opinion, a very good
one - puts every stage in its own directory.
Of course: we've always had
Date: Sun, 18 Dec 2005 11:49:37 -0500
From: Daniel Jacobowitz [EMAIL PROTECTED]
On Sun, Dec 18, 2005 at 01:28:48PM +0100, Mark Kettenis wrote:
Looks like the new toplevel bootstrap infrastructure broke
bootstrapping on OpenBSD. I get a bootstrap comparison which is
caused by
On Dec 18, 2005, at 1:40 PM, Daniel Jacobowitz wrote:
We used to have some workarounds in the libcpp-to-gcc interface to work
around the fact that we built libcpp once, with the system compiler,
and then linked it to each stage of the bootstrap. Darwin had a system
compiler that disagreed with
On Dec 17, 2005, at 10:27 PM, Andrew Pinski wrote:
On Dec 18, 2005, at 1:13 AM, Geoff Keating wrote:
Yes; to do this right, GCC's builtins need to know about the
different names.
If you're interested in fixing this, I can tell you what to do...
I figured out how to fix it and will be
On Sun, Dec 18, 2005 at 07:49:13PM +0100, Mark Kettenis wrote:
Heh, the shell does set PWD, but does not export it. If I explicitly
say export PWD, before make bootstrap it seems to work.
Weird.
I've been considering disabling ln -s support. It's too fragile,
though this is the first
Daniel Jacobowitz [EMAIL PROTECTED] writes:
[...]
| We can bootstrap the assembler in a combined tree. The first stage's
| gcc will invoke a stage1 assembler, the second stage's gcc will invoke
| a stage2 assembler. This doesn't have any fundamental benefits except
| for thoroughness; it's an
i use the gentoo flavor of linux and a recent install method has become
popular there. i myself have not done this and i do doubt the usefulness
of it but i want to check with the people who would know the most about
the basic tool-chain as it is called.
this is the install method
On 18/12/2005, at 10:57 AM, Mike Stump wrote:
On Dec 17, 2005, at 10:27 PM, Andrew Pinski wrote:
On Dec 18, 2005, at 1:13 AM, Geoff Keating wrote:
Yes; to do this right, GCC's builtins need to know about the
different names.
If you're interested in fixing this, I can tell you what to
The top level bootstrap model is to rebuild all the useful bits of the
entire tree as a group; and repeat that as many times as necessary to
be able to compare them.
Please define useful. I'm very concerned if we're doing more builds
than before and don't have a way to restrict the
The attached patch removes the unused variables BUILD_CONFIGDIRS and
TARGET_CONFIGDIRS from Makefile.tpl. It also removes the
AC_SUBST(target_configdirs) from configure.in.
Boostraped on a GNU/Linux/x86
Rafael
2005-12-18 Rafael Ávila de Espíndola [EMAIL PROTECTED]
* Makefile.tpl
--- Comment #1 from bkoz at gcc dot gnu dot org 2005-12-18 08:08 ---
Subject: Bug 25472
Author: bkoz
Date: Sun Dec 18 08:08:07 2005
New Revision: 108743
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=108743
Log:
2005-12-17 Benjamin Kosnik [EMAIL PROTECTED]
*
--- Comment #3 from irar at il dot ibm dot com 2005-12-18 08:15 ---
I failed to reproduce this ICE on ppc and i686.
Vectorizer's dump file can help.
--
irar at il dot ibm dot com changed:
What|Removed |Added
--- Comment #8 from jvdelisle at gcc dot gnu dot org 2005-12-18 08:24
---
Subject: Bug 25264
Author: jvdelisle
Date: Sun Dec 18 08:24:04 2005
New Revision: 108744
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=108744
Log:
2005-12-17 Jerry DeLisle [EMAIL PROTECTED]
PR
--- Comment #9 from jvdelisle at gcc dot gnu dot org 2005-12-18 08:24
---
Subject: Bug 25349
Author: jvdelisle
Date: Sun Dec 18 08:24:04 2005
New Revision: 108744
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=108744
Log:
2005-12-17 Jerry DeLisle [EMAIL PROTECTED]
PR
--- Comment #9 from jvdelisle at gcc dot gnu dot org 2005-12-18 08:32
---
Subject: Bug 25264
Author: jvdelisle
Date: Sun Dec 18 08:32:09 2005
New Revision: 108745
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=108745
Log:
2005-12-17 Jerry DeLisle [EMAIL PROTECTED]
PR
--- Comment #10 from jvdelisle at gcc dot gnu dot org 2005-12-18 08:32
---
Subject: Bug 25349
Author: jvdelisle
Date: Sun Dec 18 08:32:09 2005
New Revision: 108745
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=108745
Log:
2005-12-17 Jerry DeLisle [EMAIL PROTECTED]
PR
--- Comment #11 from dorit at gcc dot gnu dot org 2005-12-18 08:46 ---
Subject: Bug 24378
Author: dorit
Date: Sun Dec 18 08:46:30 2005
New Revision: 108746
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=108746
Log:
PR tree-optimization/24378
*
--- Comment #12 from dorit at gcc dot gnu dot org 2005-12-18 11:20 ---
Subject: Bug 24378
Author: dorit
Date: Sun Dec 18 11:20:17 2005
New Revision: 108750
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=108750
Log:
PR tree-optimization/24378
*
I found bug in GNU assembler.
OS is SUSE9.3
command line is:
gcc -v -save-temps -Wall -W -DASM_FILE=1 -nostdinc -fno-builtin -c -o
loader_img-loader.o loader.S
output is:
Reading specs from /usr/local/lib/gcc/i686-pc-linux-gnu/3.4.3/specs
Configured with: ./configure
Thread model: posix
gcc
--- Comment #2 from pault at gcc dot gnu dot org 2005-12-18 14:01 ---
Subject: Bug 25018
Author: pault
Date: Sun Dec 18 14:01:00 2005
New Revision: 108753
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=108753
Log:
2005-12-18 Paul Thomas [EMAIL PROTECTED]
PR
--- Comment #23 from steven at gcc dot gnu dot org 2005-12-18 14:30 ---
This bug was for mgrid, but now we're stuck on a reported mesa performance drop
that may or may not be related to this PR. I suggest that if the mesa drop is
still there, a new bug report should be opened for it.
--- Comment #3 from steven at gcc dot gnu dot org 2005-12-18 14:32 ---
ping!
There are too many reports about SPEC performance drops that stay in WAITING
for too long. That is not helpful. Uttam, please investigate this bug, you
cannot just drop a bug report about SPEC performance
--- Comment #4 from steven at gcc dot gnu dot org 2005-12-18 14:36 ---
For historic reference, once this is on the 4.1 branch too.
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #5 from hubicka at gcc dot gnu dot org 2005-12-18 14:51 ---
Subject: Bug 25224
Author: hubicka
Date: Sun Dec 18 14:51:53 2005
New Revision: 108754
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=108754
Log:
PR rtl-optimization/25224
*
--- Comment #6 from steven at gcc dot gnu dot org 2005-12-18 14:53 ---
fixeth yet
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
Compiling the following test case with ./cc1 -O2 ends up causing a segfault.
struct s {
int *blah;
};
static struct s array[] = {
{ 0 }
};
void
foo (struct s *p)
{
unsigned int n = 1;
struct s *q = array[n];
while (p q)
p++;
}
--
Summary: Segfault in
--- Comment #8 from steven at gcc dot gnu dot org 2005-12-18 15:42 ---
What is one supposed to do with this bug report?
First, it looks from the command lines in the report that the problematic
compiler is GCC 3.3. But the report is about gcc 4.1.0.
Second, I can't reproduce the
--- Comment #9 from steven at gcc dot gnu dot org 2005-12-18 15:45 ---
Unable to reproduce with GCC 4.1 without further feedback. Apparently already
fixed or made latent on GCC 4.2. The dumps in comment #1 could use some
comment so that people reading this bug report don't have to
--- Comment #10 from steven at gcc dot gnu dot org 2005-12-18 15:45 ---
Unable to reproduce with GCC 4.1 without further feedback. Apparently already
fixed or made latent on GCC 4.2. The dumps in comment #1 could use some
comment so that people reading this bug report don't have to
--- Comment #5 from kazu at gcc dot gnu dot org 2005-12-18 15:48 ---
Is this PR fixed? Or does it need some follow-up work?
--
kazu at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #7 from steven at gcc dot gnu dot org 2005-12-18 15:51 ---
Kazu assigned this to himself on December 17, see
http://gcc.gnu.org/ml/gcc-bugs/2005-12/msg01787.html
Folks, please add a comment when you assign a bug to yourself. That way, it's
easier to see which bugs have had
--- Comment #12 from steven at gcc dot gnu dot org 2005-12-18 15:55 ---
Paolo, are you going to ask for approval for GCC 4.1 too?
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #7 from steven at gcc dot gnu dot org 2005-12-18 16:04 ---
comment #6 says invalid code. So is this an ICE on valid, or _invalid_ code?
Anyway,
Starting program: /abuild/stevenb/build/gcc/cc1plus t.C
AT::A()
Breakpoint 4, expand_member_init (name=0x401c9958) at
--- Comment #12 from uweigand at gcc dot gnu dot org 2005-12-18 16:06
---
Subject: Bug 21041
Author: uweigand
Date: Sun Dec 18 16:06:55 2005
New Revision: 108760
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=108760
Log:
PR rtl-optimization/21041
* reload.c
As per the comment at the beginning of streambuf_iterator.h.
--
Summary: Specialize (overload) std::copy/find for streambuf
iterators
Product: gcc
Version: 4.1.0
Status: UNCONFIRMED
Severity: enhancement
--- Comment #6 from dberlin at gcc dot gnu dot org 2005-12-18 16:29 ---
Subject: Re: pure functions cause things to
be call clobbered still
On Sun, 2005-12-18 at 15:48 +, kazu at gcc dot gnu dot org wrote:
--- Comment #5 from kazu at gcc dot gnu dot org 2005-12-18
--- Comment #9 from steven at gcc dot gnu dot org 2005-12-18 16:36 ---
Giovanni, you never assigned this bug to yourself as far as I can tell, but
could you give this bug a quick look anyway, or otherwise unassign yourself
from this bug? Thanks.
--
Attached testcase when compiled by gcc version 4.2.0 20051217 (experimental) on
x86 using:
-
gcc -O2 -fmove-loop-invariants -c -o mpegaudiodec.o mpegaudiodec.c
-
results in the following
-
mpegaudiodec.c: In function decode_init:
--- Comment #1 from drab at kepler dot fjfi dot cvut dot cz 2005-12-18
16:39 ---
Created an attachment (id=10528)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10528action=view)
Triggers the bug
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25483
--- Comment #45 from steven at gcc dot gnu dot org 2005-12-18 16:40 ---
Alexandre, what is up with this bug? It's a gcc 4.1 regression assigned to
you, could you please at least say whether you're working on this or not?
Thanks.
--
--- Comment #1 from pinskia at gcc dot gnu dot org 2005-12-18 17:04 ---
Confirmed.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from rguenth at gcc dot gnu dot org 2005-12-18 17:09 ---
Will look at it.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #10 from steven at gcc dot gnu dot org 2005-12-18 17:15 ---
rth assigned this to himself:
http://gcc.gnu.org/ml/gcc-bugs/2005-11/msg02843.html
A progress report would be nice ;-)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16876
--- Comment #7 from steven at gcc dot gnu dot org 2005-12-18 17:17 ---
This will *NOT* be fixed for GCC 4.1.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24408
--- Comment #2 from pinskia at gcc dot gnu dot org 2005-12-18 17:30 ---
Confirmed, reduced testcase:
static int mdct_win[8][36];
int decode_init(double d)
{
int i = 0, j, k;
for(j=0; j4; j++)
{
d*= 0.5;
mdct_win[j][i ] = ((int)(((d / (15))) * (1LL32) + 0.5));
}
}
--- Comment #11 from dave at hiauly1 dot hia dot nrc dot ca 2005-12-18
17:38 ---
Subject: Re: [4.1/4.2 regression] FAIL: gcc.c-torture/execute/20040709-1.c
execution, -Os
First, it looks from the command lines in the report that the problematic
compiler is GCC 3.3. But the report
--- Comment #3 from pinskia at gcc dot gnu dot org 2005-12-18 17:41 ---
This worked in 4.2.0 20051214 but not in 4.2.0 20051217.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25483
--- Comment #3 from rguenth at gcc dot gnu dot org 2005-12-18 17:43 ---
We're hitting the assert at
#1 0x0856ac47 in handle_ptr_arith (lhsc=0x8868880, expr=0x401942d0)
at tree-ssa-structalias.c:3188
gcc_assert (first_vi_for_offset (temp, rhsoffset) != NULL);
with
--- Comment #12 from dave at hiauly1 dot hia dot nrc dot ca 2005-12-18
18:01 ---
Subject: Re: [4.1/4.2 regression] FAIL: gcc.c-torture/execute/20040709-1.c
execution, -Os
Unable to reproduce with GCC 4.1 without further feedback. Apparently already
fixed or made latent on GCC
--
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
PR25456 was fixed wrongly. This'll make the compiler ICE later on
if eg. used to cross-compile uClibc.
--
Summary: Fix for PR25456 is wrong
Product: gcc
Version: 4.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
--- Comment #1 from jbglaw at lug-owl dot de 2005-12-18 18:37 ---
Created an attachment (id=10529)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10529action=view)
Correct fix
This is the correct fix, see
http://gcc.gnu.org/ml/gcc-patches/2005-12/msg01258.html .
--
--- Comment #13 from steven at gcc dot gnu dot org 2005-12-18 18:39 ---
Ugh, I guess that means going back to a checkout of the day of the report if we
want to reproduce this :-/
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Component|c |rtl-optimization
Summary|Fix for PR25456 is wrong
Consider:
int
foo (int a, int b)
{
if (a 50)
return 19;
if (a 63 b 50)
return 17;
return 31;
}
VRP does not optimize away the second if statement.
Here is the output from VRP.
foo (a, b)
{
_Bool D.1662;
_Bool D.1661;
_Bool D.1660;
int D.1659;
bb 2:
if (a_2 50)
--- Comment #1 from pinskia at gcc dot gnu dot org 2005-12-18 19:18 ---
Confirmed, the problem is that VRP folds a 63 and then props that into temp
temp1 but does not prop after that.
--
pinskia at gcc dot gnu dot org changed:
What|Removed
--- Comment #2 from pinskia at gcc dot gnu dot org 2005-12-18 19:19 ---
I should note that this only happens for targets whos BRANCH_COST is semi high.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25485
--- Comment #3 from pinskia at gcc dot gnu dot org 2005-12-18 20:14 ---
This looks like a case where array decays to a pointer too early problem (PR
24666).
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
There is a regression in 4.2 from 4.1 with fixed-form literal character
constants that are continued to a new line. Consider the following
fixed-form code:
program a
character(len=90) c
c A tab is between 9 and 0.
c = '1234567
890'
print *, c
end
The
--- Comment #5 from hubicka at gcc dot gnu dot org 2005-12-18 20:53 ---
Simplified testcase seems to work for me on 4.1 branch:
restore_fpu:
movl4(%esp), %edx
movlboot_cpu_data+12, %eax
testl $16777216, %eax
je .L2
jmp foo
.L2:
--- Comment #4 from rguenth at gcc dot gnu dot org 2005-12-18 22:20 ---
Subject: Bug 25481
Author: rguenth
Date: Sun Dec 18 22:20:31 2005
New Revision: 108763
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=108763
Log:
2005-12-18 Richard Guenther [EMAIL PROTECTED]
PR
--- Comment #5 from rguenth at gcc dot gnu dot org 2005-12-18 22:23 ---
Fixed.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNED
The source here generates an asserion failure compiled with anything above -O0.
Changing p+1 to p seems to avoid the bug. The infinite loops are not a feature
of the original code but the uderlying problem appears to be indentical.
screenshot
[EMAIL
The source here generates an asserion failure compiled with anything above -O0.
Changing p+1 to p seems to avoid the bug. The infinite loops are not a feature
of the original code but the uderlying problem appears to be indentical.
screenshot
[EMAIL
This code:
typedef struct {
int protected_mode;
int x;
} TScreen;
extern void ClearRight (TScreen *screen, int n);
extern void ClearLeft(TScreen * screen);
extern void ClearLine(TScreen * screen);
void
do_erase_line(TScreen * screen, int param, int mode)
{
int saved_mode =
There is a pointer arithmetic related assersion failure, apparently in the
logic attempting to deduce what the pointer might be pointing at. If you
compile wiht -O0 or chaneg p+1 to p the bug is apparently bypassed. My
screenshot is
[EMAIL PROTECTED]:~/duncan/src/foo/wlocal/build/phone/mq$ gcc
--- Comment #1 from pinskia at gcc dot gnu dot org 2005-12-18 22:40 ---
*** This bug has been marked as a duplicate of 25487 ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #1 from pinskia at gcc dot gnu dot org 2005-12-18 22:40 ---
*** This bug has been marked as a duplicate of 25487 ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from pinskia at gcc dot gnu dot org 2005-12-18 22:40 ---
*** Bug 25490 has been marked as a duplicate of this bug. ***
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25487
--- Comment #2 from dps at simpson dot demon dot co dot uk 2005-12-18
22:43 ---
Created an attachment (id=10530)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10530action=view)
Example program that tickles the bug (with -On for n=1).
The example is based on a real example without
--- Comment #3 from pinskia at gcc dot gnu dot org 2005-12-18 22:45 ---
*** This bug has been marked as a duplicate of 25481 ***
*** This bug has been marked as a duplicate of 25481 ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed
--- Comment #6 from pinskia at gcc dot gnu dot org 2005-12-18 22:45 ---
*** Bug 25487 has been marked as a duplicate of this bug. ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #1 from pinskia at gcc dot gnu dot org 2005-12-18 22:40 ---
*** Bug 25488 has been marked as a duplicate of this bug. ***
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25487
--- Comment #6 from dann at godzilla dot ics dot uci dot edu 2005-12-18
22:57 ---
(In reply to comment #5)
Simplified testcase seems to work for me on 4.1 branch:
restore_fpu:
movl4(%esp), %edx
movlboot_cpu_data+12, %eax
testl $16777216, %eax
4.0
--- Comment #4 from steven at gcc dot gnu dot org 2005-12-18 23:24 ---
Works in r108712.
Breaks in r108713.
That's the ENTRY/EXIT block renumbering patch. Somehow this seems to have
messed up df_analyze_subcfg.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25483
--- Comment #2 from pinskia at gcc dot gnu dot org 2005-12-18 23:34 ---
Fixed by:
http://gcc.gnu.org/ml/gcc-patches/2005-12/msg01399.html
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #5 from steven at gcc dot gnu dot org 2005-12-18 23:44 ---
We get to iterative_dataflow from df_analyze_subcfg with this dataflow
argument:
(gdb) p *dataflow
$11 = {repr = SR_BITMAP, gen = 0xf43d90, kill = 0xf439d0, in = 0xf55ac0, out =
0xf57ca0,
dir = DF_FORWARD, conf_op
--- Comment #6 from steven at gcc dot gnu dot org 2005-12-18 23:52 ---
Kenny is working on a fix.
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #3 from kazu at gcc dot gnu dot org 2005-12-19 00:01 ---
I've got a preliminary patch.
--
kazu at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #7 from kazu at gcc dot gnu dot org 2005-12-19 00:37 ---
We are basically talking about narrowing the memory being loaded for testing.
Now, can we really optimize this case? We've got
const volatile unsigned long *addr
I am not sure if volatile allows us to change the
--- Comment #1 from kargl at gcc dot gnu dot org 2005-12-19 01:00 ---
I just bootstrapped 4.1 and the regression is also in 4.1!
I believe it appeared after 27 Nov 05 in that my older 4.1
gfortran, which wokred correctly, had that timestamp.
--
kargl at gcc dot gnu dot org changed:
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Keywords||wrong-code
Summary|[4.1 and 4.2 Regression]|[4.1/4.2
I was writing a program that evaluates an operator tree with variables
constants and operators. Rather than recursively iterate the tree many times
for different variable values to evaluate it.. I printed the tree into a source
file, compiled it as a shared library with gcc and dynamically linked
--- Comment #1 from geckosenator at gmail dot com 2005-12-19 02:27 ---
Created an attachment (id=10531)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10531action=view)
bzip2 compressed file that produces gcc segfault
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25491
--- Comment #6 from kazu at gcc dot gnu dot org 2005-12-19 02:30 ---
I just compiled the testcase on x86_64. I got
foo:
.LFB2:
movq%rdi, %rax
negq%rax
andq%rdi, %rax
ret
which is as good as the assembly generated by 3.4.3.
This is no
--- Comment #2 from kargl at gcc dot gnu dot org 2005-12-19 04:33 ---
This regression is caused by
svn update -r 107850 on 4.1
svn update -r 107745 on trunk.
This a patch I committed, but until my hard drive is replaced I
won't be able to revert without too much pain. If anyone else
--- Comment #14 from danglin at gcc dot gnu dot org 2005-12-19 04:45
---
I did a checkout as of Sep 12, 2005 00:00:00 UTC and get the same assembly
code as in the initial report using the following compilation options:
-Os -w -S -mschedule=7100LC. The build was done on
--- Comment #15 from steven at gcc dot gnu dot org 2005-12-19 06:30 ---
Could this be a dup of Bug 23585?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23954
1 - 100 of 108 matches
Mail list logo
