--- Comment #4 from svanna at operamail dot com 2006-03-29 06:20 ---
(In reply to comment #3)
> I still see this problem on canadian cross build of sh4-montavista-linux
>
> /usr/bin/install: installing multiple files, but last argument,
> `/disk2/build_area/TEMP/gcc-sh_sh4_le-root/disk2
--- Comment #1 from phython at gcc dot gnu dot org 2006-03-29 05:32 ---
Created an attachment (id=11148)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11148&action=view)
prelimiinary patch
This patch bootstraps, but I'm not sure if it causes testsuite regressions.
It triggers in
--- Comment #8 from howarth at nitro dot med dot uc dot edu 2006-03-29
04:32 ---
I can confirm this patch resolves the test case on MacOS X with gcc 4.1
branch...
Before patch...
Tue Mar 28 23:06:11 EST 2006
The following file will take roughly 10 minutes to compile
Tue Mar 28 23:06:2
--- Comment #3 from wbeebe at gmail dot com 2006-03-29 03:52 ---
Subject: Re: gcc 4.1.0 fails to bootstrap build on SuSE 10 using gcc 4.0.3
What do you mean by "static limit"?
On 11 Mar 2006 02:42:02 -, pinskia at gcc dot gnu dot org
<[EMAIL PROTECTED]> wrote:
>
>
> --- Commen
The following code:
struct Foo {
template int func() const;
};
class Bar {
friend int Foo::func() const; // line 6
};
gives the following error under gcc 4.1.0:
C:\djgpp>gcc -c z:\proj\gccerr.cpp
z:\proj\gccerr.cpp:6: error: template-id 'func' for 'int
Foo::func()' does not match
--- Comment #7 from bdavis at gcc dot gnu dot org 2006-03-29 01:47 ---
proposed patch:
http://gcc.gnu.org/ml/fortran/2006-03/msg00517.html
http://gcc.gnu.org/ml/fortran/2006-03/msg00518.html
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21130
--- Comment #27 from quanah at stanford dot edu 2006-03-29 01:47 ---
I'll try the flags and get the attachment to you tomorrow. Today is my
birthday, and my wife doesn't really want me on the computer much. ;)
So far, gcc 4.1.0 looks to be building without issue.
--
http://gcc.gnu
--- Comment #8 from rakdver at gcc dot gnu dot org 2006-03-29 01:41 ---
Subject: Bug 25985
Author: rakdver
Date: Wed Mar 29 01:41:27 2006
New Revision: 112484
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=112484
Log:
PR tree-optimization/25985
* tree-ssa-loop-ni
--- Comment #12 from rakdver at gcc dot gnu dot org 2006-03-29 01:34
---
Subject: Bug 26643
Author: rakdver
Date: Wed Mar 29 01:34:51 2006
New Revision: 112483
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=112483
Log:
PR tree-optimization/26643
* tree-ssa-loop-
--- Comment #2 from chenwj at gcrj dot com 2006-03-29 01:26 ---
Subject: RE: character \ in #include directive
The GCC SourceCode which I'm using is download from gcc.gnu.org, after
compiled, I installed it on Redhat system. So I reported here.
$B!A!A!A!A!A!A!A!A!A!A!A!A!A!A!A!A!A!A
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Severity|normal |enhancement
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26900
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Summary|[4.0,4.1 regression] bad|[4.0/4.1/4.2 regression] bad
|bitops folding
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Severity|normal |blocker
GCC build triplet|i686-linux |
GCC host
--- Comment #4 from rakdver at gcc dot gnu dot org 2006-03-29 01:03 ---
(In reply to comment #1)
> Note that we in principle know the number of iterations - just we cannot prove
> the loop runs at least once in number of iterations analysis. Of course we
> know this because we did loop
--- Comment #9 from sebastian dot pop at cri dot ensmp dot fr 2006-03-29
00:27 ---
Created an attachment (id=11147)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11147&action=view)
proposed fix
this patch (not tested yet) fixes the problem: it avoids a division by zero.
Part of t
--- Comment #8 from paolo at gcc dot gnu dot org 2006-03-29 00:12 ---
Subject: Bug 26777
Author: paolo
Date: Wed Mar 29 00:12:21 2006
New Revision: 112477
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=112477
Log:
2006-03-28 Paolo Carlini <[EMAIL PROTECTED]>
PR libstd
--- Comment #4 from schwab at suse dot de 2006-03-28 23:09 ---
Ignore my last comment. The type matters, and what is needed is indeed a
constant of _integer_ type, but enumerators are not of integer type.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14644
--- Comment #3 from schwab at suse dot de 2006-03-28 23:01 ---
But [expr.const] also says:
An integral constant-expression can involve only literals (2.13), enumerators,
...
Thus enumerators are also integral constant expressions. The distinction
between integral and enumeration is on
--- Comment #4 from sebastian dot pop at cri dot ensmp dot fr 2006-03-28
22:44 ---
Created an attachment (id=11146)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11146&action=view)
first step
with this patch scev returns (int) (char) {0,+,1} but then
chrec_convert_aggressive is
--- Comment #11 from falk at debian dot org 2006-03-28 21:59 ---
Ah. I can reproduce it now. Here is a C test case:
void abort(void);
__attribute__((noinline))
int f (unsigned short word) {
return (word & 0x1) && (((unsigned short) (word & 0x8000)) == 0x8000);
}
int main(void) {
--
pcarlini at suse dot de changed:
What|Removed |Added
Target Milestone|4.2.0 |4.1.1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26777
--- Comment #7 from pcarlini at suse dot de 2006-03-28 21:58 ---
*** Bug 26907 has been marked as a duplicate of this bug. ***
--
pcarlini at suse dot de changed:
What|Removed |Added
-
--- Comment #5 from pcarlini at suse dot de 2006-03-28 21:58 ---
Ok, now I see, the underlying issue is a duplicate of libstdc++/26777, already
fixed in mainline and pending for 4.1.1. Sorry again about the initial
misunderstanding.
*** This bug has been marked as a duplicate of 26777 *
--- Comment #2 from roger at eyesopen dot com 2006-03-28 21:46 ---
I believe that this may not be a g++ bug. The wording of the standard is:
[conv.ptr] An null pointer constant is an *integral* constant expression
(_expr.const_) rvalue of integer type that evaluates to zero.
Ignoring th
--- Comment #10 from apl at alum dot mit dot edu 2006-03-28 21:28 ---
No, you misread the parentheses. I've removed all the EXCESS ONES, leaving
answer = (UInt16(word & 0x3700) == UInt16(0x3000))
& (UInt16(word & 0x8800) == UInt16(0x8000));
Showing that we're testing
--- Comment #4 from pcarlini at suse dot de 2006-03-28 21:27 ---
(In reply to comment #3)
> And this is not true: any number of sungetc() at the beginning of the file
> fails (all return eof()) and the next sbumpc() exactly returns the first char
> of file. Indeed, If I run your testcase
--- Comment #9 from apl at alum dot mit dot edu 2006-03-28 21:26 ---
Created an attachment (id=11145)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11145&action=view)
simplified test case
--
apl at alum dot mit dot edu changed:
What|Removed |
--- Comment #3 from pcarlini at suse dot de 2006-03-28 21:15 ---
(In reply to comment #2)
> My opinion is, that an abitrary number of sungetc() at the beginning of a file
> should not have the effect, that the next sbumpc() returns the first character
> of the file. Independent to the st
--- Comment #26 from ebotcazou at gcc dot gnu dot org 2006-03-28 21:07
---
> Except that it is generated on the fly by mk-sic-ink.sh...
Sorry, I was talking about selected_int_kind.inc... Could you attach this one?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26889
--- Comment #25 from ebotcazou at gcc dot gnu dot org 2006-03-28 21:03
---
> selected_int_kind.f90 (it is just what is shipped with the gcc-4.0.3
> source...)
Except that it is generated on the fly by mk-sic-ink.sh...
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26889
--- Comment #24 from quanah at stanford dot edu 2006-03-28 20:59 ---
I will look at removing the libintl/libiconv bits, but in the past gcc failed
to find them without adding those flags.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26889
--- Comment #23 from quanah at stanford dot edu 2006-03-28 20:59 ---
Created an attachment (id=11144)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11144&action=view)
selected_int_kind.f90
selected_int_kind.f90 (it is just what is shipped with the gcc-4.0.3 source...)
--
http
--- Comment #2 from trumsko at yahoo dot com 2006-03-28 20:58 ---
o.k. I read the comments to libstdc++/9439 and browsed through section 27.5.2
of the ISO standtard again. Unfortunatly I didn't find the proof, that the
example program realy behaves contrary to the standard, as I only fou
--- Comment #8 from falk at debian dot org 2006-03-28 20:58 ---
Huh? The code does
((UInt16(word) & 0x3700) == (UInt16(0x3000) & UInt16(word & 0x8800))) ==
UInt16(0x8000);
which is of course always 0, the left part of the comparison is a comparison,
which can be only 0 or 1, and the
--- Comment #22 from quanah at stanford dot edu 2006-03-28 20:56 ---
I can look at only building GMP static, rather than static & shared.
I have a build of 4.1 happening on Solaris 9 at the moment after fixing the ksh
issue.
--Quanah
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=
--- Comment #21 from ebotcazou at gcc dot gnu dot org 2006-03-28 20:41
---
> /afs/ir.stanford.edu/src/pubsw/languages/gcc-build/sun4x_58/gcc/gfortran
> -B/afs/ir.stanford.edu/src/pubsw/languages/gcc-build/sun4x_58/gcc/
> -B/usr/pubsw/sparc-sun-solaris2.8/bin/ -B/usr/pubsw/sparc-sun-sola
--- Comment #20 from ebotcazou at gcc dot gnu dot org 2006-03-28 20:31
---
> Unsuprisingly,the build still fails after changing it to use "make boostrap"
> in the same exact way:
Maybe "unsurprisingly", but this eliminates a whole category of problems.
Could you remove --with-libintl-
--- Comment #15 from pcarlini at suse dot de 2006-03-28 20:20 ---
*** Bug 26911 has been marked as a duplicate of this bug. ***
--
pcarlini at suse dot de changed:
What|Removed |Added
--- Comment #1 from pcarlini at suse dot de 2006-03-28 20:20 ---
*** This bug has been marked as a duplicate of 26304 ***
--
pcarlini at suse dot de changed:
What|Removed |Added
--- Comment #19 from kargl at gcc dot gnu dot org 2006-03-28 20:18 ---
(In reply to comment #18)
> Unsuprisingly,the build still fails after changing it to
> use "make boostrap" in the same exact way:
>
> ../../../../gcc-4.0.3/libgfortran/intrinsics/selected_int_kind.f90 -fPIC
I've sc
All show:
FAIL: 25_algorithms/prev_permutation/1.cc execution test
From:
http://gcc.gnu.org/ml/gcc-testresults/2006-03/msg01866.html
http://gcc.gnu.org/ml/gcc-testresults/2006-03/msg01789.html
http://gcc.gnu.org/ml/gcc-testresults/2006-03/msg01793.html
--
Summary: failing 25_algorith
--- Comment #5 from kargl at gcc dot gnu dot org 2006-03-28 19:47 ---
Fixed on trunk and 4.1 branch.
--
kargl at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #1 from kargl at gcc dot gnu dot org 2006-03-28 19:46 ---
I'll fix this sometime today. Thanks for the bug report.
--
kargl at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #4 from kargl at gcc dot gnu dot org 2006-03-28 19:38 ---
Subject: Bug 26816
Author: kargl
Date: Tue Mar 28 19:38:26 2006
New Revision: 112468
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=112468
Log:
Steven G. Kargl <[EMAIL PROTECTED]>
PR fortran/26816
--- Comment #7 from roger at eyesopen dot com 2006-03-28 19:34 ---
This should now be fixed on mainline.
--
roger at eyesopen dot com changed:
What|Removed |Added
--- Comment #18 from quanah at stanford dot edu 2006-03-28 19:23 ---
Unsuprisingly,the build still fails after changing it to use "make boostrap" in
the same exact way:
/afs/ir.stanford.edu/src/pubsw/languages/gcc-build/sun4x_58/gcc/gfortran
-B/afs/ir.stanford.edu/src/pubsw/languages/gc
--- Comment #3 from ed at catmur dot co dot uk 2006-03-28 19:15 ---
OK, so it's tetex that's broken. Sorry for the invalid report.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26908
--
tromey at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Last reconfir
--- Comment #13 from law at redhat dot com 2006-03-28 19:13 ---
Subject: Re: [4.1/4.2 Regression] missed jump
threading after unroller
On Wed, 2006-03-22 at 16:06 +0100, Richard Guenther wrote:
> On 3/22/06, Jeffrey A Law <[EMAIL PROTECTED]> wrote:
> > On Wed, 2006-03-22 at 12:
--- Comment #2 from tromey at gcc dot gnu dot org 2006-03-28 19:09 ---
I'm handling this.
See the patch attached to PR 13671.
--
tromey at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #3 from tromey at gcc dot gnu dot org 2006-03-28 19:09 ---
I'm handling this.
--
tromey at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo
--- Comment #2 from tromey at gcc dot gnu dot org 2006-03-28 19:09 ---
Created an attachment (id=11143)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11143&action=view)
initial patch
This patch mostly fixes the problem.
However it is missing some minor bits for windows.
Also it co
--- Comment #4 from tromey at gcc dot gnu dot org 2006-03-28 19:05 ---
Subject: Bug 26441
Author: tromey
Date: Tue Mar 28 19:05:21 2006
New Revision: 112465
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=112465
Log:
Correcting PR number in ChangeLog:
PR libgcj/26441:
--- Comment #3 from tromey at gcc dot gnu dot org 2006-03-28 19:04 ---
I checked in the fix to svn head.
--
tromey at gcc dot gnu dot org changed:
What|Removed |Added
Currently our java/util/zip/InflaterInputStream differs
from Classpath's. Putting ours into Classpath causes regressions there.
Putting Classpath's into libgcj causes regressions in libgcj.
Probably one or both Inflater implementations is incorrect in some way.
--
Summary: re-merging
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-03-28 18:55 ---
Reducing
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26909
Compiling gcc-4.2-20060325 compiles on my FC5 box with the following error
message (gcc-4.1.0-3.src.rpm upgraded to gcc-4.2-20060325.src.rpm):
../xgcc -B ./ -O2 -c -DUNPROTOIZE -g -DIN_GCC -W -Wall -Wwrite-strings
-Wstrict-prototypes -Wmissing-prototypes -pedantic -Wno-long-long
-Wno-variadic-
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-03-28 18:45 ---
There is no garentee that bar will be in the text section.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--
--- Comment #7 from apl at alum dot mit dot edu 2006-03-28 18:40 ---
It's not minor, it causes incorrect code to be generated because it folds the
expression to zero!
--
apl at alum dot mit dot edu changed:
What|Removed |Added
-
--- Comment #1 from hanwen at xs4all dot nl 2006-03-28 18:34 ---
Created an attachment (id=11142)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11142&action=view)
trigger for ICE
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26909
C source attached.
muurbloem:~/vc/gub/target/darwin-x86/build/glib-2.9.6$
PATH=/home/lilydev/vc/gub/target/darwin-x86/system/usr/cross/bin/:$PATH
/home/lilydev/vc/gub/target/darwin-x86/system/usr/cross/bin/i686-apple-darwin8-gcc
-DHAVE_CONFIG_H -I.
-I/home/lilydev/vc/gub/target/darwin-x86/src/gl
--- Comment #1 from ed at catmur dot co dot uk 2006-03-28 18:31 ---
Created an attachment (id=11141)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11141&action=view)
foo.s
Output of gcc -g3 -S foo.c
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26908
foo.c:
asm (
".globl bar\n\t"
"bar:\n\t"
"movl $5, %eax\n\t"
"ret"
);
main() {
return bar();
}
$ gcc -g2 foo.c; ./a.out; echo $?
5
$ gcc foo.c -g3; ./a.out; echo $?
Segmentation fault
139
Disassembly of the a.out compiled with -g3 gives:
(gdb) disass main
Dump of assembler code for funct
--- Comment #8 from pbrook at gcc dot gnu dot org 2006-03-28 18:03 ---
Subject: Bug 23623
Author: pbrook
Date: Tue Mar 28 18:03:06 2006
New Revision: 112460
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=112460
Log:
2006-03-28 Paul Brook <[EMAIL PROTECTED]>
PR middle-
--
mkuvyrkov at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |mkuvyrkov at gcc dot gnu dot
|dot org
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Severity|normal |minor
Summary|[3.3/3.4 Regression] bogus |bogus 'comparis
--- Comment #10 from mkuvyrkov at gcc dot gnu dot org 2006-03-28 17:42
---
Reopen this bug as the patch, which fixes it was reverted from the mainline.
--
mkuvyrkov at gcc dot gnu dot org changed:
What|Removed |Added
--
--- Comment #40 from pinskia at gcc dot gnu dot org 2006-03-28 17:40
---
*** Bug 26903 has been marked as a duplicate of this bug. ***
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21173
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-03-28 17:40 ---
This was fixed in 4.0.1.
*** This bug has been marked as a duplicate of 21173 ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--
--- Comment #1 from pcarlini at suse dot de 2006-03-28 17:38 ---
There is nothing wrong with the current behavior: simply, at the beginning of
the file a putback position cannot be made available (i.e., a seek "-1" fails),
and, consistently, sungetc() returns traits::eof(), it suffices t
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-03-28 17:34 ---
I should note that you are using Redhat's GCC and should have reported it to
them before it was reported here.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26897
--- Comment #8 from malitzke at metronets dot com 2006-03-28 17:07 ---
You are correct. At least as far as the second batch from S.Pop (dated
2006-03-27)
goes. As I did not keep my gcc-4.2.0 binaries relative to the first batch from
S.Pop (dated 2006-03-26) I can not reproduce the non IC
If I use filebuf::sungetc() at the beginning of a file, the result of the next
sbumc() call is not
allways the first character in the file:
#include
#include
using namespace std;
int main()
{
ifstream infile("test.dat");
filebuf* inbuf=infile.rdbuf();
int res;
//at beginning of file
r
--- Comment #3 from likewise at gmx dot net 2006-03-28 16:47 ---
Created an attachment (id=11140)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11140&action=view)
preprocessed C file (bzip2'd)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26906
--- Comment #2 from likewise at gmx dot net 2006-03-28 16:40 ---
By removing the optimization flag (-Os) the compiler no longer ICEs. Also, -O1,
-O2, -O3 are OK.
--
likewise at gmx dot net changed:
What|Removed |Added
--
--- Comment #1 from likewise at gmx dot net 2006-03-28 16:37 ---
Created an attachment (id=11139)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11139&action=view)
preprocessed C file
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26906
ICE when cross-compiling on x86_64 host for armeb target.
Included the command that makes GCC fail (minus all -I include paths) with an
ICE, the output. I will attach the preprocessed C file in a direct follow-up.
See also existing bug 23442 on a different platform.
armeb-linux-gcc -march=armv5t
--- Comment #1 from benjamin at smedbergs dot us 2006-03-28 16:09 ---
Created an attachment (id=11138)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11138&action=view)
Reduced testcase, .i
gcc -fPIC -shared -o libfoo.so nsAppRunner-test6.i
Tested with 4.1 branch after the commit
if you have the visibility-hidden pragma in effect and you override it with a
per-class visibility-default attribute emits a direct call instead of a call
through the PLT.
Reduced-testcase .i file to be attached.
--
Summary: default-visibility class symbol improperly resolved as
--- Comment #5 from law at redhat dot com 2006-03-28 15:38 ---
Subject: Re: [4.2 Regression] ACATS ICE c34002a c52005
spurious storage_error
On Wed, 2006-03-22 at 19:28 +, ebotcazou at gcc dot gnu dot org
wrote:
>
> --- Comment #2 from ebotcazou at gcc dot gnu dot org
--- Comment #4 from law at gcc dot gnu dot org 2006-03-28 15:35 ---
Subject: Bug 26796
Author: law
Date: Tue Mar 28 15:35:47 2006
New Revision: 112453
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=112453
Log:
PR tree-optimization/26796
* tree-ssa-dom.c (propagat
--
law at redhat dot com changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |kenner at gcc dot gnu dot
|dot org |org
--- Comment #6 from apl at alum dot mit dot edu 2006-03-28 15:21 ---
I was wrong, this is still broken in GCC 4.0.2 and 4.1.0 although the original
test case doesn't demonstrate the bug.
/tools/linux/gcc-4.1.0/bin/g++ -c -Werror -Wall -Wextra b.cxx -O2
cc1plus: warnings being treated as
--- Comment #1 from dave at boost-consulting dot com 2006-03-28 15:16
---
Created an attachment (id=11136)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11136&action=view)
Preprocessed C++ source
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26904
--- Comment #3 from rguenth at gcc dot gnu dot org 2006-03-28 15:16 ---
Eh, of course we don't preserve loop information beyond CH. But if we did,
this would be possible?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26900
The enclosed demonstrates. define either SUPPRESS_BUG or SUPPRESS_BUG2 to show
that either not using inheritance or using a template called typer instead of
type will suppress the bug.
--
Summary: A template named the same as its member confuses lookup
through inh
--- Comment #2 from rguenth at gcc dot gnu dot org 2006-03-28 15:14 ---
Zdenek may also have an idea on this.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
---
I am getting this error running a make on mysql on the aix 5.1 os.
I am using 4.0 of the gnu compiler
--
Summary: default.c:577: internal compiler error: in
get_indirect_ref_operands, at tree-ssa-operands.c:1449
Product: gcc
Version: 4.0.0
--- Comment #1 from rguenth at gcc dot gnu dot org 2006-03-28 15:13 ---
Note that we in principle know the number of iterations - just we cannot prove
the loop runs at least once in number of iterations analysis. Of course we
know this because we did loop header copying on the loop and
--- Comment #5 from apl at alum dot mit dot edu 2006-03-28 15:09 ---
Created an attachment (id=11135)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11135&action=view)
simpler test that still fails in 4.x compilers
compile with
g++ -c -Werror -Wall -Wextra -O2 b.cxx
--
ap
--- Comment #9 from law at redhat dot com 2006-03-28 15:01 ---
Subject: Re: [4.2 Regression] ACATS c35507m
cd2a23e cxh1001 failures
On Tue, 2006-03-28 at 03:56 +, kenner at vlsi1 dot ultra dot nyu dot
edu wrote:
>
> --- Comment #8 from kenner at vlsi1 dot ultra dot nyu
double plus_1( double x )
{
asm volatile
(
"fadd %2"
: "=t" (x)
: "0" (x), "u" (1.0)
);
return x;
}
with -fomit-frame-pointer gcc produces:
plus_1:
fldl4(%esp) \
fld1 |- why just not "fld1 ; fldl 4(%esp)" ?
fx
/mnt/gnu/gcc-3.3/objdir/gcc/gcj
-B/mnt/gnu/gcc-3.3/objdir/hppa2.0w-hp-hpux11.11/
libjava/ -B/mnt/gnu/gcc-3.3/objdir/gcc/ --bootclasspath '../lib' --classpath .
-
C -d classes
../../../../../gcc/libjava/classpath/tools/gnu/classpath/tools/*.ja
va ../../../../../gcc/libjava/classpath/tools/gnu/classp
--- Comment #7 from reichelt at gcc dot gnu dot org 2006-03-28 14:50
---
The problem is not fixed.
The reduced testcase from comment #4 still crashes.
--
reichelt at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #6 from malitzke at metronets dot com 2006-03-28 14:45 ---
As no further comments are forthcoming I am taking the liberty to mark this PR
as resolved.
--
malitzke at metronets dot com changed:
What|Removed |Added
---
int foo0(int i0, int i1)
{
int i, j = 0;
for (i=i0; i<=i1+1; ++i)
++j;
return j;
}
we cannot figure out the number of iterations for this loop because of
PR26898 and PR26899.
--
Summary: Number of iterations not know for simple loop
Product: gcc
Versio
Fold currently does not fold a lot of TRUTH_AND/OR_EXPRs created by
tree-ssa-loop-niter.c:tree_simplify_using_condition_1. Like for the testcase
int foo0(int i0, int i1)
{
int i, j = 0;
for (i=i0; i<=i1+1; ++i)
++j;
return j;
}
with PR26898 fixed. We there get
i0D.1520_4 > i1D.1521
--- Comment #4 from patchapp at dberlin dot org 2006-03-28 14:00 ---
Subject: Bug number PR c/26818
A patch for this bug has been added to the patch tracker.
The mailing list url for the patch is
http://gcc.gnu.org/ml/gcc-patches/2006-03/msg01615.html
--
http://gcc.gnu.org/bugzilla
--- Comment #1 from rguenth at gcc dot gnu dot org 2006-03-28 13:59 ---
Testcase:
void foo0(int i0, int i1)
{
if (!(i0 + 1 < i1 + 1 == i0 < i1))
link_error ();
}
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26898
Fold at the moment does not fold comparisons involving signed variables with
a constant offset. Like we get from number-of-iterations analysis for
int foo0(int i0, int i1)
{
int i, j = 0;
for (i=i0; i<=i1+1; ++i)
++j;
return j;
}
where niter->may_be_zero ends up as i0 + 1 < i1 + 2 whic
1 - 100 of 112 matches
Mail list logo
