[Bug rtl-optimization/36111] [4.3/4.4 Regression] GCC 4.4.0-20080501 failed to compile openmpi's malloc.c file.
--- Comment #16 from ubizjak at gmail dot com 2008-06-08 05:55 --- (In reply to comment #15) > Fixed also for 4.3.2. See http://gcc.gnu.org/ml/gcc/2008-06/msg00172.html -- ubizjak at gmail dot com changed: What|Removed |Added Known to work|4.3.0 | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36111
[Bug rtl-optimization/36111] [4.3/4.4 Regression] GCC 4.4.0-20080501 failed to compile openmpi's malloc.c file.
--- Comment #15 from ubizjak at gmail dot com 2008-06-08 05:53 --- Fixed also for 4.3.2. -- ubizjak at gmail dot com changed: What|Removed |Added Summary|[4.4 Regression] GCC 4.4.0- |[4.3/4.4 Regression] GCC |20080501 failed to compile |4.4.0-20080501 failed to |openmpi's malloc.c file.|compile openmpi's malloc.c ||file. Target Milestone|4.4.0 |4.3.2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36111
[Bug c++/27941] offsetof produces possibly erroneous warnings
--- Comment #2 from tristan_schmelcher at alumni dot uwaterloo dot ca 2008-06-08 01:41 --- Just a note for posterity: Using offsetof in this particular case (and many others) will work in G++, but the standard doesn't require that, so in theory it's not portable. That's why G++ prints a warning. You can suppress it with -Wno-invalid-offsetof. -- tristan_schmelcher at alumni dot uwaterloo dot ca changed: What|Removed |Added CC||tristan_schmelcher at alumni ||dot uwaterloo dot ca http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27941
[Bug fortran/36462] KIND argument in INDEX results in wrong code
-- fxcoudert at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2008-06-08 01:22:20 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36462
[Bug fortran/36462] New: KIND argument in INDEX results in wrong code
$ cat a.f90 character(10) string string = 'ABCDEEDCBA' write(*,*) index(string,'A',kind=1) end $ gfortran a.f90 && ./a.out 10 I suspect we're passing 1 as a logical BACK argument to the library function. Well, I do more than suspect, I checked and that's indeed what we do :) Work needed in trans-intrinsic.c, probably an easy one. Will need auditing other intrinsics that were added a KIND argument in F2003. -- Summary: KIND argument in INDEX results in wrong code Product: gcc Version: 4.4.0 Status: UNCONFIRMED Keywords: wrong-code Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: fxcoudert at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36462
[Bug c/36359] [Regression] compile error in linux-kernel 2.6.26-rc4 with -O2
--- Comment #9 from pinskia at gmail dot com 2008-06-08 00:33 --- Subject: Re: [Regression] compile error in linux-kernel 2.6.26-rc4 with -O2 On Sat, Jun 7, 2008 at 5:17 PM, mt-ml at gmx dot de <[EMAIL PROTECTED]> wrote: > As you can see, the argument to ilog2 is urb->interval which can't be zero at > that point IMHO. Yes and that requires a lot of jump threading and many other optimizations to detect that really. First PRE has to be working and then VRP has to figure out it will be greater than 0. So really this code depends on optimization to work correctly and the kernel is broken that way again (not suppressing really) -- Pinski -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36359
Re: [Bug c/36359] [Regression] compile error in linux-kernel 2.6.26-rc4 with -O2
On Sat, Jun 7, 2008 at 5:17 PM, mt-ml at gmx dot de <[EMAIL PROTECTED]> wrote: > As you can see, the argument to ilog2 is urb->interval which can't be zero at > that point IMHO. Yes and that requires a lot of jump threading and many other optimizations to detect that really. First PRE has to be working and then VRP has to figure out it will be greater than 0. So really this code depends on optimization to work correctly and the kernel is broken that way again (not suppressing really) -- Pinski
[Bug fortran/36422] Misleading error message for (a0) edit descriptor
--- Comment #5 from jvdelisle at gcc dot gnu dot org 2008-06-08 00:31 --- Fixed on trunk. -- jvdelisle at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36422
[Bug fortran/36421] Gw.d edit descriptor for integer numbers: Wrong output
--- Comment #9 from jvdelisle at gcc dot gnu dot org 2008-06-08 00:30 --- Fixed on trunk. -- jvdelisle at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36421
[Bug fortran/36420] Fortran 2008: g0 edit descriptor
--- Comment #7 from jvdelisle at gcc dot gnu dot org 2008-06-08 00:30 --- New feature added. -- jvdelisle at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36420
[Bug c/36359] [Regression] compile error in linux-kernel 2.6.26-rc4 with -O2
--- Comment #8 from mt-ml at gmx dot de 2008-06-08 00:17 ---
I've been able to identify the code where ilog2 is called. If I do not choose
usbcore as a module I get the following error:
drivers/built-in.o: In function `usb_submit_urb':
(.text+0xc247f): undefined reference to `ilog2_NaN'
make: *** [.tmp_vmlinux1] Fehler 1
Observing that function usb_submit_urb() in drivers/usb/core/urb.c shows the
interesting lines should be:
case USB_ENDPOINT_XFER_INT:
/* too small? */
if (urb->interval <= 0)
return -EINVAL;
/* too big? */
switch (dev->speed) {
case USB_SPEED_HIGH:/* units are microframes */
/* NOTE usb handles 2^15 */
if (urb->interval > (1024 * 8))
urb->interval = 1024 * 8;
max = 1024 * 8;
break;
case USB_SPEED_FULL:/* units are frames/msec */
case USB_SPEED_LOW:
if (xfertype == USB_ENDPOINT_XFER_INT) {
if (urb->interval > 255)
return -EINVAL;
/* NOTE ohci only handles up to 32 */
max = 128;
} else {
if (urb->interval > 1024)
urb->interval = 1024;
/* NOTE usb and ohci handle up to 2^15 */
max = 1024;
}
break;
default:
return -EINVAL;
}
/* Round down to a power of 2, no more than max */
urb->interval = min(max, 1 << ilog2(urb->interval));
}
As you can see, the argument to ilog2 is urb->interval which can't be zero at
that point IMHO.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36359
[Bug fortran/36422] Misleading error message for (a0) edit descriptor
--- Comment #4 from jvdelisle at gcc dot gnu dot org 2008-06-08 00:09 --- Subject: Bug 36422 Author: jvdelisle Date: Sun Jun 8 00:09:01 2008 New Revision: 136547 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=136547 Log: 2008-06-07 Jerry DeLisle <[EMAIL PROTECTED]> PR fortran/36420 PR fortran/36421 PR fortran/36422 * gfortran.dg/fmt_g0_1.f08: New test. * gfortran.dg/fmt_g0_2.f08: New test. * gfortran.dg/fmt_g0_3.f08: New test. Added: trunk/gcc/testsuite/gfortran.dg/fmt_g0_1.f08 trunk/gcc/testsuite/gfortran.dg/fmt_g0_2.f08 trunk/gcc/testsuite/gfortran.dg/fmt_g0_3.f08 Modified: trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36422
[Bug fortran/36420] Fortran 2008: g0 edit descriptor
--- Comment #6 from jvdelisle at gcc dot gnu dot org 2008-06-08 00:09 --- Subject: Bug 36420 Author: jvdelisle Date: Sun Jun 8 00:09:01 2008 New Revision: 136547 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=136547 Log: 2008-06-07 Jerry DeLisle <[EMAIL PROTECTED]> PR fortran/36420 PR fortran/36421 PR fortran/36422 * gfortran.dg/fmt_g0_1.f08: New test. * gfortran.dg/fmt_g0_2.f08: New test. * gfortran.dg/fmt_g0_3.f08: New test. Added: trunk/gcc/testsuite/gfortran.dg/fmt_g0_1.f08 trunk/gcc/testsuite/gfortran.dg/fmt_g0_2.f08 trunk/gcc/testsuite/gfortran.dg/fmt_g0_3.f08 Modified: trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36420
[Bug fortran/36421] Gw.d edit descriptor for integer numbers: Wrong output
--- Comment #8 from jvdelisle at gcc dot gnu dot org 2008-06-08 00:09 --- Subject: Bug 36421 Author: jvdelisle Date: Sun Jun 8 00:09:01 2008 New Revision: 136547 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=136547 Log: 2008-06-07 Jerry DeLisle <[EMAIL PROTECTED]> PR fortran/36420 PR fortran/36421 PR fortran/36422 * gfortran.dg/fmt_g0_1.f08: New test. * gfortran.dg/fmt_g0_2.f08: New test. * gfortran.dg/fmt_g0_3.f08: New test. Added: trunk/gcc/testsuite/gfortran.dg/fmt_g0_1.f08 trunk/gcc/testsuite/gfortran.dg/fmt_g0_2.f08 trunk/gcc/testsuite/gfortran.dg/fmt_g0_3.f08 Modified: trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36421
[Bug fortran/36422] Misleading error message for (a0) edit descriptor
--- Comment #3 from jvdelisle at gcc dot gnu dot org 2008-06-08 00:00 --- Subject: Bug 36422 Author: jvdelisle Date: Sat Jun 7 23:59:53 2008 New Revision: 136545 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=136545 Log: 2008-06-07 Jerry DeLisle <[EMAIL PROTECTED]> PR libfortran/36420 PR libfortran/36421 PR libfortran/36422 * io/io.h: Add prototype for write_real. * io/transfer.c (formatted_transfer_scalar): For FMT_G and width zero, use write_real. * io/format.c: Add zero width error message. (parse_format_list): Use error message for FMT_A if followed by FMT_ZERO. Use zero width error message for FMT_G if mode is READ or if -std=f95 or f2003. (fmormat0): Fix typo in comment. * io/write.c (write_a): Set wlen to len if FMT_G and length is zero. (write_l): Add wlen variable and use it if FMT_G and width is zero. (write_decimal): If FMT_G, set m to -1 to flag processor dependent formatting. (write_real): Remove static declaration. Modified: trunk/libgfortran/ChangeLog trunk/libgfortran/io/format.c trunk/libgfortran/io/io.h trunk/libgfortran/io/transfer.c trunk/libgfortran/io/write.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36422
[Bug fortran/36420] Fortran 2008: g0 edit descriptor
--- Comment #5 from jvdelisle at gcc dot gnu dot org 2008-06-08 00:00 --- Subject: Bug 36420 Author: jvdelisle Date: Sat Jun 7 23:59:53 2008 New Revision: 136545 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=136545 Log: 2008-06-07 Jerry DeLisle <[EMAIL PROTECTED]> PR libfortran/36420 PR libfortran/36421 PR libfortran/36422 * io/io.h: Add prototype for write_real. * io/transfer.c (formatted_transfer_scalar): For FMT_G and width zero, use write_real. * io/format.c: Add zero width error message. (parse_format_list): Use error message for FMT_A if followed by FMT_ZERO. Use zero width error message for FMT_G if mode is READ or if -std=f95 or f2003. (fmormat0): Fix typo in comment. * io/write.c (write_a): Set wlen to len if FMT_G and length is zero. (write_l): Add wlen variable and use it if FMT_G and width is zero. (write_decimal): If FMT_G, set m to -1 to flag processor dependent formatting. (write_real): Remove static declaration. Modified: trunk/libgfortran/ChangeLog trunk/libgfortran/io/format.c trunk/libgfortran/io/io.h trunk/libgfortran/io/transfer.c trunk/libgfortran/io/write.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36420
[Bug fortran/36421] Gw.d edit descriptor for integer numbers: Wrong output
--- Comment #7 from jvdelisle at gcc dot gnu dot org 2008-06-08 00:00 --- Subject: Bug 36421 Author: jvdelisle Date: Sat Jun 7 23:59:53 2008 New Revision: 136545 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=136545 Log: 2008-06-07 Jerry DeLisle <[EMAIL PROTECTED]> PR libfortran/36420 PR libfortran/36421 PR libfortran/36422 * io/io.h: Add prototype for write_real. * io/transfer.c (formatted_transfer_scalar): For FMT_G and width zero, use write_real. * io/format.c: Add zero width error message. (parse_format_list): Use error message for FMT_A if followed by FMT_ZERO. Use zero width error message for FMT_G if mode is READ or if -std=f95 or f2003. (fmormat0): Fix typo in comment. * io/write.c (write_a): Set wlen to len if FMT_G and length is zero. (write_l): Add wlen variable and use it if FMT_G and width is zero. (write_decimal): If FMT_G, set m to -1 to flag processor dependent formatting. (write_real): Remove static declaration. Modified: trunk/libgfortran/ChangeLog trunk/libgfortran/io/format.c trunk/libgfortran/io/io.h trunk/libgfortran/io/transfer.c trunk/libgfortran/io/write.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36421
[Bug fortran/36420] Fortran 2008: g0 edit descriptor
--- Comment #4 from jvdelisle at gcc dot gnu dot org 2008-06-07 23:56 --- Subject: Bug 36420 Author: jvdelisle Date: Sat Jun 7 23:55:47 2008 New Revision: 136544 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=136544 Log: 2008-06-07 Jerry DeLisle <[EMAIL PROTECTED]> PR fortran/36420, 36422 * io.c (check_format): Add new error message for zero width. Use new error message for FMT_A and with READ, FMT_G. Allow FMT_G with WRITE except when -std=F95 and -std=F2003. Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/io.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36420
[Bug tree-optimization/34976] verify_ssa ICE with -ftree-loop-linear
--- Comment #7 from spop at gcc dot gnu dot org 2008-06-07 22:59 --- Fixed both in 4.3 and in trunk. -- spop at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34976
[Bug tree-optimization/34976] verify_ssa ICE with -ftree-loop-linear
--- Comment #6 from spop at gcc dot gnu dot org 2008-06-07 22:58 --- Subject: Bug 34976 Author: spop Date: Sat Jun 7 22:57:55 2008 New Revision: 136543 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=136543 Log: 2008-05-08 Sebastian Pop <[EMAIL PROTECTED]> PR tree-optimization/34976 * tree-loop-linear.c (try_interchange_loops): Look at size of caches: don't transform if the smallest stride is larger than the L2 cache, or if the largest stride multiplied by the number of iterations is smaller than the L1 cache. * testsuite/gcc.dg/tree-ssa/ltrans-8.c: Fix outer loop strides to be large enough to not be in L1 cache. Modified: branches/gcc-4_3-branch/gcc/ChangeLog branches/gcc-4_3-branch/gcc/testsuite/ChangeLog branches/gcc-4_3-branch/gcc/testsuite/gcc.dg/tree-ssa/ltrans-8.c branches/gcc-4_3-branch/gcc/tree-loop-linear.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34976
[Bug fortran/36459] Wrong interface use for PROCEDURE(
--- Comment #3 from burnus at gcc dot gnu dot org 2008-06-07 21:15 --- > This is the same check that's done in resolve.c (resolve_actual_arglist) for > dummy procedures. Thanks for the quick patch. (Do you think my patch for PR35830 is OK? Off topic: I'd really like to see proc pointers being checked in; one can still work afterwards on related PRs such as PR36322 or loosely related PRs PR35831 and PR36426.) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36459
[Bug rtl-optimization/36111] [4.4 Regression] GCC 4.4.0-20080501 failed to compile openmpi's malloc.c file.
--- Comment #14 from uros at gcc dot gnu dot org 2008-06-07 21:14 --- Subject: Bug 36111 Author: uros Date: Sat Jun 7 21:13:29 2008 New Revision: 136538 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=136538 Log: Backport from mainline: 2008-05-12 Uros Bizjak <[EMAIL PROTECTED]> PR rtl-optimization/36111 * recog.c (validate_replace_rtx_1): Unshare new RTL expression that was created for swappable operands. testsuite/ChangeLog: Backport from mainline: 2008-05-12 Uros Bizjak <[EMAIL PROTECTED]> PR rtl-optimization/36111 * gcc.dg/pr36111.c: New test. Added: branches/gcc-4_3-branch/gcc/testsuite/gcc.dg/pr36111.c Modified: branches/gcc-4_3-branch/gcc/ChangeLog branches/gcc-4_3-branch/gcc/recog.c branches/gcc-4_3-branch/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36111
[Bug fortran/36459] Wrong interface use for PROCEDURE(
--- Comment #2 from janus at gcc dot gnu dot org 2008-06-07 21:01 --- This patch fixes both of the test cases in comment #0 and comment#1: Index: gcc/fortran/decl.c === --- gcc/fortran/decl.c (revision 136533) +++ gcc/fortran/decl.c (working copy) @@ -4085,8 +4085,10 @@ match_procedure_decl (void) return MATCH_ERROR; } /* Handle intrinsic procedures. */ - if (gfc_intrinsic_name (proc_if->name, 0) - || gfc_intrinsic_name (proc_if->name, 1)) + if (!(proc_if->attr.external || proc_if->attr.use_assoc + || proc_if->attr.if_source == IFSRC_IFBODY) + && (gfc_intrinsic_name (proc_if->name, 0) + || gfc_intrinsic_name (proc_if->name, 1))) proc_if->attr.intrinsic = 1; if (proc_if->attr.intrinsic && !gfc_intrinsic_actual_ok (proc_if->name, 0)) This is the same check that's done in resolve.c (resolve_actual_arglist) for dummy procedures. -- janus at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |janus at gcc dot gnu dot org |dot org | Status|NEW |ASSIGNED Last reconfirmed|2008-06-07 20:15:13 |2008-06-07 21:01:38 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36459
[Bug c++/36460] No space between >'s not always handled in C++0x
--- Comment #1 from pinskia at gcc dot gnu dot org 2008-06-07 20:21 --- Really this is why think C++0x was wrong in thinking that >> can be used as "> >" in the template context :). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36460
[Bug c++/36461] New: [C++-0X] Exception throws don't use rvalue reference constructors
I will firstly admit that I don't know if exception throws /should/ use rvalue reference constructors - the proposed working at http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2006/n2118.html doesn't mention it, but one certainly would have thought it would. In my project I have a destructively copied exception class. Currently, the standard copy constructor simply moves a pointer to an internal state object which contains a large amount of debug data eg; stack backtraces. Without this the debug build can be very slow and stack usage dangerous (there is a bug in MSVC where copy construction of an exception during a throw doesn't release previous copies which causes quick exhaustion of the stack). I have tried to add an rvalue reference constructor under the idea that with -std=c++0x it would implement move semantics more legally than at current. Unfortunately, g++ really wants to use the copy constructor for a thrown exception and won't accept a rvalue copy constructor. Is this intentional? -- Summary: [C++-0X] Exception throws don't use rvalue reference constructors Product: gcc Version: 4.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: s_gccbugzilla at nedprod dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36461
[Bug libfortran/35863] [F2003] Implement ENCODING="UTF-8"
--- Comment #5 from jvdelisle at gcc dot gnu dot org 2008-06-07 20:18 --- Working on this now. -- 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|NEW |ASSIGNED Last reconfirmed|2008-04-14 18:55:43 |2008-06-07 20:18:41 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35863
[Bug c++/36460] New: No space between >'s not always handled in C++0x
template
class A {};
template
class B {};
A > x;
If you leave out the space between the two >'s at the definition of x, it fails
to compile. As far as I'm aware this should work in C++0x mode. The compiler
was run with -std=c++0x.
[EMAIL PROTECTED]:~/atlantisos/kernel$ g++ -v
Using built-in specs.
Target: i686-pc-linux-gnu
Configured with: ./configure --enable-languages=c,c++
Thread model: posix
gcc version 4.3.1 (GCC)
[EMAIL PROTECTED]:~/atlantisos/kernel$ uname -a
Linux blackbox 2.6.17.13 #12 SMP PREEMPT Fri Jun 22 23:13:07 CEST 2007 i686
Intel(R) Pentium(R) D CPU 2.66GHz GenuineIntel GNU/Linux
--
Summary: No space between >'s not always handled in C++0x
Product: gcc
Version: 4.3.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: peterbindels at gmail dot com
GCC build triplet: i486-slackware-linux
GCC host triplet: i486-slackware-linux
GCC target triplet: i586-pc-elf
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36460
[Bug fortran/36459] Wrong interface use for PROCEDURE(
--- Comment #1 from janus at gcc dot gnu dot org 2008-06-07 20:15 --- > The problem is that gfortran assigns the interface > of the INTRINSIC function "cos" to "f" You surely mean the intrinsic function DIM ;) > If one uses "interface" instead of "abstract interface" it works. No, for me it actually doesn't make a difference. In particular the following is also rejected: interface integer function dim() end function end interface procedure(dim) :: f print *, dim() end Without the PROCEDURE line it works fine. -- janus at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2008-06-07 20:15:13 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36459
[Bug testsuite/36458] [4.4 Regression] Invalid fortran-torture -msse2 tests on Athlon XP
--- Comment #2 from tkoenig at gcc dot gnu dot org 2008-06-07 19:24 --- I didn't compile it that way myself; those are testsuite failures. -- tkoenig at gcc dot gnu dot org changed: What|Removed |Added Status|RESOLVED|UNCONFIRMED Resolution|INVALID | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36458
[Bug fortran/36437] Simplify argument to [c_]sizeof
--- Comment #4 from burnus at gcc dot gnu dot org 2008-06-07 18:57 --- F2008's C_SIZEOF is implemented and also the simplification in trans-*.c. The simplification for arrays in simplify.c is missing; attachment 15721 can be used as starting point. -- burnus at gcc dot gnu dot org changed: What|Removed |Added Summary|F2008: Support c_sizeof // |Simplify argument to |Simplify argument to|[c_]sizeof |[c_]sizeof | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36437
[Bug fortran/36437] F2008: Support c_sizeof // Simplify argument to [c_]sizeof
--- Comment #3 from burnus at gcc dot gnu dot org 2008-06-07 18:53 --- Subject: Bug 36437 Author: burnus Date: Sat Jun 7 18:53:07 2008 New Revision: 136536 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=136536 Log: 2008-06-04 Tobias Burnus <[EMAIL PROTECTED]> PR fortran/36437 * intrinsic.c (add_functions): Implement c_sizeof. * trans-intrinsic.c (gfc_conv_intrinsic_sizeof): Do not create unneeded variable in the scalar case. 2008-06-04 Tobias Burnus <[EMAIL PROTECTED]> PR fortran/36437 * gfortran.dg/c_sizeof_1.f90: New. * gfortran.dg/c_sizeof_2.f90: New. Added: trunk/gcc/testsuite/gfortran.dg/c_sizeof_1.f90 trunk/gcc/testsuite/gfortran.dg/c_sizeof_2.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/intrinsic.c trunk/gcc/fortran/intrinsic.texi trunk/gcc/fortran/trans-intrinsic.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36437
[Bug testsuite/36458] [4.4 Regression] Invalid fortran-torture -msse2 tests on Athlon XP
--- Comment #1 from ubizjak at gmail dot com 2008-06-07 18:44 --- Don't compile with -msse2 if your target doesn't support SSE2. Tests works OK with: flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx lm constant _tsc arch_perfmon pebs bts rep_good pni monitor ds_cpl vmx est tm2 ssse3 cx16 xt pr lahf_lm -- ubizjak at gmail dot com changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36458
[Bug fortran/36459] New: Wrong interface use for PROCEDURE(
The following valid program is rejected. The problem is that gfortran assigns the interface of the INTRINSIC function "cos" to "f" and not the one of the abstract interface. If one uses "interface" instead of "abstract interface" it works. abstract interface function dim() integer :: dim end function dim end interface procedure(dim) :: f print *, f() end -- Summary: Wrong interface use for PROCEDURE(http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36459
[Bug fortran/35830] ICE with PROCEDURE() containing array formal arguments
--- Comment #13 from burnus at gcc dot gnu dot org 2008-06-07 17:43 --- MINE :-) -- burnus at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|janus at gcc dot gnu dot org|burnus at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35830
[Bug fortran/35830] ICE with PROCEDURE() containing array formal arguments
--- Comment #12 from burnus at gcc dot gnu dot org 2008-06-07 17:30 --- It turned out to be a attr-related thing. f needs to be 0 in the following and it was 1: trans-expr.c:2525 gfc_conv_function_call int f; f = (fsym != NULL) && !(fsym->attr.pointer || fsym->attr.allocatable) && fsym->as->type != AS_ASSUMED_SHAPE; f = f || !sym->attr.always_explicit; The problem is that sym->attr.always_explicit is 0 instead of 1. Index: gcc/fortran/resolve.c === --- gcc/fortran/resolve.c (Revision 136517) +++ gcc/fortran/resolve.c (Arbeitskopie) @@ -7905,6 +7905,7 @@ resolve_symbol (gfc_symbol *sym) sym->ts.interface = ifc; sym->attr.function = ifc->attr.function; sym->attr.subroutine = ifc->attr.subroutine; + sym->attr.always_explicit = ifc->attr.always_explicit; copy_formal_args (sym, ifc); } else if (sym->ts.interface->name[0] != '\0') -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35830
[Bug testsuite/36458] New: [4.4 Regression] Invalid fortran-torture -msse2 tests on Athlon XP
FAIL: gfortran.fortran-torture/execute/common.f90 execution, -O2 -ftree-vectorize -msse2 FAIL: gfortran.fortran-torture/execute/common_size.f90 execution, -O2 -ftree-vectorize -msse2 FAIL: gfortran.fortran-torture/execute/forall_3.f90 execution, -O2 -ftree-vectorize -msse2 FAIL: gfortran.fortran-torture/execute/forall_5.f90 execution, -O2 -ftree-vectorize -msse2 FAIL: gfortran.fortran-torture/execute/in-pack.f90 execution, -O2 -ftree-vectorize -msse2 FAIL: gfortran.fortran-torture/execute/ptr.f90 execution, -O2 -ftree-vectorize -msse2 FAIL: gfortran.fortran-torture/execute/scalarize.f90 execution, -O2 -ftree-vectorize -msse2 FAIL: gfortran.fortran-torture/execute/scalarize2.f90 execution, -O2 -ftree-vectorize -msse2 FAIL: gfortran.fortran-torture/execute/seq_io.f90 execution, -O2 -ftree-vectorize -msse2 FAIL: gfortran.fortran-torture/execute/stack_varsize.f90 execution, -O2 -ftree-vectorize -msse2 FAIL: gfortran.fortran-torture/execute/where_2.f90 execution, -O2 -ftree-vectorize -msse2 FAIL: gfortran.fortran-torture/execute/where_7.f90 execution, -O2 -ftree-vectorize -msse2 FAIL: gfortran.fortran-torture/execute/where_8.f90 execution, -O2 -ftree-vectorize -msse2 $ cat /proc/cpuinfo processor : 0 vendor_id : AuthenticAMD cpu family : 6 model : 8 model name : AMD Athlon(TM) XP 2600+ stepping: 1 cpu MHz : 2083.200 cache size : 256 KB fdiv_bug: no hlt_bug : no f00f_bug: no coma_bug: no fpu : yes fpu_exception : yes cpuid level : 1 wp : yes flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 mmx fxsr sse syscall mmxext 3dnowext 3dnow up ts bogomips: 4170.06 clflush size: 32 -- Summary: [4.4 Regression] Invalid fortran-torture -msse2 tests on Athlon XP Product: gcc Version: 4.4.0 Status: UNCONFIRMED Severity: minor Priority: P3 Component: testsuite AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: tkoenig at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36458
[Bug fortran/35830] ICE with PROCEDURE() containing array formal arguments
--- Comment #11 from burnus at gcc dot gnu dot org 2008-06-07 17:04 ---
> rev. 136130 contains the fixes from comment #2 and comment #3, but the test
> case from comment #1 is still failing.
Diff between dumped tree from comment #6 (working) and comment #1 (failing):
- f (&parm.38);
+ D.1203 = _gfortran_internal_pack (&parm.38);
+ f (D.1203);
[...]
That means that the argument of f is regarded as assumed-size array ("a(*)")
instead of as assumed-size array ("a(:)"). This happens for instance when the
interface of "f" is not known (or when as->type is wrong).
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35830
[Bug fortran/36379] preprocessing preprocessed output: invalid reads
--- Comment #5 from dfranke at gcc dot gnu dot org 2008-06-07 16:51 --- This should help: + cpp_option->char_precision = TYPE_PRECISION (char_type_node); However, now I'm stuck with an ordering problem ... -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36379
[Bug fortran/36426] Endless loop in gfc_apply_interface_mapping_to_expr
--- Comment #1 from burnus at gcc dot gnu dot org 2008-06-07 16:47 ---
Backtrace:
in gfc_getmem (n=40) at gcc/fortran/misc.c:37
in gfc_get_interface_mapping_charlen at gcc/fortran/trans-expr.c:1485
in gfc_apply_interface_mapping_to_expr at gcc/fortran/trans-expr.c:1920
in gfc_apply_interface_mapping_to_expr at gcc/fortran/trans-expr.c:1955
[... last two lines repeat several times ...]
in gfc_finish_interface_mappingat gcc/fortran/trans-expr.c:1695
in gfc_conv_function_call at gcc/fortran/trans-expr.c:2637
In gfc_apply_interface_mapping_to_expr, first a EXPR_FUNCTION with expr->name
"__len_1_i4" is mapped; then a BT_CHARACTER EXPR_VARIABLE, then a function
"__len_1_i4" then ...
Line 1955 is:
case EXPR_FUNCTION:
for (actual = expr->value.function.actual; actual; actual = actual->next)
gfc_apply_interface_mapping_to_expr (mapping, actual->expr);
Line 1920 is:
if (expr->ts.type == BT_CHARACTER && expr->ts.cl)
{
expr->ts.cl = gfc_get_interface_mapping_charlen (mapping, expr->ts.cl);
* * *
The essential part of the bug is that the length of the return value depends on
the dummy argument. Reduced test:
interface
function foo(x)
character(len=len(x)) :: foo,x
end function foo
end interface
character(len=20) :: str
str = foo("Hello")
end
Important is that both foo and x are "len(x)", if x has len=*, it works.
At the end the call looks / should look like
foo ((character(kind=1)[1:5] *) &str.1, 5, D.1017, 5);
(as generated with "(len=*) :: x")
--
burnus at gcc dot gnu dot org changed:
What|Removed |Added
Known to fail||4.3.0 4.4.0
Summary|Compiling tiny prog: Stack |Endless loop in
|overflow; uses PROCEDURE|gfc_apply_interface_mapping_
||to_expr
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36426
[Bug fortran/36371] [4.3/4.4 Regression] Wrong locus for errors in DATA statement
--- Comment #1 from pault at gcc dot gnu dot org 2008-06-07 16:17 --- (In reply to comment #0) This comes about, indirectly, because of simplification. Change the the index of the first item in the data list for 'c' to 2, for example. This can be tracked back to resolve.c (check_data_variable), where the call to gfc_check_assign is gfc_check_assign (var->expr, values.vnode->expr, 0); The rvalue, values.vnode->expr, is used for the locus in the error. Since it has been simplfied here, the error results. Using the lvalue expression at least hits the data statement. I notice that the only customer for gfc_check_assign with 'conform' == 0 is check_data_variable. It might be better to take account of this in the call. I'll do it. 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|NEW |ASSIGNED Last reconfirmed|2008-05-29 21:05:37 |2008-06-07 16:17:12 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36371
[Bug fortran/36379] preprocessing preprocessed output: invalid reads
--- Comment #4 from dfranke at gcc dot gnu dot org 2008-06-07 16:06 --- Some progress: libcpp, charset.c (emit_numeric_escape): here cvt.width != CPP_OPTION (pfile, char_precision) [0 != 8] If the logic of the check is inverted, everything works as expected. This indicates that something might be missing in the setup of libcpp? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36379
[Bug target/30243] [4.1/4.2/4.3/4.4 Regression][avr] signbit() causes an internal compiler error
--- Comment #12 from hutchinsonandy at gcc dot gnu dot org 2008-06-07 15:49 --- Subject: Bug 30243 Author: hutchinsonandy Date: Sat Jun 7 15:48:25 2008 New Revision: 136531 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=136531 Log: Backports from 4.4 PR target/27386 * config/avr/avr.h: (PUSH_ROUNDING): Remove. PR target/30243 * builtins.c (expand_builtin_signbit): Don't take lowpart when register is already smaller or equal to required mode. PR target/34932 * config/avr/avr.md (*addhi3_zero_extend2): Remove. * config/avr/avr.h (MAX_OFILE_ALIGNMENT): Define. Modified: branches/gcc-4_3-branch/gcc/ChangeLog branches/gcc-4_3-branch/gcc/builtins.c branches/gcc-4_3-branch/gcc/config/avr/avr.h branches/gcc-4_3-branch/gcc/config/avr/avr.md -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30243
[Bug target/34932] [avr] ICE in reload
--- Comment #7 from hutchinsonandy at gcc dot gnu dot org 2008-06-07 15:49 --- Subject: Bug 34932 Author: hutchinsonandy Date: Sat Jun 7 15:48:25 2008 New Revision: 136531 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=136531 Log: Backports from 4.4 PR target/27386 * config/avr/avr.h: (PUSH_ROUNDING): Remove. PR target/30243 * builtins.c (expand_builtin_signbit): Don't take lowpart when register is already smaller or equal to required mode. PR target/34932 * config/avr/avr.md (*addhi3_zero_extend2): Remove. * config/avr/avr.h (MAX_OFILE_ALIGNMENT): Define. Modified: branches/gcc-4_3-branch/gcc/ChangeLog branches/gcc-4_3-branch/gcc/builtins.c branches/gcc-4_3-branch/gcc/config/avr/avr.h branches/gcc-4_3-branch/gcc/config/avr/avr.md -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34932
[Bug target/27386] AVR: wrong code generated when passing three uint64_t arguments to function
--- Comment #17 from hutchinsonandy at gcc dot gnu dot org 2008-06-07 15:49 --- Subject: Bug 27386 Author: hutchinsonandy Date: Sat Jun 7 15:48:25 2008 New Revision: 136531 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=136531 Log: Backports from 4.4 PR target/27386 * config/avr/avr.h: (PUSH_ROUNDING): Remove. PR target/30243 * builtins.c (expand_builtin_signbit): Don't take lowpart when register is already smaller or equal to required mode. PR target/34932 * config/avr/avr.md (*addhi3_zero_extend2): Remove. * config/avr/avr.h (MAX_OFILE_ALIGNMENT): Define. Modified: branches/gcc-4_3-branch/gcc/ChangeLog branches/gcc-4_3-branch/gcc/builtins.c branches/gcc-4_3-branch/gcc/config/avr/avr.h branches/gcc-4_3-branch/gcc/config/avr/avr.md -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27386
[Bug fortran/36457] New: preprocessing: option -idirafter undefined for fortran
http://gcc.gnu.org/ml/fortran/2008-06/msg00048.html For the sake of completeness, I want to flag that with recent snapshots of GFortran, on CYGWIN, there are the following warnings, also with a simple test-case: $ cat hello.F95 program hello print *,'Hello World!' end program hello $ gfortran hello.F95 f951: warning: command line option "-idirafter" is valid for C/C++/ObjC/ObjC++ but not for Fortran -- Summary: preprocessing: option -idirafter undefined for fortran Product: gcc Version: 4.4.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: dfranke at gcc dot gnu dot org ReportedBy: dfranke at gcc dot gnu dot org GCC host triplet: cygwin http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36457
[Bug tree-optimization/36439] [4.3/4.4 Regression] infinite loop in PRE building gimp-plugin-registry
--- Comment #4 from dirtyepic at gentoo dot org 2008-06-07 14:39 --- Created an attachment (id=15728) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15728&action=view) smaller testcase -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36439
[Bug libstdc++/36456] can't build gcc 4.3.1
--- Comment #4 from paolo dot carlini at oracle dot com 2008-06-07 13:36 --- By the way, loads of people use OpenSUSE, myself included, and 10.3 at least is certainly fine. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36456
[Bug libstdc++/36456] can't build gcc 4.3.1
--- Comment #3 from paolo dot carlini at oracle dot com 2008-06-07 13:34 --- *** This bug has been marked as a duplicate of 30915 *** -- paolo dot carlini at oracle dot com changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36456
[Bug libstdc++/30915] [4.3 regression] bootstrap fails while building libstdc++-v3 on x86_64-pc-linux-gnu
--- Comment #30 from paolo dot carlini at oracle dot com 2008-06-07 13:34 --- *** Bug 36456 has been marked as a duplicate of this bug. *** -- paolo dot carlini at oracle dot com changed: What|Removed |Added CC||wbrana at gmail dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30915
[Bug libstdc++/36456] can't build gcc 4.3.1
--- Comment #2 from wbrana at gmail dot com 2008-06-07 13:33 --- I'm using Gentoo x86_64. It seems that bug 30915 isn't fixed. There is comment in 30915, that bug appears also on SUSE. I tried patch from 30915. It fails: patching file fixincludes/fixincl.x Hunk #1 FAILED at 2. Hunk #2 succeeded at 6355 (offset 6 lines). 1 out of 2 hunks FAILED -- saving rejects to file fixincludes/fixincl.x.rej patching file fixincludes/inclhack.def Hunk #1 succeeded at 3476 (offset 19 lines). -- wbrana at gmail dot com changed: What|Removed |Added Status|WAITING |UNCONFIRMED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36456
[Bug fortran/36379] preprocessing preprocessed output: invalid reads
--- Comment #3 from dfranke at gcc dot gnu dot org 2008-06-07 12:56 ---
Traced this down to libcpp, charset.c(cpp_interpret_string). There, the 'to'
string is not properly NUL-terminated, although the comments indicate that this
is the intention of the code.
Example:
$> cat x.f90
# 1 "y.f90"
end
(gdb) break do_linemarker
(gdb) run -cpp dummy -E x.f90
[step to cpp_interpret_string]
(gdb) print *from
[at beginning of cpp_interpret_string]
$19 = {len = 7, text = 0x89dd3d1 "\"y.f90\""}
[at end of cpp_interpret_string]
(gdb) print *to
$39 = {len = 5, text = 0x89d3f48 "y.f90òô·"}
$> valgrind f951 -cpp dummy -E x.f90
[...]
==29785== Invalid read of size 1
==29785==at 0x805995F: print_line (cpp.c:755)
==29785==by 0x8059BAF: cb_file_change (cpp.c:811)
==29785==by 0x87C6865: do_linemarker (directives.c:993)
==29785==by 0x87C543E: _cpp_handle_directive (directives.c:483)
==29785==by 0x87D427F: _cpp_scan_out_logical_line (traditional.c:634)
==29785==by 0x87D4961: _cpp_read_logical_line_trad (traditional.c:305)
==29785==by 0x805981D: scan_translation_unit_trad (cpp.c:701)
==29785==by 0x805945B: gfc_cpp_preprocess (cpp.c:568)
==29785==by 0x80B0C0C: gfc_new_file (scanner.c:1929)
==29785==by 0x80C74E7: gfc_init (f95-lang.c:303)
==29785==by 0x8374465: toplev_main (toplev.c:2045)
==29785==by 0x8114E81: main (main.c:35)
==29785== Address 0x425bd25 is 0 bytes after a block of size 5 alloc'd
==29785==at 0x402298D: realloc (vg_replace_malloc.c:429)
==29785==by 0x87E8066: xrealloc (xmalloc.c:179)
==29785==by 0x87D61AF: cpp_interpret_string (charset.c:1392)
==29785==by 0x87D6B42: cpp_interpret_string_notranslate (charset.c:1416)
==29785==by 0x87C689D: do_linemarker (directives.c:956)
==29785==by 0x87C543E: _cpp_handle_directive (directives.c:483)
==29785==by 0x87D427F: _cpp_scan_out_logical_line (traditional.c:634)
==29785==by 0x87D4961: _cpp_read_logical_line_trad (traditional.c:305)
==29785==by 0x805981D: scan_translation_unit_trad (cpp.c:701)
==29785==by 0x805945B: gfc_cpp_preprocess (cpp.c:568)
==29785==by 0x80B0C0C: gfc_new_file (scanner.c:1929)
==29785==by 0x80C74E7: gfc_init (f95-lang.c:303)
[...]
Interestingly, an equivalent c-code does not give the invalid reads. Either the
C-frontend does account for this, or it works by chance?!
Added Tom Tromey as CC.
Tom any insights from your point of view?
--
dfranke at gcc dot gnu dot org changed:
What|Removed |Added
CC||tromey at gcc dot gnu dot
||org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36379
[Bug libstdc++/36456] can't build gcc 4.3.1
--- Comment #1 from paolo dot carlini at oracle dot com 2008-06-07 12:02 --- Reminds me 30915... Gentoo? Did any recent previous release work for you? -- paolo dot carlini at oracle dot com changed: What|Removed |Added Status|UNCONFIRMED |WAITING http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36456
[Bug c++/35242] [4.3/4.4 regression] ICE with invalid specialization of variadic template
--- Comment #3 from paolo dot carlini at oracle dot com 2008-06-07 11:58 --- On it. -- paolo dot carlini at oracle dot com changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |paolo dot carlini at oracle |dot org |dot com Status|NEW |ASSIGNED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35242
[Bug libstdc++/36456] New: can't build gcc 4.3.1
make[4]: Entering directory `/home/x/workspace/build/x86_64-unknown-linux-gnu/libstdc++-v3/src' /bin/sh ../libtool --tag CXX --mode=compile /home/x/workspace/build/./gcc/xgcc -shared-libgcc -B/home/x/workspace/build/./gcc -nostdinc++ -L/home/x/workspace/build/x86_64-unknown-linux-gnu/libstdc++-v3/src -L/home/x/workspace/build/x86_64-unknown-linux-gnu/libstdc++-v3/src/.libs -B/usr/local/gcc/x86_64-unknown-linux-gnu/bin/ -B/usr/local/gcc/x86_64-unknown-linux-gnu/lib/ -isystem /usr/local/gcc/x86_64-unknown-linux-gnu/include -isystem /usr/local/gcc/x86_64-unknown-linux-gnu/sys-include -I/home/x/workspace/build/x86_64-unknown-linux-gnu/libstdc++-v3/include/x86_64-unknown-linux-gnu -I/home/x/workspace/build/x86_64-unknown-linux-gnu/libstdc++-v3/include -I/home/x/workspace/gcc-4.3.1/libstdc++-v3/libsupc++ -fno-implicit-templates -Wall -Wextra -Wwrite-strings -Wcast-qual -fdiagnostics-show-location=once -ffunction-sections -fdata-sections -g -O2 -D_GNU_SOURCE -c -o codecvt.lo ../../../../gcc-4.3.1/libstdc++-v3/src/codecvt.cc libtool: compile: /home/x/workspace/build/./gcc/xgcc -shared-libgcc -B/home/x/workspace/build/./gcc -nostdinc++ -L/home/x/workspace/build/x86_64-unknown-linux-gnu/libstdc++-v3/src -L/home/x/workspace/build/x86_64-unknown-linux-gnu/libstdc++-v3/src/.libs -B/usr/local/gcc/x86_64-unknown-linux-gnu/bin/ -B/usr/local/gcc/x86_64-unknown-linux-gnu/lib/ -isystem /usr/local/gcc/x86_64-unknown-linux-gnu/include -isystem /usr/local/gcc/x86_64-unknown-linux-gnu/sys-include -I/home/x/workspace/build/x86_64-unknown-linux-gnu/libstdc++-v3/include/x86_64-unknown-linux-gnu -I/home/x/workspace/build/x86_64-unknown-linux-gnu/libstdc++-v3/include -I/home/x/workspace/gcc-4.3.1/libstdc++-v3/libsupc++ -fno-implicit-templates -Wall -Wextra -Wwrite-strings -Wcast-qual -fdiagnostics-show-location=once -ffunction-sections -fdata-sections -g -O2 -D_GNU_SOURCE -c ../../../../gcc-4.3.1/libstdc++-v3/src/codecvt.cc -fPIC -DPIC -o .libs/codecvt.o In file included from /home/x/workspace/build/x86_64-unknown-linux-gnu/libstdc++-v3/include/bits/char_traits.h:48, from /home/x/workspace/build/x86_64-unknown-linux-gnu/libstdc++-v3/include/string:47, from /home/x/workspace/build/x86_64-unknown-linux-gnu/libstdc++-v3/include/bits/locale_classes.h:47, from /home/x/workspace/build/x86_64-unknown-linux-gnu/libstdc++-v3/include/locale:46, from ../../../../gcc-4.3.1/libstdc++-v3/src/codecvt.cc:30: /home/x/workspace/build/x86_64-unknown-linux-gnu/libstdc++-v3/include/cstdio:101: error: '::fpos_t' has not been declared /home/x/workspace/build/x86_64-unknown-linux-gnu/libstdc++-v3/include/cstdio:103: error: '::clearerr' has not been declared /home/x/workspace/build/x86_64-unknown-linux-gnu/libstdc++-v3/include/cstdio:104: error: '::fclose' has not been declared /home/x/workspace/build/x86_64-unknown-linux-gnu/libstdc++-v3/include/cstdio:105: error: '::feof' has not been declared /home/x/workspace/build/x86_64-unknown-linux-gnu/libstdc++-v3/include/cstdio:106: error: '::ferror' has not been declared /home/x/workspace/build/x86_64-unknown-linux-gnu/libstdc++-v3/include/cstdio:107: error: '::fflush' has not been declared /home/x/workspace/build/x86_64-unknown-linux-gnu/libstdc++-v3/include/cstdio:108: error: '::fgetc' has not been declared /home/x/workspace/build/x86_64-unknown-linux-gnu/libstdc++-v3/include/cstdio:109: error: '::fgetpos' has not been declared /home/x/workspace/build/x86_64-unknown-linux-gnu/libstdc++-v3/include/cstdio:110: error: '::fgets' has not been declared /home/x/workspace/build/x86_64-unknown-linux-gnu/libstdc++-v3/include/cstdio:111: error: '::fopen' has not been declared /home/x/workspace/build/x86_64-unknown-linux-gnu/libstdc++-v3/include/cstdio:112: error: '::fprintf' has not been declared /home/x/workspace/build/x86_64-unknown-linux-gnu/libstdc++-v3/include/cstdio:113: error: '::fputc' has not been declared /home/x/workspace/build/x86_64-unknown-linux-gnu/libstdc++-v3/include/cstdio:114: error: '::fputs' has not been declared /home/x/workspace/build/x86_64-unknown-linux-gnu/libstdc++-v3/include/cstdio:115: error: '::fread' has not been declared /home/x/workspace/build/x86_64-unknown-linux-gnu/libstdc++-v3/include/cstdio:116: error: '::freopen' has not been declared /home/x/workspace/build/x86_64-unknown-linux-gnu/libstdc++-v3/include/cstdio:117: error: '::fscanf' has not been declared /home/x/workspace/build/x86_64-unknown-linux-gnu/libstdc++-v3/include/cstdio:118: error: '::fseek' has not been declared /home/x/workspace/build/x86_64-unknown-linux-gnu/libstdc++-v3/include/cstdio:119: error: '::fsetpos' has not been declared /home/x/workspace/build/x86_64-unknown-linux-gnu/libstdc++-v3/include/cstdio:120: error: '::ftell' has not been declared /home/x/workspace/build/x86_64-unknown-linux-gnu/libstdc++-v3/include/cstdio:121: error: '::fwrite' has not been declared /home/x/workspace/build/x86_64-unknown-linux-gnu/libstdc++-v3/include/cstdio:
[Bug fortran/36366] [4.3/4.4 Regression] ICE in gfc_conv_component_ref
--- Comment #3 from pault at gcc dot gnu dot org 2008-06-07 09:05 --- Index: gcc/fortran/resolve.c > === > *** gcc/fortran/resolve.c (revision 136412) > --- gcc/fortran/resolve.c (working copy) > *** resolve_fl_derived (gfc_symbol *sym) > *** 7637,7642 > --- 7637,7647 > return FAILURE; > } > > + /* Ensure that all the derived type components are put on the > +derived type list; even in formal namespaces. */ > + if (c->ts.type == BT_DERIVED && c->ts.derived) > + resolve_fl_derived (c->ts.derived); > + > if (c->pointer || c->allocatable || c->as == NULL) > continue; This patch broke some tests because it gets into a loop with pointer components whose type is the same as the 'host' derived type. This was easily fixed. I could not apply the patch because my tree update went pear-shaped. I'll fix it all in a weeks time, when I'm back home. Paul -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36366
[Bug fortran/36376] -cpp -save-temps passes unknown options to f951
--- Comment #1 from dfranke at gcc dot gnu dot org 2008-06-07 08:30 --- There are two ways to solve this: (1) move "-fpch-preprocess" from gcc.c(cpp_options) into, say, cpp_c_options and add cpp_c_options everywhere where cpp_options are used but fortran (2) duplicate gcc.c(cpp_options) into fortran/lang-specs.h but omit "-fpch-preprocess" Which solution would be preferable? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36376
[Bug c++/35327] [4.3 regression] ICE with invalid constructor
--- Comment #5 from paolo dot carlini at oracle dot com 2008-06-07 08:08 --- Fixed for 4.4.0. -- paolo dot carlini at oracle dot com changed: What|Removed |Added AssignedTo|paolo dot carlini at oracle |unassigned at gcc dot gnu |dot com |dot org Status|ASSIGNED|NEW Summary|[4.3/4.4 regression] ICE|[4.3 regression] ICE with |with invalid constructor|invalid constructor http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35327
[Bug c++/35327] [4.3/4.4 regression] ICE with invalid constructor
--- Comment #4 from paolo at gcc dot gnu dot org 2008-06-07 08:07 --- Subject: Bug 35327 Author: paolo Date: Sat Jun 7 08:06:46 2008 New Revision: 136518 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=136518 Log: /cp 2008-06-07 Paolo Carlini <[EMAIL PROTECTED]> PR c++/35327 * decl.c (grokdeclarator): In case of wrong return type return immediately error_mark_node. /testsuite 2008-06-07 Paolo Carlini <[EMAIL PROTECTED]> PR c++/35327 * g++.dg/parse/crash41.C: New. Added: trunk/gcc/testsuite/g++.dg/parse/crash41.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/decl.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35327
