[Bug fortran/33445] openmp invalid multi-thread runtime result (-ffree-form only!)
--- Comment #4 from jakub at gcc dot gnu dot org 2007-09-17 07:16 --- Why do you think that is a bug? Please read OpenMP 2.5, 2.1.1 (Fixed Source Form Directives) and 2.1.2 (Free Source Form Directives). Continuation is done very differently between fixed and free form. So, what are you citing above is a valid fixed form continuation, but not a valid free form continuation: 10 11 12 2.1.2 has: Continued directive lines must have an ampersand as the last nonblank character on the line, prior to any comment placed inside the directive. Continuation directive lines can have an ampersand after the directive sentinel with optional white space before and after the ampersand. while 2.1.1 has: Initial directive lines must have a space or zero in column 6, and continuation directive lines must have a character other than a space or a zero in column 6. -- jakub at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |WAITING http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33445
[Bug fortran/33445] openmp invalid multi-thread runtime result (-ffree-form only!)
--- Comment #5 from burnus at gcc dot gnu dot org 2007-09-17 07:40 --- How about giving a diagnostic as ifort does: fortcom: Error: test2.f90, line 93: Syntax error, found '&' when expecting one of: ; BLOCK BLOCKDATA PROGRAM TYPE COMPLEX BYTE CHARACTER ... !$omp& default(shared) ---^ or like SUNF95 does: !$omp& default(shared) ^ "test2.f90", Line = 93, Column = 6: ERROR: Unexpected syntax: "OpenMP directive keyword" was expected but found "&". -- burnus at gcc dot gnu dot org changed: What|Removed |Added Keywords|wrong-code |accepts-invalid http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33445
[Bug fortran/33439] OpenMP: Incorrect error message for chunksize variable
--- Comment #1 from burnus at gcc dot gnu dot org 2007-09-17 08:05 --- Jakub, do you agree that this is a bug or is this no bug? -- burnus at gcc dot gnu dot org changed: What|Removed |Added CC||jakub at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33439
[Bug fortran/33439] OpenMP: Incorrect error message for chunksize variable
--- Comment #2 from jakub at gcc dot gnu dot org 2007-09-17 08:18 --- Pedantically this is not a bug. If an omp sentinel doesn't have the desired form, it should be handled as a normal comment. As the preceeding line doesn't end with &, then !$omp& is not a valid omp sentinel (as !$omp needs to be followed by a space) and thus it is the same as say ! $ omp & something That said, perhaps we could issue some diagnostics, because it is likely a user error rather than intent. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33439
[Bug fortran/33439] OpenMP: Incorrect error message for chunksize variable
--- Comment #3 from burnus at gcc dot gnu dot org 2007-09-17 08:21 --- > Pedantically this is not a bug. If an omp sentinel doesn't have the desired > form, it should be handled as a normal comment. I think your comment is with regards to PR 33445 and not regarding this PR (PR33439). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33439
[Bug middle-end/31497] FAIL: gcc.dg/builtins-59.c on PA HP-UX
--- Comment #2 from rguenth at gcc dot gnu dot org 2007-09-17 08:33 --- I guess so. All the testcases rely on either availability of cexp() or sincos(). For the former via TARGET_C99_FUNCTIONS, for the latter via TARGET_HAS_SINCOS. But it is interesting that -59 fails, as the transformation checked should be done via fold_builtin_sincos which only bails out if !TARGET_C99_FUNCTIONS or cepxi is not available (but that is a GCC builtin, so should be available all the times). I don't have time to investigate if we can somehow relax all the machinery around this transformation, but we basically try to avoid locking us up in a corner where we end up with the internal CEXPI but have no way to re-emit either sincos or cexp calls. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31497
[Bug middle-end/33449] [4.3 regression] ICE for fortran code with -O2 -ftree-vectorize
--- Comment #3 from fxcoudert at gcc dot gnu dot org 2007-09-17 08:39 --- I can reproduce that on x86_64-linux with trunk rev. 128442. Severity set to critical, as this is LAPACK. Program received signal SIGSEGV, Segmentation fault. vect_get_vec_defs_for_stmt_copy (dt=0x7fff713d44c0, vec_oprnds0=0x7fff713d44b8, vec_oprnds1=0x7fff713d44b0) at ../../../trunk/gcc/tree.h:210 210 DEF_VEC_P(tree); (gdb) bt #0 vect_get_vec_defs_for_stmt_copy (dt=0x7fff713d44c0, vec_oprnds0=0x7fff713d44b8, vec_oprnds1=0x7fff713d44b0) at ../../../trunk/gcc/tree.h:210 #1 0x00aacca6 in vectorizable_operation (stmt=0x2ac339ca5600, bsi=0x7fff713d4660, vec_stmt=0x7fff713d4528, slp_node=0x0) at ../../../trunk/gcc/tree-vect-transform.c:3987 #2 0x00ab95d4 in vect_transform_stmt (stmt=0x2ac339ca5600, bsi=0x7fff713d4660, strided_store=0x7fff713d46cf "", slp_node=0x0) at ../../../trunk/gcc/tree-vect-transform.c:6095 #3 0x00aba733 in vect_transform_loop (loop_vinfo=0x1091460) at ../../../trunk/gcc/tree-vect-transform.c:7334 #4 0x0080c28e in vectorize_loops () at ../../../trunk/gcc/tree-vectorizer.c:2507 #5 0x0064e261 in execute_one_pass (pass=0xe22180) at ../../../trunk/gcc/passes.c:1115 #6 0x0064e440 in execute_pass_list (pass=0xe22180) at ../../../trunk/gcc/passes.c:1168 #7 0x0064e455 in execute_pass_list (pass=0xe21fa0) at ../../../trunk/gcc/passes.c:1169 #8 0x0064e455 in execute_pass_list (pass=0xe213a0) at ../../../trunk/gcc/passes.c:1169 #9 0x007286e8 in tree_rest_of_compilation (fndecl=0x2ac339c14340) at ../../../trunk/gcc/tree-optimize.c:404 Reduced testcase is: $ cat foo.f SUBROUTINE DLARRE (W, IBLOCK, WORK) INTEGERM, I INTEGERIBLOCK(*) DOUBLE PRECISION W(*), WORK(*) DO JBLK = 1, 10 DO I = 1, 10 M = M + 1 W(M) = -WORK(I) IBLOCK(M) = 0 END DO END DO END $ gfortran -O2 -ftree-vectorize foo.f foo.f: In function dlarre: foo.f:1: internal compiler error: Segmentation fault -- fxcoudert at gcc dot gnu dot org changed: What|Removed |Added CC||fxcoudert at gcc dot gnu dot ||org Severity|normal |critical Status|UNCONFIRMED |NEW Component|fortran |middle-end Ever Confirmed|0 |1 GCC build triplet||x86_64-linux GCC host triplet|suse-linux-x86_64 |x86_64-linux GCC target triplet||x86_64-linux Keywords||ice-on-valid-code Known to fail||4.3.0 Known to work||4.2.2 Last reconfirmed|-00-00 00:00:00 |2007-09-17 08:39:44 date|| Summary|ice for fortran code with - |[4.3 regression] ICE for |O2 -ftree-vectorize |fortran code with -O2 - ||ftree-vectorize http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33449
[Bug fortran/33446] [4.3 regression] ERROR: gfortran.dg/nint_2.f90 -O0 : syntax error in target selector
--- Comment #2 from fxcoudert at gcc dot gnu dot org 2007-09-17 08:40 --- Yep, this was fixed. Sorry. -- fxcoudert at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33446
[Bug fortran/33445] Diagnose "!$OMP&" as an error in free format unless it is a continuation line
--- Comment #6 from burnus at gcc dot gnu dot org 2007-09-17 08:53 --- Jakub Jelinek wrote (in PR 33439, but seemingly regarding this PR): > Pedantically this is not a bug. If an omp sentinel doesn't have the desired > form, it should be handled as a normal comment. As the preceeding line > doesn't end with &, then !$omp& is not a valid omp sentinel (as !$omp needs to > be followed by a space) and thus it is the same as say > ! $ omp & something > That said, perhaps we could issue some diagnostics, because it is likely > a user error rather than intent. As this PR shows, this user error happens easily, if one converts a fixed-form into a free-form code. Thus I'm in favour of printing a warning or - as ifort and sunf95 do - an error. -- burnus at gcc dot gnu dot org changed: What|Removed |Added Status|WAITING |NEW Last reconfirmed|2007-09-17 06:55:32 |2007-09-17 08:53:10 date|| Summary|openmp invalid multi-thread |Diagnose "!$OMP&" as an |runtime result (-ffree-form |error in free format unless |only!) |it is a continuation line http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33445
[Bug middle-end/33449] [4.3 regression] ICE for fortran code with -O2 -ftree-vectorize
--- Comment #4 from irar at il dot ibm dot com 2007-09-17 08:59 --- (In reply to comment #3) > I can reproduce that on x86_64-linux with trunk rev. 128442. Dorit's fix is revision 128514, so it is not supposed to work on 128442... Anyway, I am trying to reproduce this ICE on x86_64-linux now, with the current trunk (128538). Ira -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33449
[Bug inline-asm/33451] Collapsing of offsetable memory operands.
--- Comment #1 from rguenth at gcc dot gnu dot org 2007-09-17 09:05 --- Please provide a complete testcase that shows the failure. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33451
[Bug middle-end/33449] [4.3 regression] ICE for fortran code with -O2 -ftree-vectorize
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||pinskia at gcc dot gnu dot ||org Severity|critical|normal Target Milestone|--- |4.3.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33449
[Bug tree-optimization/33453] ICE in build2_stat, at tree.c:3110 with -ftree-parallelize-loops=4 -ftree-vectorize
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-09-17 09:14 --- This is related to pointer plus. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||pinskia at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33453
[Bug fortran/33363] gfortran is missing -fcase-preserve option
-- 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 |2007-09-17 09:26:37 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33363
[Bug fortran/33375] [4.3 Regression] ICE (segfault) gfortran.dg/common_6.f90
-- 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 |2007-09-17 09:27:20 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33375
[Bug fortran/33408] ICE: tree check: expected type_decl, have in debug_flush_symbol_queue, at final.c:3986
--- Comment #5 from fxcoudert at gcc dot gnu dot org 2007-09-17 09:33 --- On x86_64-linux, when f951 (both with -m32 and -m64) is run under valgrind, I get a short series of invalid read beginning with: ==1628== Invalid read of size 1 ==1628==at 0xAEA1F0: htab_hash_string (hashtab.c:812) ==1628==by 0x5335DD: lookup_filename (dwarf2out.c:14042) ==1628==by 0x534D1C: dwarf2out_source_line (dwarf2out.c:14159) ==1628==by 0x534F41: dwarf2out_begin_prologue (dwarf2out.c:2626) ==1628==by 0x58F6BF: final_start_function (final.c:1443) ==1628==by 0x591E36: rest_of_handle_final (final.c:4048) ==1628==by 0x64E260: execute_one_pass (passes.c:1115) ==1628==by 0x64E43F: execute_pass_list (passes.c:1168) ==1628==by 0x64E454: execute_pass_list (passes.c:1169) ==1628==by 0x64E454: execute_pass_list (passes.c:1169) ==1628==by 0x7286E7: tree_rest_of_compilation (tree-optimize.c:404) ==1628==by 0x8983E3: cgraph_expand_function (cgraphunit.c:1070) ==1628== Address 0x4DC7820 is 0 bytes inside a block of size 4 free'd ==1628==at 0x4A1B46D: free (vg_replace_malloc.c:233) ==1628==by 0x461166: preprocessor_line (scanner.c:1304) ==1628==by 0x462084: load_file (scanner.c:1496) ==1628==by 0x462314: gfc_new_file (scanner.c:1556) ==1628==by 0x477922: gfc_init (f95-lang.c:288) ==1628==by 0x6CEC89: toplev_main (toplev.c:2124) ==1628==by 0x4B3B4C9: (below main) (in /usr/lib/debug/libc-2.3.6.so) ==1628== -- 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 |2007-09-17 09:33:47 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33408
[Bug tree-optimization/33319] [4.2/4.3 regression] g++.dg/tree-ssa/pr27549.C ICE with vectorization
--- Comment #2 from victork at gcc dot gnu dot org 2007-09-17 09:37 --- Subject: Bug 33319 Author: victork Date: Mon Sep 17 09:37:31 2007 New Revision: 128539 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=128539 Log: PR tree-optimization/33319 * tree-vect-analyze.c (vect_same_range_drs): New. (vect_vfa_range_equal): New. (vect_is_duplicate_ddr): Removed. (vect_mark_for_runtime_alias_test): Do not perform marking when optimizing for size or max_param for alias checking is zero. Move the function before vect_analyze_data_ref_dependence. (vect_analyze_data_ref_dependence): Add call to vect_mark_for_runtime_alias_test in two cases when dependence is not clear. (vect_analyze_data_ref_dependences): Do not call to vect_mark_for_runtime_alias_test. (vect_prune_runtime_alias_test_list): New. (vect_analyze_loop): Add call to vect_prune_runtime_alias_test_list. * tree-vect-transform.c (vect_estimate_min_profitable_iters): Update vec_outside_cost. (vect_vfa_segment_size): More compact code, use TYPE_SIZE_UNIT. (vect_create_cond_for_alias_checks): Build the base address of data reference from DR_GROUP_FIRST_DR. (vect_loop_versioning): New. (vect_transform_loop): Add a call to vect_loop_versioning. Remove factored out code. Modified: trunk/gcc/ChangeLog trunk/gcc/tree-vect-analyze.c trunk/gcc/tree-vect-transform.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33319
[Bug ada/33454] New: Wrong system.ads for --with-cpu=default32
/tmp/cvs/gcc-20070916/Build/./gcc/xgcc -B/tmp/cvs/gcc-20070916/Build/./gcc/ -B/tmp/cvs/gcc-20070916/Build/root/powerpc64-suse-linux/bin/ -B/tmp/cvs/gcc-20070916/Build/root/powerpc64-suse-linux/lib/ -isystem /tmp/cvs/gcc-20070916/Build/root/powerpc64-suse-linux/include -isystem /tmp/cvs/gcc-20070916/Build/root/powerpc64-suse-linux/sys-include -c -g -O2 -fPIC -mno-minimal-toc -W -Wall -gnatpg a-direct.adb -o a-direct.o a-direct.adb:661:13: warning: types for unchecked conversion have different sizes make[7]: *** [a-direct.o] Error 1 The compiler was configured as ../configure --prefix=/tmp/cvs/gcc-20070916/Build/root --build=powerpc64-suse-linux --host=powerpc64-suse-linux --enable-shared --enable-threads --enable-__cxa_atexit --with-system-zlib --with-cpu=default32 --enable-secureplt --with-long-double-128 -- Summary: Wrong system.ads for --with-cpu=default32 Product: gcc Version: 4.3.0 Status: UNCONFIRMED Keywords: build Severity: normal Priority: P3 Component: ada AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: schwab at suse dot de GCC target triplet: powerpc64-suse-linux http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33454
[Bug middle-end/33449] [4.3 regression] ICE for fortran code with -O2 -ftree-vectorize
--- Comment #5 from irar at il dot ibm dot com 2007-09-17 09:54 --- (In reply to comment #4) > Anyway, I am trying to reproduce this ICE on x86_64-linux now, with the > current > trunk (128538). It doesn't ICE for me. (The loop gets vectorized). Ira -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33449
[Bug bootstrap/27794] stack explosion
--- Comment #7 from kari-matti dot pulkkinen at comptel dot com 2007-09-17 10:01 --- Got the same error with 4.2.1: /temp/cpt2k4p/gcc/HP-UXita/./gcc/xgcc -B/temp/cpt2k4p/gcc/HP-UXita/./gcc/ -B/vobs/prod/tools/gnu/gcc/HP-UXita/ia64-hp-hpux11.23/bin/ -B/vobs/prod/tools/gnu/gcc/HP-UXita/ia64-hp-hpux11.23/lib/ -isystem /vobs/prod/tools/gnu/gcc/HP-UXita/ia64-hp-hpux11.23/include -isystem /vobs/prod/tools/gnu/gcc/HP-UXita/ia64-hp-hpux11.23/sys-include -O2 -O2 -O -DIN_GCC-DUSE_LIBUNWIND_EXCEPTIONS -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition -isystem ./include -g -DHAVE_GTHR_DEFAULT -DIN_LIBGCC2 -D__GCC_FLOAT_NOT_NEEDED -I. -I. -I/temp/cpt2k4p/gcc/gcc-4.2.1/gcc -I/temp/cpt2k4p/gcc/gcc-4.2.1/gcc/. -I/temp/cpt2k4p/gcc/gcc-4.2.1/gcc/../include -I/temp/cpt2k4p/gcc/gcc-4.2.1/gcc/../libcpp/include -I/temp/cpt2k4p/gcc/gcc-4.2.1/gcc/../libdecnumber -I../libdecnumber -mlp64 -DL__divxf3 -xassembler-with-cpp -c /temp/cpt2k4p/gcc/gcc-4.2.1/gcc/config/ia64/lib1funcs.asm -o libgcc/hpux64/__divxf3.o Pid 5685 received a SIGSEGV for stack growth failure. Possible causes: insufficient memory or swap space, or stack size exceeded maxssiz. make[4]: *** [libgcc/hpux64/__divxf3.o] Segmentation fault (core dumped) make[4]: Leaving directory `/net/nfs1/temp/cpt2k4p/gcc/HP-UXita/gcc' make[3]: *** [stmp-multilib] Error 2 make[3]: Leaving directory `/net/nfs1/temp/cpt2k4p/gcc/HP-UXita/gcc' make[2]: *** [all-stage1-gcc] Error 2 make[2]: Leaving directory `/net/nfs1/temp/cpt2k4p/gcc/HP-UXita' make[1]: *** [stage1-bubble] Error 2 make[1]: Leaving directory `/net/nfs1/temp/cpt2k4p/gcc/HP-UXita' make: *** [bootstrap] Error 2 [EMAIL PROTECTED]> /usr/sbin/swapinfo Kb Kb Kb PCT START/ Kb TYPE AVAILUSEDFREE USED LIMIT RESERVE PRI NAME dev 16384000 2405588 13978412 15% 0 -1 /dev/vg00/lvol2 reserve - 7281752 -7281752 memory 16768512 4921188 11847324 29% [EMAIL PROTECTED]> grep maxssiz /stand/system tunable maxssiz 268434356 tunable maxssiz_64bit 2147483648 [EMAIL PROTECTED]> Managed to compile OK with AIX 5.3, Solaris 10 and HP-UX 11.11 -- kari-matti dot pulkkinen at comptel dot com changed: What|Removed |Added CC||kari-matti dot pulkkinen at ||comptel dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27794
[Bug libfortran/21185] Improve testsuite results on newlib targets
--- Comment #24 from fxcoudert at gcc dot gnu dot org 2007-09-17 10:16 --- I'm making this a meta-bug to monitor our improvement on newlib targets. -- fxcoudert at gcc dot gnu dot org changed: What|Removed |Added URL|http://gcc.gnu.org/ml/gcc- | |patches/2007- | |09/msg01219.html| Severity|enhancement |minor Keywords|patch |meta-bug Priority|P2 |P3 Summary|libgfortran unusable for|Improve testsuite results on |cross-testing for newlib|newlib targets |targets | Version|4.1.0 |4.3.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21185
Re: [Bug target/33431] New: [SH4] performance regression between 3.4.6 and 4.x
nbkolchin at gmail dot com wrote: Our target hardware has SH7750 processor running in little endian mode under RTEMS. Unfortunetaly there is no way to boot linux there. After lurking inside backend sources, I found that m4 has several variants in GCC 4.x: m4-100, m4-200, etc. I've tried to compile this tests with m4-200 switch, but it looks like m4-200 enforces big-endian. The 7750 has direct mapped caches and so is not the best platform for benchmarking. A slight code perturbation can give a large change in performance. :( The m4-200 option is NOT suitable for that target. The 7750 is a 100 series core (not that that was a nomenclature that existed when it came out). As far as I know, anybody that has a 200 series or above has an official ST toolset to go with it (GCC of course). Andrew
[Bug target/33431] [SH4] performance regression between 3.4.6 and 4.x
--- Comment #5 from andrew dot stubbs at st dot com 2007-09-17 10:30 --- Subject: Re: New: [SH4] performance regression between 3.4.6 and 4.x nbkolchin at gmail dot com wrote: > Our target hardware has SH7750 processor running in little endian mode under > RTEMS. Unfortunetaly there is no way to boot linux there. > > After lurking inside backend sources, I found that m4 has several variants in > GCC 4.x: m4-100, m4-200, etc. I've tried to compile this tests with m4-200 > switch, but it looks like m4-200 enforces big-endian. The 7750 has direct mapped caches and so is not the best platform for benchmarking. A slight code perturbation can give a large change in performance. :( The m4-200 option is NOT suitable for that target. The 7750 is a 100 series core (not that that was a nomenclature that existed when it came out). As far as I know, anybody that has a 200 series or above has an official ST toolset to go with it (GCC of course). Andrew -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33431
[Bug middle-end/33449] [4.3 regression] ICE for fortran code with -O2 -ftree-vectorize
--- Comment #6 from fxcoudert at gcc dot gnu dot org 2007-09-17 10:42 --- Subject: Bug 33449 Author: fxcoudert Date: Mon Sep 17 10:42:29 2007 New Revision: 128543 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=128543 Log: PR middle-end/33449 * gfortran.dg/pr33449.f90: New test. Added: trunk/gcc/testsuite/gfortran.dg/pr33449.f90 Modified: trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33449
[Bug middle-end/33449] [4.3 regression] ICE for fortran code with -O2 -ftree-vectorize
--- Comment #7 from fxcoudert at gcc dot gnu dot org 2007-09-17 10:42 --- Closing the bug, after adding a reduced testcase to the testsuite. -- fxcoudert at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33449
[Bug tree-optimization/33453] ICE in build2_stat, at tree.c:3110 with -ftree-parallelize-loops=4 -ftree-vectorize
--- Comment #2 from rguenth at gcc dot gnu dot org 2007-09-17 11:03 --- Confirmed. Looks like we try to build a multiplication with ptr * int: (gdb) bt #0 fancy_abort ( file=0xf27848 "/space/rguenther/src/svn/pointer_plus/gcc/tree.c", line=3110, function=0xf291bf "build2_stat") at /space/rguenther/src/svn/pointer_plus/gcc/diagnostic.c:655 #1 0x00a98052 in build2_stat (code=MULT_EXPR, tt=0x2ad7bec23750, arg0=0x2ad7bec6ae40, arg1=0x2ad7bec638d0) at /space/rguenther/src/svn/pointer_plus/gcc/tree.c:3110 #2 0x006d8a51 in fold_build2_stat (code=MULT_EXPR, type=0x2ad7bec23750, op0=0x2ad7bec6ae40, op1=0x2ad7bec638d0) at /space/rguenther/src/svn/pointer_plus/gcc/fold-const.c:13452 #3 0x006a130c in fold_binary (code=MULT_EXPR, type=0x2ad7bec23750, op0=0x2ad7bec638d0, op1=0x2ad7bec6ae40) at /space/rguenther/src/svn/pointer_plus/gcc/fold-const.c:9464 #4 0x006d8a32 in fold_build2_stat (code=MULT_EXPR, type=0x2ad7bec23750, op0=0x2ad7bec638d0, op1=0x2ad7bec6ae40) at /space/rguenther/src/svn/pointer_plus/gcc/fold-const.c:13450 #5 0x008f6544 in canonicalize_loop_ivs (loop=0x2ad7be26bb40, nit=0x2ad7bec5e9c0) 744 fold_build2 (MULT_EXPR, atype, 745 unshare_expr (iv.step), 746 fold_convert (atype, var_before))) -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2007-09-17 11:03:24 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33453
[Bug target/11180] [avr-gcc] Optimization decrease performance of struct assignment.
--- Comment #21 from rask at gcc dot gnu dot org 2007-09-17 11:13 --- It's probably someting simple, see config.log. Like I said, the patch is a quick and dirty one and the AVR back end can use more work than that, most of which means deleting patterns. Examples: All and, ior, xor, one_cmpl and sign extend patterns larger than qimode, all zero_extend patterns, all movsi, movdi and such. Along with that all the output_xxx functions in avr.c that they use. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=11180
[Bug c++/32549] Wrong template instance resolution among multiple object files.
--- Comment #5 from opichals at seznam dot cz 2007-09-17 11:35 --- Yes, I have checked the ODR definition and it is really the fact that the code violates that. Thank you for your explanations. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32549
[Bug other/33357] collect2: ld terminated with signal 11 [Segmentation fault]
--- Comment #4 from nickc at redhat dot com 2007-09-17 12:08 --- Subject: Re: collect2: ld terminated with signal 11 [Segmentation fault] Hi Don, > Thank you both for your replies. I have now built binutils 2.18. > However I'm not root on this machine and so cannot install it in the > place where the original command (g++ -O3 -DDBUG_OFF ...) will find > it. Can either of you tell me how to arrange for the g++ command to > use the version of ld I've just built? There are several possibilities: 1. Build your own local version of g++ as well and install everything in your own local install tree. This might be a good idea if you have other bugs in the compiler or linker that you might want to track down. 2. Compile everything to object files first. Then perform a final link adding "-v" to the gcc command line. This will show you the linker command line that gcc is using. Copy this command line, replacing the name of the linker program with the path to your own, newly built linker. The problem with this approach is that you are using g++. (If you are not compiling C++ sources then switch to gcc and you will not encounter the following problem). The problem is that g++ does not invoke the linker directly. Instead it uses an intermediary program called collect2 which performs some additional work before invoking the linker. This could still be worked around if it were not for the fact that g++ communicates some critical information to collect2 via environment variables rather than the command line. These variables are not shown in the "g++ -v" output and they include the path to the linker that collect2 invokes. [A big design bug imho]. Try adding "--Wl,-debug" to the g++ command line to see some output from collect2. The simplest way around this problem is to still use g++ to perform the final link, but to rename your newly built linker executable to "real-ld" and put it in your PATH somewhere. (I normally use the current directory where I am running my tests). Collect2 should look for an executable called "real-ld" first and if it cannot find one, then use "collect-ld" or "ld" or something else which will probably be in the path given to it by the compiler, and not in a path controllable by you. > I see at least two problems here. First, g++ is not simply calling ld > on the same arguments - when I replace g++ with ld I get an error > about unrecognized option -DDBUG_OFF. > Second, I suspect that the ld I just built is the file > ~/binutils-2.18/ld/ld-new - is that correct? Correct. When the built ld-new executable is installed it is renamed to ld. Cheers Nick -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33357
[Bug tree-optimization/19097] [4.1/4.2/4.3 regression] Quadratic behavior with many sets for the same register in VRP
--- Comment #42 from rguenth at gcc dot gnu dot org 2007-09-17 13:11 --- Still slow. cfg cleanup : 7.10 (10%) usr 0.16 (10%) sys 7.26 (10%) wall 625 kB ( 1%) ggc tree VRP : 27.40 (39%) usr 0.39 (23%) sys 27.91 (38%) wall 7602 kB (11%) ggc CPROP 1 : 12.32 (17%) usr 0.26 (15%) sys 12.58 (17%) wall 1562 kB ( 2%) ggc CPROP 2 : 8.79 (12%) usr 0.20 (12%) sys 9.03 (12%) wall 1406 kB ( 2%) ggc bypass jumps : 8.73 (12%) usr 0.20 (12%) sys 8.96 (12%) wall 1406 kB ( 2%) ggc TOTAL : 70.94 1.6873.05 71071 kB -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Last reconfirmed|2005-10-31 17:12:20 |2007-09-17 13:11:02 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19097
[Bug target/33406] [4.3 Regression] At revision 128385 Bootstraping PPC Darwin still fail in Java
--- Comment #11 from dominiq at lps dot ens dot fr 2007-09-17 13:59 --- Subject: Re: [4.3 Regression] At revision 128385 Bootstraping PPC Darwin still fail in Java Did you try to bootstrap with Java with the one line patch in: http://gcc.gnu.org/ml/gcc-bugs/2007-09/msg01311.html It fixes the Fortran failure. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33406
[Bug middle-end/33348] [4.3 Regression] gfortran.dg/g77/19990826-3.f fails at -O1
--- Comment #5 from howarth at nitro dot med dot uc dot edu 2007-09-17 14:52 --- On powerpc-apple-darwin9, the patch Zdenek is checking in... http://gcc.gnu.org/ml/gcc-patches/2007-09/msg01380.html suppresses the build problems in Java... http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33406 on powerpc-apple-darwin9. Zdenek thought your patch was the true fix to the Java build problem and its suppression with his patch was a side-effect. Honza, you might want to get you changes in before Zdenek checks in just in case it suppresses this PR as well (making it impossible to test). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33348
[Bug middle-end/33348] [4.3 Regression] gfortran.dg/g77/19990826-3.f fails at -O1
--- Comment #6 from howarth at nitro dot med dot uc dot edu 2007-09-17 14:57 --- To clarify, what I meant to say in the above comment was that I am concerned if Zdenek's patch may convert this PR into a latent bug. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33348
[Bug middle-end/33348] [4.3 Regression] gfortran.dg/g77/19990826-3.f fails at -O1
--- Comment #7 from hubicka at gcc dot gnu dot org 2007-09-17 15:12 --- Subject: Bug 33348 Author: hubicka Date: Mon Sep 17 15:12:10 2007 New Revision: 128547 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=128547 Log: PR middle-end/33348 PR target/33406 * loop-invariant.c (move_invariant_reg): Unshare sequence. Modified: trunk/gcc/ChangeLog trunk/gcc/loop-invariant.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33348
[Bug target/33406] [4.3 Regression] At revision 128385 Bootstraping PPC Darwin still fail in Java
--- Comment #12 from hubicka at gcc dot gnu dot org 2007-09-17 15:12 --- Subject: Bug 33406 Author: hubicka Date: Mon Sep 17 15:12:10 2007 New Revision: 128547 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=128547 Log: PR middle-end/33348 PR target/33406 * loop-invariant.c (move_invariant_reg): Unshare sequence. Modified: trunk/gcc/ChangeLog trunk/gcc/loop-invariant.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33406
[Bug fortran/33408] ICE: tree check: expected type_decl, have in debug_flush_symbol_queue, at final.c:3986
--- Comment #6 from burnus at gcc dot gnu dot org 2007-09-17 15:26 --- > On x86_64-linux, when f951 (both with -m32 and -m64) is run under valgrind, I > get a short series of invalid read beginning with: FX, which version of gfortran are you using? I cannot reproduce it (with valgrind) under x86_64-openSUSE-10.3b3 with today's gfortran 4.3 (Rev. 128538) - neither for -m32 nor -m64. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33408
[Bug fortran/33090] Unable to build on AIX 4.3.3
--- Comment #3 from fxcoudert at gcc dot gnu dot org 2007-09-17 15:43 --- Closing, please reopen when you get time to rebuild and post the error. -- fxcoudert at gcc dot gnu dot org changed: What|Removed |Added Status|WAITING |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33090
[Bug fortran/33106] Access of components of public entities of private types wrongly allowed
--- Comment #9 from burnus at gcc dot gnu dot org 2007-09-17 15:55 --- Subject: Bug 33106 Author: burnus Date: Mon Sep 17 15:55:22 2007 New Revision: 128550 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=128550 Log: 2007-09-17 Tobias Burnus <[EMAIL PROTECTED]> PR fortran/33106 * resolve.c (resolve_symbol): Reject public variable of private derived-types for Fortran 95. 2007-09-17 Tobias Burnus <[EMAIL PROTECTED]> PR fortran/33106 * gfortran.dg/private_type_9.f90: New. Added: trunk/gcc/testsuite/gfortran.dg/private_type_9.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/resolve.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33106
[Bug fortran/33106] Access of components of public entities of private types wrongly allowed
--- Comment #10 from burnus at gcc dot gnu dot org 2007-09-17 15:56 --- FIXED on the trunk (4.3.0). -- 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=33106
[Bug rtl-optimization/26449] [4.2/4.3 Regression] ICE in loop invariant motion
--- Comment #21 from rakdver at gcc dot gnu dot org 2007-09-17 15:39 --- Subject: Bug 26449 Author: rakdver Date: Mon Sep 17 15:38:48 2007 New Revision: 128549 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=128549 Log: PR rtl-optimization/26449 * loop-invariant.c (move_invariant_reg): Do not use force_operand. (seq_insns_valid_p): Removed. Modified: trunk/gcc/ChangeLog trunk/gcc/loop-invariant.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26449
[Bug fortran/33037] TRANSFER should warn on mismatched sizes
--- Comment #5 from burnus at gcc dot gnu dot org 2007-09-17 16:29 ---
Simple patch; catches if result size > source size (cf. example in bug 31610
comment 0). However, it does not catch if result size < LHS variable. (Example
in this PR.)
Index: simplify.c
===
--- simplify.c (Revision 128550)
+++ simplify.c (Arbeitskopie)
@@ -4059,6 +4059,11 @@
result_size = result_elt_size;
}
+ if (source_size < result_size)
+gfc_warning("Intrinsic TRANSFER at %L has partly undefined result: source
"
+ "size %ld < result size %ld", &source->where,
+ (long) source_size, (long) result_size);
+
/* Allocate the buffer to store the binary version of the source. */
buffer_size = MAX (source_size, result_size);
buffer = (unsigned char*)alloca (buffer_size);
--
burnus at gcc dot gnu dot org changed:
What|Removed |Added
CC||burnus at gcc dot gnu dot
||org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33037
[Bug rtl-optimization/26449] [4.2 Regression] ICE in loop invariant motion
--- Comment #22 from ubizjak at gmail dot com 2007-09-17 16:43 --- Fixed in mainline, still (latent) present on 4.2. -- ubizjak at gmail dot com changed: What|Removed |Added Known to work||4.3.0 Summary|[4.2/4.3 Regression] ICE in |[4.2 Regression] ICE in loop |loop invariant motion |invariant motion http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26449
[Bug other/33357] collect2: ld terminated with signal 11 [Segmentation fault]
--- Comment #5 from don-gcc at isis dot cs3-inc dot com 2007-09-17 16:31
---
Subject: Re: collect2: ld terminated with signal 11 [Segmentation fault]
Nick Clifton writes:
> There are several possibilities:
...
I ended up following the recommendation below - worked fine.
I installed the binutils build into my own directory and then added
the -B. In fact I just added that to the input I passed to .configure
and the entire mysql build completed without problem.
--- Comment #3 from schwab at suse dot de 2007-09-09 08:09 ---
Use -B${binutils-bindir}, where ${binutils-bindir} is the directory where the
binutils binaries were installed. `-BPREFIX' This option specifies where
to find the executables, libraries, include files, and data files of the
compiler itself. The compiler driver program runs one or more of the
subprograms `cpp', `cc1', `as' and `ld'. It tries PREFIX as a prefix for
each program it tries to run, both with and without `MACHINE/VERSION/'
(*note Target Options::).
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33357
[Bug c++/33378] [4.3 regression] Recent gcc 4.3 snapshots think comparison operators are ambiguous
--- Comment #2 from pcarlini at suse dot de 2007-09-17 17:22 --- I can't reproduce the problem with current (128551) mainline. Likely a transient issue, otherwise, please reopen. -- pcarlini at suse dot de changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||WORKSFORME http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33378
[Bug fortran/33455] New: MERGE intrinsic: Check for same string lengths
See 31610 for another example.
"13.7.75 MERGE (TSOURCE, FSOURCE, MASK)"
"FSOURCE shall be of the same type and type parameters as TSOURCE."
NAG f95:
Error: merge_char_3.f90, line 4: Unequal character lengths (2 and 3) in MERGE
intrinsic
Error: merge_char_3.f90, line 5: Unequal character lengths (2 and 3) in MERGE
intrinsic
implicit none
character(len=2) :: a
character(len=3) :: b
print *, merge(a,b,.true.) ! { dg-error "Unequal character lengths" }
print *, merge('aa','bbb',.true.) ! { dg-error "Unequal character lengths" }
end
First version of a patch follows. However, it does not detect the second
transfer as for 'aa' expr->ts.cl->length etc. is not set, but only
expr->value.character.length (cf. match_string_constant). (Note: setting cl.*
in
match_string_constant does not completely work: In
gfortran.dg/char_length_1.f90 the warning for line 12 and 14 is then
suppressed.)
Index: check.c
===
--- check.c (Revision 128550)
+++ check.c (Arbeitskopie)
@@ -1820,6 +1820,23 @@
if (same_type_check (tsource, 0, fsource, 1) == FAILURE)
return FAILURE;
+ /* In case of characters, the string lengths need to match. */
+ if (tsource->ts.type == BT_CHARACTER && tsource->ts.cl
+ && tsource->ts.cl->length && fsource->ts.cl && fsource->ts.cl->length
+ && tsource->ts.cl->length->expr_type == EXPR_CONSTANT
+ && fsource->ts.cl->length->expr_type == EXPR_CONSTANT
+ && mpz_cmp (tsource->ts.cl->length->value.integer,
+ fsource->ts.cl->length->value.integer) != 0)
+{
+ gfc_error ("Unequal character lengths (%ld and %ld) in MERGE "
+"intrinsic at %L",
+mpz_get_si (tsource->ts.cl->length->value.integer),
+mpz_get_si (fsource->ts.cl->length->value.integer),
+&tsource->where);
+ return FAILURE;
+}
+
+
if (type_check (mask, 2, BT_LOGICAL) == FAILURE)
return FAILURE;
In case some one is interested in the match_string_constant change (which
causes the warn regression), here it comes:
Index: primary.c
===
--- primary.c (Revision 128550)
+++ primary.c (Arbeitskopie)
@@ -946,6 +946,8 @@ got_delim:
e->value.character.string = p = gfc_getmem (length + 1);
e->value.character.length = length;
+ e->ts.cl = gfc_get_charlen ();
+ e->ts.cl->length = gfc_int_expr (length);
gfc_current_locus = start_locus;
gfc_next_char ();/* Skip delimiter */
--
Summary: MERGE intrinsic: Check for same string lengths
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
Keywords: accepts-invalid
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=33455
[Bug tree-optimization/33361] ICE in find_outermost_region_in_block, at tree-cfg.c:4803
--- Comment #6 from gcc at abeckmann dot de 2007-09-17 17:35 --- Created an attachment (id=14216) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14216&action=view) minimal testcase The ICE only occurs with -O3 and above. $ /suse/NOBACKUP/gcc/gcc-4.2-branch/bin/g++ -v -O3 -fopenmp -c PR33361.min.ii Using built-in specs. Target: i686-pc-linux-gnu Configured with: ../gcc-4_2-branch/configure --enable-languages=c,c++ --prefix=/suse/NOBACKUP/gcc/gcc-4.2-branch Thread model: posix gcc version 4.2.2 20070910 (prerelease) /suse/NOBACKUP/gcc/gcc-4.2-branch/libexec/gcc/i686-pc-linux-gnu/4.2.2/cc1plus -fpreprocessed PR33361.min.ii -quiet -dumpbase PR33361.min.ii -mtune=generic -auxbase PR33361.min -O3 -version -fopenmp -o /tmp/ccdvfpMn.s GNU C++ version 4.2.2 20070910 (prerelease) (i686-pc-linux-gnu) compiled by GNU C version 4.2.2 20070908 (prerelease). GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072 Compiler executable checksum: 4c766e638e42be49e7fc1a3400590598 PR33361.min.ii: In function void f(): PR33361.min.ii:25: internal compiler error: in find_outermost_region_in_block, at tree-cfg.c:4803 -- gcc at abeckmann dot de changed: What|Removed |Added Attachment #14177|0 |1 is obsolete|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33361
[Bug web/31599] Online gcc doc page is blank - no Attribute-Syntax.html
--- Comment #2 from manu at gcc dot gnu dot org 2007-09-17 17:32 --- I think Andrew is right. If you think that this is still an issue, please reopen. -- manu at gcc dot gnu dot org changed: What|Removed |Added CC||manu at gcc dot gnu dot org Status|WAITING |RESOLVED Resolution||WORKSFORME http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31599
[Bug fortran/31610] ICE with transfer, merge in gfc_conv_expr_descriptor
--- Comment #10 from burnus at gcc dot gnu dot org 2007-09-17 17:39 ---
For the warning that TRANSFER contains partially undefined values, see also PR
33037. For MERGE, see PR 33455
Independent of those, the following valid program still gives an ICE (if one
removes the "20" in transfer, the ICE is gone). Also the patch
http://gcc.gnu.org/ml/gcc-patches/2007-05/msg01953.html does not seem to help.
character(len=20) :: string
logical :: a(20)
a = .true.
write(*,*) transfer (merge (transfer(REPEAT("A",20), "x", 20), "b", a), string
)
end
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31610
[Bug web/32927] Online installation instructions only for mainline
--- Comment #4 from manu at gcc dot gnu dot org 2007-09-17 17:56 --- I think this is confirmed as a feature that would be nice to have. So the install instructions should behave like the OpenMP manual here http://gcc.gnu.org/onlinedocs/ and we will end up with: http://gcc.gnu.org/install/ for the current development version and http://gcc.gnu.org/install/gcc-4.2.0/ for GCC 4.2.0 as released. I guess this will require to adjust a few shell scripts and perhaps adjust a few webpages. Contributors are welcome. -- manu at gcc dot gnu dot org changed: What|Removed |Added CC||manu at gcc dot gnu dot org Severity|normal |enhancement Status|WAITING |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2007-09-17 17:56:57 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32927
[Bug ada/33457] New: Renaming in context of ragged array
The object renaming does not behave properly as demonstrated with the test
codes below. Note that line 11 of message_services.adb contains the problem. In
addition, if line 11 is commented out and line 12 in uncommented, the codes
behave properly.
package Message_Services is
type Message_Code is range 0 .. 100;
subtype Message is String;
function Get_Message (Code : Message_Code) return String;
pragma Inline (Get_Message);
end Message_Services;
package body Message_Services is
type Message_Handle is access constant Message;
Message_0 : aliased constant Message := "OK";
Message_1 : aliased constant Message := "Up";
Message_2 : aliased constant Message := "Down";
Message_3 : aliased constant Message := "Left";
Message_4 : aliased constant Message := "Right";
-- ...
Default : Message renames Message_0; -- bug here
-- Default : aliased constant Message := Message_0; -- work around
Message_Table : array (Message_Code) of Message_Handle := (
000 => Message_0'access,
001 => Message_1'access,
002 => Message_2'access,
003 => Message_3'access,
004 => Message_4'access,
others => Default'access);
function Get_Message (Code : Message_Code) return String is
begin
return Message_Table (Code).all;
end Get_Message;
end Message_Services;
with Ada.Text_IO;
procedure Message_Services.Test is
use Ada;
use Text_IO;
Test_Message : constant Message := "OK";
begin
Put_Line ("Static Ragged Array construction, no heap involvement");
for Index in Message_Code range 0 .. 9 loop
Put_Line ("Message" & Message_Code'Image (Index) & " is: " &
Get_Message (Index));
end loop;
for Index in Message_Code range 5 .. 9 loop
if Get_Message (Index) /= Test_Message then
Put_Line ("Test fails");
return;
end if;
end loop;
Put_Line ("Test passes");
end Message_Services.Test;
--
Summary: Renaming in context of ragged array
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: ada
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: anhvofrcaus at gmail dot com
GCC build triplet: gcc-4.3-20070914
GCC host triplet: Red Hat i686
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33457
[Bug ada/33454] Wrong system.ads for --with-cpu=default32
--- Comment #1 from rguenth at gcc dot gnu dot org 2007-09-17 19:05 --- Confirmed. Reverting r127960 helps. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added CC||rguenth at gcc dot gnu dot ||org Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2007-09-17 19:05:46 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33454
[Bug ada/33454] [4.3 Regression] Wrong system.ads for --with-cpu=default32
-- rguenth at gcc dot gnu dot org changed: What|Removed |Added Severity|normal |blocker Summary|Wrong system.ads for --with-|[4.3 Regression] Wrong |cpu=default32 |system.ads for --with- ||cpu=default32 Target Milestone|--- |4.3.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33454
[Bug c++/29018] empty enum accepted
--- Comment #10 from pcarlini at suse dot de 2007-09-17 19:18 --- Not actively working on it (for now) -- pcarlini at suse dot de changed: What|Removed |Added AssignedTo|pcarlini at suse dot de |unassigned at gcc dot gnu ||dot org Status|ASSIGNED|NEW http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29018
[Bug fortran/33456] Vendor extension: Use env. var. to set filename of preconnect unit
--- Comment #1 from kargl at gcc dot gnu dot org 2007-09-17 19:22 --- I would strongly discourage adding this feature. A long time ago, either Paul Brook or Steven Bosscher and I exchanged email about the use of environmental variables to control various aspects of gfortran. In the end, I recall that we agreed a proliferation of environmental variables could lead to a maintenance nightmare. But, as usual if someone implements the feature, I won't stand in the way. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33456
[Bug fortran/33456] New: Vendor extension: Use env. var. to set filename of preconnect unit
Some vendors seemingly offer to set the filename of a pre-connected unit via an environment variable. I'm not sure we need this, but some other compilers seem to have it and it is seemingly used: http://groups.google.com/group/comp.lang.fortran/browse_thread/thread/16d2c1d82a05edb4 -- Summary: Vendor extension: Use env. var. to set filename of preconnect unit Product: gcc Version: 4.3.0 Status: UNCONFIRMED Severity: enhancement Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: burnus at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33456
[Bug gcov-profile/23334] FIXME in coverage.c: use build_constructor directly
--- Comment #3 from rguenth at gcc dot gnu dot org 2007-09-17 20:07 --- They're still there, but obviously no longer 4.3 material. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added OtherBugsDependingO|28177 | nThis|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23334
[Bug rtl-optimization/20211] autoincrement generation is poor
--- Comment #37 from rguenth at gcc dot gnu dot org 2007-09-17 20:06 --- No 4.3 pending patch anymore. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added OtherBugsDependingO|28177 | nThis|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20211
[Bug middle-end/24429] Remove unnecessary lhd_* hooks where a corresponding hook_* exists
--- Comment #4 from rguenth at gcc dot gnu dot org 2007-09-17 20:09 --- Queued for 4.4!? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24429
[Bug tree-optimization/33458] New: [4.3 regression] ICE "PHI def is not a GIMPLE value"
The following valid testcase triggers an ICE on mainline
when compiled with "-O":
===
inline void foo(int* p, int n)
{
for (; n > 0; --n, ++p)
*p = 0;
}
struct A
{
int x[2];
A() { foo(x, 2); }
};
inline A getA() { return A(); }
struct B
{
A a;
B();
};
B::B() : a(getA()) {}
===
bug.cc: In constructor 'B::B()':
bug.cc:20: error: PHI def is not a GIMPLE value
p_2 = PHI <&this_1(D)->a.x[0](2), p_5(3)>
&this_1(D)->a.x[0];
bug.cc:20: internal compiler error: verify_stmts failed
Please submit a full bug report, [etc.]
The regression was introduced between 2007-06-23 an 2007-07-02.
--
Summary: [4.3 regression] ICE "PHI def is not a GIMPLE value"
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
Keywords: ice-on-valid-code, monitored
Severity: normal
Priority: P3
Component: tree-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: reichelt at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33458
[Bug c++/33459] [4.2/4.3 regression] ICE on reference member in union
-- reichelt at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|--- |4.2.2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33459
[Bug tree-optimization/33458] [4.3 regression] ICE "PHI def is not a GIMPLE value"
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-09-17 21:56 --- Confirmed, inlining and RVO and RSO are interacting together interestingly. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||hubicka at gcc dot gnu dot ||org Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2007-09-17 21:56:36 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33458
[Bug c++/33460] New: [4.1/4.2/4.3 regression] ICE with static member in anonymous union
The following invalid testcase triggers an ICE since GCC 3.0:
===
struct A
{
struct
{
struct { static int i; };
void foo() { i; }
};
};
===
bug.cc:5: error: 'int A::i' invalid; an
anonymous struct can only have non-static data members
bug.cc:4: error: an anonymous union cannot have function members
bug.cc: In member function 'void Afoo()':
bug.cc:6: internal compiler error: Segmentation fault
Please submit a full bug report, [etc.]
This is similar to PR 30302, but a little more complex.
--
Summary: [4.1/4.2/4.3 regression] ICE with static member in
anonymous union
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
Keywords: ice-on-invalid-code, error-recovery, monitored
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: reichelt at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33460
[Bug c++/33460] [4.1/4.2/4.3 regression] ICE with static member in anonymous union
-- reichelt at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|--- |4.1.3 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33460
[Bug c++/33459] New: [4.2/4.3 regression] ICE on reference member in union
The following invalid testcase triggers an ICE since GCC 4.2.1:
===
union A
{
int &i;
};
void foo()
{
A();
}
===
bug.cc:3: error: 'A::i' may not have reference type 'int&' because it is a
member of a union
bug.cc: In function 'void foo()':
bug.cc:8: internal compiler error: Segmentation fault
Please submit a full bug report, [etc.]
--
Summary: [4.2/4.3 regression] ICE on reference member in union
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
Keywords: ice-on-invalid-code, error-recovery, monitored
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: reichelt at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33459
[Bug middle-end/33423] [4.2/4.3 regression]: internal compiler error: in expand_expr_real_1, at expr.c:8670
--- Comment #9 from jakub at gcc dot gnu dot org 2007-09-17 22:05 --- Subject: Bug 33423 Author: jakub Date: Mon Sep 17 22:05:40 2007 New Revision: 128554 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=128554 Log: PR middle-end/33423 * builtins.c (expand_builtin_memory_chk): Handle COMPOUND_EXPRs returned by build_call_expr. * gcc.c-torture/compile/20070915-1.c: New test. Added: trunk/gcc/testsuite/gcc.c-torture/compile/20070915-1.c Modified: trunk/gcc/ChangeLog trunk/gcc/builtins.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33423
[Bug c++/33461] New: [4.3 regression] ICE with invalid specialization involving parameter packs
The following invalid testcase triggers an ICE on mainline:
===
template struct A;
template struct A
{
struct B;
};
A a;
===
bug.cc:3: error: parameter packs not expanded with `...':
bug.cc:3: note: 'T'
bug.cc:4: error: parameter packs not expanded with `...':
bug.cc:4: note: 'T'
bug.cc: In instantiation of 'A':
bug.cc:8: instantiated from here
bug.cc:5: error: type/value mismatch at argument 1 in template parameter list
for 'template struct A::B'
bug.cc:5: error: expected a type, got ''
bug.cc:5: internal compiler error: tree check: expected class 'type', have
'exceptional' (error_mark) in tsubst_decl, at cp/pt.c:8091
Please submit a full bug report, [etc.]
Replacing "A" by "A" triggers the following ICE:
bug.cc:4: error: cannot expand 'T* ...' into a fixed-length argument list
bug.cc:9: internal compiler error: in unify, at cp/pt.c:12975
Please submit a full bug report, [etc.]
--
Summary: [4.3 regression] ICE with invalid specialization
involving parameter packs
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
Keywords: ice-on-invalid-code, error-recovery, monitored
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: reichelt at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33461
[Bug ada/33457] Renaming in context of ragged array
--- Comment #1 from anhvofrcaus at gmail dot com 2007-09-17 22:13 --- Sorry for the typo in problem description paragraph. What I mean was if line 11 commented out and line 12 uncommented, the codes behave properly. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33457
[Bug tree-optimization/33458] [4.3 regression] ICE "PHI def is not a GIMPLE value"
-- reichelt at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|--- |4.3.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33458
[Bug c++/33462] New: [4.1/4.2/4.3 regression] Broken diagnostic: 'va_arg_expr' not supported by dump_expr
The following invalid testcase triggers a broken diagnostic since GCC 3.3.1:
===
struct A {};
void foo()
{
++__builtin_va_arg(0, A);
}
===
bug.cc:5: error: no match for 'operator++' in '++#'va_arg_expr' not supported
by dump_expr#'
--
Summary: [4.1/4.2/4.3 regression] Broken diagnostic:
'va_arg_expr' not supported by dump_expr
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
Keywords: diagnostic, monitored
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: reichelt at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33462
[Bug c++/33462] [4.1/4.2/4.3 regression] Broken diagnostic: 'va_arg_expr' not supported by dump_expr
-- reichelt at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|--- |4.1.3 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33462
[Bug c++/33461] [4.3 regression] ICE with invalid specialization involving parameter packs
-- reichelt at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|--- |4.3.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33461
[Bug c++/33463] New: [4.1/4.2/4.3 regression] Broken diagnostic: 'typeid_expr' not supported by dump_expr
The following invalid testcase triggers a broken diagnostic since GCC 3.4.0:
===
namespace std
{
class type_info {};
}
template void foo()
{
!typeid(void);
}
===
bug.cc: In function 'void foo()':
bug.cc:8: error: no match for 'operator!' in '!#'typeid_expr' not supported by
dump_expr#'
bug.cc:8: note: candidates are: operator!(bool)
--
Summary: [4.1/4.2/4.3 regression] Broken diagnostic:
'typeid_expr' not supported by dump_expr
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
Keywords: diagnostic, monitored
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: reichelt at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33463
[Bug c++/33463] [4.1/4.2/4.3 regression] Broken diagnostic: 'typeid_expr' not supported by dump_expr
-- reichelt at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|--- |4.1.3 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33463
[Bug c++/33464] New: [4.1/4.2/4.3 regression] Broken diagnostic: 'trait_expr' not supported by dump_expr
The following invalid testcase triggers a broken diagnostic on mainline:
===
template void foo()
{
__is_class(int)();
}
===
bug.cc: In function 'void foo()':
bug.cc:3: error: '#'trait_expr' not supported by dump_expr#'
cannot be used as a function
This is similar to PR33212, but not yet fixed.
--
Summary: [4.1/4.2/4.3 regression] Broken diagnostic: 'trait_expr'
not supported by dump_expr
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
Keywords: diagnostic, monitored
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: reichelt at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33464
[Bug c++/33464] [4.3 regression] Broken diagnostic: 'trait_expr' not supported by dump_expr
-- reichelt at gcc dot gnu dot org changed: What|Removed |Added Summary|[4.1/4.2/4.3 regression]|[4.3 regression] Broken |Broken diagnostic: |diagnostic: 'trait_expr' not |'trait_expr' not supported |supported by dump_expr |by dump_expr| Target Milestone|--- |4.3.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33464
[Bug target/33359] [4.3 Regression] libgcc is miscompiled on SH
--- Comment #3 from lauras at gcc dot gnu dot org 2007-09-17 22:27 --- Thanks for helping with this issue. Do you want to commit this to gc-improv branch? (Removing pinskia from CC, as this must be spam to him) -- lauras 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=33359
[Bug c++/33465] New: Broken diagnostic: 'fix_trunc_expr' and 'float_expr' not supported by dump_expr
The following invalid testcase triggers a broken diagnostic since at least
GCC 2.95.3:
===
int foo(int);
void bar(double d)
{
foo(d)();
}
===
bug.cc: In function 'void bar(double)':
bug.cc:5: error: 'foo(#'fix_trunc_expr' not supported by dump_expr#)' cannot be used as a function
The other conversion is broken, too:
===
int foo(double);
void bar(int i)
{
foo(i)();
}
===
bug.cc: In function 'void bar(int)':
bug.cc:5: error: 'foo(#'float_expr' not supported by dump_expr#)' cannot be used as a function
--
Summary: Broken diagnostic: 'fix_trunc_expr' and 'float_expr' not
supported by dump_expr
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
Keywords: diagnostic, monitored
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: reichelt at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33465
[Bug target/32337] [4.3 Regression] Error: Register number out of range 0..1
--- Comment #2 from jakub at gcc dot gnu dot org 2007-09-17 22:30 --- http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=128490 -- 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=32337
[Bug target/32338] [4.3 Regression] Error: .prologue within prologue
--- Comment #8 from jakub at gcc dot gnu dot org 2007-09-17 22:30 --- http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=128446 -- 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=32338
[Bug fortran/32550] openmp: COPYPRIVATE of pointer variables fails
--- Comment #4 from jakub at gcc dot gnu dot org 2007-09-17 22:37 --- Won't fix for 4.2. -- 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=32550
[Bug target/11180] [avr-gcc] Optimization decrease performance of struct assignment.
--- Comment #22 from eweddington at cso dot atmel dot com 2007-09-17 22:53 --- Subject: RE: [avr-gcc] Optimization decrease performance of struct assignment. > --- Comment #21 from rask at gcc dot gnu dot org > 2007-09-17 11:13 --- > It's probably someting simple, see config.log. Here it is: configure:10398: error: unrecognizable insn: (insn 105 104 106 2 (set (subreg:QI (reg/f:HI 52) 0) (subreg:QI (label_ref:HI 57) 0)) -1 (nil)) configure:10398: internal compiler error: in extract_insn, at recog.c:1990 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=11180
[Bug target/33359] [4.3 Regression] libgcc is miscompiled on SH
--- Comment #4 from pinskia at gcc dot gnu dot org 2007-09-17 23:00 --- (In reply to comment #3) > (Removing pinskia from CC, as this must be spam to him) Not really since gmail actually threads nicely and remove dups and I am subscribed to gcc-bugs@ anyways :). The main reason why I CC myself is to make sure I see the important bugs (like this one). -- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||pinskia at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33359
[Bug c++/33464] [4.3 regression] Broken diagnostic: 'trait_expr' not supported by dump_expr
-- pcarlini at suse dot de changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |pcarlini at suse dot de |dot org | Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2007-09-17 23:02:26 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33464
[Bug target/33359] [4.3 Regression] libgcc is miscompiled on SH
--- Comment #5 from kkojima at gcc dot gnu dot org 2007-09-18 00:02 --- (In reply to comment #3) > Do you want to commit this to gc-improv branch? Yes. If you are OK, I'll send it to gcc-patches for gc-improv. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33359
[Bug c/33466] New: mixed-case suffix for decimal float constants
GCC accepts mixed-case suffix for decimal float constants. Mixed-case suffix is not allowed in http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1176.pdf. Is this a bug or extension? test case: double dd = 1.0dD; -- Summary: mixed-case suffix for decimal float constants Product: gcc Version: 4.2.0 Status: UNCONFIRMED Severity: minor Priority: P3 Component: c AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: s__nakayama at infoseek dot jp http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33466
[Bug c++/31863] [4.1/4.2/4.3 Regression] g++-4.1: out of memory with -O1/-O2
--- Comment #10 from alexander at kogan dot nnov dot ru 2007-09-18 04:58 --- Hi! Is there any progress with this bug? We are waiting impatiently for fix! -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31863
[Bug c++/33467] New: Compilation error while compiling DynCommon.cpp
Following is the machine and compiler details: bash-3.00$ gcc -v Using built-in specs. Target: hppa2.0w-hp-hpux11.11 Configured with: ../gcc/configure Thread model: single gcc version 4.0.2 Following error is generated while compiling "DynCommon.cpp" which is a file in opensource middleware (ACE/TAO): g++ -fvisibility=hidden -fvisibility-inlines-hidden -w -O2 -g -DHPUX_VERS= -DACE_HAS_THREADS -D_POSIX_C_SOURCE=199506L -I/instaroam/pinakee/TAO/ACE_wrappers -I/instaroam/pinakee/TAO/ACE_wrappers/TAO -DACE_HAS_EXCEPTIONS -D__ACE_INLINE__ -I../.. -I.. -DTAO_DYNAMICANY_BUILD_DLL -c -fPIC -o .shobj/DynamicAny/DynCommon.o DynamicAny/DynCommon.cpp DynamicAny/DynCommon.cpp: In member function 'void TAO_DynCommon::_ZTv0_n100_N13TAO_DynCommon17insert_longdoubleEe(CORBA::LongDouble)': DynamicAny/DynCommon.cpp:1290: internal compiler error: in make_decl_rtl, at varasm.c:871 Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html> for instructions. gmake[1]: *** [.shobj/DynamicAny/DynCommon.o] Error 1 gmake[1]: Leaving directory `/instaroam/pinakee/TAO/ACE_wrappers/TAO/tao' gmake: *** [DynamicAny] Error 2 -- Summary: Compilation error while compiling DynCommon.cpp Product: gcc Version: 4.0.2 Status: UNCONFIRMED Severity: blocker Priority: P3 Component: c++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: pinakee dot b at xius dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33467
[Bug c++/33467] Compilation error while compiling DynCommon.cpp
--- Comment #1 from pinakee dot b at xius dot com 2007-09-18 05:08 --- Created an attachment (id=14217) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14217&action=view) The file is where the compilation error is coming. The attachment is the file where the compilation error is being reported. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33467
[Bug fortran/33231] Reject for -std=f* calls to elementar functions where array and scalar are mixed
--- Comment #3 from burnus at gcc dot gnu dot org 2007-09-18 06:34 --- Subject: Bug 33231 Author: burnus Date: Tue Sep 18 06:34:30 2007 New Revision: 128570 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=128570 Log: 2007-09-18 Tobias Burnus <[EMAIL PROTECTED]> PR fortran/33231 * resolve.c (resolve_elemental_actual): Check for conformance of intent out/inout dummies. 2007-09-18 Tobias Burnus <[EMAIL PROTECTED]> PR fortran/33231 * gfortran.dg/elemental_optional_args_1.f90: Make valid Fortran. * gfortran.dg/elemental_subroutine_1.f90: Ditto. * gfortran.dg/elemental_subroutine_5.f90: New. Added: trunk/gcc/testsuite/gfortran.dg/elemental_subroutine_5.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/resolve.c trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gfortran.dg/elemental_optional_args_1.f90 trunk/gcc/testsuite/gfortran.dg/elemental_subroutine_1.f90 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33231
[Bug fortran/33231] Reject for -std=f* calls to elementar functions where array and scalar are mixed
--- Comment #4 from burnus at gcc dot gnu dot org 2007-09-18 06:34 --- FIXED on the trunk (4.3). -- burnus at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED Target Milestone|--- |4.3.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33231
