[Bug target/32785] (hpux11.11)link test not allowed GCC_NO_EXECUTABLES.
-- cnstar9988 at gmail dot com changed: What|Removed |Added CC||cnstar9988 at gmail dot com Severity|normal |critical http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32785
[Bug target/32693] [H8] : ICE: in gen_rtx_SUBREG, at emit-rtl.c:693
--- Comment #1 from Sushil dot Kothawade at kpitcummins dot com 2007-07-17 06:10 --- Created an attachment (id=13928) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13928action=view) patch to get rid of ICE... Hi, Investigation Details : While debugging gcc, I found that the reason behind this behavior is definition of flags HAVE_insv and HAVE_extzv in insn-flags.h file that gets generated while building. define_expand insv and define_expand extzv insns from h8300.md file are responsible for these definitions. If the above patch is applied i.e. if the above insns are modified not to support h8sx target, much relaxed regression results are obtained. The number of passes increase by 451 and failures decrease by 447 for h8 family. Also,the code does not end into ICE. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32693
[Bug bootstrap/32785] (hpux11.11)link test not allowed GCC_NO_EXECUTABLES.
--- Comment #11 from pinskia at gcc dot gnu dot org 2007-07-17 06:36 --- Can you please stop changing the Severity? -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Severity|critical|normal http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32785
[Bug bootstrap/32785] (hpux11.11)link test not allowed GCC_NO_EXECUTABLES.
--- Comment #12 from cnstar9988 at gmail dot com 2007-07-17 06:43 --- (In reply to comment #11) Can you please stop changing the Severity? I can't change Priority, so I change Severity for testing only, :) I have download the latest gcc-4.1, but failed to build on hppa64. ftp://gcc.gnu.org/pub/gcc/snapshots/4.1-20070716/gcc-4.1-20070716.tar.bz2 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32785
[Bug target/32787] Sun Studio 12 Undefined symbol addl
--- Comment #3 from markwright at internode dot on dot net 2007-07-17
07:14 ---
Created an attachment (id=13929)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13929action=view)
Proposed patch for bug 32787
The proposed patch compiles with Sun Studio 12.
I wrote the following little test program:
goanna% cat ../../gcc/config/i386/test_host_detect_local_cpu.c
#include stdio.h
#include string.h
#include malloc.h
#include stdlib.h
#include config.h
#include system.h
#include coretypes.h
#include tm.h
const char *host_detect_local_cpu (int argc, const char **argv);
int main(int argc, char **argv)
{
const char *bargv[1] = { arch };
const char *local_cpu = host_detect_local_cpu (1, bargv);
printf(%s\n, local_cpu);
return 0;
}
void fancy_abort(const char *a, int b, const char *c)
{
abort();
}
goanna%
Compiling it with Sun Studio 12 give the following result:
goanna% /opt/SunStudio12/SUNWspro/bin/cc -c -errtags=yes +w -g -DIN_GCC
-DHAVE_CONFIG_H -I. -I. -I../../gcc -I../../gcc/. -I../../gcc/../include
-I./../intl -I../../gcc/../libcpp/include -I../../gcc/../libdecnumber
-I../libdecnumber-I. -I. -I../../gcc -I../../gcc/. -I../../gcc/../include
-I./../intl -I../../gcc/../libcpp/include -I../../gcc/../libdecnumber
-I../libdecnumber ../../gcc/config/i386/test_host_detect_local_cpu.c
goanna% /opt/SunStudio12/SUNWspro/bin/cc -c -errtags=yes +w -g -DIN_GCC
-DHAVE_CONFIG_H -I. -I. -I../../gcc -I../../gcc/. -I../../gcc/../include
-I./../intl -I../../gcc/../libcpp/include -I../../gcc/../libdecnumber
-I../libdecnumber-I. -I. -I../../gcc -I../../gcc/. -I../../gcc/../include
-I./../intl -I../../gcc/../libcpp/include -I../../gcc/../libdecnumber
-I../libdecnumber ../../gcc/config/i386/driver-i386.c
../../gcc/config/i386/driver-i386.c, line 126: warning: integer overflow
detected: op (E_INTEGER_OVERFLOW_DETECTED)
goanna% cc -o t driver-i386.o test_host_detect_local_cpu.o ../libcpp/libcpp.a
./../intl/libintl.a ../libiberty/libiberty.a ../libdecnumber/libdecnumber.a
goanna% ./t
-march=k8
goanna%
After applying the patch, the gcc build with Sun Studio 12 then fails
due to following Sun Studio 12 bug (Sun intend to patch this soon,
and this Sun Studio 12 bug 6470247 has nothing to do with this
gcc patch):
http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6470247
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32787
[Bug target/32787] Sun Studio 12 Undefined symbol addl
--- Comment #4 from pinskia at gcc dot gnu dot org 2007-07-17 07:37 --- No, my point is GCC_VERSION will always be defined even if you are not compiling with GCC. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32787
[Bug inline-asm/32788] New: Sun Studio 12 Undefined symbol addl
Compiling gcc-4.2.1-RC-20070712 with Sun Studio 12 on Solaris Express Community Edition b66: goanna% CC -V CC: Sun C++ 5.9 SunOS_i386 2007/05/03 goanna% With the environment variables: CXXCPP=CC -E -Xs CPP=cc -E -Xs LD=/opt/jdsbld/bin/ld-wrapper CXX64=/opt/SunStudio12/SUNWspro/bin/CC CXX32=/opt/SunStudio12/SUNWspro/bin/CC CXX=/opt/SunStudio12/SUNWspro/bin/CC CC64=/opt/SunStudio12/SUNWspro/bin/cc CC32=/opt/SunStudio12/SUNWspro/bin/cc CC=/opt/SunStudio12/SUNWspro/bin/cc CCDIR=/opt/SunStudio12/SUNWspro/bin Configured like: goanna% pwd /h/goanna/2/ts/gcc/gcc-4.2.1-RC-20070712 goanna% mkdir objdir goanna% cd objdir goanna% ../configure --prefix=/h/goanna/1/s_5.11/gcc --with-as=/usr/ccs/bin/as --with-ld=/usr/ccs/bin/ld --enable-shared ... The make fails with: /opt/SunStudio12/SUNWspro/bin/cc -c -g -DIN_GCC -DHAVE_CONFIG_H -I. -I. -I../../gcc -I../../gcc/. -I../../gcc/../include -I./../intl -I../../gcc/../libcpp/include -I../../gcc/../libdecnumber -I../libdecnumber -I. -I. -I../../gcc -I../../gcc/. -I../../gcc/../include -I./../intl -I../../gcc/../libcpp/include -I../../gcc/../libdecnumber -I../libdecnumber ../../gcc/config/i386/driver-i386.c ../../gcc/config/i386/driver-i386.c, line 96: warning: parameter in inline asm statement unused: %0 ../../gcc/config/i386/driver-i386.c, line 96: warning: parameter in inline asm statement unused: %2 ../../gcc/config/i386/driver-i386.c, line 96: warning: parameter in inline asm statement unused: %3 ../../gcc/config/i386/driver-i386.c, line 96: warning: parameter in inline asm statement unused: %4 ../../gcc/config/i386/driver-i386.c, line 103: warning: parameter in inline asm statement unused: %0 ../../gcc/config/i386/driver-i386.c, line 103: warning: parameter in inline asm statement unused: %2 ../../gcc/config/i386/driver-i386.c, line 103: warning: parameter in inline asm statement unused: %3 ../../gcc/config/i386/driver-i386.c, line 103: warning: parameter in inline asm statement unused: %4 ../../gcc/config/i386/driver-i386.c, line 113: warning: parameter in inline asm statement unused: %0 ../../gcc/config/i386/driver-i386.c, line 113: warning: parameter in inline asm statement unused: %2 ../../gcc/config/i386/driver-i386.c, line 113: warning: parameter in inline asm statement unused: %3 ../../gcc/config/i386/driver-i386.c, line 113: warning: parameter in inline asm statement unused: %4 ../../gcc/config/i386/driver-i386.c, line 117: warning: parameter in inline asm statement unused: %0 ../../gcc/config/i386/driver-i386.c, line 117: warning: parameter in inline asm statement unused: %2 ../../gcc/config/i386/driver-i386.c, line 117: warning: parameter in inline asm statement unused: %3 ../../gcc/config/i386/driver-i386.c, line 117: warning: parameter in inline asm statement unused: %4 ../../gcc/config/i386/driver-i386.c, line 118: warning: integer overflow detected: op /opt/SunStudio12/SUNWspro/bin/cc -g -DIN_GCC -DHAVE_CONFIG_H -o xgcc gcc.o opts-common.o gcc-options.o gccspec.o \ intl.o prefix.o version.o driver-i386.o ../libcpp/libcpp.a ./../intl/libintl.a ../libiberty/libiberty.a ../libdecnumber/libdecnumber.a Undefined first referenced symbol in file addldriver-i386.o ld: fatal: Symbol referencing errors. No output written to xgcc make[3]: *** [xgcc] Error 1 make[3]: Leaving directory `/h/goanna/2/ts/gcc/gcc-4.2.1-RC-20070712/objdir/gcc' make[2]: *** [all-stage1-gcc] Error 2 make[2]: Leaving directory `/h/goanna/2/ts/gcc/gcc-4.2.1-RC-20070712/objdir' make[1]: *** [stage1-bubble] Error 2 make[1]: Leaving directory `/h/goanna/2/ts/gcc/gcc-4.2.1-RC-20070712/objdir' make: *** [all] Error 2 Compilation exited abnormally with code 2 at Mon Jul 16 23:17:21 -- Summary: Sun Studio 12 Undefined symbol addl Product: gcc Version: 4.2.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: inline-asm AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: markwright at internode dot on dot net GCC build triplet: i386-pc-solaris2.11 GCC host triplet: i386-pc-solaris2.11 GCC target triplet: i386-pc-solaris2.11 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32788
[Bug inline-asm/32788] Sun Studio 12 Undefined symbol addl
--- Comment #1 from markwright at internode dot on dot net 2007-07-17 07:53 --- Sorry, accidently created a duplicate of 32787, closing 32788. *** This bug has been marked as a duplicate of 32787 *** -- markwright at internode dot on dot net changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32788
[Bug target/32787] Sun Studio 12 Undefined symbol addl
--- Comment #6 from markwright at internode dot on dot net 2007-07-17 07:57 --- Created an attachment (id=13930) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13930action=view) Patch to address comment #4. Simplified as pinskia noted: GCC_VERSION will always be defined even if you are not compiling with GCC. -- markwright at internode dot on dot net changed: What|Removed |Added Attachment #13929|0 |1 is obsolete|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32787
[Bug target/32787] Sun Studio 12 Undefined symbol addl
--- Comment #5 from markwright at internode dot on dot net 2007-07-17 07:53 --- *** Bug 32788 has been marked as a duplicate of this bug. *** -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32787
[Bug libfortran/32784] [win32] Using 'con' as assigned file generates Fortran runtime error: File 'con' does not exist
--- Comment #6 from dannysmith at users dot sourceforge dot net 2007-07-17
08:43 ---
(In reply to comment #4)
What name should I change 'con' to so that the write statement writes to the
console?
I think it should be CONOUT$ (ie you had it right the first time).
The following works with g77 (and the old Intel Fortran ivf compiler)
open(unit=29,file='CONOUT$')
write(29,100)
100 format('1Hello, world!')
end
The following works in C
#include fcntl.h
#include sys/stat.h
#include stdlib.h
int main()
{
int fd= _open (CONOUT$, _O_RDWR));
if (fd = 0)
_write (fd, Hello world, sizeof (Hello world));
return 0;
}
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32784
[Bug libgomp/32789] New: Profiling not possible with -fopenmp
Hi,
I noticed that profiling data are wrong if OpenMp is used via
-fopenmp.
I have only two #pragma omp parallel statements in a class and the
calling statistic of this class contructor is completly wrong (gprof
tells me this constructor is called far too often).
I found bug http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29935
related to OpenMP and profiling but it seems to be a different issue.
I tried to reproduce it on a minimal example but could not get very
wrong results. Nevertheless I have a simple example which results in
different profiling data depending on the -fopenmp option:
#include vector
class VectorStuff
{
public:
VectorStuff()
{
}
void AddVectors(int n, const double *x1, const double *x2, double *y);
};
void VectorStuff::AddVectors(int n, const double *x1, const double *x2, double
*y)
{
y = new double[n];
#pragma omp parallel for
for (int i=0; in; ++i)
y[i] = x1[i] + x2[i];
}
int main()
{
VectorStuff vec;
const int n = 1000;
std::vectordouble x1(n, -2), x2(n, 2);
double *y;
vec.AddVectors(n, x1[0], x2[0], y);
return 0;
}
Comparig the output of
g++-4.2svn -pg -g -fopenmp main.cpp; ./a.out; gprof ./a.out ./a.out.gprof1
g++-4.2svn -pg -g main.cpp; ./a.out; gprof ./a.out ./a.out.gprof2
results in
--- a.out.gprof12007-07-17 10:47:04.0 +0200
+++ a.out.gprof22007-07-17 10:47:13.0 +0200
@@ -37,7 +37,6 @@
0.00 0.00 0.002 0.00 0.00 void
std::_Destroydouble*, double(double*, double*, std::allocatordouble)
0.00 0.00 0.001 0.00 0.00
VectorStuff::AddVectors(int, double const*, double const*, double*)
0.00 0.00 0.001 0.00 0.00
VectorStuff::VectorStuff()
- 0.00 0.00 0.001 0.00 0.00 main
% the percentage of the total running time of the
time program used by this function.
I agree that this is not very critical for this example, but for other
programs profiling is just useless.
$ c++-4.2svn --version
c++-4.2svn (GCC) 4.2.1 20070713 (prerelease)
--
Summary: Profiling not possible with -fopenmp
Product: gcc
Version: 4.2.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libgomp
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: jensseidel at users dot sf dot net
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=32789
[Bug bootstrap/32785] (hpux11.11)link test not allowed GCC_NO_EXECUTABLES.
--- Comment #13 from rask at sygehus dot dk 2007-07-17 09:53 --- Read config.log. Look for messages about collect2. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32785
[Bug libgomp/32789] Profiling not possible with -fopenmp
--- Comment #1 from theodore dot papadopoulo at sophia dot inria dot fr 2007-07-17 09:55 --- This is similar to the comment (maybe misplaced) of http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31862 The problem, as far as I understand it is that any kind of profiling (gprof, profile-arcs, probably mudflap, ...) rely on some global variables that would need to be made thread local. I do not know how difficult this would be however -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32789
[Bug bootstrap/32785] (hpux11.11)link test not allowed GCC_NO_EXECUTABLES.
--- Comment #14 from cnstar9988 at gmail dot com 2007-07-17 09:56 --- I havee set --build/--host/--target with the same value, so I think I build native gcc. why not GCC_NO_EXECUTABLES. --build=hppa64-hp-hpux11.11 --host=hppa64-hp-hpux11.11 --target=hppa64-hp-hpux11.11 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32785
[Bug rtl-optimization/32790] New: REG_N_SETS holds wrong value
In ./gcc/regclass.c:reg_scan_mark_refs() there is this source code: case SET: /* Count a set of the destination if it is a register. */ for (dest = SET_DEST (x); GET_CODE (dest) == SUBREG || GET_CODE (dest) == STRICT_LOW_PART || GET_CODE (dest) == ZERO_EXTEND; dest = XEXP (dest, 0)) ; This code counts the number of times a REG is changed (eventually used in combine, reload, regrenumber, ...) IMHO, the ZERO_EXTEND is a typo and should be a ZERO_EXTRACT, because (set (zero_extract (reg foo bar)) are RTX that are actually generated in some define_insn/define_expand insv (provided HAVE_insv) if the source deals with bitfields. As this code can already be seen in GCC 3.3.*, I guess this is not very critical. But it leads to problems in a non-standard target (tricore) that uses the information in REG_N_SETS(). Greets, Georg-Johann Lay [EMAIL PROTECTED] -- Summary: REG_N_SETS holds wrong value Product: gcc Version: unknown Status: UNCONFIRMED Severity: minor Priority: P3 Component: rtl-optimization AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: georgjohann at web dot de GCC build triplet: any GCC host triplet: any GCC target triplet: any http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32790
[Bug bootstrap/32785] (hpux11.11)link test not allowed GCC_NO_EXECUTABLES.
--- Comment #15 from cnstar9988 at gmail dot com 2007-07-17 10:04 --- yes, I seee. ld: Unsatisfied symbol pthread_mutex_unlock in file /home/beans/gcc-build/build/./gcc/libgcc_eh.a[unwind-dw2-fde.o] ld: Unsatisfied symbol pthread_mutex_lock in file /home/beans/gcc-build/build/./gcc/libgcc_eh.a[unwind-dw2-fde.o] I also export the following var, failed... LDFLAGS=-lpthread LDFLAGS_FOR_BUILD=-lpthread LDFLAGS_FOR_TARGET=-lpthread -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32785
[Bug libgomp/32789] Profiling not possible with -fopenmp
--- Comment #2 from theodore dot papadopoulo at sophia dot inria dot fr 2007-07-17 10:11 --- And to reply to myself, it needs either to use thread local storage to hold the counters and then to add some piece of code to fuse the values of the various counters at the end of a thread (which might not be easy ?) or to use atomic operations (which existence depends on the architecture, but I hope that all multi-core processors have such instructions). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32789
[Bug rtl-optimization/32790] REG_N_SETS holds wrong value
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-07-17 10:22 --- 56 kenner /* Count a set of the destination if it is a register. */ 56 kenner for (dest = SET_DEST (x); 56 kenner GET_CODE (dest) == SUBREG || GET_CODE (dest) == STRICT_LOW_PART 56 kenner || GET_CODE (dest) == ZERO_EXTEND; 56 kenner dest = XEXP (dest, 0)) 56 kenner ; This comes from the begining of time :). ZERO_EXTRACT has been there since the begining of time also: 70 kenner /* Similar for unsigned bit-field. */ 70 kenner DEF_RTL_EXPR(ZERO_EXTRACT, zero_extract, eee, 'b') -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Severity|minor |normal Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2007-07-17 10:22:51 date|| Version|unknown |4.3.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32790
[Bug libgomp/32789] Profiling not possible with -fopenmp
--- Comment #3 from jensseidel at users dot sf dot net 2007-07-17 10:24 --- (In reply to comment #2) And to reply to myself, it needs either to use thread local storage to hold the counters and then to add some piece of code to fuse the values of the various counters at the end of a thread (which might not be easy ?) or to use atomic operations (which existence depends on the architecture, but I hope that all multi-core processors have such instructions). (Don't forget about SMP machines, I have a SGI Octane (2 x Mips R12000 CPUs).) An Open MPI related discussion about atomic operations happened the last days, because architecture specific assembler code failed again for some exotic platforms. See e.g. http://lists.debian.org/debian-mips/2007/07/msg00036.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32789
[Bug libgomp/32789] Profiling not possible with -fopenmp
--- Comment #4 from pinskia at gcc dot gnu dot org 2007-07-17 10:24 --- grpof profiling is all done via a call to mcount and mcount is controlled by libc (in the GNU/Linux case glibc). So I doubt this is a GCC bug. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32789
Re: [Bug libgomp/32789] Profiling not possible with -fopenmp
On 17 Jul 2007 10:24:12 -, jensseidel at users dot sf dot net [EMAIL PROTECTED] wrote: An Open MPI related discussion about atomic operations happened the last days, because architecture specific assembler code failed again for some exotic platforms. And that is the reason why GCC added atomic builtins when openmp came in also. There are manuals for a reason :). -- Pinski
[Bug libgomp/32789] Profiling not possible with -fopenmp
--- Comment #5 from pinskia at gmail dot com 2007-07-17 10:26 --- Subject: Re: Profiling not possible with -fopenmp On 17 Jul 2007 10:24:12 -, jensseidel at users dot sf dot net [EMAIL PROTECTED] wrote: An Open MPI related discussion about atomic operations happened the last days, because architecture specific assembler code failed again for some exotic platforms. And that is the reason why GCC added atomic builtins when openmp came in also. There are manuals for a reason :). -- Pinski -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32789
[Bug bootstrap/32785] (hpux11.11)link test not allowed GCC_NO_EXECUTABLES.
--- Comment #16 from cnstar9988 at gmail dot com 2007-07-17 10:30 --- Created an attachment (id=13931) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13931action=view) config.log config.log -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32785
[Bug fortran/31259] ICE on elemental character function
--- Comment #2 from dfranke at gcc dot gnu dot org 2007-07-17 10:38 --- Please note that the problem is not limited to character functions: $ cat pr31529.f90 print *, bar((/2, 3/)) contains elemental function bar(i) integer, intent(in) :: i integer :: a(i:i) a = i bar = a(i) end function bar end Here, dummy I is used as specification expression in array bounds and accepted by gfortran (20070716). Although there is no ICE and the result is as one would expect, the code is still invalid. -- dfranke at gcc dot gnu dot org changed: What|Removed |Added CC||dfranke at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31259
[Bug middle-end/32791] New: missed optimization after inline functions with multiple return statements
If an inline function has multiple return statements the compiler misses the
opportunity to optimize the code following the function for return statements
returning constants.
here is a little test case to illustrate the problem:
static inline int inline1(int* val) {
return 2;
}
static inline int inline2(int* val) {
if(val == 0) return 1;
++*val;
return 3;
}
void a(int*);
void b(int*);
void c(int*);
void d(int*);
void func1(int* val) {
const void *const labels[] = { a, b, c, d };
goto *labels[inline1(val)];
a: a(val);
b: b(val);
c: c(val);
d: d(val);
}
void func2(int* val) {
const void *const labels[] = { a, b, c, d };
goto *labels[inline2(val)];
a: a(val);
b: b(val);
c: c(val);
d: d(val);
}
compiled with gcc -S -O3 -fomit-frame-pointer -march=nocona -Wall test.c
for func1, the compiler optimizes the code after the inline function knowing
that inline1 always returns 2.
in func2 however, the compiler generates a computed goto instead of knowing
that inline2 always returns 1 or 3.
optimal code for inline2 would be something like this:
testl %eax, %eax
je b
addl $1, (%eax)
jmpd
gcc -v
Using built-in specs.
Target: i686-pc-linux-gnu
Configured with: /var/tmp/portage/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 --disable-libmudflap --disable-libssp --disable-libgcj
--enable-languages=c,c++ --enable-shared --enable-threads=posix
--enable-__cxa_atexit --enable-clocale=gnu
Thread model: posix
gcc version 4.1.2 (Gentoo 4.1.2)
--
Summary: missed optimization after inline functions with multiple
return statements
Product: gcc
Version: 4.1.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: middle-end
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: manuelle at ee dot ethz dot ch
GCC build triplet: i686-pc-linux-gnu
GCC host triplet: i686-pc-linux-gnu
GCC target triplet: i686-pc-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32791
[Bug libgomp/32789] Profiling not possible with -fopenmp
--- Comment #6 from jensseidel at users dot sf dot net 2007-07-17 11:00 --- (In reply to comment #4) grpof profiling is all done via a call to mcount and mcount is controlled by libc (in the GNU/Linux case glibc). So I doubt this is a GCC bug. OK, for the record: I use OpenSuse 10.2 with glibc 2.5. According to http://www.cs.utah.edu/dept/old/texinfo/as/gprof.html#SEC1 mcount occurs in the gprof output but I haven't seen this yet (gprof 2.17.50.0.5). (In reply to comment #5) And that is the reason why GCC added atomic builtins when openmp came in also. There are manuals for a reason :). I don't understand this but it may be off topic. (Should I inform the Open MPI people about atomic assembler locking code in gcc so that they can reuse it?) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32789
[Bug ada/32792] New: Assert_Failure sinfo.adb:1730
-- bug.adb with Text_IO; use Text_IO; procedure Bug is typeS is range 0 .. 1000; begin Put_Line (S'Image (S'Integer_Value (12.8))); end Bug; ** gnat make -gnatf -gnato -gnatv -gnatVa -gnatwa -gnaty bug.adb gcc-4.1 -c -gnatf -gnato -gnatv -gnatVa -gnatwa -gnaty bug.adb GNAT 4.1.2 20061115 (prerelease) (Debian 4.1.1-22) Copyright 1992-2005 Free Software Foundation, Inc. Compiling: bug.adb (source file time stamp: 2007-07-17 11:05:32) +===GNAT BUG DETECTED==+ | 4.1.2 20061115 (prerelease) (Debian 4.1.1-22) (i486-pc-linux-gnu)| | Assert_Failure sinfo.adb:1730| | Error detected at bug.adb:7:24 | ... bug.adb 8 lines: No errors compilation abandoned gnatmake: bug.adb compilation error make: *** [bug] Fehler 4 -- Summary: Assert_Failure sinfo.adb:1730 Product: gcc Version: 4.1.2 Status: UNCONFIRMED Severity: trivial Priority: P3 Component: ada AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: bug63 at freakmail dot de http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32792
[Bug tree-optimization/19716] Segfault with -ftree-vectorize
--- Comment #11 from reichelt at gcc dot gnu dot org 2007-07-17 11:05 --- This got fixed by the patch for PR 25413. *** This bug has been marked as a duplicate of 25413 *** -- reichelt at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19716
[Bug target/25413] wrong alignment or incorrect address computation in vectorized code on Pentium 4 SSE
--- Comment #12 from reichelt at gcc dot gnu dot org 2007-07-17 11:05 --- *** Bug 19716 has been marked as a duplicate of this bug. *** -- reichelt at gcc dot gnu dot org changed: What|Removed |Added CC||bangerth at dealii dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25413
[Bug rtl-optimization/32790] REG_N_SETS holds wrong value
--- Comment #2 from georgjohann at web dot de 2007-07-17 11:13 --- (In reply to comment #1) This comes from the begining of time :). ZERO_EXTRACT has been there since the begining of time also: 70 kenner DEF_RTL_EXPR(ZERO_EXTRACT, zero_extract, eee, 'b') So what is the conclusion...? At least the following backends implement insv as (define_*** insv [(set (zero_extract (match_operand 0 ... with a predicate that allows registers: i386, pa, sh, c4x, arm, vax, ia64, m68k, ip2k, ns32k, rs6000, h8300, mcore Uses of REG_N_SETS(*) are spread all over the RTL passes and many of them rely on REG_N_SETS(*) == 1 etc. If such a condition holds but is incorrect because (set (zero_extract is ignored that may lead to a bug in the output, e.g. due to a wrong replacement. -- georgjohann at web dot de changed: What|Removed |Added Severity|normal |minor Version|4.3.0 |unknown http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32790
[Bug target/32522] [4.3 Regression] Bootstrap failure on Alpha due to pointer-plus changes
--- Comment #7 from ro at techfak dot uni-bielefeld dot de 2007-07-17 11:28 --- Subject: Re: [4.3 Regression] Bootstrap failure on Alpha due to pointer-plus changes belyshev at depni dot sinp dot msu dot ru writes: You need the following patch to fix this bug (but bootstrap on alpha is still broken for other reasons, see bug 32747): Thanks. A C-only bootstrap (alpha-dec-osf5.1b and alpha-dec-osf4.0f) completes with this patch, but if I build with all languages, cc1 segfaults in malloc building the stage 2 libdecnumber: $ source='/vol/gcc/src/gcc-dist/libdecnumber/decNumber.c' object='decNumber.o' libtool=no /vol/gccsrc/obj/gcc-4.3.0-20070712/4.0f-gcc/./prev-gcc/xgcc -B/vol/gccsrc/obj/gcc-4.3.0-20070712/4.0f-gcc/./prev-gcc/ -B/vol/gcc/alpha-dec-osf4.0f/bin/ -I/vol/gcc/src/gcc-dist/libdecnumber -I. -g -O2 -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition -Wmissing-format-attribute -Wcast-qual -pedantic -Wno-long-long -Werror -I/vol/gcc/src/gcc-dist/libdecnumber -I. -c /vol/gcc/src/gcc-dist/libdecnumber/decNumber.c /vol/gcc/src/gcc-dist/libdecnumber/decNumber.c: In function 'decNumberPower': /vol/gcc/src/gcc-dist/libdecnumber/decNumber.c:1242: internal compiler error: Segmentation fault Please submit a full bug report, with preprocessed source if appropriate. See URL:http://gcc.gnu.org/bugs.html for instructions. I cannot get a proper stack trace, though. The file compiles at -O. Rainer -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32522
[Bug target/24826] [4.1/4.2/4.3 Regression] Incorrect default options
--- Comment #3 from saurabh dot verma at codito dot com 2007-07-17 11:50 --- This is fixed on mainline with the following patch. -- trunk/gcc/config/h8300/h8300.c 2005/06/25 01:22:41 101314 +++ trunk/gcc/config/h8300/h8300.c 2006/08/28 13:51:04 116509 @@ -5746,4 +5746,7 @@ #undef TARGET_MACHINE_DEPENDENT_REORG #define TARGET_MACHINE_DEPENDENT_REORG h8300_reorg +#undef TARGET_DEFAULT_TARGET_FLAGS +#define TARGET_DEFAULT_TARGET_FLAGS TARGET_DEFAULT + struct gcc_target targetm = TARGET_INITIALIZER; Can put this in 4.1 branch also and mark this bug as fixed? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24826
[Bug c/32793] New: [4.3 regression] ICE dwarf2out
gcc -O2 -g -c on mayalias-2.i causes: Using built-in specs. Target: i686-pc-linux-gnu Configured with: ../gcc-4.3.0/configure --prefix=/usr --mandir=/usr/share/man --infodir=/usr/share/info --disable-nls --disable-multilib --disable-werror --disable-libunwind-exceptions --enable-checking --enable-decimal-float --enable-shared --enable-tls --enable-threads=posix --enable-bootstrap --enable-__cxa_atexit --enable-clocale=gnu --enable-languages=c,c++,fortran --with-cpu=pentium3 --with-system-zlib Thread model: posix gcc version 4.3.0 20070716 (experimental) /usr/libexec/gcc/i686-pc-linux-gnu/4.3.0/cc1 -fpreprocessed mayalias-2.i -quiet -dumpbase mayalias-2.i -mtune=pentium3 -auxbase mayalias-2 -g -O2 -version -o /tmp/ccMrEVGp.s GNU C version 4.3.0 20070716 (experimental) (i686-pc-linux-gnu) compiled by GNU C version 4.3.0 20070716 (experimental), GMP version 4.2.1, MPFR version 2.2.1-p5. GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096 Compiler executable checksum: ed6036fdbf7087c7658ad607324e2213 mayalias-2.c:2: internal compiler error: in splice_child_die, at dwarf2out.c:5630 Please submit a full bug report, with preprocessed source if appropriate. See URL:http://gcc.gnu.org/bugs.html for instructions. -- Summary: [4.3 regression] ICE dwarf2out Product: gcc Version: 4.3.0 Status: UNCONFIRMED Severity: major Priority: P3 Component: c AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: rosana07a at gmail dot com GCC build triplet: i696 GCC host triplet: i686 GCC target triplet: i686 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32793
[Bug c/32793] [4.3 regression] ICE dwarf2out
--- Comment #1 from rosana07a at gmail dot com 2007-07-17 12:09 --- Created an attachment (id=13932) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13932action=view) prerocessed from gcc.c-torture/execute -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32793
[Bug libfortran/32784] [win32] Using 'con' as assigned file generates Fortran runtime error: File 'con' does not exist
--- Comment #7 from steven dot chapel at sbcglobal dot net 2007-07-17 12:49 --- (In reply to comment #5) if all its trying to do is WRITE to the console use WRITE(unit=6) and don't give it a filename at all. Will this work for you? Not really. It's been written that way so that you can easily change where the output goes by changing one line of code. Hardcoding the output to go to the console defeats the purpose. I'm also not the author of the code, and I don't want to have to manually change every line of code like that in my local copy with each release of NONMEM. I think it should be CONOUT$ (ie you had it right the first time). The following works with g77 (and the old Intel Fortran ivf compiler) That's what it was the first time, when I got Fortran runtime error: Bad file descriptor. That's why I changed it to con. If there's something else I can change it to, I can fairly easily manually make that change with each release of NONMEM because it's only one line of code. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32784
[Bug c/32793] [4.3 regression] ICE dwarf2out
--- Comment #2 from pinskia at gcc dot gnu dot org 2007-07-17 12:51 --- *** This bug has been marked as a duplicate of 28834 *** -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32793
[Bug debug/28834] [4.0/4.1/4.2/4.3 Regression] -g crashes sometimes when using may_alias and structs (ICE in splice_child_die)
--- Comment #26 from pinskia at gcc dot gnu dot org 2007-07-17 12:51 --- *** Bug 32793 has been marked as a duplicate of this bug. *** -- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||rosana07a at gmail dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28834
[Bug other/32783] gcc-4_3-trunk/libiberty/configure - for ac_func gettimeofday ... gettimeofday - tests twice
--- Comment #4 from rob1weld at aol dot com 2007-07-17 12:56 --- (In reply to comment #3) They are duplicated because they are different sections of the case statement. Nothing we can do about this. that one is an autoconf issue an not the way we coded configure.ac That is what I said. I am repening this because of the title gettimeofday ! gcc-4_3-trunk/libiberty/configure.ac # These are neither executed nor required, but they help keep # autoheader happy without adding a bunch of text to acconfig.h. if test x = y; then AC_CHECK_FUNCS(asprintf atexit basename bcmp bcopy bsearch bzero calloc clock \ getcwd getpagesize gettimeofday index insque mkstemps memchr memcmp memcpy \ memmove mempcpy memset putenv random rename rindex sigsetmask \ strcasecmp setenv stpcpy stpncpy strchr strdup strncasecmp strndup strrchr strstr \ strtod strtol strtoul strverscmp tmpnam vasprintf vfprintf vprintf \ vsprintf waitpid getrusage on_exit psignal strerror strsignal \ sysconf times sbrk gettimeofday ffs snprintf vsnprintf \ pstat_getstatic pstat_getdynamic sysmp getsysinfo table sysctl wait3 wait4 \ realpath canonicalize_file_name __fsetlocking) AC_CHECK_DECLS([basename, ffs, asprintf, vasprintf, snprintf, vsnprintf]) AC_DEFINE(HAVE_SYS_ERRLIST, 1, [Define if you have the sys_errlist variable.]) AC_DEFINE(HAVE_SYS_NERR,1, [Define if you have the sys_nerr variable.]) AC_DEFINE(HAVE_SYS_SIGLIST, 1, [Define if you have the sys_siglist variable.]) fi See line 364 and line 369 ? 364: getcwd getpagesize gettimeofday index insque mkstemps memchr memcmp memcpy \ 369: sysconf times sbrk gettimeofday ffs snprintf vsnprintf \ See line 552 in gcc-4_3-trunk/libiberty/configure.ac ? getcwd getpagesize getrusage gettimeofday gettimeofday \ _WE_ are the ones who write the .ac files we can remove the second occurance of gettimeofday to fix this bug. Perhaps the writer intended _S_ettimeofday for the first occurance. Please review stuff when your not tired. No problem, it happens to me too. -- rob1weld at aol dot com changed: What|Removed |Added Status|RESOLVED|UNCONFIRMED Resolution|INVALID | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32783
[Bug libgcj/32781] Build breaks - libstdc++-v3/include/bits/stl_algobase.h: In function '_OI std::__copy_aux(_II, _II, _OI)': error: expected primary-expression before ')' token
--- Comment #7 from rob1weld at aol dot com 2007-07-17 13:04 --- After my moc-qt4 fix to the Makefile I have test results to prove it built: Results for 4.3.0 20070716 (experimental) testsuite on i686-pc-linux-gnu http://gcc.gnu.org/ml/gcc-testresults/2007-07/msg00721.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32781
[Bug libgcj/24403] --enable-java-awt=qt fails to build
--- Comment #15 from rob1weld at aol dot com 2007-07-17 13:05 --- After my moc-qt4 fix to the Makefile I have test results to prove it built: Results for 4.3.0 20070716 (experimental) testsuite on i686-pc-linux-gnu http://gcc.gnu.org/ml/gcc-testresults/2007-07/msg00721.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24403
[Bug fortran/32627] [ISO Bind C] Accept c_f_pointer for TYPE
--- Comment #3 from burnus at gcc dot gnu dot org 2007-07-17 15:25 --- Also http://www.lrz-muenchen.de/services/software/mathematik/gsl/fortran/index.html fails with the same error. (One needs to change g95) into g95|gfortran) in configure.) This is related in so far that it is c_f_pointer, but it fails for a different reason: SHAPE can be any integer kind, but gfortran only accepts the default kind. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32627
[Bug middle-end/32777] wrong-code with -O -ftracer
--- Comment #1 from wouter dot vermaelen at scarlet dot be 2007-07-17 16:57 --- Problem went away in SVN revision 126700. I tried these revisions: 126536 OK 126568 OK 126572 OK 126573-126586 failed to build gcc 126587 WRONG 126600 WRONG 126664 WRONG 126680 WRONG 126688 WRONG 126696 WRONG 126698 WRONG 126699 WRONG 126700 OK 126702 OK -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32777
[Bug fortran/31320] Illegal read with gfortran.dg/alloc_comp_assign_2.f90 and *_3.f90
--- Comment #8 from pault at gcc dot gnu dot org 2007-07-17 17:07 --- (In reply to comment #7) Tobias, Does the patch fix this, please? The testcase that you sent me breaks gfortran in other places and probably should have a PR all of its very own. (try the FORALL part separately). Cheers Paul -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31320
[Bug bootstrap/32794] New: GCC (SVN) naive build fails due to use of '%I64d'
Native builds of GCC (SVN) fails on i686-pc-mingw32 with: /home/gdr/Desktop/sandbox/egcs/./prev-gcc/xgcc -B/home/gdr/Desktop/sandbox/egcs/./prev-gcc/ -B/home/gdr/i686-pc-mingw32/bin/ -c -g -O2 -DIN_GCC -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition -Wmissing-format-attribute -pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -Werror -fno-common -DHAVE_CONFIG_H -I. -I. -I../../../benchwork/gcc.svn/gcc -I../../../benchwork/gcc.svn/gcc/. -I../../../benchwork/gcc.svn/gcc/../include -I../../../benchwork/gcc.svn/gcc/../libcpp/include -I/usr/local/include -I/usr/local/include -I../../../benchwork/gcc.svn/gcc/../libdecnumber -I../../../benchwork/gcc.svn/gcc/../libdecnumber/dpd -I../libdecnumber ../../../benchwork/gcc.svn/gcc/bt-load.c -o bt-load.o cc1.exe: warnings being treated as errors ../../../benchwork/gcc.svn/gcc/bt-load.c: In function 'migrate_btr_defs': ../../../benchwork/gcc.svn/gcc/bt-load.c:1416: error: ISO C does not support the 'I' printf flag ../../../benchwork/gcc.svn/gcc/bt-load.c:1416: error: format '%I64d' expects type 'int', but argument 4 has type 'gcov_type' make[3]: *** [bt-load.o] Error 1 make[3]: Leaving directory `/home/gdr/Desktop/sandbox/egcs/gcc' -- Summary: GCC (SVN) naive build fails due to use of '%I64d' Product: gcc Version: 4.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: bootstrap AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: gdr at gcc dot gnu dot org GCC build triplet: native build GCC host triplet: i868-pc-mingw32 GCC target triplet: native build http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32794
[Bug fortran/32665] allocatable array on lhs deleted while still in use on rhs
--- Comment #7 from pault at gcc dot gnu dot org 2007-07-17 17:23 --- Subject: Bug 32665 Author: pault Date: Tue Jul 17 17:22:44 2007 New Revision: 126703 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=126703 Log: 2007-07-17 Paul Thomas [EMAIL PROTECTED] PR fortran/31320 PR fortran/32665 * trans-expr.c (gfc_trans_subcomponent_assign): Ensure that renormalization unity base is done independently of existing lbound value. (gfc_trans_scalar_assign): If rhs is not a variable, put lse-pre after rse-pre to ensure that de-allocation of lhs occurs after evaluation of rhs. 2007-07-17 Paul Thomas [EMAIL PROTECTED] PR fortran/31320 PR fortran/32665 * gfortran.dg/alloc_comp_constructor_3.f90: New test. Added: trunk/gcc/testsuite/gfortran.dg/alloc_comp_constructor_3.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/trans-expr.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32665
[Bug fortran/31320] Illegal read with gfortran.dg/alloc_comp_assign_2.f90 and *_3.f90
--- Comment #9 from pault at gcc dot gnu dot org 2007-07-17 17:23 --- Subject: Bug 31320 Author: pault Date: Tue Jul 17 17:22:44 2007 New Revision: 126703 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=126703 Log: 2007-07-17 Paul Thomas [EMAIL PROTECTED] PR fortran/31320 PR fortran/32665 * trans-expr.c (gfc_trans_subcomponent_assign): Ensure that renormalization unity base is done independently of existing lbound value. (gfc_trans_scalar_assign): If rhs is not a variable, put lse-pre after rse-pre to ensure that de-allocation of lhs occurs after evaluation of rhs. 2007-07-17 Paul Thomas [EMAIL PROTECTED] PR fortran/31320 PR fortran/32665 * gfortran.dg/alloc_comp_constructor_3.f90: New test. Added: trunk/gcc/testsuite/gfortran.dg/alloc_comp_constructor_3.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/trans-expr.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31320
[Bug bootstrap/32794] GCC (SVN) naive build fails due to use of '%I64d'
-- gdr 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-07-17 17:35:41 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32794
[Bug fortran/32665] allocatable array on lhs deleted while still in use on rhs
--- Comment #8 from pault at gcc dot gnu dot org 2007-07-17 17:49 --- Fixed on trunk. Paul -- pault at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32665
[Bug other/32783] gcc-4_3-trunk/libiberty/configure - for ac_func gettimeofday ... gettimeofday - tests twice
--- Comment #5 from dj at redhat dot com 2007-07-17 17:52 --- Subject: Re: gcc-4_3-trunk/libiberty/configure - for ac_func gettimeofday ... gettimeofday - tests twice I removed the duplicate from the msdosdjgpp case. svn rev 126704 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32783
[Bug fortran/32795] New: Leaking memory (generated prog) with type constructor allocatable components
Taken from my remark to PR31320, http://gcc.gnu.org/ml/gcc-patches/2007-07/msg01457.html The generated executable leaks memory: 96 bytes in 1 blocks are definitely lost in loss record 1 of 2 at 0x4C22D06: malloc (in /usr/lib64/valgrind/amd64-linux/vgpreload_memcheck.so) by 0x40122B: MAIN__ (alloc_comp_assign_2.f90:11) by 0x401EEB: main (fmain.c:22) 96 bytes in 1 blocks are definitely lost in loss record 2 of 2 at 0x4C22D06: malloc (in /usr/lib64/valgrind/amd64-linux/vgpreload_memcheck.so) by 0x400BCA: MAIN__ (alloc_comp_assign_2.f90:10) by 0x401EEB: main (fmain.c:22) for this stripped down test case type :: a integer, allocatable :: i(:) end type a type :: b type (a), allocatable :: at(:) end type b type(a) :: x(2) type(b) :: y(2) integer i y(1) = b ((/x(1),x(2)/)) y(2) = b ((/x(2),x(1)/)) forall (i=1:2) y(i) = b ((/x(i)/)) end Paul remarked: The testcase that you sent me breaks gfortran in other places and probably should have a PR all of its very own. (try the FORALL part separately). -- Summary: Leaking memory (generated prog) with type constructor allocatable components Product: gcc Version: 4.3.0 Status: UNCONFIRMED Keywords: wrong-code 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=32795
[Bug fortran/31320] Illegal read with gfortran.dg/alloc_comp_assign_2.f90 and *_3.f90
--- Comment #10 from burnus at gcc dot gnu dot org 2007-07-17 17:58 --- Does the patch fix this, please? Yes, otherwise I would have blamed you in the patch review ;-) The testcase that you sent me breaks gfortran in other places and probably should have a PR all of its very own. (try the FORALL part separately). I now filled PR 32795; I had hoped it would be something obvious, but it is seemingly not. Thanks for fixing this PR! -- burnus at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31320
[Bug c/32796] New: internal compiler error: tree check: expected integer_type or enumeral_type or boolean_type or real_type, have pointer_type in int_fits_type_p
$ /usr/local/DIR/gcc-svn20070717/bin/gcc -Wp,-MD,drivers/kvm/.mmu.o.d -nostdinc -isystem /usr/local/DIR/gcc-svn20070717/lib/gcc/i686-pc-linux-gnu/4.3.0/include -D__KERNEL__ -Iinclude -include include/linux/autoconf.h -Wall -Wundef -Wstrict-prototypes -Wno-trigraphs -fno-strict-aliasing -fno-common -Werror-implicit-function-declaration -O1 -pipe -msoft-float -mregparm=3 -freg-struct-return -mpreferred-stack-boundary=2 -march=athlon -ffreestanding -maccumulate-outgoing-args -DCONFIG_AS_CFI=1 -DCONFIG_AS_CFI_SIGNAL_FRAME=1 -Iinclude/asm-i386/mach-generic -Iinclude/asm-i386/mach-default -fno-omit-frame-pointer -fno-optimize-sibling-calls -fasynchronous-unwind-tables -fno-stack-protector -Wdeclaration-after-statement -Wno-pointer-sign-DKBUILD_STR(s)=#s -DKBUILD_BASENAME=KBUILD_STR(mmu) -DKBUILD_MODNAME=KBUILD_STR(kvm) -c -o drivers/kvm/mmu.o drivers/kvm/mmu.c drivers/kvm/mmu.c: In function ânonpaging_mapâ: drivers/kvm/mmu.c:831: internal compiler error: tree check: expected integer_type or enumeral_type or boolean_type or real_type, have pointer_type in int_fits_type_p, at tree.c:6198 Please submit a full bug report, with preprocessed source if appropriate. See URL:http://gcc.gnu.org/bugs.html for instructions. -- Summary: internal compiler error: tree check: expected integer_type or enumeral_type or boolean_type or real_type, have pointer_type in int_fits_type_p Product: gcc Version: 4.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: bunk at stusta dot de GCC build triplet: i686-pc-linux-gnu GCC host triplet: i686-pc-linux-gnu GCC target triplet: i686-pc-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32796
[Bug c/32796] [4.3 Regression] internal compiler error: tree check: expected integer_type or enumeral_type or boolean_type or real_type, have pointer_type in int_fits_type_p
--- Comment #1 from bunk at stusta dot de 2007-07-17 18:05 --- Created an attachment (id=13933) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13933action=view) preprocessed source -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32796
[Bug fortran/32797] New: [ISO C Binding] Internal Error: gfc_basic_typename(): Undefined type
The following - valid? - program produces an ICE in gfortran. Full program: http://atom.princeton.edu/donev/Fortran/DLL/dlfcn.f90 (Should be checked after the problem in the snippet below has been fixed.) END MODULE ISO_C_UTILITIES 1 Internal Error at (1): gfc_basic_typename(): Undefined type (This snippet compiles with g95 and NAG f95, however, the generated C code of NAG f95 does not compile with gcc [In function 'iso_c_utilities_MP_c_f_string': conflicting types for 'strlen'].) MODULE ISO_C_UTILITIES USE ISO_C_BINDING implicit none CHARACTER(C_CHAR), DIMENSION(1), SAVE, TARGET, PRIVATE :: dummy_string=? CONTAINS FUNCTION C_F_STRING(CPTR) RESULT(FPTR) TYPE(C_PTR), INTENT(IN) :: CPTR ! The C address CHARACTER(KIND=C_CHAR), DIMENSION(:), POINTER :: FPTR INTERFACE FUNCTION strlen(string) RESULT(len) BIND(C,NAME=strlen) USE ISO_C_BINDING TYPE(C_PTR), VALUE :: string ! A C pointer END FUNCTION END INTERFACE CALL C_F_POINTER(FPTR=FPTR, CPTR=CPTR, SHAPE=[strlen(CPTR)]) END FUNCTION END MODULE ISO_C_UTILITIES -- Summary: [ISO C Binding] Internal Error: gfc_basic_typename(): Undefined type Product: gcc Version: 4.3.0 Status: UNCONFIRMED Keywords: ice-on-valid-code Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: burnus at gcc dot gnu dot org OtherBugsDependingO 32630 nThis: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32797
[Bug tree-optimization/32796] [4.3 Regression] internal compiler error: tree check: expected integer_type or enumeral_type or boolean_type or real_type, have pointer_type in int_fits_type_p
--- Comment #2 from belyshev at depni dot sinp dot msu dot ru 2007-07-17
18:29 ---
Confirmed, reduced testcase (compile with -O1):
unsigned long f (void *ptr)
{
return ((unsigned long)(ptr)-1) | 1ULL;
}
--
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
Component|c |tree-optimization
Ever Confirmed|0 |1
GCC build triplet|i686-pc-linux-gnu |
GCC host triplet|i686-pc-linux-gnu |
Last reconfirmed|-00-00 00:00:00 |2007-07-17 18:29:41
date||
Target Milestone|--- |4.3.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32796
[Bug c/32798] New: Multiple definitions of __flockfile when compiling an openMP program
I see the following behavior when compiling an OpenMP program:
$ cat omp.c
extern void omp_set_num_threads (int);
#define NT 4
int main() {
omp_set_num_threads(NT);
return(0);
}
$ gcc --version
gcc (GCC) 4.2.0 20070514 (rpm:4)
Copyright (C) 2007 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
$ gcc -static -fopenmp omp.c -lc
/usr/lib/../lib64/libpthread.a(lockfile.o)(.text+0xb0): In function
`__flockfile':
/usr/src/packages/BUILD/glibc-2.3/linuxthreads/lockfile.c:29: multiple
definition of `_IO_flockfile'
/usr/lib/../lib64/libc.a(flockfile.o)(.text+0x0):../linuxthreads/sysdeps/pthread/flockfile.c:30:
first defined here
/usr/bin/ld: Warning: size of symbol `_IO_flockfile' changed from 24 in
/usr/lib/../lib64/libc.a(flockfile.o) to 12 in
/usr/lib/../lib64/libc.a(flockfile.o)
/usr/lib/../lib64/libpthread.a(lockfile.o)(.text+0xb0): In function
`__flockfile':
/usr/src/packages/BUILD/glibc-2.3/linuxthreads/lockfile.c:29: multiple
definition of `__flockfile'
/usr/lib/../lib64/libc.a(flockfile.o)(.text+0x0):../linuxthreads/sysdeps/pthread/flockfile.c:30:
first defined here
/usr/bin/ld: Warning: size of symbol `__flockfile' changed from 24 in
/usr/lib/../lib64/libc.a(flockfile.o) to 12 in
/usr/lib/../lib64/libc.a(flockfile.o)
/usr/lib/../lib64/libpthread.a(lockfile.o)(.text+0xa0): In function
`__funlockfile':
/usr/src/packages/BUILD/glibc-2.3/linuxthreads/lockfile.c:39: multiple
definition of `_IO_funlockfile'
/usr/lib/../lib64/libc.a(funlockfile.o)(.text+0x0):../linuxthreads/sysdeps/pthread/funlockfile.c:30:
first defined here
/usr/bin/ld: Warning: size of symbol `_IO_funlockfile' changed from 24 in
/usr/lib/../lib64/libc.a(funlockfile.o) to 12 in
/usr/lib/../lib64/libc.a(funlockfile.o)
/usr/lib/../lib64/libpthread.a(lockfile.o)(.text+0xa0): In function
`__funlockfile':
/usr/src/packages/BUILD/glibc-2.3/linuxthreads/lockfile.c:39: multiple
definition of `__funlockfile'
/usr/lib/../lib64/libc.a(funlockfile.o)(.text+0x0):../linuxthreads/sysdeps/pthread/funlockfile.c:30:
first defined here
/usr/bin/ld: Warning: size of symbol `__funlockfile' changed from 24 in
/usr/lib/../lib64/libc.a(funlockfile.o) to 12 in
/usr/lib/../lib64/libc.a(funlockfile.o)collect2: ld returned 1 exit status
$
Problem does NOT occur if I don't include '-lc'. I don't quite understand why
this is a factor, since gcc automatically specifies '-lc' when linking the
program. Please enlighten me as to why adding this to the command line causes
the error.
Here is the version of Linux I am using:
$ uname -a
Linux guppy2 2.6.5-7.286-ss #6 SMP Wed Jul 11 14:28:20 PDT 2007 x86_64 x86_64
x86_64 GNU/Linux
$ cat /etc/SuSE-release
SUSE LINUX Enterprise Server 9 (x86_64)
VERSION = 9
PATCHLEVEL = 2
$
I am building a program for the Cray XT3, so static libraries must be used.
--
Summary: Multiple definitions of __flockfile when compiling an
openMP program
Product: gcc
Version: 4.2.0
Status: UNCONFIRMED
Severity: major
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: geir at cray dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32798
[Bug c/32799] New: Multiple definitions of __flockfile when compiling an openMP program
I see the following behavior when compiling an OpenMP program:
$ cat omp.c
extern void omp_set_num_threads (int);
#define NT 4
int main() {
omp_set_num_threads(NT);
return(0);
}
$ gcc --version
gcc (GCC) 4.2.0 20070514 (rpm:4)
Copyright (C) 2007 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
$ gcc -static -fopenmp omp.c -lc
/usr/lib/../lib64/libpthread.a(lockfile.o)(.text+0xb0): In function
`__flockfile':
/usr/src/packages/BUILD/glibc-2.3/linuxthreads/lockfile.c:29: multiple
definition of `_IO_flockfile'
/usr/lib/../lib64/libc.a(flockfile.o)(.text+0x0):../linuxthreads/sysdeps/pthread/flockfile.c:30:
first defined here
/usr/bin/ld: Warning: size of symbol `_IO_flockfile' changed from 24 in
/usr/lib/../lib64/libc.a(flockfile.o) to 12 in
/usr/lib/../lib64/libc.a(flockfile.o)
/usr/lib/../lib64/libpthread.a(lockfile.o)(.text+0xb0): In function
`__flockfile':
/usr/src/packages/BUILD/glibc-2.3/linuxthreads/lockfile.c:29: multiple
definition of `__flockfile'
/usr/lib/../lib64/libc.a(flockfile.o)(.text+0x0):../linuxthreads/sysdeps/pthread/flockfile.c:30:
first defined here
/usr/bin/ld: Warning: size of symbol `__flockfile' changed from 24 in
/usr/lib/../lib64/libc.a(flockfile.o) to 12 in
/usr/lib/../lib64/libc.a(flockfile.o)
/usr/lib/../lib64/libpthread.a(lockfile.o)(.text+0xa0): In function
`__funlockfile':
/usr/src/packages/BUILD/glibc-2.3/linuxthreads/lockfile.c:39: multiple
definition of `_IO_funlockfile'
/usr/lib/../lib64/libc.a(funlockfile.o)(.text+0x0):../linuxthreads/sysdeps/pthread/funlockfile.c:30:
first defined here
/usr/bin/ld: Warning: size of symbol `_IO_funlockfile' changed from 24 in
/usr/lib/../lib64/libc.a(funlockfile.o) to 12 in
/usr/lib/../lib64/libc.a(funlockfile.o)
/usr/lib/../lib64/libpthread.a(lockfile.o)(.text+0xa0): In function
`__funlockfile':
/usr/src/packages/BUILD/glibc-2.3/linuxthreads/lockfile.c:39: multiple
definition of `__funlockfile'
/usr/lib/../lib64/libc.a(funlockfile.o)(.text+0x0):../linuxthreads/sysdeps/pthread/funlockfile.c:30:
first defined here
/usr/bin/ld: Warning: size of symbol `__funlockfile' changed from 24 in
/usr/lib/../lib64/libc.a(funlockfile.o) to 12 in
/usr/lib/../lib64/libc.a(funlockfile.o)collect2: ld returned 1 exit status
$
Problem does NOT occur if I don't include '-lc'. I don't quite understand why
this is a factor, since gcc automatically specifies '-lc' when linking the
program. Please enlighten me as to why adding this to the command line causes
the error.
Here is the version of Linux I am using:
$ uname -a
Linux guppy2 2.6.5-7.286-ss #6 SMP Wed Jul 11 14:28:20 PDT 2007 x86_64 x86_64
x86_64 GNU/Linux
$ cat /etc/SuSE-release
SUSE LINUX Enterprise Server 9 (x86_64)
VERSION = 9
PATCHLEVEL = 2
$
I am building a program for the Cray XT3, so static libraries must be used.
--
Summary: Multiple definitions of __flockfile when compiling an
openMP program
Product: gcc
Version: 4.2.0
Status: UNCONFIRMED
Severity: major
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: geir at cray dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32799
[Bug c/32798] Multiple definitions of __flockfile when compiling an openMP program
--- Comment #1 from geir at cray dot com 2007-07-17 19:21 --- *** Bug 32799 has been marked as a duplicate of this bug. *** -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32798
[Bug c/32799] Multiple definitions of __flockfile when compiling an openMP program
--- Comment #1 from geir at cray dot com 2007-07-17 19:21 --- *** This bug has been marked as a duplicate of 32798 *** -- geir at cray dot com changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32799
[Bug c/32799] Multiple definitions of __flockfile when compiling an openMP program
--- Comment #2 from geir at cray dot com 2007-07-17 19:22 --- Pressing refresh on my browser mistakenly opened up a new bug for the problem described in bug 32798 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32799
[Bug fortran/32800] New: ISO Bind C: C_F_Pointer argument bogus checking
The following fails if the FPTR argument is not the second argument. The argument checking should be based on the ordered argument list not on the position of the call (FPTR= is not always at the second position). (Related to PR32797) CALL C_F_POINTER(FPTR=FPTR, CPTR=CPTR,SHAPE=[strlen(cptr)]) 1 Error: Argument 'cptr' to 'c_f_pointer' at (1) must have the POINTER attribute FUNCTION C_F_STRING(CPTR) RESULT(FPTR) USE ISO_C_BINDING implicit none TYPE(C_PTR), INTENT(IN) :: CPTR ! The C address CHARACTER(KIND=C_CHAR), DIMENSION(:), POINTER :: FPTR INTERFACE FUNCTION strlen(string) RESULT(len) BIND(C,NAME=strlen) import TYPE(C_PTR), VALUE :: string ! A C pointer integer(c_int) :: len END FUNCTION END INTERFACE CALL C_F_POINTER(FPTR=FPTR, CPTR=CPTR,SHAPE=[strlen(cptr)]) END FUNCTION -- Summary: ISO Bind C: C_F_Pointer argument bogus checking Product: gcc Version: 4.3.0 Status: UNCONFIRMED Keywords: rejects-valid Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: burnus at gcc dot gnu dot org OtherBugsDependingO 32630 nThis: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32800
[Bug tree-optimization/32796] [4.3 Regression] internal compiler error: tree check: expected integer_type or enumeral_type or boolean_type or real_type, have pointer_type in int_fits_type_p
--- Comment #3 from belyshev at depni dot sinp dot msu dot ru 2007-07-17 20:34 --- Fails since pointer-plus merge: r125755 | pinskia | 2007-06-16 09:42:36 +0400 (Sat, 16 Jun 2007) | 386 lines -- belyshev at depni dot sinp dot msu dot ru changed: What|Removed |Added CC||pinskia at gcc dot gnu dot ||org Keywords||ice-checking, ice-on-valid- ||code http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32796
[Bug libgomp/32798] Multiple definitions of __flockfile when compiling an openMP program
--- Comment #2 from pinskia at gcc dot gnu dot org 2007-07-17 21:02 --- One should note that static linking glibc is not really supported anyways. Also this is not a GCC bug but rather a glibc one: /usr/lib/../lib64/libpthread.a(lockfile.o)(.text+0xb0): In function `__flockfile': /usr/src/packages/BUILD/glibc-2.3/linuxthreads/lockfile.c:29: multiple definition of `_IO_flockfile' /usr/lib/../lib64/libc.a(flockfile.o)(.text+0x0):../linuxthreads/sysdeps/pthread/flockfile.c:30: first defined here -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Severity|major |normal Status|UNCONFIRMED |RESOLVED Component|c |libgomp Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32798
[Bug c/32796] [4.3 Regression] internal compiler error: tree check: expected integer_type or enumeral_type or boolean_type or real_type, have pointer_type in int_fits_type_p
--- Comment #4 from pinskia at gcc dot gnu dot org 2007-07-17 21:05 --- Actually this is a front-end issue: #2 0x0034dce8 in int_fits_type_p (c=0x436812d0, type=0x4361f460) at ../../gcc/tree.c:6198 #3 0x0007a950 in build_binary_op (code=BIT_IOR_EXPR, orig_op0=0x436c5000, orig_op1=0x436812d0, convert_p=1) at ../../gcc/c-typeck.c:8245 -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Component|tree-optimization |c http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32796
[Bug bootstrap/32794] GCC (SVN) naive build fails due to use of '%I64d'
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-07-17 21:13 --- This is why you should not confirm your own bugs, because most likely there is already a bug about this issue. Anyways the work around is to configure with --disable-werror . *** This bug has been marked as a duplicate of 25502 *** -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32794
[Bug bootstrap/25502] Werror problem in build
--- Comment #9 from pinskia at gcc dot gnu dot org 2007-07-17 21:13 --- *** Bug 32794 has been marked as a duplicate of this bug. *** -- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||gdr at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25502
[Bug fortran/32535] namelist with private items contained in sub-sub-procedure of a module rejected
--- Comment #2 from burnus at gcc dot gnu dot org 2007-07-17 21:33 --- Subject: Bug 32535 Author: burnus Date: Tue Jul 17 21:33:34 2007 New Revision: 126706 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=126706 Log: 2007-07-17 Janus Weil [EMAIL PROTECTED] PR fortran/32535 * resolve.c (resolve_fl_namelist): Check for namelist private components in contained subprograms. 2007-07-17 Janus Weil [EMAIL PROTECTED] PR fortran/32535 * gfortran.dg/pr32535.f90: New test. Added: trunk/gcc/testsuite/gfortran.dg/pr32535.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/resolve.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32535
[Bug fortran/32535] namelist with private items contained in sub-sub-procedure of a module rejected
--- Comment #3 from burnus at gcc dot gnu dot org 2007-07-17 21:34 --- FIXED in the trunk; no regression = no backporting. -- burnus at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32535
[Bug fortran/32795] Leaking memory (generated prog) with type constructor allocatable components
--- Comment #1 from dfranke at gcc dot gnu dot org 2007-07-17 21:42 --- After update to r126703, updated example from pr31320, comment #4: type :: a integer, allocatable :: i(:) end type a type(a) :: x, y x = a ((/ 1,2,3 /)) ! y = a (x%i(1:3)) ! ok ! y = a (x%i(1:))! ok ! y = a (x%i(:3))! ok ! y = a (x%i(:)) ! memory leak ! y = a (x%i)! memory leak ! y = x ! ok end ==21521== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 7 from 1) ==21521== malloc/free: in use at exit: 12 bytes in 1 blocks. ==21521== malloc/free: 12 allocs, 11 frees, 25,539 bytes allocated. ==21521== For counts of detected errors, rerun with: -v ==21521== searching for pointers to 1 not-freed blocks. ==21521== checked 66,236 bytes. ==21521== ==21521== 12 bytes in 1 blocks are definitely lost in loss record 1 of 1 ==21521==at 0x40215CD: malloc (vg_replace_malloc.c:149) ==21521==by 0x80486CC: MAIN__ (in /home/daniel/pr/a.out) ==21521==by 0x8048958: main (fmain.c:22) -- dfranke at gcc dot gnu dot org changed: What|Removed |Added CC||dfranke at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32795
[Bug tree-optimization/32635] [4.3 Regression] gfortran - internal compiler error: verify_ssa failed
--- Comment #2 from tkoenig at gcc dot gnu dot org 2007-07-17 21:58 --- Works for me with gcc version 4.3.0 20070715 on i686-pc-linux-gnu. Could this be target specific? -- tkoenig at gcc dot gnu dot org changed: What|Removed |Added CC||tkoenig at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32635
[Bug fortran/32801] New: USE of ISO_C_BINDING, ONLY: C_LOC causes compiler seg fault
The following program causes a fault in the compiler: c_loc_prob.f:0: internal compiler error: Segmentation fault: 11 This is the reduced program: PROGRAM c_loc_prob USE, INTRINSIC :: ISO_C_BINDING, ONLY: C_LOC ! USE, INTRINSIC :: ISO_C_BINDING, ONLY: C_PTR, C_LOC END PROGRAM c_loc_prob Additional information: - Options for optimization and warnings seem to not affect the errot. - If C_PTR is declared prior to C_LOC (as in the comment), the compiler doesn't fault. - In the original programs (from which this example is extracted, the declaration of C_PTR prior to C_LOC causes the compiler to erroneously diagnose various other constructs Workarounds: At least two workaounds for this problem work in the other (much larger) programs: - Avoid use of ONLY: qualifier to ISO_C_BINDING, e.g., USE, INTRINSIC :: ISO_C_BINDING - Replace C_LOC with LOC at the invocation and C_PTR with C_LONG at the INTERFACE declaration. -- Summary: USE of ISO_C_BINDING, ONLY: C_LOC causes compiler seg fault Product: gcc Version: 4.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: sysmaint at contek dot com GCC build triplet: same GCC host triplet: gfortran - 386-portbld-freebsd6.2 - 4.3.0 20070713 (experimental GCC target triplet: same http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32801
[Bug bootstrap/32785] (hpux11.11)link test not allowed GCC_NO_EXECUTABLES.
--- Comment #17 from cnstar9988 at gmail dot com 2007-07-18 02:26 --- LDFLAGS. http://gcc.gnu.org/ml/gcc-patches/2004-04/msg00953.html We sometimes get configure errors claiming that LDFLAGS value has changed since the last configure. This patch fixes that problem, thanks to a hint from Andreas Schwab. This adds LDFLAGS to the set of variables set and exported by the configure rules in the toplevel Makefile, so that the environment for subconfigures matches the environment for submakes. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32785
[Bug libfortran/32784] [win32] Using 'con' as assigned file generates Fortran runtime error: File 'con' does not exist
--- Comment #8 from jvdelisle at gcc dot gnu dot org 2007-07-18 02:54 --- I can't get anything to work, but I have some ideas. -- jvdelisle at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |jvdelisle at gcc dot gnu dot |dot org |org Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2007-07-18 02:54:22 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32784
[Bug ada/32802] New: Assert_Failure sinfo.adb:1730
-- bug.adb with Text_IO; use Text_IO; procedure Bug is typeS is range 0 .. 1000; begin Put_Line (S'Image (S'Integer_Value (12.8))); end Bug; ** gnat make -gnatf -gnato -gnatv -gnatVa -gnatwa -gnaty bug.adb gcc-4.1 -c -gnatf -gnato -gnatv -gnatVa -gnatwa -gnaty bug.adb GNAT 4.1.2 20061115 (prerelease) (Debian 4.1.1-22) Copyright 1992-2005 Free Software Foundation, Inc. Compiling: bug.adb (source file time stamp: 2007-07-17 11:05:32) +===GNAT BUG DETECTED==+ | 4.1.2 20061115 (prerelease) (Debian 4.1.1-22) (i486-pc-linux-gnu)| | Assert_Failure sinfo.adb:1730| | Error detected at bug.adb:7:24 | ... bug.adb 8 lines: No errors compilation abandoned gnatmake: bug.adb compilation error make: *** [bug] Fehler 4 -- Summary: Assert_Failure sinfo.adb:1730 Product: gcc Version: 4.1.2 Status: UNCONFIRMED Severity: trivial Priority: P3 Component: ada AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: bug63 at freakmail dot de http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32802
[Bug ada/32802] Assert_Failure sinfo.adb:1730
--- Comment #1 from bug63 at freakmail dot de 2007-07-18 05:15 --- *** This bug has been marked as a duplicate of 32792 *** -- bug63 at freakmail dot de changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32802
[Bug ada/32792] Assert_Failure sinfo.adb:1730
--- Comment #1 from bug63 at freakmail dot de 2007-07-18 05:15 --- *** Bug 32802 has been marked as a duplicate of this bug. *** -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32792
[Bug fortran/32801] USE of ISO_C_BINDING, ONLY: C_LOC causes compiler seg fault
-- burnus at gcc dot gnu dot org changed: What|Removed |Added OtherBugsDependingO||32630 nThis|| Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 GCC build triplet|same| GCC host triplet|gfortran - 386-portbld- | |freebsd6.2 - 4.3.0 20070713 | |(experimental | GCC target triplet|same| Keywords||ice-on-valid-code Last reconfirmed|-00-00 00:00:00 |2007-07-18 05:44:38 date|| Target Milestone|--- |4.3.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32801
