[Bug fortran/37903] [4.3/4.4 Regression] wrong-code for complicated vector subscripts
--- Comment #6 from pault at gcc dot gnu dot org 2008-10-28 06:25 --- (In reply to comment #3) I suspect this is only hiding the problem though. Indeed it is - the old problem returns with integer :: i(-1:1) = 1, j(3) = 1, k(3) k = j(I + (/1,1,1/)) end for obvious reasons. It's a nice try though and you are obviously getting to the nub of the problem. Paul -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37903
[Bug c/37931] [4.4 Regression] ice: verify_gimple failed
--- Comment #1 from jakub at gcc dot gnu dot org 2008-10-28 07:47 ---
Smaller testcase:
int
foo (void)
{
int a = 0, b = 0;
unsigned int c = 0;
return (a | b == b) (c | 1);
}
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Last reconfirmed|-00-00 00:00:00 |2008-10-28 07:47:39
date||
Summary|ice: verify_gimple failed |[4.4 Regression] ice:
||verify_gimple failed
Target Milestone|--- |4.4.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37931
[Bug c/37931] [4.4 Regression] ice: verify_gimple failed
--- Comment #2 from jakub at gcc dot gnu dot org 2008-10-28 07:54 ---
Even smaller:
int a;
unsigned int b;
int
foo (void)
{
return (a | 1) (b | 1);
}
--
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|2008-10-28 07:47:39 |2008-10-28 07:54:17
date||
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37931
[Bug c++/37932] New: narrowing conversion with -std=c++0x
There some confusing/wrong error messages with the -std=c++0x option.
All three example statements below work fine without -std=c++0x and with
gcc versions = 4.3. Seems to be a gcc bug and no C++0x demand (at least
the first 2 example statements).
typedef enum { AA=1, BB=2 } my_enum;
typedef struct { my_enum a:4 ; unsigned b:28; } stru;
void foo (char c, my_enum x, int i)
{
char arr[2] = {c+'0', 0};
stru s = {x,0};
stru t = {i,0};
}
$ g++ -std=c++0x -c tst.c
tst.c: In function 'void foo(char, my_enum, int)':
tst.c:7: error: narrowing conversion of '(((int)c) + 48)' to 'char' inside { }
tst.c:8: error: narrowing conversion of 'x' to 'unsigned char:4' inside { }
tst.c:9: error: narrowing conversion of 'i' to 'unsigned char:4' inside { }
gcc trunk rev. 141404
--
Summary: narrowing conversion with -std=c++0x
Product: gcc
Version: 4.4.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: holger dot hopp at sap dot com
GCC build triplet: x86_64-unknown-linux-gnu
GCC host triplet: x86_64-unknown-linux-gnu
GCC target triplet: x86_64-unknown-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37932
[Bug middle-end/37931] [4.4 Regression] ice: verify_gimple failed
--- Comment #3 from jakub at gcc dot gnu dot org 2008-10-28 10:36 --- Subject: Bug 37931 Author: jakub Date: Tue Oct 28 10:34:51 2008 New Revision: 141406 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=141406 Log: PR middle-end/37931 * fold-const.c (distribute_bit_expr): Convert common, left and right arguments to type. * gcc.c-torture/execute/pr37931.c: New test. Added: trunk/gcc/testsuite/gcc.c-torture/execute/pr37931.c Modified: trunk/gcc/ChangeLog trunk/gcc/fold-const.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37931
[Bug middle-end/37931] [4.4 Regression] ice: verify_gimple failed
--- Comment #4 from jakub at gcc dot gnu dot org 2008-10-28 10:38 --- Fixed. -- jakub at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37931
[Bug c++/26693] [4.2/4.3/4.4 regression] Access checks not performed for types in templates
-- dodji at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |dodji at gcc dot gnu dot org |dot org | Status|NEW |ASSIGNED Last reconfirmed|2007-09-01 20:49:21 |2008-10-28 12:16:16 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26693
[Bug fortran/37903] [4.3/4.4 Regression] wrong-code for complicated vector subscripts
--- Comment #7 from mikael dot morin at tele2 dot fr 2008-10-28 12:21 --- This is happening because (1) gfc_trans_constant_array_constructor sets loop-temp_dim to 1. (2) gfc_conv_loop_setup choses the last ss whose shape is known (that of i). (3) gfc_conv_loop_setup sets loop bounds (-1-1) according to the chosen ss (i). (4) gfc_trans_create_temp_array conditionally resets the loop bounds (if n = loop-temp_dim). (5) gfc_trans_create_temp_array later assumes that the loop starts at zero. (2) explains why it works with y(i+(/1,1,1/)) but not with y((/1,1,1/)+i) My patch in comment #3 changes the last ss to first ss and of course it doesn't work as was said in comment #6 I have two fixes almost ready. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37903
[Bug c++/37933] New: reference to ... is amibgous: same error shown twice for same line of code
$ cat test.cpp
namespace x {
extern char *foo;
};
using namespace x;
char *foo;
char bar()
{
return *foo;
}
$ g++ test.cpp -fsyntax-only
test.cpp: In function char bar():
test.cpp:8: error: reference to foo is ambiguous
test.cpp:5: error: candidates are: char* foo
test.cpp:2: error: char* x::foo
test.cpp:8: error: reference to foo is ambiguous
test.cpp:5: error: candidates are: char* foo
test.cpp:2: error: char* x::foo
The same error is shown twice.
I think it would be enough to show the error once.
This is with:
$ g++ -v
Using built-in specs.
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Debian 4.3.2-1'
--with-bugurl=file:///usr/share/doc/gcc-4.3/README.Bugs
--enable-languages=c,c++,fortran,objc,obj-c++ --prefix=/usr --enable-shared
--with-system-zlib --libexecdir=/usr/lib --without-included-gettext
--enable-threads=posix --enable-nls --with-gxx-include-dir=/usr/include/c++/4.3
--program-suffix=-4.3 --enable-clocale=gnu --enable-libstdcxx-debug
--enable-objc-gc --enable-mpfr --enable-cld --enable-checking=release
--build=x86_64-linux-gnu --host=x86_64-linux-gnu --target=x86_64-linux-gnu
Thread model: posix
gcc version 4.3.2 (Debian 4.3.2-1)
Same happens with g++-4.2, and trunk (r141407), g++-4.1 appears to infloop.
--
Summary: reference to ... is amibgous: same error shown twice for
same line of code
Product: gcc
Version: 4.3.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: edwintorok at gmail dot com
GCC build triplet: x86_64-linux-gnu
GCC host triplet: x86_64-linux-gnu
GCC target triplet: x86_64-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37933
[Bug c++/37934] New: show a warning when a symbol is unused and completely removed from the output file
Consider the testcase below.
$ cat test.cpp
namespace x {
extern const char ** const foo;
extern const char ** const bar;
};
using namespace x;
namespace {
const char* X;
};
const char ** const foo = X;
const char ** const x::bar = X;
$ g++ test.cpp -Wall -Wunused -Wextra -c -o test.o
$ nm test.o | c++filt
b (anonymous namespace)::X
R x::bar
foo is completely removed from the output, and no warning is shown.
It would be useful to show a warning here.
For example in the above testcase I forgot to add the x:: namespace qualifier
to foo (the extern declaration was in a header and I didn't notice it was part
of a namespace).
Since I didn't get any warning, I got a linker error, and had to spend some
time tracing down this typo in my code.
Had I seen a warning from the compiler that 'foo' is not used
and will get removed I would have immediately noticed the absence of the x::
namespace qualifier.
--
Summary: show a warning when a symbol is unused and completely
removed from the output file
Product: gcc
Version: 4.3.2
Status: UNCONFIRMED
Severity: enhancement
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: edwintorok at gmail dot com
GCC build triplet: x86_64-linux-gnu
GCC host triplet: x86_64-linux-gnu
GCC target triplet: x86_64-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37934
[Bug middle-end/37913] [4.4 Regression] ICE: Segmentation fault in link_block, cfg.c:153
-- 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 | URL||http://gcc.gnu.org/ml/gcc- ||patches/2008- ||10/msg01190.html Status|NEW |ASSIGNED Last reconfirmed|2008-10-25 09:46:53 |2008-10-28 13:09:04 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37913
[Bug libgomp/37935] New: omp_set_schedule not documented in libgomp.texi
I just saw that at least omp_set_schedule but maybe all new OpenMP 3 functions are not documented in libgomp.texi. -- Summary: omp_set_schedule not documented in libgomp.texi Product: gcc Version: 4.4.0 Status: UNCONFIRMED Keywords: documentation, openmp Severity: normal Priority: P3 Component: libgomp AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: burnus at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37935
[Bug c++/37936] New: Conditional operator optimization error with const int
I have found an error in the optimizer that is causing it to over-optimze a conditional operator, ?:. The optimizer will always choose the first option regardless of the value of the condition. In the code, the call to setHelpInt1 is always passed the value for UP even though DOWN is the correct option at runtime. Subsequent uses of the same condition produce the correct output. Swapping UP and DOWN in getState() causes DOWN to be forced. The incorrect output generated is: setInt 1 to 1 setInt 2 to 2 val: 2 The correct output is: setInt 1 to 2 setInt 2 to 2 val: 2 A slight change in the code will cause the error to not occur. Any of the following changes will cause the optimizer to work correctly: - Make getState() not inlined - Change the getState() function to write out the conditional operator as an if/else statement - Remove the if(gok) test in main() - Change if(gok) to if(gflags) in main() - Compile with -O instead of -O2 - Change the signature of setHelpInt2 to take a const int instead of a const int. This is the strangest 'fix' as it occurs after the call to setHelpInt1. The error is present on a RHEL 5.1 64-bit system with GCC 4.1.2 with the specified configuration: Using built-in specs. Target: x86_64-redhat-linux Configured with: ../configure --prefix=/usr --mandir=/usr/share/man --infodir=/usr/share/info --enable-shared --enable-threads=posix --enable-checking=release --with-system-zlib --enable-__cxa_atexit --disable-libunwind-exceptions --enable-libgcj-multifile --enable-languages=c,c++,objc,obj-c++,java,fortran,ada --enable-java-awt=gtk --disable-dssi --enable-plugin --with-java-home=/usr/lib/jvm/java-1.4.2-gcj-1.4.2.0/jre --with-cpu=generic --host=x86_64-redhat-linux Thread model: posix gcc version 4.1.2 20070626 (Red Hat 4.1.2-14) /usr/libexec/gcc/x86_64-redhat-linux/4.1.2/cc1plus -E -quiet -v -D_GNU_SOURCE badref2.cpp -mtune=generic -Wall -O2 -fpch-preprocess -o badref2.ii ignoring nonexistent directory /usr/lib/gcc/x86_64-redhat-linux/4.1.2/../../../../x86_64-redhat-linux/include #include ... search starts here: #include ... search starts here: /usr/lib/gcc/x86_64-redhat-linux/4.1.2/../../../../include/c++/4.1.2 /usr/lib/gcc/x86_64-redhat-linux/4.1.2/../../../../include/c++/4.1.2/x86_64-redhat-linux /usr/lib/gcc/x86_64-redhat-linux/4.1.2/../../../../include/c++/4.1.2/backward /usr/local/include /usr/lib/gcc/x86_64-redhat-linux/4.1.2/include /usr/include End of search list. /usr/libexec/gcc/x86_64-redhat-linux/4.1.2/cc1plus -fpreprocessed badref2.ii -quiet -dumpbase badref2.cpp -mtune=generic -auxbase badref2 -O2 -Wall -version -o badref2.s GNU C++ version 4.1.2 20070626 (Red Hat 4.1.2-14) (x86_64-redhat-linux) compiled by GNU C version 4.1.2 20070626 (Red Hat 4.1.2-14). GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072 Compiler executable checksum: 6f6d1884a37abf7abe8da2d985ac9045 as -V -Qy -o badref2.o badref2.s GNU assembler version 2.17.50.0.6-5.el5 (x86_64-redhat-linux) using BFD version 2.17.50.0.6-5.el5 20061020 /usr/libexec/gcc/x86_64-redhat-linux/4.1.2/collect2 --eh-frame-hdr -m elf_x86_64 --hash-style=gnu -dynamic-linker /lib64/ld-linux-x86-64.so.2 /usr/lib/gcc/x86_64-redhat-linux/4.1.2/../../../../lib64/crt1.o /usr/lib/gcc/x86_64-redhat-linux/4.1.2/../../../../lib64/crti.o /usr/lib/gcc/x86_64-redhat-linux/4.1.2/crtbegin.o -L/usr/lib/gcc/x86_64-redhat-linux/4.1.2 -L/usr/lib/gcc/x86_64-redhat-linux/4.1.2 -L/usr/lib/gcc/x86_64-redhat-linux/4.1.2/../../../../lib64 -L/lib/../lib64 -L/usr/lib/../lib64 badref2.o -lstdc++ -lm -lgcc_s -lgcc -lc -lgcc_s -lgcc /usr/lib/gcc/x86_64-redhat-linux/4.1.2/crtend.o /usr/lib/gcc/x86_64-redhat-linux/4.1.2/../../../../lib64/crtn.o It has also been reproduced on a PPC cross-compiler with GCC 4.2.1. Both systems exhibit the same behavior regarding the changes that fix the problem. Using built-in specs. Target: powerpc-ai-linux Configured with: /tmphome/jeffh/dev/toolkit-rh5/modules/gcc/configure --prefix=/usr/local/ai/ppc826x-lx2.4-1.70 --srcdir=/tmphome/jeffh/dev/toolkit-rh5/modules/gcc --enable-languages=c,c++ --target=powerpc-ai-linux --with-libs=/usr/local/ai/ppc826x-lx2.4-1.70/target/lib --with-headers=/usr/local/ai/ppc826x-lx2.4-1.70/target/usr/include --enable-shared --disable-nls --with-cpu=603e --enable-threads --enable-__cxa_atexit --with-gnu-ld --with-gnu-as Thread model: posix gcc version 4.2.1 /usr/local/ai/ppc826x-lx2.4-1.70/libexec/gcc/powerpc-ai-linux/4.2.1/cc1plus -E -quiet -v -D_GNU_SOURCE -D__unix__ -D__gnu_linux__ -D__linux__ -Dunix -D__unix -Dlinux -D__linux -Asystem=linux -Asystem=unix -Asystem=posix badref2.cpp -mcpu=603e -O2 -fpch-preprocess -o badref2.ii #include ... search starts here: #include ... search starts here: /usr/local/ai/ppc826x-lx2.4-1.70/lib/gcc/powerpc-ai-linux/4.2.1/../../../../powerpc-ai-linux/include/c++/4.2.1 /usr/local/ai/ppc826x-lx2.4-1.70/lib/gcc/powerpc-ai-linux/4.2.1/../../../../powerpc-ai-linux/include/c++/4.2.1/powerpc-ai-linux
[Bug c++/37936] Conditional operator optimization error with const int
--- Comment #2 from jeff_harris at kentrox dot com 2008-10-28 13:27 --- Compiled as: g++ -Wall -O2 -v -save-temps badref2.cpp -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37936
[Bug fortran/37930] gfortran error and ICE at automatic type conversion with transfer intrinsic
--- Comment #5 from dominiq at lps dot ens dot fr 2008-10-28 13:30 --- On *-Darwin9 I get: i = transfer(-1,1.0) 1 Error: Arithmetic overflow converting REAL(4) to INTEGER(4) at (1). This check can be disabled with the option -fno-range-check If I use the option -fno-range-check I get: gfortran: Internal error: Illegal instruction (program f951) Please submit a full bug report. See http://gcc.gnu.org/bugs.html for instructions. on Intel and Out of stack space. Try running 'limit stacksize unlimited' in the shell to raise its limit. on ppc. I have not tested the patch in http://gcc.gnu.org/ml/gcc-patches/2008-10/msg01183.html, but I am afraid that it will just hide the bug. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37930
[Bug c++/37936] Conditional operator optimization error with const int
--- Comment #1 from jeff_harris at kentrox dot com 2008-10-28 13:27 --- Created an attachment (id=16572) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16572action=view) Source code for bug -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37936
[Bug c++/37936] Conditional operator optimization error with const int
--- Comment #3 from paolo dot carlini at oracle dot com 2008-10-28 13:34 --- Cannot be reproduced in mainline and 4_3-branch. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37936
[Bug fortran/37937] New: Bind(C) diagnostic when using c_double for COMPLEX variables
REAL(c_double) matches double and is OK. However, COMPLEX(c_double) is invalid as the proper kind parameter is c_double_complex matching double _Complex Internally, both yield the same value and also sizeof(0.0_c_double) and sizeof(real(cmplx(0.0, c_double_cmpl)) is the same. Thus one could simply accept c_double as synonym for c_double_complex. gfortran, however, has checks build in which ensure the right KIND is used; there is room for improvement however: ! -- use iso_c_binding implicit none real(c_double) :: r complex(c_double) :: c ! Wrong type(c_ptr) :: ptr ptr = c_loc(c) ! ERROR here end ! -- Error: C kind parameter is for type REAL but symbol 'c' at (1) is of type COMPLEX Expected: The error is printed in the COMPLEX(c_double) line and not in the c_loc line. The other question is whether a WARNING is enough or whether one wants to have an ERROR. PS: Found at http://www.lrz-muenchen.de/services/software/mathematik/gsl/fortran/README - gfortran 4.3.x does not support complex(c_double). -- Summary: Bind(C) diagnostic when using c_double for COMPLEX variables Product: gcc Version: 4.4.0 Status: UNCONFIRMED Keywords: diagnostic Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: burnus at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37937
[Bug fortran/37930] gfortran error and ICE at automatic type conversion with transfer intrinsic
--- Comment #6 from sgk at troutmask dot apl dot washington dot edu 2008-10-28 14:03 --- Subject: Re: gfortran error and ICE at automatic type conversion with transfer intrinsic On Tue, Oct 28, 2008 at 01:30:28PM -, dominiq at lps dot ens dot fr wrote: --- Comment #5 from dominiq at lps dot ens dot fr 2008-10-28 13:30 --- On *-Darwin9 I get: i = transfer(-1,1.0) 1 Error: Arithmetic overflow converting REAL(4) to INTEGER(4) at (1). This check can be disabled with the option -fno-range-check What does program test print *, transfer(-1,1.0) end program test print? I have not tested the patch in http://gcc.gnu.org/ml/gcc-patches/2008-10/msg01183.html, but I am afraid that it will just hide the bug. The actual bug is in the Fortran code! My patch simply fixes the ICE in gfortran. By itself, transfer(-1,1.0) is valid and it so happens to be an NaN. i = NaN is invalid (although I doubt the standard will actually say i = NaN is invalid in a straight forward manner). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37930
[Bug fortran/35820] internal compiler error with nested FORALL
--- Comment #9 from mikael dot morin at tele2 dot fr 2008-10-28 14:06 --- So that they are not lost, patches are here: http://gcc.gnu.org/ml/fortran/2008-10/msg00153.html http://gcc.gnu.org/ml/fortran/2008-10/msg00181.html http://gcc.gnu.org/ml/fortran/2008-10/msg00212.html See the follow-up threads and the mailing list archive for comments. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35820
[Bug fortran/35840] ICE for character expression in I/O specifier
--- Comment #18 from mikael dot morin at tele2 dot fr 2008-10-28 14:08 --- The final patch is here: http://gcc.gnu.org/ml/fortran/2008-10/msg00104.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35840
[Bug fortran/37930] gfortran error and ICE at automatic type conversion with transfer intrinsic
--- Comment #7 from dominiq at lps dot ens dot fr 2008-10-28 14:36 --- What does ... print? NaN on both ppc/intel-Darwin9. My patch simply fixes the ICE in gfortran. I think the conversion of NaN to int is buggy since the behavior is platform/option dependent. Your patch just prevents to reach the bug. It always make me nervous when a bug is hidden without being understood. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37930
[Bug libgomp/37938] New: libgomp testsuite failures on ia64-linux
In one bootstrap/regtest on 16way Itanium 2 I saw
FAIL: libgomp.c/atomic-4.c execution test
FAIL: libgomp.c/nqueens-1.c execution test
FAIL: libgomp.c/pr29947-1.c execution test
FAIL: libgomp.c/sort-1.c execution test
FAIL: libgomp.c++/task-3.C -O3 -fomit-frame-pointer execution test
FAIL: libgomp.c++/task-3.C -O3 -fomit-frame-pointer -funroll-all-loops
-finline-functions execution test
FAIL: libgomp.c++/task-5.C -O1 execution test
FAIL: libgomp.c++/task-5.C -O3 -g execution test
in another one:
FAIL: libgomp.c/nqueens-1.c execution test
FAIL: libgomp.c/sort-1.c execution test
FAIL: libgomp.c++/collapse-2.C -O2 execution test
FAIL: libgomp.c++/task-3.C -Os execution test
WARNING: program timed out.
FAIL: libgomp.c++/task-5.C -O1 execution test
WARNING: program timed out.
FAIL: libgomp.c++/task-5.C -O2 execution test
Trying atomic-4.c by hand, I see it aborts most of the time and even:
extern void abort (void);
int
main (void)
{
int d = 0;
int i;
#pragma omp parallel for shared (d)
for (i = 0; i 10; i++)
{
GOMP_atomic_start ();
d = d + 1;
GOMP_atomic_end ();
}
if (d != 10)
{
__builtin_printf (d is %d\n, d);
return 1;
}
return 0;
}
fails quite often (with OMP_NUM_THREADS=16 very soon, 50% in the first
invocation, with e.g. OMP_NUM_THREADS=4 less often, but still within first 40
invocations). When it fails (both for original atomic-4.c and this testcase) d
is (slightly) smaller than it should be (say 1 through 10 smaller than
expected), but the test never hangs. If just __sync builtin is used instead of
GOMP_atomic_{start,end} pair (e.g. when double instead of long double is used
in atomic-4.c, or int), then I couldn't reproduce any failures. This happens
both with trunk libgomp and 4.1.2-RH system libgomp. I wonder if we need a
barrier somewhere in ia64 specific code or something.
GOMP_atomic_start just uses gomp_mutex_lock (atomic_lock); and GOMP_atomic_end
gomp_mutex_unlock (atomic_lock);. I haven't seen similar problems on other
arches, so I'm afraid this is ia64 specific.
--
Summary: libgomp testsuite failures on ia64-linux
Product: gcc
Version: 4.4.0
Status: UNCONFIRMED
Keywords: openmp
Severity: normal
Priority: P3
Component: libgomp
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: jakub at gcc dot gnu dot org
GCC target triplet: ia64-linux
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37938
[Bug fortran/37903] [4.3/4.4 Regression] wrong-code for complicated vector subscripts
--- Comment #8 from mikael dot morin at tele2 dot fr 2008-10-28 14:42 --- Created an attachment (id=16573) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16573action=view) second fix This patch solves the problem by releasing the (4) condition, making the loop bounds reset unconditional at the beginning of gfc_trans_create_temp_array. This is harmless because most of the time the loop-from is already zero (there was an assertion for that before PR31610) and the code adds nothing, while in other cases the bounds reset is executed. I had initially a problem though, because then the array indexes for accessing elements of (/1,1,1/) were wrong as the offset for that array was set too early, taking the initial loop bounds into account instead of the later zero-based ones. I looked at what happened in the case of i as its indexes were not miscalculated and found that there was a code for that at the end of gfc_conv_loop_setup. What this patch does is remove the code setting the offset according to the loop in gfc_trans_array_constructor, and allow GFC_SS_CONSTRUCTOR in gfc_conv_loop_setup's code. This patch passes the regression tests without any new failure. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37903
[Bug libgomp/37938] libgomp testsuite failures on ia64-linux
--- Comment #1 from jakub at gcc dot gnu dot org 2008-10-28 15:02 ---
BTW, using + reduction in the same loop (and with asm optimization barrier for
that variable) I see the reduction computed value always correct, so the loop
body is executed the correct number of times. That means in some cases the
memory reads/writes between GOMP_atomic_{start,end} must overlap between
threads.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37938
[Bug fortran/37930] gfortran error and ICE at automatic type conversion with transfer intrinsic
--- Comment #8 from sgk at troutmask dot apl dot washington dot edu 2008-10-28 15:03 --- Subject: Re: gfortran error and ICE at automatic type conversion with transfer intrinsic On Tue, Oct 28, 2008 at 02:36:07PM -, dominiq at lps dot ens dot fr wrote: What does ... print? NaN on both ppc/intel-Darwin9. My patch simply fixes the ICE in gfortran. I think the conversion of NaN to int is buggy since the behavior is platform/option dependent. Your patch just prevents to reach the bug. It always make me nervous when a bug is hidden without being understood. i = NaN is an assignment not a bitwise copy. This isn't platform dependent nor option dependent. You simply can't assign a NaN to an INTEGER. In thinking about transfer(-1,1.0), this may also be invalid because the standard forbids calling an intrinsic procedure if it will return a result outside the representable range of the return type. There is probably some argument on whether NaN is this range. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37930
[Bug c++/37934] show a warning when a symbol is unused and completely removed from the output file
--- Comment #1 from manu at gcc dot gnu dot org 2008-10-28 15:10 --- I think this is just some bit missing in our Wunused. We currently do this for explicit static, so it shouldn't be hard to do it for the implicit one. -- manu at gcc dot gnu dot org changed: What|Removed |Added CC||manu at gcc dot gnu dot org Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2008-10-28 15:10:32 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37934
[Bug target/36568] infinite _Unwind_Backtrace / thread stack unwinding.
--- Comment #7 from pluto at agmk dot net 2008-10-28 15:18 --- (In reply to comment #5) This is a glibc bug then. hmm, Ulrich Drepper rejects this bug report. http://sources.redhat.com/bugzilla/show_bug.cgi?id=6693#c1 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36568
[Bug c++/37936] Conditional operator optimization error with const int
--- Comment #4 from manu at gcc dot gnu dot org 2008-10-28 15:24 --- I can reproduce in vanilla 4.2.4 and 4.1.2 but cannot reproduce in 4.3.2 and trunk. Not sure if this is a regression from 4.0 or earlier but in any case it is fixed in 4.3.2 and mainline and there no more planned releases of the 4.2 branch. -- manu at gcc dot gnu dot org changed: What|Removed |Added CC||manu at gcc dot gnu dot org Status|UNCONFIRMED |RESOLVED Known to fail||4.2.4 4.1.2 Known to work||4.3.2 4.4.0 Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37936
[Bug c++/37933] reference to ... is amibgous: same error shown twice for same line of code
--- Comment #1 from manu at gcc dot gnu dot org 2008-10-28 15:27 --- Confirmed also in mainline. -- manu at gcc dot gnu dot org changed: What|Removed |Added CC||manu at gcc dot gnu dot org Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Keywords||diagnostic Last reconfirmed|-00-00 00:00:00 |2008-10-28 15:27:52 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37933
[Bug c++/37932] narrowing conversion with -std=c++0x
--- Comment #1 from manu at gcc dot gnu dot org 2008-10-28 15:41 --- Jason, what you think about this? In any case, there are some issues with this code: First, it would be better to print the type of the expression (%qT) rather than the expression itself (%qE), because it is informative and in many cases we cannot reconstruct the expression in any sensible way. Also, that function could share a lot of code with conversion_warning in c-common.c. Finally, it is missing a proper comment above it. -- manu at gcc dot gnu dot org changed: What|Removed |Added CC||jason at redhat dot com, ||manu at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37932
[Bug fortran/37930] gfortran error and ICE at automatic type conversion with transfer intrinsic
--- Comment #9 from deji_aking at yahoo dot ca 2008-10-28 15:47 --- (In reply to comment #7) What does ... print? NaN on both ppc/intel-Darwin9. My patch simply fixes the ICE in gfortran. I think the conversion of NaN to int is buggy since the behavior is platform/option dependent. Your patch just prevents to reach the bug. It always make me nervous when a bug is hidden without being understood. When I run program test integer i i = transfer(-1,1.0) print *, i end I get -2147483648 with gcc-4.2, ifort, and pgf90 on x86_64 Linux, and same value with xlf on AIX with power5. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37930
[Bug fortran/37930] gfortran error and ICE at automatic type conversion with transfer intrinsic
--- Comment #10 from sgk at troutmask dot apl dot washington dot edu 2008-10-28 16:19 --- Subject: Re: gfortran error and ICE at automatic type conversion with transfer intrinsic On Tue, Oct 28, 2008 at 03:47:30PM -, deji_aking at yahoo dot ca wrote: --- Comment #9 from deji_aking at yahoo dot ca 2008-10-28 15:47 --- (In reply to comment #7) What does ... print? NaN on both ppc/intel-Darwin9. My patch simply fixes the ICE in gfortran. I think the conversion of NaN to int is buggy since the behavior is platform/option dependent. Your patch just prevents to reach the bug. It always make me nervous when a bug is hidden without being understood. When I run program test integer i i = transfer(-1,1.0) print *, i end I get -2147483648 with gcc-4.2, ifort, and pgf90 on x86_64 Linux, and same value with xlf on AIX with power5. What does program test print *, transfer(-1,1.0) end program test print with those compilers? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37930
[Bug bootstrap/37923] [4.4 Regression] CPPFLAGS now unset for stage 1 build of libcpp files.
--- Comment #24 from howarth at nitro dot med dot uc dot edu 2008-10-28 16:21 --- I still don't understand how the stage1 build of libcpp manages to ignore the CFLAGS setting in the libccp level Makefile. This would suggest that the stage 1 build of libcpp is entirely handled by the toplevel Makefile and the Makefile in libcpp is ignored, no? I only see three instance of CPPFLAGS in the libcpp level Makefile... CPPFLAGS = -I/sw/include ... ALL_CFLAGS = $(CFLAGS) $(WARN_CFLAGS) $(INCLUDES) $(CPPFLAGS) ... COMPILE.base = $(CC) $(DEFS) $(INCLUDES) $(CPPFLAGS) $(ALL_CFLAGS) -c I don't see how, even if CPPFLAGS is unset at the toplevel, that the setting of CPPFLAGS is ignored if the libcpp level Makefile is actually being used in the stage 1 build of libcpp. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37923
[Bug bootstrap/37923] [4.4 Regression] CPPFLAGS now unset for stage 1 build of libcpp files.
--- Comment #25 from bonzini at gnu dot org 2008-10-28 16:28 --- Subject: Re: [4.4 Regression] CPPFLAGS now unset for stage 1 build of libcpp files. You do know that A=B in the command line overrides A=C in the makefile right? :-) Does the patch work? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37923
[Bug bootstrap/37923] [4.4 Regression] CPPFLAGS now unset for stage 1 build of libcpp files.
--- Comment #26 from howarth at nitro dot med dot uc dot edu 2008-10-28 16:34 --- No, I said earlier that the proposed patch doesn't work. Note that INCINTL doesn't even appear in either the toplevel Makefile or the Makefile in intl with your patch. It does appear in the libcpp Makefile but is set to nothing. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37923
[Bug bootstrap/37923] [4.4 Regression] CPPFLAGS now unset for stage 1 build of libcpp files.
--- Comment #27 from bonzini at gnu dot org 2008-10-28 16:39 --- Ah, I missed that. But yes, only libcpp/Makefile is supposed to have INCINTL. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37923
[Bug target/37939] New: [4.2/4.3/4.4 Regression] CRIS port: no addi insn
The CRIS port no longer emits an addi insn for (a N) + b, where N = {1, 2}.
Trivial test-case:
/* Make sure ADDI is combined and emitted successfully.
See also PRX. */
/* { dg-do compile } */
/* { dg-options -O2 } */
/* { dg-final { scan-assembler addi } } */
/* { dg-final { scan-assembler-not lsl } } */
int xyzzy (int r10, int r11)
{
return r11 * 4 + r10;
}
This insn was created and emitted for e.g. 3.2.1
A look at the combine dump shows that the cost for the individual insns is 5
for the shift (the constant counts as 1 as per cris_rtx_costs) and 4 for the
add. However, the combined cost is 10, also as per cris_rtx_costs, because the
insn is (perhaps wrongly) specified as (plus (mult 4 reg1) reg2) and the MULT
cost is 6 as per cris_rtx_costs and the PLUS counts as 4.
The way the target address cost function is called has changed, and
cris_address_cost needs adjustment. Actually, it needs a rewrite, but an
adjustment will do for the 4.3 and 4.4/trunk, being in stage 3.
Patch in progress.
--
Summary: [4.2/4.3/4.4 Regression] CRIS port: no addi insn
Product: gcc
Version: 4.3.3
Status: UNCONFIRMED
Keywords: missed-optimization
Severity: normal
Priority: P3
Component: target
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: hp at gcc dot gnu dot org
GCC host triplet: x86_64-unknown-linux-gnu
GCC target triplet: cris-*-* and crisv32-*-*
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37939
[Bug target/37939] [4.2/4.3/4.4 Regression] CRIS port: no addi insn
-- hp at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |hp at gcc dot gnu dot org |dot org | Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Known to fail||4.3.3 Known to work||3.2.1 Last reconfirmed|-00-00 00:00:00 |2008-10-28 16:51:37 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37939
[Bug target/37939] [4.2/4.3/4.4 Regression] CRIS port: no addi insn
--- Comment #1 from hp at gcc dot gnu dot org 2008-10-28 16:54 --- Forgot to mention that combine simplifies the ASHIFT to a MULT, despite not being in an address. The corresponding address mode exists, and having the same shape for both the separate insns and the addressing mode serves the purpose for the time being, but it might be seen as an RTX canonicalization bug on part of the combine pass. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37939
[Bug bootstrap/37923] [4.4 Regression] CPPFLAGS now unset for stage 1 build of libcpp files.
--- Comment #28 from howarth at nitro dot med dot uc dot edu 2008-10-28 16:55 --- Doh, it may be an issue with the fink packaging system. They have a command... NoSetCPPFLAGS: True which I assumed was unsetting CPPFLAGS within fink but it very well may be just setting CPPFLAGS to a null string. I'll remove that and substitute the use of unsetenv CPPFLAGS instead. I update the bug report later this evening with the results. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37923
[Bug target/37939] [4.2/4.3/4.4 Regression] CRIS port: no addi insn
--- Comment #2 from hp at gcc dot gnu dot org 2008-10-28 16:56 --- ...and the ASHIFT is what is incoming to combine, despite there being a multiplication in the code, all fine and by definition. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37939
[Bug fortran/37930] gfortran error and ICE at automatic type conversion with transfer intrinsic
--- Comment #11 from deji_aking at yahoo dot ca 2008-10-28 17:07 --- (In reply to comment #10) Subject: Re: gfortran error and ICE at automatic type conversion with transfer intrinsic When I run program test integer i i = transfer(-1,1.0) print *, i end I get -2147483648 with gcc-4.2, ifort, and pgf90 on x86_64 Linux, and same value with xlf on AIX with power5. What does program test print *, transfer(-1,1.0) end program test print with those compilers? NaN with all the compilers on x86_64 Linux and -NaNQ with xlf on power5 AIX. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37930
[Bug fortran/37903] [4.3/4.4 Regression] wrong-code for complicated vector subscripts
--- Comment #9 from dominiq at lps dot ens dot fr 2008-10-28 17:18 --- The patch in comment #8 works as expected on my tests and regtest without regression but conflicts with the patch for pr35681 in http://gcc.gnu.org/ml/fortran/2008-10/msg00256.html. Some synchronization seems needed. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37903
[Bug fortran/35810] [TR 15581 / F2003] Automatic reallocation on assignment to allocatable variables
--- Comment #2 from burnus at gcc dot gnu dot org 2008-10-28 17:37 --- Segfault with return values of allocatable functions. A code which does not work is the following TR15581-conform program. It seqfaults (SIGABRT) and valgrind shows errors of the kind: ==12853== Invalid write of size 4 ==12853==at 0x400966: MAIN__ (aa.f90:7) ==12853== Address 0x58e7b4c is 0 bytes after a block of size 4 alloc'd ==12853==at 0x4C256AE: malloc (in /usr/lib64/valgrind/amd64-linux/vgpreload_memcheck.so) ==12853==by 0x4008A4: MAIN__ (aa.f90:4) Test case: implicit none integer,allocatable :: j(:) integer :: i allocate(j(1)) do i = 1,20 ! deallocate(j) j = alloc() end do contains function alloc() integer, allocatable :: alloc(:) allocate(alloc(1)) end function end -- burnus at gcc dot gnu dot org changed: What|Removed |Added Severity|enhancement |normal Keywords||wrong-code Summary|[F2003] Automatic |[TR 15581 / F2003] Automatic |reallocation on assignment |reallocation on assignment |to allocatable variables|to allocatable variables http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35810
[Bug fortran/37930] gfortran error and ICE at automatic type conversion with transfer intrinsic
--- Comment #12 from dominiq at lps dot ens dot fr 2008-10-28 17:51 --- (In reply to comment #8) i = NaN is an assignment not a bitwise copy. This isn't platform dependent nor option dependent. You simply can't assign a NaN to an INTEGER. Before the assignment, there is an attempt to convert the real 'NaN' to a default integer. This conversion is platform dependent. Now consider the following code: i = -huge(1.0) print *, i, -huge(1.0) end which compiles without problem with the option -fno-range-check and gives at run time: 0 -3.40282347E+38 Is -3.40282347E+38 more valid than NaN or -Inf? Or is that the extension has not been defined for the later real values? In thinking about transfer(-1,1.0), this may also be invalid because the standard forbids calling an intrinsic procedure if it will return a result outside the representable range of the return type. There is probably some argument on whether NaN is this range. My point of view has always been that +/-Inf and NaN's should abort the executable, but I seems alone to think so! I also find very weird to assign transfer(integer, real) to an integer. I don't see the logic of this construct: what is it supposed to do? Note also that the behavior of gfortran is not consistent, as shown by the following test: [ibook-dhum] f90/bug% cat pr37930_db_1.f90 r = transfer(-1,1.0) i = r print *, i end [ibook-dhum] f90/bug% gfc pr37930_db_1.f90 [ibook-dhum] f90/bug% a.out -2147483648 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37930
[Bug libfortran/37839] st_parameter_dt has unwanted padding, is out of sync with compiler
--- Comment #9 from sje at cup dot hp dot com 2008-10-28 18:26 --- Further investigation shows that it is not the size of common that is the problem. The bug is related to the new union of st_parameter_43 and st_parameter_44. Specifically, st_parameter_44 contains pos which is type GFC_IO_INT which is 8 bytes on IA64 and requires an 8 byte alignment. This causes the entire st_parameter_44 structure to require 8 byte alignment and the union that it is part of to require 8 byte alignment. This changes the layout/offset of fields in the p and q parts of the st_parameter_dt structure. The compiler definition of st_parameter_dt, created from ioparm.def, does not know anything about the union that is used in the library and just lays out the fields as if there was no *_44 structure and no union and this layout is then different then the library layout. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37839
[Bug fortran/37903] [4.3/4.4 Regression] wrong-code for complicated vector subscripts
--- Comment #10 from mikael dot morin at tele2 dot fr 2008-10-28 18:27 --- Created an attachment (id=16574) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16574action=view) first fix This patch tries to solve the problem by changing the (2) condition. It tries to use an ss whose starting value is zero when there is one (In this case it is that of (/1,1,1/)). The regression tests pass with both this patch applied and that one http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31610#c21 reverted (ICEing is better than wrong-coding). I was initially dissatisfied by this patch as it was not changing the beginning of gfc_trans_create_temp_array, which was leaving room for another case where the loop would not start at zero. I failed to find such a case though. However, I believe it is still valuable as it produces a (just a little) better code (see array indexes) than the other one. Now I suggest we apply both patches. Any comments ? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37903
[Bug c/37940] New: no error detected for semicolon in C function declaration
The following code has an extra semi-colon at the end of the function prototype
declaring bad_func1:
void bad_func1 (unsigned long long arg1, const char *arg2 ; );
void bad_func2 ()
{
const char *foo = foo;
bad_func1 (0, foo);
}
GCC 3.4 reports an error:
elm3b187% /home/janis/tools/gcc-3.4-anonsvn/bin/gcc -c bug.c
bug.c:1: error: parameter arg1 has just a forward declaration
bug.c:1: error: parameter arg2 has just a forward declaration
GCC 4.0 and later (including current mainline) accept the code with no error or
warning, even with -Wall, and generate code as if the prototype did not exist
rather than generating code as if the semicolon did not exist.
--
Summary: no error detected for semicolon in C function
declaration
Product: gcc
Version: 4.0.0
Status: UNCONFIRMED
Keywords: accepts-invalid
Severity: normal
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: janis at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37940
[Bug fortran/37930] gfortran error and ICE at automatic type conversion with transfer intrinsic
--- Comment #13 from sgk at troutmask dot apl dot washington dot edu 2008-10-28 18:40 --- Subject: Re: gfortran error and ICE at automatic type conversion with transfer intrinsic On Tue, Oct 28, 2008 at 05:51:06PM -, dominiq at lps dot ens dot fr wrote: i = NaN is an assignment not a bitwise copy. This isn't platform dependent nor option dependent. You simply can't assign a NaN to an INTEGER. Before the assignment, there is an attempt to convert the real 'NaN' to a default integer. i = 1.23456 -- i = 1 i = 3.14149 -- i = 3 i = NaN -- i = what goes here? This conversion is platform dependent. Now consider the following code: i = -huge(1.0) print *, i, -huge(1.0) end which compiles without problem with the option -fno-range-check and gives at As soon as you used the -fno-range-check option, you are telling gfortran to violate the standard. gfortran can do whatever it pleases. troutmask:kargl[213] gfc -o z -fno-range-check -fdump-parse-tree j.f90 ASSIGN MAIN__:i 340282346638528859811704183484516925440 WRITE UNIT=6 FMT=-1 TRANSFER MAIN__:i TRANSFER 3.40282347e38 DT_END Looks like the well-known integer wrap around issue. What is mod(34028..., 2^32)? Could also be 2^31 - 1; too lazy to investigate any farther. run time: 0 -3.40282347E+38 Is -3.40282347E+38 more valid than NaN or -Inf? Or is that the extension has not been defined for the later real values? What happens without -fno-range-check? In thinking about transfer(-1,1.0), this may also be invalid because the standard forbids calling an intrinsic procedure if it will return a result outside the representable range of the return type. There is probably some argument on whether NaN is this range. My point of view has always been that +/-Inf and NaN's should abort the executable, but I seems alone to think so! See -ffpe-trap option. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37930
[Bug fortran/37926] Program gives wrong output (connected to char len)
--- Comment #2 from pault at gcc dot gnu dot org 2008-10-28 18:42 ---
(In reply to comment #1)
Tobias,
Isn't the problem the following?
parm.22.dim[0].lbound = 1;
parm.22.dim[0].ubound = D.1616;
parm.22.dim[0].stride = NON_LVALUE_EXPR D.1622;
parm.22.data = (void *) (*ifm.21)[0];
parm.22.offset = NON_LVALUE_EXPR D.1621;
D.1623 = _gfortran_internal_pack (parm.22); / void* result /
D.1625 = mysize (D.1623); / mysize expects struct
array1_integer(kind=4) a /
D.1627 = MAX_EXPR D.1625, 0 * 64;
if (D.1627 0)
{
_gfortran_runtime_error (Attempt to allocate a negative amount of
memory.[1]{lb: 1 sz: 1});
}
D.1628 = __builtin_malloc (MAX_EXPR (integer(kind=8)) D.1627, 1);
if (D.1628 == 0B)
{
_gfortran_os_error (Memory allocation failed[1]{lb: 1 sz: 1});
}
pstr.23 = (character(kind=1)[1:MAX_EXPR D.1625, 0] *) D.1628;
p (pstr.23, MAX_EXPR D.1625, 0, D.1614, mysize);
Thus it's the internal_pack that does this in.
Paul
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37926
[Bug fortran/37903] [4.3/4.4 Regression] wrong-code for complicated vector subscripts
--- Comment #11 from mikael dot morin at tele2 dot fr 2008-10-28 18:43 --- (In reply to comment #9) Some synchronization seems needed. Well, may patch is made against trunk, so I will leave it as is for now. If Daniel commits his patch for PR35861, I can provide an updated patch. I quickly looked at it, and it should be rather straightforward (it looks like a tabs problem only). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37903
[Bug fortran/37903] [4.3/4.4 Regression] wrong-code for complicated vector subscripts
--- Comment #12 from domob at gcc dot gnu dot org 2008-10-28 18:46 --- (In reply to comment #11) Well, may patch is made against trunk, so I will leave it as is for now. If Daniel commits his patch for PR35861, I can provide an updated patch. I quickly looked at it, and it should be rather straightforward (it looks like a tabs problem only). I do think it is a trivial merge, too. But as discussed with Dominique on IRC, I think we could also review and check-in your patch prior to mine, as it is simpler and might get review faster. Then I'd do the merge. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37903
[Bug fortran/37930] gfortran error and ICE at automatic type conversion with transfer intrinsic
--- Comment #14 from burnus at gcc dot gnu dot org 2008-10-28 18:56 --- When I run program test integer i i = transfer(-1,1.0) print *, i end I get -2147483648 with gcc-4.2, ifort, and pgf90 on x86_64 Linux, and same value with xlf on AIX with power5. Ditto for openf95. g95 warns (integer overflow) and prints 0; NAG f95 gives an Error: Result of TRANSFER is Not a Number. At run time, gfortran, g95 and NAG f95 (w/ IEEE exceptions disabled) processes it and print -2147483648. I agree with Steve that assigning NaN and INF to an integer does not make sense. What integer matches NaN - none! One can assign the bit pattern of NaN, i.e. i = transfer(NaN, 0) but that is something completely different and well defined. NAG's arithmetic exception also makes sense. Steve wrote: In thinking about transfer(-1,1.0), this may also be invalid With Fortran 2003's IEEE support the latter should be valid (if a given processor supports the needed IEEE features and similar restrictions). Dominque wrote: I think the conversion of NaN to int is buggy since the behavior is platform/option dependent. Your patch just prevents to reach the bug. It always make me nervous when a bug is hidden without being understood. I think such an investigation makes sense in general but for the error message gmp: overflow in mpz type it might not be needed: It simply states that MPFR/GMP does not like the conversion. If there are any other code paths, the patch does not make it more likely that they are hit. From the patch: + gfc_error (Conversion of exceptional value at %L, where); I don't like this error message - when I read it I don't understand the meaning of exceptional. How about something like the following: - Conversion of non-representable value (NaN or Infinity) at %L - Conversion of non-representable value at %L - Conversion of NaN or Infinity at %L - Conversion of Not-a-Number or Infinity at %L or ... ? Dominique just wrote: Is -3.40282347E+38 more valid than NaN or -Inf? I believe it is. You can convert -3.40282347E+38 into an integer and you get: -34028234700. You can now assign that integer to your integer variable. You probably loose some digits as the variable is too small (overflows but actually it is rather a cut off of digits, ignoring the sign bit for the moment). But which integer matches INF? 9 with infinitely many trailing 9s. Or do you prefer to have 1 with infinitely many trailing 0s. Depending what you choose and taking the last n bits you get different values for your variable. And for NaN: I frankly have no idea to what integer this is supposed to match. If you talk about bit patterns the situation is completely different. You can assign the bit pattern of NaN to any integer, real, logical etc. variable if you want. For instance transfer(-1, 0.0) is a perfectly fine real number, which you also may assign to any other real or complex number. You may also TRANSFER it bitwise to an integer number (which gives the number you started with: -1). But if you try to assign the number, you are in trouble (see above). --- From comment 1: Adw_xabcd_8(1:n) = transfer(-1,1.0) ! Adw_xabcd_8 is REAL That makes sense: One assigns NaN to a real variable (though a comment would be helpful). However Adw_Fn_I (n) = transfer(-1,1.0) ! Adw_Fn_I is an INTEGER does not make sense as there is no NaN for integers. Here, one could have used -HUGE(Adw_Fn_I) or similar. I think the programmer simply missed that Adw_Fn_I is no real variable; as long as compiler digest this number it does its purpose - initializing the variable with garbage, but syntactically it does not make sense - and a compiler has all rights to reject it. -- burnus at gcc dot gnu dot org changed: What|Removed |Added CC||burnus at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37930
[Bug c/37924] [4.2/4.3/4.4 Regression] ice in smallest_mode_for_size, at stor-layout.c:219
--- Comment #5 from jakub at gcc dot gnu dot org 2008-10-28 19:04 --- Subject: Bug 37924 Author: jakub Date: Tue Oct 28 19:02:36 2008 New Revision: 141413 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=141413 Log: PR c/37924 * combine.c (make_compound_operation): Don't call make_extraction with non-positive length. (simplify_shift_const_1): Canonicalize count even if complement_p. * gcc.c-torture/execute/pr37924.c: New test. Added: trunk/gcc/testsuite/gcc.c-torture/execute/pr37924.c Modified: trunk/gcc/ChangeLog trunk/gcc/combine.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37924
[Bug c/37924] [4.2/4.3 Regression] ice in smallest_mode_for_size, at stor-layout.c:219
--- Comment #6 from jakub at gcc dot gnu dot org 2008-10-28 19:06 --- Fixed in 4.4 so far. -- jakub at gcc dot gnu dot org changed: What|Removed |Added Known to fail|4.2.4 4.3.2 4.4.0 |4.2.4 4.3.2 Known to work|4.1.2 |4.1.2 4.4.0 Summary|[4.2/4.3/4.4 Regression] ice|[4.2/4.3 Regression] ice in |in smallest_mode_for_size, |smallest_mode_for_size, at |at stor-layout.c:219|stor-layout.c:219 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37924
[Bug tree-optimization/37663] [4.4 Regression] ice in simplify_truth_ops_using_ranges, at tree-vrp.c:6335
--- Comment #4 from eric dot weddington at atmel dot com 2008-10-28 19:56 --- Reopening bug. New test case gcc.dg/pr37663.c fails for AVR with: /usr/local/avrdev/gcc/gcc/gcc/testsuite/gcc.dg/pr37663.c: In function 'foo': /usr/local/avrdev/gcc/gcc/gcc/testsuite/gcc.dg/pr37663.c:11: warning: overflow in implicit constant conversion Line 11: int y = -1885403717; This test case assumes that an int is 32 bits. An int is 16 bits on AVR. -- eric dot weddington at atmel dot com changed: What|Removed |Added Status|RESOLVED|REOPENED GCC target triplet|i686-pc-linux-gnu |i686-pc-linux-gnu avr-*-* Resolution|FIXED | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37663
[Bug middle-end/37943] New: [graphite] ICE : in build_graphite_scops, at graphite.c:1823
gcc -c -O3 -floop-block test_graphite.c test_graphite.c: In function 'compress': test_graphite.c:17: internal compiler error: in build_graphite_scops, at graphite.c:1823 Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html for instructions. -- Summary: [graphite] ICE : in build_graphite_scops, at graphite.c:1823 Product: gcc Version: 4.4.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: middle-end AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: mitul dot thakkar at amd dot com GCC build triplet: x86_64-unknown-linux-gnu GCC host triplet: x86_64-unknown-linux-gnu GCC target triplet: x86_64-unknown-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37943
[Bug middle-end/37943] [graphite] ICE : in build_graphite_scops, at graphite.c:1823
--- Comment #1 from mitul dot thakkar at amd dot com 2008-10-28 20:05 --- Created an attachment (id=16575) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16575action=view) Reduced Test Case -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37943
[Bug tree-optimization/37663] [4.4 Regression] ice in simplify_truth_ops_using_ranges, at tree-vrp.c:6335
--- Comment #5 from jakub at gcc dot gnu dot org 2008-10-28 20:07 --- Subject: Bug 37663 Author: jakub Date: Tue Oct 28 20:06:08 2008 New Revision: 141414 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=141414 Log: PR tree-optimization/37663 * gcc.dg/pr37663.c: Require int32plus. Modified: trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gcc.dg/pr37663.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37663
[Bug tree-optimization/37663] [4.4 Regression] ice in simplify_truth_ops_using_ranges, at tree-vrp.c:6335
--- Comment #6 from jakub at gcc dot gnu dot org 2008-10-28 20:09 --- Next time, please don't reopen the original PR. Whether the test fails on avr or not doesn't have anything to do with the fact that the original bug has been fixed. IMHO either open a new PR and link it to the original PR, or (preferrably) just submit a patch to gcc-patches to modify the testcase. -- jakub at gcc dot gnu dot org changed: What|Removed |Added Status|REOPENED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37663
[Bug target/37944] New: [4.4 Regression] FAIL: gcc.dg/pr33645-3.c scan-assembler-not var1_t
Regression test failure: FAIL: gcc.dg/pr33645-3.c scan-assembler-not var1_t Executing on host: /usr/local/avrdev/gcc/build/gcc/xgcc -B/usr/local/avrdev/gcc/build/gcc/ /usr/local/avrdev/gcc/gcc/gcc/testsuite/gcc.dg/pr33645-3.c -O2 -fno-unit-at-a-time -DSTACK_SIZE=2048 -DNO_TRAMPOLINES -S -DSIGNAL_SUPPRESS -mmcu=atmega128 -o pr33645-3.s(timeout = 300) PASS: gcc.dg/pr33645-3.c (test for excess errors) FAIL: gcc.dg/pr33645-3.c scan-assembler-not var1_t Known success on 2008-09-02 trunk revision 139891 Known fail on 2008-09-04 trunk revision 139992 Still fails on trunk revision 141408 -- Summary: [4.4 Regression] FAIL: gcc.dg/pr33645-3.c scan- assembler-not var1_t Product: gcc Version: 4.4.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: eric dot weddington at atmel dot com GCC target triplet: avr-*-* http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37944
[Bug fortran/37930] gfortran error and ICE at automatic type conversion with transfer intrinsic
--- Comment #16 from burnus at gcc dot gnu dot org 2008-10-28 20:15 --- Well, I think it may be more complicated. Have I mentioned how much I hate TRANSFER. :( Well, I didn't do much with TRANSFER, but I fully understand you. To make matters worse, with trunk I see call sub(x,0.) i = x NaN -2147483648 FFC0 Looks OK to me as run-time behaviour. If you want to catch this, simply compile gfortran with -ffpe-trap=invalid. gfc_mpfr_to_mpz but also gfc_real2int and gfc_complex2int. I don't think so. You have in gfc_real2int the call: gfc_mpfr_to_mpz (result-value.integer, src-value.real); and in gfc_complex2int you have gfc_mpfr_to_mpz (result-value.integer, src-value.complex.r); Thus you really only need to modify gfc_mpfr_to_mpz. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37930
[Bug c/37940] no error detected for semicolon in C function declaration
--- Comment #1 from jsm28 at gcc dot gnu dot org 2008-10-28 20:25 --- *** This bug has been marked as a duplicate of 23144 *** -- jsm28 at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37940
[Bug c/23144] [4.2/4.3/4.4 Regression] invalid parameter forward declarations not diagnosed
--- Comment #9 from jsm28 at gcc dot gnu dot org 2008-10-28 20:25 --- *** Bug 37940 has been marked as a duplicate of this bug. *** -- jsm28 at gcc dot gnu dot org changed: What|Removed |Added CC||janis at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23144
[Bug ada/37945] New: GNAT Sockaddr and Sockaddr_In does not match c-structures on RTEMS
RTEMS has FreeBSD style structures: Sockaddr and Sockaddr_In should have the 8bit Len and Family variable instead of 16 family in gcc/ada/socthi.ads. Bug prevents at least binding local address to socket, connecting tcp socket or sending udp data. diff g-socthi.ads g-socthi-rtems.ads 145c145,146 Sa_Family : C.unsigned_short; --- Sa_Len: C.unsigned_char; Sa_Family : C.unsigned_char; 156c157,158 Sin_Family : C.unsigned_short := Constants.AF_INET; --- Sin_Len: C.unsigned_char := 0; Sin_Family : C.unsigned_char := Constants.AF_INET; diff g-socthi.adb g-socthi-rtems.adb 451c451 Sin.Sin_Family := C.unsigned_short (Family); --- Sin.Sin_Family := C.unsigned_char (Family); -- Summary: GNAT Sockaddr and Sockaddr_In does not match c- structures on RTEMS Product: gcc Version: 4.3.2 Status: UNCONFIRMED Severity: blocker Priority: P3 Component: ada AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: petri dot rokka at tut dot fi http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37945
[Bug target/37944] [4.4 Regression] FAIL: gcc.dg/pr33645-3.c scan-assembler-not var1_t
--- Comment #1 from jakub at gcc dot gnu dot org 2008-10-28 21:37 --- *** This bug has been marked as a duplicate of 37339 *** -- jakub at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37944
[Bug middle-end/37339] [4.4 Regression] gcc.dg/pr33645-3.c scan-assembler-not var1_t
--- Comment #3 from jakub at gcc dot gnu dot org 2008-10-28 21:37 --- *** Bug 37944 has been marked as a duplicate of this bug. *** -- jakub at gcc dot gnu dot org changed: What|Removed |Added CC||eric dot weddington at atmel ||dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37339
[Bug ada/37945] GNAT Sockaddr and Sockaddr_In does not match c-structures on RTEMS
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||pinskia at gcc dot gnu dot ||org Severity|blocker |normal http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37945
[Bug middle-end/37339] [4.4 Regression] gcc.dg/pr33645-3.c scan-assembler-not var1_t
--- Comment #4 from sje at cup dot hp dot com 2008-10-28 21:51 --- I have posted a patch in which I propose removing this test. It has not gotten any feedback yet. http://gcc.gnu.org/ml/gcc-patches/2008-10/msg00826.html -- sje at cup dot hp dot com changed: What|Removed |Added URL||http://gcc.gnu.org/ml/gcc- ||patches/2008- ||10/msg00826.html http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37339
[Bug ada/37945] GNAT Sockaddr and Sockaddr_In does not match c-structures on RTEMS
--- Comment #1 from joel at gcc dot gnu dot org 2008-10-28 22:00 --- This does not impact the SVN trunk. This requires adding g-socthi-rtems.ads and corresponding Makefile.in change. I will prepare and test a complete patch. We wondered if this is broken for FreeBSD as well. We use the FreeBSD TCP/IP stack in RTEMS and it should be broken the same way. Can someone confirm that? -- joel at gcc dot gnu dot org changed: What|Removed |Added Severity|normal |blocker http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37945
[Bug target/37878] [4.4 regression] PPC64 ldu command generated with invalid offset
--- Comment #11 from dje at gcc dot gnu dot org 2008-10-28 22:35 --- Created an attachment (id=16576) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16576action=view) disallow illegal displacement wrapped in PRE_MODIFY or PRE_INC/DEC I think this patch accomplishes the effect but easier to follow with the address form localized in one place. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37878
[Bug target/37878] [4.4 regression] PPC64 ldu command generated with invalid offset
--- Comment #12 from dje at gcc dot gnu dot org 2008-10-28 23:13 --- Created an attachment (id=16577) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16577action=view) another refinement Jakub suggested a further refinement to hoist a common sub-expression. -- dje at gcc dot gnu dot org changed: What|Removed |Added Attachment #16576|0 |1 is obsolete|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37878
[Bug testsuite/37241] [4.4 Regression]: FAIL: g++.dg/abi/key2.C
--- Comment #3 from pinskia at gcc dot gnu dot org 2008-10-28 23:22 --- The section does not change so there is no need for the .section in the scan-assembler: .globl __ZTV1f .weak_definition __ZTV1f .section __DATA,__const_coal,coalesced .align 3 __ZTV1f: .long 0 .long __ZTI1f .long __ZN1f1gEv .long __ZN1f1hEv .globl __ZTI1f .weak_definition __ZTI1f .align 2 __ZTI1f: -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Component|target |testsuite GCC build triplet|*-apple-darwin* | GCC host triplet|*-apple-darwin* | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37241
[Bug c++/37946] New: ICE with enum class
Following (valid I believe) code causes internal compiler error:
enum class E : char
{
e1,
e2
};
inline E operator| (E a1, E a2)
{
char ret = static_castchar (a1)
| static_castchar (a2);
return static_castE(ret);
}
g++-4.4.0-alpha20081010 -v -c -std=c++0x enum_class_ice.cc
Using built-in specs.
Target: i686-pc-linux-gnu
Configured with:
/var/tmp/paludis/sys-devel-gcc-4.4.0_alpha20081010/work/gcc-4.4-20081010/configure
--prefix=/usr --bindir=/usr/i686-pc-linux-gnu/gcc-bin/4.4.0-alpha20081010
--includedir=/usr/lib/gcc/i686-pc-linux-gnu/4.4.0-alpha20081010/include
--datadir=/usr/share/gcc-data/i686-pc-linux-gnu/4.4.0-alpha20081010
--mandir=/usr/share/gcc-data/i686-pc-linux-gnu/4.4.0-alpha20081010/man
--infodir=/usr/share/gcc-data/i686-pc-linux-gnu/4.4.0-alpha20081010/info
--with-gxx-include-dir=/usr/lib/gcc/i686-pc-linux-gnu/4.4.0-alpha20081010/include/g++-v4
--host=i686-pc-linux-gnu --build=i686-pc-linux-gnu --disable-altivec
--enable-nls --without-included-gettext --with-system-zlib --disable-checking
--disable-werror --enable-secureplt --disable-multilib --enable-libmudflap
--disable-libssp --enable-cld --disable-libgcj --with-arch=i686
--enable-languages=c,c++ --enable-shared --enable-threads=posix
--enable-__cxa_atexit --enable-clocale=gnu
--with-bugurl=http://bugs.gentoo.org/ --with-pkgversion='Gentoo
4.4.0_alpha20081010'
Thread model: posix
gcc version 4.4.0-alpha20081010 (experimental) (Gentoo 4.4.0_alpha20081010)
COLLECT_GCC_OPTIONS='-v' '-c' '-std=c++0x' '-E' '-shared-libgcc'
'-mtune=generic' '-march=i686'
/usr/libexec/gcc/i686-pc-linux-gnu/4.4.0-alpha20081010/cc1plus -E -quiet -v
-D_GNU_SOURCE enum_class_ice.cc -mtune=generic -march=i686 -std=c++0x
ignoring nonexistent directory /usr/local/include
ignoring nonexistent directory
/usr/lib/gcc/i686-pc-linux-gnu/4.4.0-alpha20081010/../../../../i686-pc-linux-gnu/include
#include ... search starts here:
#include ... search starts here:
/usr/lib/gcc/i686-pc-linux-gnu/4.4.0-alpha20081010/include/g++-v4
/usr/lib/gcc/i686-pc-linux-gnu/4.4.0-alpha20081010/include/g++-v4/i686-pc-linux-gnu
/usr/lib/gcc/i686-pc-linux-gnu/4.4.0-alpha20081010/include/g++-v4/backward
/usr/lib/gcc/i686-pc-linux-gnu/4.4.0-alpha20081010/include
/usr/lib/gcc/i686-pc-linux-gnu/4.4.0-alpha20081010/include-fixed
/usr/include
End of search list.
COMPILER_PATH=/usr/libexec/gcc/i686-pc-linux-gnu/4.4.0-alpha20081010/:/usr/libexec/gcc/i686-pc-linux-gnu/4.4.0-alpha20081010/:/usr/libexec/gcc/i686-pc-linux-gnu/:/usr/lib/gcc/i686-pc-linux-gnu/4.4.0-alpha20081010/:/usr/lib/gcc/i686-pc-linux-gnu/:/usr/libexec/gcc/i686-pc-linux-gnu/4.4.0-alpha20081010/:/usr/libexec/gcc/i686-pc-linux-gnu/:/usr/lib/gcc/i686-pc-linux-gnu/4.4.0-alpha20081010/:/usr/lib/gcc/i686-pc-linux-gnu/:/usr/lib/gcc/i686-pc-linux-gnu/4.4.0-alpha20081010/../../../../i686-pc-linux-gnu/bin/
LIBRARY_PATH=/usr/lib/gcc/i686-pc-linux-gnu/4.4.0-alpha20081010/:/usr/lib/gcc/i686-pc-linux-gnu/4.4.0-alpha20081010/:/usr/lib/gcc/i686-pc-linux-gnu/4.4.0-alpha20081010/../../../../i686-pc-linux-gnu/lib/:/usr/lib/gcc/i686-pc-linux-gnu/4.4.0-alpha20081010/../../../:/lib/:/usr/lib/
COLLECT_GCC_OPTIONS='-v' '-c' '-std=c++0x' '-E' '-shared-libgcc'
'-mtune=generic' '-march=i686'
Using built-in specs.
Target: i686-pc-linux-gnu
Configured with:
/var/tmp/paludis/sys-devel-gcc-4.4.0_alpha20081010/work/gcc-4.4-20081010/configure
--prefix=/usr --bindir=/usr/i686-pc-linux-gnu/gcc-bin/4.4.0-alpha20081010
--includedir=/usr/lib/gcc/i686-pc-linux-gnu/4.4.0-alpha20081010/include
--datadir=/usr/share/gcc-data/i686-pc-linux-gnu/4.4.0-alpha20081010
--mandir=/usr/share/gcc-data/i686-pc-linux-gnu/4.4.0-alpha20081010/man
--infodir=/usr/share/gcc-data/i686-pc-linux-gnu/4.4.0-alpha20081010/info
--with-gxx-include-dir=/usr/lib/gcc/i686-pc-linux-gnu/4.4.0-alpha20081010/include/g++-v4
--host=i686-pc-linux-gnu --build=i686-pc-linux-gnu --disable-altivec
--enable-nls --without-included-gettext --with-system-zlib --disable-checking
--disable-werror --enable-secureplt --disable-multilib --enable-libmudflap
--disable-libssp --enable-cld --disable-libgcj --with-arch=i686
--enable-languages=c,c++ --enable-shared --enable-threads=posix
--enable-__cxa_atexit --enable-clocale=gnu
--with-bugurl=http://bugs.gentoo.org/ --with-pkgversion='Gentoo
4.4.0_alpha20081010'
Thread model: posix
gcc version 4.4.0-alpha20081010 (experimental) (Gentoo 4.4.0_alpha20081010)
COLLECT_GCC_OPTIONS='-v' '-c' '-std=c++0x' '-o'
'/home/prak/.ccache/tmp.hash.sandra.23558.o' '-shared-libgcc' '-mtune=generic'
'-march=i686'
/usr/libexec/gcc/i686-pc-linux-gnu/4.4.0-alpha20081010/cc1plus -fpreprocessed
/home/prak/.ccache/enum_class.tmp.sandra.23558.ii -quiet -dumpbase
enum_class.tmp.sandra.23558.ii -mtune=generic -march=i686 -auxbase-strip
/home/prak/.ccache/tmp.hash.sandra.23558.o -std=c++0x -version -o
/tmp/ccpib1aZ.s
GNU C++ (Gentoo 4.4.0_alpha20081010) version 4.4.0-alpha20081010
(experimental) (i686-pc-linux-gnu)
compiled by GNU C version 4.4.0-alpha20081010
[Bug testsuite/37241] [4.4 Regression]: FAIL: g++.dg/abi/key2.C
--- Comment #4 from jakub at gcc dot gnu dot org 2008-10-28 23:33 --- Not P1, as it is just a testcase issue, not compiler bug. -- jakub at gcc dot gnu dot org changed: What|Removed |Added Priority|P1 |P2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37241
[Bug c++/37946] ICE with enum class
--- Comment #1 from piotr dot rak at gmail dot com 2008-10-28 23:35 --- Created an attachment (id=16578) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16578action=view) Test case -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37946
[Bug bootstrap/37923] [4.4 Regression] CPPFLAGS now unset for stage 1 build of libcpp files.
--- Comment #29 from howarth at nitro dot med dot uc dot edu 2008-10-28 23:37 --- I have verified that the fink build system wasn't in fact setting CPPFLAGS to null or anything else. So this problem is real when CPPFLAGS doesn't exist, -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37923
[Bug c/37947] New: p-count += inc(p); // value of p-count is wrong, if inc(p) not only returns an int but also increases p-counter
The following programm prints out 1, it should print 4 (like it does with
gcc-3.3.6:
// Start of test.c
#include stdlib.h
#include stdio.h
struct test
{
unsigned long counter;
};
unsigned long inc(struct test *tp)
{
tp-counter += 3;
return 1;
}
int main()
{
struct test *p;
p = (struct test*) malloc(sizeof(struct test));
p-counter = 0;
p-counter += inc(p);
printf(%ld\n, p-counter);
free(p);
return 0;
}
// End of test.c
The following programm is not affected and prints out 4:
// Start of test2.c
#include stdlib.h
#include stdio.h
unsigned long inc(unsigned long *c)
{
*c += 3;
return 1;
}
int main()
{
unsigned long counter;
counter = 0;
counter += inc(counter);
printf(%ld\n, counter);
return 0;
}
// End of test2.c
// Start output of gcc -v -save-temps -Wall test.c
Using built-in specs.
Target: i686-pc-linux-gnu
Configured with:
/home/portage/portage/sys-devel/gcc-4.1.2/work/gcc-4.1.2/configure
--prefix=/usr --bindir=/usr/i686-pc-linux-gnu/gcc-bin/4.1.2
--includedir=/usr/lib/gcc/i686-pc-linux-gnu/4.1.2/include
--datadir=/usr/share/gcc-data/i686-pc-linux-gnu/4.1.2
--mandir=/usr/share/gcc-data/i686-pc-linux-gnu/4.1.2/man
--infodir=/usr/share/gcc-data/i686-pc-linux-gnu/4.1.2/info
--with-gxx-include-dir=/usr/lib/gcc/i686-pc-linux-gnu/4.1.2/include/g++-v4
--host=i686-pc-linux-gnu --build=i686-pc-linux-gnu --disable-altivec
--enable-nls --without-included-gettext --with-system-zlib --disable-checking
--disable-werror --enable-secureplt --disable-libunwind-exceptions
--disable-multilib --enable-libmudflap --disable-libssp --enable-java-awt=gtk
--with-arch=i686 --enable-languages=c,c++,java,treelang,fortran --enable-shared
--enable-threads=posix --enable-__cxa_atexit --enable-clocale=gnu
--with-bugurl=http://bugs.gentoo.org/ --with-pkgversion=Gentoo 4.1.2 p1.1
Thread model: posix
gcc version 4.1.2 (Gentoo 4.1.2 p1.1)
/usr/libexec/gcc/i686-pc-linux-gnu/4.1.2/cc1 -E -quiet -v test.c -march=i686
-Wall -fpch-preprocess -o test.i
ignoring nonexistent directory /usr/local/include
ignoring nonexistent directory
/usr/lib/gcc/i686-pc-linux-gnu/4.1.2/../../../../i686-pc-linux-gnu/include
#include ... search starts here:
#include ... search starts here:
/usr/lib/gcc/i686-pc-linux-gnu/4.1.2/include
/usr/include
End of search list.
/usr/libexec/gcc/i686-pc-linux-gnu/4.1.2/cc1 -fpreprocessed test.i -quiet
-dumpbase test.c -march=i686 -auxbase test -Wall -version -o test.s
GNU C version 4.1.2 (Gentoo 4.1.2 p1.1) (i686-pc-linux-gnu)
compiled by GNU C version 4.1.2 (Gentoo 4.1.2 p1.1).
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
Compiler executable checksum: db0ff7bf11ec8c21ed7c44c88f5253be
/usr/lib/gcc/i686-pc-linux-gnu/4.1.2/../../../../i686-pc-linux-gnu/bin/as -V
-Qy -o test.o test.s
GNU assembler version 2.18 (i686-pc-linux-gnu) using BFD version (GNU Binutils)
2.18
/usr/libexec/gcc/i686-pc-linux-gnu/4.1.2/collect2 --eh-frame-hdr -m elf_i386
-dynamic-linker /lib/ld-linux.so.2
/usr/lib/gcc/i686-pc-linux-gnu/4.1.2/../../../crt1.o
/usr/lib/gcc/i686-pc-linux-gnu/4.1.2/../../../crti.o
/usr/lib/gcc/i686-pc-linux-gnu/4.1.2/crtbegin.o
-L/usr/lib/gcc/i686-pc-linux-gnu/4.1.2 -L/usr/lib/gcc/i686-pc-linux-gnu/4.1.2
-L/usr/lib/gcc/i686-pc-linux-gnu/4.1.2/../../../../i686-pc-linux-gnu/lib
-L/usr/lib/gcc/i686-pc-linux-gnu/4.1.2/../../.. test.o -lgcc --as-needed
-lgcc_s --no-as-needed -lc -lgcc --as-needed -lgcc_s --no-as-needed
/usr/lib/gcc/i686-pc-linux-gnu/4.1.2/crtend.o
/usr/lib/gcc/i686-pc-linux-gnu/4.1.2/../../../crtn.o
// End output of gcc -v -save-temps -Wall test.c
--
Summary: p-count += inc(p); // value of p-count is wrong, if
inc(p) not only returns an int but also increases p-
counter
Product: gcc
Version: 4.1.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: micirio at gmx dot net
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37947
[Bug c/37947] p-count += inc(p); // value of p-count is wrong, if inc(p) not only returns an int but also increases p-counter
--- Comment #1 from micirio at gmx dot net 2008-10-29 01:29 --- Created an attachment (id=16579) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16579action=view) test.i -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37947
[Bug c/37947] p-count += inc(p); // value of p-count is wrong, if inc(p) not only returns an int but also increases p-counter
--- Comment #2 from pinskia at gcc dot gnu dot org 2008-10-29 01:34 --- counter += inc(counter); That is undefined code as you access counter without a sequence point where you assign it. So it is valid for GCC to change the above to: int tmp = counter; tmp += inc(counter); counter = tmp; Or int tmp = inc(counter); counter += tmp; The same thing happens with p-counter += inc(p); except instead s/counter/p-counter/ and s/counter/p/. Thanks, Andrew Pinski -- 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=37947
[Bug c/37947] p-count += inc(p); // value of p-count is wrong, if inc(p) not only returns an int but also increases p-counter
--- Comment #3 from micirio at gmx dot net 2008-10-29 01:44 --- Thanks for the quick answer. Is it possible to get a warning if I write undefined code like this? -Wall didn't tell me anything. I'm asking, because I need to convert an existing (old) project where I found this line that caused a segfault at a very other point in the source. So a warning would avoid some odd surprises. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37947
[Bug middle-end/37886] [graphite] ICE: Segmentation fault
--- Comment #6 from grosser at gcc dot gnu dot org 2008-10-29 04:37 --- Fix committed. -- grosser at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37886
[Bug middle-end/37943] [graphite] ICE : in build_graphite_scops, at graphite.c:1823
-- grosser at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |grosser at gcc dot gnu dot |dot org |org Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2008-10-29 04:40:55 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37943
[Bug libfortran/37707] Namelist read of array of derived type incorrect
--- Comment #33 from jvdelisle at gcc dot gnu dot org 2008-10-29 04:45 --- Subject: Bug 37707 Author: jvdelisle Date: Wed Oct 29 04:44:15 2008 New Revision: 141420 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=141420 Log: 2008-10-28 Jerry DeLisle [EMAIL PROTECTED] PR libfortran/37707 Backport from trunk. * io/list_read.c (read_character): Remove code to look ahead in namelist reads to descriminate non-delimited strings from namelist objects. * io/write.c (namelist_write): Delimit character strings with quote or apostrophe, defaulting to quote. Modified: branches/gcc-4_3-branch/libgfortran/ChangeLog branches/gcc-4_3-branch/libgfortran/io/list_read.c branches/gcc-4_3-branch/libgfortran/io/write.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37707
[Bug libfortran/37707] Namelist read of array of derived type incorrect
--- Comment #34 from jvdelisle at gcc dot gnu dot org 2008-10-29 04:47 --- Fixed on 4.3, closing -- jvdelisle at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37707
[Bug libfortran/37707] Namelist read of array of derived type incorrect
--- Comment #35 from jvdelisle at gcc dot gnu dot org 2008-10-29 04:48 --- Subject: Bug 37707 Author: jvdelisle Date: Wed Oct 29 04:47:20 2008 New Revision: 141421 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=141421 Log: 2008-10-28 Jerry DeLisle [EMAIL PROTECTED] PR libfortran/37707 * gfortran.dg/namelist_18.f90: Revise. * gfortran.dg/namelist_55.f90: New test. * gfortran.dg/namelist_56.f90: New test. Added: branches/gcc-4_3-branch/gcc/testsuite/gfortran.dg/namelist_55.f90 branches/gcc-4_3-branch/gcc/testsuite/gfortran.dg/namelist_56.f90 Modified: branches/gcc-4_3-branch/gcc/testsuite/ChangeLog branches/gcc-4_3-branch/gcc/testsuite/gfortran.dg/namelist_18.f90 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37707
[Bug rtl-optimization/37948] New: [4.4 Regression] IRA generates slower code for -mtune=core2
+++ This bug was initially created as a clone of Bug #37364 +++ Testcase in PR 37364: http://gcc.gnu.org/bugzilla/attachment.cgi?id=16536 shows IRA generates slower code for -mtune=core2. $ gcc -m32 -O2 -mssse3 -mfpmath=sse 36.c $ time -p ./a.out real 7.97 $ gcc -m32 -O2 -mssse3 -mfpmath=sse -mtune=core2 -o core2.exe 36.c $ time -p ./core2.exe real 12.27 -- Summary: [4.4 Regression] IRA generates slower code for - mtune=core2 Product: gcc Version: 4.4.0 Status: UNCONFIRMED Keywords: missed-optimization, ra Severity: normal Priority: P3 Component: rtl-optimization AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: hjl dot tools at gmail dot com GCC target triplet: i686-pc-linux-gnu BugsThisDependsOn: 37364 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37948
[Bug rtl-optimization/37948] [4.4 Regression] IRA generates slower code for -mtune=core2
--- Comment #1 from hjl dot tools at gmail dot com 2008-10-29 05:44 ---
It looks like the cost of loading/storing FP values aren't appropriate for
Core 2. With this patch:
[EMAIL PROTECTED] i386]$ diff -up i386.c.foo i386.c
--- i386.c.foo 2008-10-28 21:56:19.0 -0700
+++ i386.c 2008-10-28 22:01:53.0 -0700
@@ -990,9 +990,9 @@ struct processor_costs core2_cost = {
Relative to reg-reg move (2). */
{4, 4, 4}, /* cost of storing integer registers */
2, /* cost of reg,reg fld/fst */
- {6, 6, 6}, /* cost of loading fp registers
+ {12, 12, 12},/* cost of loading fp registers
in SFmode, DFmode and XFmode */
- {4, 4, 4}, /* cost of storing fp registers
+ {6, 6, 8}, /* cost of storing fp registers
in SFmode, DFmode and XFmode */
2, /* cost of moving MMX register */
{6, 6}, /* cost of loading MMX registers
@@ -1000,9 +1000,9 @@ struct processor_costs core2_cost = {
{4, 4}, /* cost of storing MMX registers
in SImode and DImode */
2, /* cost of moving SSE register */
- {6, 6, 6}, /* cost of loading SSE registers
+ {8, 8, 8}, /* cost of loading SSE registers
in SImode, DImode and TImode */
- {4, 4, 4}, /* cost of storing SSE registers
+ {8, 8, 8}, /* cost of storing SSE registers
in SImode, DImode and TImode */
2, /* MMX or SSE register to integer */
32, /* size of l1 cache. */
[EMAIL PROTECTED] i386]$
I got
[EMAIL PROTECTED] gcc]$ ./xgcc -B./ -m32 -O2 /tmp/foo.c -o core2.sse
-mtune=core2
-msse3 -mfpmath=sse
[EMAIL PROTECTED] gcc]$ ./xgcc -B./ -m32 -O2 /tmp/foo.c -o core2 -mtune=core2
[EMAIL PROTECTED] gcc]$ ./xgcc -B./ -m32 -O2 /tmp/foo.c -o o2 -msse3
-mfpmath=sse
[EMAIL PROTECTED] gcc]$ ./xgcc -B./ -m32 -O2 /tmp/foo.c -o o2.sse
[EMAIL PROTECTED] gcc]$ time ./o2
real0m7.163s
user0m7.161s
sys 0m0.001s
[EMAIL PROTECTED] gcc]$ time ./core2
real0m7.833s
user0m7.829s
sys 0m0.001s
[EMAIL PROTECTED] gcc]$ time ./o2.sse
real0m7.795s
user0m7.794s
sys 0m0.000s
[EMAIL PROTECTED] gcc]$ time ./core2.sse
real0m7.339s
user0m7.337s
sys 0m0.001s
[EMAIL PROTECTED] gcc]$
But even with this patch, IRA still generates slower codes:
[EMAIL PROTECTED] gcc]$ ./xgcc -B./ -m32 -O2 /tmp/foo.c -o core2.noira
-mtune=core2
-fno-ira
[EMAIL PROTECTED] gcc]$ time ./core2.noira
real0m7.444s
user0m7.441s
sys 0m0.001s
[EMAIL PROTECTED] gcc]$ ./xgcc -B./ -m32 -O2 /tmp/foo.c -o core2.sse.noira
-mtune=core2 -fno-ira -msse3 -mfpmath=sse
[EMAIL PROTECTED] gcc]$ time ./core2.sse.noira
real0m7.229s
user0m7.224s
sys 0m0.000s
[EMAIL PROTECTED] gcc]$
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37948
