--- Comment #1 from paolo dot bonzini at lu dot unisi dot ch 2006-01-16
07:56 ---
Subject: Re: New: make clean fails
aoliva at gcc dot gnu dot org wrote:
>It appears that make clean (on a native bootstrap) always fails for me. After
>make clean on a tree containing a build interrup
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-01-16 06:24 ---
The ICE is:
t.cc:33: error: inlined_to pointer is set but no predecesors found
virtual std::events::scrollbar::~scrollbar()/33: (inline copy in void
__static_initialization_and_destruction_0(int, int)/11)
availabilit
--- Comment #6 from pinskia at gcc dot gnu dot org 2006-01-16 06:02 ---
The problem here is that operand_equal_p returns false for these two trees:
unit size
align 8 symtab 0 alias set -1 precision 8 min max
pointer_to_this >
arg 0
QI size u
--- Comment #4 from pinskia at gcc dot gnu dot org 2006-01-16 04:28 ---
This is an infinite loop in df.c:
0x00559052 in df_hybrid_search_backward (bb=0x2b34e400,
dataflow=0xc15080, single_pass=0 '\0')
at /home/pinskia/src/checkin/trunk/gcc/df-core.c:465
465 if
--- Comment #8 from kkojima at gcc dot gnu dot org 2006-01-16 04:26 ---
Patches were committed already.
Sorry for forgetting to change this as FIXED.
--
kkojima at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #3 from pinskia at gcc dot gnu dot org 2006-01-16 04:26 ---
I saw this while reducing PR 25798 also.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-01-16 03:59 ---
Backtrace:
#0 0x004fe035 in bitmap_set_bit (head=0xc61150, bit=Variable "bit" is
not available.
)
at /home/pinskia/src/checkin/trunk/gcc/bitmap.c:116
#1 0x0084b53e in mark_reg_change (reg=Variab
--- Comment #27 from drab at kepler dot fjfi dot cvut dot cz 2006-01-16
03:42 ---
(In reply to comment #23)
...
> it really looks as that writing, but I still didn't figure out where is the
> third argument of the memset. Do you see it set somewhere?
OK, I think I see it now. The only
--- Comment #26 from pinskia at gcc dot gnu dot org 2006-01-16 03:40
---
(In reply to comment #24)
> (In reply to comment #22)
> > Looks like PR 15248 is not really fixed on the mainline.
>
> Yes, the commit there seems to be only from the 4_0 branch.
It was also commited to the other
--- Comment #25 from pinskia at gcc dot gnu dot org 2006-01-16 03:39
---
CCing Bernd Schmidt as he is the reload expert and the fact he touched reload
code for rejecting read only memory reloads.
--
pinskia at gcc dot gnu dot org changed:
What|Removed
--- Comment #24 from drab at kepler dot fjfi dot cvut dot cz 2006-01-16
03:34 ---
(In reply to comment #22)
> Looks like PR 15248 is not really fixed on the mainline.
Yes, the commit there seems to be only from the 4_0 branch.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25636
--- Comment #23 from drab at kepler dot fjfi dot cvut dot cz 2006-01-16
03:33 ---
(In reply to comment #20)
> (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 i
--- Comment #22 from pinskia at gcc dot gnu dot org 2006-01-16 03:32
---
Looks like PR 15248 is not really fixed on the mainline.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--
--- Comment #21 from pinskia at gcc dot gnu dot org 2006-01-16 03:28
---
(In reply to comment #20)
> I assume this means "read-only" just as a hint for the compiler, right? Not
> that it would really actually reside in a "read-only" memory. So the writing
> should not cause the segfault
--- 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.
--- 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.
--- 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 #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
movlcl_o
--- 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 #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 ot
--- 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 #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 #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
Status|
--- 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=gcc&view=rev&rev=109741
Log:
PR target/25168
* tree.c (get_file_function_n
--- 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 #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=gcc&view=rev&rev=109740
Log:
PR target/25168
* tree.c (get_file_function_n
--- 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 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 => /lib/ld-linux.s
--- 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
-Wold-style-definit
--- 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 noti
--- 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 -
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 2006
--- 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 (unsigned
--- 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 #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 p
--- 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, cl_options
--- 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 == PREINCREMENT_EX
--- 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 t
--- 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
Status|UNCON
--- 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
LC_NAME
--- 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 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 #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 #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
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 int
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 diagnos
--- 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.,
> "I::B::foo;") are deprecated in current C++. The preferred way to w
--- 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=10650&action=view)
Patch that disallows nested-name-specifiers for constructors when in class
scope.
This patch is not recomme
--- 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 #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 I::B
during a call from cp_parser_constructor_declarator_p. That function sets
check_dependency_p to false, because we do have to resolve depe
--- 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 label_context_stack_vm==
--- 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 #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 mention
--- 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 I::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 cases
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 are
--- 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
--- 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 #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
Prio
--- 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 #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
Prio
--- 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 w
--- 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 #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 wh
--- 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 #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 #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 #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 dot
--- 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 #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 #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=10649&action=view)
Triggers the problem
Same test file as in bug 25798.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi
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, sin
--- 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 objects
--- 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 #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 bes
--- 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 #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.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi
--- 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=10648&action=view)
Triggers the bug
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25798
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 ‘main’:
insmod.c:143: internal compiler error: Segmentation fault
Please submit a full bu
--- 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?
>
> LD
--- 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
signed char a = -4;
#if 0
#define CALC(A) (((unsigned int) (signed int) (A)) / 2
--- 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 #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 ;
buf[0] = 3;
# VUSE ;
D.1523_8 = buf[0];
--
pinskia at gcc dot gnu dot org changed:
--- 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
L
--- 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 #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
--
--
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 20:30:
--- 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
.p2ali
--- 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 perform
--- 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 (0http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23855
--- 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);
void
--- 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 #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 #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 #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=10647&action=view)
patch aft the point I stopped working on this
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22568
--- 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:
http://gcc.gnu.org
--- 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 #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=gcc&view=rev&rev=109726
Log:
2006-01-15 Paolo Carlini <[EMAIL PROTECTED]>
Gabrie
--- 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 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
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_string, std::allocator
>::_S_construct(char*, char*, std::allocator const&,
std::forward_iterator_
1 - 100 of 114 matches
Mail list logo
