--- Comment #1 from daney at gcc dot gnu dot org 2007-03-19 07:09 ---
Patch here:
http://gcc.gnu.org/ml/java-patches/2007-q1/msg00693.html
--
daney at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #4 from Luc dot Maisonobe at free dot fr 2007-03-19 08:08
---
Sorry, I missed this.
One question remains, though: does this also stand for the -U flag in the diff
command from script libjava/classpath/scripts/check_jni_methods.sh ? I did not
find anything about it (but
--- Comment #6 from fxcoudert at gcc dot gnu dot org 2007-03-19 08:13
---
Subject: Bug 31203
Author: fxcoudert
Date: Mon Mar 19 08:13:30 2007
New Revision: 123051
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=123051
Log:
PR fortran/31203
* trans-expr.c
--
fxcoudert at gcc dot gnu dot org changed:
What|Removed |Added
Known to fail|4.1.3 4.2.0 4.3.0 |4.1.3 4.2.0
Known to work||4.3.0
--
fxcoudert at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |fxcoudert at gcc dot gnu dot
|dot org
--- Comment #3 from fxcoudert at gcc dot gnu dot org 2007-03-19 09:05
---
Created an attachment (id=13229)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13229action=view)
Patch that fixes the issue reported
The attached patch fixes the issue for the reported testcase. I checked
--- Comment #2 from burnus at gcc dot gnu dot org 2007-03-19 09:07 ---
Gfortran and Portland group Fortran accept it by default, while xlf, ifort,
NAG f95 and g95 reject it by default.
I'd say the current behaviour is OK.
Then close as won't fix.
--
burnus at gcc dot gnu dot
--- Comment #17 from pluto at agmk dot net 2007-03-19 09:09 ---
4.1.2 release and 4.2.0-RC1 still fails.
4.3 not tested.
--
pluto at agmk dot net changed:
What|Removed |Added
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-03-19 09:14 ---
Confirmed, via a dicussion that is going on the gnustep mailing list. The
reason why most people don't see an issue with this anymore is because Linux
uses --as-needed option to the linker.
--
pinskia at gcc
--- Comment #6 from pluto at agmk dot net 2007-03-19 09:15 ---
`int f( int x ) { return x / x; }' still not optimized on 4.2/4.3
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24333
Using SVN revision 123051
cat bug.ii
templateclass T1 struct S1 {
templatebool T2 struct S2;
templatetemplatebool class T3 struct S3 {
templatetypename T4 = S3S2 struct S4 {};
struct S5 : S4 {
g++ bug.ii
bug-segv.ii:5: internal compiler error: Segmentation fault
--
Summary: ICE:
--- Comment #5 from pluto at agmk dot net 2007-03-19 09:25 ---
4.2/ppc works for me and no one have time to track this down on 4.1,
so closing...
--
pluto at agmk dot net changed:
What|Removed |Added
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-03-19 09:26 ---
It seems like this can be made into valid code and still ICE.
The valid code is:
templateclass T1 struct S1 {
templatebool T2 struct S2;
templatetemplatebool class T3 struct S3 {
templatetypename T4=S3S2 struct S4
--- Comment #3 from dominiq at lps dot ens dot fr 2007-03-19 09:28 ---
BTW, did I miss an option to turn this optimization off?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31249
--- Comment #24 from eesrjhc at bath dot ac dot uk 2007-03-19 09:30 ---
(In reply to comment #20)
(In reply to comment #19)
...
this isn't enough even with building with this brand new
gcc-4.3.0_alpha20070309.
I'll repeat it with include of proper stdio.h, which looks in gentoo
Hello,
I try to compile the rrdtool on my system
a digitalserver 7305 (rawhide) with debian 3.1 kernel 2.6.20 and
gcc 4.1.1.
The tool does some floatingpoint calculation
using IEEE Math.
If I try to run ./configure there is a problem:
checking if IEEE math works out of the box... no
checking
--- Comment #25 from rguenth at gcc dot gnu dot org 2007-03-19 09:55
---
Well, so unless somebody has a testcase that is miscompiled (preferably at the
tree level ;)) and that I can investigate with a cross compiler I cannot do
anything here :/
--
--- Comment #13 from rguenth at gcc dot gnu dot org 2007-03-19 10:36
---
I'll take care (the patch in comment #12 looks ok, though we can keep the
'else')
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #4 from rguenth at gcc dot gnu dot org 2007-03-19 10:43 ---
There is no option to turn it off. But for !TARGET_C99_FUNCTIONS and
!TARGET_HAS_SINCOS targets it's off. Usually (in fact, for every libm I looked
into), cexp is implemented as
complex double cexp (complex
--- Comment #5 from wouter dot vermaelen at pi dot be 2007-03-19 10:55
---
I hit the same problem. My testcase is slightly shorter, but i'm not sure it's
also actually simpler. Requires -O -finline-functions
cat bug.ii
struct S {
S();
~S() {}
void f();
};
void
In 4.2 with -O2 -m32 -fomit-frame-pointer on x86_64:
unsigned int foo (unsigned int x)
{
return (8 - (x 7)) 7;
}
results in andl $7, reg; negl reg; andl $7, reg.
On 4.3 apparently some RTL optimization catches this, but it is still a missed
tree optimization, fold should be able to fold:
(cst
--- Comment #26 from rguenth at gcc dot gnu dot org 2007-03-19 11:07
---
Btw, did you compare testsuite results from a non-bootstrapped patched vs.
unpatched tree?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31169
--- Comment #5 from burnus at gcc dot gnu dot org 2007-03-19 11:12 ---
Current result:
a = ABCDEFXXX
b = ABCDEF
c = ABCDEFXXX
Result by g95/ifort:
ABCDEFXXX
ABCDEFXXX
ABCDEFXXX
Result by NAG f95, SUN and HP:
ABCDEFXXX
ABCXXDEF
ABCDEFXXX
I think the latter is correct:
--- Comment #1 from rguenth at gcc dot gnu dot org 2007-03-19 11:17 ---
(x 7) + 8 7 is actually ((x 7) + 8) 7
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31261
--- Comment #2 from rguenth at gcc dot gnu dot org 2007-03-19 11:19 ---
You would need to enhance associate_trees () or the reassoc pass to fix this.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from bkoz at gcc dot gnu dot org 2007-03-19 11:35 ---
Wolfgang: I agree. We should have also parallelized this for SSE/Altivec a la
MacSTL.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31000
--- Comment #5 from bkoz at gcc dot gnu dot org 2007-03-19 11:37 ---
Fixed
--
bkoz at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #6 from dominiq at lps dot ens dot fr 2007-03-19 12:15 ---
Result by g95/ifort:
You can probably add xlf to this list (should be checked
on a recent version).
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31199
--- Comment #7 from dominiq at lps dot ens dot fr 2007-03-19 12:18 ---
You can probably add xlf to this list
and Portland Group Fortran.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31199
$ cat uu.f90
print *, 7_8*huge(0_8)+17_8
end
$ gfortran -static uu.f90 -fno-range-check
uu.f90: In function MAIN__:
uu.f90:1: internal compiler error: in gfc_conv_mpz_to_tree, at
fortran/trans-const.c:183
There's an assertion in gfc_conv_mpz_to_tree:
/* We assume that all numbers are
--- Comment #1 from fxcoudert at gcc dot gnu dot org 2007-03-19 12:24
---
This is mine, I'm deep into these things right now :(
--
fxcoudert at gcc dot gnu dot org changed:
What|Removed |Added
--
fxcoudert at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |fxcoudert at gcc dot gnu dot
|dot org
--- Comment #3 from gdr at cs dot tamu dot edu 2007-03-19 12:40 ---
Subject: Re: std::valarray should be annotated with OpenMP directives
bkoz at gcc dot gnu dot org [EMAIL PROTECTED] writes:
|
| Wolfgang: I agree. We should have also parallelized this for SSE/Altivec a la
| MacSTL.
--- Comment #5 from dominiq at lps dot ens dot fr 2007-03-19 12:43 ---
There is no option to turn it off. But for !TARGET_C99_FUNCTIONS and
!TARGET_HAS_SINCOS targets it's off.
From my understanding of the thread
http://gcc.gnu.org/ml/gcc/2007-03/msg00639.html
if !TARGET_64BIT,
--- Comment #8 from burnus at gcc dot gnu dot org 2007-03-19 12:53 ---
Reading further, I find:
For nonadvancing input [...] If no error condition occurred in a nonadvancing
output statement, the file position is not changed.
If I understand the whole correctly, it means:
- The
--- Comment #6 from mueller at gcc dot gnu dot org 2007-03-19 13:21 ---
it seems to be caused by -r121780
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30864
--- Comment #14 from rguenth at gcc dot gnu dot org 2007-03-19 13:36
---
Subject: Bug 31254
Author: rguenth
Date: Mon Mar 19 13:36:29 2007
New Revision: 123060
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=123060
Log:
2007-03-19 Andrew Pinski [EMAIL PROTECTED]
Richard
--- Comment #15 from rguenth at gcc dot gnu dot org 2007-03-19 13:37
---
Fixed.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
I'm not sure, if this can be called a bug, but it is at least a really bad case
of poor optimization.
The following program calls the function 'Square' several times, either with
x=1000 or x=i*2-i-i+1000 (which is also 1000). The second version is executed
much FASTER. I see no reason, why this
--- Comment #9 from manu at gcc dot gnu dot org 2007-03-19 13:56 ---
(In reply to comment #8)
I agree with you Paolo. The front-end should make sure that its
artefacts don't adversily affect diagnostics we emit.
I agree to some extend. The reason why the try/catch is there is
--- Comment #4 from bangerth at dealii dot org 2007-03-19 14:03 ---
(In reply to comment #3)
I suspect that parallelizing for SSE/Altivec might be more peneficial
in most cases than for OpenMP -- OpenMP is a 1,000 pounds gorilla.
I certainly agree. The beauty is that one may have
imac20:/tmp/javolution mohanembar$ i686-apple-darwin8-gcj -v -save-temps -c -O2
javolution.jar
Using built-in specs.
Reading specs from
/datal/gcc/i686-apple-darwin8/bin/../lib/gcc/i686-apple-darwin8/4.3.0/../../../libgcj.spec
rename spec startfile to startfileorig
rename spec lib to liborig
--- Comment #1 from membar at gcc dot gnu dot org 2007-03-19 14:43 ---
Created an attachment (id=13230)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13230action=view)
javolution.jar (BSD license)
source distribution from http://www.javolution.org/
--
--- Comment #2 from membar at gcc dot gnu dot org 2007-03-19 14:44 ---
Created an attachment (id=13231)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13231action=view)
temps file
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31264
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |jakub at gcc dot gnu dot org
|dot org
--
aph at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |aph at gcc dot gnu dot org
|dot org
--- Comment #10 from gdr at cs dot tamu dot edu 2007-03-19 15:19 ---
Subject: Re: Strange -Wunreachable-code warning with _GLIBCXX_DEBUG
manu at gcc dot gnu dot org [EMAIL PROTECTED] writes:
| And I think that we should not warn about generated code. No matter if it is
| generated by
--- Comment #5 from gdr at cs dot tamu dot edu 2007-03-19 15:23 ---
Subject: Re: std::valarray should be annotated with OpenMP directives
bangerth at dealii dot org [EMAIL PROTECTED] writes:
| (In reply to comment #3)
| I suspect that parallelizing for SSE/Altivec might be more
--- Comment #6 from jakub at gcc dot gnu dot org 2007-03-19 15:26 ---
Caused by PR21299 patch.
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #12 from jakub at gcc dot gnu dot org 2007-03-19 15:27 ---
This fix causes PR30505 regression.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21299
With std f95 or f2003, reshape is not allowed in real arrays, but it is in
integer ones or with std legacy or gnu.
It seems the standard should actually allow this construct (see
http://gcc.gnu.org/ml/fortran/2007-02/msg1.html), so here is a bug report
(I didn't anything similar).
$cat
When a component of a custom type is a character, taking a substring of it
triggers a warning about the variable being truncated (with -Wall). Maybe it is
not the correct syntax to get a substring out of a character component (still,
it works fine for printing, for example)?
$cat test.f90
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-03-19 15:47 ---
On the trunk, there is no difference in the assembly produced for PPC-darwin.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #3 from aph at gcc dot gnu dot org 2007-03-19 15:53 ---
Created an attachment (id=13232)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13232action=view)
Failing routine
A stripped-down test case that demonstrates the failure.
--
--- Comment #4 from aph at gcc dot gnu dot org 2007-03-19 15:57 ---
Created an attachment (id=13233)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13233action=view)
.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31264
This wrong code (missing typename):
templateclass T
struct A
{
typedef typename T::B C;
void f(C::D x);
};
gives the following error message:
a.cpp:5: error: '#'typename_type' not supported by dump_decl#declaration
error::D' is not a type
instead of 'C::D' is not a type.
--
--- Comment #27 from sje at cup dot hp dot com 2007-03-19 16:11 ---
I did a non-bootstrap build and test on hppa1.1-hp-hpux11.11 over the weekend
(C only) and I got two failures that I don't normally see, builtin-pow-mpfr-1.c
and builtin-sin-mpfr-1.c. I am not certain these failures
It took me several hours to try to extract a usable test-case for this issue,
so I hope you will be able to make sense out of it.
The problem : compiling with current g++ 4.2, with -O2, makes the attached
program loop infinitely, while it is not expected to.
It does not loop with g++ 4.3 or
--- Comment #1 from sylvain dot pion at sophia dot inria dot fr 2007-03-19
16:27 ---
I will happily create the attachements when bugzilla will work...
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31268
--- Comment #5 from aph at gcc dot gnu dot org 2007-03-19 16:30 ---
Created an attachment (id=13234)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13234action=view)
.class file
Compile this with gcc/trunk/install/bin/gcj MathLib.class -c -O2
--
aph at gcc dot gnu dot org
--- Comment #2 from rguenth at gcc dot gnu dot org 2007-03-19 16:32 ---
Just wild guessing - try -fwrapv.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31268
--- Comment #28 from ghazi at gcc dot gnu dot org 2007-03-19 16:41 ---
(In reply to comment #27)
I did a non-bootstrap build and test on hppa1.1-hp-hpux11.11 over the weekend
(C only) and I got two failures that I don't normally see,
builtin-pow-mpfr-1.c
and builtin-sin-mpfr-1.c.
--- Comment #3 from pinskia at gcc dot gnu dot org 2007-03-19 16:45 ---
(In reply to comment #2)
Just wild guessing - try -fwrapv.
Well it already does not look for -fno-strict-aliasing so I am assuming an
aliasing bug in your code until you provide the sources.
--
pinskia at gcc
--- Comment #2 from rguenth at gcc dot gnu dot org 2007-03-19 16:47 ---
On x86 different addressing modes and induction variables are used. Good:
.L2:
movq%r12, 8(%rsp)
addl$1, %ebp
movsd 8(%rsp), %xmm0
callSquare
movsd %xmm0,
--- Comment #4 from sylvain dot pion at sophia dot inria dot fr 2007-03-19
16:50 ---
(sorry I still can't create attachments)
-ftrapw makes the program work (no loop).
Let me copy-paste here the non-preprocessed source files which show everything
which is executed, while waiting for
--- Comment #5 from sylvain dot pion at sophia dot inria dot fr 2007-03-19
16:55 ---
Subject: Re: Non-deterministic bug producing a run-time infinite
loop
Let me try to attach the pre-processed file through an email
attachement.
--
--- Comment #5 from kristerw at gcc dot gnu dot org 2007-03-19 17:08
---
Subject: Bug 30058
Author: kristerw
Date: Mon Mar 19 17:08:14 2007
New Revision: 123065
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=123065
Log:
2007-03-18 Krister Walfridsson [EMAIL PROTECTED]
program toto
implicit none
real:: a(10)
integer :: i
a(:) = 1.
do i=1,100
if( i = 10 .and. a(i) 0. ) write(*,*) i,a(i)
enddo
end
Compiling this program with -fbounds-check will give an out-of-bound error
because the bound checking happens before the evaluation of the expression.
As
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-03-19 17:24 ---
As mentioned before, this is not really a bug as the fortran says .and. is not
short circuiting.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from tobi at gcc dot gnu dot org 2007-03-19 17:37 ---
I'm not going to dig through the standard again to dig out the precise wording,
but as long as one doesn't actually access the out-of-bound array element the
program is valid. Furthermore, the standard allows
--
tobi at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Last
On 19 Mar 2007 12:43:49 -, dominiq at lps dot ens dot fr
[EMAIL PROTECTED] wrote:
Since sin() and cos() are non trivial functions, I am very surprised
that a wrong API makes a 50% difference.
Well Here is how it can make a 50% difference (at least on the Cell,
the 970 has less of a
--- Comment #6 from pinskia at gmail dot com 2007-03-19 17:52 ---
Subject: Re: pseudo-optimzation with sincos/cexpi
On 19 Mar 2007 12:43:49 -, dominiq at lps dot ens dot fr
[EMAIL PROTECTED] wrote:
Since sin() and cos() are non trivial functions, I am very surprised
that a
--- Comment #6 from fang at csl dot cornell dot edu 2007-03-19 18:51
---
Subject: Re: std::valarray should be annotated with
OpenMP directives
bangerth at dealii dot org [EMAIL PROTECTED] writes:
| (In reply to comment #3)
| I suspect that parallelizing for SSE/Altivec might be
--- Comment #6 from sylvain dot pion at sophia dot inria dot fr 2007-03-19
19:37 ---
Created an attachment (id=13235)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13235action=view)
pre-processed source file
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31268
--- Comment #7 from law at redhat dot com 2007-03-19 19:52 ---
Fixed with today's patch to tree-cfg.c.
--
law at redhat dot com changed:
What|Removed |Added
--- Comment #8 from law at gcc dot gnu dot org 2007-03-19 19:52 ---
Subject: Bug 30984
Author: law
Date: Mon Mar 19 19:52:19 2007
New Revision: 123067
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=123067
Log:
* tree-cfg.c (find_taken_edge): Tighten conditions for
Mo DeJong wrote:
long val2 = 1; /* incorrect warn when val2 is a long */
int c2 = (
((long long) val2)
((long long)(-2147483647L - 1))
);
The result of the compare will always be false, so the warning is correct.
The long variable val2 can not hold a value
--- Comment #9 from law at gcc dot gnu dot org 2007-03-19 20:03 ---
Subject: Bug 30984
Author: law
Date: Mon Mar 19 20:03:07 2007
New Revision: 123068
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=123068
Log:
2007-03-19 Jeff Law [EMAIL PROTECTED]
* tree-cfg.c
--- Comment #10 from law at redhat dot com 2007-03-19 20:04 ---
Fix committed to mainline, gcc-4.1 and gcc-4.2 branches
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30984
--- Comment #11 from law at gcc dot gnu dot org 2007-03-19 20:04 ---
Subject: Bug 30984
Author: law
Date: Mon Mar 19 20:04:04 2007
New Revision: 123069
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=123069
Log:
2007-03-19 Jeff Law [EMAIL PROTECTED]
* tree-cfg.c
Eric Lemings wrote:
Is this a bug or new behavior? If the latter, what is this attributed
to?
FYI gcc-bugs isn't the best place to ask questions, as it is mostly used
for output from our bug database.
I'm not a C++ expert, so I'm not the right person to say for sure, but
this looks like
--- Comment #2 from wilson at gcc dot gnu dot org 2007-03-19 21:32 ---
In theory, obstack.h is imported from the FSF gnulib package, though
unfortunately that isn't documented in our codingconventions.html web page, and
it looks like people have just been modifying it in place. The
--- Comment #3 from vivekrao4 at yahoo dot com 2007-03-19 21:55 ---
I agree with comments #1 and #2 that minimal width and fixed width
list-directed I/O can be useful, and I don't think gfortran should change its
default list-directed output, because some people may be relying, unwisely
For the code
program xcheck
implicit none
integer :: i,ivec(2)
ivec = 0
do i=1,3
if (i**2 10) print*,ivec(i)
end do
end program xcheck
gfortran -Wall -fbounds-check
for mingw 4.3.0 20070315
gives at run time
Fortran runtime error: Array reference out of bounds for array 'ivec', upper
The following shows a missing easy optimization for GCC:
int
in_canforward(unsigned int in)
{
if ((in ~0xff0f) == 0xf0 || (in ~0xff0f) == 0xe0)
return 0;
return 1;
}
results in (@ -O2):
in_canforward:
andl$240, %edi
cmpl$240,
--- Comment #11 from pinskia at gcc dot gnu dot org 2007-03-19 22:31
---
(In reply to comment #10)
I fully agree.
I am not agreeing fully, This warning is only because we can prove something
is pure/const/cannot throw and that only comes because of simple optimization.
What about
--- Comment #29 from sje at cup dot hp dot com 2007-03-19 22:41 ---
In reply to comment #28: I suspected as much but it is interesting that I have
a new gmp/mpfr. If I build bootstrap the resulting compiler passes these
tests. If I build non-bootstrap the resulting compiler does not
.L13:
cmpl %r1,$127
jeql .L14
xorb2 $1,%r0
movzbl %r0,%r0
ret
.L14:
movb $1,%r0
xorb2 $1,%r0
movzbl %r0,%r0
ret
.size in_canforward, .-in_canforward
.ident GCC: (GNU) 4.3.0 20070319 (experimental)
Notice
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-03-19 22:44 ---
This is most likely super block formation happening way too late to be able to
optimize these calls.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
pinskia at gcc dot gnu dot org [EMAIL PROTECTED] writes:
| (In reply to comment #10)
|
| I fully agree.
|
| I am not agreeing fully,
Well, you've got a problem.
[...]
| What about this case:
There is a distinction betwen user code and compiler-generated codes.
Warning about
--- Comment #12 from gdr at cs dot tamu dot edu 2007-03-19 22:45 ---
Subject: Re: Strange -Wunreachable-code warning with _GLIBCXX_DEBUG
pinskia at gcc dot gnu dot org [EMAIL PROTECTED] writes:
| (In reply to comment #10)
|
| I fully agree.
|
| I am not agreeing fully,
Well,
--- Comment #20 from anlauf at gmx dot de 2007-03-19 22:59 ---
(In reply to comment #19)
Jerry,
I tried FX's snapshot from today (20070319) and the example
above works. A somewhat more twisted example which I have
not yet been able to reduce leads to an IOSTAT value of 5001
(BTW
The following code compiles fine in GCC 4.1.
enum E { e };
struct S {
E v:5;
};
S s;
int main() { if (!s.v) return 0; }
In 4.2 (20070307), it gives the following error:
test.cpp: In function 'int main()':
test02.cpp:6: error:
-elf
Configured with: /mnt/Sources/GCC/gcc_4/configure --prefix=/opt/arm
--target=arm-elf --enable-interwork --enable-multilib --enable-languages=c
Thread model: single
gcc version 4.1.3 20070319 (prerelease)
$ gcc-4.1.2 -v
Using built-in specs.
Target: x86_64-unknown-linux-gnu
Configured with: /mnt
--- Comment #13 from manu at gcc dot gnu dot org 2007-03-19 23:13 ---
Andrew, as you say, -Wunreachable-code is not enabled by -Wall. The user has to
give it explicitly. And in your testcases the code is not reachable. So in that
case, it could be argued whether the warning is warranted
--- Comment #14 from pinskia at gcc dot gnu dot org 2007-03-19 23:18
---
But the user can see the code, it is what is produced by what the C++ standard
says is produced, now you could say the user has no control over fixing it, it
is also true with the template case. Both cases are
--- Comment #1 from TabonyEE at austin dot rr dot com 2007-03-19 23:19
---
GCC 4.1.2 returns 0.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31136
--- Comment #7 from jakub at gcc dot gnu dot org 2007-03-19 23:24 ---
Subject: Bug 30505
Author: jakub
Date: Mon Mar 19 23:24:43 2007
New Revision: 123072
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=123072
Log:
PR inline-asm/30505
* reload1.c (reload): Do
--- Comment #12 from jakub at gcc dot gnu dot org 2007-03-19 23:26 ---
Subject: Bug 30762
Author: jakub
Date: Mon Mar 19 23:26:14 2007
New Revision: 123073
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=123073
Log:
PR c/30762
* c-typeck.c (convert_for_assignment):
1 - 100 of 122 matches
Mail list logo
