[Bug regression/32582] Bootstrap with vectorization enabled fails with ICE on PPC

--- Comment #16 from rakdver at kam dot mff dot cuni dot cz 2007-07-29 06:33 --- Subject: Re: Bootstrap with vectorization enabled fails with ICE on PPC > > rakdver at kam dot mff dot cuni dot cz writes: > > rakdver> Probably the problem is that -maltivec does not > rakdver> impl

[Bug libgcj/32929] [4.3 Regression] Make FAILURE in 4.3.0 - error: `CXX' has changed since the previous run:

--- Comment #3 from pinskia at gcc dot gnu dot org 2007-07-29 03:52 --- Yes it was: -# CONFIG_SUBDIRS section, as fixed in confsubdir.m4. +# CONFIG_SUBDIRS section. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32929

[Bug libgcj/32929] [4.3 Regression] Make FAILURE in 4.3.0 - error: `CXX' has changed since the previous run:

--- Comment #2 from pinskia at gcc dot gnu dot org 2007-07-29 03:51 --- I think configure was regenerated wrongly. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32929

[Bug libgcj/32929] [4.3 Regression] Make FAILURE in 4.3.0 - error: `CXX' has changed since the previous run:

--- Comment #1 from pinskia at gcc dot gnu dot org 2007-07-29 03:49 --- I could reproduce this on i386-darwin: configure: error: `CXX' has changed since the previous run: configure: former value: /Users/apinski/src/local/gcc/objdir/./gcc/xgcc -shared-libgcc -B/Users/apinski/src/local/

[Bug libgcj/32929] [4.3 Regression] Make FAILURE in 4.3.0 - error: `CXX' has changed since the previous run:

-- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||pinskia at gcc dot gnu dot |

[Bug target/32522] [4.3 Regression] Bootstrap failure on Alpha due to pointer-plus changes

--- Comment #12 from pinskia at gcc dot gnu dot org 2007-07-29 02:00 --- *** Bug 32930 has been marked as a duplicate of this bug. *** -- pinskia at gcc dot gnu dot org changed: What|Removed |Added -

[Bug bootstrap/32930] Bootstrap ICE in build2_stat

--- Comment #1 from pinskia at gcc dot gnu dot org 2007-07-29 02:00 --- *** This bug has been marked as a duplicate of 32522 *** -- pinskia at gcc dot gnu dot org changed: What|Removed |Added --

[Bug bootstrap/32930] New: Bootstrap ICE in build2_stat

Recent CVS /home/mckelvey/software/gcc-obj/./gcc/xgcc -B/home/mckelvey/software/gcc-obj/./gcc/ -B/usr/local/alphaev56-unknown-linux-gnu/bin/ -B/usr/local/alphaev56-unknown-linux-gnu/lib/ -isystem /usr/local/alphaev56-unknown-linux-gnu/include -isystem /usr/local/alphaev56-unknown-linux-gnu/sys-inc

[Bug other/32923] [4.3 Regression] too many memory references for `lea'

--- Comment #10 from pinskia at gcc dot gnu dot org 2007-07-29 00:46 --- > Not my problem as I clearly can use earlier versions of gcc or other > compilers. lets put it this way, glibc's headers are broken for the version you are using. And it just happens that newer GCC's break bad i

[Bug other/32923] [4.3 Regression] too many memory references for `lea'

--- Comment #9 from rosana07a at gmail dot com 2007-07-29 00:43 --- > And it will be done if you indicate that you don't intend to do it, but as you > found it, it's more natural that you report it (if only, to be kept informed . > Not my problem as I clearly can use earlier versions o

[Bug java/32929] New: [4.3 Regression] Make FAILURE in 4.3.0 - error: `CXX' has changed since the previous run:

revision 127028 failed to bootstrap on Linux/x86-64: configure: error: `CXX' has changed since the previous run: ... It may be caused by http://gcc.gnu.org/ml/java-patches/2007-q3/msg00022.html -- Summary: [4.3 Regression] Make FAILURE in 4.3.0 - error: `CXX' ha

[Bug tree-optimization/32921] [4.3 Regression] Revision 126326 causes 12% slowdown

--- Comment #8 from hjl at lucon dot org 2007-07-28 23:25 --- (In reply to comment #7) > This sounds strange and maybe relates this to PR32624. > I tried the patch in http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32624#c4 It doesn't make a difference in this case. But both are related

[Bug other/32923] [4.3 Regression] too many memory references for `lea'

--- Comment #8 from pinskia at gcc dot gnu dot org 2007-07-28 23:24 --- Again glibc is a seperate project from GCC. THis is a bug in glibc's headers and should reported to them. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added --

[Bug other/32923] [4.3 Regression] too many memory references for `lea'

--- Comment #7 from fxcoudert at gcc dot gnu dot org 2007-07-28 22:41 --- (In reply to comment #6) > To my knowledge the C library is part of the C compiler. Well, this is not true. The C library and C compiler are distinct projects. The GCC compiler can be used with multiple C librari

[Bug fortran/32925] "Syscall param write(buf) points to uninitialised value": unf_io_convert_3.f90

--- Comment #2 from jvdelisle at gcc dot gnu dot org 2007-07-28 22:33 --- I think this is ignorable. We allocate a buffer of 8192 bytes. We only use a portion of it, so the pointer to that block is being flagged as pointing to uninitialized memory. We don't want to take the performan

[Bug other/32923] [4.3 Regression] too many memory references for `lea'

--- Comment #6 from rosana07a at gmail dot com 2007-07-28 22:10 --- As a mathematician and logician the handling os this PR and my previous PR32720 make no sense. A fellow worker told me about fortan 90/95 under gcc-4.3. the only thing in common with both PR's was a change from gcc-4.2.x

[Bug libfortran/32858] printf-capabilities for runtime_error()

--- Comment #6 from tkoenig at gcc dot gnu dot org 2007-07-28 22:04 --- There are also a few other issues with the incomplete patch. vsnprintf can be replaced by __builtin_vsnprintf on systems where it isn't available. I'll iron that out when I have the main functionality working. --

[Bug fortran/31609] module that calls a contained function with an ENTRY point

--- Comment #12 from jvdelisle at gcc dot gnu dot org 2007-07-28 22:02 --- Subject: Bug 31609 Author: jvdelisle Date: Sat Jul 28 22:02:42 2007 New Revision: 127028 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=127028 Log: 2007-07-29 Jerry DeLisle <[EMAIL PROTECTED]>

[Bug libfortran/32858] printf-capabilities for runtime_error()

--- Comment #5 from tkoenig at gcc dot gnu dot org 2007-07-28 21:59 --- Created an attachment (id=13995) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13995&action=view) a patch. Unfortunately, it doesn't print out any error messages right now. -- http://gcc.gnu.org/bugzilla/

[Bug regression/32582] Bootstrap with vectorization enabled fails with ICE on PPC

--- Comment #15 from dje at watson dot ibm dot com 2007-07-28 21:48 --- Subject: Re: Bootstrap with vectorization enabled fails with ICE on PPC > rakdver at kam dot mff dot cuni dot cz writes: rakdver> Probably the problem is that -maltivec does not rakdver> imply -mabi=altivec,

[Bug fortran/31609] module that calls a contained function with an ENTRY point

--- Comment #11 from jvdelisle at gcc dot gnu dot org 2007-07-28 21:17 --- Subject: Bug 31609 Author: jvdelisle Date: Sat Jul 28 21:17:20 2007 New Revision: 127026 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=127026 Log: 2007-07-28 Jerry DeLisle <[EMAIL PROTECTED]>

[Bug regression/32582] Bootstrap with vectorization enabled fails with ICE on PPC

--- Comment #14 from rakdver at kam dot mff dot cuni dot cz 2007-07-28 21:11 --- Subject: Re: Bootstrap with vectorization enabled fails with ICE on PPC > What happens if you add -mabi=altivec to the command line, does it work then? > If not, then that loop I pointed out is being mis

[Bug target/32893] zlib segfault in inflate_table() compiled w/ -O -msse2 ftree-vectorize

--- Comment #3 from dorit at gcc dot gnu dot org 2007-07-28 21:03 --- (In reply to comment #2) > > Andrew, makes sense to you? > I think my patch only checks PREFERRED_STACK_BOUNDARY and not STACK_BOUNDARY > which is why it does not work but I have not looked into it at all. I see refer

[Bug fortran/10220] attribute DW_AT_calling_convention not correct for fortran

--- Comment #3 from fxcoudert at gcc dot gnu dot org 2007-07-28 21:01 --- There's a thread about it starting at http://gcc.gnu.org/ml/gcc-patches/2005-11/msg01501.html and with a summary of the consensus at http://gcc.gnu.org/ml/gcc-patches/2005-11/msg01572.html (although no further act

[Bug tree-optimization/32921] [4.3 Regression] Revision 126326 causes 12% slowdown

--- Comment #7 from rguenther at suse dot de 2007-07-28 20:59 --- Subject: Re: [4.3 Regression] Revision 126326 causes 12% slowdown On Sat, 28 Jul 2007, hjl at lucon dot org wrote: > causes this performance regression. > > 437.leslie3d is a big file with 19 functions. If I put each

[Bug fortran/32795] allocatable components are nullified prematurely

--- Comment #4 from pault at gcc dot gnu dot org 2007-07-28 20:52 --- (In reply to comment #3) Could somebody test the patch below, please? Paul Index: gcc/fortran/trans-stmt.c === *** gcc/fortran/trans-stmt.c(revisio

[Bug fortran/22629] Would like to access "long double" equivalent type as real*16

--- Comment #8 from fxcoudert at gcc dot gnu dot org 2007-07-28 20:51 --- I do understand that it would be easier for you to "tweak" the kind numbers used by gfortran to accomodate old code, but there really is a problem with doing so: it will, for example, clash with the prospected use

[Bug tree-optimization/32921] [4.3 Regression] Revision 126326 causes 12% slowdown

--- Comment #6 from hjl at lucon dot org 2007-07-28 20:51 --- This part of the patch: Index: tree-ssa.c === --- tree-ssa.c (revision 126326) +++ tree-ssa.c (working copy) @@ -979,11 +979,9 @@ useless_type_conversion_p (tr

[Bug fortran/32682] [4.3 Regression] ICE in gfc_trans_array_constructor, at fortran/trans-array.c:1664

--- Comment #7 from fxcoudert at gcc dot gnu dot org 2007-07-28 20:47 --- (In reply to comment #3) > Index: gcc/fortran/trans-array.c > === > *** gcc/fortran/trans-array.c (revision 126461) > --- gcc/fortran/trans-array.c

[Bug target/31644] [avr] can't find a register in class 'BASE_POINTER_REGS' while reloading 'asm'

--- Comment #4 from pavel dot petrovic at gmail dot com 2007-07-28 20:24 --- This bug is quite cruel. I have similar application, also for atmega168 and WinAVR (avr-gcc (GCC) 4.1.2 (WinAVR 20070525)), and the following lines do not compile giving the same error. Even worse, if the code

[Bug fortran/13939] Does not accept missing subroutine arguments like g77

--- Comment #4 from fxcoudert at gcc dot gnu dot org 2007-07-28 20:18 --- After some talk among gfortran developers on IRC, it seems that there is consensus that we won't be implementing this particular g77 feature. I'm thus closing this bug as WONTFIX. Of course, if anyone is interest

[Bug c++/30917] [4.1 Regression] ICE with friend in local class (to a function)

--- Comment #8 from simartin at gcc dot gnu dot org 2007-07-28 20:14 --- Fixed in 4.2 and 4.3. -- simartin at gcc dot gnu dot org changed: What|Removed |Added

[Bug fortran/25297] Support for STRUCTURE/END STRUCTURE and RECORD

--- Comment #4 from jb at gcc dot gnu dot org 2007-07-28 20:13 --- Closing as WONTFIX, since nobody seems interested in a) implementing this feature b) maintaining it. As already mentioned, gfortran supports Fortran derived types which can be used for similar purposes as these proposed

[Bug c++/30917] [4.1/4.2/4.3 Regression] ICE with friend in local class (to a function)

--- Comment #7 from simartin at gcc dot gnu dot org 2007-07-28 20:12 --- Subject: Bug 30917 Author: simartin Date: Sat Jul 28 20:12:42 2007 New Revision: 127023 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=127023 Log: gcc/cp/ 2007-07-28 Simon Martin <[EMAIL PROTECTED]>

[Bug libfortran/32736] Replace -fallow-leading-underscore by Bind(C)

--- Comment #3 from fxcoudert at gcc dot gnu dot org 2007-07-28 20:12 --- Another problem is that some of these routines take CHARACTER(LEN=*) arguments, which make them incompatible with BIND(C): ../../../../trunk/libgfortran/generated/misc_specifics.F90:225.37: elemental function in

[Bug regression/32582] Bootstrap with vectorization enabled fails with ICE on PPC

--- Comment #13 from pinskia at gcc dot gnu dot org 2007-07-28 19:49 --- What happens if you add -mabi=altivec to the command line, does it work then? If not, then that loop I pointed out is being miscompiled :). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32582

[Bug regression/32582] Bootstrap with vectorization enabled fails with ICE on PPC

--- Comment #12 from dje at watson dot ibm dot com 2007-07-28 19:48 --- Subject: Re: Bootstrap with vectorization enabled fails with ICE on PPC And we default to ALTIVEC ABI for powerpc-linux: /* Set Altivec ABI as default for powerpc64 linux. */ if (TARGET_ELF && TARGET

[Bug regression/32582] Bootstrap with vectorization enabled fails with ICE on PPC

--- Comment #11 from pinskia at gcc dot gnu dot org 2007-07-28 19:45 --- This code in rs6000_conditional_register_usage should have done the same thing as the patch posted: if (TARGET_ALTIVEC_ABI) for (i = FIRST_ALTIVEC_REGNO; i < FIRST_ALTIVEC_REGNO + 20; ++i) call_used_re

[Bug regression/32582] Bootstrap with vectorization enabled fails with ICE on PPC

--- Comment #10 from dje at watson dot ibm dot com 2007-07-28 19:40 --- Subject: Re: Bootstrap with vectorization enabled fails with ICE on PPC Should this test be using -mabi=altivec or is there a general assumption of -mabi=altivec when using autovec? That conditionally set

[Bug regression/32582] Bootstrap with vectorization enabled fails with ICE on PPC

--- Comment #9 from rakdver at kam dot mff dot cuni dot cz 2007-07-28 19:27 --- Subject: Re: Bootstrap with vectorization enabled fails with ICE on PPC > > v0 (and v10 are scratch registers and not saved. > > so does it look like a register allocation bug then? not really; it seems

[Bug regression/32582] Bootstrap with vectorization enabled fails with ICE on PPC

--- Comment #8 from dorit at gcc dot gnu dot org 2007-07-28 19:20 --- > v0 (and v10 are scratch registers and not saved. so does it look like a register allocation bug then? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32582

[Bug libfortran/32736] Replace -fallow-leading-underscore by Bind(C)

--- Comment #2 from fxcoudert at gcc dot gnu dot org 2007-07-28 18:17 --- Hum, first problem: we can't make a function like _gfortran_selected_real_kind bind(c) because it has optional arguments: function selected_real_kind (p, r) & bind(c,name="_gfortran_selected_real_kind"

[Bug fortran/32926] Internal compiler error in the middle of a sizeable package build

-- pinskia at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|4.3.0 |--- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32926

[Bug web/32927] Online installation instructions only for mainline

--- Comment #1 from pinskia at gcc dot gnu dot org 2007-07-28 17:11 --- This one purpose, you should have looked into the install directory which has an index.html already in the tar file you downloaded. -- pinskia at gcc dot gnu dot org changed: What|Removed

[Bug middle-end/32920] [4.3 Regression] error: type mismatch in binary expression

--- Comment #5 from rguenth at gcc dot gnu dot org 2007-07-28 16:33 --- Thx! -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|NEW

[Bug middle-end/32920] [4.3 Regression] error: type mismatch in binary expression

--- Comment #4 from kristerw at gcc dot gnu dot org 2007-07-28 16:26 --- Subject: Bug 32920 Author: kristerw Date: Sat Jul 28 16:26:44 2007 New Revision: 127021 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=127021 Log: 2007-07-28 Richard Guenther <[EMAIL PROTECTED]>

[Bug middle-end/32920] [4.3 Regression] error: type mismatch in binary expression

--- Comment #3 from cato at df dot lth dot se 2007-07-28 16:13 --- Subject: Re: [4.3 Regression] error: type mismatch in binary expression On Sat, 28 Jul 2007, rguenth at gcc dot gnu dot org wrote: > This patch fixes it. It's ok for mainline if it passes a bootstrap & regtest. > It

[Bug fortran/32924] "Conditional jump depends on uninitialised value": gfortran.dg/large_unit_1.f90

--- Comment #2 from jvdelisle at gcc dot gnu dot org 2007-07-28 16:13 --- I believe that valgrind is showing this because the st_parameter_common structure "cmp" is set at compile time. The options.locus parameter is initialized to zero in environ.c -- jvdelisle at gcc dot gnu dot

[Bug fortran/32925] "Syscall param write(buf) points to uninitialised value": unf_io_convert_3.f90

--- Comment #1 from jvdelisle at gcc dot gnu dot org 2007-07-28 15:57 --- This is most likely mine. -- jvdelisle at gcc dot gnu dot org changed: What|Removed |Added

[Bug fortran/32924] "Conditional jump depends on uninitialised value": gfortran.dg/large_unit_1.f90

--- Comment #1 from jvdelisle at gcc dot gnu dot org 2007-07-28 15:56 --- I will take care of this one -- jvdelisle at gcc dot gnu dot org changed: What|Removed |Added

[Bug fortran/32926] Internal compiler error in the middle of a sizeable package build

--- Comment #3 from jvdelisle at gcc dot gnu dot org 2007-07-28 15:37 --- I will mention that pr31213 has multiple problems. We have a partial fix that appears to take care of one of these. So if you get a reduced case here, we can try it. -- http://gcc.gnu.org/bugzilla/show_bug.

[Bug fortran/31609] module that calls a contained function with an ENTRY point

--- Comment #10 from jvdelisle at gcc dot gnu dot org 2007-07-28 15:29 --- Created an attachment (id=13994) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13994&action=view) Example of bad translation This attached example of tree-dump-original shows that we are getting a translat

[Bug fortran/32048] max/min and NaN

--- Comment #9 from fxcoudert at gcc dot gnu dot org 2007-07-28 15:23 --- Fixed. -- fxcoudert at gcc dot gnu dot org changed: What|Removed |Added Status|ASSI

[Bug fortran/32048] max/min and NaN

--- Comment #8 from fxcoudert at gcc dot gnu dot org 2007-07-28 15:23 --- Subject: Bug 32048 Author: fxcoudert Date: Sat Jul 28 15:23:11 2007 New Revision: 127019 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=127019 Log: PR fortran/32048 * f95-lang.c (gfc_init

[Bug libfortran/32770] -fdefault-integer-8 and the library

--- Comment #4 from dominiq at lps dot ens dot fr 2007-07-28 14:18 --- > (Full doc is available at http://gcc.gnu.org/install/test.html) I have read it, but I got confused by: "In order to run sets of tests selectively, there are targets `make check-gcc' and `make check-g++' in the gcc

[Bug fortran/32928] DATA statement with array element as initializer is rejected

--- Comment #2 from burnus at gcc dot gnu dot org 2007-07-28 14:00 --- R532 data-stmt-constant is scalar-constant or scalar-constant-subobject or signed-int-literal-constant or signed-real-literal-constant

[Bug fortran/32048] max/min and NaN

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

[Bug fortran/32048] max / min and NaN

--- Comment #7 from fxcoudert at gcc dot gnu dot org 2007-07-28 13:49 --- Here's a patch that yields results according to IEEE: Index: f95-lang.c === --- f95-lang.c (revision 126997) +++ f95-lang.c (working copy) @@ -100

[Bug libfortran/32770] -fdefault-integer-8 and the library

--- Comment #3 from fxcoudert at gcc dot gnu dot org 2007-07-28 13:37 --- (In reply to comment #2) > I have looked for the way to run the testsuite on gfortran only, but did not > find a way to > do it. Could someone give me the right pointer? Also I'll need the directive > to > do the

[Bug fortran/32928] DATA statement with array element as initializer is rejected

--- Comment #1 from burnus at gcc dot gnu dot org 2007-07-28 13:29 --- The problem seems to be that in decl.c the var_element() function assumes that it only has to match a variable and not also, e.g., an array element. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32928

[Bug libfortran/32770] -fdefault-integer-8 and the library

--- Comment #2 from dominiq at lps dot ens dot fr 2007-07-28 13:27 --- > I fixed the same kind of problems with MVBITS (it was PR32357). Maybe we > should > ask to Dominique Dhumières to test on ppc-darwin? (like, running the testsuite > with -fdefault-integer-8) I have looked for the

[Bug fortran/32928] New: DATA statement with array element as initializer is rejected

Found while debugging PR32315. program chkdata character(len=1), parameter,dimension(4) :: string = 'A' character :: a data a /string(4)/ end program chkdata Is rejected: data a /string(4)/ 1 Error: Syntax error in DATA statement at (1) However, g95, NAG f95, ifo

[Bug libfortran/32812] random_seed and date_and_time

--- Comment #1 from fxcoudert at gcc dot gnu dot org 2007-07-28 13:07 --- (In reply to comment #0) > <[EMAIL PROTECTED]>, This Usenet post can be found at: http://groups.google.com/group/comp.lang.fortran/browse_thread/thread/0b60cf25162534bf/2e8d2775f455a33f -- fxcoudert at gcc do

[Bug fortran/32487] no 8-bit type when compiling a cross-compiler for mips

--- Comment #4 from fxcoudert at gcc dot gnu dot org 2007-07-28 12:57 --- No news... closing as INVALID. Please reopen with additional information (like the C library you used, whether you do a combined build, etc.) if you want us to investigate further. -- fxcoudert at gcc dot gnu

[Bug fortran/24965] Wrong file name in error message

--- Comment #6 from fxcoudert at gcc dot gnu dot org 2007-07-28 12:55 --- Closing, unless Erik can tell us more about how the files were prepared. -- fxcoudert at gcc dot gnu dot org changed: What|Removed |Added ---

[Bug web/32927] New: Online installation instructions only for mainline

The GCC installation instructions at only cover the mainline version. If the instructions were kept per-version as the GCC manual it would make configuring and installing release versions easier. See the thread starting at

[Bug libfortran/32736] Replace -fallow-leading-underscore by Bind(C)

--- Comment #1 from fxcoudert at gcc dot gnu dot org 2007-07-28 12:52 --- I'll take care of that. -- fxcoudert at gcc dot gnu dot org changed: What|Removed |Added

[Bug libfortran/32736] Replace -fallow-leading-underscore by Bind(C)

-- fxcoudert at gcc dot gnu dot org changed: What|Removed |Added Severity|minor |enhancement Status|UNCONFIRMED |NEW

[Bug libfortran/32770] -fdefault-integer-8 and the library

--- Comment #1 from fxcoudert at gcc dot gnu dot org 2007-07-28 12:42 --- I fixed the same kind of problems with MVBITS (it was PR32357). Maybe we should ask to Dominique Dhumières to test on ppc-darwin? (like, running the testsuite with -fdefault-integer-8) -- fxcoudert at gcc dot

[Bug fortran/32926] Internal compiler error in the middle of a sizeable package build

--- Comment #2 from fxcoudert at gcc dot gnu dot org 2007-07-28 12:33 --- Hi Ralph, Thanks for the bug report. Can you please email the sources to me privately ([EMAIL PROTECTED]). I will work out whether this is a duplicate of PR31213, or a different bug (and will make a short testcas

[Bug fortran/32926] Internal compiler error in the middle of a sizeable package build

--- Comment #1 from burnus at gcc dot gnu dot org 2007-07-28 11:57 --- Possibly a duplicate of PR 31213. -- burnus at gcc dot gnu dot org changed: What|Removed |Added

[Bug fortran/32926] New: Internal compiler error in the middle of a sizeable package build

This bug occurred during a build of a version of "GlobSol" that builds correctly with the g95 compiler. It happens with the "unofficial" build of gfortran for native Windows that I downloaded from http://gcc.gnu.org/wiki/GFortranBinaries#Windows from the link: mingw build, or "native Windows": do

[Bug c++/30917] [4.1/4.2/4.3 Regression] ICE with friend in local class (to a function)

--- Comment #6 from simartin at gcc dot gnu dot org 2007-07-28 10:48 --- Subject: Bug 30917 Author: simartin Date: Sat Jul 28 10:48:30 2007 New Revision: 127016 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=127016 Log: gcc/cp/ 2007-07-28 Simon Martin <[EMAIL PROTECTED]>

[Bug middle-end/32920] [4.3 Regression] error: type mismatch in binary expression

--- Comment #2 from rguenth at gcc dot gnu dot org 2007-07-28 10:33 --- Created an attachment (id=13993) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13993&action=view) patch This patch fixes it. It's ok for mainline if it passes a bootstrap & regtest. It would be nice if someon

[Bug middle-end/32920] [4.3 Regression] error: type mismatch in binary expression

--- Comment #1 from rguenth at gcc dot gnu dot org 2007-07-28 10:32 --- Confirmed. A bug in fold. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added

[Bug tree-optimization/32921] [4.3 Regression] Revision 126326 causes 12% slowdown

--- Comment #5 from rguenth at gcc dot gnu dot org 2007-07-28 10:02 --- It might be a missed optimization, so it would be nice to see where the slowdown is and what changed there wrt trees we get. (note I will not have time to investigate this for the next three weeks as I'm on vacation

[Bug fortran/32925] New: "Syscall param write(buf) points to uninitialised value": unf_io_convert_3.f90

Compiling testsuite/gfortran.dg/unf_io_convert_3.f90 and running valgrind a.out shows the following diagnostic: ==2411== Syscall param write(buf) points to uninitialised byte(s) ==2411==at 0x5606730: write (in /lib64/libc-2.6.so) ==2411==by 0x4EBEFB0: do_write (unix.c:365) ==2411==by 0

[Bug fortran/32924] New: "Conditional jump depends on uninitialised value": gfortran.dg/large_unit_1.f90

compiling testsuite/gfortran.dg/large_unit_1.f90 and running valgrind ./a.out shows the following error message. The error message shown is: At line 8 of file large_unit_1.f90 Fortran runtime error: Unit number in I/O statement too large ==20895== Conditional jump or move depends on uninitiali

[Bug fortran/32879] Document algorithm used for random generator

--- Comment #3 from patchapp at dberlin dot org 2007-07-28 09:45 --- Subject: Bug number PR32879 A patch for this bug has been added to the patch tracker. The mailing list url for the patch is http://gcc.gnu.org/ml/gcc-patches/2007-07/msg02029.html -- http://gcc.gnu.org/bugzilla/sh

[Bug target/32923] [4.3 Regression] too many memory references for `lea'

--- Comment #5 from pinskia at gcc dot gnu dot org 2007-07-28 09:13 --- static inline __attribute__((always_inline)) int strncmp(const char * cs,const char * ct,size_t count) { register int __res; int d0, d1, d2; __asm__ __volatile__( "1:\tdecl %3\n\t" "js 2f\n\t" "lodsb\n\t" "scasb\

[Bug target/32923] [4.3 Regression] too many memory references for `lea'

-- pinskia at gcc dot gnu dot org changed: What|Removed |Added Severity|major |normal Component|c |target

[Bug c/32923] [4.3.0 Regression] too many memory references for `lea'

--- Comment #4 from rask at sygehus dot dk 2007-07-28 09:00 --- This is not a GCC bug. The part that fails is broken, inline asm: #APP # 173 "include/asm/string.h" 1 movb %al,%ah 1: lodsb cmpb %ah,%al jne 2f leal -1(%esi),20(%esp) 2: testb %al,%

[Bug fortran/32905] NAMELIST accepts types with ultimate POINTER components

--- Comment #3 from dfranke at gcc dot gnu dot org 2007-07-28 08:54 --- Fixed in trunk. Closing. -- dfranke at gcc dot gnu dot org changed: What|Removed |Added

[Bug fortran/32876] Wrongly accepts private items in public NAMELISTs

--- Comment #5 from dfranke at gcc dot gnu dot org 2007-07-28 08:53 --- Fixed in trunk. Closing. -- dfranke at gcc dot gnu dot org changed: What|Removed |Added

[Bug fortran/31818] Wrongly accepts namelists with assumed-shape arrays

--- Comment #7 from dfranke at gcc dot gnu dot org 2007-07-28 08:52 --- Fixed in trunk. Closing. -- dfranke at gcc dot gnu dot org changed: What|Removed |Added

[Bug fortran/32876] Wrongly accepts private items in public NAMELISTs

--- Comment #4 from dfranke at gcc dot gnu dot org 2007-07-28 08:51 --- Subject: Bug 32876 Author: dfranke Date: Sat Jul 28 08:51:06 2007 New Revision: 127014 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=127014 Log: gcc/fortran: 2007-07-28 Daniel Franke <[EMAIL PROTECTED]>

[Bug fortran/32905] NAMELIST accepts types with ultimate POINTER components

--- Comment #2 from dfranke at gcc dot gnu dot org 2007-07-28 08:51 --- Subject: Bug 32905 Author: dfranke Date: Sat Jul 28 08:51:06 2007 New Revision: 127014 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=127014 Log: gcc/fortran: 2007-07-28 Daniel Franke <[EMAIL PROTECTED]>

[Bug fortran/31818] Wrongly accepts namelists with assumed-shape arrays

--- Comment #6 from dfranke at gcc dot gnu dot org 2007-07-28 08:51 --- Subject: Bug 31818 Author: dfranke Date: Sat Jul 28 08:51:06 2007 New Revision: 127014 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=127014 Log: gcc/fortran: 2007-07-28 Daniel Franke <[EMAIL PROTECTED]>

[Bug libstdc++/32908] Miss lexicographical_compare random access override

--- Comment #1 from pcarlini at suse dot de 2007-07-28 07:38 --- Hi Chris. Sure, I can work on this, no big deal, otherwise, I'll let you know, thanks. Before starting on that, however, I would be curious to hear from Zdenek: is there something that could be done in the loop optimizer de