[Bug bootstrap/31224] some installation scripts and Makefiles do not run on stock Solaris
--- 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 again may have missed something). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31224
[Bug fortran/31203] Character length should never be negative
--- 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_trans_init_string_length): Length should never be negative. (gfc_conv_function_call): Likewise. * gfortran.dg/string_length_1.f90: New test. Added: trunk/gcc/testsuite/gfortran.dg/string_length_1.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/trans-expr.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31203
[Bug fortran/31203] [4.1/4.2 only] Character length should never be negative
-- 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 Summary|Character length should |[4.1/4.2 only] Character |never be negative |length should never be ||negative Target Milestone|--- |4.2.1 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31203
[Bug fortran/30834] ICE with kind=8 exponentiaton
-- 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 |org Status|NEW |ASSIGNED Last reconfirmed|2007-02-17 18:36:03 |2007-03-19 08:29:47 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30834
[Bug fortran/31119] -fbounds-check: Check for presence of optional arguments before bound checking
--- 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 that we still issue errors when the optional parameter is present and has the wrong size; the code below will error out as expected if one of the commented lines is uncommented: module sub_mod contains elemental subroutine set_optional(i,idef,iopt) ! set i to (iopt,idef) if iopt (is,is not) PRESENT integer, intent(out) :: i integer, intent(in) :: idef integer, intent(in), optional :: iopt if (present(iopt)) then i = iopt else i = idef end if end subroutine set_optional subroutine sub(ivec) integer , intent(in), optional :: ivec(:) integer :: ivec_(2) call set_optional(ivec_,(/1,2/)) print*,"ivec_=",ivec_ call set_optional(ivec_,(/1,2/),ivec) print*,"ivec_=",ivec_ end subroutine sub end module sub_mod program main use sub_mod, only: sub call sub() call sub((/4,5/)) ! call sub((/4/)) ! call sub((/4,5,6/)) end program main Anyway, the other calls to checking routines need to be audited for similar problems with optional args. That probably includes making a testcase for each situation, and see if optional arg can be used in each context. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31119
[Bug fortran/30923] Respecifying USE associated NAMELIST should raise warning by default
--- 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 org changed: What|Removed |Added Status|WAITING |RESOLVED Resolution||WONTFIX http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30923
[Bug bootstrap/25672] [4.1/4.2 regression] cross build's libgcc picks up CFLAGS
--- 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 Known to fail||4.1.2 4.2.0 Known to work||4.0.2 Summary|cross build's libgcc picks |[4.1/4.2 regression] cross |up CFLAGS |build's libgcc picks up ||CFLAGS http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25672
[Bug driver/31089] gccspec.c doesn't handle -x options
--- 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 gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2007-03-19 09:14:51 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31089
[Bug tree-optimization/24333] missed div optimizations
--- 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
[Bug c++/31260] New: ICE: segmentation fault on invalid code
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
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: wouter dot vermaelen at pi dot be
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31260
[Bug other/29559] '-O1 -ftree-vrp -fwrapv' misscompiles stable gnupg-1.4.5.
--- 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 Status|UNCONFIRMED |RESOLVED Resolution||WONTFIX http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29559
[Bug c++/31260] [4.1/4.2/4.3 Regression] ICE: segmentation fault with template code
--- 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<> {
};
};
};
-
Note if I change how S5 is declared using a specific template argument instead
of <>, the crash goes away in that the follow compiles just fine:
template struct S1 {
template struct S2;
template class T3> struct S3 {
template > struct S4 {};
struct S5 : S4 > {
};
};
};
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Keywords||ice-on-invalid-code, ice-on-
||valid-code
Last reconfirmed|-00-00 00:00:00 |2007-03-19 09:26:55
date||
Summary|ICE: segmentation fault on |[4.1/4.2/4.3 Regression]
|invalid code|ICE: segmentation fault with
||template code
Target Milestone|--- |4.1.3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31260
[Bug middle-end/31249] pseudo-optimzation with sincos/cexpi
--- 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
[Bug libstdc++/30915] [4.3 regression] bootstrap fails while building libstdc++-v3 on x86_64-pc-linux-gnu
--- 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 > > multilib > > like this > > > > jama gcc # cat /usr/include/stdio.h > > Ok, thanks. But then, an important question is: which (empty? not including > any > declaration of the expected facilities?!? What header is that?) stdio.h is > instead included at build time if you don't specify explicitely the path? You > should try to figure out that, whether on your system there are around (in the > build directory or elsewhere) stdio.h which in fact are not the correct one. > > In order to do that, you could proceed as follows: go the build directory of > the library and invoke by hand the same line which is failing the build of > compatibility.cc, but running only the preprocessor, with -E. You save its > output, it should tell us what a heck of wrong stdio.h is included. > Incidentally, I have (by using a binary search, bootstapping into an empty build directory each time) found that revision 121025 builds OK, while revision 121027 fails with this problem. Doing the suggestion above, this is what I get: [EMAIL PROTECTED] $ /MHz/roger/src/gcc-svn-121027/build-121027/./gcc/xgcc -sh ared-libgcc -B/MHz/roger/src/gcc-svn-121027/build-121027/./gcc -nostdinc++ -L/MHz/roger/src/gcc-svn-121027/build-121027/x86_64-unknown-linux-gnu/libstdc++-v3/src -L/MHz/roger/src/gcc-svn-121027/build-121027/x86_64-unknown-linux-gnu/libstdc++-v3/src/.libs -B/usr/local/gcc-svn/x86_64-unknown-linux-gnu/bin/ -B/usr/local/gcc-svn/x86_64-unknown-linux-gnu/lib/ -isystem /usr/local/gcc-svn/x86_64-unknown-linux-gnu/include -isystem /usr/local/gcc-svn/x86_64-unknown-linux-gnu/sys-include -I/MHz/roger/src/gcc-svn-121027/build-121027/x86_64-unknown-linux-gnu/libstdc++-v3/include/x86_64-unknown-linux-gnu -I/MHz/roger/src/gcc-svn-121027/build-121027/x86_64-unknown-linux-gnu/libstdc++-v3/include -I/MHz/roger/src/gcc-svn-121027/trunk/libstdc++-v3/libsupc++ -fno-implicit-templates -Wall -Wextra -Wwrite-strings -Wcast-qual -fdiagnostics-show-location=once -ffunction-sections -fdata-sections -g -O2 -D_GNU_SOURCE -c ../../../../trunk/libstdc++-v3/src/compatibility.cc -fPIC -DPIC -o .libs/compatibility.o -E -v Reading specs from /MHz/roger/src/gcc-svn-121027/build-121027/./gcc/specs Target: x86_64-unknown-linux-gnu Configured with: ../trunk/configure --prefix=/usr/local/gcc-svn --enable-languages=c,c++ --disable-multilib Thread model: posix gcc version 4.3.0 20070121 (experimental) /MHz/roger/src/gcc-svn-121027/build-121027/./gcc/cc1plus -E -quiet -nostdinc++ -v -I/MHz/roger/src/gcc-svn-121027/build-121027/x86_64-unknown-linux-gnu/libstdc++-v3/include/x86_64-unknown-linux-gnu -I/MHz/roger/src/gcc-svn-121027/build-121027/x86_64-unknown-linux-gnu/libstdc++-v3/include -I/MHz/roger/src/gcc-svn-121027/trunk/libstdc++-v3/libsupc++ -iprefix /MHz/roger/src/gcc-svn-121027/build-121027/gcc/../lib/gcc/x86_64-unknown-linux-gnu/4.3.0/ -isystem /MHz/roger/src/gcc-svn-121027/build-121027/./gcc/include -D_GNU_SOURCE -D_GNU_SOURCE -DPIC -isystem /usr/local/gcc-svn/x86_64-unknown-linux-gnu/include -isystem /usr/local/gcc-svn/x86_64-unknown-linux-gnu/sys-include ../../../../trunk/libstdc++-v3/src/compatibility.cc -o .libs/compatibility.o -mtune=generic -Wall -Wextra -Wwrite-strings -Wcast-qual -fno-implicit-templates -fdiagnostics-show-location=once -ffunction-sections -fdata-sections -fPIC -fworking-directory -O2 ignoring nonexistent directory "/usr/local/gcc-svn/x86_64-unknown-linux-gnu/include" ignoring nonexistent directory "/usr/local/gcc-svn/x86_64-unknown-linux-gnu/sys-include" ignoring nonexistent directory "/MHz/roger/src/gcc-svn-121027/build-121027/gcc/../lib/gcc/x86_64-unknown-linux-gnu/4.3.0/include" ignoring nonexistent directory "/MHz/roger/src/gcc-svn-121027/build-121027/gcc/../lib/gcc/x86_64-unknown-linux-gnu/4.3.0/../../../../x86_64-unknown-linux-gnu/include" ignoring nonexistent directory "/MHz/roger/src/gcc-svn-121027/build-121027/gcc/../lib/gcc//include" ignoring nonexistent directory "/MHz/roger/src/gcc-svn-121027/build-121027/gcc/../lib/gcc//lib/gcc/x86_64-unknown-linux-gnu/4.3.0/include" ignoring nonexistent directory "/MHz/roger/src/gcc-svn-121027/build-121027/gcc/../lib/gcc//lib/gcc/x86_64-unknown-linux-gnu/4.3.0/../../../../x86_64-unknown-linux-gnu/include" #include "..." search starts here: #include <...> search starts here: /MHz/roger/src/gcc-svn-121027/build-121027/x86_64-unknown-linux-gnu/libstdc++-v3/include/x86_64-unknown-linux-gnu /MHz/roger/src/gcc-svn-121027/build-121027/x86_64-unknown-linux-gnu/libstdc++-v3/include /MHz/roger/src/gcc-svn-121027/trunk/libstdc++-v3/libsupc++ /MHz/roger/src/gcc-svn-121027/build-121027/./gcc/include /usr/local/include /usr/include End of search list. So, searching in order the directories
IEEE Math is not working on Alpha Rawhide
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 if IEEE math works with the -ieee switch... no checking if IEEE math works with the -qfloat=nofold switch... no checking if IEEE math works with the -w -qflttrap=enable:zerodivide... no checking if IEEE math works with the -mieee switch... not isnan(NaN) ... no checking if IEEE math works with the -q float=rndsngl switch... no checking if IEEE math works with the -OPT:IEEE_NaN_inf=ON switch... no checking if IEEE math works with the -OPT:IEEE_comparisons=ON switch... no checking if IEEE math works with fpsetmask(0)... no checking if IEEE math works with signal(SIGFPE,SIG_IGN)... no configure: error: Your Compiler does not do propper IEEE math ... Please find out how to make IEEE math work with your compiler and let me know (tobi at oetiker.ch ). Check config.log to see what went wrong ... How can I make gcc support IEEE- math on my system? It seems to be a bug, because on Kernel 2.4 I was able to compile the tool. Thanks SteffenP.
[Bug tree-optimization/31169] Bootstrap comparison error at revision 122821
--- 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_bug.cgi?id=31169
[Bug tree-optimization/31254] [4.3 Regression] verify_ssa failed: type mismatch between an SSA_NAME and its symbol
--- 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 AssignedTo|unassigned at gcc dot gnu |rguenth at gcc dot gnu dot |dot org |org Status|NEW |ASSIGNED Last reconfirmed|2007-03-18 12:47:35 |2007-03-19 10:36:25 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31254
[Bug middle-end/31249] pseudo-optimzation with sincos/cexpi
--- 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 x)
{
double cos = cos (imag(x));
double sin = sin (imag(x));
double e = 1;
if (real(x) != 0)
e = exp (real(x));
...
possibly computing cos and sin in an efficient way (using sincos). So
cexp () should be never slower than calling sin () and cos (). If the ABI
were not stupid of course ;)
Does darwin have a sincos() library function?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31249
[Bug middle-end/30864] [4.3 Regression] ice for legal code with -O2
--- 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 f() {
int x, y;
while (x) {
x = x ? x : y;
}
}
void g() {
S s;
s.f();
}
void h() {
S s;
f();
g();
}
> g++ -O -finline-functions bug.ii
bug.ii: In function 'void h()':
bug.ii:16: internal compiler error: in alloc_aux_for_block, at cfg.c:665
--
wouter dot vermaelen at pi dot be changed:
What|Removed |Added
CC||wouter dot vermaelen at pi
||dot be
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30864
[Bug tree-optimization/31261] New: Missed tree optimizations: (8 - (x & 7)) & 7
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 - (x & cstmask)) & cstmask2 as
(cst & cstmask2) + (-x & cstmask2) if x is unsigned or if -INT_MIN wraps to
INT_MIN, both cstmask and cstmask2 are constants z^2-1 for some z and
(cstmask & cstmask2) == cstmask2.
BTW, even for
(8 + (x & 7)) & 7
the optimized dump contains:
(x & 7) + 8 & 7
for both 4.2/4.3 (no idea why 8 & 7 hasn't been simplified as 0).
--
Summary: Missed tree optimizations: (8 - (x & 7)) & 7
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: jakub at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31261
[Bug tree-optimization/31169] Bootstrap comparison error at revision 122821
--- 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
[Bug fortran/31199] write with "t1" format gives wrong output
--- 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: Section 9.2.3.3 of the Fortran 2003 standard: "For a formatted stream output statement, ... the terminal point of the file is set to the highest-numbered position to which data was transferred by the statement." (Thanks to Ian Hounam/NAG for pointing out.) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31199
[Bug tree-optimization/31261] Missed tree optimizations: (8 - (x & 7)) & 7
--- 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
[Bug tree-optimization/31261] Missed tree optimizations: (8 - (x & 7)) & 7
--- 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 Severity|normal |enhancement Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Keywords||missed-optimization, TREE Last reconfirmed|-00-00 00:00:00 |2007-03-19 11:19:48 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31261
[Bug libstdc++/31000] std::valarray should be annotated with OpenMP directives
--- 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
[Bug libstdc++/30571] Use of C++0x keywords in libstdc++-v3 headers
--- 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|RESOLVED Resolution||FIXED Target Milestone|--- |4.3.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30571
[Bug fortran/31199] write with "t1" format gives wrong output
--- 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
[Bug fortran/31199] write with "t1" format gives wrong output
--- 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
[Bug fortran/31262] New: -fno-range-check can trigger ICE
$ 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 in range for its type, and that we never create a type larger than 2*HWI, which is the largest that the middle-end can handle. */ It's wrong. Now that we have -fno-range-check, we should handle this in some way, probably by a modulo operation. -- Summary: -fno-range-check can trigger ICE Product: gcc Version: 4.3.0 Status: UNCONFIRMED Keywords: ice-on-invalid-code Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: fxcoudert at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31262
[Bug fortran/31262] -fno-range-check can trigger ICE
--- 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 Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2007-03-19 12:24:48 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31262
[Bug fortran/31262] -fno-range-check can trigger ICE
-- 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 |org Status|NEW |ASSIGNED Last reconfirmed|2007-03-19 12:24:48 |2007-03-19 12:24:57 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31262
[Bug libstdc++/31000] std::valarray should be annotated with OpenMP directives
--- 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. I suspect that parallelizing for SSE/Altivec might be more peneficial in most cases than for OpenMP -- OpenMP is a 1,000 pounds gorilla. -- Gaby -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31000
[Bug middle-end/31249] pseudo-optimzation with sincos/cexpi
--- 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, then TARGET_C99_FUNCTIONS depends on darwin_macosx_version_min which seems presently default to 10.1. So TARGET_C99_FUNCTIONS seems to be set to 0 at least for a G5 under OSX 10.3 and a G4 under 10.4. > Does darwin have a sincos() library function? I don't know. If there is no answer in this PR, I can ask the question on [EMAIL PROTECTED] >From the behavior reported in PR30969, PR30980, and PR31161, it seems that the optimization is off for gcc, but on for g++ and gfortran, though I cannot figure out why. > If the ABI were not stupid of course ;) Since sin() and cos() are non trivial functions, I am very surprised that a wrong API makes a 50% difference. If the API is so time consuming, why not inline sin() and cos()? In addition a decent optimizer should be able to eliminate redundant part of the codes, making the use of a sincos() function not necessary, or am I too naive? What is the best way to collect data on the different platform to evaluate how this optimization is really working? I have only access to OSX and Intel or AMD64 under Linux. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31249
[Bug fortran/31199] write with "t1" + nonadvancing transfer format gives wrong output
--- 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 position for the nonadvancing transfer of "X", t1, "ABC" is after the "ABC". - After doing the advancing transfer "DEF" it is at the highest-numbered position to which data was transferred by the statement, namely after "ABCDEFXXX" + new_line. Thus, NAG f95/Sun/HP seems to be wrong; ifort, g95, xlf and portland seem to be right and gfortran gets it differently wrong. -- burnus at gcc dot gnu dot org changed: What|Removed |Added Summary|write with "t1" format gives|write with "t1" + |wrong output|nonadvancing transfer format ||gives wrong output http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31199
[Bug middle-end/30864] [4.3 Regression] ice for legal code with -O2
--- 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
[Bug tree-optimization/31254] [4.3 Regression] verify_ssa failed: type mismatch between an SSA_NAME and its symbol
--- 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]> Richard Guenther <[EMAIL PROTECTED]> PR tree-optimization/31254 * tree-ssa-forwprop.c (forward_propagate_addr_expr_1): Use handled_component_p () where appropriate. Continue propagating into the rhs if we propagated into an INDIRECT_REF on the lhs. * gcc.dg/torture/pr31254.c: New testcase. Added: trunk/gcc/testsuite/gcc.dg/torture/pr31254.c Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/tree-ssa-forwprop.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31254
[Bug tree-optimization/31254] [4.3 Regression] verify_ssa failed: type mismatch between an SSA_NAME and its symbol
--- 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|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31254
[Bug c/31263] New: Misoptimization of constant function expressions
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 should be so. I tested it with gcc 4.1.1
and 4.1.2. The timings are more or less equal.
> gcc -O2 f_demo.c f_demo2.c -o f_demo
> time f_demo
real0m1.537s
user0m1.183s
sys 0m0.345s
> gcc -D VARIABLE_PAR -O2 f_demo.c f_demo2.c -o f_demo
> time f_demo
real0m0.700s
user0m0.368s
sys 0m0.329s
--- f_demo.c ---
#include
double Square(double x);
#ifdef VARIABLE_PAR
#define PAR i*2-i-i+1000
#else
#define PAR 1000
#endif
int main()
{
const int iSize=5000;
int i;
double *pdA=malloc(iSize*sizeof(double));
for(i=0;ihttp://gcc.gnu.org/bugzilla/show_bug.cgi?id=31263
[Bug c++/31246] Strange -Wunreachable-code warning with _GLIBCXX_DEBUG
--- 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 because of > what the C++ standard says should happen and not really an artafact of what > the > GCC is doing really. When I first say this bug I was going to say this should > not warned about, but when I looked into it a little more, I was thinking the > warning is correct except for the fact, there is no way of working around the > issue. > > I think we need to decide what -Wunreachable-code actually means, does it mean > if there is a way to "fix" the code, then warn about unreachable code or does > it mean to warn about code which is even hard to work around like in templates > and constructors? > And I think that we should not warn about generated code. No matter if it is generated by optimisers or front-ends. If it is not user code, then there should be no warning. In that sense, this is similar to PR31227. -- manu at gcc dot gnu dot org changed: What|Removed |Added CC||manu at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31246
[Bug libstdc++/31000] std::valarray should be annotated with OpenMP directives
--- 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 both: SSE/Altivec/... if the template argument of std::valarray is float/double/int (in which case one would have to have explicit specializations of the member functions), and OpenMP if it is anything else. W. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31000
[Bug java/31264] New: internal compiler error: in build_int_cst_wide, at tree.c:886
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: i686-apple-darwin8 Configured with: /datal/gcc/gcc/configure --build=i686-apple-darwin8 --target=i686-apple-darwin8 --disable-shared --enable-static --disable-multilib --disable-checking --disable-gconf-peer --disable-plugin --prefix=/datal/gcc/i686-apple-darwin --enable-languages=c,java,objc --with-gmp=/opt/local --with-mpfr=/opt/local Thread model: posix gcc version 4.3.0 20070311 (experimental) /datal/gcc/i686-apple-darwin8/bin/../libexec/gcc/i686-apple-darwin8/4.3.0/jc1 javolution.jar -fhash-synchronization -fuse-divide-subroutine -fcheck-references -fuse-boehm-gc -fkeep-inline-functions -fPIC -mmacosx-version-min=10.4 -quiet -dumpbase javolution.jar -mtune=generic -march=nocona -auxbase javolution -O2 -version -fbootclasspath=./:/datal/gcc/i686-apple-darwin8/bin/../lib/gcc/../../share/java/libgcj-4.3.0.jar -faux-classpath javolution.zip -o javolution.s GNU Java version 4.3.0 20070311 (experimental) (i686-apple-darwin8) compiled by GNU C version 4.3.0 20070311 (experimental). GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072 Class path starts here: javolution.zip/ (zip) ./ (system) /datal/gcc/i686-apple-darwin8/bin/../lib/gcc/../../share/java/libgcj-4.3.0.jar/ (system) (zip) javolution/lang/MathLib.java: In class 'javolution.lang.MathLib': javolution/lang/MathLib.java: In method 'javolution.lang.MathLib.toLongPow2(double,int)': javolution/lang/MathLib.java:0: internal compiler error: in build_int_cst_wide, at tree.c:886 Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html> for instructions. -- Summary: internal compiler error: in build_int_cst_wide, at tree.c:886 Product: gcc Version: 4.3.0 Status: UNCONFIRMED Severity: major Priority: P3 Component: java AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: membar at gcc dot gnu dot org GCC build triplet: i686-apple-darwin8 GCC host triplet: i686-apple-darwin8 GCC target triplet: i686-apple-darwin8 and powerpc-apple-darwin8 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31264
[Bug java/31264] internal compiler error: in build_int_cst_wide, at tree.c:886
--- 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/bugzilla/show_bug.cgi?id=31264
[Bug java/31264] internal compiler error: in build_int_cst_wide, at tree.c:886
--- 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
[Bug inline-asm/30505] [4.2/4.3 regression] asm operand has impossible constraints.
-- 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 | Status|NEW |ASSIGNED Last reconfirmed|2007-03-05 09:18:03 |2007-03-19 14:59:12 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30505
[Bug java/31264] internal compiler error: in build_int_cst_wide, at tree.c:886
-- 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 | Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2007-03-19 15:00:26 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31264
[Bug c++/31246] Strange -Wunreachable-code warning with _GLIBCXX_DEBUG
--- 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 optimisers or front-ends. If it is not user code, then there | should be no warning. I fully agree. -- Gaby -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31246
[Bug libstdc++/31000] std::valarray should be annotated with OpenMP directives
--- 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 peneficial | > in most cases than for OpenMP -- OpenMP is a 1,000 pounds gorilla. | | I certainly agree. The beauty is that one may have both: SSE/Altivec/... if | the template argument of std::valarray is float/double/int (in which case one | would have to have explicit specializations of the member functions), and | OpenMP if it is anything else. on my single node AMD64 machine, I would prefer the compiler to generate codes that takes advantage of SSE than launch OpenMP. On the other hand, if I had multiple nodes, I might be contemplating OpenMP for some of the valarrays, so I'm not sure the issue is that simply cut... -- Gaby -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31000
[Bug inline-asm/30505] [4.2/4.3 regression] asm operand has impossible constraints.
--- 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 URL||http://gcc.gnu.org/ml/gcc- ||patches/2007- ||03/msg01254.html Keywords||rejects-valid http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30505
[Bug rtl-optimization/21299] [4.0/4.1 Regression] internal error on invalid asm statement
--- 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
[Bug fortran/31265] New: Error with RESHAPE on REAL initialization
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 test.f90 PROGRAM test IMPLICIT NONE INTEGER, DIMENSION(3,3), PARAMETER :: & Aij=RESHAPE((/ 1,3,3, & 3,2,2, & 3,2,2 /), (/3,3/)) REAL, DIMENSION(3,3), PARAMETER :: & Bij=RESHAPE((/ 1.0D0,3.0D0,3.0D0, & 3.0D0,2.0D0,2.0D0, & 3.0D0,2.0D0,2.0D0 /), (/3,3/)) END PROGRAM test $gfortran -std=f95 -c test.f90 test.f90:9.8: Bij=RESHAPE((/ 1.0D0,3.0D0,3.0D0, & 1 Error: Extension: Evaluation of nonstandard initialization expression at (1) -- Summary: Error with RESHAPE on REAL initialization Product: gcc Version: 4.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: jellby at yahoo dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31265
[Bug fortran/31266] New: Spurious(?) warning about character truncation
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 PROGRAM test IMPLICIT NONE TYPE custom CHARACTER(LEN=10) :: nom END TYPE custom CHARACTER (LEN=10) :: a CHARACTER (LEN=2) :: b TYPE(custom) :: c a='1234567890' b=a(1:2) c%nom=a b=c%nom(1:2) END PROGRAM test $gfortran -Wall -c test.f90 test1.f90:13.14: b=c%nom(1:2) 1 Warning: rhs of CHARACTER assignment at (1) will be truncated (10/2) -- Summary: Spurious(?) warning about character truncation Product: gcc Version: 4.3.0 Status: UNCONFIRMED Severity: minor Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: jellby at yahoo dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31266
[Bug middle-end/31263] Misoptimization of constant function expressions
--- 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 Component|c |middle-end http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31263
[Bug java/31264] internal compiler error: in build_int_cst_wide, at tree.c:886
--- 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_bug.cgi?id=31264
[Bug java/31264] internal compiler error: in build_int_cst_wide, at tree.c:886
--- 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
[Bug c++/31267] New: #'typename_type' not supported by dump_decl#
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: #'typename_type' not supported by dump_decl#
Product: gcc
Version: 4.1.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: guillaume dot melquiond at ens-lyon dot fr
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31267
[Bug tree-optimization/31169] Bootstrap comparison error at revision 122821
--- 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 related to this defect but I will investigate some more. The pow test is failing some tree dump scans and sin is failing with link_error() undefined. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31169
[Bug c++/31268] New: Non-deterministic bug producing a run-time infinite loop
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 versions than 4.2. It also does not loop when adding -fno-strict-aliasing with g++ 4.2, or when compiling with -O only. Even more strange : it does not loop when I remove some unused bits of the program (which is why I had a hard time shrinking it down), for example unused typedefs (look for "limb2"). The relevant part of the program is a small class (MP_Float) containing an std::vector, and some code around it, namely the operator_minus() function which is called, and which loops. I attach the pre-processed file, as well as the main small file so that you can see what is the relevant part of it, and decide if it is a compiler bug or an issue with my program. My program does some type conversions, which may be the source of the problem (triggering undefined behavior ?), but they seem fine to me. -- Summary: Non-deterministic bug producing a run-time infinite loop Product: gcc Version: 4.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: sylvain dot pion at sophia dot inria dot fr GCC host triplet: i686-pc-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31268
[Bug c++/31268] Non-deterministic bug producing a run-time infinite loop
--- 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
[Bug java/31264] internal compiler error: in build_int_cst_wide, at tree.c:886
--- 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 changed: What|Removed |Added Attachment #13230|0 |1 is obsolete|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31264
[Bug c++/31268] Non-deterministic bug producing a run-time infinite loop
--- 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
[Bug tree-optimization/31169] Bootstrap comparison error at revision 122821
--- 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. I am not certain these failures are related to this > defect but I will investigate some more. The pow test is failing some tree > dump scans and sin is failing with link_error() undefined. Those testcases should only fail if your MPFR is too old (i.e. something less than version 2.2.1). So I don't think they are related to this defect either. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31169
[Bug c++/31268] Non-deterministic bug producing a run-time infinite loop
--- 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 dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |WAITING http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31268
[Bug middle-end/31263] Misoptimization of constant function expressions
--- 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, (%rbx) addq$8, %rbx cmpl$5000, %ebp jne .L2 bad: .L2: movq%r12, 8(%rsp) movsd 8(%rsp), %xmm0 callSquare movsd %xmm0, (%rbp,%rbx,8) addq$1, %rbx cmpq$5000, %rbx jne .L2 this is because we retain the complex expression until the last DOM run after loop optimization (for 4.1.2 at least). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31263
[Bug c++/31268] Non-deterministic bug producing a run-time infinite loop
--- 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 bugzilla to allow me to add the large
pre-processed file.
-
#ifndef CGAL_MP_FLOAT_H
#define CGAL_MP_FLOAT_H
#include
typedef short limb; // unused
typedef intlimb2; // unused
struct MP_Float
{
typedef std::vector V;
typedef V::iteratoriterator; // unused
V v;
int exp; // unused
MP_Float(short i)
: v(1)
{
v[0] = i;
canonicalize();
}
void remove_leading_zeros()
{
while ((!v.empty()) && (v.back() == 0))
v.pop_back();
}
void remove_trailing_zeros()
{
if (v.empty() || (v.front() != 0))
return;
V::iterator i = v.begin();
for (++i; *i == 0; ++i) ;
//v.erase(v.begin(), i);
}
void canonicalize()
{
remove_leading_zeros();
remove_trailing_zeros();
}
// replacing int by std::size_t appears to also fix the loop...
int max_exp() const
{
return v.size();
}
short of_exp(int i) const
{
if (i >= max_exp()) return 0;
return v[i];
}
};
// This union is used to convert an unsigned short to a short with
// the same binary representation, without invoking implementation-defined
// behavior (standard 4.7.3).
union to_signed {
unsigned short us;
short s;
};
inline
void split(int l, short & high, short & low)
{
to_signed l2 = {l};
low = l2.s;
high = (l - low) >> 16;
}
MP_Float
operator_minus(const MP_Float &a, const MP_Float & b /* unused */)
{
int max_exp = std::max(a.max_exp(), b.max_exp());
MP_Float r(0);
r.v.resize(2);
for(int i = 0; i < max_exp ; ++i)
{
int tmp = r.v[i] + (a.of_exp(i) - b.of_exp(i));
split(tmp, r.v[i+1], r.v[i]);
}
r.canonicalize();
return r;
}
#endif // CGAL_MP_FLOAT_H
// #include
#include // this one pulls up unrelated stuff
but necessary for the bug to show up
int main()
{
MP_Float a=2, b=1;
MP_Float d= operator_minus(a, a);
}
-
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31268
[Bug c++/31268] Non-deterministic bug producing a run-time infinite loop
--- 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=31268
[Bug target/30058] [4.3 regression] bootstrap broken on i386-unknown-netbsdelf2.0.2
--- 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]> PR target/30058 * inclhack.def (netbsd_c99_inline_1): New. * fixincl.x: Regenerate. * tests/base/signal.h: New. Added: trunk/fixincludes/tests/base/signal.h Modified: trunk/fixincludes/ChangeLog trunk/fixincludes/fixincl.x trunk/fixincludes/inclhack.def -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30058
[Bug fortran/31269] New: short-circuit in -fbounds-check
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 short-circuit (i.e. not evaluating the second part of the expression when its result is determined by the first part) is used by gfortran, it would be nice to use it also for bound checking (at least as an option). -- Summary: short-circuit in -fbounds-check Product: gcc Version: 4.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: mimo2 at free dot fr http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31269
[Bug fortran/31269] short-circuit in -fbounds-check
--- 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 Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31269
[Bug fortran/31269] short-circuit in -fbounds-check
--- 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-circuiting logic. Finally, bounds checking is not defined by the standard. I agree with the submitter that this behavior is at least surprising, and could be enhanced upon. -- tobi at gcc dot gnu dot org changed: What|Removed |Added Severity|normal |enhancement Status|RESOLVED|UNCONFIRMED Resolution|INVALID | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31269
[Bug fortran/31269] short-circuit in -fbounds-check
-- tobi at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2007-03-19 17:40:07 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31269
Re: [Bug middle-end/31249] 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 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 restriction and only the dispatch group is rejected). Modern PowerPC processors like not to store stuff to the stack and then load it again with in a number of cycles (cell is around 50 cycles while the 970 is just within a dispatch group). Transfering between the integer register set and the floating point register set can only be done via memory so you will get a LHS or a LRU reject (depending on what processor you are on). This can either cause a 50 cycle delay or reject of the dispatch group (the later can cause multiple rejects). The number of cycles used up by this issue can add up with both sides of the function having this hazard. Thanks, Andrew Pinski
[Bug middle-end/31249] pseudo-optimzation with sincos/cexpi
--- 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 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 restriction and only the dispatch group is rejected). Modern PowerPC processors like not to store stuff to the stack and then load it again with in a number of cycles (cell is around 50 cycles while the 970 is just within a dispatch group). Transfering between the integer register set and the floating point register set can only be done via memory so you will get a LHS or a LRU reject (depending on what processor you are on). This can either cause a 50 cycle delay or reject of the dispatch group (the later can cause multiple rejects). The number of cycles used up by this issue can add up with both sides of the function having this hazard. Thanks, Andrew Pinski -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31249
[Bug libstdc++/31000] std::valarray should be annotated with OpenMP directives
--- 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 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 both: SSE/Altivec/... if > | the template argument of std::valarray is float/double/int (in which case > one > | would have to have explicit specializations of the member functions), and > | OpenMP if it is anything else. > > on my single node AMD64 machine, I would prefer the compiler to > generate codes that takes advantage of SSE than launch OpenMP. On > the other hand, if I had multiple nodes, I might be contemplating > OpenMP for some of the valarrays, so I'm not sure the issue is > that simply cut... Thinking out loud... Is there any interest/effort in placing vectorizable operations somewhere outside of valarray so that other STL algorithms/containers might be able to be able to leverage them? For example, I'd like to be able to use tr1/array on basic numeric types and have the benefits of valarray operations without having to first copy to a valarray, which uses heap-allocated memory. I'm imagining something like vectorize_traits that would check for the operation's vectorizability (std::plus) with the vectorizability of the value_type (_Integral). Then a subset of algorithms ( among others) would have additional level of template-wrapping to dispatch the appropriate __algorithm() based on vectorize_traits and iterator_traits. One issue however might be assumptions about the aliasing of input/output iterators... we're aware that many optimizations rely on non-aliasing assumptions, whereas the standard algorithms make no such assumptions (except valarray's ops). A run-time overlap check on random_access_iterators would incur a slight penalty. But yes, having STL take advantage of low-level acceleration through abstraction and compile-time polymorphism is a good thing, IMHO. Fang -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31000
[Bug c++/31268] Non-deterministic bug producing a run-time infinite loop
--- 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
[Bug tree-optimization/30984] [4.1/4.2/4.3 Regression] ICE with computed goto and constants
--- 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 Status|NEW |RESOLVED Component|middle-end |tree-optimization Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30984
[Bug tree-optimization/30984] [4.1/4.2/4.3 Regression] ICE with computed goto and constants
--- 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 optimizing computed gotos. * PR tree-optimization/30984 * gcc.c-torture/pr30984.c: New test. Added: trunk/gcc/testsuite/gcc.c-torture/compile/pr30984.c Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/tree-cfg.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30984
Re: gcc bug WRT warning that should not be displayed
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 smaller than LONG_MIN. Adding casts to long long does not change this fact. -- Jim Wilson, GNU Tools Support, http://www.specifix.com
[Bug tree-optimization/30984] [4.1/4.2/4.3 Regression] ICE with computed goto and constants
--- 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_taken_edge): Tighten conditions for optimizing computed gotos. 2007-03-19 Jeff Law <[EMAIL PROTECTED]> * PR tree-optimization/30984 * gcc.c-torture/pr30984.c: New test. Added: branches/gcc-4_1-branch/gcc/testsuite/gcc.c-torture/compile/pr30984.c Modified: branches/gcc-4_1-branch/gcc/ChangeLog branches/gcc-4_1-branch/gcc/testsuite/ChangeLog branches/gcc-4_1-branch/gcc/tree-cfg.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30984
[Bug tree-optimization/30984] [4.1/4.2/4.3 Regression] ICE with computed goto and constants
--- 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
[Bug tree-optimization/30984] [4.1/4.2/4.3 Regression] ICE with computed goto and constants
--- 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 (find_taken_edge): Tighten conditions for optimizing computed gotos. 2007-03-19 Jeff Law <[EMAIL PROTECTED]> * PR tree-optimization/30984 * gcc.c-torture/pr30984.c: New test. Added: branches/gcc-4_2-branch/gcc/testsuite/gcc.c-torture/compile/pr30984.c Modified: branches/gcc-4_2-branch/gcc/ChangeLog branches/gcc-4_2-branch/gcc/testsuite/ChangeLog branches/gcc-4_2-branch/gcc/tree-cfg.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30984
Re: Bitfield conversion bug in 4.2?
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 accidental bug to me. There were patches added to change the bitfield type representation, the is_bitfield_expr_with_lowered_type change, which is for PR 26534. I believe these patches have an error. It looks to me like the bug is in standard_conversion in cp/calls.c at these lines if (bitfield_type) from = strip_top_quals (bitfield_type); This sets from, but fails to set fcode, resulting in an inconsistency. In this case, fcode is INTEGER_TYPE and from is now an enumeral type after originally being an integer type. This causes a failure further down in the tcode == BOOLEAN_TYPE code where we fail to match the conditions due to this inconsistency. I'd suggest opening a bug report. -- Jim Wilson, GNU Tools Support, http://www.specifix.com
[Bug c/31233] obstack.h typo
--- 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 parent package is here http://savannah.gnu.org/projects/gnulib#options Looking at the cvs history, it looks like this was broken in revision 1.24 and fixed in revision 1.32, so we should be able to import a fixed version of this file to fix this bug report. Except that we will have to deal with local changes somehow. They really should be pushed to the FSF is they aren't already there. -- wilson at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2007-03-19 21:32:30 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31233
[Bug fortran/31190] minimum field width list-directed output
--- 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 on a particular format. But an OPTION for minimal width list-directed output could be useful. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31190
[Bug fortran/31270] New: print subscript value and array bounds when out-of-bounds error occurs
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 bound of dimension 1 exceeded (in file 'xbounds_check.f90', at line 6) 0 0 This is good, but g95 is a little more informative, identifyng the value of the out-of-bound subscript and the relevant dimension of the array, saying 0 0 At line 6 of file xbounds_check.f90 (Unit 6) Traceback: not available, compile with -ftrace=frame or -ftrace=full Fortran runtime error: Array element out of bounds: 3 in (1:2), dim=1 Vivek Rao -- Summary: print subscript value and array bounds when out-of- bounds error occurs Product: gcc Version: 4.3.0 Status: UNCONFIRMED Severity: enhancement Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: vivekrao4 at yahoo dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31270
[Bug rtl-optimization/31271] New: Missing simple optimization
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, %edi
sete%al
cmpl$224, %edi
sete%dl
orl %edx, %eax
xorl$1, %eax
movzbl %al, %eax
ret
given that 0xf0 and 0xe0 only differ by one bit, there is no reason to test for
that bit so the comparision could be: (in & 0xff1f) == 0xe0. More
generally
the optimization is:
given (x & m) == a0 || (x & m) == a1
where m, a0, and a1 are all constant
let b = (a0 ^ a1)
then if (b & (b - 1)) == 0 [b is a power of 2]
rewrite to: (x & (m|b)) == (a0 & ~b)
--
Summary: Missing simple optimization
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
Severity: enhancement
Priority: P3
Component: rtl-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: matt at 3am-software dot com
GCC build triplet: x86_64--netbsd
GCC host triplet: x86_64--netbsd
GCC target triplet: x86_64--netbsd
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31271
[Bug c++/31246] Strange -Wunreachable-code warning with _GLIBCXX_DEBUG
--- 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 this case:
int f(int a) { return a;}
int g(int b)
{
try
{
return f(b);
}catch (...) { return 0; }
}
Should we warn about the catch being unreachable?
This is the same issue as -Wuninitialized warning in that we warn about a lot
of cases where we should not. I think this is why this option is not turned on
via either -W or -Wall, it is hard sometimes to work around.
Take even more extrem example where templates come into play:
int f(int a) { return a;}
int f(float a);
template
int g(a b)
{
try
{
return f(a);
}catch (...) { return 0; }
}
int d = g(10);
Should we warn that the catch case is unreachable, I think so as it is obvious
but how do we avoid it, well you can specialize the template but that could get
messy.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31246
[Bug tree-optimization/31169] Bootstrap comparison error at revision 122821
--- 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 pass these tests. I guess that is because the compiler I am starting with wasn't built with the new gmp/mpfr. But this has nothing to do with this bug report. I have two non-bootstrap compilers now (with and without the patch), I will try expanding my testing to include C++ and Fortran and see if that finds a test difference. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31169
[Bug tree-optimization/31272] New: gcc is being too clever
[This problem occurs in 4.1.2 and 4.1.3 as well]
Given the following source:
int
in_canforward(unsigned int in)
{
unsigned int net;
if ((in & ~0xff0f) == 0xf0 || (in & ~0xff0f) == 0xe0)
return 0;
if ((in & 0x80) == 0) {
net = in & 0xff;
if (net == 0 || net == 0x7f)
return 0;
}
return 1;
"cc1 -O2 -quiet" emit:
#NO_APP
.file "inc.c"
.text
.align 1
.globl in_canforward
.type in_canforward, @function
in_canforward:
.word 0x0
subl2 $4,%sp
movl 4(%ap),%r1
bicl3 $-241,%r1,%r0
cmpl %r0,$240
jeql .L2
cmpl %r0,$224
jeql .L2
bicb3 $127,%r1,%r0
jneq .L12
bicl2 $-256,%r1
jneq .L13
.L2:
clrl %r0
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 "GCC: (GNU) 4.3.0 20070319 (experimental)"
Notice the code at .L14? Why go through all extra that effort? Why not just
do clrl %r0 and ret or preferrably branch to .L2 which already does that? The
same argument goes for the xorb2/movzbl right before .L14. movl $1,%r0 and
ret or preferably branch to .L12 which already does that.
Now if you move .L13 before .L12 (so it can all fall through) and take the
mentioned branches, the almost-optimal version becomes:
in_canforward:
.word 0x0
subl2 $4,%sp
movl 4(%ap),%r1
bicl3 $-241,%r1,%r0
cmpl %r0,$240
jeql .L2
cmpl %r0,$224
jeql .L2
bicb3 $127,%r1,%r0
jneq .L12
bicl2 $-256,%r1
jneq .L13
.L2:
clrl %r0
ret
.L13:
cmpl %r1,$127
jeql .L2
.L12:
movl $1,%r0
ret
--
Summary: gcc is being too clever
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: matt at 3am-software dot com
GCC build triplet: x86_64--netbsd
GCC host triplet: x86_64--netbsd
GCC target triplet: vax--netbsdelf
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31272
[Bug rtl-optimization/31272] gcc is being too clever
--- 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 Severity|normal |enhancement Component|tree-optimization |rtl-optimization http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31272
Re: [Bug c++/31246] 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, you've got a problem. [...] | What about this case: There is a distinction betwen user code and compiler-generated codes. Warning about compiler-generated codes is pointless. -- Gaby
[Bug c++/31246] Strange -Wunreachable-code warning with _GLIBCXX_DEBUG
--- 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, you've got a problem. [...] | What about this case: There is a distinction betwen user code and compiler-generated codes. Warning about compiler-generated codes is pointless. -- Gaby -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31246
[Bug libfortran/31052] Bad IOSTAT values when readings NAMELISTs past EOF
--- 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: what does that value mean?) in the namelist read, although the subroutine position_nml succeeds. The file libgfortran is not in that distribution. Could you please put here these IOSTAT values? Nor are these in the .info files. Thanks! -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31052
[Bug c/31273] New: Erroneous bitfield conversions to boolean values
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: could not convert 's.S::v' to 'bool'
test02.cpp:6: error: in arguument to unary !
Jim Wilson has suggested this is a bug due to recent patches to the 4.2 branch.
--
Summary: Erroneous bitfield conversions to boolean values
Product: gcc
Version: 4.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: eric dot lemings at roguewave dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31273
[Bug tree-optimization/31274] New: gcc 4.1 side effect missed
While compiling code below with -O1 second call to ubasic_get_variable() gets
optimized out and code works incorrectly as ubasic_set_variable() can modify
variables[].
Code runs as expected when compiled with 4.0.2 or with 4.1.1, 4.1.2 (and 4.1
branch) with "-O1 -fno-tree-dominator-opts -fno-tree-fre" switches. Haven't
checked 4.2.
Happes both on x86-64 and arm-elf.
$ arm-elf-gcc -O1 -S test.c
===CUT
int ubasic_get_variable(int varnum);
void ubasic_set_variable(int varum, int value);
struct for_state {
short line_after_for;
short for_variable;
int to;
};
#define MAX_FOR_STACK_DEPTH 4
static struct for_state for_stack[MAX_FOR_STACK_DEPTH];
static int for_stack_ptr;
#define MAX_VARNUM 26
int variables[MAX_VARNUM];
void
next_statement(int var)
{
ubasic_set_variable(var, ubasic_get_variable(var) + 1);
if(ubasic_get_variable(var) <= for_stack[for_stack_ptr - 1].to) {
jump_line(0);
}
}
int ubasic_get_variable(int varnum)
{
return variables[varnum];
}
/* // "fixes" problem also
void xxx(int a, int b)
{
for_stack[a].to = b;
}
*/
===CUT
$ arm-elf-gcc -v
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-unknown-linux-gnu
Configured with: /mnt/Sources/GCC/gcc_4_1_2_release/configure
--prefix=/usr/local --libexecdir=/usr/local/lib64 --program-suffix=-4.1.2
--enable-shared --enable-threads=posix --enable-__cxa_atexit
--enable-clocale=gnu --disable-multilib
--enable-languages=c,c++,objc,fortran,java,obj-c++
Thread model: posix
gcc version 4.1.2
Thanks.
--
Summary: gcc 4.1 side effect missed
Product: gcc
Version: 4.1.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: vitalyb at telenet dot dn dot ua
GCC host triplet: x86_64-unknown-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31274
[Bug c++/31246] Strange -Wunreachable-code warning with _GLIBCXX_DEBUG
--- 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 or not. So, yes, you got a point. But... that is not what this PR is about. This PR is that the user cannot see the code we are warning about. Even if it were code with an easy workaround unlike your testcases, that doesn't matter at all, we should not emit the warning. -- manu at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2007-03-19 23:13:32 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31246
[Bug c++/31246] Strange -Wunreachable-code warning with _GLIBCXX_DEBUG
--- 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 hard to fix without much
thought. There is also something like:
static inline int f(int a)
{
if (a)
return g();
return 0;
}
int h(void)
{
return f(0);
}
With -Wunreachable-code -O1, we warn that we cannot reach the line containing
return g(); Now should we, it is the same case, how can an user fix that code
if the static inline function comes in from a header, they cannot.
-Wunreachable-code warning is useless except if you want to see if you do
coverage.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution||WONTFIX
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31246
[Bug tree-optimization/31136] FRE ignores bit-field truncation
--- 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
[Bug inline-asm/30505] [4.2/4.3 regression] asm operand has impossible constraints.
--- 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 invalid ASM checking after cleanup_subreg_operands. * gcc.target/i386/pr30505.c: New test. Added: trunk/gcc/testsuite/gcc.target/i386/pr30505.c Modified: trunk/gcc/ChangeLog trunk/gcc/reload1.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30505
[Bug c/30762] [4.2/4.3 Regression] IMA messes up with inlining
--- 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): Call comptypes for RECORD_TYPE or UNION_TYPE. * gcc.dg/pr30762-1.c: New test. * gcc.dg/pr30762-2.c: New test. Added: trunk/gcc/testsuite/gcc.dg/pr30762-1.c trunk/gcc/testsuite/gcc.dg/pr30762-2.c Modified: trunk/gcc/ChangeLog trunk/gcc/c-typeck.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30762
[Bug inline-asm/30505] [4.2/4.3 regression] asm operand has impossible constraints.
--- 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 invalid ASM checking after cleanup_subreg_operands. * gcc.target/i386/pr30505.c: New test. Added: branches/gcc-4_2-branch/gcc/testsuite/gcc.target/i386/pr30505.c Modified: branches/gcc-4_2-branch/gcc/ChangeLog branches/gcc-4_2-branch/gcc/reload1.c branches/gcc-4_2-branch/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30505
