[Bug fortran/36517] New: Type-spec in array constructor ignored for PARAMETER
Type spec support for constructors was implemented in PR27997, however, it is not honored for the -std=f* checking for PARAMETERs. The following program works with default options, however, using -std=f2003 one gets the follow error message: Error: The CHARACTER elements of the array constructor at (1) must have the same length (1/3) (To compile the first two lines, the patch of PR36476 is needed.) CHARACTER (len=*) MY_STRING(1:3) PARAMETER ( MY_STRING = (/CHARACTER (len=3) :: AC , B, C /) ) character(len=*), parameter :: str(2) = [character(len=3):: 'A','cc'] end -- Summary: Type-spec in array constructor ignored for PARAMETER Product: gcc Version: 4.4.0 Status: UNCONFIRMED Keywords: diagnostic Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: burnus at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36517
[Bug fortran/36495] libgfortran should be build with FCFLAGS -fimplicit-none
--- Comment #3 from burnus at gcc dot gnu dot org 2008-06-13 07:11 --- Subject: Bug 36495 Author: burnus Date: Fri Jun 13 07:10:15 2008 New Revision: 136740 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=136740 Log: 2008-06-13 Tobias Burnus [EMAIL PROTECTED] PR fortran/36495 * configure: Add -Werror -fimplicit-none to the AM_FCFLAGS. * configure.ac: Ditto. * intrinsics/dprod_r8.f90: Add implicit none. Modified: trunk/libgfortran/ChangeLog trunk/libgfortran/configure trunk/libgfortran/configure.ac trunk/libgfortran/intrinsics/dprod_r8.f90 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36495
[Bug fortran/36518] New: libgfortran: warning: format '%d' expects type 'int', but
I get the following warnings when building libgfortran. I think they should be fixed and libgfortran should be build with -Werror. generated/all_l1.c:142: warning: format '%d' expects type 'int', but argument 2 has type 'index_type' generated/all_l2.c:142: warning: format '%d' expects type 'int', but argument 2 has type 'index_type' generated/all_l4.c:142: warning: format '%d' expects type 'int', but argument 2 has type 'index_type' generated/all_l8.c:142: warning: format '%d' expects type 'int', but argument 2 has type 'index_type' generated/all_l16.c:142: warning: format '%d' expects type 'int', but argument 2 has type 'index_type' generated/any_l1.c:142: warning: format '%d' expects type 'int', but argument 2 has type 'index_type' generated/any_l2.c:142: warning: format '%d' expects type 'int', but argument 2 has type 'index_type' generated/any_l4.c:142: warning: format '%d' expects type 'int', but argument 2 has type 'index_type' generated/any_l8.c:142: warning: format '%d' expects type 'int', but argument 2 has type 'index_type' generated/any_l16.c:142: warning: format '%d' expects type 'int', but argument 2 has type 'index_type' generated/count_1_l.c:142: warning: format '%d' expects type 'int', but argument 2 has type 'index_type' generated/count_2_l.c:142: warning: format '%d' expects type 'int', but argument 2 has type 'index_type' generated/count_4_l.c:142: warning: format '%d' expects type 'int', but argument 2 has type 'index_type' generated/count_8_l.c:142: warning: format '%d' expects type 'int', but argument 2 has type 'index_type' generated/count_16_l.c:142: warning: format '%d' expects type 'int', but argument 2 has type 'index_type' -- Summary: libgfortran: warning: format '%d' expects type 'int', but Product: gcc Version: 4.4.0 Status: UNCONFIRMED 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=36518
[Bug fortran/36495] libgfortran should be build with FCFLAGS -fimplicit-none
--- Comment #4 from burnus at gcc dot gnu dot org 2008-06-13 07:43 --- FIXED on the trunk (4.4.0). (For building also the C part of libgfortran with -Werror, see PR36518; the .f90f.in file in libgomp has now also implicit none [Rev. 136703]; however, -fimplict-none is not used in libgomp as it also affects libgomp/testsuite/.) -- 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=36495
[Bug tree-optimization/36511] [4.4 Regression] ice for legal code with -O2
--- Comment #1 from rguenth at gcc dot gnu dot org 2008-06-13 08:14 ---
Confirmed. We do not create a EH region in the first place even though
fprintf and fputs could throw. When CCP folds fputs to fputc it hits
the propagator assert
if (tree_could_throw_p (new_stmt))
{
eh_region = lookup_stmt_eh_region (stmt);
/* We couldn't possibly turn a nothrow into a throw statement. */
gcc_assert (eh_region = 0);
where /* We couldn't possibly turn a nothrow into a throw statement. */ is
obviously only true if we'd have created a EH region in the first place.
So either that we didn't is a bug or the assert should be
gcc_assert (eh_region = 0 || tree_could_throw_p (stmt));
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Component|c++ |tree-optimization
Ever Confirmed|0 |1
Keywords||ice-on-valid-code
Known to work||4.3.1
Last reconfirmed|-00-00 00:00:00 |2008-06-13 08:14:17
date||
Summary|ice for legal code with -O2 |[4.4 Regression] ice for
||legal code with -O2
Target Milestone|--- |4.4.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36511
[Bug other/36519] New: [4.3 Regression] time/memory hog for c++ source.
i discovered one more problem with 4.3 branch head with patch suggested in comment http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36498#c7 stats: gcc-4.3-20080417 : ~500MB, 50 seconds. gcc-4.3-head+patch : 5GB, 100% cpu, 40 minutes and still going... # command line: x86_64-gnu-linux-g++ esClockAnalyzerPrimitivesInitialization.ii \ -c -std=gnu++0x -g0 -O2 (gdb) bt #0 0x00703f4f in VN_INFO () #1 0x007082ab in run_scc_vn () #2 0x006fe95b in execute_pre () #3 0x006ff27e in execute_fre () #4 0x005f4c18 in execute_one_pass () #5 0x005f4dac in execute_pass_list () #6 0x005f4dbe in execute_pass_list () #7 0x00697b22 in tree_rest_of_compilation () #8 0x00796002 in cgraph_expand_function () #9 0x0079774e in cgraph_optimize () #10 0x0044864f in cp_write_global_declarations () #11 0x0066628e in toplev_main () #12 0x2b6fe60a34a4 in __libc_start_main () from /lib64/libc.so.6 #13 0x00402709 in _start () -- Summary: [4.3 Regression] time/memory hog for c++ source. Product: gcc Version: 4.3.2 Status: UNCONFIRMED Severity: normal Priority: P3 Component: other AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: pluto at agmk dot net GCC target triplet: x86_64-gnu-linux http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36519
[Bug other/36519] [4.3 Regression] time/memory hog for c++ source.
--- Comment #1 from pluto at agmk dot net 2008-06-13 08:17 --- Created an attachment (id=15759) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15759action=view) testcase -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36519
[Bug middle-end/36520] New: [4.4 Regression] ICE in get_memory_rtx
Program received signal SIGSEGV, Segmentation fault. 0x00b3b4e0 in host_integerp (t=0x0, pos=0) at /space/rguenther/src/svn/trunk/gcc/tree.c:4938 4938 return (TREE_CODE (t) == INTEGER_CST #1 0x00504a0d in get_memory_rtx (exp=0x2b5573d27870, len=0x2b5573b18420) at /space/rguenther/src/svn/trunk/gcc/builtins.c:1128 #2 0x0050e97b in expand_builtin_memcpy (exp=0x2b5573d705a0, target=0x2b55730d6450, mode=VOIDmode) at /space/rguenther/src/svn/trunk/gcc/builtins.c:3354 possibly caused by 2008-06-11 Eric Botcazou [EMAIL PROTECTED] Olivier Hainque [EMAIL PROTECTED] * builtins.c (get_memory_rtx): Accept byte-addressable bitfields. Use DECL_SIZE_UNIT to retrieve the size of the field. -- Summary: [4.4 Regression] ICE in get_memory_rtx Product: gcc Version: 4.4.0 Status: UNCONFIRMED Keywords: ice-on-valid-code Severity: normal Priority: P3 Component: middle-end AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: rguenth at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36520
[Bug middle-end/36520] [4.4 Regression] ICE in get_memory_rtx
--- Comment #1 from rguenth at gcc dot gnu dot org 2008-06-13 08:33 ---
Testcase from net-tools:
typedef long unsigned int size_t;
typedef unsigned short int sa_family_t;
struct cmsghdr {
size_t cmsg_len;
__extension__ unsigned char __cmsg_data [];
};
typedef unsigned int uint32_t;
struct in6_addr {
union {
uint32_t u6_addr32[4];
} in6_u;
};
struct sockaddr_in {
sa_family_t sin_family;
};
struct in6_pktinfo {
struct in6_addr ipi6_addr;
};
typedef union {
struct sockaddr_in sin;
} sockaddr_any;
static sockaddr_any src_addr;
inline struct cmsghdr * cmsg_put(struct cmsghdr *cm, int type, void *data,
size_t len) {
memcpy(((cm)-__cmsg_data), data, len);
}
int hop_sendmsg(int fd) {
struct cmsghdr *cm;
if (src_addr.sin.sin_family) {
if (src_addr.sin.sin_family == 2) {
struct in6_pktinfo info;
cm = cmsg_put(cm, 50, info, sizeof(info));
}
}
}
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36520
[Bug middle-end/36520] [4.4 Regression] ICE in get_memory_rtx
--- Comment #2 from rguenth at gcc dot gnu dot org 2008-06-13 08:35 ---
For
struct cmsghdr {
size_t cmsg_len;
__extension__ unsigned char __cmsg_data [];
};
DECL_SIZE{_UNIT} of __cmsg_data is NULL.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36520
[Bug other/36498] [4.3 Regression] time/memory hog for large c++ source.
--- Comment #13 from rguenth at gcc dot gnu dot org 2008-06-13 08:42 --- Subject: Bug 36498 Author: rguenth Date: Fri Jun 13 08:41:45 2008 New Revision: 136744 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=136744 Log: 2008-06-13 Richard Guenther [EMAIL PROTECTED] PR tree-optimization/36498 * tree-flow-inline.h (var_can_have_subvars): Unions cannot have subvars. Modified: branches/gcc-4_3-branch/gcc/ChangeLog branches/gcc-4_3-branch/gcc/tree-flow-inline.h -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36498
[Bug middle-end/36520] [4.4 Regression] ICE in get_memory_rtx
--- Comment #3 from ebotcazou at gcc dot gnu dot org 2008-06-13 08:46
---
For
struct cmsghdr {
size_t cmsg_len;
__extension__ unsigned char __cmsg_data [];
};
DECL_SIZE{_UNIT} of __cmsg_data is NULL.
I wondered if this could happen... now I know. :-) Fixing...
--
ebotcazou at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |ebotcazou at gcc dot gnu dot
|dot org |org
Status|UNCONFIRMED |ASSIGNED
Ever Confirmed|0 |1
Last reconfirmed|-00-00 00:00:00 |2008-06-13 08:46:56
date||
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36520
[Bug c/36521] New: Expression in for expression gets wrong value
The program below on gcc 4.1.2 prints:
gcc4 test.c
./a.out
got 0
x
y
done
--
The program below on gcc 3.4.4 prints:
gcc test.c
./a.out
got 0
x
y
and then locks up...
--
#include stdio.h
int main()
{
unsigned int var102 = 1;
int a = ( var102 0x1eU sizeof 290 );
printf(got %d\n, a); fflush(stdout);
for ( ; 0; )
{}
printf(x\n); fflush(stdout);
for ( ; a; )
{}
printf(y\n); fflush(stdout);
for ( ; ( var102 0x1eU sizeof 290 ); ) // Fails here
{}
printf(done\n);
return 0;
}
--
Summary: Expression in for expression gets wrong value
Product: gcc
Version: 3.4.4
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: peter at xmos dot com
GCC build triplet: gcc (GCC) 3.4.4 (cygming special, gdc 0.12, using dmd
0.125)
GCC host triplet: CYGWIN_NT-5.1 duane 1.5.24(0.156/4/2) 2007-01-31 10:57
i686 Cygw
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36521
[Bug c/36521] Expression in for expression gets wrong value
--- Comment #1 from peter at xmos dot com 2008-06-13 08:52 --- Created an attachment (id=15760) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15760action=view) test.i -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36521
[Bug tree-optimization/36519] [4.3 Regression] time/memory hog for c++ source.
--- Comment #2 from rguenth at gcc dot gnu dot org 2008-06-13 09:15 --- Confirmed. void es::ClockAnalyzer::initPrimitives() is the offending function - yet another testcase with a huge initialization sequence (we have problems there since long). This is probably caused by the fix for PR36339. In the mean time building with -O1 is fine (the branch has SFTs disabled there now), and the root of all evil is the fix for PR33870. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added OtherBugsDependingO||33870, 36339 nThis|| Status|UNCONFIRMED |NEW Component|other |tree-optimization Ever Confirmed|0 |1 Keywords||alias, compile-time-hog, ||memory-hog Last reconfirmed|-00-00 00:00:00 |2008-06-13 09:15:31 date|| Target Milestone|--- |4.3.2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36519
[Bug tree-optimization/36519] [4.3 Regression] time/memory hog for c++ source.
--- Comment #3 from rguenth at gcc dot gnu dot org 2008-06-13 09:27 --- Mine. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |rguenth at gcc dot gnu dot |dot org |org Status|NEW |ASSIGNED Last reconfirmed|2008-06-13 09:15:31 |2008-06-13 09:27:53 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36519
[Bug target/36135] GCC creates suboptimal ASM : suboptimal Adressing-Modes used
--- Comment #5 from gunnar at greyhound-data dot com 2008-06-13 09:31
---
(In reply to comment #4)
This comes down to IV-OPTs not understanding {post,pre}_{dec,inc} at all.
There is another bug about this somewhere I think for arm. PowerPC has the
same issue too ...
If this effects so many platforms this sounds like an important issue to me.
Maybe someone should increase the priority and severity of the issue in this
case?
Andrew, do you plan to fix this issue?
Cheers
Gunnar
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36135
[Bug fortran/36518] libgfortran: warning: format '%d' expects type 'int', but
--- Comment #1 from burnus at gcc dot gnu dot org 2008-06-13 09:36 --- Patch -- still untested. Index: m4/ifunction_logical.m4 === --- m4/ifunction_logical.m4 (Revision 136740) +++ m4/ifunction_logical.m4 (Arbeitskopie) @@ -121,7 +121,7 @@ name`'rtype_qual`_'atype_code (rtype * c if (extent[n] != ret_extent) runtime_error (Incorrect extent in return value of u_name intrinsic in dimension %d: - is %ld, should be %ld, n + 1, + is %ld, should be %ld, (int) n + 1, (long int) ret_extent, (long int) extent[n]); } } Index: configure.ac === --- configure.ac(Revision 136740) +++ configure.ac(Arbeitskopie) @@ -126,7 +126,7 @@ if test x$GCC = xyes; then AM_FCFLAGS=-I . -Wall -Werror -fimplicit-none -fno-repack-arrays -fno-underscoring ## We like to use C99 routines when available. This makes sure that ## __STDC_VERSION__ is set such that libc includes make them available. - AM_CFLAGS=-std=gnu99 -Wall -Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition -Wextra -Wwrite-strings + AM_CFLAGS=-std=gnu99 -Werror -Wall -Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition -Wextra -Wwrite-strings ## Compile the following tests with the same system header contents ## that we'll encounter when compiling our own source files. CFLAGS=-std=gnu99 $CFLAGS -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36518
[Bug c/36507] [4.3/4.4 Regression] ISO C99 inline semantics doesn't play together with nested functions
--- Comment #4 from jakub at gcc dot gnu dot org 2008-06-13 09:39 --- Subject: Bug 36507 Author: jakub Date: Fri Jun 13 09:38:31 2008 New Revision: 136745 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=136745 Log: PR c/36507 * c-decl.c (merge_decls): Don't clear DECL_EXTERNAL for nested inline functions. (start_decl, start_function): Don't invert DECL_EXTERNAL for nested inline functions. * gcc.dg/inline-28.c: New test. * gcc.dg/inline-29.c: New test. * gcc.dg/inline-30.c: New test. Added: trunk/gcc/testsuite/gcc.dg/inline-28.c trunk/gcc/testsuite/gcc.dg/inline-29.c trunk/gcc/testsuite/gcc.dg/inline-30.c Modified: trunk/gcc/ChangeLog trunk/gcc/c-decl.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36507
[Bug c/36507] [4.3/4.4 Regression] ISO C99 inline semantics doesn't play together with nested functions
--- Comment #5 from jakub at gcc dot gnu dot org 2008-06-13 09:41 --- Subject: Bug 36507 Author: jakub Date: Fri Jun 13 09:40:21 2008 New Revision: 136746 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=136746 Log: PR c/36507 * c-decl.c (merge_decls): Don't clear DECL_EXTERNAL for nested inline functions. (start_decl, start_function): Don't invert DECL_EXTERNAL for nested inline functions. * gcc.dg/inline-28.c: New test. * gcc.dg/inline-29.c: New test. * gcc.dg/inline-30.c: New test. Added: branches/gcc-4_3-branch/gcc/testsuite/gcc.dg/inline-28.c branches/gcc-4_3-branch/gcc/testsuite/gcc.dg/inline-29.c branches/gcc-4_3-branch/gcc/testsuite/gcc.dg/inline-30.c Modified: branches/gcc-4_3-branch/gcc/ChangeLog branches/gcc-4_3-branch/gcc/c-decl.c branches/gcc-4_3-branch/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36507
[Bug c/36507] [4.3/4.4 Regression] ISO C99 inline semantics doesn't play together with nested functions
--- Comment #6 from jakub at gcc dot gnu dot org 2008-06-13 09:54 --- Fixed. -- jakub at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36507
[Bug fortran/36517] Type-spec in array constructor: Invalid error for -std=f2003/f2008
--- Comment #1 from burnus at gcc dot gnu dot org 2008-06-13 09:54 --- Also occurs for -std=f2003 with print *, [ character(len=2) :: 'a', 'bb' ] - adjust bug summary -- burnus at gcc dot gnu dot org changed: What|Removed |Added Summary|Type-spec in array |Type-spec in array |constructor ignored for |constructor: Invalid error |PARAMETER |for -std=f2003/f2008 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36517
[Bug tree-optimization/36519] [4.3 Regression] time/memory hog for c++ source.
--- Comment #4 from rguenth at gcc dot gnu dot org 2008-06-13 10:02 --- Created an attachment (id=15761) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15761action=view) patch Patch. Wider testing appreciated. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36519
[Bug c++/36523] New: OpenMP task construct fails to instantiate copy constructor
The following test case fails with a linker error. It compiles okay with the
pragma omp task line removed.
templatetypename T
struct A
{
A() { }
A(const A) { }
void foo() { }
};
int main()
{
Aint a;
#pragma omp task
a.foo();
return 0;
}
g++- -fopenmp -Wall task_instantiation.cpp
/tmp/ccQDTSgc.o: In function `main.omp_cpyfn.1':
task_instantiation.cpp:(.text+0x7e): undefined reference to `Aint::A(Aint
const)'
collect2: ld returned 1 exit status
Workarounds:
-declare 'a' shared (mind data consistency)
-instantiate copy constructor explicitly
--
Summary: OpenMP task construct fails to instantiate copy
constructor
Product: gcc
Version: 4.4.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: singler at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36523
[Bug middle-end/36520] [4.4 Regression] ICE in get_memory_rtx
--- Comment #4 from ebotcazou at gcc dot gnu dot org 2008-06-13 10:21 --- Subject: Bug 36520 Author: ebotcazou Date: Fri Jun 13 10:20:57 2008 New Revision: 136747 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=136747 Log: PR middle-end/36520 * builtins.c (get_memory_rtx): Test for the presence of DECL_SIZE_UNIT before evaluating it. Added: trunk/gcc/testsuite/gcc.c-torture/compile/20080613-1.c Modified: trunk/gcc/ChangeLog trunk/gcc/builtins.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36520
[Bug middle-end/36520] [4.4 Regression] ICE in get_memory_rtx
--- Comment #5 from ebotcazou at gcc dot gnu dot org 2008-06-13 10:23 --- Thanks for the testcase. -- ebotcazou at gcc dot gnu dot org changed: What|Removed |Added URL||http://gcc.gnu.org/ml/gcc- ||patches/2008- ||06/msg00838.html Status|ASSIGNED|RESOLVED Resolution||FIXED Target Milestone|--- |4.4.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36520
[Bug tree-optimization/36524] New: regression: crash when compiling IdentifierTable.cpp
When I compile IdentifierTable.cpp from clang using gcc 4.3.1 I get a crash, compiling with gcc 4.2.4 doesn't crash. If I preprocess it first, and then compile it doesn't crash. If I move the the llvm-svn/llvm/include files to a different folder it doesn't crash. So I am not even able to provide an archive of .cpp and .h files to reproduce since it depends on folder names. I will rebuild g++ with debug symbols and see where it crashes. What --enable-checking setting should I use? Do you have any other suggestions how to get some files that I could submit that would reproduce the bug? $ /usr/bin/g++ -I/home/edwin/llvm-svn/llvm/include -I/home/edwin/llvm-svn/llvm/tools/clang/lib/Basic -D_DEBUG -I/home/edwin/llvm-svn/llvm/tools/clang/lib/Basic/../../include -D_GNU_SOURCE -D__STDC_LIMIT_MACROS IdentifierTable.cpp -o IdentifierTable.o -c -O1 In file included from IdentifierTable.cpp:161: /home/edwin/llvm-svn/llvm/tools/clang/lib/Basic/../../include/clang/Basic/TokenKinds.def:272: internal compiler error: Segmentation fault Please submit a full bug report, with preprocessed source if appropriate. See file:///usr/share/doc/gcc-4.3/README.Bugs for instructions. Valgrind shows: ==17940== Invalid write of size 1 ==17940==at 0x9B4D40: (within /usr/lib/gcc/x86_64-linux-gnu/4.3/cc1plus) ==17940==by 0x9B4FFF: (within /usr/lib/gcc/x86_64-linux-gnu/4.3/cc1plus) ==17940==by 0x4D1ACD: (within /usr/lib/gcc/x86_64-linux-gnu/4.3/cc1plus) ==17940==by 0x4570CF: (within /usr/lib/gcc/x86_64-linux-gnu/4.3/cc1plus) ==17940==by 0x469544: (within /usr/lib/gcc/x86_64-linux-gnu/4.3/cc1plus) ==17940==by 0x4D615C: (within /usr/lib/gcc/x86_64-linux-gnu/4.3/cc1plus) ==17940==by 0x68DFAA: (within /usr/lib/gcc/x86_64-linux-gnu/4.3/cc1plus) ==17940==by 0x4C4F1A5: (below main) (libc-start.c:222) ==17940== Address 0x227505b36fb6 is not stack'd, malloc'd or (recently) free'd $ g++ -v Using built-in specs. Target: x86_64-linux-gnu Configured with: ../src/configure -v --with-pkgversion='Debian 4.3.1-2' --with-bugurl=file:///usr/share/doc/gcc-4.3/README.Bugs --enable-languages=c,c++,fortran,objc,obj-c++ --prefix=/usr --enable-shared --with-system-zlib --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --enable-nls --with-gxx-include-dir=/usr/include/c++/4.3 --program-suffix=-4.3 --enable-clocale=gnu --enable-libstdcxx-debug --enable-objc-gc --enable-mpfr --enable-cld --enable-checking=release --build=x86_64-linux-gnu --host=x86_64-linux-gnu --target=x86_64-linux-gnu Thread model: posix gcc version 4.3.1 (Debian 4.3.1-2) Doesn't crash: $ /usr/bin/g++-4.2 -I/home/edwin/llvm-svn/llvm/include -I/home/edwin/llvm-svn/llvm/tools/clang/lib/Basic -D_DEBUG -I/home/edwin/llvm-svn/llvm/tools/clang/lib/Basic/../../include -D_GNU_SOURCE -D__STDC_LIMIT_MACROS IdentifierTable.cpp -o IdentifierTable.o -c -O1 $ g++-4.2 -v Using built-in specs. Target: x86_64-linux-gnu Configured with: ../src/configure -v --enable-languages=c,c++,fortran,objc,obj-c++ --prefix=/usr --enable-shared --with-system-zlib --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --enable-nls --with-gxx-include-dir=/usr/include/c++/4.2 --program-suffix=-4.2 --enable-clocale=gnu --enable-libstdcxx-debug --enable-objc-gc --enable-mpfr --enable-checking=release --build=x86_64-linux-gnu --host=x86_64-linux-gnu --target=x86_64-linux-gnu Thread model: posix gcc version 4.2.4 (Debian 4.2.4-2) I am unable to reproduce the crash if I first preprocess and then I compile, I tried: $ /usr/bin/g++ -v -I/home/edwin/llvm-svn/llvm/include -I/home/edwin/llvm-svn/llvm/tools/clang/lib/Basic -D_DEBUG -I/home/edwin/llvm-svn/llvm/tools/clang/lib/Basic/../../include -D_GNU_SOURCE -D__STDC_LIMIT_MACROS IdentifierTable.cpp -o IdentifierTable.o -c -O1 -save-temps Using built-in specs. Target: x86_64-linux-gnu Configured with: ../src/configure -v --with-pkgversion='Debian 4.3.1-2' --with-bugurl=file:///usr/share/doc/gcc-4.3/README.Bugs --enable-languages=c,c++,fortran,objc,obj-c++ --prefix=/usr --enable-shared --with-system-zlib --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --enable-nls --with-gxx-include-dir=/usr/include/c++/4.3 --program-suffix=-4.3 --enable-clocale=gnu --enable-libstdcxx-debug --enable-objc-gc --enable-mpfr --enable-cld --enable-checking=release --build=x86_64-linux-gnu --host=x86_64-linux-gnu --target=x86_64-linux-gnu Thread model: posix gcc version 4.3.1 (Debian 4.3.1-2) COLLECT_GCC_OPTIONS='-v' '-I/home/edwin/llvm-svn/llvm/include' '-I/home/edwin/llvm-svn/llvm/tools/clang/lib/Basic' '-D_DEBUG' '-I/home/edwin/llvm-svn/llvm/tools/clang/lib/Basic/../../include' '-D_GNU_SOURCE' '-D__STDC_LIMIT_MACROS' '-o' 'IdentifierTable.o' '-c' '-save-temps' '-O1' '-shared-libgcc' '-mtune=generic' /usr/lib/gcc/x86_64-linux-gnu/4.3.1/cc1plus -E -quiet -v -I/home/edwin/llvm-svn/llvm/include -I/home/edwin/llvm-svn/llvm/tools/clang/lib/Basic -I/home/edwin/llvm-svn/llvm/tools/clang/lib/Basic/../../include
[Bug tree-optimization/36524] regression: crash when compiling IdentifierTable.cpp
--- Comment #1 from rguenth at gcc dot gnu dot org 2008-06-13 11:24 --- -fpch-preprocess is probably one of the keys? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36524
[Bug c/36521] Expression in for expression gets wrong value
--- Comment #2 from rguenth at gcc dot gnu dot org 2008-06-13 11:28 --- Fixed in 4.1.0 -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Known to fail||3.4.6 4.0.4 Known to work||3.3.6 4.1.0 Resolution||FIXED Target Milestone|--- |4.1.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36521
[Bug tree-optimization/36524] regression: crash when compiling IdentifierTable.cpp
--- Comment #2 from edwintorok at gmail dot com 2008-06-13 11:34 --- (In reply to comment #1) -fpch-preprocess is probably one of the keys? Running cc1plus without -fpch-preprocess still leads to a crash. [EMAIL PROTECTED]:~/llvm-svn/llvm/tools/clang/lib/Basic$ /usr/lib/gcc/x86_64-linux-gnu/4.3.1/cc1plus -E -quiet -v -I/home/edwin/llvm-svn/llvm/include -I/home/edwin/llvm-svn/llvm/tools/clang/lib/Basic -I/home/edwin/llvm-svn/llvm/tools/clang/lib/Basic/../../include -MMD /home/edwin/llvm-svn/llvm/tools/clang/lib/Basic/Release/IdentifierTable.d -MF /home/edwin/llvm-svn/llvm/tools/clang/lib/Basic/Release/IdentifierTable.d.tmp -MP -MT /home/edwin/llvm-svn/llvm/tools/clang/lib/Basic/Release/IdentifierTable.lo -MT /home/edwin/llvm-svn/llvm/tools/clang/lib/Basic/Release/IdentifierTable.o -MT /home/edwin/llvm-svn/llvm/tools/clang/lib/Basic/Release/IdentifierTable.d -D_GNU_SOURCE -D_DEBUG -D_GNU_SOURCE -D__STDC_LIMIT_MACROS IdentifierTable.cpp -mtune=generic -Woverloaded-virtual -pedantic -Wall -W -Wwrite-strings -Wno-long-long -Wunused -Wno-unused-parameter -fomit-frame-pointer -fno-exceptions -fno-rtti -O1 -o IdentifierTable.ii ignoring nonexistent directory /usr/local/include/x86_64-linux-gnu ignoring nonexistent directory /usr/lib/gcc/x86_64-linux-gnu/4.3.1/../../../../x86_64-linux-gnu/include ignoring nonexistent directory /usr/include/x86_64-linux-gnu #include ... search starts here: #include ... search starts here: /home/edwin/llvm-svn/llvm/include /home/edwin/llvm-svn/llvm/tools/clang/lib/Basic /home/edwin/llvm-svn/llvm/tools/clang/lib/Basic/../../include /usr/include/c++/4.3 /usr/include/c++/4.3/x86_64-linux-gnu /usr/include/c++/4.3/backward /usr/local/include /usr/lib/gcc/x86_64-linux-gnu/4.3.1/include /usr/lib/gcc/x86_64-linux-gnu/4.3.1/include-fixed /usr/include End of search list. In file included from built-in:0: built-in:0: internal compiler error: Segmentation fault Please submit a full bug report, with preprocessed source if appropriate. See file:///usr/share/doc/gcc-4.3/README.Bugs for instructions. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36524
[Bug tree-optimization/36524] regression: crash when compiling IdentifierTable.cpp
--- Comment #3 from rguenth at gcc dot gnu dot org 2008-06-13 11:45 --- Can you delete the preprocessed libstdc++ includes from /usr/lib? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36524
[Bug tree-optimization/36524] regression: crash when compiling IdentifierTable.cpp
--- Comment #4 from edwintorok at gmail dot com 2008-06-13 12:01 --- (In reply to comment #3) Can you delete the preprocessed libstdc++ includes from /usr/lib? Sure, I only had these: $ find /usr/lib/ /usr/local/lib -name *.gch /usr/lib/gcc/i586-mingw32msvc/4.2.1-sjlj/include/c++/i586-mingw32msvc/bits/stdtr1c++.h.gch /usr/lib/gcc/i586-mingw32msvc/4.2.1-sjlj/include/c++/i586-mingw32msvc/bits/stdtr1c++.h.gch/O2g.gch /usr/lib/gcc/i586-mingw32msvc/4.2.1-sjlj/include/c++/i586-mingw32msvc/bits/stdc++.h.gch /usr/lib/gcc/i586-mingw32msvc/4.2.1-sjlj/include/c++/i586-mingw32msvc/bits/stdc++.h.gch/O0g.gch /usr/lib/gcc/i586-mingw32msvc/4.2.1-sjlj/include/c++/i586-mingw32msvc/bits/stdc++.h.gch/O2g.gch I deleted them, however I am still getting teh crash. Meanwhile, I am building gcc 4.3.1 from sources, with: --enable-checking=all --disable-bootstrap --disable-multilib --enable-languages=c,c++ -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36524
[Bug target/36525] New: prologue code may give invalid stack back chain
The SPU ABI states: The first word of the stack frame must always point to the previously allocated stack frame (toward higher addresses), except for the first stack frame, which must have a back chain pointer of 0 (NULL). SPU doesn't have a single instruction that can both write the back chain and adjust the stack pointer, so keeping the above invariant in the presence of interrupts is a little tricky. For frames smaller than 2000 bytes, spu_expand_prologue first writes the back chain word, then adjusts the stack. This is fine since we have a 2000 byte red zone. For frames larger than 2000 bytes, the stack is decremented first, then the back chain word is written. This opens a small window where an interrupt can occur with an uninitialized back chain. If the interrupt handler walks stack frames for some reason, it will see a broken frame. Tools like oprofile are known to have such handlers. A possible solution is to ensure that the back chain write and the stack adjust insns are always in the same dispatch pair. -- Summary: prologue code may give invalid stack back chain Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: target AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: amodra at bigpond dot net dot au GCC target triplet: spu-elf http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36525
[Bug fortran/36526] New: pointer in pure function
Hi, I discovered a problem with gfortran 4.3.1 when compiling code with pure function with pointer argument. Inside the pure function, the argument is passed further to an other function. This seems to work, as long this other function is an intrinsic function, but seems to fail for user defined pure functions. The effect is demonstrated by the code below. Best regards, Bálint module TestPure implicit none type T1 character(10) :: str end type T1 contains pure function getT1Len(self) result(t1len) type(T1), pointer :: self integer :: t1len t1len = getStrLen(self%str) !t1len = len_trim(self%str) ! - this would work end function getT1Len pure function getStrLen(str) result(length) character(*), intent(in) :: str integer :: length length = len_trim(str) end function getStrLen end module TestPure program Test use TestPure implicit none type(T1), pointer :: pT1 allocate(pT1) pT1%str = test write (*,*) getT1Len(pT1) deallocate(pT1) end program Test -- -- Summary: pointer in pure function Product: gcc Version: 4.3.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: aradi at bccms dot uni-bremen dot de GCC target triplet: x86_64-unknown-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36526
[Bug target/36527] New: gcc 4.2.x generates wrong code for ARM target
We have encountered what seems to be a gcc bug in the attempt to upgrade our toolchain (using buildroot, embedded ARM no-MMU CPU) from 3.4.6 to 4.2.x. The bug has been seen on both 4.2.3 and 4.2.4. We have not yet been able to build a toolchain based on gcc 4.3.1. Most of our +5 MB system runs fine, but some strange problems we had boiled down to the attached test programs which essentially deals with passing some int parms and a struct through two function calls. The test code fails when executed on the ARM target. It works on x86 using gcc 4.2.3 and also on a MIPS platform using gcc 4.2.1. The test code only fails with -O2. Compiled using: [EMAIL PROTECTED]:~/src/kuss/tmp$ /home/bla/src/kuss/bs/toolchain/linux24/usr/bin/arm-elf-gcc -save-temps -c -Wall -Werror -O2 -g -Wa,-W -o .o/arm4/test.o test.c [EMAIL PROTECTED]:~/src/kuss/tmp$ /home/bla/src/kuss/bs/toolchain/linux24/usr/bin/arm-elf-g++ -save-temps -c -Wall -Werror -O2 -g -Wa,-W -o .o/arm4/testcpp.o testcpp.cpp Output from the C test run on target: :/ /bin/test ### C test: Values before test: 1 2 3 4 ### FAILS: 0x0001 0x0002 0x0004 0x0004 ### OK Output from the C++ test run on target: :/ /bin/testcpp ### C++ test: Values before test: 1 2 3 4 ### FAILS: 0x0001 0x0002 0x0004 0x0004 ### OK [EMAIL PROTECTED]:~/src/kuss/tmp$ ../bs/toolchain/linux24/usr/bin/arm-elf-gcc -v Using built-in specs. Target: arm-linux-uclibc Configured with: /home/bla/src/kuss/opensrc/gpl/toolchains/arm-gcc4/toolchain_build_arm/gcc-4.2.4/configure --prefix=/usr --build=i386-pc-linux-gnu --host=i386-pc-linux-gnu --target=arm-linux-uclibc --enable-languages=c,c++ --with-sysroot=/home/bla/src/kuss/bs/toolchain/linux24 --with-build-time-tools=/home/bla/src/kuss/bs/toolchain/linux24/usr/arm-linux-uclibc/bin --disable-__cxa_atexit --enable-target-optspace --with-gnu-ld --disable-libgomp --disable-libmudflap --disable-shared --with-gmp=/home/bla/src/kuss/opensrc/gpl/toolchains/arm-gcc4/toolchain_build_arm/gmp --with-mpfr=/home/bla/src/kuss/opensrc/gpl/toolchains/arm-gcc4/toolchain_build_arm/mpfr --disable-nls --enable-threads --disable-multilib --with-float=soft --with-arch=armv4 --with-tune=arm7tdmi Thread model: posix gcc version 4.2.4 -- Summary: gcc 4.2.x generates wrong code for ARM target Product: gcc Version: 4.2.4 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: benny at ammitzboell-consult dot dk GCC build triplet: i386-pc-linux-gnu GCC host triplet: i386-pc-linux-gnu GCC target triplet: arm-linux-uclibc http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36527
[Bug target/36527] gcc 4.2.x generates wrong code for ARM target
--- Comment #1 from benny at ammitzboell-consult dot dk 2008-06-13 12:59 --- Created an attachment (id=15762) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15762action=view) C test program -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36527
[Bug target/36527] gcc 4.2.x generates wrong code for ARM target
--- Comment #2 from benny at ammitzboell-consult dot dk 2008-06-13 13:00 --- Created an attachment (id=15763) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15763action=view) C++ test program -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36527
[Bug target/36527] gcc 4.2.x generates wrong code for ARM target
--- Comment #3 from benny at ammitzboell-consult dot dk 2008-06-13 13:00 --- Created an attachment (id=15764) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15764action=view) test.i -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36527
[Bug target/36527] gcc 4.2.x generates wrong code for ARM target
--- Comment #4 from benny at ammitzboell-consult dot dk 2008-06-13 13:01 --- Created an attachment (id=15765) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15765action=view) test.s -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36527
[Bug target/36527] gcc 4.2.x generates wrong code for ARM target
--- Comment #5 from benny at ammitzboell-consult dot dk 2008-06-13 13:01 --- Created an attachment (id=15766) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15766action=view) testcpp.ii -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36527
[Bug target/36527] gcc 4.2.x generates wrong code for ARM target
--- Comment #6 from benny at ammitzboell-consult dot dk 2008-06-13 13:01 --- Created an attachment (id=15767) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15767action=view) testcpp.s -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36527
[Bug fortran/36476] ICE: len=* CHARACTER array with separate PARAMETER statement
--- Comment #5 from burnus at gcc dot gnu dot org 2008-06-13 13:05 --- Subject: Bug 36476 Author: burnus Date: Fri Jun 13 13:04:26 2008 New Revision: 136754 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=136754 Log: 2008-06-13 Tobias Burnus [EMAIL PROTECTED] PR fortran/36476 * decl.c (do_parm): Handle init expression for len=*. 2008-06-13 Tobias Burnus [EMAIL PROTECTED] PR fortran/36476 * gfortran.dg/parameter_array_init_4.f90: New. Added: trunk/gcc/testsuite/gfortran.dg/parameter_array_init_4.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/decl.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36476
[Bug fortran/36476] ICE: len=* CHARACTER array with separate PARAMETER statement
--- Comment #6 from burnus at gcc dot gnu dot org 2008-06-13 13:14 --- FIXED on the trunk (4.4.0). Thanks for the report. -- burnus at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36476
[Bug c++/36523] OpenMP task construct fails to instantiate copy constructor
-- 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 Last reconfirmed|-00-00 00:00:00 |2008-06-13 13:29:33 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36523
[Bug fortran/36517] Type-spec in array constructor: Invalid error for -std=f2003/f2008
--- Comment #2 from burnus at gcc dot gnu dot org 2008-06-13 13:30 --- Daniel, as you have implemented the constructor with type spec, maybe you have an idea how to fix this best. The error message is generated in decl.c's gfc_set_constant_character_len. The problem is that for -std=f2003 the same error is generated as if no type-spec were present; gfc_set_constant_character_len is called at three places (with argument array=true). I believe we forgot to test character string when implementing it - and characters are always special due to the LENGTH type parameter. (The length-type parameter of derived types will also be fun, but it will probably not be implemented soon.) -- burnus at gcc dot gnu dot org changed: What|Removed |Added CC||d at domob dot eu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36517
[Bug target/36135] GCC creates suboptimal ASM : suboptimal Adressing-Modes used
--- Comment #6 from gunnar at greyhound-data dot com 2008-06-13 13:34
---
(In reply to comment #4)
This comes down to IV-OPTs not understanding {post,pre}_{dec,inc} at all.
There is another bug about this somewhere I think for arm. PowerPC has the
same issue too ...
Hi Andrew,
I want to make clear that the 68K backend used to be able to do this
optimization in the GCC 2.9 times. Later with 3.4 or 4.x this optmization did
not work anymore and the code became worth.
Does this make sense in your opinion?
Cheers
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36135
[Bug tree-optimization/36524] regression: crash when compiling IdentifierTable.cpp
--- Comment #5 from edwintorok at gmail dot com 2008-06-13 13:37 ---
I have built with --enable-checking=yes (instead of all), because all was
taking too long.
It looks like a value of a pointer is invalid.
See the gdb session below.
What should I do next to help debug the problem?
Starting program: /usr/local/libexec/gcc/x86_64-unknown-linux-gnu/4.3.1/cc1plus
-E -quiet -v -I/home/edwin/llvm-svn/llvm/include
-I/home/edwin/llvm-svn/llvm/tools/clang/lib/Basic
-I/home/edwin/llvm-svn/llvm/tools/clang/lib/Basic/../../include -MMD I.d -MF
/home/edwin/llvm-svn/llvm/tools/clang/lib/Basic/Release/IdentifierTable.d.tmp
-MP -MT /home/edwin/ll
vm-svn/llvm/tools/clang/lib/Basic/Release/IdentifierTable.lo -MT
/home/edwin/llvm-svn/llvm/tools/clang/lib/Basic/Release/IdentifierTable.o -MT
/home/edwin/llvm-svn/llvm/tools/cla
ng/lib/Basic/Release/IdentifierTable.d -D_GNU_SOURCE -D_DEBUG -D_GNU_SOURCE
-D__STDC_LIMIT_MACROS IdentifierTable.cpp -o I.ii -mtune=generic
-Woverloaded-virtual -pedantic -Wall
-W -Wwrite-strings -Wno-long-long -Wunused -Wno-unused-parameter -Winvalid-pch
-fomit-frame-pointer -fno-exceptions -fno-rtti -O1
ignoring nonexistent directory
/usr/local/lib/gcc/x86_64-unknown-linux-gnu/4.3.1/../../../../x86_64-unknown-linux-gnu/include
#include ... search starts here:
#include ... search starts here:
/home/edwin/llvm-svn/llvm/include
/home/edwin/llvm-svn/llvm/tools/clang/lib/Basic
/home/edwin/llvm-svn/llvm/tools/clang/lib/Basic/../../include
/usr/local/lib/gcc/x86_64-unknown-linux-gnu/4.3.1/../../../../include/c++/4.3.1
/usr/local/lib/gcc/x86_64-unknown-linux-gnu/4.3.1/../../../../include/c++/4.3.1/x86_64-unknown-linux-gnu
/usr/local/lib/gcc/x86_64-unknown-linux-gnu/4.3.1/../../../../include/c++/4.3.1/backward
/usr/local/include
/usr/local/lib/gcc/x86_64-unknown-linux-gnu/4.3.1/include
/usr/local/lib/gcc/x86_64-unknown-linux-gnu/4.3.1/include-fixed
/usr/include
End of search list.
Program received signal SIGSEGV, Segmentation fault.
0x00c111d3 in new_string_token (pfile=0x2ae4280, text=0x22745f323372
Address 0x22745f323372 out of bounds, len=2743223540) at
../../gcc-4.3.1/libcpp/macro.c:100
(gdb) bt
#0 0x00c111d3 in new_string_token (pfile=0x2ae4280,
text=0x22745f323372 Address 0x22745f323372 out of bounds, len=2743223540) at
../../gcc-4.3.1/libcpp/macro.c:100
#1 0x00c11cbb in stringify_arg (pfile=0x2ae4280, arg=0x2b439a0) at
../../gcc-4.3.1/libcpp/macro.c:434
#2 0x00c12a61 in replace_args (pfile=0x2ae4280, node=0x7f8657b614a0,
macro=0x7f8657a15140, args=0x2b439a0) at ../../gcc-4.3.1/libcpp/macro.c:921
#3 0x00c12888 in enter_macro_context (pfile=0x2ae4280,
node=0x7f8657b614a0, result=0x2ae4710) at ../../gcc-4.3.1/libcpp/macro.c:850
#4 0x00c133e7 in cpp_get_token (pfile=0x2ae4280) at
../../gcc-4.3.1/libcpp/macro.c:1234
#5 0x005a4a28 in preprocess_file (pfile=0x2ae4280) at
../../gcc-4.3.1/gcc/c-ppoutput.c:148
#6 0x005a08a9 in c_common_init () at ../../gcc-4.3.1/gcc/c-opts.c:1244
#7 0x004bf843 in cxx_init () at ../../gcc-4.3.1/gcc/cp/lex.c:421
#8 0x00807698 in toplev_main (argc=value optimized out, argv=value
optimized out) at ../../gcc-4.3.1/gcc/toplev.c:2123
#9 0x003cbb81e1a6 in __libc_start_main () from /lib/libc.so.6
#10 0x00404269 in _start ()
(gdb) p text
$1 = (unsigned char *) 0x22745f323372 Address 0x22745f323372 out of bounds
(gdb) p len
$2 = 2743223540
(gdb) up
(gdb) p dest
$3 = (unsigned char *) 0x2b47866
(gdb) p len
$4 = 18446706190546257140
looks like a negative number to me
(gdb) p pfile-u_buff
$5 = (_cpp_buff *) 0x2b47850
432 len = dest - BUFF_FRONT (pfile-u_buff);
433 BUFF_FRONT (pfile-u_buff) = dest + 1;
434 return new_string_token (pfile, dest - len, len);
(gdb) display arg-first[0]
(gdb) b 433
Breakpoint 6 at 0xc11c8a: file ../../gcc-4.3.1/libcpp/macro.c, line 433.
(gdb) cond 6 len10
(gdb) r
...
Breakpoint 6, stringify_arg (pfile=0x2a0f280, arg=0x2a6e9a0) at
../../gcc-4.3.1/libcpp/macro.c:433
1: *arg-first[0] = {src_loc = 9522344, type = CPP_NAME, flags = 0 '\0', val =
{node = 0x7f472c117020, source = 0x7f472c117020, str = {len = 739340320, text =
0x2a72512 \clang/
Basic/TokenKinds.def\}, arg_no = 739340320, pragma = 739340320}}
(gdb) p pfile-u_buff-cur
$30 = (unsigned char *) 0x22745f323372 Address 0x22745f323372 out of bounds
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36524
[Bug fortran/36528] New: Cray pointer to function mishandled
http://groups.google.com/group/comp.lang.fortran/msg/86b65bad78e6af78 The following program should compile (with -fcray-pointer) and print on run time: integral f(x) u intervalu [0,1] = 0.49975004 integral f(x) u intervalu [0,1] = 0.49975004 sunf95 handles this correctly, however, gfortran fails at link time: undefined reference to `fcn_' pointer (pfcn, fcn) pfcn = loc(p1) ! p1 is a function interface y = y + fcn(x)*dx ! Directly calling p1 y = euler(0.0,1.0,0.0005,fcn) The dump shows: integer(kind=8) pfcn; D.1063 = (integer(kind=8)) p1; pfcn = D.1063; y = Unknown tree: call_expr 4 (real(kind=4) (*T2ef) (real(kind=4) )) pfcn x (x) * dx +y y = euler (C.1072, C.1073, C.1074, fcn); Full source code, see link. I think the test was created/tested for ifort and gives there an ICE. -- Summary: Cray pointer to function mishandled Product: gcc Version: 4.4.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 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36528
[Bug target/36135] GCC creates suboptimal ASM : suboptimal Adressing-Modes used
--- Comment #7 from pinskia at gcc dot gnu dot org 2008-06-13 14:34 --- Andrew, do you plan to fix this issue? Personally no. Mostly because IV-opts is hard to understand. Also it is not the m68k back-end doing the optimization rather loop.c did it. See PR 31849. *** This bug has been marked as a duplicate of 31849 *** -- 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=36135
[Bug tree-optimization/31849] [4.3/4.4 Regression] Code size increased with PR 31360 (IV-opts not understanding autoincrement)
--- Comment #37 from pinskia at gcc dot gnu dot org 2008-06-13 14:34 --- *** Bug 36135 has been marked as a duplicate of this bug. *** -- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||gunnar at greyhound-data dot ||com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31849
[Bug c++/36529] New: -fsee causes ICE
Adding -fsee to the compile line causes ICE on a valid file which compiled fine without -fsee. -- Summary: -fsee causes ICE Product: gcc Version: 4.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: william dot l dot maynard at nasa dot gov GCC target triplet: G5-apple-darwin-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36529
[Bug c++/36529] -fsee causes ICE
--- Comment #1 from william dot l dot maynard at nasa dot gov 2008-06-13 15:29 --- Created an attachment (id=15768) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15768action=view) file from the compile which produced ICE -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36529
[Bug c++/36529] -fsee causes ICE
--- Comment #2 from william dot l dot maynard at nasa dot gov 2008-06-13 15:35 --- Created an attachment (id=15769) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15769action=view) GNU c++ compiler make command and error output -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36529
[Bug preprocessor/36479] Short buffer in libcpp
-- tromey at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|--- |4.4.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36479
[Bug libstdc++/36530] New: ptrdiff_t undefined if stddef.h is included after wchar.h and wctype.h
If stddef.h is included after wchar.h and wctype.h, the following error
occurs:
$ cat test.cpp g++ -c test.cpp
#include wchar.h
#include wctype.h
#include stddef.h
using namespace std;
ptrdiff_t ptr = 0;
test.cpp:9: error: ptrdiff_t does not name a type
Workaround: replace order of included files.
$ uname -a
Linux farid-ubuntu 2.6.24-18-generic #1 SMP Wed May 28 19:28:38 UTC 2008 x86_64
GNU/Linux
$ g++ -v
Using built-in specs.
Target: x86_64-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
--with-gxx-include-dir=/usr/include/c++/4.2 --program-suffix=-4.2
--enable-clocale=gnu --enable-libstdcxx-debug --enable-objc-gc --enable-mpfr
--enable-checking=release --build=x86_64-linux-gnu --host=x86_64-linux-gnu
--target=x86_64-linux-gnu
Thread model: posix
gcc version 4.2.3 (Ubuntu 4.2.3-2ubuntu7)
Preprocessed output:
# 1 test.cpp
# 1 built-in
# 1 command-line
# 1 test.cpp
# 1 /usr/include/wchar.h 1 3 4
# 28 /usr/include/wchar.h 3 4
# 1 /usr/include/features.h 1 3 4
# 330 /usr/include/features.h 3 4
# 1 /usr/include/sys/cdefs.h 1 3 4
# 348 /usr/include/sys/cdefs.h 3 4
# 1 /usr/include/bits/wordsize.h 1 3 4
# 349 /usr/include/sys/cdefs.h 2 3 4
# 331 /usr/include/features.h 2 3 4
# 354 /usr/include/features.h 3 4
# 1 /usr/include/gnu/stubs.h 1 3 4
# 1 /usr/include/bits/wordsize.h 1 3 4
# 5 /usr/include/gnu/stubs.h 2 3 4
# 1 /usr/include/gnu/stubs-64.h 1 3 4
# 10 /usr/include/gnu/stubs.h 2 3 4
# 355 /usr/include/features.h 2 3 4
# 29 /usr/include/wchar.h 2 3 4
# 37 /usr/include/wchar.h 3 4
# 1 /usr/include/stdio.h 1 3 4
# 45 /usr/include/stdio.h 3 4
struct _IO_FILE;
typedef struct _IO_FILE FILE;
# 65 /usr/include/stdio.h 3 4
typedef struct _IO_FILE __FILE;
# 38 /usr/include/wchar.h 2 3 4
# 1 /usr/lib/gcc/x86_64-linux-gnu/4.3.0/include/stdarg.h 1 3 4
# 43 /usr/lib/gcc/x86_64-linux-gnu/4.3.0/include/stdarg.h 3 4
typedef __builtin_va_list __gnuc_va_list;
# 41 /usr/include/wchar.h 2 3 4
# 1 /usr/include/bits/wchar.h 1 3 4
# 43 /usr/include/wchar.h 2 3 4
# 52 /usr/include/wchar.h 3 4
# 1 /usr/lib/gcc/x86_64-linux-gnu/4.3.0/include/stddef.h 1 3 4
# 214 /usr/lib/gcc/x86_64-linux-gnu/4.3.0/include/stddef.h 3 4
typedef long unsigned int size_t;
# 355 /usr/lib/gcc/x86_64-linux-gnu/4.3.0/include/stddef.h 3 4
typedef unsigned int wint_t;
# 53 /usr/include/wchar.h 2 3 4
# 78 /usr/include/wchar.h 3 4
typedef struct
{
int __count;
union
{
unsigned int __wch;
char __wchb[4];
} __value;
} __mbstate_t;
# 99 /usr/include/wchar.h 3 4
typedef __mbstate_t mbstate_t;
# 124 /usr/include/wchar.h 3 4
extern C {
struct tm;
extern wchar_t *wcscpy (wchar_t *__restrict __dest,
__const wchar_t *__restrict __src) throw ();
extern wchar_t *wcsncpy (wchar_t *__restrict __dest,
__const wchar_t *__restrict __src, size_t __n)
throw ();
extern wchar_t *wcscat (wchar_t *__restrict __dest,
__const wchar_t *__restrict __src) throw ();
extern wchar_t *wcsncat (wchar_t *__restrict __dest,
__const wchar_t *__restrict __src, size_t __n)
throw ();
extern int wcscmp (__const wchar_t *__s1, __const wchar_t *__s2)
throw () __attribute__ ((__pure__));
extern int wcsncmp (__const wchar_t *__s1, __const wchar_t *__s2, size_t __n)
throw () __attribute__ ((__pure__));
extern int wcscasecmp (__const wchar_t *__s1, __const wchar_t *__s2) throw ();
extern int wcsncasecmp (__const wchar_t *__s1, __const wchar_t *__s2,
size_t __n) throw ();
# 1 /usr/include/xlocale.h 1 3 4
# 28 /usr/include/xlocale.h 3 4
typedef struct __locale_struct
{
struct locale_data *__locales[13];
const unsigned short int *__ctype_b;
const int *__ctype_tolower;
const int *__ctype_toupper;
const char *__names[13];
} *__locale_t;
# 173 /usr/include/wchar.h 2 3 4
extern int wcscasecmp_l (__const wchar_t *__s1, __const wchar_t *__s2,
__locale_t __loc) throw ();
extern int wcsncasecmp_l (__const wchar_t *__s1, __const wchar_t *__s2,
size_t __n, __locale_t __loc) throw ();
extern int wcscoll (__const wchar_t *__s1, __const wchar_t *__s2) throw ();
extern size_t wcsxfrm (wchar_t *__restrict __s1,
__const wchar_t *__restrict __s2, size_t __n) throw ();
extern int wcscoll_l (__const wchar_t *__s1, __const wchar_t *__s2,
__locale_t __loc) throw ();
extern size_t wcsxfrm_l (wchar_t *__s1, __const wchar_t *__s2,
size_t __n, __locale_t __loc) throw ();
extern wchar_t *wcsdup (__const wchar_t *__s) throw () __attribute__
((__malloc__));
extern wchar_t *wcschr (__const wchar_t *__wcs, wchar_t __wc)
throw () __attribute__ ((__pure__));
extern wchar_t *wcsrchr (__const wchar_t *__wcs, wchar_t
[Bug fortran/36528] Cray pointer to function mishandled
--- Comment #1 from burnus at gcc dot gnu dot org 2008-06-13 16:54 --- For gfortran documentation, see: http://gcc.gnu.org/onlinedocs/gfortran/Cray-pointers.html#Cray-pointers a) If used directly, the tree is wrong (see dump), but it works nonetheless (I somehow have not to realize this) b) If used as actual argument, it is completely mishandled. Without explicit interface, it should be: myfunc( (void)(*T4)(void) pointee) (i.e. build_pointer_type (build_function_type (void_type_node, NULL_TREE))) and with an explicit interface, it should convert pointee to the tree TYPE of the dummy argument.) c) TODO: Check whether using the pointee as non-procedure actual argument works (incl. VALUE attribute and similar things; it probably works.) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36528
[Bug fortran/36517] Type-spec in array constructor: Invalid error for -std=f2003/f2008
--- Comment #3 from d at domob dot eu 2008-06-13 17:04 --- Confirmed. I'll try to get this fixed! Might be funny, as I can't yet think of any reason why -std= should affect such a behaviour... But I also haven't looked at the code for this one deeper, so hopefully I'll find out soon! -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36517
[Bug c/36531] New: -Wno-packed appears to be disconnected/ignored
With the -Wno-packed switch used, I'm still getting message like warning: 'packed' attribute ignored for field of type 'foo'. I see it associated with members of structs, but I haven't researched if it is associated with non-struct stand alone variables. -- Summary: -Wno-packed appears to be disconnected/ignored Product: gcc Version: 4.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: jmorrison at printronix dot com GCC target triplet: powerpc-eabi http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36531
[Bug c/36531] -Wno-packed appears to be disconnected/ignored
--- Comment #1 from jmorrison at printronix dot com 2008-06-13 17:21 --- Here is the configure info: Configured with: /home/morr_jo/work/ToolChain/cross/src/gcc-4.2.0/configure --target=powerpc-eabi --prefix=/opt/lnxshare/gcc.ppc-4.2.0 --enable-languages=c,c++ --with-gnu-as --with-gnu-ld --with-newlib --with-gxx-include-dir=/opt/lnxshare/gcc.ppc-4.2.0/powerpc-eabi/include -v Edited (removed propritary stuff) command line: /opt/lnxshare/gcc.ppc-4.2.0/powerpc-eabi/bin/gcc -v -c -Wall -mcpu=603 -g -c -mstrict-align -Wall -Wno-format -Wno-pointer-sign -Wno-packed -O0 -nostdinc -DRW_MULTI_THREAD -D_REENTRANT -fno-builtin -fno-for-scope -I include/paths -D OUT_FLAGS pgmpath/path/pgm.c -o pgm.o 2 /err/pgm.err -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36531
[Bug fortran/36526] pointer in pure function
--- Comment #1 from burnus at gcc dot gnu dot org 2008-06-13 17:52 --- CONFIRM. Works with other compilers. The constraint checked for is: C1272 In a pure subprogram any designator with a base object that is in common or accessed by host or use association, is a dummy argument of a pure function, is a dummy argument with INTENT (IN) of a pure subroutine, or an object that is storage associated with any such variable, shall not be used in the following contexts: [...] (5) As an actual argument associated with a dummy argument with INTENT (OUT) or INTENT (INOUT) or with the POINTER attribute. (From F2003.) At a glance, it seems as if this applies, but as the non-normative note indicates, C1272 does not apply in this case: NOTE 12.45 Pure subroutines are included to allow subroutine calls from pure procedures in a safe way [...] The constraints for pure subroutines are based on the same principles as for pure functions, except that side effects to INTENT (OUT), INTENT (INOUT), and pointer dummy arguments are permitted. However, I failed to find this in the normative part; I will try a bit more to figure out why C1272 does not apply. -- burnus at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Keywords||rejects-valid Last reconfirmed|-00-00 00:00:00 |2008-06-13 17:52:34 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36526
[Bug fortran/36517] Type-spec in array constructor: Invalid error for -std=f2003/f2008
--- Comment #4 from d at domob dot eu 2008-06-13 17:53 --- Created an attachment (id=15770) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15770action=view) Probably obvious fix. Attached a simple fix by disabling this error if we are inside an array-constructor with typespec; the two tests above are included in the patch and work now. Regression-testing is just running, but I don't expect any errors there. If it succeeds, I'll submit the patch to gcc-patches. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36517
[Bug fortran/36492] incorrect error when compiling
--- Comment #4 from burnus at gcc dot gnu dot org 2008-06-13 18:10 --- OK, I can reproduce it now. Workaround: Replacing -std=f2003 by -std=gnu. First program, causes an ICE. g95 prints Error: Symbol 'max_fld_hed' at (1) has no IMPLICIT type -- MODULE WinData IMPLICIT NONE INTEGER (1), PARAMETER :: MAXFLD = 25_1, MAXHED = 5_1, MAXCHR = 80_1 integer :: i TYPE TWindowData CHARACTER (MAX_FLD_HED, 1) :: DWFdHd(MAXFLD) = [( , i = 1, MAXFLD)] END TYPE TWindowData END MODULE WinData -- Reduced test case - compile with -std=f2003 -- INTEGER, PARAMETER :: len = 40 type t character (len, 1) :: DWFdHd(1) = [( , i = 1, 1)] end type t end -- Error: The CHARACTER elements of the array constructor at (1) must have the same length (1/40) -- burnus at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Keywords||diagnostic, ice-on-invalid- ||code Last reconfirmed|-00-00 00:00:00 |2008-06-13 18:10:46 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36492
[Bug libgomp/36469] bootstrap broken on HPUX PA
--- Comment #2 from andreast at gcc dot gnu dot org 2008-06-13 18:29 --- Fixed. Thanks. -- andreast at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED Target Milestone|--- |4.4.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36469
[Bug fortran/36518] libgfortran: warning: format '%d' expects type 'int', but
--- Comment #2 from burnus at gcc dot gnu dot org 2008-06-13 18:44 --- Subject: Bug 36518 Author: burnus Date: Fri Jun 13 18:43:25 2008 New Revision: 136761 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=136761 Log: 2008-06-13 Tobias Burnus [EMAIL PROTECTED] PR libgfortran/36518 * configure.ac (AM_CFLAGS): Add -Werror. * configure: Regenerate. * m4/ifunction_logical.m4: Cast n to (int). * generated/any_l16.c: Regenerate. * generated/any_l2.c: Regenerate. * generated/all_l1.c: Regenerate. * generated/all_l2.c: Regenerate. * generated/all_l16.c: Regenerate. * generated/any_l4.c: Regenerate. * generated/count_4_l.c: Regenerate. * generated/count_8_l.c: Regenerate. * generated/all_l4.c: Regenerate. * generated/count_1_l.c: Regenerate. * generated/count_16_l.c: Regenerate. * generated/any_l8.c: Regenerate. * generated/count_2_l.c: Regenerate. * generated/any_l1.c: Regenerate. * generated/all_l8.c: Regenerate. Modified: trunk/libgfortran/configure trunk/libgfortran/configure.ac trunk/libgfortran/generated/all_l1.c trunk/libgfortran/generated/all_l16.c trunk/libgfortran/generated/all_l2.c trunk/libgfortran/generated/all_l4.c trunk/libgfortran/generated/all_l8.c trunk/libgfortran/generated/any_l1.c trunk/libgfortran/generated/any_l16.c trunk/libgfortran/generated/any_l2.c trunk/libgfortran/generated/any_l4.c trunk/libgfortran/generated/any_l8.c trunk/libgfortran/generated/count_16_l.c trunk/libgfortran/generated/count_1_l.c trunk/libgfortran/generated/count_2_l.c trunk/libgfortran/generated/count_4_l.c trunk/libgfortran/generated/count_8_l.c trunk/libgfortran/m4/ifunction_logical.m4 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36518
[Bug c/36532] New: ICE in simplify_subreg at simplify-rtx.c:4484
int main() {
*c = 'x';
}
Compiling the above with just 'gcc asdf.c':
asdf.c: In function âmainâ:
asdf.c:2: internal compiler error: in simplify_subreg, at simplify-rtx.c:4484
I've duplicated this on both Windows and Linux, respective 'gcc -v' outputs are
as follows:
--
Using built-in specs.
Target: i686-pc-mingw32
Configured with: ../src/configure --prefix=c:/temp/gcc/dest
--enable-languages=c,c++ --enable-thread
s --disable-nls --disable-win32-registry --disable-sjlj-exceptions
--with-arch=i486 --with-tune=gene
ric --enable-cxx-flags=-fno-function-sections -fno-data-sections
--disable-libstdcxx-pch --disable-s
hared --enable-checking=release --disable-bootstrap
Thread model: win32
gcc version 4.2.1-dw2 (mingw32-2)
--
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
--with-gxx-include-dir=/usr/include/c++/4.2 --program-suffix=-4.2
--enable-clocale=gnu --enable-libstdcxx-debug --enable-objc-gc --enable-mpfr
--enable-targets=all --enable-checking=release --build=i486-linux-gnu
--host=i486-linux-gnu --target=i486-linux-gnu
Thread model: posix
gcc version 4.2.3 (Ubuntu 4.2.3-2ubuntu7)
--
Summary: ICE in simplify_subreg at simplify-rtx.c:4484
Product: gcc
Version: 4.2.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: matti dot niemenmaa+gccbugs at iki dot fi
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36532
[Bug fortran/36518] libgfortran: warning: format '%d' expects type 'int', but
--- Comment #3 from burnus at gcc dot gnu dot org 2008-06-13 18:48 --- FIXED on the trunk (4.4.0). -- 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=36518
[Bug middle-end/36532] ICE in simplify_subreg at simplify-rtx.c:4484
--- Comment #1 from pinskia at gcc dot gnu dot org 2008-06-13 18:52 --- This code is undefined. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||pinskia at gcc dot gnu dot ||org Component|c |middle-end http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36532
[Bug rtl-optimization/36529] -fsee causes ICE
--- Comment #3 from pinskia at gcc dot gnu dot org 2008-06-13 19:27 --- There was some fixes to the trunk for -fsee really. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36529
[Bug fortran/36492] incorrect error when compiling
--- Comment #5 from burnus at gcc dot gnu dot org 2008-06-13 20:25 ---
First program, causes an ICE.
Valgrind shows that it fails in decl.c's build_struct:
if (c-ts.type == BT_CHARACTER !c-pointer c-initializer)
{
int len = mpz_get_si (c-ts.cl-length-value.integer);
As c-ts.cl-length-value is probably a NULL pointer.
Thus for some reason there is no check whether the length is a specification
expression - or actually in this case it needs to be even an initialization
expression.
Possible starting point for investigations: char_len_param_value
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36492
[Bug libfortran/35863] [F2003] Implement ENCODING=UTF-8
--- Comment #6 from jvdelisle at gcc dot gnu dot org 2008-06-13 20:28 --- Subject: Bug 35863 Author: jvdelisle Date: Fri Jun 13 20:28:08 2008 New Revision: 136763 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=136763 Log: 2008-06-13 Jerry DeLisle [EMAIL PROTECTED] PR fortran/35863 * libgfortran.h: Change l8_to_l4_offset to big_endian and add endian_off. * runtime/main.c: Fix error in comment. Change l8_to_l4_offset to big_endian. (determine_endianness): Add endian_off and set its value according to big_endian. * gfortran.map: Add symbol for new _gfortran_transfer_character_wide. * io/io.h: Add prototype declarations for new functions. * io/list_read.c (list_formatted_read_scalar): Modify to handle kind=4. (list_formatted_read): Calculate stride based on kind for character type and use it when calling list_formatted_read_scalar. * io/inquire.c (inquire_via_unit): Change l8_to_l4_offset to big_endian. * io/open.c (st_open): Change l8_to_l4_offset to big_endian. * io/read.c (read_a_char4): New function to handle formatted read. * io/write.c: Define GFC_CHAR4(x) to improve readability of code. (write_a_char4): New function to handle formatted write. (write_character): Modify to accept the kind parameter and adjust for endianess of the machine. (list_formatted_write): Calculate the stride resulting from the kind and adjust the list_formatted_write_scalar call accordingly. (nml_write_obj): Adjust calls to write_character. (namelist_write): Likewise. * io/transfer.c (formatted_transfer_scaler): Rename 'len' argument to 'kind' argument to better describe what it is. Add calls to new functions for kind == 4. (formatted_transfer): Modify to handle the case of type character and kind equals 4 to pass in the kind to the transfer routines. (transfer_character_wide): Add this new function. (transfer_array): Don't set kind to the character string length. Adjust strides bases on character kind. (unformatted_read): Adjust size based on kind for character types. (unformatted_write): Likewise. (data_transfer_init): Change l8_to_l4_offset to big_endian. Modified: trunk/libgfortran/ChangeLog trunk/libgfortran/gfortran.map trunk/libgfortran/io/fbuf.c trunk/libgfortran/io/inquire.c trunk/libgfortran/io/io.h trunk/libgfortran/io/list_read.c trunk/libgfortran/io/open.c trunk/libgfortran/io/read.c trunk/libgfortran/io/transfer.c trunk/libgfortran/io/write.c trunk/libgfortran/libgfortran.h trunk/libgfortran/runtime/main.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35863
[Bug libfortran/35863] [F2003] Implement ENCODING=UTF-8
--- Comment #7 from jvdelisle at gcc dot gnu dot org 2008-06-13 20:31 --- Subject: Bug 35863 Author: jvdelisle Date: Fri Jun 13 20:30:48 2008 New Revision: 136764 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=136764 Log: 2008-06-13 Jerry DeLisle [EMAIL PROTECTED] PR fortran/35863 * trans-io.c (gfc_build_io_library_fndecls): Build declaration for transfer_character_wide which includes passing in the character kind to support wide character IO. (transfer_expr): If the kind == 4, create the argument and build the call. * gfortran.texi: Fix typo. Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/gfortran.texi trunk/gcc/fortran/trans-io.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35863
[Bug libfortran/35863] [F2003] Implement ENCODING=UTF-8
--- Comment #8 from jvdelisle at gcc dot gnu dot org 2008-06-13 20:35 --- Subject: Bug 35863 Author: jvdelisle Date: Fri Jun 13 20:35:12 2008 New Revision: 136766 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=136766 Log: 2008-06-13 Jerry DeLisle [EMAIL PROTECTED] PR fortran/35863 * gfortran.dg/widechar_IO_1.f90: New test. * gfortran.dg/widechar_IO_2.f90: New test. * gfortran.dg/widechar_IO_3.f90: New test. * gfortran.dg/widechar_IO_4.f90: New test. Added: trunk/gcc/testsuite/gfortran.dg/widechar_IO_1.f90 trunk/gcc/testsuite/gfortran.dg/widechar_IO_2.f90 trunk/gcc/testsuite/gfortran.dg/widechar_IO_3.f90 trunk/gcc/testsuite/gfortran.dg/widechar_IO_4.f90 Modified: trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35863
[Bug fortran/36492] incorrect error when compiling
--- Comment #6 from d at domob dot eu 2008-06-13 20:36 --- Thanks for the additional hint, I'm into this. I've implemented some tests and am now working on integrating this fix with my pending patch for PR 36517. When the bogus error is fixed, I'll work on the ICE and hopefully we can fix PR 36517 and this one soon. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36492
[Bug fortran/36342] [4.4 Regression] Missing file name in compilation diagnostics of preprocessed fortran source
--- Comment #7 from burnus at gcc dot gnu dot org 2008-06-13 21:19 --- Works for me. Possibly fixed by PR preprocessor/36479. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36342
[Bug target/36533] New: [4.3/4.4 Regression] Incorrectly assumed aligned_operand
The following testcase is miscompiled on i?86 -m32 -Os:
/* { dg-options -Os } */
typedef struct S1
{
unsigned long s1;
struct S1 *s2;
char *s3;
} S1;
typedef struct
{
unsigned int s4;
unsigned int s5;
int s6;
unsigned int *s7;
} S2;
typedef struct
{
unsigned int s8;
unsigned short s9;
unsigned char s10;
unsigned char s11;
char s12[255];
} S3;
typedef struct
{
unsigned int s4;
unsigned short s13;
unsigned short s14;
} S4;
typedef struct
{
char s15[16];
unsigned long s16;
} S5;
typedef struct
{
char s15[48];
S5 *s17;
} S6;
typedef struct
{
S1 *s18;
} S7;
extern __attribute__((regparm (3))) int fn1 (const char *x, void *y, S1 *z);
extern __attribute__((regparm (3))) int fn2 (const char *x, int y, S2 *z);
static inline __attribute__ ((always_inline)) unsigned int
fn4 (unsigned short x)
{
unsigned len = x;
if (len == ((1 16) - 1))
return 1 16;
return len;
}
static inline __attribute__ ((always_inline)) S3 *
fn3 (S3 *p)
{
return (S3 *) ((char *) p + fn4 (p-s9));
}
extern __attribute__((regparm (3))) int fn5 (void);
static inline __attribute__ ((always_inline)) int
fn6 (S3 *w, int x, S2 *y, S4 *z)
{
int a = 0;
char *b = (char *) w;
S2 c = *y;
while ((char *) w b + x)
{
if (w-s10 w-s8)
{
fn2 (w-s12, w-s10, c);
z--;
z-s4 = c.s4;
z-s13 = (unsigned short) ((char *) w - b);
z-s14 = w-s9;
a++;
fn5 ();
}
w = fn3 (w);
}
return a;
}
__attribute__((regparm (3))) unsigned int
test (void *u, S6 *v, S1 **w, S7 *x, S2 *y, S1 *z)
{
unsigned b = v-s17-s16;
unsigned a;
S4 *c;
unsigned d, e, f, i;
fn1 (__func__, u, x-s18);
c = (S4 *) (z-s3 + b);
a = fn6 ((S3 *) (*w)-s3, b, y, c);
c -= a;
f = 0;
e = 0;
for (i = a - 1; ; i--)
{
if (f + (unsigned short) (c[i].s14 / 2) b / 2)
break;
f += c[i].s14;
e++;
}
d = a - e;
return c[d].s4;
}
since the PR28690 backport. The c[i].s14 read is done using
movl(%ecx), %edi# variable.s14, D.1321
rather than
movw (%ecx), %di
which is wrong in this case, as %ecx is provably not 32-bit aligned (%ecx - 6
is
known to be 32-bit aligned). Shouldn't be hard to transform this into an
executable testcase (put the array of S14 at the end of mmaped page such that
the last c[i].s14 is right before end of page).
This is a regression since 4.3.0.
--
Summary: [4.3/4.4 Regression] Incorrectly assumed aligned_operand
Product: gcc
Version: 4.3.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: jakub at gcc dot gnu dot org
GCC target triplet: i686-linux
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36533
[Bug target/36533] [4.3/4.4 Regression] Incorrectly assumed aligned_operand
-- jakub at gcc dot gnu dot org changed: What|Removed |Added CC||bergner at gcc dot gnu dot ||org Severity|normal |major Priority|P3 |P1 Target Milestone|--- |4.3.2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36533
[Bug fortran/36534] New: Bogus: '__convert_s1_s4' at (1) is obsolescent in fortran 95
Found via a typo and missing -pedantic in
gfortran.dg/parameter_array_init_4.f90
$ gfortran -pedantic gfortran.dg/parameter_array_init_4.f90
parameter_array_init_4.f90:18.45:
PARAMETER ( MY_STRING4 = (/ A , B, C /) )
1
Warning: CHARACTER(*) function '__convert_s1_s4' at (1) is obsolescent in
fortran 95
Expected: No warning message for internal functions.
See resolve.c:
if (sym-attr.function
sym-ts.type == BT_CHARACTER
sym-ts.cl sym-ts.cl-length == NULL)
{
[...]
/* Appendix B.2 of the standard. Contained functions give an
error anyway. Fixed-form is likely to be F77/legacy. */
if (!sym-attr.contained gfc_current_form != FORM_FIXED)
gfc_notify_std (GFC_STD_F95_OBS, CHARACTER(*) function
'%s' at %L is obsolescent in fortran 95,
sym-name, sym-declared_at);
Test case:
CHARACTER (kind=4,len=*) MY_STRING4(1:3), my_string_s4
PARAMETER ( MY_STRING4 = (/ A , B, C /) )
--
Summary: Bogus: '__convert_s1_s4' at (1) is obsolescent in
fortran 95
Product: gcc
Version: 4.4.0
Status: UNCONFIRMED
Keywords: diagnostic
Severity: normal
Priority: P3
Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: burnus at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36534
[Bug c++/36364] [4.1/4.2/4.3/4.4 Regression] Problem with -frepo
-- mmitchel at gcc dot gnu dot org changed: What|Removed |Added Priority|P3 |P1 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36364
[Bug bootstrap/35619] [4.3/4.4 Regression] fixed includes not being found if building in src dir
--- Comment #19 from mmitchel at gcc dot gnu dot org 2008-06-13 21:40 --- Andrew -- Why did you reopen this? It sounds like the submitter was building in the srcdir, and that when building in the objdir, it worked fined. Isn't that exactly the situation we expect? -- Mark -- mmitchel 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=35619
[Bug tree-optimization/36218] [4.2/4.3/4.4 regression] VRP causes stack overflow while building libgcj
--- Comment #8 from mmitchel at gcc dot gnu dot org 2008-06-13 21:41 --- Ian -- Do you have any thoughts about this issue? -- Mark -- mmitchel at gcc dot gnu dot org changed: What|Removed |Added CC||ian at airs dot com Priority|P3 |P2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36218
[Bug testsuite/36344] [4.3/4.4 Regression] gcc.dg/tree-ssa/loadpre8.c XFAILed
-- mmitchel at gcc dot gnu dot org changed: What|Removed |Added Priority|P3 |P2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36344
[Bug rtl-optimization/36365] [4.3/4.4 Regression] Hang in df_analyze
-- mmitchel at gcc dot gnu dot org changed: What|Removed |Added Priority|P3 |P2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36365
[Bug rtl-optimization/36419] [4.1/4.3/4.4 Regression] Wrong unwind info with -Os -fasynchronous-unwind-tables
--- Comment #11 from mmitchel at gcc dot gnu dot org 2008-06-13 21:43 --- Jakub -- This is still marked as a 4.3/4.4 regression. But, there are patches in the audit trail. If that's correct would you please adjust the Summary field? Thanks, -- Mark -- mmitchel at gcc dot gnu dot org changed: What|Removed |Added Priority|P3 |P1 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36419
[Bug tree-optimization/36439] [4.3/4.4 Regression] infinite loop in PRE building gimp-plugin-registry
-- mmitchel at gcc dot gnu dot org changed: What|Removed |Added Priority|P3 |P2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36439
[Bug tree-optimization/36493] [4.3/4.4 Regression] vectorizer aliasing bug
-- mmitchel at gcc dot gnu dot org changed: What|Removed |Added Priority|P3 |P1 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36493
[Bug tree-optimization/36504] [4.3/4.4 regression] ICE when building xorg-server with -O3 -fprefetch-loop-arrays
-- mmitchel at gcc dot gnu dot org changed: What|Removed |Added Priority|P3 |P1 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36504
[Bug tree-optimization/36508] [4.3 Regression] ICE in compute_antic
-- mmitchel at gcc dot gnu dot org changed: What|Removed |Added Priority|P3 |P1 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36508
[Bug target/36533] [4.3/4.4 Regression] Incorrectly assumed aligned_operand
--- Comment #1 from pinskia at gcc dot gnu dot org 2008-06-13 21:46 ---
aligned_operand looks wrong:
/* Look for some component that isn't known to be aligned. */
if (parts.index)
{
if (REGNO_POINTER_ALIGN (REGNO (parts.index)) * parts.scale 32)
return 0;
}
if (parts.base)
{
if (REGNO_POINTER_ALIGN (REGNO (parts.base)) 32)
return 0;
}
We are using the hard registers here so we can have the wrong alignment as they
are shared.
Why are we looking into register pointer's alignment anyways? The MEM_ALIGN
check about should give the correct information anyways.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
CC||pinskia at gcc dot gnu dot
||org
Severity|major |normal
Keywords||wrong-code
Priority|P1 |P2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36533
[Bug middle-end/36369] [4.3/4.4 Regression] may_alias broken with previous uses of non attributed type in some cases
-- mmitchel at gcc dot gnu dot org changed: What|Removed |Added Priority|P3 |P1 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36369
[Bug tree-optimization/36373] [4.2/4.3/4.4 Regression] Wrong code with struct return
-- mmitchel at gcc dot gnu dot org changed: What|Removed |Added Priority|P3 |P1 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36373
[Bug other/36498] [4.3 Regression] time/memory hog for large c++ source.
--- Comment #14 from mmitchel at gcc dot gnu dot org 2008-06-13 21:53 --- Richard -- Is this still an issue, after your patch? Thanks, -- Mark -- mmitchel at gcc dot gnu dot org changed: What|Removed |Added Priority|P3 |P2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36498
[Bug tree-optimization/36519] [4.3 Regression] time/memory hog for c++ source.
-- mmitchel at gcc dot gnu dot org changed: What|Removed |Added Priority|P3 |P2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36519
[Bug target/36349] gcc-4.3.0 build fails with multiple definitions
--- Comment #7 from phorgan1 at gmail dot com 2008-06-13 21:54 --- I don't know what changed, but on the same machine with the same circumstances the build completes successfully now. I can only think that something in the environment changed as a result of updates on the machine, although the version of gcc that builds it now is the same as the one that didn't build it before?:( Patricik -- phorgan1 at gmail dot com changed: What|Removed |Added Status|WAITING |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36349
[Bug bootstrap/35752] [4.3/4.4 Regression]: Combined gcc + binutils source tree doesn't bootstrap with --enable-shared
-- mmitchel at gcc dot gnu dot org changed: What|Removed |Added Priority|P3 |P2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35752
[Bug rtl-optimization/36419] [4.1/4.3/4.4 Regression] Wrong unwind info with -Os -fasynchronous-unwind-tables
--- Comment #12 from jakub at gcc dot gnu dot org 2008-06-13 21:57 --- See comment #c5. There are 3 issues, 1) has been fixed, 2) has a patch posted, but so far not reviewed - http://gcc.gnu.org/ml/gcc-patches/2008-06/msg00677.html and 3) has no fix yet at all. All 3 are needed to fix the miscompiled OOo. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36419
[Bug libstdc++/35637] [4.3 Regression] tr1::function fails with const member function pointer
--- Comment #13 from mmitchel at gcc dot gnu dot org 2008-06-13 21:59 --- I've reclosed this bug. Manuel, if you'd like to open another issue for Comment #9, please go ahead. Thanks, -- Mark -- mmitchel at gcc dot gnu dot org changed: What|Removed |Added Status|REOPENED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35637
[Bug target/36533] [4.3/4.4 Regression] Incorrectly assumed aligned_operand
--- Comment #2 from bergner at gcc dot gnu dot org 2008-06-13 22:14 ---
We shouldn't be attempting to call mark_reg_pointer in set_reg_attrs_from_value
for a hard reg, since they can be shared between different values. Andrew
mentioned we maybe shouldn't be calling set_reg_attrs_from_value() with a hard
reg, or we could do the following:
--- emit-rtl.c (revision 134986)
+++ emit-rtl.c (working copy)
@@ -969,14 +969,14 @@ set_reg_attrs_from_value (rtx reg, rtx x
if (MEM_OFFSET (x) GET_CODE (MEM_OFFSET (x)) == CONST_INT)
REG_ATTRS (reg)
= get_reg_attrs (MEM_EXPR (x), INTVAL (MEM_OFFSET (x)) + offset);
- if (MEM_POINTER (x))
+ if (!HARD_REGISTER_P (reg) MEM_POINTER (x))
mark_reg_pointer (reg, MEM_ALIGN (x));
}
else if (REG_P (x))
{
if (REG_ATTRS (x))
update_reg_offset (reg, x, offset);
- if (REG_POINTER (x))
+ if (!HARD_REGISTER_P (reg) REG_POINTER (x))
mark_reg_pointer (reg, REGNO_POINTER_ALIGN (REGNO (x)));
}
}
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36533
[Bug target/36533] [4.3/4.4 Regression] Incorrectly assumed aligned_operand
--- Comment #3 from jakub at gcc dot gnu dot org 2008-06-13 22:19 --- In addition to that, I wonder whether i386's aligned_operand shouldn't prefer ORIGINAL_REGNO over REGNO when checking pointer alignment. -- jakub at gcc dot gnu dot org changed: What|Removed |Added CC||hubicka at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36533
[Bug fortran/36535] New: gfortran.dg/parameter_array_init_4.f90 doesn't work
On Linux/x86-64, I got Executing on host: /export/build/gnu/gcc/build-x86_64-linux/gcc/testsuite/gfortran/../../gfortran -B/export/build/gnu/gcc/build-x86_64-linux/gcc/testsuite/gfortran/../../ /net/gnu-13/export/gnu/src/gcc/gcc/gcc/testsuite/gfortran.dg/parameter_array_init_4.f90 -O0 -pedantic-errors -L/export/build/gnu/gcc/build-x86_64-linux/x86_64-unknown-linux-gnu/32/libgfortran/.libs -L/export/build/gnu/gcc/build-x86_64-linux/x86_64-unknown-linux-gnu/32/libgfortran/.libs -L/export/build/gnu/gcc/build-x86_64-linux/x86_64-unknown-linux-gnu/32/libiberty -lm -m32 -o ./parameter_array_init_4.exe(timeout = 300) /net/gnu-13/export/gnu/src/gcc/gcc/gcc/testsuite/gfortran.dg/parameter_array_init_4.f90:18.45:^M ^M PARAMETER ( MY_STRING4 = (/ A , B, C /) )^M 1^M Warning: CHARACTER(*) function '__convert_s1_s4' at (1) is obsolescent in fortran 95^M output is: /net/gnu-13/export/gnu/src/gcc/gcc/gcc/testsuite/gfortran.dg/parameter_array_init_4.f90:18.45:^M ^M PARAMETER ( MY_STRING4 = (/ A , B, C /) )^M 1^M Warning: CHARACTER(*) function '__convert_s1_s4' at (1) is obsolescent in fortran 95^M FAIL: gfortran.dg/parameter_array_init_4.f90 -O0 (test for excess errors) -- Summary: gfortran.dg/parameter_array_init_4.f90 doesn't work Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: hjl dot tools at gmail dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36535
[Bug fortran/36534] Bogus: '__convert_s1_s4' at (1) is obsolescent in fortran 95
--- Comment #1 from fxcoudert at gcc dot gnu dot org 2008-06-13 23:06 --- I love that one: Fixed-form is likely to be F77/legacy. Well, the issue is that I don't think we have a way to tell, from the sym, that it's a internal conversion function. Maybe the crude way, check if the name starts with __convert_? -- fxcoudert at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2008-06-13 23:06:13 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36534
