[Bug c/29626] New: Code generation bug for aliased long long with -mpentium-m
The following C program gives incorrect results with vanilla gcc 4.1.1 (default
./configure options except --prefix, compiled on Fedora Core 5) and specific
compile options.
#include
char buf[8] = {1,1,1,1,1,1,1,1};
char zero=0;
int main() {
int i;
*(long long*)buf = 0;
*(short*)buf ^= (zero) ^ (zero<<1);
for (i=0; i<8; i++) printf("%x,", buf[i]);
return 0;
}
The buffer should contain all zeros after the two assignments, but it doesn't:
$ ~/gcc-4.1.1/bin/gcc -W -Wall -Wno-long-long -pedantic \
-march=pentium-m -O2 -o gcc-bug gcc-bug.c
$ ./gcc-bug
1,1,0,0,0,0,0,0,
Looks like some sort of aliasing issue for long longs; I don't see it happening
with ints. Twiddling compile options and further code simplification tends to
make the problem disappear.
The above is a (painfully) reduced version of useful code which exhibited the
problem, so it's actually something you can bump into.
--
Summary: Code generation bug for aliased long long with -
mpentium-m
Product: gcc
Version: 4.1.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: gcc2eran at tromer dot org
GCC build triplet: 4.1.1
GCC target triplet: i686-pc-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29626
[Bug c/29626] Code generation bug for aliased long long with -mpentium-m
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-10-28 07:57 --- You are violating C aliasing rules. You are accessing a character array via something other than a character type which is undefined. The opposite way would have been defined in that accessing an long long array (or a short array) via a character type. *** This bug has been marked as a duplicate of 21920 *** -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29626
[Bug c/21920] alias violating
--- Comment #107 from pinskia at gcc dot gnu dot org 2006-10-28 07:57 --- *** Bug 29626 has been marked as a duplicate of this bug. *** -- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||gcc2eran at tromer dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21920
[Bug middle-end/29335] transcendental functions with constant arguments should be resolved at compile-time
--- Comment #18 from vincent at vinc17 dot org 2006-10-28 09:07 --- (In reply to comment #17) > Yes, I can reproduce the NaN. In fact, any negative value > gives a NaN. Not any negative value, but in lngamma.c: /* if x < 0 and -2k-1 <= x <= -2k, then lngamma(x) = NaN */ probably because the gamma value is negative. This is because MPFR defines lngamma as log(gamma(x)) while the C standard defines it as log|gamma(x)|. I wonder if this should be regarded as a bug or if a new function (say, mpfr_lgamma) should be defined in MPFR (in which case, not before 2.3.0). Do other standards (other languages) define such a function, either as log(gamma(x)) or as log|gamma(x)|? Also, warning! The mpfr_erfc is incomplete for x >= 4096: There is an infinite loop in the 2.2 branch. This problem is now detected in the trunk, and until this is completely fixed, a NaN is returned with the MPFR erange flag set. This should be in the 2.2 branch in a few days (and a preversion of MPFR 2.2.1 will come several days after that). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29335
[Bug target/29377] Build for h8300-elf crashes on 64bit hosts due to int/HWI mismatch
--- Comment #2 from uros at gcc dot gnu dot org 2006-10-28 09:41 --- Subject: Bug 29377 Author: uros Date: Sat Oct 28 09:41:41 2006 New Revision: 118102 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=118102 Log: PR target/29377 * config/h8300/h8300.c (h8300_emit_stack_adjustment): Change "size" argument to HOST_WIDE_INT. Update function prototype. (round_frame_size): Change return type to HOST_WIDE_INT. Change "size" argument to HOST_WIDE_INT. Update function prototype. Modified: trunk/gcc/ChangeLog trunk/gcc/config/h8300/h8300.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29377
[Bug target/29377] Build for h8300-elf crashes on 64bit hosts due to int/HWI mismatch
--- Comment #3 from uros at kss-loka dot si 2006-10-28 09:43 --- Fixed on 4.3 mainline -- uros at kss-loka dot si changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |uros at kss-loka dot si |dot org | Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Known to fail||4.2.0 Known to work||4.3.0 Last reconfirmed|-00-00 00:00:00 |2006-10-28 09:43:15 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29377
[Bug target/29377] Build for h8300-elf crashes on 64bit hosts due to int/HWI mismatch
--- Comment #4 from uros at gcc dot gnu dot org 2006-10-28 10:03 --- Subject: Bug 29377 Author: uros Date: Sat Oct 28 10:03:37 2006 New Revision: 118103 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=118103 Log: PR target/29377 * config/h8300/h8300.c (h8300_emit_stack_adjustment): Change "size" argument to HOST_WIDE_INT. Update function prototype. (round_frame_size): Change return type to HOST_WIDE_INT. Change "size" argument to HOST_WIDE_INT. Update function prototype. Modified: branches/gcc-4_1-branch/gcc/ChangeLog branches/gcc-4_1-branch/gcc/config/h8300/h8300.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29377
[Bug target/29377] Build for h8300-elf crashes on 64bit hosts due to int/HWI mismatch
--- Comment #5 from uros at kss-loka dot si 2006-10-28 10:04 --- Fixed for 4.1.2. -- uros at kss-loka dot si changed: What|Removed |Added Known to work|4.3.0 |4.1.2 4.3.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29377
[Bug c++/29618] argument dependent lookup: what about built-in types?
--- Comment #6 from v dot vasaitis at sms dot ed dot ac dot uk 2006-10-28 11:08 --- OK thanks, it's quite clear now. My apologies for acting inappropriately. Regards, Vasilis -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29618
[Bug target/28806] lround is not expanded inline to SSE conversion sequence
--- Comment #2 from rguenth at gcc dot gnu dot org 2006-10-28 11:31 --- Subject: Bug 28806 Author: rguenth Date: Sat Oct 28 11:30:41 2006 New Revision: 118105 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=118105 Log: 2006-10-28 Richard Guenther <[EMAIL PROTECTED]> PR target/28806 * builtins.c (expand_builtin_int_roundingfn_2): Expand BUILT_IN_LROUND and BUILT_IN_LLROUND from here. (expand_builtin): Adjust likewise. * genopinit.c (optabs[]): Add lround optab. * optabs.c (init_optabs): Initialize lround_optab. * optabs.h (enum convert_optab_index): Add COI_lround. (lround_optab): Define. * config/i386/i386-protos.h (ix86_expand_lround): Declare. * config/i386/i386.c (ix86_sse_copysign_to_positive): New static function. (ix86_expand_lround): New function. * config/i386/i386.md (lrounddi2, lroundsi2): New expanders. * doc/md.texi (lroundMN2): Document. * gcc.target/i386/math-torture/lround.c: New testcase. Added: trunk/gcc/testsuite/gcc.target/i386/math-torture/lround.c Modified: trunk/gcc/ChangeLog trunk/gcc/builtins.c trunk/gcc/config/i386/i386-protos.h trunk/gcc/config/i386/i386.c trunk/gcc/config/i386/i386.md trunk/gcc/doc/md.texi trunk/gcc/genopinit.c trunk/gcc/optabs.c trunk/gcc/optabs.h trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28806
[Bug middle-end/28970] [4.1 Regression] Wrong code for simple loop test case
--- Comment #6 from rguenth at gcc dot gnu dot org 2006-10-28 11:06 --- Ah, no - I didn't look at the result of this first hunt and though it was the switch from -floop-optimize to -floop-optimize2. Sorry for the noise. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28970
[Bug middle-end/29335] transcendental functions with constant arguments should be resolved at compile-time
--- Comment #19 from ghazi at gcc dot gnu dot org 2006-10-28 13:28 --- (In reply to comment #18) > (In reply to comment #17) > > Yes, I can reproduce the NaN. In fact, any negative value > > gives a NaN. > Not any negative value, but in lngamma.c: > /* if x < 0 and -2k-1 <= x <= -2k, then lngamma(x) = NaN */ > probably because the gamma value is negative. This is because MPFR defines > lngamma as log(gamma(x)) while the C standard defines it as log|gamma(x)|. I > wonder if this should be regarded as a bug or if a new function (say, > mpfr_lgamma) should be defined in MPFR (in which case, not before 2.3.0). The documenation in MPFR says: -- Function: int mpfr_lngamma (mpfr_t ROP, mpfr_t OP, mp_rnd_t RND) Set ROP to the value of the Gamma function on OP, and its logarithm respectively, rounded in the direction RND. When OP is a negative integer, NaN is returned. It only talked about negative integers, and I glossed over the fact that it left out the absolute value that C does. So it was pilot error, but I think a clarification would help. Many times in the docs MPFR takes pains to follow the C99 standard, e.g. the inputs to atan2 or pow. Where you deviate from it should also be noted. Or you could consider it a bug and fix it. :-) Anyway, I think I can hand wrap mpfr_log(mpfr_abs(mpfr_gamma)) myself right? > Also, warning! The mpfr_erfc is incomplete for x >= 4096: There is an infinite > loop in the 2.2 branch. This problem is now detected in the trunk, and until > this is completely fixed, a NaN is returned with the MPFR erange flag set. > This > should be in the 2.2 branch in a few days (and a preversion of MPFR 2.2.1 will > come several days after that). If it returns NaN for now that's fine since GCC avoids any transformation that returns NaN or Inf. Glad to hear a new version is coming out. If you make a prerelease tarball available somewhere I'd like to try it with mainline GCC. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29335
[Bug fortran/29625] Octal edit descriptors allow real variables, even with -std=f95
--- Comment #1 from tobias dot burnus at physik dot fu-berlin dot de 2006-10-28 13:34 --- Probably the same for binary and hexadecimal? io/transfer.c(formatted_transfer_scalar): "case FMT_O:" seems to be a good place for adding notify_std (&dtp->common, GFC_STD_GNU,...) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29625
[Bug fortran/29267] different length non-constant strings in array constructors ICE
--- Comment #14 from tobias dot burnus at physik dot fu-berlin dot de 2006-10-28 13:09 --- > Do g95 and ifort also compile the original testcase and do The Right Thing? No. g95 has a run-time error, ifort garbage at the beginning (but no crash); f95 and sunf95 don't compile. gfortran: ICE for "x", for "x": compiles, but garbage (extra 1.000) at run time, for "x"//31characters: ok like all the other compilers > g95 ice29267.f90 > ./a.out Fortran runtime error: Inconsistent string size in array constructor > ifort ice4.f90 > ./a.out # with print *, a: xw~D#�*'@x$� 1.000 NAGf95: Array constructor values have differing CHARACTER lengths (1 and 32) sunf95: Line = 3, Column = 23: ERROR: Array constructor values of type character must all have the same length. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29267
[Bug middle-end/29335] transcendental functions with constant arguments should be resolved at compile-time
--- Comment #20 from vincent at vinc17 dot org 2006-10-28 14:05 --- (In reply to comment #19) > The documenation in MPFR says: > -- Function: int mpfr_lngamma (mpfr_t ROP, mpfr_t OP, mp_rnd_t RND) > Set ROP to the value of the Gamma function on OP, and its > logarithm respectively, rounded in the direction RND. When OP is > a negative integer, NaN is returned. > > It only talked about negative integers, AFAIK, this was mainly for Gamma(negative integer). But this is also true for lngamma(negative integer). But the point is that if gamma(x) is negative, then lngamma(x) is NaN since the logarithm of a negative value is NaN. But that's why the C standard defines lgamma as log|gamma(x)| instead of log(gamma(x)). > and I glossed over the fact that it > left out the absolute value that C does. So it was pilot error, but I think a > clarification would help. Many times in the docs MPFR takes pains to follow > the C99 standard, e.g. the inputs to atan2 or pow. Where you deviate from it > should also be noted. I agree. And I think that none of the MPFR developers were aware of this problem (I didn't notice the difference when I was looking for C functions that were missing in MPFR). I posted a mail about that on the MPFR mailing-list. > Or you could consider it a bug and fix it. :-) I think this is the best solution, in particular because this would change only NaN values. > Anyway, I think I can hand wrap mpfr_log(mpfr_abs(mpfr_gamma)) myself right? Probably not a good idea, because I think that mpfr_gamma may overflow, though the final result may be in the double-precision range. > Glad to hear a new version is coming out. If you make a prerelease tarball > available somewhere I'd like to try it with mainline GCC. OK, I hope I won't forget to announce it in the gcc dev mailing-list. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29335
[Bug libgomp/26165] Cannot find libgomp.spec after 'make install' on x86_64 and ppc64
--- Comment #9 from franke dot daniel at gmail dot com 2006-10-28 14:27 --- I ran into this on a x86_64 running some flavour of debian. Since I can not alter the system setup, I have to compile svn sources with multilib disabled (otherwise the build process stops due to various errors). There wasn't any problem up until recently when I tried to compile an OMP enabled fortran program: $> gfortran-4.2-svn -fopenmp foo.f gfortran-4.2-svn: libgomp.spec: No such file or directory $> cat foo.f PROGRAM main END PROGRAM $> gfortran-4.2-svn Using built-in specs. Target: x86_64-linux Configured with: ../../svn/gcc-4.2-branch/configure --prefix=$(localpath)/gcc-4.2-svn --with-gmp=$(localpath)/gmp-4.2.1 --with-mpfr=$(localpath)/mpfr-2.2.0 --enable-bootstrap --enable-threads=posix --enable-shared --with-system-zlib --program-suffix=-4.2-svn --disable-multilib x86_64-linux --disable-nls --enable-languages=c,c++,fortran Thread model: posix gcc version 4.2.0 20061026 (prerelease) Any suggestions how to work around this problem? Setting up my own toolchain is, due to quota, not an option. -- franke dot daniel at gmail dot com changed: What|Removed |Added CC||franke dot daniel at gmail ||dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26165
[Bug middle-end/29335] transcendental functions with constant arguments should be resolved at compile-time
--- Comment #21 from ghazi at gcc dot gnu dot org 2006-10-28 16:03 --- (In reply to comment #20) > I agree. And I think that none of the MPFR developers were aware of this > problem (I didn't notice the difference when I was looking for C functions > that were missing in MPFR). Since you mentioned C functions missing in MPFR, what are your plans for the Bessel functions? I'd like to hook up builtins j0/j1/jn/y0/y1/yn. Thanks. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29335
[Bug middle-end/29335] transcendental functions with constant arguments should be resolved at compile-time
--- Comment #22 from vincent at vinc17 dot org 2006-10-28 16:58 --- (In reply to comment #21) > Since you mentioned C functions missing in MPFR, what are your plans for the > Bessel functions? I'd like to hook up builtins j0/j1/jn/y0/y1/yn. Thanks. They're in the TODO, but there are no plans yet to implement them. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29335
[Bug fortran/28484] system_clock with real-type count_rate does not compile
--- Comment #3 from patchapp at dberlin dot org 2006-10-28 16:39 --- Subject: Bug number PR28484 A patch for this bug has been added to the patch tracker. The mailing list url for the patch is http://gcc.gnu.org/ml/gcc-patches/2006-10/msg01387.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28484
[Bug c++/29054] [4.0/4.1 Regression] ICE on friend template specialization
--- Comment #3 from Thomas8675309 at yahoo dot com 2006-10-28 17:57 --- If one clicks on the list of "All regressions" for GCC 4.1.1 from the main page, http://gcc.gnu.org, this bug doesn't come up. Any idea why? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29054
[Bug middle-end/26899] Fold does not fold (i0 > i1 + 1) || (i1 < i0 - 1)
--- Comment #2 from rguenth at gcc dot gnu dot org 2006-10-28 18:03 --- Subject: Bug 26899 Author: rguenth Date: Sat Oct 28 18:03:21 2006 New Revision: 118106 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=118106 Log: 2006-10-28 Richard Guenther <[EMAIL PROTECTED]> PR middle-end/26899 * fold-const.c (maybe_canonicalize_comparison_1): Helper for maybe_canonicalize_comparison. (maybe_canonicalize_comparison): New function for canonicalizing comparison trees. (fold_comparison): Call it to canonicalize comparisons with constants involved. * gcc.dg/tree-ssa/pr26899.c: New testcase. Added: trunk/gcc/testsuite/gcc.dg/tree-ssa/pr26899.c Modified: trunk/gcc/ChangeLog trunk/gcc/fold-const.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26899
[Bug middle-end/26899] Fold does not fold (i0 > i1 + 1) || (i1 < i0 - 1)
--- Comment #3 from rguenth at gcc dot gnu dot org 2006-10-28 18:04 --- Fixed what is possible to fix. -- 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=26899
[Bug c++/29054] [4.0/4.1 Regression] ICE on friend template specialization
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|--- |4.1.2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29054
[Bug libfortran/29627] New: partial unformatted reads shouldn't succeed
$ cat partial.f90 program main character(len=1) a(2) open(10, form="unformatted",status="unknown") write (10) 'a' rewind 10 a = 'b' read (10) a print *,a end program main $ gfortran -v Using built-in specs. Target: i686-pc-linux-gnu Configured with: ../../gcc/trunk/configure --prefix=/home/ig25 --enable-languages=c,fortran Thread model: posix gcc version 4.2.0 20061020 (experimental) This should generate a runtime error. ifort gets this right: $ ifort partial.f90 $ ./a.out forrtl: severe (67): input statement requires too much data, unit 10, file /home/ig25/Krempel/Transfer/fort.10 Image PCRoutineLineSource a.out 08085958 Unknown Unknown Unknown a.out 08085450 Unknown Unknown Unknown a.out 08084A0D Unknown Unknown Unknown a.out 080648C8 Unknown Unknown Unknown a.out 08064D6B Unknown Unknown Unknown a.out 08055937 Unknown Unknown Unknown a.out 080554B1 Unknown Unknown Unknown a.out 0804A239 Unknown Unknown Unknown a.out 0804A13C Unknown Unknown Unknown UnknownA7E40EA8 Unknown Unknown Unknown a.out 08049FF1 Unknown Unknown Unknown -- Summary: partial unformatted reads shouldn't succeed Product: gcc Version: 4.2.0 Status: UNCONFIRMED Keywords: wrong-code Severity: normal Priority: P3 Component: libfortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: tkoenig at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29627
[Bug libfortran/29627] partial unformatted reads shouldn't succeed
--- Comment #1 from tkoenig at gcc dot gnu dot org 2006-10-28 18:11 --- Uh, I forgot the actual output from the program: $ gfortran partial.f90 $ ./a.out ab -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29627
[Bug target/28806] lround is not expanded inline to SSE conversion sequence
--- Comment #3 from pinskia at gcc dot gnu dot org 2006-10-28 18:22 --- Fixed. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28806
[Bug middle-end/26900] Number of iterations not know for simple loop
--- Comment #13 from rguenth at gcc dot gnu dot org 2006-10-28 18:22 --- Now that we do all possible canonicalization we still can not figure out # of iterations here. I'm revisiting the proposed patch for this PR and am going to attack tree-ssa-loop-niter.c:simplify_using_initial_conditions again. (Zdenek, I hope you don't mind if I take this bug from you again ;)) -- rguenth at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|rakdver at gcc dot gnu dot |rguenth at gcc dot gnu dot |org |org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26900
[Bug target/28806] lround is not expanded inline to SSE conversion sequence
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|--- |4.3.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28806
[Bug fortran/29617] gfortran testsuite failure
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-10-28 18:26 --- Related to PR 21952. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29617
[Bug c++/29615] Class can't be friends of itself?
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-10-28 18:44 --- As far as I can tell this has been a pedwarning since the begining of the C++ front-end. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Keywords||rejects-valid http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29615
[Bug debug/29614] [4.2/4.3 Regression] DWARF information for function static variable is missing after unrelated code addition
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-10-28 18:49 --- Confirmed. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||pinskia at gcc dot gnu dot ||org Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 GCC build triplet|i686-pc-linux-gnu | GCC host triplet|i686-pc-linux-gnu | Keywords||wrong-debug Last reconfirmed|-00-00 00:00:00 |2006-10-28 18:49:28 date|| Summary|DWARF information for |[4.2/4.3 Regression] DWARF |function static variable is |information for function |missing after unrelated code|static variable is missing |addition|after unrelated code ||addition Target Milestone|--- |4.2.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29614
[Bug libfortran/29627] partial unformatted reads shouldn't succeed
-- tkoenig at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |tkoenig at gcc dot gnu dot |dot org |org Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2006-10-28 19:30:27 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29627
[Bug debug/29628] New: [32bit] unused argc/argv missing their DW_AT_location
`main' function (the function with specific prologue/epilogue) is missing DWARF
`DW_AT_location' for its `argc' and `argv' on 32-bit targets - only if these
arguments are never unused.
affected: x86_64-redhat-linux with -m32, i386-redhat-linux
not affected: x86_64-redhat-linux (-m64)
32-bit broken for: gcc-4.1.1, SVN snapshot 4.3.0
always works: gcc-3.4.6
It causes gdb(1) to hide the arguments during backtrace:
#0 main () at test.c:3
correct [i386]:
echo 'int main (int argc, char **argv) { return argc + (int) argv; }' >main.c
;gcc -o main.o main.c -ggdb3;readelf -a --debug main.o|grep -A5 -w argc
incorrect [i386]:
echo 'int main (int argc, char **argv) { return 0; }' >main.c ;gcc -o main.o
main.c -ggdb3;readelf -a --debug main.o|grep -A5 -w argc
correct (gcc-3.4.6):
<1>: Abbrev Number: 33 (DW_TAG_subprogram)
DW_AT_sibling :
DW_AT_external: 1
DW_AT_name: main
DW_AT_decl_file : 46
DW_AT_decl_line : 267
DW_AT_prototyped : 1
DW_AT_type:
DW_AT_low_pc : 0x8048c0f
DW_AT_high_pc : 0x8048e26
DW_AT_frame_base : 616(location list)
<2>: Abbrev Number: 34 (DW_TAG_formal_parameter)
DW_AT_name: argc
DW_AT_decl_file : 46
DW_AT_decl_line : 267
DW_AT_type:
DW_AT_location: 2 byte block: 91 0 (DW_OP_fbreg: 0)
<2>: Abbrev Number: 34 (DW_TAG_formal_parameter)
DW_AT_name: argv
DW_AT_decl_file : 46
DW_AT_decl_line : 267
DW_AT_type:
DW_AT_location: 2 byte block: 91 4 (DW_OP_fbreg: 4)
incorrect (gcc-4.1.1; appropriately for SVN snapshot - ~4.3.0):
<1><64>: Abbrev Number: 2 (DW_TAG_subprogram)
DW_AT_external: 1
DW_AT_name: main
DW_AT_decl_file : 1
DW_AT_decl_line : 2
DW_AT_prototyped : 1
DW_AT_type: <9b>
DW_AT_low_pc : 0x8048324
DW_AT_high_pc : 0x804833d
DW_AT_frame_base : 0 (location list)
DW_AT_sibling : <9b>
<2><82>: Abbrev Number: 3 (DW_TAG_formal_parameter)
DW_AT_name: argc
DW_AT_decl_file : 1
DW_AT_decl_line : 1
DW_AT_type: <9b>
<2><8e>: Abbrev Number: 3 (DW_TAG_formal_parameter)
DW_AT_name: argv
DW_AT_decl_file : 1
DW_AT_decl_line : 1
DW_AT_type:
dwarf2.out.c mem_loc_descriptor () GET_CODE (rtl):
`case REG:' for i386 `argc'; it will fail on:
if (REGNO (rtl) < FIRST_PSEUDO_REGISTER)
Checked there:
REGNO (rtl) == 61 /* Therefore pseudoreg. */
ORIGINAL_REGNO (rtl) == REGNO (rtl)
reg_renumber [61] == -1
On i386 with the arguments used it is fine as:
REGNO (rtl) == 1 /* Therefore hard register. */
On x86_64 it goes the `case PLUS:' way, not `case REG:'.
Could you advice where to find the location information for pseudoregisters
there?
--
Summary: [32bit] unused argc/argv missing their DW_AT_location
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: minor
Priority: P3
Component: debug
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: jan dot kratochvil at redhat dot com
GCC build triplet: i686-pc-linux-gnu
GCC host triplet: i686-pc-linux-gnu
GCC target triplet: i686-pc-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29628
[Bug fortran/29625] Octal edit descriptors allow real variables, even with -std=f95
--- Comment #2 from burnus at gcc dot gnu dot org 2006-10-28 21:05 --- Subject: Bug 29625 Author: burnus Date: Sat Oct 28 21:05:42 2006 New Revision: 118111 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=118111 Log: 2006-10-28 Tobias Burnus <[EMAIL PROTECTED]> PR fortran/29625 * io/transfer.c (formatted_transfer_scalar): Allow binary edit descriptors for real variables; give error for BOZ edit descriptor for non-integers when using -std=f*. Modified: trunk/libgfortran/ChangeLog trunk/libgfortran/io/transfer.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29625
[Bug fortran/29629] New: ICE on OpenMP-enabled program (gfc_conv_variable, at fortran/trans-expr.c:404)
There must be something inherently evil with the code below as both, gfortran and ifort, crash. If either "func" is not array valued or not listed in the REDUCE-clause, everything is fine. $> cat omp.f90 PROGRAM omp write (*,*) func(n) CONTAINS FUNCTION func(n) INTEGER, INTENT(in) :: n INTEGER, DIMENSION(n) :: func INTEGER :: k func = 0 !$OMP PARALLEL DO PRIVATE(k), REDUCTION(+:func) DO k = 1, n func = func + 1 END DO !$OMP END PARALLEL DO END FUNCTION END PROGRAM $> gfortran-svn -g -Wall -fopenmp omp.f90 omp.f90: In function 'func': omp.f90:11: internal compiler error: in gfc_conv_variable, at fortran/trans-expr.c:404 Please submit a full bug report, with preprocessed source if appropriate. $> gfortran-svn -v Using built-in specs. Target: i686-pc-linux-gnu Configured with: ../../svn/gcc/configure --prefix=/home/daniel/nfs/packages/i686-pc-linux-gnu/gcc-svn --disable-nls --enable-threads=posix --enable-shared --enable-bootstrap --with-system-zlib --program-suffix=-svn --enable-languages=c,c++,fortran Thread model: posix gcc version 4.3.0 20061026 (experimental) $> ifort -g -warn all -check all -openmp omp.f90 fortcom: Severe: **Internal compiler error: segmentation violation signal raised** Please report this error along with the circumstances in which it occurred in a Software Problem Report. Note: File and line given may not be explicit cause of this error. $> ifort -v Version 9.0 -- Summary: ICE on OpenMP-enabled program (gfc_conv_variable, at fortran/trans-expr.c:404) Product: gcc Version: 4.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: franke dot daniel at gmail dot com GCC host triplet: i686-pc-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29629
[Bug fortran/29625] Octal edit descriptors allow real variables, even with -std=f95
--- Comment #3 from burnus at gcc dot gnu dot org 2006-10-28 21:07 --- Subject: Bug 29625 Author: burnus Date: Sat Oct 28 21:07:19 2006 New Revision: 118112 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=118112 Log: 2006-10-28 Tobias Burnus <[EMAIL PROTECTED]> PR fortran/29625 * gfortran.dg/io_real_boz.f90: Add. * gfortran.dg/io_real_boz2.f90: Add. Added: trunk/gcc/testsuite/gfortran.dg/io_real_boz.f90 trunk/gcc/testsuite/gfortran.dg/io_real_boz2.f90 Modified: trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29625
[Bug libfortran/29627] partial unformatted reads shouldn't succeed
--- Comment #2 from tkoenig at gcc dot gnu dot org 2006-10-28 21:24 --- Created an attachment (id=12504) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12504&action=view) preliminary patch -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29627
[Bug fortran/28224] gfortran should support namelist (nml) for internal file units
--- Comment #5 from burnus at gcc dot gnu dot org 2006-10-28 21:46 --- Accept. -- burnus at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |burnus at gcc dot gnu dot |dot org |org Status|NEW |ASSIGNED Last reconfirmed|2006-07-02 23:10:59 |2006-10-28 21:46:49 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28224
[Bug fortran/29625] Octal edit descriptors allow real variables, even with -std=f95
--- Comment #4 from burnus at gcc dot gnu dot org 2006-10-28 21:43 --- Fix checked in: Author: burnus Date: Sat Oct 28 21:05:42 2006 New Revision: 118111 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=118111 Log: 2006-10-28 Tobias Burnus <[EMAIL PROTECTED]> PR fortran/29625 * io/transfer.c (formatted_transfer_scalar): Allow binary edit descriptors for real variables; give error for BOZ edit descriptor for non-integers when using -std=f*. Modified: trunk/libgfortran/ChangeLog trunk/libgfortran/io/transfer.c Author: burnus Date: Sat Oct 28 21:07:19 2006 New Revision: 118112 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=118112 Log: 2006-10-28 Tobias Burnus <[EMAIL PROTECTED]> PR fortran/29625 * gfortran.dg/io_real_boz.f90: Add. * gfortran.dg/io_real_boz2.f90: Add. Added: trunk/gcc/testsuite/gfortran.dg/io_real_boz.f90 trunk/gcc/testsuite/gfortran.dg/io_real_boz2.f90 Modified: trunk/gcc/testsuite/ChangeLog -- burnus at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |burnus at gcc dot gnu dot |dot org |org Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2006-10-28 21:43:44 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29625
[Bug fortran/29630] New: "Unclassifiable statement" with vector subscripts in initialization
erik:~/gcc$ cat bug.f90 program init implicit none integer, parameter :: a1(6) = [1, 2, 3, 4, 5, 6] integer, parameter :: b1(3) = a1([1,2,3]) end program init erik:~/gcc$ gfortran bug.f90 In file bug.f90:4 integer, parameter :: b1(3) = a1([1,2,3]) 1 Error: Unclassifiable statement at (1) -- Summary: "Unclassifiable statement" with vector subscripts in initialization Product: gcc Version: 4.3.0 Status: UNCONFIRMED Keywords: rejects-valid Severity: normal Priority: P3 Component: fortran AssignedTo: eedelman at gcc dot gnu dot org ReportedBy: eedelman at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29630
[Bug fortran/29625] Octal edit descriptors allow real variables, even with -std=f95
--- Comment #5 from burnus at gcc dot gnu dot org 2006-10-28 21:44 --- Mark fixed. -- burnus at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29625
[Bug fortran/28224] gfortran should support namelist (nml) for internal file units
--- Comment #6 from burnus at gcc dot gnu dot org 2006-10-28 21:59 --- Subject: Bug 28224 Author: burnus Date: Sat Oct 28 21:59:20 2006 New Revision: 118113 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=118113 Log: fortran/ 2006-10-28 Tobias Burnus <[EMAIL PROTECTED]> PR fortran/28224 * io.c (check_io_constraints): Allow namelists for internal files for Fortran 2003. testsuite/ 2006-10-28 Tobias Burnus <[EMAIL PROTECTED]> PR fortran/28224 * gfortran.dg/io_constraints_2.f90: Use -std=f95. * gfortran.dg/namelist_internal.f90: New test. Added: trunk/gcc/testsuite/gfortran.dg/namelist_internal.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/io.c trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gfortran.dg/io_constraints_2.f90 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28224
[Bug fortran/28224] gfortran should support namelist (nml) for internal file units
--- Comment #7 from burnus at gcc dot gnu dot org 2006-10-28 21:59 --- Fixed. -- burnus at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28224
[Bug fortran/28484] system_clock with real-type count_rate does not compile
--- Comment #4 from burnus at gcc dot gnu dot org 2006-10-28 22:13 --- Assign. Preliminary patch at: http://gcc.gnu.org/ml/gcc-patches/2006-10/msg01387.html -- burnus at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |burnus at gcc dot gnu dot |dot org |org Status|NEW |ASSIGNED Last reconfirmed|2006-09-03 06:10:52 |2006-10-28 22:13:07 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28484
[Bug libstdc++/29529] purify with iostream reports 128 uninitialized memory reads
--- Comment #4 from pcarlini at suse dot de 2006-10-28 22:34 --- Ok, I have double checked that both on 4.0.3 and the active branches everything is fine per Valgrind (3.2.1). You may want to pass -v to Valgrind and look at the "supp:" lines in the output, showing the used suppressions: interestingly, one pretty commonly used is called "Ubuntu-stripped-ld.so", that is, it has been added to cope with Ubuntu-specific false positives... -- pcarlini at suse dot de changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29529
[Bug c++/29033] %s substituted with "left"/"right" can't be properly translated
--- Comment #2 from mueller at gcc dot gnu dot org 2006-10-28 22:34 --- Subject: Bug 29033 Author: mueller Date: Sat Oct 28 22:34:06 2006 New Revision: 118117 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=118117 Log: 2006-10-29 Dirk Mueller <[EMAIL PROTECTED]> PR c++/29033 * typeck.c (build_binary_op): Duplicate warning message for better translation. Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/typeck.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29033
[Bug c++/29033] %s substituted with "left"/"right" can't be properly translated
--- Comment #3 from mueller at gcc dot gnu dot org 2006-10-28 22:41 --- Fixed for 4.3. -- mueller at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Known to work||4.3.0 Resolution||FIXED Target Milestone|--- |4.3.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29033
[Bug middle-end/29631] [4.1 regression] Incorrect zero extension of signed short IV
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-10-28 23:05 --- What happens if you try -O2 -fno-loop-optimize? -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Component|tree-optimization |middle-end Known to work||4.2.0 Target Milestone|--- |4.1.2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29631
[Bug c++/29295] ++ operator with bool typedef increments or operator -- with bool typedef
--- Comment #5 from pinskia at gcc dot gnu dot org 2006-10-28 23:02 --- Subject: Bug 29295 Author: pinskia Date: Sat Oct 28 23:01:59 2006 New Revision: 118118 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=118118 Log: 2006-10-28 Andrew Pinski <[EMAIL PROTECTED]> PR C++/29295 * typeck.c (build_unary_op): Use same_type_p when comparing to boolean type. 2006-10-28 Andrew Pinski <[EMAIL PROTECTED]> PR C++/29295 * g++.dg/expr/bool1.C: New test. * g++.dg/expr/bool2.C: New test. Added: trunk/gcc/testsuite/g++.dg/expr/bool1.C trunk/gcc/testsuite/g++.dg/expr/bool2.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/typeck.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29295
[Bug tree-optimization/29631] New: [4.1 regression] Incorrect zero extension of signed short IV
This is extracted from gnushogi (http://bugs.debian.org/393075).
[EMAIL PROTECTED]:~% cat bug.c
const signed char nunmap[] = { 17, -1, 1 };
__attribute__((noinline))
void ff(int i) {
asm volatile("");
}
__attribute__((noinline))
void f(short delta) {
short p0 = 2, s;
for (s = 0; s < 2; s++) {
p0 += delta;
ff(s);
if (nunmap[p0] == 17)
asm volatile("# nop");
}
}
int main() {
f(-1);
return 0;
}
[EMAIL PROTECTED]:~% gcc-3.4 -O2 bug.c && ./a.out
[EMAIL PROTECTED]:~% gcc-4.2 -O2 bug.c && ./a.out
[EMAIL PROTECTED]:~% gcc-4.1 -O2 bug.c && ./a.out
zsh: segmentation fault (core dumped) ./a.out
Reason seems to be that delta is zero extended, not sign extended:
$f..ng:
lda $30,-32($30)
ldah $1,nunmap($29) !gprelhigh
lda $1,nunmap($1) !gprellow
stq $9,8($30)
stq $10,16($30)
mov $31,$9
stq $11,24($30)
lda $10,3($1)# $10 = numap + 3
zapnot $16,3,$11 # $11 = zero extend delta (=65535)
stq $26,0($30)
.prologue 1
$L4:
addq $10,$11,$10 # $10 += $11
addl $31,$9,$16
bsr $26,ff !samegp
ldq_u $1,-1($10) # access numap[65537] -> SEGV
extqh $1,$10,$1
sra $1,56,$1
cmpeq $1,17,$1
bne $1,$L12
$L5:
lda $9,1($9)
cmpeq $9,2,$1
beq $1,$L4
ldq $26,0($30)
ldq $9,8($30)
ldq $10,16($30)
ldq $11,24($30)
lda $30,32($30)
ret $31,($26),1
.align 4
$L12:
.setmacro
# nop
.setnomacro
br $31,$L5
--
Summary: [4.1 regression] Incorrect zero extension of signed
short IV
Product: gcc
Version: 4.1.2
Status: UNCONFIRMED
Keywords: wrong-code
Severity: normal
Priority: P3
Component: tree-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: falk at debian dot org
GCC build triplet: alpha-linux-gnu
GCC host triplet: alpha-linux-gnu
GCC target triplet: alpha-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29631
[Bug c++/29295] ++ operator with bool typedef increments or operator -- with bool typedef
--- Comment #6 from pinskia at gcc dot gnu dot org 2006-10-28 23:02 --- Fixed. -- pinskia 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=29295
[Bug middle-end/29631] [4.1 regression] Incorrect zero extension of signed short IV
--- Comment #2 from falk at debian dot org 2006-10-28 23:13 --- (In reply to comment #1) > What happens if you try -O2 -fno-loop-optimize? No crash then. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29631
[Bug rtl-optimization/29631] [4.1 regression] Incorrect zero extension of signed short IV
--- Comment #3 from pinskia at gcc dot gnu dot org 2006-10-28 23:19 --- > No crash then. So this is another loop.c bug. This is why it was removed, it was full of bugs :). -- pinskia at gcc dot gnu dot org changed: What|Removed |Added BugsThisDependsOn||28970 Component|middle-end |rtl-optimization http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29631
[Bug c++/16307] -Wchar-subscripts does not warn on pointers
--- Comment #4 from mueller at gcc dot gnu dot org 2006-10-28 23:22 --- Testing patch. -- mueller at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |mueller at gcc dot gnu dot |dot org |org Status|NEW |ASSIGNED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16307
[Bug debug/29628] unused argc/argv missing their DW_AT_location
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added Severity|minor |normal GCC build triplet|i686-pc-linux-gnu | GCC host triplet|i686-pc-linux-gnu | Summary|[32bit] unused argc/argv|unused argc/argv missing |missing their DW_AT_location|their DW_AT_location http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29628
[Bug c++/6321] no warning for bad main function declaration
--- Comment #4 from mueller at gcc dot gnu dot org 2006-10-28 23:45 --- testing patch -- mueller at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |mueller at gcc dot gnu dot |dot org |org Status|NEW |ASSIGNED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=6321
[Bug fortran/29537] ICE in gfc_match_common for blank common in BLOCK DATA unit
--- Comment #10 from sgk at troutmask dot apl dot washington dot edu 2006-10-28 23:56 --- Subject: Re: ICE in gfc_match_common for blank common in BLOCK DATA unit On Sun, Oct 22, 2006 at 09:08:02PM -, aldot at gcc dot gnu dot org wrote: > > Created an attachment (id=12476) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12476&action=view) > --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12476&action=view) > untested proposed fix > > I hope to test this patch soon. > > Note that it adds a warning about blank common in block data but -- unlike the > patch in the previous comment -- does accept the common instead of abandoning > it via goto cleanup. Please advise if not cleaning this up is acceptable or if > blank commons should be ignored there. > > fortran/ChangeLog: > 2006-10-22 Bernhard Fischer <[EMAIL PROTECTED]> > > PR fortran/29537 > * trans-common.c (gfc_trans_common): For unnamed block data the > proc_name is null, so use the locus of the common. > (gfc_sym_mangled_common_id): Fix whitespace. > * match.c (gfc_match_common): Emit warning about blank common in > block data. > > testsuite/ChangeLog: > 2006-10-22 Bernhard Fischer <[EMAIL PROTECTED]> > > PR fortran/29537 > * blockdata_1.f90: Add warning about blank common in block data. > * blockdata_2.f90: New testcase. > > Bernhard, This is ok for trunk. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29537
[Bug libfortran/29627] partial unformatted reads shouldn't succeed
--- Comment #3 from jvdelisle at gcc dot gnu dot org 2006-10-28 23:21 --- I had considered flipping the logic around on is_stream_io as you have done in the preliminary patch. The first versions of stream_io I was leaving the existing code completely untouched while testing out the overall approach. Now that we are in 4.3 this is a good time to do some cleanup. Overall, the prelminary patch approach looks good, but I have not tested yet. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29627
[Bug other/29271] Incorrect -fdump-rtl-sched documentation
--- Comment #4 from pinskia at gcc dot gnu dot org 2006-10-29 00:28 --- Subject: Bug 29271 Author: pinskia Date: Sun Oct 29 00:27:49 2006 New Revision: 118128 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=118128 Log: 2006-10-28 Andrew Pinski <[EMAIL PROTECTED]> PR tree-opt/29271 * doc/invoke.texi (-fdump-rtl-sched2) Fix file extension number. (-fdump-rtl-sched): Rename to .. (-fdump-rtl-sched1): here. Also fix file extension number. Modified: trunk/gcc/ChangeLog trunk/gcc/doc/invoke.texi -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29271
[Bug other/29271] Incorrect -fdump-rtl-sched documentation
--- Comment #5 from pinskia at gcc dot gnu dot org 2006-10-29 00:28 --- Fixed. -- pinskia 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=29271
[Bug middle-end/29335] transcendental functions with constant arguments should be resolved at compile-time
--- Comment #23 from ghazi at gcc dot gnu dot org 2006-10-29 02:02 --- Subject: Bug 29335 Author: ghazi Date: Sun Oct 29 02:02:10 2006 New Revision: 118129 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=118129 Log: PR middle-end/29335 * builtins.c (do_mpfr_arg2, fold_builtin_hypot): New. (fold_builtin_pow): Evaluate constant arguments at compile-time using MPFR. (fold_builtin_1): Handle BUILT_IN_ATAN2 and BUILT_IN_HYPOT. (do_mpfr_ckconv): New helper function. (do_mpfr_arg1): Use do_mpfr_ckconv. (do_mpfr_arg2): New. testsuite: * gcc.dg/builtins-20.c: Add tests for hypot. * gcc.dg/torture/builtin-math-2.c (TESTIT2): New. Add tests for two-argument builtins. * gcc.dg/torture/builtin-math-3.c (TESTIT_R): Renamed from TESTIT2. Update all callers. (TESTIT2, TESTIT2_R): New helper macros. Add testcases for pow, hypot and atan2. Modified: trunk/gcc/ChangeLog trunk/gcc/builtins.c trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gcc.dg/builtins-20.c trunk/gcc/testsuite/gcc.dg/torture/builtin-math-2.c trunk/gcc/testsuite/gcc.dg/torture/builtin-math-3.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29335
[Bug c++/29632] New: ICE on invalid code: regenerate_decl_from_template, at cp/pt.c:10969
The following crashes g++:
struct nullptr_type {
nullptr_type ( void ) {}
template < typename T >
operator T* ( void ) const {
return ( 0 );
}
} const nullptr;
int main ( void ) {
0 == nullptr;
}
g++ -v:
Reading specs from /usr/lib/gcc/i686-pc-linux-gnu/3.4.6/specs
Configured with: /var/tmp/portage/gcc-3.4.6-r1/work/gcc-3.4.6/configure
--prefix=/usr --bindir=/usr/i686-pc-linux-gnu/gcc-bin/3.4.6
--includedir=/usr/lib/gcc/i686-pc-linux-gnu/3.4.6/include
--datadir=/usr/share/gcc-data/i686-pc-linux-gnu/3.4.6
--mandir=/usr/share/gcc-data/i686-pc-linux-gnu/3.4.6/man
--infodir=/usr/share/gcc-data/i686-pc-linux-gnu/3.4.6/info
--with-gxx-include-dir=/usr/lib/gcc/i686-pc-linux-gnu/3.4.6/include/g++-v3
--host=i686-pc-linux-gnu --build=i686-pc-linux-gnu --disable-altivec
--enable-nls --without-included-gettext --with-system-zlib --disable-checking
--disable-werror --disable-libunwind-exceptions --disable-multilib
--disable-libgcj --enable-languages=c,c++,f77 --enable-shared
--enable-threads=posix --enable-__cxa_atexit --enable-clocale=gnu
Thread model: posix
--
Summary: ICE on invalid code: regenerate_decl_from_template, at
cp/pt.c:10969
Product: gcc
Version: 4.1.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: jkherciueh at gmx dot net
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29632
[Bug c++/29633] New: syntax error in do/while condition with templates reports incorrect line number
The simplest way to explain this is with an example. When compiling the
testcase below, g++ will report an error on lines 16, but it should report an
error on lines 18. If you change just about anything about this example, it
will report the correct line number (e.g. using non-template classes for either
class, changing the pointer type to Class1, removing "tc_a &&" from the
condition). So there's some interaction between a template member function
referencing the name/pointer of a templated class in a logic expression in a
do/while loop that is causing the wrong line number to be reported. It's
definitely an obscure situation, but it left me scratching my head for a while
trying to figure out why my code wouldn't compile.
template
struct Class1
{
void testfn1(void);
};
template
class Class2
{
public:
void testfn2(void)
{
Class1 * tc_a;
do
{
int x = 0; //line 16
}
while (tc_a && tc_a->testfn1); //line 18
}
};
int main(void)
{
Class2 tc2;
tc2.testfn2();
return 0;
}
--
Summary: syntax error in do/while condition with templates
reports incorrect line number
Product: gcc
Version: 4.1.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: ceckak at alumni dot washington dot edu
GCC host triplet: g++ (GCC) 4.1.1 20060724 (prerelease) (4.1.1-3mdk)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29633
[Bug c++/29633] syntax error in do/while condition with templates reports incorrect line number
--- Comment #1 from ceckak at alumni dot washington dot edu 2006-10-29 04:51 --- Created an attachment (id=12505) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12505&action=view) testcase -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29633
[Bug fortran/24978] ICE in gfc_assign_data_value_range
--- Comment #5 from jvdelisle at gcc dot gnu dot org 2006-10-29 05:16 --- Should we simply avoid the ice, perhaps accepting the invalid code or do we want to search for duplicates in the DATA statements and generate an error? Also, Is this valid?: real :: a(5,5) DATA a(1,1), a(3,1), a(1,2), a(3,3) /2*1.0, 2*2.0/ DATA a(2,1) /2.5/ In other words, no overlap in the DATA statements. It is a big difference if we have to search element by element. I suspect this is why this is not a constraint on the compiler, but is a restriction on the programmer, so to speak. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24978
[Bug c++/29633] syntax error in do/while condition with templates reports incorrect line number
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-10-29 06:48 --- Confirmed, not a regression. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 GCC host triplet|g++ (GCC) 4.1.1 20060724| |(prerelease) (4.1.1-3mdk) | Keywords||diagnostic Known to fail||2.95 3.2.3 3.4.0 4.0.0 4.2.0 ||4.0.4 4.1.2 Last reconfirmed|-00-00 00:00:00 |2006-10-29 06:48:10 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29633
[Bug fortran/29629] ICE on OpenMP-enabled program (gfc_conv_variable, at fortran/trans-expr.c:404)
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-10-29 06:50 --- Confirmed. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||pinskia at gcc dot gnu dot ||org Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Keywords||ice-on-valid-code, openmp Last reconfirmed|-00-00 00:00:00 |2006-10-29 06:50:04 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29629
[Bug c++/29632] [4.0/4.1/4.2 Regression] ICE on invalid code: regenerate_decl_from_template, at cp/pt.c:10969
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-10-29 06:44 --- Confirmed, we stopped ICEing sometime between 3.4.x and 4.0.0. I am going to mark this as a regression, though I don't know if it should or not. The ICE has happened since at least 2.95.3. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||pinskia at gcc dot gnu dot ||org Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Keywords||accepts-invalid Last reconfirmed|-00-00 00:00:00 |2006-10-29 06:44:51 date|| Summary|ICE on invalid code:|[4.0/4.1/4.2 Regression] ICE |regenerate_decl_from_templat|on invalid code: |e, at cp/pt.c:10969 |regenerate_decl_from_templat ||e, at cp/pt.c:10969 Target Milestone|--- |4.0.4 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29632
