--- Comment #5 from halcy0n at gentoo dot org 2006-01-15 08:09 ---
Mainline is fine. I accidently installed 4.0 over 4.2.
--
halcy0n at gentoo dot org changed:
What|Removed |Added
--- Comment #55 from steven at gcc dot gnu dot org 2006-01-15 09:22 ---
The leap indeterminate to uninitialized is simply C99 3.4.3:
1. undefined behavior
behavior, upon use of a nonportable or erroneous program construct or of
erroneous data, for which this International Standard
--- Comment #1 from ebotcazou at gcc dot gnu dot org 2006-01-15 10:01
---
We cannot do anything without a reproducer. See http://gcc.gnu.org/bugs.html.
However, a segfault at runtime on several platforms with -O2 and not -O1 may
hint at an aliasing problem in the code. You could try
--- Comment #14 from ebotcazou at gcc dot gnu dot org 2006-01-15 11:30
---
Created an attachment (id=10645)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10645action=view) [edit]
Improved patch
Works For Me(tm).
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25716
--- Comment #11 from nathan at gcc dot gnu dot org 2006-01-15 14:04 ---
What's happening is that we parse IT::B as a type specifier and then squirrel
away a preparsed template type specifier, but because IT::B is a
non-dependent type, the preparsed specifier becomes simply ::B, losing
g++-4.0.1 (also reproduced with g++-3.4.4) fails to add the linkage name of the
class constructor to the debugging info, making it impossible to set
breakpoints in classes containing more than one constructor (e.g. with gdb).
How to reconstruct: Save the following as test.hpp:
class TestClass {
I can't figure out how to get gcc to build using a local build of glibc. I've
built and installed glibc-2.3.6 in /usr/glibc2. As I understand it, I need to
make a cross-compiler in order to make gcc with the new glibc2 (nothing told me
to do this, its just the only way I can kinda get it to
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-01-15 16:19 ---
HUH The linkage_name is not needed for gdb, well it should not be needed.
This is also a dup of bug 11774 which has a better description of why
linkage_name is going away.
Also I tried with a newer gdb
--- Comment #5 from pinskia at gcc dot gnu dot org 2006-01-15 16:19 ---
*** Bug 25793 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 2006-01-15 16:29 ---
You should be setting BOOT_LDFLAGS and not BOOT_CFLAGS for the ld options.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
extern const char *mystr; /* normally in a header */
const char *mystr __attribute__ ((externally_visible));
What happens is that we call cgraph_varpool_node from
handle_externally_visible_attribute
which adds the second decl (which will not exist
/home/pinskia/src/checkin/trunk/gcc/testsuite/gcc.target/i386/cmov6.c:1: error:
CPU you selected does not support x86-64 instruction set^M
/home/pinskia/src/checkin/trunk/gcc/testsuite/gcc.target/i386/cmov6.c:1: error:
CPU you selected does not support x86-64 instruction set^M
FAIL:
--- Comment #1 from ian at gcc dot gnu dot org 2006-01-15 17:06 ---
Subject: Bug 25796
Author: ian
Date: Sun Jan 15 17:06:14 2006
New Revision: 109723
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=109723
Log:
PR testsuite/25796
* gcc.target/i386/cmov6.c: Use
--- Comment #2 from ian at airs dot com 2006-01-15 17:07 ---
Fixed.
--
ian at airs dot com changed:
What|Removed |Added
CC|
FAIL: 21_strings/basic_string/cons/char/6.cc (test for excess errors)
Excess errors:
/usr/bin/ld:
testsuite_abi.o(.text._ZNSs12_S_constructIPcEES0_T_S1_RKSaIcESt20forward_iterator_tag[char*
std::basic_stringchar, std::char_traitschar, std::allocatorchar
::_S_constructchar*(char*, char*,
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-01-15 17:22 ---
Oh and also on powerpc64-linux-gnu:
http://gcc.gnu.org/ml/gcc-testresults/2006-01/msg00755.html
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25797
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-01-15 17:23 ---
This worked with rev 109555.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #1 from paolo at gcc dot gnu dot org 2006-01-15 18:04 ---
Subject: Bug 25626
Author: paolo
Date: Sun Jan 15 18:04:31 2006
New Revision: 109726
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=109726
Log:
2006-01-15 Paolo Carlini [EMAIL PROTECTED]
Gabriel
--- Comment #2 from pcarlini at suse dot de 2006-01-15 18:06 ---
Fixed for 4.2.
--
pcarlini at suse dot de changed:
What|Removed |Added
Status|UNCONFIRMED
--- Comment #3 from pcarlini at suse dot de 2006-01-15 18:09 ---
I know what's going on, I saw this with stock binutils 2.16.1 on x86-linux.
See:
http://gcc.gnu.org/ml/libstdc++/2006-01/msg00051.html
And, there is also another issue with --gc-sections, this one:
--- Comment #11 from rguenth at gcc dot gnu dot org 2006-01-15 19:11
---
Created an attachment (id=10647)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10647action=view)
patch aft the point I stopped working on this
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22568
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-01-15 19:28 ---
*** This bug has been marked as a duplicate of 24958 ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #5 from pinskia at gcc dot gnu dot org 2006-01-15 19:28 ---
*** Bug 25146 has been marked as a duplicate of this bug. ***
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24958
--- Comment #12 from pinskia at gcc dot gnu dot org 2006-01-15 20:03
---
Actually the one left now is the one in comment #0 and only the second testcase
which needs the tree combiner. everything else has been fixed in 4.2.0 for
sure.
--
pinskia at gcc dot gnu dot org changed:
--- Comment #6 from pinskia at gcc dot gnu dot org 2006-01-15 20:08 ---
What really should happen is that we should change the loop to be something
like which helps a different bug too (I cannot find it right now but it has to
do with pulling stuff out of the loops):
void bar(void);
--- Comment #7 from pinskia at gcc dot gnu dot org 2006-01-15 20:12 ---
Oh, that was PR 23970.
And I had meant:
void bar(void);
void foo(int ie, int je)
{
int i, j;
if (0je 0 ie)
{
j = 0;
do {
i =0;
do {
bar();
i++;
} while (i ie);
j++;
} while (j
--- Comment #8 from rakdver at gcc dot gnu dot org 2006-01-15 20:15 ---
Unswitching the condition (i ie) (plus empty loop removal) would produce this
code. Nevertheless, this is a fairly common case, so perhaps it might make
sense to special-case it in loop header copying (for
--- Comment #5 from pinskia at gcc dot gnu dot org 2006-01-15 20:26 ---
Hmm, we get:
foo:
movl4(%esp), %edx
xorl%ecx, %ecx
movl$1, %eax
cmplg+4, %ecx
jb .L3
cmplg, %edx
jb .L3
ret
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Status|SUSPENDED |NEW
Last reconfirmed|2005-05-04 18:12:43 |2006-01-15
--- Comment #2 from pault at gcc dot gnu dot org 2006-01-15 20:33 ---
(In reply to comment #1)
Confirmed.
Thanks, Harald. I will follow this up on a ~few weekish timescale.
Paul
--
pault at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #28 from tkoenig at gcc dot gnu dot org 2006-01-15 21:07
---
Patch for environment variable in for review.
--
tkoenig at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #14 from belyshev at depni dot sinp dot msu dot ru 2006-01-15
21:22 ---
PING!!!
--
belyshev at depni dot sinp dot msu dot ru changed:
What|Removed |Added
--- Comment #5 from pinskia at gcc dot gnu dot org 2006-01-15 21:35 ---
I am going to look into this soon but I don't think it is an aliasing issue as
shown by:
# SFT.0_6 = V_MUST_DEF SFT.0_5;
buf[0] = 3;
# VUSE SFT.0_6;
D.1523_8 = buf[0];
--
pinskia at gcc dot gnu dot
--- Comment #1 from laurent at guerby dot net 2006-01-15 21:41 ---
Did you try the obvious run_acats patch?
LD_LIBRARY_PATH=$ADA_INCLUDE_PATH:$BASE:$LD_LIBRARY_PATH
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25777
--- Comment #7 from kazu at gcc dot gnu dot org 2006-01-15 21:44 ---
In the original test case, TRUNC_DIV_EXPR is used, but we can also use
TRUNC_MOD_EXPR to cause a similar problem. See below.
#include stdio.h
signed char a = -4;
#if 0
#define CALC(A) (((unsigned int) (signed int)
--- Comment #2 from dave at hiauly1 dot hia dot nrc dot ca 2006-01-15
21:53 ---
Subject: Re: acats_run doesn't include gcc base directory in LD_LIBRARY_PATH
--- Comment #1 from laurent at guerby dot net 2006-01-15 21:41 ---
Did you try the obvious run_acats patch?
Attached code when compiled by gcc version 4.2.0 20060113 (experimental) using
--
gcc -O1 -fmodulo-sched -ftracer -c insmod.c -o insmod.o
--
fails like this:
--
insmod.c: In function #8216;main#8217;:
insmod.c:143: internal compiler error: Segmentation fault
Please
--- Comment #1 from drab at kepler dot fjfi dot cvut dot cz 2006-01-15
21:59 ---
Created an attachment (id=10648)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10648action=view)
Triggers the bug
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25798
--- Comment #5 from mmitchel at gcc dot gnu dot org 2006-01-15 22:11
---
I'm leaving this at P3 until we have more information. Clearly, if this is a
general problem that affets primary/secondary targets, we should increase the
priority.
--
--- Comment #14 from mmitchel at gcc dot gnu dot org 2006-01-15 22:13
---
We're generating correct code, so I've marked this as P2, rather than P1.
--
mmitchel at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #9 from mmitchel at gcc dot gnu dot org 2006-01-15 22:19
---
I agree that this looks related to PR 16269.
In that PR, RTH suggests that the right way to fix this is for the front end to
be more explicit about the lifetime of the temporaries, which definitely seems
the
--- Comment #1 from mmitchel at gcc dot gnu dot org 2006-01-15 22:20
---
Marking as P2, since this is just an accepts-invalid regression.
--
mmitchel at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #10 from sabre at nondot dot org 2006-01-15 22:23 ---
Actually, it would be impossible/impractical for the middle end to do this.
The middle end can't know that the called functions (which are passed the stack
objects by reference) don't hang on to a pointer to these
Attached code when compiled by gcc version 4.2.0 20060113 (experimental) using
--
gcc -O1 -fmodulo-sched -c insmod.c -o insmod.o
--
makes the cc1 (preprocessor) process stall indefinitely (well I let it few
minutes, then killed manually. Tested only on x86. It is a regression,
--- Comment #1 from drab at kepler dot fjfi dot cvut dot cz 2006-01-15
22:26 ---
Created an attachment (id=10649)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10649action=view)
Triggers the problem
Same test file as in bug 25798.
--
--- Comment #4 from mmitchel at gcc dot gnu dot org 2006-01-15 22:27
---
This kind of code is common so this is a P1.
--
mmitchel at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #7 from mmitchel at gcc dot gnu dot org 2006-01-15 22:30
---
This is not critical, as it only affects secondary uses of the compiler.
--
mmitchel at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #10 from mmitchel at gcc dot gnu dot org 2006-01-15 22:43
---
The claim in Comment #9 is that this is a 4.1 regression as well as a 4.0
regression, so I've udpated the subject line. It would be interesting to know
if this affects mainline as well.
--
mmitchel at gcc
--- Comment #5 from mmitchel at gcc dot gnu dot org 2006-01-15 22:43
---
This is a relatively obscure case with a relatively minor failure mode; P2.
--
mmitchel at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from drab at kepler dot fjfi dot cvut dot cz 2006-01-15
22:47 ---
OK, sorry, I somehow thought cc1 was a preprocessor, it isn't. My mistake, but
anyway.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25799
--- Comment #2 from mmitchel at gcc dot gnu dot org 2006-01-15 22:47
---
68k is not a primary platform; P5.
--
mmitchel at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #10 from mmitchel at gcc dot gnu dot org 2006-01-15 22:50
---
I think it's unwise to backport -Wstrict-aliasing for C++ to 4.0. As Jakub
says, this is going to break -Werror builds for some packages, and, contrary to
Andrew's claim, there are relatively common situations
--- Comment #2 from mmitchel at gcc dot gnu dot org 2006-01-15 22:51
---
I think we should understand this problem, at least, before 4.0.3.
--
mmitchel at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #11 from pinskia at gcc dot gnu dot org 2006-01-15 22:52
---
(In reply to comment #10)
The claim in Comment #9 is that this is a 4.1 regression as well as a 4.0
regression, so I've udpated the subject line. It would be interesting to know
if this affects mainline as
--- Comment #4 from mmitchel at gcc dot gnu dot org 2006-01-15 22:54
---
ICE on valid; P1.
--
mmitchel at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from mmitchel at gcc dot gnu dot org 2006-01-15 22:57
---
Wrong code on primary platform; P1.
Kazu, does your patch for PR 23150 apply to 4.0? If so, would you please test
that change?
--
mmitchel at gcc dot gnu dot org changed:
What|Removed
--- Comment #6 from mmitchel at gcc dot gnu dot org 2006-01-15 22:57
---
ICE on valid; P1.
--
mmitchel at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #3 from mmitchel at gcc dot gnu dot org 2006-01-15 22:58
---
gcov is not core functionality; P2.
--
mmitchel at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #7 from mmitchel at gcc dot gnu dot org 2006-01-15 22:59
---
SH is not a primary platform; P5.
--
mmitchel at gcc dot gnu dot org changed:
What|Removed |Added
I just tried to call cc1 of gcc version 4.2.0 20060113 (experimental) on an x86
directly with
-
./cc1 --help
-
in a hope, that it would tell me more about what exactly it is (I assume a C
front end). And the result was this:
--
$ ./cc1 --help
The following options
--- Comment #12 from mmitchel at gcc dot gnu dot org 2006-01-15 23:12
---
I agree that this should be a P1.
Why do we think IT::B is a non-dependent type? It should be considered
dependent, because we may have a specialization of I for which B is not a base
class. There are some
--- Comment #14 from mmitchel at gcc dot gnu dot org 2006-01-15 23:15
---
This is valid code, but not particularly commonplace code. Furthermore, it
doesn't look like we've got any good way to fix this -- except for the patch in
Comment #8. What were the results of the testing
--- Comment #15 from steven at gcc dot gnu dot org 2006-01-15 23:22 ---
I don't recall the results of testing this.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23200
--- Comment #8 from joseph at codesourcery dot com 2006-01-15 23:52 ---
Subject: Re: [4.0/4.1/4.2 Regression] Internal compiler error
(segfault) instead of error message
On Sun, 8 Jan 2006, steven at gcc dot gnu dot org wrote:
My hack-around is to deal with
--- Comment #13 from mmitchel at gcc dot gnu dot org 2006-01-15 23:57
---
The problem is that we originally encounter the nested name specifier IT::B
during a call from cp_parser_constructor_declarator_p. That function sets
check_dependency_p to false, because we do have to resolve
--- Comment #2 from schwab at suse dot de 2006-01-16 00:01 ---
This is no longer reproducible with 4.0.2. It is also not a regression.
--
schwab at suse dot de changed:
What|Removed |Added
--- Comment #14 from mmitchel at gcc dot gnu dot org 2006-01-16 00:04
---
Created an attachment (id=10650)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10650action=view)
Patch that disallows nested-name-specifiers for constructors when in class
scope.
This patch is not
--- Comment #15 from bangerth at math dot tamu dot edu 2006-01-16 00:10
---
Subject: Re: [4.1/4.2 regression] Rejects old-style using
declaration
For the original submitter: ARM-style access declarations (e.g.,
IT::B::foo;) are deprecated in current C++. The preferred way to
extern int (*a)[];
void g(void) { a++; }
yields the diagnostics
t2.c: In function 'g':
t2.c:2: error: increment of pointer to unknown structure
t2.c:2: error: arithmetic on pointer to an incomplete type
This isn't a pointer to a structure, it's one to an array; and after giving the
first
GCC doesn't diagnose function-scope VM declarations of variables with external
or internal linkage. (VM declarations of function-local statics are OK.) Four
tests (all should be rejected unconditionally, none are even with -std=c99
-pedantic-errors):
extern int (*a)[];
void f(int b) { extern
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-01-16 00:49 ---
do you have a LANG or a LC_* set?
Because I cannot reproduce this at all.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25800
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-01-16 00:51 ---
*** This bug has been marked as a duplicate of 25636 ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #3 from pinskia at gcc dot gnu dot org 2006-01-16 00:51 ---
*** Bug 25800 has been marked as a duplicate of this bug. ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #4 from pinskia at gcc dot gnu dot org 2006-01-16 00:54 ---
This does make sense as printed is set right before the memset if was NULL.
Can you use make bootstrap instead?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25636
--- Comment #3 from drab at kepler dot fjfi dot cvut dot cz 2006-01-16
01:16 ---
Yes, UTF-8.
$ set|grep LC
LC_ADDRESS=cs_CZ.UTF-8
LC_COLLATE=en_US.UTF-8
LC_CTYPE=en_US.UTF-8
LC_IDENTIFICATION=cs_CZ.UTF-8
LC_MEASUREMENT=cs_CZ.UTF-8
LC_MESSAGES=en_US.UTF-8
LC_MONETARY=cs_CZ.UTF-8
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-01-16 01:19 ---
Confirmed.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #5 from drab at kepler dot fjfi dot cvut dot cz 2006-01-16
01:24 ---
(In reply to comment #1)
I cannot reproduce this on either powerpc-darwin or x86_64-linux-gnu.
Confirmed here, irreproducible on x86_64, but occures on plain 32-bit x86.
Just in case LANG* or LC_* has
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-01-16 01:25 ---
The problem with the first error message is obvious where it goes wrong (in
c-typeck.c):
if (!COMPLETE_OR_VOID_TYPE_P (TREE_TYPE (result_type)))
{
if (code ==
--- Comment #6 from drab at kepler dot fjfi dot cvut dot cz 2006-01-16
01:33 ---
(In reply to comment #2)
Program received signal SIGSEGV, Segmentation fault.
0x083580bd in print_filtered_help (flag=536870912) at ../.././gcc/opts.c:1301
1301 memset (printed, 0,
--- Comment #7 from drab at kepler dot fjfi dot cvut dot cz 2006-01-16
01:38 ---
(In reply to comment #6)
(In reply to comment #2)
...
So perhaps this should rather be something like:
printed = xrealloc (printed, cl_options_count);
memset (printed, 0, cl_options_count);
Or
--- Comment #8 from pinskia at gcc dot gnu dot org 2006-01-16 01:40 ---
cl_options_count does not change.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25636
--- Comment #9 from drab at kepler dot fjfi dot cvut dot cz 2006-01-16
01:48 ---
OK, so how about this, couldn't this be an issue?
--- opts.c.old 2006-01-15 23:36:53.0 +0100
+++ opts.c 2006-01-16 02:48:17.0 +0100
@@ -1291,7 +1291,7 @@ print_filtered_help
On Jan 15, 2006, at 8:48 PM, drab at kepler dot fjfi dot cvut dot cz
wrote:
--- Comment #9 from drab at kepler dot fjfi dot cvut dot cz
2006-01-16 01:48 ---
OK, so how about this, couldn't this be an issue?
--- opts.c.old 2006-01-15 23:36:53.0 +0100
+++ opts.c
--- Comment #10 from pinskia at gcc dot gnu dot org 2006-01-16 01:50
---
Subject: Re: cc1 and cc1plus --help core
On Jan 15, 2006, at 8:48 PM, drab at kepler dot fjfi dot cvut dot cz
wrote:
--- Comment #9 from drab at kepler dot fjfi dot cvut dot cz
2006-01-16 01:48
--- Comment #11 from drab at kepler dot fjfi dot cvut dot cz 2006-01-16
02:02 ---
OK, now, this is totally weird, because now I checked the 'stage1-cc/cc1'
within the output object compilation tree and it works OK. However the higher
stages 'prev-gcc/cc1' and 'gcc/cc1' fail! I also
--- Comment #12 from drab at kepler dot fjfi dot cvut dot cz 2006-01-16
02:09 ---
From compilation logs, I see:
--
gcc -c -g -DIN_GCC -W -Wall -Wwrite-strings -Wstrict-prototypes
-Wmissing-prototypes -pedantic -Wno-long-long -Wno-variadic-macros
--- Comment #2 from davek at csh dot rit dot edu 2006-01-16 02:21 ---
still won't compile
stage one compiler still linked to old glibc -
$ which ldd
/usr/glibc2/bin/ldd
$ ldd gcc/stage1/xgcc
libc.so.6 = /lib/libc.so.6 (0x40019000)
/lib/ld-linux.so.2 =
--- Comment #3 from pinskia at gcc dot gnu dot org 2006-01-16 02:25 ---
This is not the right forum to ask help for compiling with weird options.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from danglin at gcc dot gnu dot org 2006-01-16 02:26 ---
Subject: Bug 25168
Author: danglin
Date: Mon Jan 16 02:26:42 2006
New Revision: 109740
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=109740
Log:
PR target/25168
* tree.c
--- Comment #4 from davek at csh dot rit dot edu 2006-01-16 02:36 ---
so GCC won't compile with glibc-2.3.6. thanks.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25794
--- Comment #3 from danglin at gcc dot gnu dot org 2006-01-16 02:46 ---
Subject: Bug 25168
Author: danglin
Date: Mon Jan 16 02:46:09 2006
New Revision: 109741
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=109741
Log:
PR target/25168
* tree.c
--- Comment #4 from danglin at gcc dot gnu dot org 2006-01-16 02:47 ---
Fixed by patch.
--
danglin at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #13 from drab at kepler dot fjfi dot cvut dot cz 2006-01-16
02:51 ---
This is how the (relevant) thing looks like, when compiled with -O2
-fomit-frame-pointer. I removed the static modifier of the function, since
then it got merged within other functions and didn't get its
--- Comment #14 from pinskia at gcc dot gnu dot org 2006-01-16 02:55
---
I can reproduce this now after building on x86.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25636
--- Comment #15 from drab at kepler dot fjfi dot cvut dot cz 2006-01-16
03:02 ---
(In reply to comment #13)
This is how the (relevant) thing looks like, when compiled with -O2
-fomit-frame-pointer. I removed the static modifier of the function, since
then it got merged within other
--- Comment #16 from pinskia at gcc dot gnu dot org 2006-01-16 03:03
---
mov%ebx,0x85ac8f4
We are writting to cl_options_count for some reason.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #17 from drab at kepler dot fjfi dot cvut dot cz 2006-01-16
03:09 ---
(In reply to comment #16)
mov%ebx,0x85ac8f4
We are writting to cl_options_count for some reason.
Yes, it is unnecessary, but not wrong, since if you take a closer look, it is
just
movl
--- Comment #18 from pinskia at gcc dot gnu dot org 2006-01-16 03:11
---
(In reply to comment #17)
Yes, it is unnecessary, but not wrong, since if you take a closer look, it is
just
Actually it is wrong as it is in read only memory.
(insn:TI 412 535 40 ../../gcc/opts.c:1301 (set
--- Comment #19 from drab at kepler dot fjfi dot cvut dot cz 2006-01-16
03:16 ---
(In reply to comment #18)
(In reply to comment #17)
Yes, it is unnecessary, but not wrong, since if you take a closer look, it
is
just
Actually it is wrong as it is in read only memory.
OK,
--- Comment #20 from drab at kepler dot fjfi dot cvut dot cz 2006-01-16
03:25 ---
(In reply to comment #18)
(In reply to comment #17)
Yes, it is unnecessary, but not wrong, since if you take a closer look, it
is
just
Actually it is wrong as it is in read only memory.
1 - 100 of 114 matches
Mail list logo
