[Bug middle-end/39625] [4.5 regression] Revision 145338 breaks ability to build Ada
--- Comment #21 from ebotcazou at gcc dot gnu dot org 2009-04-07 05:13 --- > It looks like this would affect: hpux-ia64, lynxos-ppc, lynxos-x86, > vxworks-arm, vxworks-m68k, vxworks-mips, vxworks-sparcv9 and vxworks-x86 > with the "default" ./configure _AND_ every other Target _IF_ the Builder > chooses to use "--enable-sjlj-exceptions" (which is 'legal'). You can exclude all cross platforms; moreover hpux-ia64 is not really supported. > Someone else "confirmed" this on "i686-pc-cygwin". It's the only platform really affected. -- ebotcazou at gcc dot gnu dot org changed: What|Removed |Added Severity|enhancement |normal Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2009-04-07 05:13:57 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39625
[Bug c++/35146] [4.3/4.4/4.5 regression] weird error in template function specialization
--- Comment #13 from jason at gcc dot gnu dot org 2009-04-07 04:46 --- Fixed. -- jason at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35146
[Bug c++/37806] CV-qualifiers on function typedef's are inconsistently accepted depending on typedef scope
--- Comment #8 from jason at gcc dot gnu dot org 2009-04-07 04:38 --- Fixed for 4.4. -- jason at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37806
[Bug libstdc++/39310] T const assumed to be compatible with int (A::*) (void) const
--- Comment #13 from jason at gcc dot gnu dot org 2009-04-07 04:38 --- Subject: Bug 39310 Author: jason Date: Tue Apr 7 04:38:10 2009 New Revision: 145648 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=145648 Log: * decl.c (grokdeclarator): Reject pointer to qualified function type. PR c++/37806, core issue 547 * typeck.c (cp_apply_type_quals_to_decl): Don't apply any quals to a typedef. * tree.c (cp_build_qualified_type_real): Don't apply restrict to a function type. * decl.h (enum decl_context): Add TEMPLATE_TYPE_ARG. * decl.c (groktypename): Add is_template_arg parameter. (grokdeclarator): Allow function cv-quals on a template type arg. * parser.c (cp_parser_new_type_id, cp_parser_type_id): Add is_template_arg argument in calls to groktypename. * cp-tree.h: Adjust prototype. * error.c (dump_type_prefix, dump_type_suffix): Fix plain FUNCTION_TYPE printing. PR libstdc++/39310 * include/tr1_impl/type_traits (is_function): Add partial specializations with function cv-quals. (__is_function_helper): Remove. (is_member_pointer): Don't define in terms of is_member_*_pointer. Added: branches/gcc-4_4-branch/gcc/testsuite/g++.dg/other/typedef2.C - copied unchanged from r145367, trunk/gcc/testsuite/g++.dg/other/typedef2.C branches/gcc-4_4-branch/gcc/testsuite/g++.dg/template/typedef17.C - copied unchanged from r145367, trunk/gcc/testsuite/g++.dg/template/typedef17.C Modified: branches/gcc-4_4-branch/gcc/cp/ChangeLog branches/gcc-4_4-branch/gcc/cp/cp-tree.h branches/gcc-4_4-branch/gcc/cp/decl.c branches/gcc-4_4-branch/gcc/cp/decl.h branches/gcc-4_4-branch/gcc/cp/error.c branches/gcc-4_4-branch/gcc/cp/parser.c branches/gcc-4_4-branch/gcc/cp/tree.c branches/gcc-4_4-branch/gcc/cp/typeck.c branches/gcc-4_4-branch/gcc/testsuite/ChangeLog branches/gcc-4_4-branch/gcc/testsuite/g++.dg/template/qualttp20.C branches/gcc-4_4-branch/libstdc++-v3/ChangeLog branches/gcc-4_4-branch/libstdc++-v3/include/tr1_impl/type_traits -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39310
[Bug c++/37806] CV-qualifiers on function typedef's are inconsistently accepted depending on typedef scope
--- Comment #7 from jason at gcc dot gnu dot org 2009-04-07 04:38 --- Subject: Bug 37806 Author: jason Date: Tue Apr 7 04:38:10 2009 New Revision: 145648 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=145648 Log: * decl.c (grokdeclarator): Reject pointer to qualified function type. PR c++/37806, core issue 547 * typeck.c (cp_apply_type_quals_to_decl): Don't apply any quals to a typedef. * tree.c (cp_build_qualified_type_real): Don't apply restrict to a function type. * decl.h (enum decl_context): Add TEMPLATE_TYPE_ARG. * decl.c (groktypename): Add is_template_arg parameter. (grokdeclarator): Allow function cv-quals on a template type arg. * parser.c (cp_parser_new_type_id, cp_parser_type_id): Add is_template_arg argument in calls to groktypename. * cp-tree.h: Adjust prototype. * error.c (dump_type_prefix, dump_type_suffix): Fix plain FUNCTION_TYPE printing. PR libstdc++/39310 * include/tr1_impl/type_traits (is_function): Add partial specializations with function cv-quals. (__is_function_helper): Remove. (is_member_pointer): Don't define in terms of is_member_*_pointer. Added: branches/gcc-4_4-branch/gcc/testsuite/g++.dg/other/typedef2.C - copied unchanged from r145367, trunk/gcc/testsuite/g++.dg/other/typedef2.C branches/gcc-4_4-branch/gcc/testsuite/g++.dg/template/typedef17.C - copied unchanged from r145367, trunk/gcc/testsuite/g++.dg/template/typedef17.C Modified: branches/gcc-4_4-branch/gcc/cp/ChangeLog branches/gcc-4_4-branch/gcc/cp/cp-tree.h branches/gcc-4_4-branch/gcc/cp/decl.c branches/gcc-4_4-branch/gcc/cp/decl.h branches/gcc-4_4-branch/gcc/cp/error.c branches/gcc-4_4-branch/gcc/cp/parser.c branches/gcc-4_4-branch/gcc/cp/tree.c branches/gcc-4_4-branch/gcc/cp/typeck.c branches/gcc-4_4-branch/gcc/testsuite/ChangeLog branches/gcc-4_4-branch/gcc/testsuite/g++.dg/template/qualttp20.C branches/gcc-4_4-branch/libstdc++-v3/ChangeLog branches/gcc-4_4-branch/libstdc++-v3/include/tr1_impl/type_traits -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37806
[Bug libfortran/39668] Wrongly read namelist with two dimensional array.
--- Comment #2 from burnus at gcc dot gnu dot org 2009-04-07 04:35 --- (In reply to comment #1) > I see the problem in 4.3, 4.4, and 4.5. I don't have a 4.2 around, can > someone check that to see if this is a regression. 4.1/4.2 show the same result. openf95, g95, ifort, sunf95 all have the following (which differs from Toon's expected result): &NAMTEST I = 1, 4, 7, 8, 9, 4*0 / NAG f95 needs an extra "open(10)" and prints then: Invalid character '2' in NAMELIST input I'm not sure whether the example is valid. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39668
[Bug middle-end/39625] [4.5 regression] Revision 145338 breaks ability to build Ada
--- Comment #20 from rob1weld at aol dot com 2009-04-07 04:00 --- (In reply to comment #8) > Bug is not in an FSF-GCC supported port. > Does the problem reproduce on supported targets? Otherwise this bug > should be closed as "INVALID". (In reply to comment #12) >> As for the backend issue, may be it will show up on i386-unknown-freebsd >> too (a primary platform), and there's a gcc/ada/system-freebsd-x86.ads >> in the FSF tree. > Most probably not, you need FE SJLJ exceptions. I did some studying ;) . The "current" Docs do not show this info but 4.2.4 does. These 'quotes' are derived from this URL: http://gcc.gnu.org/onlinedocs/gcc-4.2.4/gnat_ugn_unw/Exception-Handling-Control.html 0. Any Target may be configured to use SJLJ. 1. GNAT uses two methods for handling exceptions at run-time. The setjmp/longjmp method and zero cost exception handling. 2. The setjmp/longjmp approach is available on all targets, while the zero cost approach is available on selected targets. With ZCX to propagate an exception through a C/C++ code, the C/C++ code must be compiled with the -funwind-tables GCC's option. 3. To determine whether zero cost exceptions can be used for a particular target, look at the private part of the file system.ads. Either GCC_ZCX_Support or Front_End_ZCX_Support must be True to use the zero cost approach. If both of these switches are set to False, this means that zero cost exception handling is not yet available for that target. So ... Two strikes and your out: # grep ZCX /mnt/drive2/gcc_trunk/gcc/ada/system* | grep False /mnt/drive2/gcc_trunk/gcc/ada/system.ads: ZCX_By_Default: constant Boolean := False; /mnt/drive2/gcc_trunk/gcc/ada/system.ads: GCC_ZCX_Support : constant Boolean := False; /mnt/drive2/gcc_trunk/gcc/ada/system.ads: Front_End_ZCX_Support : constant Boolean := False; /mnt/drive2/gcc_trunk/gcc/ada/system-aix.ads: ZCX_By_Default: constant Boolean := False; /mnt/drive2/gcc_trunk/gcc/ada/system-hpux-ia64.ads: ZCX_By_Default : constant Boolean := False; /mnt/drive2/gcc_trunk/gcc/ada/system-hpux-ia64.ads: GCC_ZCX_Support : constant Boolean := False; /mnt/drive2/gcc_trunk/gcc/ada/system-linux-alpha.ads: Front_End_ZCX_Support : constant Boolean := False; /mnt/drive2/gcc_trunk/gcc/ada/system-linux-mips.ads: Front_End_ZCX_Support : constant Boolean := False; /mnt/drive2/gcc_trunk/gcc/ada/system-linux-mipsel.ads: Front_End_ZCX_Support : constant Boolean := False; /mnt/drive2/gcc_trunk/gcc/ada/system-linux-s390.ads: Front_End_ZCX_Support : constant Boolean := False; /mnt/drive2/gcc_trunk/gcc/ada/system-linux-s390x.ads: Front_End_ZCX_Support : constant Boolean := False; /mnt/drive2/gcc_trunk/gcc/ada/system-linux-sparc.ads: Front_End_ZCX_Support : constant Boolean := False; /mnt/drive2/gcc_trunk/gcc/ada/system-linux-sparcv9.ads: Front_End_ZCX_Support : constant Boolean := False; /mnt/drive2/gcc_trunk/gcc/ada/system-lynxos-ppc.ads: ZCX_By_Default : constant Boolean := False; /mnt/drive2/gcc_trunk/gcc/ada/system-lynxos-ppc.ads: GCC_ZCX_Support : constant Boolean := False; /mnt/drive2/gcc_trunk/gcc/ada/system-lynxos-x86.ads: ZCX_By_Default : constant Boolean := False; /mnt/drive2/gcc_trunk/gcc/ada/system-lynxos-x86.ads: GCC_ZCX_Support : constant Boolean := False; /mnt/drive2/gcc_trunk/gcc/ada/system-mingw.ads: ZCX_By_Default: constant Boolean := False; /mnt/drive2/gcc_trunk/gcc/ada/system-rtems.ads: ZCX_By_Default: constant Boolean := False; /mnt/drive2/gcc_trunk/gcc/ada/system-vms.ads: GCC_ZCX_Support : constant Boolean := False; /mnt/drive2/gcc_trunk/gcc/ada/system-vxworks-arm.ads: ZCX_By_Default : constant Boolean := False; /mnt/drive2/gcc_trunk/gcc/ada/system-vxworks-arm.ads: GCC_ZCX_Support : constant Boolean := False; /mnt/drive2/gcc_trunk/gcc/ada/system-vxworks-m68k.ads: ZCX_By_Default : constant Boolean := False; /mnt/drive2/gcc_trunk/gcc/ada/system-vxworks-m68k.ads: GCC_ZCX_Support : constant Boolean := False; /mnt/drive2/gcc_trunk/gcc/ada/system-vxworks-mips.ads: ZCX_By_Default : constant Boolean := False; /mnt/drive2/gcc_trunk/gcc/ada/system-vxworks-mips.ads: GCC_ZCX_Support : constant Boolean := False; /mnt/drive2/gcc_trunk/gcc/ada/system-vxworks-ppc.ads: ZCX_By_Default : constant Boolean := False; /mnt/drive2/gcc_trunk/gcc/ada/system-vxworks-sparcv9.ads: ZCX_By_Default : constant Boolean := False; /mnt/drive2/gcc_trunk/gcc/ada/system-vxworks-sparcv9.ads: GCC_ZCX_Support : constant Boolean := False; /mnt/drive2/gcc_trunk/gcc/ada/system-vxworks-x86.ads: ZCX_By_Default : constant Boolean := False; /mnt/drive2/gcc_trunk/gcc/ada/system-vxworks-x86.ads: GCC_ZCX_Support : constant Boolean := False; It looks like this woul
[Bug c++/35146] [4.3/4.4/4.5 regression] weird error in template function specialization
--- Comment #12 from jason at gcc dot gnu dot org 2009-04-07 03:51 --- Subject: Bug 35146 Author: jason Date: Tue Apr 7 03:50:49 2009 New Revision: 145647 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=145647 Log: PR c++/35146 * pt.c (fn_type_unification): For DEDUCE_EXACT check that the deduced template arguments give us the parameter types we're looking for. Added: branches/gcc-4_3-branch/gcc/testsuite/g++.dg/template/fnspec1.C Modified: branches/gcc-4_3-branch/gcc/cp/ChangeLog branches/gcc-4_3-branch/gcc/cp/pt.c branches/gcc-4_3-branch/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35146
[Bug bootstrap/39660] Mingw Bootstrap stops with "..host-mingw32.c:140: error: ISO C90 forbids mixed.."
-- dannysmith at users dot sourceforge dot net changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |dannysmith at users dot |dot org |sourceforge dot net Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2009-04-07 03:39:21 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39660
[Bug libfortran/39668] Wrongly read namelist with two dimensional array.
--- Comment #1 from jvdelisle at gcc dot gnu dot org 2009-04-07 02:59 --- I see the problem in 4.3, 4.4, and 4.5. I don't have a 4.2 around, can someone check that to see if this is a regression. -- jvdelisle at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |jvdelisle at gcc dot gnu dot |dot org |org Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2009-04-07 02:59:59 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39668
[Bug bootstrap/39617] bootstrap failure with ICE building libiberty in stage3
-- hjl dot tools at gmail dot com changed: What|Removed |Added Target Milestone|--- |4.5.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39617
[Bug target/39634] powerpc64 libgcc contains useless softfp functions
--- Comment #4 from amodra at bigpond dot net dot au 2009-04-07 01:21 --- Fixed -- amodra at bigpond dot net dot au changed: What|Removed |Added Status|ASSIGNED|RESOLVED Known to fail|4.3.4 4.4.0 4.5.0 |4.3.3 4.4.0 4.5.0 Resolution||FIXED Target Milestone|--- |4.3.4 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39634
[Bug target/39634] powerpc64 libgcc contains useless softfp functions
--- Comment #3 from amodra at gcc dot gnu dot org 2009-04-07 01:15 --- Subject: Bug 39634 Author: amodra Date: Tue Apr 7 01:15:37 2009 New Revision: 145643 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=145643 Log: PR target/39634 * config.gcc (powerpc-*-linux*): Include soft-fp/t-softfp after rs6000/t-linux64. Modified: branches/gcc-4_3-branch/gcc/ChangeLog branches/gcc-4_3-branch/gcc/config.gcc -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39634
[Bug target/39634] powerpc64 libgcc contains useless softfp functions
--- Comment #2 from amodra at gcc dot gnu dot org 2009-04-07 00:53 --- Subject: Bug 39634 Author: amodra Date: Tue Apr 7 00:53:05 2009 New Revision: 145642 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=145642 Log: PR target/39634 * config.gcc (powerpc-*-linux*): Include soft-fp/t-softfp after rs6000/t-linux64. Modified: branches/gcc-4_4-branch/gcc/ChangeLog branches/gcc-4_4-branch/gcc/config.gcc -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39634
[Bug target/39634] powerpc64 libgcc contains useless softfp functions
--- Comment #1 from amodra at gcc dot gnu dot org 2009-04-07 00:47 --- Subject: Bug 39634 Author: amodra Date: Tue Apr 7 00:47:21 2009 New Revision: 145641 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=145641 Log: PR target/39634 * config.gcc: Merge powerpc-*-linux* and powerpc64-*-linux*. Include soft-fp/t-softfp after rs6000/t-linux64. * config.host: Reorder and merge to match config.gcc change. Modified: trunk/gcc/ChangeLog trunk/gcc/config.gcc trunk/libgcc/ChangeLog trunk/libgcc/config.host -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39634
[Bug target/39663] mingw hosted arm-elf output differs from linux hosted arm-elf when compiling with -Os and -mthumb
--- Comment #3 from hp at gcc dot gnu dot org 2009-04-07 00:38 --- The issue is rather 64-bit HOST_WIDE_INT host compared to 32-bit HOST_WIDE_INT host. (To prove wrong, compare with i686-unknown-linux-gnu instead x86_64-unknown-linux-gnu or configure and build with 'CC=gcc -m32'.) You *will* see some differences for code where 64-bit entities appear (maybe your pic_t and isr_t); known issue. I think there's another PR which to which this is a duplicate. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39663
[Bug gcov-profile/39669] gcov --preserve-paths causes mangled filenames on windows
--- Comment #2 from pinskia at gcc dot gnu dot org 2009-04-06 23:51 --- Can you try a newer GCC? 3.4.x has not been supported for a while. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39669
[Bug gcov-profile/39669] gcov --preserve-paths causes mangled filenames on windows
--- Comment #1 from kazeits at rockwellcollins dot com 2009-04-06 23:50 --- Created an attachment (id=17597) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17597&action=view) test case: zip file containing example project. unzipping and runing 'make coverage_bad' shows the problem. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39669
[Bug gcov-profile/39669] gcov --preserve-paths causes mangled filenames on windows
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added Severity|major |normal http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39669
[Bug gcov-profile/39669] New: gcov --preserve-paths causes mangled filenames on windows
using a MinGW build of gcov 'gcov (GCC) 3.4.5 (mingw-vista special r3)' --preserve paths cause mangled output filenames. Say there is a file called C:/foo/bar.gcda calling 'gcov C:/foo/bar.gcda -o foo --preserve-paths -b' from 'C:\' causes the file 'foo#bar.gcov' to be output in in 'c:\' instead of 'bar.gcov' being produced in 'c:\foo\' -- Summary: gcov --preserve-paths causes mangled filenames on windows Product: gcc Version: 3.4.5 Status: UNCONFIRMED Severity: major Priority: P3 Component: gcov-profile AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: kazeits at rockwellcollins dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39669
[Bug libfortran/39664] [4.5 Regression] Revision 145571 breaks stdio
--- Comment #15 from hjl dot tools at gmail dot com 2009-04-06 23:16 --- Fixed. -- hjl dot tools at gmail dot com changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED Target Milestone|--- |4.5.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39664
[Bug libfortran/39664] [4.5 Regression] Revision 145571 breaks stdio
--- Comment #14 from hjl at gcc dot gnu dot org 2009-04-06 23:08 --- Subject: Bug 39664 Author: hjl Date: Mon Apr 6 23:07:51 2009 New Revision: 145636 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=145636 Log: 2009-04-06 H.J. Lu PR libgfortran/39664 * io/unix.c (raw_close): Don't close STDOUT_FILENO, STDERR_FILENO nor STDIN_FILENO. Modified: trunk/libgfortran/ChangeLog trunk/libgfortran/io/unix.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39664
[Bug libfortran/39664] [4.5 Regression] Revision 145571 breaks stdio
--- Comment #13 from hjl dot tools at gmail dot com 2009-04-06 22:57 --- (In reply to comment #10) > > Works for me. > troutmask:sgk[204] ~/work/4x/bin/gcc -c g.c > troutmask:sgk[205] gfc4x -o z g.o > troutmask:sgk[206] ./z > zxc > troutmask:sgk[207] cat zxc > > Done. Did you try it on Linux? libgfortran closes FDs which are the parts of C library. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39664
[Bug libfortran/39664] [4.5 Regression] Revision 145571 breaks stdio
--- Comment #12 from hjl dot tools at gmail dot com 2009-04-06 22:53 --- A patch is posted at http://gcc.gnu.org/ml/gcc-patches/2009-04/msg00464.html -- hjl dot tools at gmail dot com changed: What|Removed |Added URL||http://gcc.gnu.org/ml/gcc- ||patches/2009- ||04/msg00464.html http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39664
[Bug libfortran/39664] [4.5 Regression] Revision 145571 breaks stdio
--- Comment #11 from pinskia at gcc dot gnu dot org 2009-04-06 22:47
---
(In reply to comment #9)
> This patch seems to work for the small testcase:
This patch looks correct based on the old code:
- if (s->fd != STDOUT_FILENO && s->fd != STDERR_FILENO && s->fd !=
STDIN_FILENO)
-{
- if (close (s->fd) < 0)
- return FAILURE;
-}
-
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39664
[Bug libfortran/39664] [4.5 Regression] Revision 145571 breaks stdio
--- Comment #10 from kargl at gcc dot gnu dot org 2009-04-06 22:46 ---
(In reply to comment #6)
> Revision 145571 breaks stdio when the output was redirected to a file:
>
> [h[...@gnu-16 pr39664]$ cat foo.c
> #include
>
> int
> main ()
> {
>
> printf("\n");
>
> printf("Done.\n");
>
> return 0;
> }
> j...@gnu-16 pr39664]$ /export/gnu/import/rrs/145571/usr/bin/gcc -O2 -c -o
> foo.o
> foo.c
> [...@gnu-16 pr39664]$ /export/gnu/import/rrs/145571/usr/bin/gfortran -o foo
> foo.o
> [...@gnu-16 pr39664]$ LD_LIBRARY_PATH=/export/gnu/import/rrs/145571/usr/lib64
> ./foo > 1
> [...@gnu-16 pr39664]$ cat 1
> [...@gnu-16 pr39664]$ LD_LIBRARY_PATH=/export/gnu/import/rrs/145571/usr/lib64
> ./foo
>
> Done.
> [...@gnu-16 pr39664]$
>
Works for me.
troutmask:sgk[204] ~/work/4x/bin/gcc -c g.c
troutmask:sgk[205] gfc4x -o z g.o
troutmask:sgk[206] ./z > zxc
troutmask:sgk[207] cat zxc
----
Done.
troutmask:sgk[208] gfc4x --version
GNU Fortran (GCC) 4.5.0 20090406 (experimental)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39664
[Bug libfortran/39664] [4.5 Regression] Revision 145571 breaks stdio
--- Comment #9 from hjl dot tools at gmail dot com 2009-04-06 22:43 ---
This patch seems to work for the small testcase:
Index: io/unix.c
===
--- io/unix.c (revision 145571)
+++ io/unix.c (working copy)
@@ -344,7 +344,12 @@ raw_close (unix_stream * s)
{
int retval;
- retval = close (s->fd);
+ if (s->fd != STDOUT_FILENO
+ && s->fd != STDERR_FILENO
+ && s->fd != STDIN_FILENO)
+retval = close (s->fd);
+ else
+retval = SUCCESS;
free_mem (s);
return retval;
}
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39664
[Bug libfortran/39664] [4.5 Regression] Revision 145571 breaks stdio
--- Comment #8 from hjl dot tools at gmail dot com 2009-04-06 22:41 --- (In reply to comment #7) > I don't know if this is really a bug. The interaction between Fortran I/O and > C FILE I/O is not defined anywhere. Does it mean that gcc doesn't support mixing C codes which contain stdio with Fortran I/O? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39664
[Bug target/37466] [AVR] avr-gcc generating incorrect assembly for expression with the long constant operands
--- Comment #4 from eric dot weddington at atmel dot com 2009-04-06 22:38 --- *** Bug 39593 has been marked as a duplicate of this bug. *** -- eric dot weddington at atmel dot com changed: What|Removed |Added CC||szir at sch dot bme dot hu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37466
[Bug target/39593] [avr] faulty value assignment
--- Comment #10 from eric dot weddington at atmel dot com 2009-04-06 22:38 --- This looks like a duplicate of bug #37466. *** This bug has been marked as a duplicate of 37466 *** -- eric dot weddington at atmel dot com changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39593
[Bug libfortran/39664] [4.5 Regression] Revision 145571 breaks stdio
--- Comment #7 from pinskia at gcc dot gnu dot org 2009-04-06 22:22 --- I don't know if this is really a bug. The interaction between Fortran I/O and C FILE I/O is not defined anywhere. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39664
[Bug libfortran/39664] [4.5 Regression] Revision 145571 breaks stdio
--- Comment #6 from hjl dot tools at gmail dot com 2009-04-06 22:20 ---
Revision 145571 breaks stdio when the output was redirected to a file:
[h[...@gnu-16 pr39664]$ cat foo.c
#include
int
main ()
{
printf("\n");
printf("Done.\n");
return 0;
}
j...@gnu-16 pr39664]$ /export/gnu/import/rrs/145571/usr/bin/gcc -O2 -c -o
foo.o
foo.c
[...@gnu-16 pr39664]$ /export/gnu/import/rrs/145571/usr/bin/gfortran -o foo
foo.o
[...@gnu-16 pr39664]$ LD_LIBRARY_PATH=/export/gnu/import/rrs/145571/usr/lib64
./foo > 1
[...@gnu-16 pr39664]$ cat 1
[...@gnu-16 pr39664]$ LD_LIBRARY_PATH=/export/gnu/import/rrs/145571/usr/lib64
./foo
Done.
[...@gnu-16 pr39664]$
--
hjl dot tools at gmail dot com changed:
What|Removed |Added
Summary|[4.5 Regression] Revision |[4.5 Regression] Revision
|145571 caused 436.cactusADM |145571 breaks stdio
|in SPEC CPU 2006 to fail|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39664
[Bug libfortran/39664] [4.5 Regression] Revision 145571 caused 436.cactusADM in SPEC CPU 2006 to fail
--- Comment #5 from hjl dot tools at gmail dot com 2009-04-06 22:15 ---
cactusADM has both C and Fortran. The following code
printf("\n");
printf("Done.\n");
in C won't show up when the output is redirected to a file.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39664
[Bug libobjc/39465] libobjc does not find classes of DLLs
--- Comment #11 from ayers at gcc dot gnu dot org 2009-04-06 21:59 --- With 'native' I meant mingw := build=host=target so no... it's not native in the sense that I was talking about. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39465
[Bug bootstrap/39617] bootstrap failure with ICE building libiberty in stage3
--- Comment #2 from janis at gcc dot gnu dot org 2009-04-06 21:39 --- Surprise, Richard, you fixed this! The failure goes away with r145494, the merge of the alias-improvements branch. -- janis at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39617
[Bug libobjc/39465] libobjc does not find classes of DLLs
--- Comment #10 from js-gcc at webkeks dot org 2009-04-06 21:39 --- What exactly do you mean by native build? Do you mean if I build a compiler to run on Linux and not on win32, but which targets win32? If so, yes. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39465
[Bug c++/35146] [4.3/4.4/4.5 regression] weird error in template function specialization
--- Comment #11 from jason at gcc dot gnu dot org 2009-04-06 21:35 --- Subject: Bug 35146 Author: jason Date: Mon Apr 6 21:35:29 2009 New Revision: 145634 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=145634 Log: PR c++/35146 * pt.c (fn_type_unification): For DEDUCE_EXACT check that the deduced template arguments give us the parameter types we're looking for. Added: branches/gcc-4_4-branch/gcc/testsuite/g++.dg/template/fnspec1.C Modified: branches/gcc-4_4-branch/gcc/cp/ChangeLog branches/gcc-4_4-branch/gcc/cp/pt.c branches/gcc-4_4-branch/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35146
[Bug libfortran/39664] [4.5 Regression] Revision 145571 caused 436.cactusADM in SPEC CPU 2006 to fail
--- Comment #4 from hjl dot tools at gmail dot com 2009-04-06 21:34 --- It is very hard to extract a small testcase. However, you can download Cactus from http://www.cactuscode.org/ -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39664
[Bug libobjc/39465] libobjc does not find classes of DLLs
--- Comment #9 from ayers at gcc dot gnu dot org 2009-04-06 21:22 --- I'm sorry, I'm simply not familiar with cygwin/mingw environments and cross builds. But I'm surprised that --enable-shared doesn't work. Is that a native build? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39465
[Bug c++/35146] [4.3/4.4/4.5 regression] weird error in template function specialization
--- Comment #10 from jason at gcc dot gnu dot org 2009-04-06 20:55 --- Subject: Bug 35146 Author: jason Date: Mon Apr 6 20:55:04 2009 New Revision: 145625 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=145625 Log: PR c++/35146 * pt.c (fn_type_unification): For DEDUCE_EXACT check that the deduced template arguments give us the parameter types we're looking for. Added: trunk/gcc/testsuite/g++.dg/template/fnspec1.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/pt.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35146
[Bug libfortran/39668] New: Wrongly read namelist with two dimensional array.
Fortran code: INTEGER :: i(3,3) namelist/namtest/i i=0 OPEN(10) CLOSE(10) READ(10,namtest) WRITE(6,namtest) END Namelist in fort.10: &namtest i(1,1)=1,2,3, i(2,1)=4,5,6, i(3,1)=7,8,9, / Print out of program: &NAMTEST I= 1, 4, 7, 0, 6, 8, 2*0 , 9, / Output should have been: &NAMTEST I= 1, 4, 7, 2, 5, 8, 3, 6, 9, / -- Summary: Wrongly read namelist with two dimensional array. Product: gcc Version: 4.5.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libfortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: toon at moene dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39668
[Bug c++/35146] [4.3/4.4/4.5 regression] weird error in template function specialization
--- Comment #9 from jason at gcc dot gnu dot org 2009-04-06 20:29 --- ...and GCC miscompiles the original testcase due to the same bug. -- jason at gcc dot gnu dot org changed: What|Removed |Added Keywords||wrong-code http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35146
[Bug fortran/38863] WHERE with multiple elemental defined assignments gives wrong answer
--- Comment #8 from pault at gcc dot gnu dot org 2009-04-06 20:17 --- Fixed on trunk. Thanks for the report Paul -- pault at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38863
[Bug c++/35146] [4.3/4.4/4.5 regression] weird error in template function specialization
--- Comment #8 from jason at gcc dot gnu dot org 2009-04-06 20:14 --- The testcase in comment #2 is ill-formed; template <> void foo(S, S*); is not a specialization of any function template in scope. But we're giving very much the wrong error for that. Testing a patch now. -- jason at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |jason at gcc dot gnu dot org |dot org | Status|NEW |ASSIGNED Last reconfirmed|2009-03-31 15:10:20 |2009-04-06 20:14:50 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35146
[Bug fortran/38863] WHERE with multiple elemental defined assignments gives wrong answer
--- Comment #7 from pault at gcc dot gnu dot org 2009-04-06 20:13 --- Subject: Bug 38863 Author: pault Date: Mon Apr 6 20:13:39 2009 New Revision: 145621 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=145621 Log: 2009-04-06 Paul Thomas PR fortran/38863 * dependency.c (ref_same_as_full_array): New function. (gfc_dep_resolver): Call it. 2009-04-06 Paul Thomas PR fortran/38863 * gfortran.dg/dependency_23.f90: New test. Added: trunk/gcc/testsuite/gfortran.dg/dependency_23.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/dependency.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38863
[Bug libfortran/39664] [4.5 Regression] Revision 145571 caused 436.cactusADM in SPEC CPU 2006 to fail
--- Comment #3 from hjl dot tools at gmail dot com 2009-04-06 19:52 --- (In reply to comment #2) > Could you try to reduce the problem - as SPEC is not publicly available it is > a > bit hard to debug (by far most gfortraners do not have access to SPEC). I am working on it. > (In reply to comment #1) > > It may be caused by revision 145571: > > http://gcc.gnu.org/ml/gcc-cvs/2009-04/msg00193.html > > Could you confirm that it was indeed caused by that patch? > (You wrote "may" ... ;-) Yes, revision 145571 is the cause. -- hjl dot tools at gmail dot com changed: What|Removed |Added Summary|[4.5 Regression]|[4.5 Regression] Revision |436.cactusADM in SPEC CPU |145571 caused 436.cactusADM |2006 is miscompiled |in SPEC CPU 2006 to fail http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39664
[Bug libfortran/39664] [4.5 Regression] 436.cactusADM in SPEC CPU 2006 is miscompiled
--- Comment #2 from burnus at gcc dot gnu dot org 2009-04-06 19:49 --- Could you try to reduce the problem - as SPEC is not publicly available it is a bit hard to debug (by far most gfortraners do not have access to SPEC). (In reply to comment #1) > It may be caused by revision 145571: > http://gcc.gnu.org/ml/gcc-cvs/2009-04/msg00193.html Could you confirm that it was indeed caused by that patch? (You wrote "may" ... ;-) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39664
[Bug libobjc/39465] libobjc does not find classes of DLLs
--- Comment #8 from js-gcc at webkeks dot org 2009-04-06 19:41 --- Any news on this? Any way how I could compile libobjc as a shared library? Specifying --enable-shared breaks basically every library that gcc ships and I haven't found a way to only enable it for libobjc. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39465
[Bug rtl-optimization/38603] [4.4/4.5 Regression] IRA does not accommodate LOAD_EXTEND_OP transformations done by combine
--- Comment #6 from ubizjak at gmail dot com 2009-04-06 18:20 --- (In reply to comment #5) > It looks to me that this is a reload bug, independent of IRA. See thread [1] > for analysis of what seems to be the same problem. > > [1] http://gcc.gnu.org/ml/gcc/2009-04/msg00033.html Thread continues at http://gcc.gnu.org/ml/gcc/2009-04/msg00038.html. -- ubizjak at gmail dot com changed: What|Removed |Added CC||ubizjak at gmail dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38603
[Bug rtl-optimization/38603] [4.4/4.5 Regression] IRA does not accommodate LOAD_EXTEND_OP transformations done by combine
--- Comment #5 from ubizjak at gmail dot com 2009-04-06 18:18 --- It looks to me that this is a reload bug, independent of IRA. See thread [1] for analysis of what seems to be the same problem. [1] http://gcc.gnu.org/ml/gcc/2009-04/msg00033.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38603
[Bug libfortran/39665] Fortran IO using unaligned accesses to read/write doubles.
--- Comment #2 from domob at gcc dot gnu dot org 2009-04-06 18:16 --- See also this thread: http://gcc.gnu.org/ml/fortran/2009-04/msg00065.html -- domob at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2009-04-06 18:16:54 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39665
[Bug fortran/39667] New: Possibly unneccesary truncations
See: http://gcc.gnu.org/ml/fortran/2009-04/msg00054.html Some namelist and utf8/widechar tests now require a working fd_truncate, which causes failures on systems not offering this. Thus one should check whether the truncations are really needed. -- Summary: Possibly unneccesary truncations Product: gcc Version: 4.5.0 Status: UNCONFIRMED Keywords: missed-optimization 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=39667
[Bug middle-end/39666] New: spurious warning with ranged-switch statements
[Follow-up to http://gcc.gnu.org/ml/gcc/2009-04/msg00175.html]
$ cat range.f90
FUNCTION f(n)
INTEGER, INTENT(in) :: n
REAL:: f
SELECT CASE (n)
CASE ( :-1); f = -1.0
CASE (0); f = 0.0
CASE (1: ); f = 1.0
END SELECT
END FUNCTION
$> gfortran-svn -c -O -Wall -fdump-tree-original -fdump-tree-optimized
range.f90
range.f90: In function 'f':
range.f90:1: warning: '__result_f' may be used uninitialized in this function
The dump after optimization shows a 'default' clause that is never reached:
:
switch (*n;) , case -2147483648 ... -1: , case 0: L.3, case
1 ... 2147483647: L.4>
If above code is changed to
$ cat range.f90
FUNCTION f(n)
INTEGER, INTENT(in) :: n
REAL:: f
SELECT CASE (n)
CASE ( :-1); f = 0.0 ! was -1.0
CASE (0); f = 0.0
CASE (1: ); f = 0.0 ! was 1.0
END SELECT
END FUNCTION
$> gfortran-svn -c -O -Wall -fdump-tree-original -fdump-tree-optimized
range.f90
[no warning]
The dump after optimization shows:
f (integer(kind=4) & n)
{
:
return 0.0;
}
The initial dump has the same structure for both cases (second case shown):
switch (*n)
{
case -2147483648 ... -1:;
__result_f = 0.0;
goto L.1;
case 0:;
__result_f = 0.0;
goto L.1;
case 1 ... 2147483647:;
__result_f = 0.0;
goto L.1;
}
L.1:;
In the first case, somewhere during optimization a 'default' is added although
the whole range of an INTEGER(kind=4) is covered - which is found in the second
case.
--
Summary: spurious warning with ranged-switch statements
Product: gcc
Version: 4.5.0
Status: UNCONFIRMED
Keywords: diagnostic
Severity: normal
Priority: P3
Component: middle-end
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: dfranke at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39666
Re: Register Allocation Bug?
#define ESP
(rel,value,addr) \
asm volatile ("mov (%%esp, %2, 4), %0\n
\t" \
"lea (%%esp, %2, 4), %1\n
\t" \
: "=r" (value),
"=r" (addr) \
:
"r" (rel)); \
It didn't work as expected so I looked at the assembler code generated
for the above:
1: b8 00 00 00 00 mov$0x0,%eax
2: 8b 04 84mov(%esp,%eax,4),%eax
3: 8d 14 84lea(%esp,%eax,4),%edx
4: 89 45 f8mov%eax,0xfff8(%ebp)
5: 89 55 fcmov%edx,0xfffc(%ebp)
As it turns out, %eax is being used for both input and output in line
2, clobbering %eax, so of course line 3 does not give the expected
result... Is this a compiler error?
It's not a compiler bug: you need to use an "early clobber", namely
"=&r"(value) . See the Fine Manual.
Segher
[Bug c/39621] Delaying operation to end of function causes high stack usage
--- Comment #2 from hp at gcc dot gnu dot org 2009-04-06 17:16 --- It'd be nice to know if -fno-tree-reassoc helped here. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39621
[Bug libfortran/39665] Fortran IO using unaligned accesses to read/write doubles.
--- Comment #1 from sje at cup dot hp dot com 2009-04-06 16:20 --- I forgot to mention that this failure started with the merging of the fortran-dev brach into the mainline. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39665
[Bug libfortran/39665] New: Fortran IO using unaligned accesses to read/write doubles.
Many fortran tests, like libgfortran.dg/arrayio_9.f90 and libgfortran.dg/arrayio_10.f90 are failing on IA64 because the IO library is reading and writing double values to unaligned addresses. In gdb I see: (gdb) r Starting program: /proj/opensrc/nightly/build-ia64-hp-hpux11.23-trunk/x Program received signal SIGBUS, Bus error si_code: 1 - BUS_ADRALN - Invalid address alignment. 0x9fffbd717700:0 in *_gfortrani_convert_real (dtp=0x9fffef80, dest=0x907c, buffer=0x60021de0 "1", length=8) at /proj/opensrc/nightly/src/trunk/libgfortran/io/read.c:154 154 *((GFC_REAL_8*) dest) = strtod (buffer, NULL); The dest address is not 8 byte aligned which is what is required for writing a double out to memory on IA64 due to its strong alignment requirement. -- Summary: Fortran IO using unaligned accesses to read/write doubles. Product: gcc Version: 4.5.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libfortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: sje at cup dot hp dot com GCC target triplet: ia64-hp-hpux11.23 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39665
[Bug libfortran/39664] [4.5 Regression] 436.cactusADM in SPEC CPU 2006 is miscompiled
--- Comment #1 from hjl dot tools at gmail dot com 2009-04-06 15:42 --- It may be caused by revision 145571: http://gcc.gnu.org/ml/gcc-cvs/2009-04/msg00193.html -- hjl dot tools at gmail dot com changed: What|Removed |Added CC||d at domob dot eu, jvdelisle ||at gcc dot gnu dot org Component|fortran |libfortran http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39664
[Bug fortran/39664] New: [4.5 Regression] 436.cactusADM in SPEC CPU 2006 is miscompiled
On Linux/ia32 and Linux/x86-64, revision 145573 gave: Running 436.cactusADM ref base o2 default Error with '/export/gnu/import/svn/gcc-test/spec/2006/x86_64/spec/bin/specinvoke -E -d /export/gnu/import/svn/gcc-test/spec/2006/x86_64/spec/benchspec/CPU2006/4 36.cactusADM/run/run_base_ref_o2. -c 1 -e compare.err -o compare.stdout -f c ompare.cmd': check file '/export/gnu/import/svn/gcc-test/spec/2006/x86_64/spec/b enchspec/CPU2006/436.cactusADM/run/run_base_ref_o2./.err' *** Miscompare of benchADM.out, see /export/gnu/import/svn/gcc-test/spec/2006/x8 6_64/spec/benchspec/CPU2006/436.cactusADM/run/run_base_ref_o2./benchADM.out. mis -- Summary: [4.5 Regression] 436.cactusADM in SPEC CPU 2006 is miscompiled Product: gcc Version: 4.5.0 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=39664
[Bug c++/4926] C++ ABI needs clarification on mangling of complex expressions
--- Comment #13 from jason at redhat dot com 2009-04-06 15:39 --- Subject: Re: C++ ABI needs clarification on mangling of complex expressions hjl dot tools at gmail dot com wrote: > /export/gnu/src/gcc-work/gcc/gcc/testsuite/g++.dg/template/foo.ii:45: sorry, > unimplemented: mangling template_id_expr > > Is this expected? That is in fact still unimplemented, and a good reason not to close the PR. Jason -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=4926
[Bug libstdc++/39644] [4.5 Regression]: cris-elf 17_intro/headers/c++200x/all.cc plus 3
--- Comment #22 from paolo dot carlini at oracle dot com 2009-04-06 15:32 --- Probably, somewhere, an _GLIBCXX_USE_C99_STDINT_TR1 is protecting the inclusion of itself, thus we are back to square one... If you want - as I said, I don't think it's really a good way to spend our time - you should then figure out why the configure-time tests do not enable _GLIBCXX_USE_C99_STDINT_TR1. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39644
[Bug c++/25185] deep typedef substitution in error message
--- Comment #24 from jason at redhat dot com 2009-04-06 15:32 --- Subject: Re: deep typedef substitution in error message dave at boostpro dot com wrote: > I'm confused as to why you think you need to give a still-dependent > type in the signature Because the signature we're printing is the signature of the template, not the specialization. Jason -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25185
[Bug libstdc++/39644] [4.5 Regression]: cris-elf 17_intro/headers/c++200x/all.cc plus 3
--- Comment #21 from paolo dot carlini at oracle dot com 2009-04-06 15:21 --- Interesting. Then you should really look inside the pre-processed using_namespace_std_tr1_neg.cc and see why uint_fast32_t is not known. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39644
[Bug libstdc++/39644] [4.5 Regression]: cris-elf 17_intro/headers/c++200x/all.cc plus 3
--- Comment #20 from hp at gcc dot gnu dot org 2009-04-06 15:15 --- (In reply to comment #19) > One final remark: since you are having problem with uint_fast32_t, > unqualified, > what really matters is _GLIBCXX_HAVE_STDINT_H, *not* > _GLIBCXX_USE_C99_STDINT_TR1. I see in gccobj/cris-elf/libstdc++-v3/include/cris-elf/bits/c++config.h: #define _GLIBCXX_HAVE_STDINT_H 1 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39644
[Bug tree-optimization/28868] [4.3/4.4 Regression] Not eliminating the PHIs which have the same arguments
--- Comment #20 from rguenth at gcc dot gnu dot org 2009-04-06 14:56 --- Fixed for GCC 4.5.0. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|rguenth at gcc dot gnu dot |unassigned at gcc dot gnu |org |dot org Status|ASSIGNED|NEW Known to work|3.3.3 3.2.3 2.95.3 |3.3.3 3.2.3 2.95.3 4.5.0 Summary|[4.3/4.4/4.5 Regression] Not|[4.3/4.4 Regression] Not |eliminating the PHIs which |eliminating the PHIs which |have the same arguments |have the same arguments http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28868
[Bug tree-optimization/28868] [4.3/4.4/4.5 Regression] Not eliminating the PHIs which have the same arguments
--- Comment #19 from rguenth at gcc dot gnu dot org 2009-04-06 14:55 --- Subject: Bug 28868 Author: rguenth Date: Mon Apr 6 14:55:31 2009 New Revision: 145607 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=145607 Log: 2009-04-06 Richard Guenther PR tree-optimization/28868 * tree-ssa-pre.c (inserted_phi_names): New bitmap to keep track of which PHI results we inserted. (insert_into_preds_of_block): Record inserted PHIs. (eliminate): Eliminate redundant PHI nodes. (init_pre): Init inserted_phi_names. * gcc.dg/tree-ssa/ssa-fre-21.c: New testcase. * gcc.dg/tree-ssa/ssa-sccvn-1.c: Adjust. * gcc.dg/tree-ssa/ssa-sccvn-2.c: Likewise. * gcc.dg/tree-ssa/ssa-sccvn-4.c: Likewise. Added: trunk/gcc/testsuite/gcc.dg/tree-ssa/ssa-fre-23.c Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gcc.dg/tree-ssa/ssa-sccvn-1.c trunk/gcc/testsuite/gcc.dg/tree-ssa/ssa-sccvn-2.c trunk/gcc/testsuite/gcc.dg/tree-ssa/ssa-sccvn-4.c trunk/gcc/tree-ssa-pre.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28868
[Bug libstdc++/39644] [4.5 Regression]: cris-elf 17_intro/headers/c++200x/all.cc plus 3
--- Comment #19 from paolo dot carlini at oracle dot com 2009-04-06 14:36 --- One final remark: since you are having problem with uint_fast32_t, unqualified, what really matters is _GLIBCXX_HAVE_STDINT_H, *not* _GLIBCXX_USE_C99_STDINT_TR1. Have a look to include/c_global/cstdint for details: if _GLIBCXX_HAVE_STDINT_H is not defined, then isn't really included and any facility including doesn't really include much. Thus, for your target, the basic issue, at the moment, is why _GLIBCXX_HAVE_STDINT_H is not defined. Certainly in configure.ac we are running AC_CHECK_HEADERS on stdint.h... -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39644
[Bug tree-optimization/39643] [4.5 Regression]: cris-elf gcc.dg/torture/builtin-math-3.c -O1 and -Os sincos one
--- Comment #7 from rguenth at gcc dot gnu dot org 2009-04-06 14:16 --- Subject: Bug 39643 Author: rguenth Date: Mon Apr 6 14:16:15 2009 New Revision: 145604 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=145604 Log: 2009-04-06 Richard Guenther PR tree-optimization/39643 * tree-ssa-ccp.c (ccp_fold): Fold REALPART_EXPRs and IMAGPART_EXPRs of complex constants. (execute_fold_all_builtins): If we folded a call queue TODO_update_address_taken. Modified: trunk/gcc/ChangeLog trunk/gcc/tree-ssa-ccp.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39643
[Bug tree-optimization/39643] [4.5 Regression]: cris-elf gcc.dg/torture/builtin-math-3.c -O1 and -Os sincos one
--- Comment #6 from rguenth at gcc dot gnu dot org 2009-04-06 14:16 --- Fixed. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39643
[Bug libstdc++/39644] [4.5 Regression]: cris-elf 17_intro/headers/c++200x/all.cc plus 3
--- Comment #18 from paolo dot carlini at oracle dot com 2009-04-06 14:13 --- (In reply to comment #17) > Superficially, it looks as if it fails because stdint.h isn't picked up > properly by libstdc++ (in contrast to the C test-suite) so I do think this is > worthwhile. I don't think it's worthwhile to try and make a distinction > between incomplete-target-stdint and libstdc++-stdint-include-issues before > that analysis. :) I see what you mean, but one thing is configure time, another the library proper. Again, when 448 will closed, the library will be cleaned up to not do *any* configure time checks in this area. Otherwise, , as you can see yourself is *trivial*, cannot do anything wrong with stdint.h, as doesn't do anything wrong with float.h. That said, if you notice something strange just let us know! -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39644
[Bug libstdc++/39644] [4.5 Regression]: cris-elf 17_intro/headers/c++200x/all.cc plus 3
--- Comment #17 from hp at gcc dot gnu dot org 2009-04-06 14:03 --- (In reply to comment #16) > I hope my explanation is more clear. Yes, thanks, sorry I didn't get the picture before. > The above said, I'm not sure we should spend much time trying to figure out > why > for your target the configure checks for stdint.h fail, Superficially, it looks as if it fails because stdint.h isn't picked up properly by libstdc++ (in contrast to the C test-suite) so I do think this is worthwhile. I don't think it's worthwhile to try and make a distinction between incomplete-target-stdint and libstdc++-stdint-include-issues before that analysis. :) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39644
[Bug target/39663] mingw hosted arm-elf output differs from linux hosted arm-elf when compiling with -Os and -mthumb
--- Comment #2 from info dot gnu at rt-labs dot com 2009-04-06 13:51 --- Created an attachment (id=17596) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17596&action=view) sample makefile to genererate output difference -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39663
[Bug target/39663] mingw hosted arm-elf output differs from linux hosted arm-elf when compiling with -Os and -mthumb
--- Comment #1 from info dot gnu at rt-labs dot com 2009-04-06 13:50 --- Created an attachment (id=17595) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17595&action=view) source file that cause output difference -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39663
[Bug libstdc++/39644] [4.5 Regression]: cris-elf 17_intro/headers/c++200x/all.cc plus 3
--- Comment #16 from paolo dot carlini at oracle dot com 2009-04-06 13:49 --- (In reply to comment #15) > Well *some* configure tests succeed (see "Description"), but grep says, of > cris-elf/libstdc++-v3/include/cris-elf/bits/c++config.h: > /* #undef _GLIBCXX_USE_C99_STDINT_TR1 */ Ok... > > if the tests do not pass, the issue is probably > > simpler, just matter of waiting for 448 to be closed > > I can't see that it is a matter of something depending on that PR since all > the > target stuff is there, I'm afraid you didn't get my point completely: *if* that macro above is disabled, then the library *assumes* stdint.h is *not* available, in general. In that case, *any* library code relying on stdint.h should be ifdef-out out completely, disabled. However, the author of the new std::random bits didn't take care of doing that - we have been consistently doing that, elsewhere - and in that case fails are expected. When 448 will be closed, we'll *remove* completely any configure test for stdint.h, we'll assume it's available, similarly to float.h for example, we'll unconditionally include it, and correctly unconditionally enable any facility relying on it. To summarize, right now, for std::random the library is in an inconsistent state for some targets, because the facility is unconditionally enabled but stdint.h is not unconditionally available. I hope my explanation is more clear. The above said, I'm not sure we should spend much time trying to figure out why for your target the configure checks for stdint.h fail, because, as I said above, as soon as 448 is closed, all those tests will go away, the library will simply assume stdint.h (that's the very point of 448, after all, for libstdc++ and all the other target libraries). If, however, you have reasons to believe your stdint.h is still not ok, it's really not ok, that's another matter, does not have much to do with libstdc++ proper. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39644
[Bug target/39663] New: mingw hosted arm-elf output differs from linux hosted arm-elf when compiling with -Os and -mthumb
Mingw hosted arm-elf output differs from linux hosted arm-elf when compiling
with -Os and -mthumb for the code added below. Remove -mthumb and the output
won't differ.
Mingw hosted toolchain:
Target: arm-elf
Configured with: ../gcc-4.2.2/configure --target=arm-elf
--prefix=/proj/crossgcc/arm-elf --disable-nls --with-gnu-as --with-gnu-ld
--enable-languages=c --disable-shared --disable-threads --disable-libssp
--disable-__cxa_atexit --disable-libstdcxx-pch --enable-interwork
--enable-multilib
Thread model: single
gcc version 4.2.2
Linux hosted toolchain:
Target: arm-elf
Configured with: ../gcc-4.2.2/configure --target=arm-elf
--prefix=/proj/crossgcc/arm-elf --disable-nls --with-gnu-as --with-gnu-ld
--enable-languages=c --disable-shared --disable-threads --disable-libssp
--disable-__cxa_atexit --disable-libstdcxx-pch --enable-interwork
--enable-multilib
Thread model: single
gcc version 4.2.2
arm-elf-gcc -Wall -mlittle-endian -mthumb -mthumb-interwork -Os -save-temps -c
main.c
main.c:
typedef struct pic
{
unsigned int soft_set;
unsigned int soft_clear;
} pic_t;
typedef struct isr
{
void (*func)(void *);
void * arg;
} isr_t;
static volatile pic_t * const pSIC = (pic_t *)0xCA00;
static isr_t isr_table[32];
static void isr1 (void * arg)
{
/* Clear high priority IRQ */
pSIC->soft_clear = (1 << 0);
}
int main (void)
{
/* Install interrupt handlers */
isr_table[0].func = isr1;
isr_table[0].arg = (void *)3;
while(1);
return (1);
}
regards Andreas
--
Summary: mingw hosted arm-elf output differs from linux hosted
arm-elf when compiling with -Os and -mthumb
Product: gcc
Version: 4.2.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: info dot gnu at rt-labs dot com
GCC build triplet: x86_64-unknown-linux-gnu, i686-pc-mingw32
GCC host triplet: x86_64-unknown-linux-gnu, i686-pc-mingw32
GCC target triplet: arm-elf
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39663
[Bug libstdc++/39644] [4.5 Regression]: cris-elf 17_intro/headers/c++200x/all.cc plus 3
--- Comment #15 from hp at gcc dot gnu dot org 2009-04-06 13:36 --- (In reply to comment #14) > In particular, I would like to know if on such targets stdint.h is > available at C++ library configure time, the configure tests succeed Well *some* configure tests succeed (see "Description"), but grep says, of cris-elf/libstdc++-v3/include/cris-elf/bits/c++config.h: /* #undef _GLIBCXX_USE_C99_STDINT_TR1 */ > if the tests do not pass, the issue is probably > simpler, just matter of waiting for 448 to be closed I can't see that it is a matter of something depending on that PR since all the target stuff is there, but something definitely goes wrong for libstdc++: checking for ISO C99 support to TR1 in ... no Maybe that newlib provides an incomplete stdint.h which is picked up before the gcc-generated one; I definitely see two stdint.h. Anyway, later on that bit. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39644
[Bug middle-end/39659] [4.5 Regression] ICE building libstdc++v3 functexcept.cc
--- Comment #7 from ayers at gcc dot gnu dot org 2009-04-06 12:29 --- Fixed. -- ayers at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39659
[Bug c/39661] segmentation failed on correctly compiled mixed C and C++ code
--- Comment #1 from pavel dot petrovic at gmail dot com 2009-04-06 12:28 --- *** This bug has been marked as a duplicate of 39662 *** -- pavel dot petrovic at gmail dot com changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE Summary|segmentation failed on |segmentation failed on |correctly compiled mixed C |correctly compiled mixed C |and C++ code|and C++ code http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39661
[Bug c/39662] segmentation failed on correctly compiled mixed C and C++ code
--- Comment #2 from pavel dot petrovic at gmail dot com 2009-04-06 12:28 --- *** Bug 39661 has been marked as a duplicate of this bug. *** -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39662
[Bug c/39662] segmentation failed on correctly compiled mixed C and C++ code
--- Comment #1 from pavel dot petrovic at gmail dot com 2009-04-06 12:23 --- Created an attachment (id=17594) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17594&action=view) archive with all sources, and i. .ii, .s files -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39662
[Bug c/39662] New: segmentation failed on correctly compiled mixed C and C++ code
I understand C is low-level, but I'd love the compiler to refuse to compile or
link a mixed C and C++ code that is not mixed correctly.
The story is: parts of the program are implemented in C, parts are in C++. The
functions in C++ are made callable from C using the "__attribute__((stdcall))"
feature, i.e. these are C-type functions implemented in C++. The main program
is in C, and attempts to call the C-style C++ function, which only computes a
number. The program crashes on exit from the main() function. It does not crash
if compiled using gcc/g++ version 3.3. However, removing the obsolete line "int
a = 1;" makes the program crash also when compiled using 3.3 version of the
compliers. Here are the sources:
/* fnc.h - prototype of C++ function with C-style calling style int f2(nt int)
*/
#ifdef __cplusplus
#define EXPORTCALL __attribute__((stdcall))
#else
#define EXPORTCALL
#endif
#ifdef __cplusplus
extern "C" {
#endif
extern int EXPORTCALL f2(int a, int b);
#ifdef __cplusplus
}
#endif
---
/* fnmc.h - main C program that calls a C++ function int f2(int, int) */
#include
#include "fnc.h"
int main(int argc, char **argv)
{
int a = 1;
printf("f2(2,3)=%d\n", f2(2,3));
printf("exiting...\n");
return;
}
--
/* fnc.cpp - implementation of the C++ function int f2(int, int),
using the C-calling semantics */
#include "fnc.h" /* function prototype for f2() */
/* the function only returns the result */
int EXPORTCALL f2(int a, int b)
{
return a+b;
}
--
# Makefile
GCC=gcc
GPP=g++
# GCC=gcc-3.3
# GPP=g++-3.3
all:fn3
fn3:fnc.cpp fnmc.c
$(GPP) -v -save-temps -c fnc.cpp -g
$(GCC) -v -save-temps -c fnmc.c -g
$(GPP) -v -save-temps -o fn3 fnc.o fnmc.o -g
clean:
rm -f *.o *.s *.i *.ii
rm -f fn3
Here is the what is obtained when running:
petro...@student03:~/pasCPP2$ make clean
rm -f *.o *.s *.i *.ii
rm -f fn3
petro...@student03:~/pasCPP2$ make
g++ -v -save-temps -c fnc.cpp -g
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.4 (Ubuntu 4.2.4-1ubuntu3)
/usr/lib/gcc/i486-linux-gnu/4.2.4/cc1plus -E -quiet -v -D_GNU_SOURCE fnc.cpp
-mtune=generic -fworking-directory -fpch-preprocess -o fnc.ii
ignoring nonexistent directory "/usr/local/include/i486-linux-gnu"
ignoring nonexistent directory
"/usr/lib/gcc/i486-linux-gnu/4.2.4/../../../../i486-linux-gnu/include"
ignoring nonexistent directory "/usr/include/i486-linux-gnu"
#include "..." search starts here:
#include <...> search starts here:
/usr/include/c++/4.2
/usr/include/c++/4.2/i486-linux-gnu
/usr/include/c++/4.2/backward
/usr/local/include
/usr/lib/gcc/i486-linux-gnu/4.2.4/include
/usr/include
End of search list.
/usr/lib/gcc/i486-linux-gnu/4.2.4/cc1plus -fpreprocessed fnc.ii -quiet
-dumpbase fnc.cpp -mtune=generic -auxbase fnc -g -version -fstack-protector
-fstack-protector -o fnc.s
GNU C++ version 4.2.4 (Ubuntu 4.2.4-1ubuntu3) (i486-linux-gnu)
compiled by GNU C version 4.2.4 (Ubuntu 4.2.4-1ubuntu3).
GGC heuristics: --param ggc-min-expand=98 --param ggc-min-heapsize=128358
Compiler executable checksum: cca9b7b48c023363b938f208576b99cc
as --traditional-format -V -Qy -o fnc.o fnc.s
GNU assembler version 2.18.0 (i486-linux-gnu) using BFD version (GNU Binutils
for Ubuntu) 2.18.0.20080103
gcc -v -save-temps -c fnmc.c -g
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.4 (Ubuntu 4.2.4-1ubuntu3)
/usr/lib/gcc/i486-linux-gnu/4.2.4/cc1 -E -quiet -v fnmc.c -mtune=generic
-fworking-directory -fpch-preprocess -o fnmc.i
ignoring nonexistent directory "/usr/local/include/i486-linux-gnu"
ignoring nonexistent directory
"/usr/lib/gcc/i486-linux-gnu/
[Bug c/39661] New: segmentation failed on correctly compiled mixed C and C++ code
I understand C is low-level, but I'd love the compiler to refuse to compile or link a mixed C and C++ code that is not mixed correctly. The story is: parts of the program are implemented in C, parts are in C++. The functions in C++ are made callable from C using the "__attribute__((stdcall))" feature, i.e. these are C-type functions implemented in C++. The main program is in C, and attempts to call these functions, which further call -- Summary: segmentation failed on correctly compiled mixed C and C++ code Product: gcc Version: 4.2.4 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: pavel dot petrovic at gmail dot com GCC build triplet: i486-linux-gnu GCC host triplet: i486-linux-gnu GCC target triplet: i486-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39661
[Bug middle-end/39659] [4.5 Regression] ICE building libstdc++v3 functexcept.cc
--- Comment #6 from hubicka at gcc dot gnu dot org 2009-04-06 11:24 --- Subject: Bug 39659 Author: hubicka Date: Mon Apr 6 11:24:32 2009 New Revision: 145589 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=145589 Log: PR middle-end/39659 * except.c (remove_unreachable_regions): Propagate may_contain_throw flag. Modified: trunk/gcc/ChangeLog trunk/gcc/except.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39659
[Bug bootstrap/39660] New: Mingw Bootstrap stops with "..host-mingw32.c:140: error: ISO C90 forbids mixed.."
Latest svn version (and for the past few weeks) stops in compilation with ../../gcc4svnsource/gcc/config/i386/host-mingw32.c: In function 'mingw32_gt_pch_use_address': ../../gcc4svnsource/gcc/config/i386/host-mingw32.c:140: error: ISO C90 forbids mixed declarations and code Mingw. Using a recent 4.4. -- Summary: Mingw Bootstrap stops with "..host-mingw32.c:140: error: ISO C90 forbids mixed.." Product: gcc Version: 4.4.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: bootstrap AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: arxeio at gmail dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39660
[Bug tree-optimization/39643] [4.5 Regression]: cris-elf gcc.dg/torture/builtin-math-3.c -O1 and -Os sincos one
--- Comment #5 from rguenth at gcc dot gnu dot org 2009-04-06 11:14 --- For cris-axis-elf we do not fold one_1 = 1.0e+0; oneL_2 = 1.0e+0; __builtin_sincos (1.0e+0, &s, &c); to a constant because __builtin_sincos did not get transformed to __builtin_cexpi. We fold it later via the fold-all-builtins pass but nothing promotes memory to registers after that pass with -O1. I have a patch that should fix this. -- 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 Keywords||missed-optimization Last reconfirmed|2009-04-05 22:00:23 |2009-04-06 11:14:36 date|| Target Milestone|--- |4.5.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39643
[Bug fortran/36703] ICE (segfault) in reduce_binary0 (arith.c:1778)
--- Comment #6 from pault at gcc dot gnu dot org 2009-04-06 11:07 --- Fixed on trunk and 4.4 Thanks for the report Paul -- pault at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36703
[Bug middle-end/39659] [4.5 Regression] ICE building libstdc++v3 functexcept.cc
--- Comment #5 from ayers at gcc dot gnu dot org 2009-04-06 11:07 --- Bootstrap completed successfully, thanks for the fast patch! -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39659
[Bug fortran/36528] Cray pointer to function mishandled
--- Comment #6 from pault at gcc dot gnu dot org 2009-04-06 11:07 --- Fixed on trunk and 4.4 Thanks for the report Paul -- pault at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36528
[Bug tree-optimization/39643] [4.5 Regression]: cris-elf gcc.dg/torture/builtin-math-3.c -O1 and -Os sincos one
--- Comment #4 from rguenth at gcc dot gnu dot org 2009-04-06 11:00 --- Ok, I can see at least one missed CCP optimization when looking at what the x86_64 target produces. Now building a cross to see why for cris the second CCP pass together with either FRE or DOM or the third CCP pass do not fix this. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39643
[Bug fortran/34640] ICE when assigning item of a derived-component to a pointer
--- Comment #11 from pault at gcc dot gnu dot org 2009-04-06 10:57 --- Enfin, j'aborde le boulot Paul -- pault at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |pault at gcc dot gnu dot org |dot org | Status|SUSPENDED |ASSIGNED Last reconfirmed|2008-03-14 13:24:43 |2009-04-06 10:57:29 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34640
[Bug fortran/35718] deallocating non-allocated pointer target does not fail
-- pault at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |pault at gcc dot gnu dot org |dot org | Status|SUSPENDED |ASSIGNED Last reconfirmed|2008-03-27 16:50:00 |2009-04-06 10:55:56 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35718
[Bug fortran/39304] ICE with MATMUL, specific/generic functions and rank checking
-- pault at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |pault at gcc dot gnu dot org |dot org | Status|SUSPENDED |ASSIGNED Last reconfirmed|2009-02-25 18:10:46 |2009-04-06 10:55:25 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39304
[Bug fortran/38918] compile time error for DATA of NULL() to pointer structure component
--- Comment #5 from pault at gcc dot gnu dot org 2009-04-06 10:54 --- Fixed on trunk. I am prepared to backport but the mood appears to be against it. Thanks for the report. Paul -- pault at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38918
[Bug fortran/38917] Can't use DATA to initialize pointer to array to NULL()
--- Comment #5 from pault at gcc dot gnu dot org 2009-04-06 10:54 --- Fixed on trunk. I am prepared to backport but the mood appears to be against it. Thanks for the report. Paul -- pault at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38917
[Bug fortran/38915] wrong results for structure assignment of character components when left and right sides overlap
--- Comment #7 from pault at gcc dot gnu dot org 2009-04-06 10:53 --- Fixed on trunk. I am prepared to backport but the mood appears to be against it. Thanks for the report. Paul -- pault at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38915
[Bug fortran/38538] ICE with elemental character function
--- Comment #18 from pault at gcc dot gnu dot org 2009-04-06 10:52 --- Fixed on trunk. I am prepared to backport but the mood appears to be against it. Thanks for the report. Paul -- pault at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38538
[Bug fortran/36091] false positive in bounds checking with forall
--- Comment #9 from pault at gcc dot gnu dot org 2009-04-06 10:52 --- Fixed on trunk. I am prepared to backport but the mood appears to be against it. Thanks for the report. Paul -- pault at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36091
[Bug c++/39637] ICE on ill-formed sizeof() in variadic template
--- Comment #2 from dodji at gcc dot gnu dot org 2009-04-06 10:28 --- Created an attachment (id=17593) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17593&action=view) candidate fix I am regtesting this fix atm. With it, I get the following error output from g++ trunk from today: test.cc:11: instantiated from here test.cc:5: error: enumerator value for e is not an integer constant -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39637
[Bug middle-end/39659] [4.5 Regression] ICE building libstdc++v3 functexcept.cc
--- Comment #4 from ayers at gcc dot gnu dot org 2009-04-06 10:06 --- The patch fixes the build... a new bootstrap is in progress. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39659
[Bug tree-optimization/39657] [4.3 Regression] compiling ruby (yacc) output takes inordinate amount of time on x86 with -O2
--- Comment #2 from rguenth at gcc dot gnu dot org 2009-04-06 09:39 --- tree PRE : 362.75 (97%) usr 3.30 (80%) sys 366.55 (97%) wall 7515 kB ( 8%) ggc So you can use -fno-tree-pre to work around this issue or limit the size of the SCCs processed (with the same effect) with the --param sccvn-max-scc-size -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Component|pending |tree-optimization Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2009-04-06 09:39:39 date|| Target Milestone|--- |4.3.4 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39657
