[Bug c++/36307] New: __attribute__((deprecated)) does not work for member templates

The following could should produce a warning but it doesn't. struct Foo { template void foo() __attribute__((deprecated)); }; template void Foo::foo() {} int main () { Foo f; f.foo(); } My compiler is g++-4.3 (Debian 4.3.0-3) 4.3.1 20080401 (prerelease) This is a regression.

[Bug target/36079] [4.3/4.4 Regression] cld instruction is not emitted anymore.

--- Comment #13 from uros at gcc dot gnu dot org 2008-05-23 07:53 --- Subject: Bug 36079 Author: uros Date: Fri May 23 07:53:16 2008 New Revision: 135792 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=135792 Log: PR target/36079 * configure.ac: Handle --enable-cl

[Bug target/36079] [4.3/4.4 Regression] cld instruction is not emitted anymore.

--- Comment #14 from ubizjak at gmail dot com 2008-05-23 08:39 --- Fixed for 4.3.1 and 4.4. -- ubizjak at gmail dot com changed: What|Removed |Added Status|RE

[Bug c++/36308] New: OpenMP privatized vars don't get dtors called if they are virtual

// { dg-do run } #include #include #define N 10 struct B { static int icount; static int ccount; static int dcount; static int xcount; B (); B (const B &); virtual ~B (); B& operator= (const B &); void doit (); static void clear () { icount = ccount = dcount = xcount = 0;

[Bug c++/36237] internal compiler error: in lower_stmt, at gimple-low.c:282 erase 'private(localTodoStack)' it compiles successfully.

--- Comment #3 from jakub at gcc dot gnu dot org 2008-05-23 09:12 --- Reduced testcase: struct A { ~A (); }; struct B { explicit B (const A &x = A ()) : a (x) { } A a; }; B var; void bar (); void foo () { #pragma omp parallel private (var) bar (); } Note that your examp

[Bug fortran/36309] New: gfrotran and cc1 error

When invoking gfortran to compile some fortran code with C preprocessor commands in it and using the .F file extension to ensure that the code is passed though the C pre-processor and error occurs with cc1 The command is: gfortran -c -g -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -fno-underscoring

[Bug c++/36310] New: Lots of (possibly) unnecesary static initialization code generated.

I add -Os -Wall flags to every avr-g++ command. During coding I've noticed g++ adds plenty of unnecessary assembly to output file. I'll try to check it with gcc 4.x but currently I fail to compile it. Problem is related to static initialization of template class/struct variable. Following code sni

[Bug middle-end/36213] Wrong search path generation

--- Comment #9 from martin dot drab at fjfi dot cvut dot cz 2008-05-23 11:09 --- OK, so I tried to compile with autogenerated paths just from the prefix, and with the --enable-version-specific-runtime-libs option. The path no longer seems corrupted. It searches all its internal include

[Bug bootstrap/36311] New: Bootstrapping ada fails

Bootstrapping ada fails today, on Wednesday it was okay The error is | 4.4.0 20080523 (experimental) (i686-pc-linux-gnu) GCC error: | | in handle_type_generic_attribute, at ada/utils.c:4716| | Error detected around ../../gcc/gcc/ada/system.ads:1

[Bug c/36312] New: Compiling options

Why doesn't gcc report an error or warning in such a case: gcc filename.c -g -o filename.c I have a very long C program, whose sources that got lost because of the above command. All I see in my program are some junk letters. I know it's human error, but can you please incorporate any warning mes

[Bug c++/36308] OpenMP privatized vars don't get dtors called if they are virtual

--- Comment #1 from jakub at gcc dot gnu dot org 2008-05-23 11:53 --- Subject: Bug 36308 Author: jakub Date: Fri May 23 11:52:44 2008 New Revision: 135798 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=135798 Log: PR c++/36308 * semantics.c (omp_clause_info_fndec

[Bug bootstrap/36311] Bootstrapping ada fails

--- Comment #1 from charlet at gcc dot gnu dot org 2008-05-23 11:58 --- This has been fixed already by Eric, rev 135797 Arno -- charlet at gcc dot gnu dot org changed: What|Removed |Added ---

[Bug c++/36308] OpenMP privatized vars don't get dtors called if they are virtual

--- Comment #2 from jakub at gcc dot gnu dot org 2008-05-23 12:17 --- Subject: Bug 36308 Author: jakub Date: Fri May 23 12:16:41 2008 New Revision: 135800 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=135800 Log: PR c++/36308 * semantics.c (omp_clause_info_fndec

[Bug c++/36310] Lots of (possibly) unnecesary static initialization code generated.

--- Comment #3 from bla at thera dot be 2008-05-23 12:42 --- Compiled by hand 4.2.0 version (4.3 has some Makefile issue I wasn't able to fix). It seems to have the same "issue", although it saves some space on context save/restore. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36

[Bug fortran/36313] New: [F2003] {MIN,MAX}{LOC,VAL} should accept character arguments

Starting with Fortran 2003, MINVAL, MAXVAL, MINLOC and MAXLOC accept character arguments. (Also, when implementing this, please remember to support wide characters!) -- Summary: [F2003] {MIN,MAX}{LOC,VAL} should accept character arguments Product: gcc

[Bug c++/36237] internal compiler error: in lower_stmt, at gimple-low.c:282 erase 'private(localTodoStack)' it compiles successfully.

--- Comment #4 from silviug at gmail dot com 2008-05-23 12:51 --- (In reply to comment #3) > Note that your example is very buggy. Yes, I must agree, I'm new to OpenMP :) In the end I solved the issues you are pointing out. Still I shouldn't get a compiler internal error for buggy code

[Bug c++/36310] Lots of (possibly) unnecesary static initialization code generated.

--- Comment #2 from bla at thera dot be 2008-05-23 12:40 --- Created an attachment (id=15675) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15675&action=view) OUTER=1, no additional static initialization (gcc 4.2) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36310

[Bug c++/36310] Lots of (possibly) unnecesary static initialization code generated.

--- Comment #1 from bla at thera dot be 2008-05-23 12:39 --- Created an attachment (id=15674) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15674&action=view) Code with additional static initialization (OUTER=0) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36310

[Bug libgcj/35020] Class.getSimpleName() differs from Sun Java

--- Comment #4 from aph at gcc dot gnu dot org 2008-05-23 13:05 --- Subject: Bug 35020 Author: aph Date: Fri May 23 13:04:18 2008 New Revision: 135801 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=135801 Log: 2008-05-22 Andrew Haley <[EMAIL PROTECTED]> PR libgcj/3502

[Bug libgcj/35020] Class.getSimpleName() differs from Sun Java

--- Comment #5 from aph at gcc dot gnu dot org 2008-05-23 13:05 --- Fixed. -- aph at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED

[Bug c++/36237] internal compiler error: in lower_stmt, at gimple-low.c:282 erase 'private(localTodoStack)' it compiles successfully.

--- Comment #5 from jakub at gcc dot gnu dot org 2008-05-23 13:22 --- Subject: Bug 36237 Author: jakub Date: Fri May 23 13:21:47 2008 New Revision: 135802 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=135802 Log: PR c++/36237 * cp-gimplify.c (cxx_omp_clause_appl

[Bug c++/36308] OpenMP privatized vars don't get dtors called if they are virtual

-- jakub at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reco

[Bug c++/36237] internal compiler error: in lower_stmt, at gimple-low.c:282 erase 'private(localTodoStack)' it compiles successfully.

--- Comment #6 from jakub at gcc dot gnu dot org 2008-05-23 13:31 --- Subject: Bug 36237 Author: jakub Date: Fri May 23 13:30:51 2008 New Revision: 135807 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=135807 Log: PR c++/36237 * cp-gimplify.c (cxx_omp_clause_appl

[Bug c++/36237] internal compiler error: in lower_stmt, at gimple-low.c:282 erase 'private(localTodoStack)' it compiles successfully.

-- 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

[Bug c++/36237] internal compiler error: in lower_stmt, at gimple-low.c:282 erase 'private(localTodoStack)' it compiles successfully.

--- Comment #7 from jakub at gcc dot gnu dot org 2008-05-23 13:33 --- Fixed in 4.4/4.3. -- jakub at gcc dot gnu dot org changed: What|Removed |Added Status|AS

[Bug c++/36308] OpenMP privatized vars don't get dtors called if they are virtual

--- Comment #3 from jakub at gcc dot gnu dot org 2008-05-23 13:34 --- Fixed for 4.3/4.4. -- jakub at gcc dot gnu dot org changed: What|Removed |Added Status|A

[Bug c++/34158] Template delete doesn't call if exception thrown in constructor

--- Comment #3 from steve_cheng at scotiacapital dot com 2008-05-23 13:41 --- I have hit the same bug as the original reporter. Attached is a simplified test case. Run with: $ g++ -v -save-temps -o testPlacementDelete testPlacementDelete.C $ ./testPlacementDelete placement new call

[Bug c++/34158] Template delete doesn't call if exception thrown in constructor

--- Comment #4 from steve_cheng at scotiacapital dot com 2008-05-23 13:43 --- Created an attachment (id=15676) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15676&action=view) C++ test case -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34158

[Bug c++/34158] Template delete doesn't call if exception thrown in constructor

--- Comment #5 from steve_cheng at scotiacapital dot com 2008-05-23 13:44 --- Created an attachment (id=15677) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15677&action=view) -save-temps when compiling C++ testcase -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34158

[Bug fortran/36314] New: gfortran.dg/eoshift_large_1.f90 doesn't wiork

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/eoshift_large_1.f90 -O0 -pedantic-errors -L/export/buil

[Bug tree-optimization/36291] GCC is slow and memory-hungry building sipQtGuipart.cpp

--- Comment #7 from rguenth at gcc dot gnu dot org 2008-05-23 14:16 --- Ok, apart from the var annotations I give up here as far as 4.3 is concerned. We cannot really fix the compile-time problem without skewing the heuristics and risking fallout through that. We already know from PR332

[Bug tree-optimization/36291] GCC is slow and memory-hungry building sipQtGuipart.cpp

-- 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

[Bug fortran/36314] gfortran.dg/eoshift_large_1.f90 doesn't work

--- Comment #1 from dominiq at lps dot ens dot fr 2008-05-23 14:30 --- (from http://gcc.gnu.org/ml/gcc-patches/2008-05/msg01473.html) > It may be a 64bit target problem. I don't think so. As stated by the warnings "Nonconforming tab character", there are two "tabs" in the test source, m

[Bug tree-optimization/35618] [4.3 regression] ICE in cgraph_estimate_size_after_inlining, at ipa-inline.c:188

--- Comment #8 from rguenth at gcc dot gnu dot org 2008-05-23 14:35 --- Confirmed. Testcase, -Os -fno-unit-at-a-time static void __resched_task(void *p, int tif_bit); static inline __attribute__((always_inline)) void resched_task(void *p) { __resched_task(p, 2); } static void __resch

[Bug fortran/36314] gfortran.dg/eoshift_large_1.f90 doesn't work

--- Comment #2 from hjl dot tools at gmail dot com 2008-05-23 14:45 --- I got different messages for 64bit and 32bit targets on Linux/Intel64: [EMAIL PROTECTED] gfortran]$ /export/build/gnu/gcc/build-x86_64-linux/gcc/testsuite/gfortran/../../gfortran -B/export/build/gnu/gcc/build-x86_64

[Bug target/35658] [4.3/4.4 regression] Bad interaction on ia64 between -funroll-loops -fno-automatic -O2 and common block variable

--- Comment #6 from sje at cup dot hp dot com 2008-05-23 15:02 --- It looks like this is a bug in register renaming. register renaming is turned on by -floop-unroll. You can reproduce the bug using -frename-registers in place of -funroll-loops. -- http://gcc.gnu.org/bugzilla/show_

[Bug fortran/36314] gfortran.dg/eoshift_large_1.f90 doesn't work

--- Comment #3 from burnus at gcc dot gnu dot org 2008-05-23 15:07 --- Subject: Bug 36314 Author: burnus Date: Fri May 23 15:06:26 2008 New Revision: 135817 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=135817 Log: 2008-05-23 Tobias Burnus <[EMAIL PROTECTED]> PR fortr

[Bug fortran/36314] gfortran.dg/eoshift_large_1.f90 doesn't work

--- Comment #4 from burnus at gcc dot gnu dot org 2008-05-23 15:08 --- FIXED on the trunk (4.4.0). * * * > I got different messages for 64bit and 32bit targets on Linux/Intel64: > Error: Kind 16 not supported for type INTEGER at (1) That error should never occur on 32bit as there is

[Bug fortran/36314] gfortran.dg/eoshift_large_1.f90 doesn't work

--- Comment #5 from dominiq at lps dot ens dot fr 2008-05-23 15:17 --- > I got different messages for 64bit and 32bit targets on Linux/Intel64: AFAICT KIND=16 is available on 64 bit mode only: dg-require-effective-target fortran_large_int . -- http://gcc.gnu.org/bugzilla/show_bug.

[Bug middle-end/36213] Wrong search path generation

--- Comment #10 from Ralf dot Wildenhues at gmx dot de 2008-05-23 15:25 --- The --enable-version-specific-runtime-libs bit of this bug report is a duplicate of PR32415 -- Ralf dot Wildenhues at gmx dot de changed: What|Removed |Added -

[Bug middle-end/36213] Wrong search path generation

--- Comment #11 from martin dot drab at fjfi dot cvut dot cz 2008-05-23 16:05 --- Alright, and I think I know what causes the rest of the path problem. The GCC_EXEC_PREFIX environment variable has to lead to the .../lib/gcc/ and not the .../lib/gcc/x86_64-pc-linux-gnu/4.4.0 and IT HAS T

[Bug fortran/36309] gfrotran and cc1 error

--- Comment #1 from rguenth at gcc dot gnu dot org 2008-05-23 16:39 --- Works with 4.3. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Known to work|

[Bug driver/36312] should refuse to overwrite input file with output file

--- Comment #1 from rguenth at gcc dot gnu dot org 2008-05-23 16:41 --- Happened to me as well. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added S

[Bug driver/36312] should refuse to overwrite input file with output file

--- Comment #2 from shoaib dot jameel at gmail dot com 2008-05-23 16:48 --- (In reply to comment #1) > Happened to me as well. any remedy...so as to recover the lost C codes? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36312

[Bug driver/36312] should refuse to overwrite input file with output file

--- Comment #3 from rguenth at gcc dot gnu dot org 2008-05-23 17:01 --- I didn't lose anything - the internet backs up for me. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36312

[Bug libgomp/36298] gomp contains small memoryleak

--- Comment #1 from jakub at gcc dot gnu dot org 2008-05-23 17:03 --- This is not a memory leak, just misunderstanding what valgrind is reporting. Memory still reachable at exit time is not a bug, all memory is freed by exit. Some libraries are instrumented with hooks that at exit time c

[Bug driver/36312] should refuse to overwrite input file with output file

--- Comment #4 from shoaib dot jameel at gmail dot com 2008-05-23 17:05 --- (In reply to comment #3) > I didn't lose anything - the internet backs up for me. THe problem with me is rather grave. I dont even have a backup. Any method by which I can recover the source code? I need the co

[Bug middle-end/36315] New: [4.4 Regression] ICE with -fprofile-use (Invalid read of size 8)

With 4.4.0 20080523 [trunk revision 135791] the following fails on x86-64. It was working with 2008-05-20-r135601. $ gfortran -fprofile-generate -march=opteron -ffast-math -funroll-loops -ftree-vectorize -ftree-loop-linear -msse3 -O3 mdbx.f90 $ ./a.out $ gfortran -fprofile-use -march=opteron

[Bug fortran/36309] gfrotran and cc1 error

--- Comment #2 from burnus at gcc dot gnu dot org 2008-05-23 17:49 --- Could you provide some more details, especially about your gfortran version. The problem is that using: $ gfortran-4.1 -fno-underscoring aa.F $ gfortran-4.2 -fno-underscoring aa.F $ gfortran-4.3 -fno-underscoring aa.

[Bug fortran/36316] New: type mismatch in binary expression caught by verify_gimple

The following module definition: MODULE YOMCAIN IMPLICIT NONE SAVE TYPE distributed_vector REAL, pointer :: local(:) INTEGER :: global_length,local_start,local_end,nchnks END TYPE distributed_vector INTERFACE ASSIGNMENT (=) MODULE PROCEDURE assign_dv_dv END INTERFACE INTERFACE OPERATOR (

[Bug fortran/36316] type mismatch in binary expression caught by verify_gimple

--- Comment #1 from dominiq at lps dot ens dot fr 2008-05-23 18:35 --- On *-apple-darwin9, revision 135821, but also gfortran 4.3.0, I get: pr36316.f90:52.5: ZTEMP = PVAZG * SCALP_DV 1 Error: Incompatible ranks 0 and 1 in assignment at (1) Same thing with ifort 10.1 and g95. --

[Bug c++/36317] New: Linker creates failing binary, object file order, extern

Linker creates a failing binary. Trivial to duplicate: http://www.ltn.lv/~edgarsi/upload/files/big_fail_test.pdf This behaviour appears on g++ versions: 3.3.6 and 4.2.3 -- Summary: Linker creates failing binary, object file order, extern Product: gcc Version: 4.

[Bug fortran/36316] type mismatch in binary expression caught by verify_gimple

--- Comment #2 from burnus at gcc dot gnu dot org 2008-05-23 19:56 --- Same here. With gfortran 4.1, 4.2 and 4.3 of openSUSE and with today's builds of 4.2, 4.3 and 4.4 I get the error message. Also valgrind does not show any problems. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=

[Bug c++/36317] Linker creates failing binary, object file order, extern

--- Comment #1 from pinskia at gcc dot gnu dot org 2008-05-23 19:58 --- the order of initializers between translational units is unspecified. Therefor this code is invalid and gcc/ld is doing the correct thing. -- pinskia at gcc dot gnu dot org changed: What|Removed

[Bug fortran/36316] type mismatch in binary expression caught by verify_gimple

--- Comment #3 from toon at moene dot indiv dot nluug dot nl 2008-05-23 20:07 --- Ugh, sorry, I see I included the wrong source. Here's the correct one: MODULE YOMCAIN IMPLICIT NONE SAVE TYPE distributed_vector REAL, pointer :: local(:) INTEGER :: global_length,local_start,loc

[Bug middle-end/36315] [4.4 Regression] ICE with -fprofile-use (Invalid read of size 8)

--- Comment #1 from ubizjak at gmail dot com 2008-05-23 20:44 --- Confirmed with mdbx.f90 source, probably due to: 2008-05-21 Tom Tromey <[EMAIL PROTECTED]> * ggc-zone.c (lookup_page_table_if_allocated): New function. (zone_find_object_offset): Likewise. (gt_g

[Bug fortran/36309] gfortran and cc1 error

--- Comment #3 from kih at mail dot nerc-essc dot ac dot uk 2008-05-23 20:45 --- Subject: RE: gfrotran and cc1 error Hi Thanks for the response. I was actually installing software on someone else's system (with their permission) which was an apple machine. I will check the version

[Bug fortran/36309] gfortran and cc1 error

--- Comment #4 from kih at mail dot nerc-essc dot ac dot uk 2008-05-23 20:52 --- Subject: RE: gfrotran and cc1 error Hi 'gfortran -v' and 'gcc -v' report: gfortran -v Using built-in specs. Target: powerpc-apple-darwin8 Configured with: /Builds/apple/gcc_42-5531/obj/src/configure

[Bug testsuite/22523] template/inline1.C does not test correctly on all targerts

--- Comment #3 from hp at gcc dot gnu dot org 2008-05-23 21:19 --- No, that change didn't work. On contrary, r135691 caused this test to fail for targets with _ in front of labels, for example cris-elf, by now matching the *use* of the label, like so: jsr __ZN1X3FooIiEEvT_ I'll

[Bug testsuite/22523] template/inline1.C does not test correctly on all targerts

-- hp at gcc dot gnu dot org changed: What|Removed |Added CC||hp at gcc dot gnu dot org AssignedTo|unassigned at gcc dot gnu |

[Bug tree-optimization/36318] New: SRA pessimizes struct copies without -Os

rtl --enable-languages=c,c++,objc Thread model: posix gcc version 4.4.0 20080523 (experimental) (GCC) and these options: > gcc -fno-pic -fomit-frame-pointer -O3 -S wc.c For the attached source, gcc generates good code for global variable assignment: _foo0: subl$12, %esp movl

[Bug tree-optimization/36318] SRA pessimizes struct copies without -Os

--- Comment #1 from astrange at ithinksw dot com 2008-05-23 21:37 --- Created an attachment (id=15678) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15678&action=view) testcase -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36318

[Bug preprocessor/30867] Can we have a new __DATE__ which is sortable, eg YYYY-MM-DD

--- Comment #5 from andrew_dowden at softdesign dot net dot nz 2008-05-23 22:53 --- Strongly agree, can not change existing use/std. as relates to C89/C90 etc. Would also suggest (as minor alternative): __DATEI__ date index-order, numeric, sort friendly; also US-military, etc..

[Bug target/36133] GCC creates suboptimal ASM : Code includes unneeded TST instructions

--- Comment #2 from hp at gcc dot gnu dot org 2008-05-23 23:04 --- This could be a duplicate of PR20211. -- hp at gcc dot gnu dot org changed: What|Removed |Added

[Bug middle-end/31241] Post Increment opportunity missed

--- Comment #3 from hp at gcc dot gnu dot org 2008-05-23 23:05 --- This could be a duplicate of PR20211. -- hp at gcc dot gnu dot org changed: What|Removed |Added

[Bug rtl-optimization/20211] autoincrement generation is poor

--- Comment #38 from hp at gcc dot gnu dot org 2008-05-23 23:13 --- Maybe this issue migrated into PR31849? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20211

[Bug rtl-optimization/34849] Missed autoincrement oppurtunities thanks to a different basic block structure.

--- Comment #4 from hp at gcc dot gnu dot org 2008-05-23 23:14 --- Perhaps this is a duplicate of PR31849? -- hp at gcc dot gnu dot org changed: What|Removed |Added

[Bug tree-optimization/31849] [4.3/4.4 Regression] Code size increased with PR 31360 (IV-opts not understanding autoincrement)

--- Comment #35 from hp at gcc dot gnu dot org 2008-05-23 23:36 --- Looks like this is the new-generation/df equivalent of PR20211! -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31849

[Bug testsuite/22523] template/inline1.C does not test correctly on all targerts

--- Comment #4 from hp at gcc dot gnu dot org 2008-05-24 00:37 --- Subject: Bug 22523 Author: hp Date: Sat May 24 00:37:01 2008 New Revision: 135840 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=135840 Log: PR testsuite/22523 * g++.dg/template/inline1.C: For the

[Bug testsuite/22523] template/inline1.C does not test correctly on all targerts

--- Comment #5 from hp at gcc dot gnu dot org 2008-05-24 00:39 --- See . -- hp at gcc dot gnu dot org changed: What|Removed |Added

[Bug testsuite/22523] template/inline1.C does not test correctly on all targerts

-- hp at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|--- |4.4.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22523

[Bug fortran/36319] New: Segfault with wide characters in DATA

The following code draws a compile time segfault. This is derived from data_array_1.f90 that I have modified while working on wide character I/O. program chkdata integer, parameter,dimension(4) :: myint = [ 4,3,2,1 ] character(len=3, kind=4), parameter, dimension(3) :: mychar = [ "abc", "

[Bug fortran/36319] Segfault with wide characters in DATA

--- Comment #1 from jvdelisle at gcc dot gnu dot org 2008-05-24 02:34 --- Reduced test case: program chkdata integer, parameter :: k4=4 character(len=3, kind=4), parameter, dimension(3) :: mychar = [ "abc", "def", "ghi" ] end program chkdata Note the initializers are kind=1.

[Bug fortran/36319] Segfault with wide characters in DATA

--- Comment #2 from jvdelisle at gcc dot gnu dot org 2008-05-24 02:47 --- Here is a variation: integer, parameter :: k4=4 character(len=3, kind=4), parameter, dimension(3) :: mychar = & &[ k4_"abc", k4_"def", k4_"ghi" ] This gives an error. Is this valid? --

[Bug fortran/36319] Segfault with wide characters in DATA

--- Comment #3 from fxcoudert at gcc dot gnu dot org 2008-05-24 06:52 --- I'm aware of both bugs (found them indepedently while testing some more string intrinsics) and have fixed them with my next patch (will submit in a few days). -- fxcoudert at gcc dot gnu dot org changed: