[Bug target/29943] [4.2/4.3 Regression] gcc generate incorrect alias symbols for PPC
--- Comment #7 from amodra at bigpond dot net dot au 2006-11-23 08:01 --- This is the simple patch I've bootstrapped and am currently regression testing. Index: varasm.c === --- varasm.c(revision 119100) +++ varasm.c(working copy) @@ -981,6 +981,10 @@ use_blocks_for_decl_p (tree decl) if (DECL_INITIAL (decl) == decl) return false; + /* If this decl is an alias, then we don't want to emit a definition. */ + if (lookup_attribute (alias, DECL_ATTRIBUTES (decl))) +return false; + return true; } Another possibility is to check for named sections in handle_alias_attribute (and alias attributes in handle_section_attribute), possibly giving a diagnostic. It's clear that code like extern int a __attribute__ ((section (.sec1))); extern int b __attribute__ ((section (.sec2))) __attribute__ ((alias (a))); is invalid; b can't alias a and be in a different section. However, from the previous discussion over 28598 I gather we don't want to go down the path of checking section attributes. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29943
[Bug bootstrap/29937] bootstrap failure on Linux AMD64
--- Comment #12 from dkouroun at cc dot uoi dot gr 2006-11-23 08:34 --- Subject: Re: bootstrap failure on Linux AMD64 I submitted a bug report in the Gentoo Bugzilla. I hope they will fix it. I still believe that the best way through would be to add an option to the configure script of the GCC. I tried to compile with --disable-multilib. GCC-4.2 had no problem without the -j5. With -j5 it stops where it stopped before. On the other hand gcc-4.3 breaks both with or without -j5 at libgfortran spitting a lot of messages like: .libs/in_unpack_generic.o: In function `__strsep_1c': in_unpack_generic.c:(.text+0x5da): multiple definition of `__strsep_1c' .libs/environ.o:environ.c:(.text+0x1057): first defined here .libs/in_unpack_generic.o: In function `strtoull': in_unpack_generic.c:(.text+0x625): multiple definition of `strtoull' .libs/environ.o:environ.c:(.text+0xf8f): first defined here .libs/in_unpack_generic.o: In function `strtouq': in_unpack_generic.c:(.text+0x638): multiple definition of `strtouq' .libs/environ.o:environ.c:(.text+0xfa2): first defined here .libs/in_unpack_generic.o: In function `strtoll': in_unpack_generic.c:(.text+0x64b): multiple definition of `strtoll' .libs/environ.o:environ.c:(.text+0xfb5): first defined here .libs/in_unpack_generic.o: In function `strtoq': in_unpack_generic.c:(.text+0x65e): multiple definition of `strtoq' .libs/environ.o:environ.c:(.text+0xfc8): first defined here .libs/in_unpack_generic.o: In function `strtold': in_unpack_generic.c:(.text+0x671): multiple definition of `strtold' .libs/environ.o:environ.c:(.text+0xfdb): first defined here .libs/in_unpack_generic.o: In function `strtof': in_unpack_generic.c:(.text+0x684): multiple definition of `strtof' .libs/environ.o:environ.c:(.text+0xfee): first defined here .libs/in_unpack_generic.o: In function `strtoul': in_unpack_generic.c:(.text+0x697): multiple definition of `strtoul' .libs/environ.o:environ.c:(.text+0x1001): first defined here .libs/in_unpack_generic.o: In function `strtol': in_unpack_generic.c:(.text+0x6aa): multiple definition of `strtol' .libs/environ.o:environ.c:(.text+0x1031): first defined here .libs/in_unpack_generic.o: In function `strtod': in_unpack_generic.c:(.text+0x6bd): multiple definition of `strtod' .libs/environ.o:environ.c:(.text+0x1044): first defined here .libs/in_unpack_generic.o: In function `atoi': in_unpack_generic.c:(.text+0x6d0): multiple definition of `atoi' .libs/environ.o:environ.c:(.text+0x1014): first defined here .libs/in_unpack_generic.o: In function `atol': in_unpack_generic.c:(.text+0x6ed): multiple definition of `atol' .libs/environ.o:environ.c:(.text+0x1227): first defined here .libs/in_unpack_generic.o: In function `atoll': in_unpack_generic.c:(.text+0x70a): multiple definition of `atoll' .libs/environ.o:environ.c:(.text+0x120a): first defined here .libs/in_unpack_generic.o: In function `atof': in_unpack_generic.c:(.text+0x727): multiple definition of `atof' .libs/environ.o:environ.c:(.text+0x1244): first defined here collect2: ld returned 1 exit status make[3]: *** [libgfortran.la] Error 1 make[3]: Leaving directory `/common/compilers/linux/gcc-4.3/x86_64-unknown-linux-gnu/libgfortran' make[2]: *** [all] Error 2 make[2]: Leaving directory `/common/compilers/linux/gcc-4.3/x86_64-unknown-linux-gnu/libgfortran' make[1]: *** [all-target-libgfortran] Error 2 make[1]: Leaving directory `/common/compilers/linux/gcc-4.3' make: *** [bootstrap-lean] Error 2 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29937
[Bug libgomp/26165] Cannot find libgomp.spec after 'make install' on x86_64 and ppc64
--- Comment #10 from martin at mpa-garching dot mpg dot de 2006-11-23 09:22 --- I can still reproduce the compilation problem with today's mainline. I'll try with the 4.2 branch as soon as possible. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26165
[Bug fortran/29951] New: incorrect conversion from string to integer by convert()
Dear people, The sample code below converts 4 characters to an integer using the transfer function. If the characters are stored in an array of characters this works fine. If the characters are stored in a string the transfer fails. The following commands were used to compile with both gfortran and pgf90 (also ifort and g95 give the same output as pgf90): gfortran -o test_convert test_convert.F90 pgf90 -o test_convert test_convert.F90 When executed the program produces the following output: pgf90 result: byte_string = 157 127 1000 byte_array = 157 127 1000 byte_string: value = 6586269 byte_array: value = 6586269 byte_string holds 4 bytes byte_array holds 4 bytes gfortran result: byte_string = 157 127 100 0 byte_array = 157 127 100 0 byte_string: value = 157 byte_array: value = 6586269 byte_string holds4 bytes byte_array holds4 bytes sample code: program test_convert implicit none character(len=4) :: byte_string character(len=1),dimension(4) :: byte_array integer*4 :: value,n,i byte_string(1:1) = char(157) byte_string(2:2) = char(127) byte_string(3:3) = char(100) byte_string(4:4) = char(0) byte_array(1:4) = (/char(157),char(127),char(100),char(0)/) print *,byte_string = ,(ichar(byte_string(i:i)),i=1,4) print *,byte_array = ,(ichar(byte_array( i:i)),i=1,4) value = transfer(byte_string(1:4),value) print *,byte_string: value = ,value value = transfer(byte_array(1:4),value) print *,byte_array: value = ,value inquire(iolength=n) byte_string print *,byte_string holds ,n, bytes inquire(iolength=n) byte_array print *,byte_array holds ,n, bytes end program test_convert If I understand correctly transfer() should only look at the second parameter (and the optional size parameter) to decide whether the result should be a scalar or an array. At least this is what Metcalf and Reid say in their book fortran90/95 explained. However, gfortran seems to look at the rank of the first parameter as well. best regards, Jos de Kloe -- Summary: incorrect conversion from string to integer by convert() Product: gcc Version: 4.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: kloedej at knmi dot nl http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29951
[Bug fortran/29951] incorrect conversion from string to integer by convert()
--- Comment #1 from kloedej at knmi dot nl 2006-11-23 09:27 --- Hi, a little correction on the just submitted report. I seem to have mixed up the two cases. The string case fails so it clearly has nothing to do with the rank of the first parameter to transfer(). Jos de Kloe -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29951
[Bug fortran/29952] New: Flag to give runtime information array temporary was created for argument
Intel has a nice feature to find bad array definitions. Somehow thinking of C I wrote: real :: coord(N,3) rather than coord(3,N). Using ifort -check arg_temp_created this gave then such information at run time (in my example below 20 times): forrtl: warning (402): fort: (1): In call to DISTANCE, an array temporary was created for argument #1 While one can sometimes not prevent the need for a array temporary, one often can and should do so to speed up the program. Example program: - program tmp implicit none integer, parameter :: N = 20 real :: coord(N,3) ! better: (3,N) integer:: i real :: d coord = 0.0 do i=1,N d = distance(coord(i,:)) end do contains function distance(a) real :: a(3) real :: distance distance = sqrt(a(1)**2 + a(2)**2 + a(3)**2) end function distance end program tmp -- Summary: Flag to give runtime information array temporary was created for argument 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 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29952
[Bug target/29953] New: [SH-4] Perfomance regression in loops. cmp/eq used instead of dt
GCC 4.1.1 (probably all 4.* versions, tested 4.3.0-svn also), uses cmp/eq instead of dt in loops. This leads to ~20% perfomance decrease. Technically, loop processing algorithm is completely different between versions. Example (sources in attach): CFLAGS=-m4 -O3 -fomit-frame-pointer gcc 3.4.4: .LFB2: mov.l .L11,r3 mov #0,r0 mov.l .L12,r2 .L5: mov.l @r3+,r1 ! !!! dt r2 ! !!! bf/s.L5 add r1,r0 rts nop .L13: .align 2 .L11: .long -1946157056 .L12: .long 100 - gcc 4.1.1: - .LFB2: mov.l .L8,r2 mov #0,r0 mov.l .L9,r3 .L2: mov.l @r2+,r1 ! !!! cmp/eq r3,r2 ! !!! bf/s.L2 add r1,r0 rts nop .L10: .align 2 .L8: .long -1946157056 .L9: .long -1942157056 - P.S. We are porting application from gcc3.4 to gcc4.1 and have about 60% perfomance decrease. So this is probably just first report. :( -- Summary: [SH-4] Perfomance regression in loops. cmp/eq used instead of dt Product: gcc Version: 4.1.1 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: i686-pc-linux-gnu GCC host triplet: i686-pc-linux-gnu GCC target triplet: sh-rtemself http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29953
[Bug target/29953] [SH-4] Perfomance regression in loops. cmp/eq used instead of dt
--- Comment #1 from nbkolchin at gmail dot com 2006-11-23 10:15 --- Created an attachment (id=12671) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12671action=view) test.cpp Testcase -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29953
[Bug c++/29954] New: Not able to Compile for SUN Solaris 10.0
Hi I am compiling gcc for SUN solaris10.0 with the following parameters: --enable-languages=c,c++ --enable-shared here is the following errors I found: ld: fatal: relocation error: R_SPARC_DISP32: file .libs/libstdc++.lax/libsupc++convenience.a/new_op.o: symbol unknown: offset 0xfccd14b5 is non-aligned ld: fatal: relocation error: R_SPARC_DISP32: file .libs/libstdc++.lax/libsupc++convenience.a/new_opnt.o: symbol unknown: offset 0xfccd14f1 is non-aligned ld: fatal: relocation error: R_SPARC_DISP32: file .libs/libstdc++.lax/libsupc++convenience.a/new_opv.o: symbol unknown: offset 0xfccd152d is non-aligned ld: fatal: relocation error: R_SPARC_DISP32: file .libs/libstdc++.lax/libsupc++convenience.a/vec.o: symbol unknown: offset 0xfccd1809 is non-aligned ld: fatal: relocation error: R_SPARC_DISP32: file .libs/libstdc++.lax/libsupc++convenience.a/vec.o: symbol unknown: offset 0xfccd1829 is non-aligned ld: fatal: relocation error: R_SPARC_DISP32: file .libs/libstdc++.lax/libsupc++convenience.a/vec.o: symbol unknown: offset 0xfccd1849 is non-aligned ld: fatal: relocation error: R_SPARC_DISP32: file .libs/libstdc++.lax/libsupc++convenience.a/vec.o: symbol unknown: offset 0xfccd1869 is non-aligned ld: fatal: relocation error: R_SPARC_DISP32: file .libs/libstdc++.lax/libsupc++convenience.a/vec.o: symbol unknown: offset 0xfccd18a9 is non-aligned ld: fatal: relocation error: R_SPARC_DISP32: file .libs/libstdc++.lax/libsupc++convenience.a/vec.o: symbol unknown: offset 0xfccd18c9 is non-aligned ld: fatal: relocation error: R_SPARC_DISP32: file .libs/libstdc++.lax/libsupc++convenience.a/vec.o: symbol unknown: offset 0xfccd18e9 is non-aligned ld: fatal: relocation error: R_SPARC_DISP32: file .libs/libstdc++.lax/libsupc++convenience.a/vec.o: symbol unknown: offset 0xfccd1909 is non-aligned ld: fatal: relocation error: R_SPARC_DISP32: file .libs/libstdc++.lax/libsupc++convenience.a/vterminate.o: symbol unknown: offset 0xfccd1945 is non-aligned collect2: ld returned 1 exit status make[3]: *** [libstdc++.la] Error 1 Waiting for your valuable suggestion. Please feel free to mail me for any systems related information. Regards, Indranil -- Summary: Not able to Compile for SUN Solaris 10.0 Product: gcc Version: 4.0.2 Status: UNCONFIRMED Severity: critical Priority: P3 Component: c++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: sos at cal dot interrasystems dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29954
[Bug c/29955] New: ICE with -fopenmp -fexceptions
extern void bar (int);
void
foo (int n)
{
int i;
#pragma omp parallel for schedule(dynamic)
for (i = 0; i n; i++)
bar (0);
}
ICEs on ia64-linux with -xc -O2 -fopenmp -fexceptions, as
eh_personality_libfunc
isn't set, yet foo.omp_fn.0 has cfun-uses_eh_lsda.
--
Summary: ICE with -fopenmp -fexceptions
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: jakub at gcc dot gnu dot org
GCC target triplet: ia64-*-linux
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29955
[Bug c/29955] ICE with -fopenmp -fexceptions
-- jakub at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |jakub at gcc dot gnu dot org |dot org | Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Keywords||openmp Known to fail||4.2.0 4.3.0 Last reconfirmed|-00-00 00:00:00 |2006-11-23 10:41:55 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29955
[Bug fortran/29951] incorrect conversion from string to integer by TRANSFER()
--- Comment #2 from burnus at gcc dot gnu dot org 2006-11-23 11:17 ---
Confirmed.
For transfer(string, integer), gfortran's transfer only uses the first
character (byte).
It should use all characters.
-fdump-tree-original:
value = VIEW_CONVERT_EXPRint4(byte_string[1]{lb: 1 sz: 1});
In iresolve.c gfortran only checks whether the source is scalar or an array,
the transfer is then done in gfc_conv_intrinsic_transfer (scalar) or
gfc_conv_intrinsic_array_transfer in trans-intrinsic.c.
--
burnus at gcc dot gnu dot org changed:
What|Removed |Added
CC||burnus at gcc dot gnu dot
||org
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Keywords||wrong-code
Last reconfirmed|-00-00 00:00:00 |2006-11-23 11:17:09
date||
Summary|incorrect conversion from |incorrect conversion from
|string to integer by|string to integer by
|convert() |TRANSFER()
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29951
[Bug c++/29954] Not able to compile for SPARC/Solaris 10
--- Comment #1 from ebotcazou at gcc dot gnu dot org 2006-11-23 11:18 --- Please specify the exact configure line and build command. Also make sure to read the documentation: http://gcc.gnu.org/install -- ebotcazou at gcc dot gnu dot org changed: What|Removed |Added CC||ebotcazou at gcc dot gnu dot ||org Severity|critical|minor Status|UNCONFIRMED |WAITING Summary|Not able to Compile for SUN |Not able to compile for |Solaris 10.0|SPARC/Solaris 10 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29954
[Bug fortran/29951] incorrect conversion from string to integer by TRANSFER()
--- Comment #3 from burnus at gcc dot gnu dot org 2006-11-23 11:39 --- In iresolve.c gfortran only checks whether the source is scalar or an array, This is none sense it actually checks the mold-rank. The function to modify is gfc_conv_intrinsic_transfer (trans-intrinsic.c); we somewhere need to obtain for character strings their byte size. gfc_conv_intrinsic_array_transfer seems to do the right thing. For character(len=2) :: byte_array(2) it works, for character(len=4) :: byte_array(1) it does not. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29951
[Bug c++/29954] Not able to Compile for SUN Solaris 10.0
-- sos at cal dot interrasystems dot com changed: What|Removed |Added CC||sos at cal dot ||interrasystems dot com Severity|minor |critical Summary|Not able to compile for |Not able to Compile for SUN |SPARC/Solaris 10|Solaris 10.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29954
[Bug c++/29954] Not able to Compile for SUN Solaris 10.0
--- Comment #2 from sos at cal dot interrasystems dot com 2006-11-23 12:29 --- Hi Ebotcazou, Thanks for your reply. Here is the command, that I am using: I am at gcc-4.0.2_obj directory. ../gcc-4.0.2_src/configure --prefix=/software/gcc/v4.0.2/sparc-sun-solaris2.10 --enable-languages=c,c++ --enable-shared I had compilled many gcc source for veriuos O/S (SUN Solaris 5.6/7/8) with this command. But never use for Solaris 5.10. Can you please help me in this issue and give the comman for build gcc4.x on Solaris 10. Regards, indranil -- sos at cal dot interrasystems dot com changed: What|Removed |Added Status|WAITING |UNCONFIRMED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29954
[Bug target/29943] [4.2/4.3 Regression] gcc generate incorrect alias symbols for PPC
--- Comment #8 from patchapp at dberlin dot org 2006-11-23 12:45 --- Subject: Bug number PR29943 A patch for this bug has been added to the patch tracker. The mailing list url for the patch is http://gcc.gnu.org/ml/gcc-patches/2006-11/msg01613.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29943
[Bug c++/29956] New: Violation of ISO C++ 4.4 Qualification conversions
g++ -v: Reading specs from /usr/local/lib/gcc/sparc-sun-solaris2.9/3.4.2/specs Configured with: ../configure --with-as=/usr/ccs/bin/as --with-ld=/usr/ccs/bin/ld --disable-nls--disable-libgcj --enable-languages=c,c+ : (reconfigured) ../configure --with-as=/usr/ccs/bin/as --with-ld=/usr/ccs/bin/ld --disable-nls --disable-libgcj --enable-languages=c,c++ Thread model: posix gcc version 3.4.2 g++ 1.cpp -o 1: 1.cpp: In function `int main()': 1.cpp:6: error: invalid operands of types `const int* const* const' and `int* const* const' to binary `operator-' Expected behaviour: errorless compilation, since the programm follows ISO C++ 4.4 Qualification conversions. -- Summary: Violation of ISO C++ 4.4 Qualification conversions Product: gcc Version: 3.4.2 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: sgaltsev at cbossgroup dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29956
[Bug c++/29956] Violation of ISO C++ 4.4 Qualification conversions
--- Comment #1 from sgaltsev at cbossgroup dot com 2006-11-23 14:09 --- Created an attachment (id=12672) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12672action=view) 1.ii -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29956
[Bug c++/29956] Violation of ISO C++ 4.4 Qualification conversions
--- Comment #2 from rguenth at gcc dot gnu dot org 2006-11-23 14:13 --- No, subtraction of pointer types const int *const * and int *const * is nonstandard. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29956
[Bug c++/29954] Not able to compile for SPARC/Solaris 10.0
--- Comment #3 from ebotcazou at gcc dot gnu dot org 2006-11-23 14:20 --- Thanks for your reply. You're welcome, but please do not undo the changes to the fields. Can you please help me in this issue and give the comman for build gcc4.x on Solaris 10. You didn't post the build command. What compiler do you use? -- ebotcazou at gcc dot gnu dot org changed: What|Removed |Added Severity|critical|minor Status|UNCONFIRMED |WAITING Summary|Not able to Compile for SUN |Not able to compile for |Solaris 10.0|SPARC/Solaris 10.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29954
[Bug c++/29927] template instantiation with function type
--- Comment #5 from s__nakayama at infoseek dot jp 2006-11-23 14:34 --- (In reply to comment #4) In any case, can you clarify why exactly you think the code should be rejected? ISO 14882:2003 14.3.1 p3 If a declaration acquires a function type through a type dependent on a template-parameter and this causes a declaration that does not use the syntactic form of a function declarator to have function type, the program is ill-formed. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29927
[Bug bootstrap/29937] bootstrap failure on Linux AMD64
--- Comment #13 from pinskia at gcc dot gnu dot org 2006-11-23 17:45 --- (In reply to comment #12) On the other hand gcc-4.3 breaks both with or without -j5 at libgfortran spitting a lot of messages like: That is an issue with the glibc headers not being C99 complaint. Anyways there is already a bug about that. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29937
[Bug fortran/29941] gfortran reports error with len of assumed size character array
--- Comment #2 from pault at gcc dot gnu dot org 2006-11-23 17:55 ---
Tobias,
This one liner does the right thing but I have no time right now to do anything
with it:
Index: gcc/fortran/resolve.c
===
*** gcc/fortran/resolve.c (revision 119077)
--- gcc/fortran/resolve.c (working copy)
*** resolve_function (gfc_expr * expr)
*** 1523,1528
--- 1523,1529
else if (expr-value.function.actual != NULL
expr-value.function.isym != NULL
expr-value.function.isym-generic_id != GFC_ISYM_LBOUND
+ expr-value.function.isym-generic_id != GFC_ISYM_LEN
expr-value.function.isym-generic_id != GFC_ISYM_LOC
expr-value.function.isym-generic_id != GFC_ISYM_PRESENT)
{
If you want to regtest it, I would be OK with it being applied as obvious to
trunk, 4.2 and 4.1.
Paul
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29941
[Bug fortran/29952] Flag to give runtime information array temporary was created for argument
--- Comment #1 from pault at gcc dot gnu dot org 2006-11-23 18:31 ---
Confirmed sort of.
While one can sometimes not prevent the need for a array temporary, one often
can and should do so to speed up the program.
{
void * D.1019;
struct array1_real4 parm.2;
int4 D.1008;
D.1008 = i;
parm.2.dtype = 281;
parm.2.dim[0].lbound = 1;
parm.2.dim[0].ubound = 3;
parm.2.dim[0].stride = 20;
parm.2.data = (void *) coord[D.1008 + -1];
parm.2.offset = 0;
D.1019 = _gfortran_internal_pack (parm.2);
d = distance (D.1019);
if (D.1019 != (real4[0:] *) parm.2.data)
{
_gfortran_internal_unpack (parm.2, D.1019);
_gfortran_internal_free (D.1019);
}
else
{
(void) 0;
}
}
It is the parm.2.dim[0].stride = 20; that determines the need for a temporary.
If it has a value of 1, internal pack returns a pointer to the source array.
Thus, such an option would work for constant strides of other than one but
would have to report in real-time for variable strides.
Paul
--
pault at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Last reconfirmed|-00-00 00:00:00 |2006-11-23 18:31:25
date||
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29952
[Bug c/9072] -Wconversion should be split into two distinct flags
--- Comment #17 from manu at gcc dot gnu dot org 2006-11-23 18:39 --- Subject: Bug 9072 Author: manu Date: Thu Nov 23 18:39:32 2006 New Revision: 119129 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=119129 Log: 2006-11-23 Manuel Lopez-Ibanez [EMAIL PROTECTED] PR c/9072 * c.opt (Wtraditional-conversion): New. (Wconversion): Update description. * c-typeck.c (convert_arguments): Warnings for prototypes causing type conversions different from what would happen in the absence of prototype are now handled by Wtraditional-conversion. * doc/invoke.texi (Wtraditional-conversion): New. (Wconversion): Update description. * doc/trouble.texi (Wconversion): Replace Wconversion by Wtraditional-conversion. testsuite/ PR c/9072 * gcc.dg/builtin-protos-1.c: Replace Wconversion by Wtraditional-conversion. * gcc.dg/overflow-warn-2.c: Likewise. * gcc.dg/Wconversion.c: Likewise. Renamed as Wtraditional-conversion.c . * gcc.dg/Wconversion-2.c: Likewise. Renamed as Wtraditional-conversion-2.c . * gcc.dg/dfp/Wconversion-2.c: Likewise. Renamed as Wtraditional-conversion-2.c * gcc.dg/Wconversion-negative-constants.c: New. Added: trunk/gcc/testsuite/gcc.dg/Wconversion-negative-constants.c trunk/gcc/testsuite/gcc.dg/Wtraditional-conversion-2.c - copied, changed from r119128, trunk/gcc/testsuite/gcc.dg/Wconversion-2.c trunk/gcc/testsuite/gcc.dg/Wtraditional-conversion.c - copied, changed from r119128, trunk/gcc/testsuite/gcc.dg/Wconversion.c trunk/gcc/testsuite/gcc.dg/dfp/Wtraditional-conversion-2.c - copied, changed from r119128, trunk/gcc/testsuite/gcc.dg/dfp/Wconversion-2.c Removed: trunk/gcc/testsuite/gcc.dg/Wconversion-2.c trunk/gcc/testsuite/gcc.dg/Wconversion.c trunk/gcc/testsuite/gcc.dg/dfp/Wconversion-2.c Modified: trunk/ChangeLog trunk/gcc/ChangeLog trunk/gcc/c-typeck.c trunk/gcc/c.opt trunk/gcc/doc/invoke.texi trunk/gcc/doc/trouble.texi trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gcc.dg/builtin-protos-1.c trunk/gcc/testsuite/gcc.dg/overflow-warn-2.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=9072
[Bug ada/29958] New: Ada: gcc bug box with an inherited generic private package
$ uname -a Linux athena 2.6.17-2-486 #1 Wed Sep 13 15:56:30 UTC 2006 i686 GNU/Linux $ gcc -v Using built-in specs. Target: i486-linux-gnu Configured with: ../src/configure -v --enable-languages=c,c++,fortran,objc,obj-c++,treelang --prefix=/usr --enable-shared --with-system-zlib --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --enable-nls --program-suffix=-4.1 --enable-__cxa_atexit --enable-clocale=gnu --enable-libstdcxx-debug --enable-mpfr --with-tune=i686 --enable-checking=release i486-linux-gnu Thread model: posix gcc version 4.1.2 20061028 (prerelease) (Debian 4.1.1-19) $ gcc -c cell-list-iter-std-tools.adb +===GNAT BUG DETECTED==+ | 4.1.2 20061028 (prerelease) (Debian 4.1.1-19) (i486-pc-linux-gnu)| | Assert_Failure sem_ch7.adb:1313 | | Error detected at cell-list-iter-std-tools.ads:7:1 | | Please submit a bug report; see http://gcc.gnu.org/bugs.html.| | Use a subject line meaningful to you and us to track the bug.| | Include the entire contents of this bug box in the report. | | Include the exact gcc-4.1 or gnatmake command that you entered. | | Also include sources listed below in gnatchop format | | (concatenated together with no headers between files). | +==+ Please include these source files with error report Note that list may not be accurate in some cases, so please double check that the problem can still be reproduced with the set of files listed. cell-list-iter-std-tools.adb cell-list-iter-std-tools.ads cell-list-iter-std.ads cell-list-iter.ads cell-list.ads cell.ads cell-list-std.ads cell-list-pattern.ads compilation abandoned This code compiles with the gnat's Adacore version (gcc-3.4.6 GNAT GPL 2006 20060522). I'm sorry for the quite large list of sources files included, I'm trying to minimize it. -- Summary: Ada: gcc bug box with an inherited generic private package Product: gcc Version: 4.1.2 Status: UNCONFIRMED Severity: normal Priority: P3 Component: ada AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: chevallier_sylvain at yahoo dot fr http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29958
[Bug c/9072] -Wconversion should be split into two distinct flags
--- Comment #18 from lopezibanez at gmail dot com 2006-11-23 18:55 --- I have insufficient privileges to close this bug. Please, someone, close it as FIXED. Thanks. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=9072
[Bug ada/29958] Ada: gcc bug box with an inherited generic private package
--- Comment #1 from chevallier_sylvain at yahoo dot fr 2006-11-23 19:00 --- Created an attachment (id=12673) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12673action=view) cat of all the source files required by the bug box This is the cat of the source files named by the bug box. Again, I'm trying to reduced this error, i'm sorry for the inconvenience. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29958
[Bug fortran/29820] ICE in fold_convert, at fold-const.c:2146
--- Comment #10 from pault at gcc dot gnu dot org 2006-11-23 19:14 --- Subject: Bug 29820 Author: pault Date: Thu Nov 23 19:14:05 2006 New Revision: 119132 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=119132 Log: 2006-11-23 Paul Thomas [EMAIL PROTECTED] PR fortran/25087 * resolve.c (resolve_fl_procedure): Add an error if an external automatic character length function does not have an explicit interface. PR fortran/29652 * interface.c (check_interface1): Use a local value, instead of the dummy, as the inner iterator over interface symbols. PR fortran/29820 * trans-array.c (gfc_get_derived_type): Once done, spread the backend_decl to all identical derived types in all sibling namespaces. 2006-11-23 Paul Thomas [EMAIL PROTECTED] PR fortran/25087 * gfortran.dg/auto_char_len_4.f90: New test. PR fortran/29652 * gfortran.dg/generic_7.f90: New test. * gfortran.dg/defined_operators_1.f90: Add new error. PR fortran/29820 * gfortran.dg/used_types_13.f90: New test. Added: branches/gcc-4_2-branch/gcc/testsuite/gfortran.dg/auto_char_len_4.f90 branches/gcc-4_2-branch/gcc/testsuite/gfortran.dg/generic_7.f90 branches/gcc-4_2-branch/gcc/testsuite/gfortran.dg/used_types_13.f90 Modified: branches/gcc-4_2-branch/gcc/fortran/ChangeLog branches/gcc-4_2-branch/gcc/fortran/interface.c branches/gcc-4_2-branch/gcc/fortran/resolve.c branches/gcc-4_2-branch/gcc/fortran/trans-types.c branches/gcc-4_2-branch/gcc/testsuite/ChangeLog branches/gcc-4_2-branch/gcc/testsuite/gfortran.dg/defined_operators_1.f90 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29820
[Bug fortran/25087] Error for missing explicit interface needed.
--- Comment #7 from pault at gcc dot gnu dot org 2006-11-23 19:14 --- Subject: Bug 25087 Author: pault Date: Thu Nov 23 19:14:05 2006 New Revision: 119132 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=119132 Log: 2006-11-23 Paul Thomas [EMAIL PROTECTED] PR fortran/25087 * resolve.c (resolve_fl_procedure): Add an error if an external automatic character length function does not have an explicit interface. PR fortran/29652 * interface.c (check_interface1): Use a local value, instead of the dummy, as the inner iterator over interface symbols. PR fortran/29820 * trans-array.c (gfc_get_derived_type): Once done, spread the backend_decl to all identical derived types in all sibling namespaces. 2006-11-23 Paul Thomas [EMAIL PROTECTED] PR fortran/25087 * gfortran.dg/auto_char_len_4.f90: New test. PR fortran/29652 * gfortran.dg/generic_7.f90: New test. * gfortran.dg/defined_operators_1.f90: Add new error. PR fortran/29820 * gfortran.dg/used_types_13.f90: New test. Added: branches/gcc-4_2-branch/gcc/testsuite/gfortran.dg/auto_char_len_4.f90 branches/gcc-4_2-branch/gcc/testsuite/gfortran.dg/generic_7.f90 branches/gcc-4_2-branch/gcc/testsuite/gfortran.dg/used_types_13.f90 Modified: branches/gcc-4_2-branch/gcc/fortran/ChangeLog branches/gcc-4_2-branch/gcc/fortran/interface.c branches/gcc-4_2-branch/gcc/fortran/resolve.c branches/gcc-4_2-branch/gcc/fortran/trans-types.c branches/gcc-4_2-branch/gcc/testsuite/ChangeLog branches/gcc-4_2-branch/gcc/testsuite/gfortran.dg/defined_operators_1.f90 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25087
[Bug fortran/29652] ambiguous interface declaration undetected
--- Comment #4 from pault at gcc dot gnu dot org 2006-11-23 19:14 --- Subject: Bug 29652 Author: pault Date: Thu Nov 23 19:14:05 2006 New Revision: 119132 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=119132 Log: 2006-11-23 Paul Thomas [EMAIL PROTECTED] PR fortran/25087 * resolve.c (resolve_fl_procedure): Add an error if an external automatic character length function does not have an explicit interface. PR fortran/29652 * interface.c (check_interface1): Use a local value, instead of the dummy, as the inner iterator over interface symbols. PR fortran/29820 * trans-array.c (gfc_get_derived_type): Once done, spread the backend_decl to all identical derived types in all sibling namespaces. 2006-11-23 Paul Thomas [EMAIL PROTECTED] PR fortran/25087 * gfortran.dg/auto_char_len_4.f90: New test. PR fortran/29652 * gfortran.dg/generic_7.f90: New test. * gfortran.dg/defined_operators_1.f90: Add new error. PR fortran/29820 * gfortran.dg/used_types_13.f90: New test. Added: branches/gcc-4_2-branch/gcc/testsuite/gfortran.dg/auto_char_len_4.f90 branches/gcc-4_2-branch/gcc/testsuite/gfortran.dg/generic_7.f90 branches/gcc-4_2-branch/gcc/testsuite/gfortran.dg/used_types_13.f90 Modified: branches/gcc-4_2-branch/gcc/fortran/ChangeLog branches/gcc-4_2-branch/gcc/fortran/interface.c branches/gcc-4_2-branch/gcc/fortran/resolve.c branches/gcc-4_2-branch/gcc/fortran/trans-types.c branches/gcc-4_2-branch/gcc/testsuite/ChangeLog branches/gcc-4_2-branch/gcc/testsuite/gfortran.dg/defined_operators_1.f90 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29652
[Bug fortran/25087] Error for missing explicit interface needed.
--- Comment #8 from pault at gcc dot gnu dot org 2006-11-23 19:17 --- Fixed on trunk and 4.2 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=25087
[Bug fortran/29652] ambiguous interface declaration undetected
--- Comment #5 from pault at gcc dot gnu dot org 2006-11-23 19:18 --- Fixed on trunk and 4.2 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=29652
[Bug fortran/29820] ICE in fold_convert, at fold-const.c:2146
--- Comment #11 from pault at gcc dot gnu dot org 2006-11-23 19:19 --- Fixed on trunk and 4.2 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=29820
[Bug other/29842] outstanding patches / issues from STMicroelectronics
--- Comment #2 from amylaar at gcc dot gnu dot org 2006-11-23 19:59 --- For the -mrelax breakage, also see: http://sourceware.org/bugzilla/show_bug.cgi?id=3298 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29842
[Bug target/29961] New: SH port uses big-endian specific register numbers
The SH port internally uses fixed register numbers for MACH/MACL and the floating point registers, which are only appropriate for big endian. This prevents using SImode subregs of DFmode registers, and referring to a 64 bit multiplication result in MACH/MACL as DImode. The register numbering should be changed so that the registers always appear in the same endianness as memory, and inasmuch as they only exist because of the wrong-numbered registers, pattern and register class anomalies removed and CLASS_CANNOT_CHANGE_MODE made to return 0 whenever possible. This should allow to make best use of the rtl optimizers. -- Summary: SH port uses big-endian specific register numbers Product: gcc Version: 4.3.0 Status: UNCONFIRMED Keywords: missed-optimization Severity: normal Priority: P3 Component: target AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: amylaar at gcc dot gnu dot org GCC target triplet: sh-*-* BugsThisDependsOn: 29842 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29961
[Bug target/29943] [4.2/4.3 Regression] gcc generate incorrect alias symbols for PPC
-- amodra at bigpond dot net dot au changed: What|Removed |Added AssignedTo|amodra at bigpond dot net |unassigned at gcc dot gnu |dot au |dot org Status|ASSIGNED|NEW http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29943
[Bug libgomp/29949] implement argument checking for user accessable runtime routines
--- Comment #2 from patchapp at dberlin dot org 2006-11-23 20:30 --- Subject: Bug number PR29949 A patch for this bug has been added to the patch tracker. The mailing list url for the patch is http://gcc.gnu.org/ml/gcc-patches/2006-11/msg01644.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29949
[Bug fortran/29962] New: Initialization expressions checking in gfc_intrinsic_func_interface
We should only allow
a) elemental functions
b) we currently check gfc_init_expr_extensions():
/* FIXME: This should be moved into the intrinsic definitions. */
static const char * const init_expr_extensions[] = {
digits, epsilon, huge, kind, maxexponent, minexponent,
precision, present, radix, range, selected_real_kind,
tiny, NULL
};
I'm neither sure whether this is correct nor whether this is complete.
See: 7.1.7 Initialization expression in Fortran 2003 and
7.1.6.1 Constant expression in Fortran 95.
There is at least the following difference between the standards:
F2003: [Allowed is] A reference to an elemental standard intrinsic function,
where each argument is an initialization expression
F95:
An initialization expression is a constant expression in which the
exponentiation operation is
permitted only with an integer power, and each primary is
[...]
(4) An elemental intrinsic function reference of type integer or character
where each argument is an initialization expression of type integer or
character
--
Summary: Initialization expressions checking in
gfc_intrinsic_func_interface
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
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29962
[Bug target/29963] New: could speed up variable access with different object layout
Currently, variables are generally placed in the data or bss segment; they cannot be addressed directly, hence their address needs to be loaded into a register first. Moreover, this address load is done with a pc-relative load, which incurs extra latency. If the variable was in the text segment within pc-relative load range, integer loads could be done with pc-relative loads, while stores and floating point loads could obtain their address using the mova instruction. Using a pc-relative load saves the extra latency of the address load and/or the register that is used to hold the address. Using mova saves the address load latency, and by making the address cheper to obtain, makes it more feasible to recompute it in a loop so that harder to reload values can be kept in a register. For static variables, the compiler can determine if it is possible to place the variable within reach when the translation unit is compiled. (There are some issues with asms using directives like .rept or .org throwing off the instruction length calculations, but these are also a problem with other compiler activities requiring length calculation, i.e. branch shortening and constant pool layout, and programmers are well-advised to write their assembler templates in a way that their size will not underestimated, e.g. by passing with extra lines.) For variables with global / namespace linkage, the best placement can only be determined at link time. This could either be done using the -mrelax mechanism ( but that would need fixing first, see binutils/3298 http://sourceware.org/bugzilla/show_bug.cgi?id=3298 ), or by integrating this optimization in the LTO framework. -- Summary: could speed up variable access with different object layout Product: gcc Version: 4.3.0 Status: UNCONFIRMED Keywords: missed-optimization Severity: normal Priority: P3 Component: target AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: amylaar at gcc dot gnu dot org GCC target triplet: sh-*-* OtherBugsDependingO 29842 nThis: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29963
[Bug fortran/25392] ICEs with -ff2c
-- tobi at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |tobi at gcc dot gnu dot org |dot org | Status|NEW |ASSIGNED Last reconfirmed|2006-10-21 21:32:45 |2006-11-23 20:52:22 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25392
[Bug fortran/29962] Initialization expressions checking in gfc_intrinsic_func_interface
--- Comment #1 from burnus at gcc dot gnu dot org 2006-11-23 21:10 ---
I just realized I was too brief:
There are three types of initialization expressions (IE):
- Valid in F95
- Added as valid F2003
- Only valid as GNU extensions
We need to check:
- Is there a non-elemental function in the IE
- Is the list in gfc_init_expr_extensions() correct:
/* FIXME: This should be moved into the intrinsic definitions. */
static const char * const init_expr_extensions[] = {
digits, epsilon, huge, kind, maxexponent, minexponent,
precision, present, radix, range, selected_real_kind,
tiny, NULL
It is currently used in gfc_intrinsic_func_interface as:
if (gfc_init_expr flag gfc_init_expr_extensions (specific))
- Do we miss some other restriction?
- Do we miss another change between F95 and F2003 except that
noninteger/noncharacter arguments to elemental intrinsics are allowed?
- Is it possible to reach the gfc_notify_std (GFC_STD_GNU, block, if one
checks for if (expr-ts.type != BT_INTEGER expr-ts.type != BT_CHARACTER)
and does one allows things in F2003 which should not be allowed?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29962
[Bug libstdc++/29920] include/Makefile.am still uses CCODECVT_H
--- Comment #5 from amylaar at gcc dot gnu dot org 2006-11-23 21:22 --- Subject: Bug 29920 Author: amylaar Date: Thu Nov 23 21:22:23 2006 New Revision: 119134 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=119134 Log: 2006-11-22 Antony King [EMAIL PROTECTED] Jorn Rennecke [EMAIL PROTECTED] PR libstdc++/29920 * include/Makefile.am (stamp-host): Remove CCODECVT_H line. * include/Makefile.in: Regenerate. Modified: branches/gcc-4_2-branch/libstdc++-v3/ChangeLog branches/gcc-4_2-branch/libstdc++-v3/include/Makefile.am branches/gcc-4_2-branch/libstdc++-v3/include/Makefile.in -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29920
[Bug libstdc++/29920] include/Makefile.am still uses CCODECVT_H
--- Comment #6 from amylaar at gcc dot gnu dot org 2006-11-23 21:25 --- Fixed in Revision 119091 (mainline) / 119134 (gcc-4_2-branch) -- amylaar at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29920
[Bug c/29964] New: volatile problem in optimized functions
Using -Os and volatile results in functions, sometimes the optimizer 'forgets'
the volatile property of the function and makes it pure. This has a major
impact in some cases. Test case 1 gives buggy code where test case 2 3 works.
The command line to compile this was arm-elf-gcc -c test.c -Os
/* Test case 1 */
struct test_a { volatile int a; };
int func_a(void) __attribute__ ((noinline));
int func_a(void)
{
return ((struct test_a *)0)-a;
}
void a(void)
{
while(func_a() == 0);
}
/* Test case 2 */
struct test_b { volatile int a;};
int func_b(void) __attribute__ ((noinline));
int func_b(void)
{
volatile struct test_b *t= 0;
return t-a;
}
void b(void)
{
while(func_b() == 0);
}
/* Test case 3 */
struct test_c { volatile int a; };
int func_c(void) __attribute__ ((noinline));
int func_c(void)
{
return ((volatile struct test_c *)0)-a;
}
void c(void)
{
while(func_c() == 0);
}
The result from this is:
func_a:
0: e3a03000mov r3, #0 ; 0x0
4: e593ldr r0, [r3]
8: e12fff1ebx lr
000c a:
c: e52de004str lr, [sp, #-4]!
10: ebfebl 0 func_a
14: e350cmp r0, #0 ; 0x0
18: 0a03beq 14 a+0x8 --- looping back to the cmp!?!
1c: e49df004ldr pc, [sp], #4
0020 func_b:
20: e3a03000mov r3, #0 ; 0x0
24: e593ldr r0, [r3]
28: e12fff1ebx lr
002c b:
2c: e52de004str lr, [sp, #-4]!
30: ebfebl 20 func_b
34: e350cmp r0, #0 ; 0x0
38: 0a0abeq 30 b+0x4 --- looping back to the functon
call
3c: e49df004ldr pc, [sp], #4
0040 func_c:
40: e3a03000mov r3, #0 ; 0x0
44: e593ldr r0, [r3]
48: e12fff1ebx lr
004c c:
4c: e52de004str lr, [sp, #-4]!
50: ebfebl 40 func_c
54: e350cmp r0, #0 ; 0x0
58: 0a12beq 50 c+0x4 --- looping back to the functon
call
5c: e49df004ldr pc, [sp], #4
--
Summary: volatile problem in optimized functions
Product: gcc
Version: 4.1.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: sb at anoto dot com
GCC build triplet: x86-pc-cygwin
GCC host triplet: x86-pc-cygwin
GCC target triplet: arm-elf-gcc
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29964
[Bug c/29964] volatile problem in optimized functions
-- sb at anoto dot com changed: What|Removed |Added CC||sb at anoto dot com Severity|normal |major Keywords||wrong-code http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29964
[Bug tree-optimization/29964] [4.1/4.2/4.3 Regression] function with volatile operators still found to be pure
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-11-23 21:40 --- Confirmed. IPA pure-const pass is founds func_a as pure which is incorrect: Function found to be pure: func_a -- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||pinskia at gcc dot gnu dot ||org Severity|major |normal Status|UNCONFIRMED |NEW Component|c |tree-optimization Ever Confirmed|0 |1 GCC build triplet|x86-pc-cygwin | GCC host triplet|x86-pc-cygwin | GCC target triplet|arm-elf-gcc | Last reconfirmed|-00-00 00:00:00 |2006-11-23 21:40:57 date|| Summary|volatile problem in |[4.1/4.2/4.3 Regression] |optimized functions |function with volatile ||operators still found to be ||pure Target Milestone|--- |4.1.2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29964
[Bug fortran/29962] Initialization expressions checking in gfc_intrinsic_func_interface
--- Comment #2 from burnus at gcc dot gnu dot org 2006-11-23 21:58 --- One other thing we need to change: real, parameter :: d = 2.0**0.5 1 Error: Exponent at (1) must be INTEGER for an initialization expression This is now also allowed in F2003. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29962
[Bug tree-optimization/29964] [4.1/4.2/4.3 Regression] function with volatile operators still found to be pure
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-11-23 22:08 --- And I have a fix which I am testing right now. It moves some code around so we get the correct result. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |pinskia at gcc dot gnu dot |dot org |org Status|NEW |ASSIGNED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29964
[Bug tree-optimization/29964] [4.1/4.2/4.3 Regression] function with volatile operators still found to be pure
--- Comment #3 from pinskia at gcc dot gnu dot org 2006-11-23 22:49 ---
By the way this is the patch which I am testing:
Index: ipa-pure-const.c
===
--- ipa-pure-const.c(revision 119134)
+++ ipa-pure-const.c(working copy)
@@ -166,6 +166,14 @@ check_tree (funct_state local, tree t, b
if ((TREE_CODE (t) == EXC_PTR_EXPR) || (TREE_CODE (t) == FILTER_EXPR))
return;
+ /* Any tree which is volatile disqualifies this function from being
+ const or pure. */
+ if (TREE_THIS_VOLATILE (t))
+{
+ local-pure_const_state = IPA_NEITHER;
+ return;
+}
+
while (TREE_CODE (t) == REALPART_EXPR
|| TREE_CODE (t) == IMAGPART_EXPR
|| handled_component_p (t))
@@ -183,12 +191,13 @@ check_tree (funct_state local, tree t, b
/* Any indirect reference that occurs on the lhs
disqualifies the function from being pure or const. Any
-indirect reference to a volatile disqualifies the
-function from being pure or const. Any indirect
-reference that occurs on the rhs disqualifies the
+indirect reference that occurs on the rhs disqualifies the
function from being const. */
- if (checking_write || TREE_THIS_VOLATILE (t))
- local-pure_const_state = IPA_NEITHER;
+ if (checking_write)
+ {
+ local-pure_const_state = IPA_NEITHER;
+ return;
+ }
else if (local-pure_const_state == IPA_CONST)
local-pure_const_state = IPA_PURE;
}
@@ -541,7 +550,7 @@ analyze_function (struct cgraph_node *fn
walk_tree (bsi_stmt_ptr (bsi), scan_function,
fn, visited_nodes);
if (l-pure_const_state == IPA_NEITHER)
- return;
+ goto end;
}
}
@@ -568,6 +577,14 @@ analyze_function (struct cgraph_node *fn
pop_cfun ();
}
}
+
+end:
+ if (dump_file)
+{
+ fprintf (dump_file, after local analysis of %s with initial value =
%d\n ,
+ cgraph_node_name (fn),
+ l-pure_const_state);
+}
}
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29964
[Bug c/9072] -Wconversion should be split into two distinct flags
--- Comment #19 from pinskia at gcc dot gnu dot org 2006-11-23 22:51 --- (In reply to comment #18) I have insufficient privileges to close this bug. Please, someone, close it as FIXED. Thanks. You should be able to use your @gcc.gnu.org account to close the bug report. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED Target Milestone|--- |4.3.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=9072
[Bug objc/29965] New: Objective-C exceptions vs OpenMP
The following program causes an ICE with -fopenmp -fexceptions:
extern void bar (int);
void
foo (int n)
{
int i;
#pragma omp parallel for schedule(dynamic)
for (i = 0; i n; i++)
{
bar (0);
@throw 0;
}
}
--
Summary: Objective-C exceptions vs OpenMP
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
Keywords: ice-on-valid-code, openmp
Severity: normal
Priority: P3
Component: objc
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: pinskia at gcc dot gnu dot org
GCC target triplet: i686-pc-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29965
[Bug middle-end/29965] OpenMP vs always throw in a loop
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-11-23 23:04 ---
Actually you can reproduce the same ICE (with the same backtrace) with C++
code:
extern void bar (int);
void
foo (int n)
{
int i;
#pragma omp parallel for schedule(dynamic)
for (i = 0; i n; i++)
{
throw 0;
}
}
So this is not specific to Objective-C any more.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Component|objc|middle-end
Summary|Objective-C exceptions vs |OpenMP vs always throw in a
|OpenMP |loop
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29965
[Bug fortran/29962] Initialization expressions checking in gfc_intrinsic_func_interface
--- Comment #3 from burnus at gcc dot gnu dot org 2006-11-23 23:51 ---
Non-elemental intrinsic functions in Section 13.7 of Fortran 2003:
ALL(T), ALLOCATED(I), ANY(T), ASSOCIATED(I), BIT_SIZE(I),
COMMAND_ARGUMENT_COUNT(I), COUNT(T), CSHIFT(T), DIGITS(I), DOT_PRODUCT(T),
EOSHIFT(T), EPSILON(I), EXTENDS_TYPE_OF(I), HUGE(I), KIND(I), LBOUND(I),
LEN(I), MATMUL(T), MAXLOC(T), MAXVAL(T), MINLOC(T), MINVAL(T), NEW_LINE(I),
NULL(T), PACK(T), PRECISION(I), PRESENT(I), PRODUCT(T), RADIX(I), RANGE(I),
REPEAT(T), RESHAPE(T), SAME_TYPE_AS(I), SELECTED_CHAR_KIND(T),
SELECTED_INT_KIND(T), SELECTED_REAL_KIND(T), SHAPE(I), SIZE(I), SPREAD(T),
SUM(T), TINY(I), TRANSFER(T), TRANPOSE(T), TRIM(T), UBOUND(I), UNPACK(T),
(I) = Inquiry functiony
(T) = Transformational function
Allowed in Fortran 2003:
- elemental standard intrinsic functions (with argument = initialization
expression)
- transformational standard intrinsic functions (constrain: dito), not NULL()
- NULL() without non-initialization expression type parameters
- Inquiry function where argument is either an initialization expression - or
when not needed - properties are not deferred/assumed or noninit. expr.
From modules:
- IEEE_SELECTED_REAL_KIND
(Remark: This seems to allow command_line_argument(), but this is technically
not possible! -- well, if it is not supported, 0 can be returned)
Fortran 95:
- elemental functions: Only with initi.expr. of integer/character type
- Transformational functions: Only REPEAT, RESHAPE, SELECTED_INT_KIND,
SELECTED_REAL_KIND, TRANSFER, TRIM: w/ init.expr.-
- NULL
- Array inquiry function but not ALLOCATED [i.e.: lbound, ubound, shape, size,
]
- BIT_SIZE, LEN, KIND
- Numeric inquiry function: digits, epsilon,huge,maxexponent, minexponent,
precision, radix,range,tiny
I don't think GFC_STD_GNU allows more than Fortran 2003 (and extra intrinsics
of -std=gnu are filtered out earlier).
Current problems:
---
real :: p
real, parameter :: x = TRANSFER('a',p)
end
Error:
Parameter 'p' at (1) has not been declared or is a variable, which does not
reduce to a constant expression
Works with g95, fails with ifort, f95, sunf95.
I believe this is valid in Fortran 95 (and Fortran 2003)
---
real, parameter :: x = dot_product( (/1/), (/2/))
1
Error: transformational intrinsic 'dot_product' at (1) is not permitted in an
initialization expression
- Should be valid in Fortran 2003
- fails also in g95, f95, ifort
Presumably analogously: matmul, ...
---
--
burnus at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Last reconfirmed|-00-00 00:00:00 |2006-11-23 23:51:55
date||
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29962
[Bug preprocessor/29966] New: crash in cc1 with backtrace from free()
Both gcc and g++ crash on this. (I'll attach the code later, as it's still kind of large.) Seemingly innocent changes will affect the crash behavior. Normally I compile with -std=gnu99 -O2; this is intended to be C code. These very similar programs give different errors at times, especially when using -O0 instead of -O2. I suppose I'll blame the preprocessor, but changing from -O2 to -O0 will usualy (not always) cause the crash to be a regular SIGSEGV instead of a glibc backtrace. I suppose the preprocessor is all unified now though, so a bit of memory corruption could make things go weird later. $ gcc -std=gnu99 -O0 gcc-bug4.c gcc-bug4.c: In function boomwrap: gcc-bug4.c:134: error: invalid application of sizeof to incomplete type struct dief gcc-bug4.c:138: error: expected : before ) token gcc-bug4.c:138: error: expected statement before ) token gcc-bug4.c:138: error: expected expression before : token gcc-bug4.c:141: error: expected : before ) token gcc-bug4.c:141: error: expected statement before ) token gcc-bug4.c:141: error: expected expression before : token gcc-bug4.c:141: error: expected : before ) token gcc-bug4.c:141: error: expected statement before ) token gcc-bug4.c:141: error: expected expression before : token gcc-bug4.c:142: error: expected : before ) token gcc-bug4.c:142: error: expected statement before ) token gcc-bug4.c:142: error: expected expression before : token gcc-bug4.c:447:1: error: unterminated argument list invoking macro swap32 gcc-bug4.c:142: error: swap32 undeclared (first use in this function) gcc-bug4.c:142: error: (Each undeclared identifier is reported only once gcc-bug4.c:142: error: for each function it appears in.) gcc-bug4.c:142: error: expected ; at end of input gcc-bug4.c:142: error: expected declaration or statement at end of input *** glibc detected *** /usr/libexec/gcc/x86_64-redhat-linux/4.1.1/cc1: free(): invalid next size (normal): 0x00c939e0 *** === Backtrace: = /lib64/libc.so.6[0x347e06eb00] /lib64/libc.so.6(cfree+0x8c)[0x347e07227c] /usr/libexec/gcc/x86_64-redhat-linux/4.1.1/cc1[0x696bfd] /usr/libexec/gcc/x86_64-redhat-linux/4.1.1/cc1[0x746e53] /usr/libexec/gcc/x86_64-redhat-linux/4.1.1/cc1[0x747224] /usr/libexec/gcc/x86_64-redhat-linux/4.1.1/cc1[0x40af09] /usr/libexec/gcc/x86_64-redhat-linux/4.1.1/cc1[0x4476ee] /usr/libexec/gcc/x86_64-redhat-linux/4.1.1/cc1[0x44e164] /usr/libexec/gcc/x86_64-redhat-linux/4.1.1/cc1[0x439aea] /usr/libexec/gcc/x86_64-redhat-linux/4.1.1/cc1[0x6e9ac5] /lib64/libc.so.6(__libc_start_main+0xf4)[0x347e01da44] /usr/libexec/gcc/x86_64-redhat-linux/4.1.1/cc1(calloc+0x191)[0x402399] === Memory map: 0040-00972000 r-xp 08:07 2734449 /usr/libexec/gcc/x86_64-redhat-linux/4.1.1/cc1 00b72000-00b79000 rw-p 00572000 08:07 2734449 /usr/libexec/gcc/x86_64-redhat-linux/4.1.1/cc1 00b79000-00c9a000 rw-p 00b79000 00:00 0 [heap] 347d00-347d01a000 r-xp 08:07 1974387 /lib64/ld-2.4.90.so 347d219000-347d21a000 r--p 00019000 08:07 1974387 /lib64/ld-2.4.90.so 347d21a000-347d21b000 rw-p 0001a000 08:07 1974387 /lib64/ld-2.4.90.so 347e00-347e144000 r-xp 08:07 1974396 /lib64/libc-2.4.90.so 347e144000-347e344000 ---p 00144000 08:07 1974396 /lib64/libc-2.4.90.so 347e344000-347e348000 r--p 00144000 08:07 1974396 /lib64/libc-2.4.90.so 347e348000-347e349000 rw-p 00148000 08:07 1974396 /lib64/libc-2.4.90.so 347e349000-347e34e000 rw-p 347e349000 00:00 0 3489a0-3489a0d000 r-xp 08:07 1974339 /lib64/libgcc_s-4.1.1-20060828.so.1 3489a0d000-3489c0c000 ---p d000 08:07 1974339 /lib64/libgcc_s-4.1.1-20060828.so.1 3489c0c000-3489c0d000 rw-p c000 08:07 1974339 /lib64/libgcc_s-4.1.1-20060828.so.1 2aaab000-2aaac000 rw-p 2aaab000 00:00 0 2aac3000-2aac5000 rw-p 2aac3000 00:00 0 2aac5000-2dfb7000 r--p 08:07 833564 /usr/lib/locale/locale-archive 2dfb7000-2e484000 rw-p 2dfb7000 00:00 0 2aaab000-2aaab0021000 rw-p 2aaab000 00:00 0 2aaab0021000-2aaab400 ---p 2aaab0021000 00:00 0 7fffc45dc000-7fffc45f2000 rw-p 7fffc45dc000 00:00 0 [stack] ff60-ffe0 ---p 00:00 0 [vdso] gcc-bug4.c:142: confused by earlier errors, bailing out -- Summary: crash in cc1 with backtrace from free() Product: gcc Version: 4.1.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: preprocessor AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: acahalan at gmail dot com
[Bug preprocessor/29966] crash in cc1 with backtrace from free()
--- Comment #1 from acahalan at gmail dot com 2006-11-23 23:59 --- Created an attachment (id=12676) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12676action=view) crash1.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29966
[Bug preprocessor/29966] crash in cc1 with backtrace from free()
--- Comment #2 from acahalan at gmail dot com 2006-11-24 00:00 --- Created an attachment (id=12677) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12677action=view) crash2.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29966
[Bug preprocessor/29966] crash in cc1 with backtrace from free()
--- Comment #3 from acahalan at gmail dot com 2006-11-24 00:01 --- Created an attachment (id=12678) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12678action=view) crash3.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29966
[Bug preprocessor/29966] crash in cc1 with backtrace from free()
--- Comment #4 from acahalan at gmail dot com 2006-11-24 00:01 --- Created an attachment (id=12679) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12679action=view) crash4.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29966
[Bug preprocessor/29966] crash in cc1 with backtrace from free()
--- Comment #5 from acahalan at gmail dot com 2006-11-24 00:02 --- Created an attachment (id=12680) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12680action=view) crash5.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29966
[Bug debug/28834] [4.0/4.1/4.2/4.3 Regression] -O3 -g crashes sometimes when using may_alias and structs
--- Comment #17 from acahalan at gmail dot com 2006-11-24 00:11 --- (In reply to comment #13) The question I asked is why doesn't this happen for 'const'? That turned out to be a good question, because it leads to the better question of what debugging output did you expect for this code, anyway? It seems to me that __noalias__ is an interesting attribute that should be somehow reflected in the DWARF. That would require a GNU extension, of course. Rather than comparing this with const, compare it with restrict. This deserves representation in DWARF if and only if restrict deserves it. (and that I can't answer, but my gut feeling is that such representation should be only for things that C++ would put into name mangling) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28834
[Bug preprocessor/29966] crash in cc1 with backtrace from free()
--- Comment #6 from pinskia at gcc dot gnu dot org 2006-11-24 00:17 --- valgrind on the mainline shows begining with: ==11886== Invalid write of size 1 ==11886==at 0x8592FE0: _cpp_lex_direct (lex.c:881) ==11886== Address 0x48DD485 is 5 bytes after a block of size 4,000 alloc'd ==11886==at 0x40051F9: malloc (vg_replace_malloc.c:149) ==11886==by 0x85AD1F5: xmalloc (xmalloc.c:147) 4.0.4 and 4.1.2 all have the same issue. I have not looked at 3.4.6 yet to see if this is a regression. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Keywords||ice-on-invalid-code Known to fail||4.0.4 4.1.2 4.2.0 4.3.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29966
[Bug c/2707] gcc does not warn on truncate
--- Comment #7 from manu at gcc dot gnu dot org 2006-11-24 01:50 --- Subject: Bug 2707 Author: manu Date: Fri Nov 24 01:50:33 2006 New Revision: 119143 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=119143 Log: 2006-11-24 Manuel Lopez-Ibanez [EMAIL PROTECTED] PR c/2707 PR c++/26167 * c-common.c (conversion_warning): New. (convert_and_check): Call conversion_warning unless there is an overflow warning. * doc/invoke.texi (-Wconversion): Update description. testsuite/ * gcc.dg/Wconversion-integer.c: New. Supersedes Wconversion-negative-constants.c * gcc.dg/Wconversion-real.c: New. * gcc.dg/Wconversion-real-integer.c: New. * gcc.dg/Wconversion-negative-constants.c: Deleted. * g++.dg/warn/Wconversion1.C: Modified. Added: trunk/gcc/testsuite/gcc.dg/Wconversion-integer.c trunk/gcc/testsuite/gcc.dg/Wconversion-real-integer.c trunk/gcc/testsuite/gcc.dg/Wconversion-real.c Removed: trunk/gcc/testsuite/gcc.dg/Wconversion-negative-constants.c Modified: trunk/gcc/ChangeLog trunk/gcc/c-common.c trunk/gcc/doc/invoke.texi trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/g++.dg/warn/Wconversion1.C -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=2707
[Bug c++/26167] -Wconversion fails to detect signedness conversion from int to unsigned int in fuction call
--- Comment #15 from manu at gcc dot gnu dot org 2006-11-24 01:50 --- Subject: Bug 26167 Author: manu Date: Fri Nov 24 01:50:33 2006 New Revision: 119143 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=119143 Log: 2006-11-24 Manuel Lopez-Ibanez [EMAIL PROTECTED] PR c/2707 PR c++/26167 * c-common.c (conversion_warning): New. (convert_and_check): Call conversion_warning unless there is an overflow warning. * doc/invoke.texi (-Wconversion): Update description. testsuite/ * gcc.dg/Wconversion-integer.c: New. Supersedes Wconversion-negative-constants.c * gcc.dg/Wconversion-real.c: New. * gcc.dg/Wconversion-real-integer.c: New. * gcc.dg/Wconversion-negative-constants.c: Deleted. * g++.dg/warn/Wconversion1.C: Modified. Added: trunk/gcc/testsuite/gcc.dg/Wconversion-integer.c trunk/gcc/testsuite/gcc.dg/Wconversion-real-integer.c trunk/gcc/testsuite/gcc.dg/Wconversion-real.c Removed: trunk/gcc/testsuite/gcc.dg/Wconversion-negative-constants.c Modified: trunk/gcc/ChangeLog trunk/gcc/c-common.c trunk/gcc/doc/invoke.texi trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/g++.dg/warn/Wconversion1.C -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26167
[Bug c++/26167] -Wconversion fails to detect signedness conversion from int to unsigned int in fuction call
--- Comment #16 from manu at gcc dot gnu dot org 2006-11-24 01:56 --- Fixed in mainline. -- manu at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED Target Milestone|--- |4.3.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26167
[Bug c/2707] gcc does not warn on truncate
--- Comment #8 from manu at gcc dot gnu dot org 2006-11-24 01:59 --- Fixed in mainline. -- manu at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED Target Milestone|--- |4.3.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=2707
[Bug target/21323] internal compiler error: Segmentation fault
--- Comment #8 from pinskia at gcc dot gnu dot org 2006-11-24 02:00 --- No feedback in over 3 months so closing. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|WAITING |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21323
[Bug fortran/29882] gfortran testsuite doesn't recognize warnings and errors
--- Comment #4 from pinskia at gcc dot gnu dot org 2006-11-24 02:10 --- Confirmed. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2006-11-24 02:10:43 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29882
[Bug c++/29883] i686-pc-cygwin/3.4.4 - internal compiler error: Segmentation fault
--- Comment #3 from pinskia at gcc dot gnu dot org 2006-11-24 02:17 --- This works for me in 4.0.4 on i686-linux-gnu. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29883
[Bug tree-optimization/29877] [4.0/4.1/4.2 Regression] out of SSA (TER) extends variable life of variable beyond original declared
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added Keywords||wrong-code Summary|out of SSA (TER) extends|[4.0/4.1/4.2 Regression] out |variable life of variable |of SSA (TER) extends |beyond original declared|variable life of variable ||beyond original declared Target Milestone|--- |4.0.4 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29877
[Bug tree-optimization/29902] [4.2 Regression] ICE in coalesce_abnormal_edges, at tree-outof-ssa.c:644
--- Comment #8 from pinskia at gcc dot gnu dot org 2006-11-24 02:23 --- Fixed on the trunk. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Summary|[4.2/4.3 Regression] ICE in |[4.2 Regression] ICE in |coalesce_abnormal_edges, at |coalesce_abnormal_edges, at |tree-outof-ssa.c:644|tree-outof-ssa.c:644 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29902
[Bug target/29907] ARM Optimization Bug
--- Comment #4 from pinskia at gcc dot gnu dot org 2006-11-24 02:34 --- (In reply to comment #3) The C standard permits structures to have common layout for *initial* elements and casting between these *is* permitted. But your code is taking the address of an element in the *middle* of the structure and this has no defined behaviour in the standard. Consider, for example The only time the C standard mentions initial elements is with respect of unions and not aliasing. In terms of aliasing it mentions about structs containing other structs but that is common sense there :). So this testcase is invalid too. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED GCC build triplet|arm-rtems-gcc -O2 -g -c | |test.c | Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29907
[Bug java/29929] libjvm is missing a .so version
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-11-24 02:36 --- As explained already this is not a bug. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29929
[Bug rtl-optimization/29950] Generated code changes after unrelated edits in source.
--- Comment #3 from pinskia at gcc dot gnu dot org 2006-11-24 02:51 --- Most likely something is being hashed by addresses and then transversing the hashtable or an unstable sort due to using addresses as the last compare. A lot of these issues were fixed in 4.2.0 so this might be fixed already. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29950
[Bug fortran/29951] incorrect conversion from string to integer by TRANSFER()
--- Comment #4 from pinskia at gcc dot gnu dot org 2006-11-24 03:00 ---
(In reply to comment #2)
Confirmed.
For transfer(string, integer), gfortran's transfer only uses the first
character (byte).
It should use all characters.
-fdump-tree-original:
value = VIEW_CONVERT_EXPRint4(byte_string[1]{lb: 1 sz: 1});
Hmm, I think this is only a bug in 4.3.0 but this was reported against 4.2.0.
The above VCE is my fault and I have to figure that out but I think there is
something else going wrong if it fails for 4.2.0 since my VCE patch was not
applied there. I guess I might have revert the VCE patch and create a new one
with memcpy and just hope someone optimizes memcpy better.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
CC||pinskia at gcc dot gnu dot
||org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29951
[Bug ada/29958] Ada: gcc bug box with an inherited generic package
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-11-24 03:06 --- Still fails as of today. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29958
[Bug target/29693] ICE while compiling gcc-3.4.3 with gcc-4.1.1
--- Comment #3 from pinskia at gcc dot gnu dot org 2006-11-24 03:43 ---
Reduced Testcase:
unsigned char dwarf_reg_size_table[63 +1];
init_dwarf_reg_size_table (void)
{
__builtin_init_dwarf_reg_size_table (dwarf_reg_size_table);
}
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Last reconfirmed|-00-00 00:00:00 |2006-11-24 03:43:57
date||
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29693
[Bug target/29967] New: wrong code generated with -O2 on sh4-linux
gcc 4.1.1 generates wrong code for following source with -O2
on sh4-linux.
'-fno-schedule-insns' fixes this problem.
int *p = 0;
void *bar()
{
return (void *)p;
}
void foo (int code)
{
void **pp;
pp = bar();
*pp = malloc (sizeof (int));
**(int **)pp = code; /* segmentation fault here */
}
int main()
{
foo(1);
}
--
Summary: wrong code generated with -O2 on sh4-linux
Product: gcc
Version: 4.1.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: sugioka at itonet dot co dot jp
GCC build triplet: sh4-unknown-linux
GCC host triplet: sh4-unknown-linux
GCC target triplet: sh4-unknown-linux
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29967
[Bug target/29967] wrong code generated with -O2 on sh4-linux
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-11-24 06:00 --- *pp = malloc (sizeof (int)); **(int **)pp = code; /* segmentation fault here */ You are violating aliasing rules in that void* does not alias int* so the optimizers are swapping around the store to *pp and the load of *(int**)(pp). -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29967
[Bug target/29967] wrong code generated with -O2 on sh4-linux
--- Comment #2 from sugioka at itonet dot co dot jp 2006-11-24 06:20 --- This code is reduced from gcc/java/expr.c(add_type_assertion). jc1 is really miscompiled on sh4-linux, so bootstrapping libgcj fails with segmentation fault in jc1. Should gcc/java/expr.c be fixed ? It would be better if I got warning about aliasing rule violation. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29967
Re: [Bug target/29967] wrong code generated with -O2 on sh4-linux
On Fri, 2006-11-24 at 06:20 +, sugioka at itonet dot co dot jp wrote: --- Comment #2 from sugioka at itonet dot co dot jp 2006-11-24 06:20 --- This code is reduced from gcc/java/expr.c(add_type_assertion). jc1 is really miscompiled on sh4-linux, so bootstrapping libgcj fails with segmentation fault in jc1. Should gcc/java/expr.c be fixed ? Yes it should. A warning is hard here unless we change the warning to be based on the flow. Thanks, Andrew Pinski
[Bug target/29967] wrong code generated with -O2 on sh4-linux
--- Comment #3 from pinskia at gmail dot com 2006-11-24 06:32 --- Subject: Re: wrong code generated with -O2 on sh4-linux On Fri, 2006-11-24 at 06:20 +, sugioka at itonet dot co dot jp wrote: --- Comment #2 from sugioka at itonet dot co dot jp 2006-11-24 06:20 --- This code is reduced from gcc/java/expr.c(add_type_assertion). jc1 is really miscompiled on sh4-linux, so bootstrapping libgcj fails with segmentation fault in jc1. Should gcc/java/expr.c be fixed ? Yes it should. A warning is hard here unless we change the warning to be based on the flow. Thanks, Andrew Pinski -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29967
[Bug fortran/29962] Initialization expressions checking in gfc_intrinsic_func_interface
--- Comment #4 from burnus at gcc dot gnu dot org 2006-11-24 07:19 --- Some more points (thanks to Richard Main for pointing out): Not all inquiry functions are allowed but only specification inquiry listed in 7.1.6: - Array inquiry (14.5.7; lbound, ubound, shape, size) - bit_size - len - kind - new_line - numeric inquiry (13.5.8, digits, epsilon, huge, maxexponent, minexponent, precision, radix, range, tiny) - type parameter inquiry (6.1.3): designator % type-parm-name (examples: a%kind, a%len, b(10)%kind, p%len) - IEEE inquiry function (14.9.1: IEEE_support_flag, IEEE_support_flag; IEEE_support_datatype, IEEE_support_denormal, IEEE_support_divide, IEEE_support_inf, IEEE_support_io, IEEE_support_nan, IEEE_support_rounding, IEEE_support_sqrt, IEEE_support_standard, IEEE_support_underflow_control -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29962
[Bug c++/29883] i686-pc-cygwin/3.4.4 - internal compiler error: Segmentation fault
--- Comment #4 from dannysmith at users dot sourceforge dot net 2006-11-24 07:43 --- This works for me too, using same cygwin distro of gcc-3.4.4, same command line (g++ -Wall -o Employee.h Employee.h -mno-cygwin), cygwin version 1.5.22. Could it be a mmap vs .pch problem that is now fixed in cygwin1.dll? Also works with mingw (3.4.5, 4.1.2, 4.2.0), but my text editor surely does have problems with the 6+MB pch file now disguising itself as the input header file :(. Danny -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29883
