--- 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 once
--- 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=gcc&view=rev&rev=123051
Log:
PR fortran/31203
* trans-expr.c (gfc_tr
--
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=13229&action=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
--- 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 dot
--- 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
template struct S1 {
template struct S2;
template class T3> struct S3 {
template > struct S4 {};
struct S5 : S4<> {
> g++ bug.ii
bug-segv.ii:5: internal compiler error: Segmentation fault
--
Summary: ICE: segmentation fault on invalid code
--- 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:
template struct S1 {
template struct S2;
template class T3> struct S3 {
template > struct S4 {};
struct S5 : S4<> {
};
};
};
-
N
--- 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
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 i
--- 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 :/
--
http://gcc.gnu.org/bugzilla/show_b
--- 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 double
--- 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:
Sec
--- 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
| MacS
--- 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 positi
--- 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=gcc&view=rev&rev=123060
Log:
2007-03-19 Andrew Pinski <[EMAIL PROTECTED]>
Rich
--- 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
Status|ASSIGNE
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 sh
--- 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
--- 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 bo
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
Target
--- 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=13230&action=view)
javolution.jar (BSD license)
source & distribution from http://www.javolution.org/
--
http://gcc.gnu.org/bu
--- 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=13231&action=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
--- 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 tes
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
PROGR
--- 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=13232&action=view)
Failing routine
A stripped-down test case that demonstrates the failure.
--
http://gcc.gnu.org/bugzilla/show_b
--- 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=13233&action=view)
.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31264
This wrong code (missing typename):
template
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#::D' is not a type
instead of "'C::D' is not a type".
--
Summary: #
--- 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 are
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 older
--- 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=13234&action=view)
.class file
Compile this with gcc/trunk/install/bin/gcj MathLib.class -c -O2
--
aph at gcc dot gnu dot org chan
--- 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, (%r
--- 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 b
--- 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.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=312
--- 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=gcc&view=rev&rev=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 short-cir
--
tobi at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Last reconfirme
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 restr
--- 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
--- 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=13235&action=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
S
--- 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=gcc&view=rev&rev=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 sma
--- 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=gcc&view=rev&rev=123068
Log:
2007-03-19 Jeff Law <[EMAIL PROTECTED]>
* tree-cfg.c (find
--- 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=gcc&view=rev&rev=123069
Log:
2007-03-19 Jeff Law <[EMAIL PROTECTED]>
* tree-cfg.c (fin
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 an
--- 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 pare
--- 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
boun
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, %e
--- 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 abou
--- 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 p
ret
.L12:
movl $1,%r0
ret
.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 &quo
--- 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 compiler-
--- 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
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: coul
Using built-in specs.
Target: arm-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-unkno
--- 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 har
--- 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=gcc&view=rev&rev=123072
Log:
PR inline-asm/30505
* reload1.c (reload): Do inva
--- 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=gcc&view=rev&rev=123073
Log:
PR c/30762
* c-typeck.c (convert_for_assignment)
--- Comment #8 from jakub at gcc dot gnu dot org 2007-03-19 23:27 ---
Subject: Bug 30505
Author: jakub
Date: Mon Mar 19 23:27:34 2007
New Revision: 123074
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=123074
Log:
PR inline-asm/30505
* reload1.c (reload): Do inva
1 - 100 of 123 matches
Mail list logo
