[Bug c++/33425] GCC Compiles C++ program containing value-returning functions that don't return a value
--- Comment #4 from bobby_miesen at yahoo dot com 2007-09-14 06:02 --- Subject: Re: GCC Compiles C++ program containing value-returning functions that don't return a value Thank you for clarifying that. I will let Addison-Wesley know of this as well. pinskia at gcc dot gnu dot org wrote: --- Comment #3 from pinskia at gcc dot gnu dot org 2007-09-13 23:51 --- That book is wrong when it comes to the standard. The standard says (6.6.2/2, last sentence): Flowing off the end of a function is equivalent to a return with no value; this results in ___undefined behavior___ in a value returning function. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33425
[Bug debug/33429] New: debug info for class2 in g++.dg/other/unused1.C requires -femit-class-debug-always
See conversation at http://gcc.gnu.org/ml/gcc-patches/2007-09/msg01230.html. The changed default for that option exposes the bug; -femit-class-debug-always should not be required to emit debug info for class2. -- Summary: debug info for class2 in g++.dg/other/unused1.C requires -femit-class-debug-always Product: gcc Version: 4.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: debug 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-axis-elf http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33429
[Bug debug/33429] debug info for class2 in g++.dg/other/unused1.C requires -femit-class-debug-always
--- Comment #1 from hp at gcc dot gnu dot org 2007-09-14 06:33 --- I forgot to mention that this likely happens everywhere, not just for cris-axis-elf. Compare for example http://gcc.gnu.org/ml/gcc-testresults/2007-09/msg00622.html (r128455, before the changed default of r128474) and http://gcc.gnu.org/ml/gcc-testresults/2007-09/msg00671.html (r128486, after). -- hp at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2007-09-14 06:33:22 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33429
[Bug debug/33429] debug info for class2 in g++.dg/other/unused1.C requires -femit-class-debug-always
--- Comment #2 from hp at gcc dot gnu dot org 2007-09-14 06:48 --- Subject: Bug 33429 Author: hp Date: Fri Sep 14 06:48:17 2007 New Revision: 128489 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=128489 Log: PR debug/33429 * g++.dg/other/unused1.C: XFAIL class2 scan. Modified: trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/g++.dg/other/unused1.C -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33429
[Bug preprocessor/33415] Can't compile .cpp file with UTF-8 BOM.
--- Comment #2 from pinskia at gcc dot gnu dot org 2007-09-14 09:28 --- Actually I already know this is not handled. In fact any of the BOMs are not handled. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|WAITING |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2007-09-14 09:28:32 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33415
[Bug fortran/33430] New: Improve -finit-*: Initialization of derived types, equivalenced variables
The following features are missing from the current version of the -finit-* patch (PR 20441): - Optional initialization of INTENT(OUT) variables: PR 31447 - Derived types are not initialized; there are two cases: (a) no initializer, (b) initializer which initializes not all variables - Equivalenced variables: g77 initialized them with -finit-local-zero. The challenge is of cause if the variables have different types and -finit-real/-finit-integer etc. is used instead of -finit-local-zero. -- Summary: Improve -finit-*: Initialization of derived types, equivalenced variables Product: gcc Version: 4.3.0 Status: UNCONFIRMED Severity: enhancement Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: burnus at gcc dot gnu dot org BugsThisDependsOn: 20441 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33430
[Bug fortran/31447] set intent(out) arguments to uninitialized
--- Comment #2 from burnus at gcc dot gnu dot org 2007-09-14 09:53 --- Initializing INTENT(OUT) variables should not be the default with -finit-local-zero; otherwise I'm in favour of this option. See also PR 33430 for other omissions of the -finit-* patch (cf. PR 20441). -- 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=31447
[Bug fortran/33430] Improve -finit-*: Initialization of derived types, equivalenced variables
--- Comment #1 from burnus at gcc dot gnu dot org 2007-09-14 09:55 --- ... and of cause: - Signalling NaN (sNaN) should be supported as well. (mpfr currently only supports qNaN - last not least as IEEE 754 does not specify the bitpattern for sNaN/qNaN; IEEE 754r does, but it has not been accepted yet.) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33430
[Bug target/33431] New: [SH4] performance regression between 3.4.6 and 4.x
I've found serious performance regression between GCC version 3.4.6 and 4.2/4.3. SciMark2 Numeric Benchmark, see http://math.nist.gov/scimark GCC: 3.4.6 4.2.1 4.3.0 (20070907) Composite: 6.055.014.82 FFT: 4.904.154.21 SOR: 10.108.367.64 MonteCarlo: 3.683.063.04 Sparse matmult: 5.454.454.03 LU: 6.105.035.18 BYTEmark* Native Mode Benchmark ver. 2 (10/95) GCC: 3.4.6 4.2.1 4.3.0 (20070907) NUMERIC SORT: 35.459 32.2 29.327 STRING SORT: 0.59430.57604 0.8603 BITFIELD: 1.0585e+07 9.269e+06 9.4138e+06 FP EMULATION: 4.4944 4.6012 5.364 FOURIER: 272.28 241.34 259.12 ASSIGNMENT:0.359970.38373 0.39683 IDEA: 124.11 95.057 100.07 HUFFMAN: 45.593 52.083 56.391 NEURAL NET:0.361530.30922 0.31348 LU DECOMPOSITION: 11.331 9.4938 8.255 The real world application has 20%-200% performance regression with GCC 4.x. All tests were compiled with this arguments: -O3 -ffast-math -fomit-frame-pointer -funroll-loops -ftracer -funit-at-a-time -m4 -ml This arguments were tuned for the best results under 3.4.6. I've played with various settings under 4.x, but can't achieve any performance improvement. I can rerun them with any key combination you want. This tests compilable under Linux can be downloaded from: - scimark: http://oktetlabs.ru/~snob/scimark.tgz - nbench: http://oktetlabs.ru/~snob/nbench.tgz I can attach this files to bugreport if this is acceptable and will not pollute bugzilla. Our target hardware has SH7750 processor running in little endian mode under RTEMS. Unfortunetaly there is no way to boot linux there. Can I ask you to run this tests under linux-sh? At least scimark one. After lurking inside backend sources, I found that m4 has several variants in GCC 4.x: m4-100, m4-200, etc. I've tried to compile this tests with m4-200 switch, but it looks like m4-200 enforces big-endian. Backend sources show, that there is a lot of work going on SH4 GCC part. I also wrote simple stupid tests to compare code generation between different compiler versions (I can mail/attach them to you, but they are really stupid) to understand what can cause such performance regression. But generated assembler is really different across versions. I can found only two obvious things: - GCC4 has a much more aggressive inline and loop unrolling. (-funroll-loops was dropped from compiler arguments with no positive result) - GCC4 has different command scheduling, which probably leads to performance regression. -- Summary: [SH4] performance regression between 3.4.6 and 4.x Product: gcc Version: 4.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: nbkolchin at gmail dot com GCC build triplet: x86_64-unknown-linux-gnu GCC host triplet: x86_64-unknown-linux-gnu GCC target triplet: sh-unknown-rtemself http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33431
[Bug fortran/33432] New: g77 extension: Support for the .XOR. operator
The .XOR. operator is supported by several vendor compilers including IBM's XL fortran, DEC fortran, SUN fortran and even GNU f77! A patch has been proposed at: See: [PATCH] Support .XOR. as a -std=legacy extension http://gcc.gnu.org/ml/fortran/2007-09/msg00070.html The only problem is that this patch rejects (with -std=gnu/legacy) a user-implemented .XOR., which is valid Fortran 90/95/2003. Other compilers such as ifort and sunf95 implemented .XOR. such that by default both the intrinsic .XOR. as also a user-implemented .XOR. work; see also http://gcc.gnu.org/ml/fortran/2007-09/msg00082.html -- Summary: g77 extension: Support for the .XOR. operator Product: gcc Version: 4.3.0 Status: UNCONFIRMED Keywords: patch 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=33432
[Bug target/29473] -masm=intel combined with -march=athlon64 has some issues.
--- Comment #11 from rask at gcc dot gnu dot org 2007-09-14 10:15 --- Yes, that worked. It is quite obvious from trying a bootstrap with -masm=intel that nobody ever uses Intel syntax, because there are assorted issues around the edges. Additionally, I'm now blocked by binutils bug gas/5034. http://sourceware.org/bugzilla/show_bug.cgi?id=5034 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29473
[Bug libfortran/21185] libgfortran unusable for cross-testing for newlib targets
--- Comment #10 from rask at gcc dot gnu dot org 2007-09-14 10:42 --- I'm testing mipsisa64-unknown-elf, sh-unknown-elf and v850-unknown-elf right now. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21185
[Bug tree-optimization/33389] [4.3 Regression] Revision 128239 causes libgomp failure
--- Comment #28 from jakub at gcc dot gnu dot org 2007-09-14 11:32 --- Thanks, Jim. -- jakub at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33389
[Bug libfortran/25561] Eventually get rid of the Alloc Stream Facility
--- Comment #3 from fxcoudert at gcc dot gnu dot org 2007-09-14 11:33 --- Why marking this as blocking asynchronous I/O? -- fxcoudert at gcc dot gnu dot org changed: What|Removed |Added CC||fxcoudert at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25561
[Bug libfortran/31546] add --enable-intermodule
--- Comment #8 from fxcoudert at gcc dot gnu dot org 2007-09-14 11:37 --- Wasn't the patch for this approved? (http://gcc.gnu.org/ml/fortran/2007-08/msg00517.html) Since stage3 has started, it probably would be best to commit rather soon. -- fxcoudert at gcc dot gnu dot org changed: What|Removed |Added CC||fxcoudert at gcc dot gnu dot ||org AssignedTo|unassigned at gcc dot gnu |aldot at gcc dot gnu dot org |dot org | Status|NEW |ASSIGNED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31546
[Bug target/33431] [SH4] performance regression between 3.4.6 and 4.x
--- Comment #1 from kkojima at gcc dot gnu dot org 2007-09-14 11:46 --- I've run scimark on my box: sh4-unknown-linux-gnu / linux-kernel 2.6.22-rc4 / SH7751R with -O3 -ffast-math -fomit-frame-pointer -funroll-loops -ftracer -funit-at-a-time: gcc-3.4.6gcc-4.2.1gcc-4.3.0(20070910) Composite Score: 16.7616.8616.99 FFT Mflops:12.9213.3613.36 SOR Mflops:27.8826.7628.01 MonteCarlo:Mflops: 9.96 9.73 9.67 Sparse matmult Mflops:14.9516.0614.84 LU Mflops:18.0818.3919.05 Hmm... I can't reproduce the regression in linux-sh, at least for SH7751R. -- kkojima at gcc dot gnu dot org changed: What|Removed |Added CC||kkojima at gcc dot gnu dot ||org Summary|[SH4] performance regression|[SH4] performance regression |between 3.4.6 and 4.x |between 3.4.6 and 4.x http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33431
[Bug libfortran/21881] Array descriptors limit derived type sizes
--- Comment #4 from fxcoudert at gcc dot gnu dot org 2007-09-14 11:31
---
I think this is related to the check in trans-types.c:
if (size INTEGER_CST_P (size))
{
if (tree_int_cst_lt (gfc_max_array_element_size, size))
internal_error (Array element size too big);
i += TREE_INT_CST_LOW (size) GFC_DTYPE_SIZE_SHIFT;
}
dtype = build_int_cst (gfc_array_index_type, i);
which is triggered by code such as:
type t
integer i001(268435456)
end type t
type(t), allocatable :: x(:)
allocate(x(1))
print *, size(x)
print *, shape(x)
end
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21881
[Bug tree-optimization/33434] New: [4.3 Regression] -fipa-cp miscompilation
Found this while trying to bootstrap with BOOT_CFLAGS=-O3 -fipa-cp and it
miscompiled libcpp/macro.c at the stage2. Appeared somewhere in between
r122374 and r124593:
/* { dg-do run } */
/* { dg-options -O3 -fipa-cp } */
int k;
void f1 (int a, int b)
{
if (a)
while (b --)
k = 1;
else
if (b != 1)
__builtin_abort ();
}
int main (void)
{
f1 (1, 1);
if (k != 1)
__builtin_abort ();
return 0;
}
--
Summary: [4.3 Regression] -fipa-cp miscompilation
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
Keywords: wrong-code
Severity: normal
Priority: P3
Component: tree-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: belyshev at depni dot sinp dot msu dot ru
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33434
[Bug libfortran/21185] libgfortran unusable for cross-testing for newlib targets
--- Comment #11 from hp at gcc dot gnu dot org 2007-09-14 12:10 --- (In reply to comment #9) Patch submitted at http://gcc.gnu.org/ml/gcc-patches/2007-09/msg01219.html. I'd be glad if some with access to cris-axis-elf I'll test that. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21185
[Bug c++/33435] New: internal compiler error with templates and openmp
I get the error message
bug.cpp:16: internal compiler error: in create_tmp_var, at gimplify.c:487
when compiling the following code with
g++ -fopenmp -DTVMET_OPTIMIZE -c bug.cpp
where bug.cpp contains:
#include tvmet/Vector.h // Tiny Vector Matrix library using
Expression Templates
#include tvmet/VectorFunctions.h // http://tvmet.sourceforge.net/
using namespace tvmet;
int main() {
Vectorint,3 a[10];
int i;
#pragma omp parallel
{
#pragma omp for schedule(dynamic)
for (i=0; i10; ++i) {
// do something
}
#pragma omp master
{
a[0] = a[1];
}
#pragma omp for schedule(dynamic)
for (i=0; i10; ++i) {
// do something
}
}
}
The problem is definitely related to openmp because the following code compiles
without any error:
#include tvmet/Vector.h // Tiny Vector Matrix library using
Expression Templates
#include tvmet/VectorFunctions.h // http://tvmet.sourceforge.net/
using namespace tvmet;
int main() {
Vectorint,3 a[10];
int i;
#pragma omp parallel for schedule(dynamic)
for (i=0; i10; ++i) {
// do something
}
a[0] = a[1];
#pragma omp parallel for schedule(dynamic)
for (i=0; i10; ++i) {
// do something
}
}
--
Summary: internal compiler error with templates and openmp
Product: gcc
Version: 4.2.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: E dot Kuemmerle at fz-juelich dot de
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=33435
[Bug libfortran/21185] libgfortran unusable for cross-testing for newlib targets
--- Comment #12 from rask at gcc dot gnu dot org 2007-09-14 13:12 --- Testing on v850-unknown-elf suggests that getcwd() is also needed by libgfortran. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21185
[Bug libfortran/21185] libgfortran unusable for cross-testing for newlib targets
--- Comment #13 from hp at gcc dot gnu dot org 2007-09-14 13:19 --- Sorry, build fails for cris-elf with: libtool: compile: /home/hp/combe/cris-regobj/./gcc/xgcc -B/home/hp/combe/cris-regobj/./gcc/ -nostdinc -B/home/hp/combe/cris-rego\ bj/cris-unknown-elf/newlib/ -isystem /home/hp/combe/cris-regobj/cris-unknown-elf/newlib/targ-include -isystem /home/hp/combe/comb\ ined/newlib/libc/include -B/home/hp/combe/cris-regobj/cris-unknown-elf/libgloss/cris -L/home/hp/combe/cris-regobj/cris-unknown-el\ f/libgloss/libnosys -L/home/hp/combe/combined/libgloss/cris -B/tmp/reg-cris/cris-unknown-elf/bin/ -B/tmp/reg-cris/cris-unknown-el\ f/lib/ -isystem /tmp/reg-cris/cris-unknown-elf/include -isystem /tmp/reg-cris/cris-unknown-elf/sys-include -L/home/hp/combe/cris-\ regobj/./ld -DHAVE_CONFIG_H -I. -I/home/hp/combe/combined/libgfortran -I. -iquote/home/hp/combe/combined/libgfortran/io -I/home/h\ p/combe/combined/libgfortran/../gcc -I/home/hp/combe/combined/libgfortran/../gcc/config -I../.././gcc -D_GNU_SOURCE -std=gnu99 -W\ all -Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition -Wextra -Wwrite-strings -O2 -g -O2 -MT unix.lo -MD -MP -MF .d\ eps/unix.Tpo -c /home/hp/combe/combined/libgfortran/io/unix.c -o unix.o /home/hp/combe/combined/libgfortran/io/unix.c:1794: error: static declaration of 'access' follows non-static declaration /home/hp/combe/combined/newlib/libc/include/sys/unistd.h:19: error: previous declaration of 'access' was here /home/hp/combe/combined/libgfortran/io/unix.c: In function 'access': /home/hp/combe/combined/libgfortran/io/unix.c:1795: error: 'amod' undeclared (first use in this function) /home/hp/combe/combined/libgfortran/io/unix.c:1795: error: (Each undeclared identifier is reported only once /home/hp/combe/combined/libgfortran/io/unix.c:1795: error: for each function it appears in.) /home/hp/combe/combined/libgfortran/io/unix.c:1793: warning: unused parameter 'amode' make[5]: *** [unix.lo] Error 1 make[5]: Leaving directory `/home/hp/combe/cris-regobj/cris-unknown-elf/libgfortran' Besides the obvious s/amod/amode/ typo, maybe use a different name for the internal function, and #ifndef HAVE_ACCESS ... libgfortran_access implementation #else #define libgfortran_access access #endif to avoid problems with the access prototype. I'm testing such an updated patch. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21185
[Bug libfortran/21185] libgfortran unusable for cross-testing for newlib targets
--- Comment #14 from hp at gcc dot gnu dot org 2007-09-14 13:22 --- (In reply to comment #13) Oops, I mean: #ifndef HAVE_ACCESS ... libgfortran_access implementation #undef access #define access libgfortran_access #endif -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21185
[Bug libfortran/21185] libgfortran unusable for cross-testing for newlib targets
--- Comment #15 from fxcoudert at gcc dot gnu dot org 2007-09-14 13:38 --- Created an attachment (id=14208) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14208action=view) Updated patch (In reply to comment #13) /home/hp/combe/combined/libgfortran/io/unix.c:1794: error: static declaration of 'access' follows non-static declaration /home/hp/combe/combined/newlib/libc/include/sys/unistd.h:19: error: previous declaration of 'access' was here Oh, you have a prototype for access() in standard headers but no function in the libc? That's weird! Embedded targets will always surprise me. Besides the obvious s/amod/amode/ typo Hum, how did that even get past my testing? I thought I had commented out HAVE_ACCESS on my x86_64-linux. maybe use a different name for the internal function Yup, you're right (the second version). I'm attaching an updated patch that should do the same thing you did. (In reply to comment #12) Testing on v850-unknown-elf suggests that getcwd() is also needed by libgfortran. Also fixed in the attached new patch. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21185
[Bug libfortran/21185] libgfortran unusable for cross-testing for newlib targets
--- Comment #16 from rask at gcc dot gnu dot org 2007-09-14 13:43 --- I get the same build failure on sh-unknown-elf and mipsisa64-unknown-elf. I'm continuing without the static keyword and with s/amod/amode/g. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21185
[Bug libfortran/21185] libgfortran unusable for cross-testing for newlib targets
--- Comment #17 from hp at gcc dot gnu dot org 2007-09-14 14:13 --- (In reply to comment #14) The build succeeds with my locally fixed version. We'll see whether the test-results are meaningful; it's likely there's more to fix. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21185
[Bug middle-end/33436] New: Bad constant output with TARGET_ASM_ALIGNED_DI_OP
Executing on host: /mnt/gnu/gcc/objdir/gcc/xgcc -B/mnt/gnu/gcc/objdir/gcc/ /mnt/ gnu/gcc/gcc/gcc/testsuite/gcc.dg/pr32912-2.c -O2 -w -fno-show-column -lm -o ./pr32912-2.exe(timeout = 300) /var/tmp//cclFD5RH.s: Assembler messages: /var/tmp//cclFD5RH.s:5: Warning: bignum truncated to 8 bytes output is: /var/tmp//cclFD5RH.s: Assembler messages: /var/tmp//cclFD5RH.s:5: Warning: bignum truncated to 8 bytes FAIL: gcc.dg/pr32912-2.c (test for excess errors) Excess errors: /var/tmp//cclFD5RH.s:5: Warning: bignum truncated to 8 bytes Setting LD_LIBRARY_PATH to :/mnt/gnu/gcc/objdir/gcc::/mnt/gnu/gcc/objdir/gcc FAIL: gcc.dg/pr32912-2.c execution test .LEVEL 2.0w .section.rodata .align 8 L$C: .dword 0x ... Mainline is ok. -- Summary: Bad constant output with TARGET_ASM_ALIGNED_DI_OP Product: gcc Version: 4.2.2 Status: UNCONFIRMED Severity: normal Priority: P3 Component: middle-end AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: danglin at gcc dot gnu dot org GCC build triplet: hppa64-hp-hpux11.11 GCC host triplet: hppa64-hp-hpux11.11 GCC target triplet: hppa64-hp-hpux11.11 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33436
[Bug ada/33392] ACATS cxa5a09, cxa5a10 and controlled2.adb failure
--- Comment #5 from anhvofrcaus at gmail dot com 2007-09-14 15:16 --- Yes, you are absolutely correct that my tree is skewed. After updating my tree again, all ACATS tests passed beautifully. One more thing to say you guys are fantastic. AV -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33392
[Bug c/33437] New: potentially valid construct rejected
extern char x[] __attribute__((__weak__)); int i = (long)x; results in 'initializer element is not computable at load time'. However, the compiler really can't know this, as x may be either zero (since it's weak) or may be used as C-level place holder for an assembler/linker defined absolute symbol. While emitting a warning here (that should have a control for suppressing) seems appropriate, failing the compilation isn't - that decision should be left to the assembler (in case the target doesn't have an appropriately sized relocation type) or the linker. -- Summary: potentially valid construct rejected Product: gcc Version: 4.2.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: jbeulich at novell 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=33437
[Bug rtl-optimization/26449] [4.2/4.3 Regression] ICE in loop invariant motion
--- Comment #20 from rakdver at gcc dot gnu dot org 2007-09-14 15:57 --- (In reply to comment #19) Zdenek, the fix in Comment #5 is wrong (please look at Comment #11 why), as cofirmed by a couple of dupes. From PR 33428: actually the fix in loop-invariant is correct for the original problem (where expand_simple_binop fails and returns NULL_RTX). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26449
[Bug target/33431] [SH4] performance regression between 3.4.6 and 4.x
--- Comment #2 from nbkolchin at gmail dot com 2007-09-14 16:10 --- Thank you for your reply. Variants: - you are not using: -m4 -ml, but some other architecture settings. - SH7751R and SH7750R have different instruction pipeline (probably not, both are SH4-200 variants as I know). - gcc for linux is different from gcc for RTEMS (how this can be checked?) - processor endians are different. -- nbkolchin at gmail dot com changed: What|Removed |Added CC||nbkolchin at gmail dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33431
[Bug debug/33429] debug info for class2 in g++.dg/other/unused1.C requires -femit-class-debug-always
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |spark at gcc dot gnu dot org |dot org | Status|NEW |ASSIGNED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33429
[Bug target/33438] New: [4.3 Regression] ICE in cselib_record_set, at cselib.c:1515 on x86
Compile with -O1:
long double f (long double x)
{
return __builtin_remainderl (x, x);
}
bug.c: In function 'f':
bug.c:4: internal compiler error: in cselib_record_set, at cselib.c:1515
--
Summary: [4.3 Regression] ICE in cselib_record_set, at
cselib.c:1515 on x86
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
Keywords: ice-on-valid-code
Severity: normal
Priority: P3
Component: target
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: belyshev at depni dot sinp dot msu dot ru
GCC target triplet: x86_64-*-*, i?86-*-*
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33438
[Bug target/33438] [4.3 Regression] ICE in cselib_record_set, at cselib.c:1515 on x86
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||pinskia at gcc dot gnu dot ||org Target Milestone|--- |4.3.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33438
Couldn't install GCC properly in my cygwin!
Hello, I've CYGWIN_NT-5.0 (1.3.22) version installed in my system. Here I try to install a fresh GCC version (GCC-3.4.6). But I don't have already any compiled version of GCC in my system. So I took GCC-3.4.6 tarballs from the recommended GNU source. Downloaded properly. As a first step, when I do configure for native compiler I get the following error. ../gcc-3.4.6/configure --prefix=/opt/gcc-3.4.6 loading cache ./config.cache checking host system type... i686-pc-cygwin checking target system type... i686-pc-cygwin checking build system type... i686-pc-cygwin checking for a BSD compatible install... /bin/install -c *** This configuration is not supported in the following subdirectories: target-libffi target-boehm-gc target-zlib target-libjava (Any other directories should still work fine.) gcc: installation problem, cannot exec `cc1': No such file or directory *** The command 'gcc -o conftest -O2 conftest.c' failed. *** You must set the environment variable CC to a working compiler. 1. To set environment variable tried all the posibities as mentioned in this link http://forums.fedoraforum.org/archive/index.php/t-207.html 2. Then to avoid subdirectories problem I tried the following and got the error mentioned like above ../gcc-3.4.6/configure --prefix=/opt/gcc-3.4.6 --verbose --enable-languages=c --disable-libgcj 3. Tried downloading pre compiled RPM version of GCC-3.3.3-1 to rectify the Set Env to CC working directory problem Here downloaded RPM version but don't have RPM installed in my system. So went to setup the RPM tool in my system. Downloaded this tool and did untar, but no luck, still RPM command is not working. But there is a RPM.exe etc. So when I search the solution for this, I found There should be a proper GCC compiler to get this RPM tool to be installed propely Somehow I'm in dead lock condition. Please help me to rectify this problem. My ultimate aim is to install proper GCC compiler in my cygwin system when there is no existing working compiler. Really tried so much to solve this problem, couldn't. Finally come to you guys to get an advanced mind. Help me ! Thanks in advance! Regards, Poovizhi -- View this message in context: http://www.nabble.com/Couldn%27t-install-GCC-properly-in-my-cygwin%21-tf080.html#a12680112 Sent from the gcc - bugs mailing list archive at Nabble.com.
[Bug fortran/33439] New: Incorrect error message for chunksize variable
The GNU compiler is asking that when a default(none) clause is present on the OMP PARALLEL DO, and a chunk-size expression (in this case just the variable fsize) appears in a schedule clause, that the variable must appear in a shared or private clause. Other compilers (PGI, Pathscale) do not require that this be done. I cannot find a justification for requiring that fsize be listed in a private or shared clause. It is referenced before the construct begins execution, but not within the construct itself. Admittedly, the OpenMP 2.5 spec is a bit weak on scoping rules in this case, but the text at page 63 lines 25-28 hints to me that a variable that appears in a schedule clause is not automatically a reference. The text on page 36 lines 1-19 says that IF the variable is declared private then the value used is not the private copy but rather the value of the version external to the construct. Again this suggests that the variable in the schedule clause is outside the scope of the construct. gfortran -c -fopenmp test.f90 test.f90: In function 'MAIN__': test.f90:16: error: 'fsize' not specified in enclosing parallel test.f90:16: error: enclosing parallel cat test.f90 program OMP_program ! derived from ISU's RTED_OpenMP/FORTRAN/SECTION_C/F_C_3_2_a.f90 !RTED_OpenMP/FORTRAN/SECTION_C/F_C_3_2_d.f90 integer, parameter :: nt=4 double precision :: s,tmp double precision :: ARR(100) integer :: fsize,i call omp_set_num_threads(nt) s = 0.d0 arr = 1.0d0 tmp = 4.d0*atan(1.d0) fsize = int(sin(-0.25*tmp)*10.0) write(*,*) 'tmp, fsize',tmp, fsize !$omp parallel do default(none) shared(arr) private(i) reduction(+:s) schedule(static,fsize) do i=1,100 s = s + arr(i) end do !$omp end parallel do print *,'s =', s end program OMP_program -- Summary: Incorrect error message for chunksize variable Product: gcc Version: 4.2.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: longb at cray dot com GCC build triplet: x86_64-suse-linux GCC host triplet: x86_64-suse-linux GCC target triplet: x86_64-suse-linux http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33439
[Bug target/33406] [4.3 Regression] At revision 128385 Bootstraping PPC Darwin still fail in Java
--- Comment #6 from howarth at nitro dot med dot uc dot edu 2007-09-14 18:00 --- Is anyone working on this bug? I ask because Apple's regress server has effectively stopped showing testresults because of this bug. Also, I am a tad confused by the comments that -enable-checking is now used. Does this imply that this bug has been latent in prior gcc releases and that the new default use of -enable-checking has exposed it? Also would I be able to suppress this problem with --disable-checking? I was hoping to test the new vectorization changes in gcc branch without disabling the java build on powerpc Darwin. Lastly, if this is the same bug that is breaking the libgomp build on powerpc64 linux, those testresults are now all being posted with libgomp disabled. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33406
[Bug bootstrap/21335] [meta-bug] bootstrap fails with -ftree-vectorize
--- Comment #7 from dorit at gcc dot gnu dot org 2007-09-14 18:49 --- (In reply to comment #6) I can bootstrap current trunk (r128479) with -ftree-vectorize on x86_64-unknown-linux-gnu for some time now, and, according to http://gcc.gnu.org/ml/gcc-patches/2007-09/msg00327.html, this problem is gone on powerpc64 too. actually the link you give above explicitly states that we don't pass bootstrap with vectorization enabled on powerpc-linux, but there's already a PR for that (PR32582) so it's ok to close this one So closing as fixed. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21335
[Bug tree-optimization/33373] [4.3 Regression] ICE in vectorizable_type_demotion, at tree-vect-transform.c:4098
--- Comment #4 from belyshev at depni dot sinp dot msu dot ru 2007-09-14
19:15 ---
Very similar testcase with the difference that it is not fixed by r128415 and
makes current trunk segfault in VEC_tree_base_pop():
void f (unsigned int *d, unsigned int *s, int w)
{
int i;
for (i = 0; i w; ++i)
d [i] = s [i] * (unsigned short) (~d [i] 24);
}
--
belyshev at depni dot sinp dot msu dot ru changed:
What|Removed |Added
CC||belyshev at depni dot sinp
||dot msu dot ru
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
GCC build triplet|x86_64-unknown-linux-gnu|
GCC host triplet|x86_64-unknown-linux-gnu|
GCC target triplet|i586-unknown-linux-gnu |
Last reconfirmed|-00-00 00:00:00 |2007-09-14 19:15:21
date||
Summary|ICE in |[4.3 Regression] ICE in
|vectorizable_type_demotion, |vectorizable_type_demotion,
|at tree-vect- |at tree-vect-
|transform.c:4098|transform.c:4098
Target Milestone|--- |4.3.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33373
[Bug target/33438] [4.3 Regression] ICE in cselib_record_set, at cselib.c:1515 on x86
--- Comment #2 from ubizjak at gmail dot com 2007-09-14 19:27 --- Fixed. -- ubizjak at gmail dot com changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33438
[Bug target/33438] [4.3 Regression] ICE in cselib_record_set, at cselib.c:1515 on x86
--- Comment #1 from uros at gcc dot gnu dot org 2007-09-14 19:24 --- Subject: Bug 33438 Author: uros Date: Fri Sep 14 19:24:26 2007 New Revision: 128502 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=128502 Log: PR target/33438 * config/i386/i386.md (fmodxf3): Copy operands[2] to temporary register when operands[2] equals operands[1]. (remainderxf3): Ditto. testsuite/ChangeLog: PR target/33438 * gcc.target/i386/pr33438.c: New test. Added: trunk/gcc/testsuite/gcc.target/i386/pr33483.c Modified: trunk/gcc/ChangeLog trunk/gcc/config/i386/i386.md trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33438
[Bug tree-optimization/33373] [4.3 Regression] ICE in vectorizable_type_demotion, at tree-vect-transform.c:4098
--- Comment #5 from dorit at gcc dot gnu dot org 2007-09-14 20:53 ---
(In reply to comment #4)
Very similar testcase with the difference that it is not fixed by r128415 and
makes current trunk segfault in VEC_tree_base_pop():
void f (unsigned int *d, unsigned int *s, int w)
{
int i;
for (i = 0; i w; ++i)
d [i] = s [i] * (unsigned short) (~d [i] 24);
}
this should fix it:
Index: tree-vect-transform.c
===
*** tree-vect-transform.c (revision 128501)
--- tree-vect-transform.c (working copy)
*** vect_get_vec_defs_for_stmt_copy (enum ve
*** 1938,1944
vec_oprnd = vect_get_vec_def_for_stmt_copy (dt[0], vec_oprnd);
VEC_quick_push (tree, *vec_oprnds0, vec_oprnd);
! if (vec_oprnds1)
{
vec_oprnd = VEC_pop (tree, *vec_oprnds1);
vec_oprnd = vect_get_vec_def_for_stmt_copy (dt[1], vec_oprnd);
--- 1938,1944
vec_oprnd = vect_get_vec_def_for_stmt_copy (dt[0], vec_oprnd);
VEC_quick_push (tree, *vec_oprnds0, vec_oprnd);
! if (vec_oprnds1 *vec_oprnds1)
{
vec_oprnd = VEC_pop (tree, *vec_oprnds1);
vec_oprnd = vect_get_vec_def_for_stmt_copy (dt[1], vec_oprnd);
(and by the way, I think this is a totally different issue than what this PR
was originally opened for, and should be a separate PR. I think this regression
is due to r128289)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33373
[Bug libfortran/21185] libgfortran unusable for cross-testing for newlib targets
--- Comment #18 from hp at gcc dot gnu dot org 2007-09-14 21:31 --- (In reply to comment #17) We'll see whether the test-results are meaningful; it's likely there's more to fix. Unfortunately not very meaningful without a getcwd. I got curious why getcwd would be needed, so I looked around, and it seems the stored absolute exe path is only reachable by full_exe_path(), called only from runtime/backtrace.c:show_backtrace() - which is #if GLIBC_BACKTRACE'd out; empty for newlib targets! So, I'll update your patch to get rid of the getcwd call, attach the result and start a new test. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21185
[Bug libfortran/21185] libgfortran unusable for cross-testing for newlib targets
--- Comment #19 from hp at gcc dot gnu dot org 2007-09-14 21:36 --- (In reply to comment #18) So, I'll update your patch to get rid of the getcwd call, attach the result and start a new test. Never mind, I see you've taken care of it in the access_dup2 patch here. Doh! Starting test... -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21185
[Bug target/33431] [SH4] performance regression between 3.4.6 and 4.x
--- Comment #3 from kkojima at gcc dot gnu dot org 2007-09-14 22:10 --- -ml and -m4 are default on sh4-unknown-linux-gnu compilers. For 4.3.0, you could see how the default target specific options are set with 'cc1 --target-help'. I've got the following result on my linux box. You can compare it with your RETMS's one. The following options are target specific: -m4 [enabled] -m4-100 [disabled] -m4-200 [disabled] -m4-300 [disabled] -m4a [disabled] -mb [disabled] -mbigtable[disabled] -mbranch-cost=0x -mcbranchdi [enabled] -mcmpeqdi [disabled] -mcut2-workaround [disabled] -mdalign [disabled] -mdiv= -mdivsi3_libfunc= -mexpand-cbranchdi[enabled] -mfused-madd [disabled] -mgettrcost= 0x -mglibc [enabled] -mhitachi [disabled] -mieee[disabled] -minline-ic_invalidate[disabled] -misize [disabled] -ml [enabled] -mnomacsave [disabled] -mpadstruct [disabled] -mprefergot [disabled] -mpretend-cmove [disabled] -mrelax [disabled] -mrenesas [disabled] -mspace [disabled] -muclibc [disabled] -multcost=0x -musermode[enabled] -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33431
[Bug c/33440] New: gcc-compiled program possibly reporting wrong variable address to gdb
Environment:
gcc (GCC) 4.1.2 (Ubuntu 4.1.2-0ubuntu4) from Ubuntu repositories
Ubuntu 7.04 2.6.20-16-generic kernel
GNU gdb 6.6-debian
I run this program in GDB, and put a breakpoing right before the call to
whatever(). At this point, I print a, and the value is no good, but the
variable is uninitialized so that's expected. However, after the other
statements which set the value of a, printing a still show the
uninitialized value.
This was compiled simply using gcc -g test.c and run using gdb ./a.out.
=== test.c ===
int
main (
int argc,
char *argv[])
{
int a;
void whatever ()
{
a = 123;
}
whatever();
a = 321;
return 0;
}
==
It looks like gdb decodes the address as 4 bytes too low, gcc says its location
is DW_OP_fbreg -16. I don't know if this is a gdb or a gcc problem, but from
what I've been told a variable not updating is almost always a compiler bug.
I've also submitted the issue to gdb's bugtracking system
(http://sourceware.org/cgi-bin/gnatsweb.pl) as issue 2319.
Thanks,
Seth Grover
--
Summary: gcc-compiled program possibly reporting wrong variable
address to gdb
Product: gcc
Version: 4.1.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: sethdgrover at gmail dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33440
[Bug debug/33440] gcc-compiled program possibly reporting wrong variable address to gdb
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-09-14 22:57 --- This works for me on the trunk with gdb 6.3-debian. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33440
Re: Couldn't install GCC properly in my cygwin!
poovizhi wrote: I've CYGWIN_NT-5.0 (1.3.22) version installed in my system. Here I try to install a fresh GCC version (GCC-3.4.6). But I don't have already any compiled version of GCC in my system. If you don't already have a compiler, then you won't be able to compile the gcc sources on your cygwin system. Download a gcc binary from the www.cygwin.com site. See the docs on this site for more info. Jim
Haunted Halloween fun at Mountain Village 1890!
Central Arkansas Society for Paranormal Research http://www.casprquest.com/privateten.htm Haunted Mountain Village 1890 http://www.1890village.com/ Mountain Village 1890 Bull Shoals Caverns 1011 C. S. Woods Boulevard P. O. Box 444 Bull Shoals, Arkansas 72619 Phone: (870) 445-7177 Toll free: (800) 445-7177 As quoted from their web site: Mountain Village 1890, an historic re-creation of an Ozark settlement, is a living tribute to the pioneers who first settled this remote part of the country. These were hardy men and women who followed the trails into our mountains from the Carolinas, Virginia, Tennessee and Georgia. The village is a Bull Shoals, Arkansas, attraction that draws families, particularly those interested in local or living history, from across the United States. Find out more by visiting the village at www.1890village.com Current Sightings and Experiences: The 1890s Village was bought in October, 2006 by the Oates family and is currently under the management of siblings, David, Steve, and Ginger. Steve's girlfriend and bride to be, Stephanie, helps with day to day operations as well. The family is from Tampa, Florida, and had no idea that the Village and Caverns they just purchased were inhabited by ghostly spirits. Each one was equally surprised by their own personal encounters with the paranormal on the grounds, inside the buildings and even inside the ancient caverns. Finally, after many unexplainable experiences, they called in our team of investigators to validate the hauntings. As related to CASPR investigators, all of the owners and employees experience what they call a sense of being watched as if someone is standing right behind them. Many people have reported seeing ghostly figures dressed in Civil War uniforms as well as dark, shadowy figures that disappear when you turn to look directly at them. Steve said, I was in the back of the cave in Diamond Chapel sweeping water out the back gate when I heard a voice in the room say what are you doing? I looked around and I was thinking that Marvin was in there or some of the kids that were coming for a field trip that day, so I didn't think much of it at the moment and kept on sweeping. Then, I started hearing whisperings, kind of like mumblings and murmurings and thought the kids were coming in. I went out of the cave and all the way to the top of the hill before I saw anyone. At that time I was getting very anxious and nervous and called up everyone to see where they were, to see if anyone was playing a joke on me. Marvin and Ginger were up front in the Depot talking with the kids so I had been all alone in the cave. Ginger Oates said, Around midnight a few weeks ago, we (she and brothers, Steve and David) noticed that one of the shutters had come open on the Jordan house. Steve said that was odd and shouldn't have happened. We had a flashlight so we walked over there to check it out. Just a few feet away from the shutter, we heard laughter. I thought the guys were cutting up, but it wasn't them. Whatever this thing was seemed to be right behind us, the laughter was very loud, and it just seemed like another person was in the room. It didn't feel sinister at all. It sounded like a young person, but you couldn't really tell if it was a young girl or boy. Something was definitely in there with us. David Oates had a slightly different experience that night in the Jordan house, which is not unusual with paranormal occurrences. CASPR has discovered that although a group of people may all hear or feel the same unexplainable event, some come away with more of an experience than others. David said, The first thing I heard that night in the Jordan house was a very loud, heavy sigh. Then came the child-like laughter. It didn't feel threatening at all. Equipment Used: 6 Super Night Shot Video Cameras 5 DVR's (Digital Voice Recorders) 6 Digital Cameras and EMF Meters Reported Sightings and Experiences: The Church: Upon arrival, CASPR Director, Karen went to the church to set up her video equipment. She took out her Gauss EMF meter and began to sweep the pews and pulpit area. Nothing registered, then, as she moved to the other side of the church, her EMF detector went off while sweeping it across one of the pews. The meter chirped loudly, then silenced as she moved to the right. Immediately, upon hearing the tone, she swept back across the same area and it sounded off again. Then, it was gone. She says that it was as if someone unseen was sitting in the pew. There is no electricity in the church and later an extension cord was run from the depot to accommodate the cameras. At this time, there was absolutely nothing inside the church that could have caused the EMF detector to go off. If anyone has information regarding this church from Blue Eye, MO, please contact us at [EMAIL PROTECTED] The Coffin Shop: An investigator was asking questions while attempting to
[Bug middle-end/33423] [4.2/4.3 regression]: internal compiler error: in expand_expr_real_1, at expr.c:8670
--- Comment #2 from hjl at lucon dot org 2007-09-15 03:43 --- It also fails on Linux/ia32 and Linux/x86-64. -- hjl at lucon dot org changed: What|Removed |Added GCC target triplet|ia64-unknown-linux-gnu | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33423
