[Bug fortran/39178] Generate main() rather than using a main in libgfortran/fmain.c

--- Comment #3 from burnus at gcc dot gnu dot org 2009-05-20 06:01 --- Patch: http://gcc.gnu.org/ml/fortran/2009-05/msg00310.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39178

[Bug target/37216] [cygming] Invalid alignment for SSE store to .comm data generated with -O3

--- Comment #56 from dave dot korn dot cygwin at gmail dot com 2009-05-20 04:25 --- Created an attachment (id=17895) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17895&action=view) Target option and autoconf test to enable aligned common support. Currently putting the attached t

[Bug tree-optimization/40087] [4.3/4.4/4.5 Regression] Number of iterations analysis wrong

--- Comment #9 from rakdver at gcc dot gnu dot org 2009-05-20 00:34 --- Subject: Bug 40087 Author: rakdver Date: Wed May 20 00:33:54 2009 New Revision: 147727 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=147727 Log: PR tree-optimization/40087 * tree-ssa-loop-ni

[Bug libfortran/37754] [4.4 Regression] READ I/O Performance regression from 4.3 to 4.4/4.5

--- Comment #16 from jvdelisle at gcc dot gnu dot org 2009-05-20 00:16 --- Subject: Bug 37754 Author: jvdelisle Date: Wed May 20 00:16:38 2009 New Revision: 147725 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=147725 Log: 2009-05-19 Jerry DeLisle PR libfortran/3775

Re: 64 bit linux build problem for gcc 4.4.0

Aharon Robbins wrote: Hi. After several tries and a modicum of googling, I found that CFLAGS=-m64 ../gcc-4.4.0/configure --disable-multilib was the magic incantation to get gcc to get into the second stage of the boostrap. This is on a Fedora Core 10 system. This seems to be an old is

[Bug libstdc++/39542] doesn't contain vasprintf() and asprintf()

--- Comment #3 from paolo dot carlini at oracle dot com 2009-05-19 22:27 --- *** Bug 40203 has been marked as a duplicate of this bug. *** -- paolo dot carlini at oracle dot com changed: What|Removed |Added

[Bug libstdc++/40203] asprintf() and vasprintf() missing in header file

--- Comment #4 from paolo dot carlini at oracle dot com 2009-05-19 22:27 --- *** This bug has been marked as a duplicate of 39542 *** -- paolo dot carlini at oracle dot com changed: What|Removed |Added ---

[Bug libstdc++/40203] asprintf() and vasprintf() missing in header file

--- Comment #3 from paolo dot carlini at oracle dot com 2009-05-19 22:27 --- Indeed... -- paolo dot carlini at oracle dot com changed: What|Removed |Added St

[Bug libstdc++/40203] asprintf() and vasprintf() missing in header file

--- Comment #2 from paolo dot carlini at oracle dot com 2009-05-19 22:25 --- Indeed, these are extensions and certainly the C++ standard doesn't say must be made available in namespace std:: via . Actually, I think this PR is a duplicate... -- paolo dot carlini at oracle dot com cha

[Bug fortran/40019] LEADZ and TRAILZ give wrong results

-- 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 c/40204] New: segfault with bitfields in structs

Compiling the following (nonsense but valid) code triggers an internal compiler error. Environment: System: Linux thanatos 2.6.26-2-686-bigmem #1 SMP Thu Mar 26 02:03:34 UTC 2009 i686 GNU/Linux How-To-Repeat: Compile the following: -- snip -- struct s {

[Bug c++/40202] warning about passing non-POD objects through �...� should include name and location of declaration being called

--- Comment #1 from pinskia at gcc dot gnu dot org 2009-05-19 22:04 --- So are you asking to print out 'x' here? -- pinskia at gcc dot gnu dot org changed: What|Removed |Added ---

[Bug libstdc++/40203] asprintf() and vasprintf() missing in header file

--- Comment #1 from pinskia at gcc dot gnu dot org 2009-05-19 22:02 --- Both asprintf and vasprintf are extensions to the C (and the C++) standard so ... -- pinskia at gcc dot gnu dot org changed: What|Removed |Added ---

[Bug bootstrap/40198] No rule to make target `proto', needed by `native'. Stop.

--- Comment #3 from wuddja at yahoo dot de 2009-05-19 21:28 --- ok lets take a look at my config flags /var/tmp/portage/sys-devel/gcc-4.5.0_pre/work/gcc-4.5.0-/configure --prefix=/usr --bindir=/usr/i686-pc-linux-gnu/gcc-bin/4.5.0-pre --includedir=/usr/lib/gcc/i686-pc-linux-g

[Bug c/40172] [4.5 Regression] Revision 147596 breaks bootstrap

--- Comment #29 from hjl at gcc dot gnu dot org 2009-05-19 21:24 --- Subject: Bug 40172 Author: hjl Date: Tue May 19 21:24:23 2009 New Revision: 147720 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=147720 Log: 2009-05-19 H.J. Lu Backport from mainline: 2009-

[Bug c/40172] [4.5 Regression] Revision 147596 breaks bootstrap

--- Comment #28 from hjl at gcc dot gnu dot org 2009-05-19 21:17 --- Subject: Bug 40172 Author: hjl Date: Tue May 19 21:17:00 2009 New Revision: 147719 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=147719 Log: 2009-05-19 H.J. Lu PR c/40172 * gcc.dg/pr40172.c

[Bug c++/40203] New: asprintf() and vasprintf() missing in header file

The asprintf() and vasprintf() prototypes are declared in header file. The should be the "adapted" version of the same file for C++ language. Nonetheless those two prototypes are missing. Quoting from the : /** @file include/cstdio * This is a Standard C++ Library file. You should @c #include

[Bug c/40172] [4.5 Regression] Revision 147596 breaks bootstrap

--- Comment #27 from ddaney at caviumnetworks dot com 2009-05-19 20:58 --- Subject: Re: [4.5 Regression] Revision 147596 breaks bootstrap manu at gcc dot gnu dot org wrote: > --- Comment #26 from manu at gcc dot gnu dot org 2009-05-19 20:29 --- > The case in toplev.c cannot

64 bit linux build problem for gcc 4.4.0

Hi. After several tries and a modicum of googling, I found that CFLAGS=-m64 ../gcc-4.4.0/configure --disable-multilib was the magic incantation to get gcc to get into the second stage of the boostrap. This is on a Fedora Core 10 system. This seems to be an old issue; google turns things

[Bug c++/40202] New: warning about passing non-POD objects through �...� should include name and location of declaration being called

void f(...); struct X { X(); }; void g() { X x; f(x); } nonpod.cpp: In function ‘void g()’: nonpod.cpp:9: warning: cannot pass objects of non-POD type ‘struct X’ through ‘...’; call will abort at runtime Someone I know is currently trying to fix this warning in a very large ap

[Bug c/40172] [4.5 Regression] Revision 147596 breaks bootstrap

--- Comment #26 from manu at gcc dot gnu dot org 2009-05-19 20:29 --- The case in toplev.c cannot be fixed without tracking macro expansions somehow, but I wonder why it warns (multiple times!) for this case: > ../../trunk/gcc/config/mips/sb1.md:159: error: logical �or� of > collec

[Bug c/40172] [4.5 Regression] Revision 147596 breaks bootstrap

--- Comment #25 from manu at gcc dot gnu dot org 2009-05-19 19:29 --- Subject: Bug 40172 Author: manu Date: Tue May 19 19:29:27 2009 New Revision: 147717 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=147717 Log: 2009-05-19 Manuel López-Ibáñez PR c/40172 gcc/

[Bug libstdc++/40184] locale(const char* std_name) can create invalid facets for nonuniform locale

--- Comment #5 from paolo dot carlini at oracle dot com 2009-05-19 18:24 --- Fixed. -- paolo dot carlini at oracle dot com changed: What|Removed |Added Statu

[Bug libstdc++/40184] locale(const char* std_name) can create invalid facets for nonuniform locale

--- Comment #4 from paolo at gcc dot gnu dot org 2009-05-19 18:20 --- Subject: Bug 40184 Author: paolo Date: Tue May 19 18:20:47 2009 New Revision: 147714 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=147714 Log: 2009-05-19 Paolo Carlini PR libstdc++/40184 *

[Bug c++/40192] [4.4/4.5 Regression] Unable to use std::vector with typedef'd array types

--- Comment #13 from paolo dot carlini at oracle dot com 2009-05-19 18:19 --- It's life, you know ;) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40192

[Bug c++/40192] [4.4/4.5 Regression] Unable to use std::vector with typedef'd array types

--- Comment #12 from jeff at schwabcenter dot com 2009-05-19 18:07 --- What he said. I'm perusing your patch, and I appreciate that you removed an artificial restriction. The right place to catch this is up front, in a concept check, rather than in _Destroy; since I'm not about to add

[Bug c++/40192] [4.4/4.5 Regression] Unable to use std::vector with typedef'd array types

--- Comment #11 from coleb at eyesopen dot com 2009-05-19 17:57 --- (In reply to comment #10) > Look closely at the patch I committed, I changed *nothing* of the actual > behavior of the containers. Thus the semantics is exactly the same as before, > only, the destructor in not called ex

[Bug libfortran/40190] DATE_AND_TIME returns GMT hour sometimes with OpenMP

--- Comment #5 from hjl dot tools at gmail dot com 2009-05-19 17:47 --- *** Bug 40201 has been marked as a duplicate of this bug. *** -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40190

[Bug fortran/40201] DATE_AND_TIME returns GMT hour sometimes with OpenMP

--- Comment #1 from hjl dot tools at gmail dot com 2009-05-19 17:47 --- *** This bug has been marked as a duplicate of 40190 *** -- hjl dot tools at gmail dot com changed: What|Removed |Added --

[Bug c++/40192] [4.4/4.5 Regression] Unable to use std::vector with typedef'd array types

--- Comment #10 from paolo dot carlini at oracle dot com 2009-05-19 17:38 --- Look closely at the patch I committed, I changed *nothing* of the actual behavior of the containers. Thus the semantics is exactly the same as before, only, the destructor in not called explicitly anymore on s

[Bug fortran/40201] New: DATE_AND_TIME returns GMT hour sometimes with OpenMP

Test case: program testhour use omp_lib integer :: h(1000), h1(1000), bins(0:23), v(8) call omp_set_num_threads(4) print *, "Running on",omp_get_max_threads(),"threads and",omp_get_num_procs(),"procs." !$omp parallel do schedule(STATIC,250) do i=1,1000 call date_and_time(values=v) h(i) = v

[Bug c++/40192] [4.4/4.5 Regression] Unable to use std::vector with typedef'd array types

--- Comment #9 from jeff at schwabcenter dot com 2009-05-19 17:32 --- OK. Thanks for the explanation. Are the semantics documented somewhere? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40192

[Bug libfortran/40187] c_f_pointer with stride in SHAPE

--- Comment #5 from tkoenig at gcc dot gnu dot org 2009-05-19 17:18 --- Since I'm working in this area anyway, I might as well take this. -- tkoenig at gcc dot gnu dot org changed: What|Removed |Added ---

[Bug libfortran/40187] c_f_pointer with stride in SHAPE

--- Comment #4 from tkoenig at gcc dot gnu dot org 2009-05-19 17:17 --- Created an attachment (id=17894) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17894&action=view) Driver for failing test case (identical to c_f_pointer_shape_tests_2_driver.c) $ gfortran c_f_pointer_shape_tes

[Bug libfortran/40187] c_f_pointer with stride in SHAPE

--- Comment #3 from tkoenig at gcc dot gnu dot org 2009-05-19 17:14 --- Created an attachment (id=17893) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17893&action=view) Failing test case -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40187

[Bug c++/40192] [4.4/4.5 Regression] Unable to use std::vector with typedef'd array types

--- Comment #8 from paolo dot carlini at oracle dot com 2009-05-19 17:12 --- This is not going to change again. We had this behaviour forever until 4.3.x and all the major implementations outside GCC behave the same as GCC now (and before the change of behavior). -- http://gcc.gnu.

[Bug c++/40192] [4.4/4.5 Regression] Unable to use std::vector with typedef'd array types

--- Comment #7 from jeff at schwabcenter dot com 2009-05-19 17:09 --- I understand the desire for backward compatibility, but are the semantics actually the same? Are the vector values arrays, or do they decay to pointers? Section 23.1 says standard container elements have to be CopyCo

[Bug c++/40200] New: ''gcc file.cpp -o file.cpp'' Kills the code

Command gcc file.cpp -o file.cpp leads to overwriting of the code by the compiled version I propose error or backup of the overwritten file if it is equal to the sourse file. This happened just now. I was in deep debug. While it didn't compile - no problem. As soon as I finished with all compil

[Bug c++/40192] [4.4/4.5 Regression] Unable to use std::vector with typedef'd array types

--- Comment #6 from paolo dot carlini at oracle dot com 2009-05-19 16:42 --- I think that, in any case, we cannot do anything wrong here: we are simply restoring an implementation detail of the previous implementations, which, as a side effect, allows to compile this specific kind of sn

[Bug c++/40192] [4.4/4.5 Regression] Unable to use std::vector with typedef'd array types

--- Comment #5 from jeff at schwabcenter dot com 2009-05-19 16:36 --- Whoa whoa whoa... The behavior seemed correct before. vector shouldn't even be legal. Shouldn't the compiler to catch such a mistake? -- jeff at schwabcenter dot com changed: What|Removed

[Bug bootstrap/40198] No rule to make target `proto', needed by `native'. Stop.

--- Comment #2 from joseph at codesourcery dot com 2009-05-19 16:15 --- Subject: Re: No rule to make target `proto', needed by `native'. Stop. protoize and unprotoize were removed in 4.5 having been deprecated in 4.4 - either some reference did not get removed, or an old build comma

[Bug bootstrap/40198] No rule to make target `proto', needed by `native'. Stop.

--- Comment #1 from hjl dot tools at gmail dot com 2009-05-19 16:09 --- I have no problems with 4.5 revision 147705 on Linux/ia32. If you still have problems, please post the English version of the error messages. -- hjl dot tools at gmail dot com changed: What|Remove

[Bug fortran/27613] compile fails with "Unclassifiable statement" error message

--- Comment #12 from tobi at gcc dot gnu dot org 2009-05-19 15:55 --- Add an ampersand (&) (In reply to comment #11) > write(*,*)kandidat, ' ist nicht Teiler' & here ^^ and be sure to read the section on continuation lines in your Fo

[Bug fortran/27613] compile fails with "Unclassifiable statement" error message

--- Comment #11 from theresa dot adelt at greselius dot net 2009-05-19 15:45 --- Hello! I need help, too. I want to compile with g95 the following easy program: program prim ! Testet, ob eine gegebene Zahl prim integer :: kandidat, teiler, rest kandidat = 7099 do teiler = 2, kandidat

[Bug fortran/40197] [4.5 Regression] Spu fortran does not build

--- Comment #2 from pinskia at gcc dot gnu dot org 2009-05-19 14:36 --- Actually http://gcc.gnu.org/ml/gcc-patches/2009-05/msg01181.html is a better patch since PTRDIFF_TYPE and SIZE_TYPE are documented to have defaults. -- pinskia at gcc dot gnu dot org changed: What

[Bug c/40199] New: crash when using -std=gnu99, no crash without -std=gnu99

Compiling the following program causes gcc to crash when using the -std=gnu99 option, but there is no crash without this option. I need to use this option because the program uses language features such as loop initial declarations which require passing -std=c99 or -std=gnu99 option. =

[Bug tree-optimization/40198] New: No rule to make target `proto', needed by `native'. Stop.

Compiling GCC-4.5.0:trunk or 20090514 fails on my System Gentoo Intel Atom N270 With following log message: > tmp-mlib.h; \ fi echo '#include "tree.def"' > tmp-all-tree.def echo timestamp > s-gtyp-input lsf=""; for f in $lsf; do \ echo "#include \"$f\""; \

[Bug target/40197] Spu fortran does not build

--- Comment #1 from meissner at linux dot vnet dot ibm dot com 2009-05-19 12:35 --- Created an attachment (id=17892) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17892&action=view) Define PTRDIFF_TYPE, SIZE_TYPE. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40197

[Bug target/40197] New: Spu fortran does not build

Spu.h needs to define PTRDIFF_TYPE, since fortran now uses this in compiling trans-types. SIZE_TYPE probably should also be defined. gcc -c -g -O2 -DIN_GCC -DCROSS_DIRECTORY_STRUCTURE -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -Wcast-qual -Wold-style-definition -Wc++-comp

[Bug middle-end/40194] fortran rules for optimizing

--- Comment #7 from rguenth at gcc dot gnu dot org 2009-05-19 12:10 --- Hm, no. It doesn't pass it by value. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40194

[Bug middle-end/40194] fortran rules for optimizing

--- Comment #6 from rguenth at gcc dot gnu dot org 2009-05-19 12:04 --- The intel compiler passes I1 by value: ..___tag_value_f1_.1: #1.18 subq $24, %rsp #1.18 ..___tag_value_f1_.3:

[Bug middle-end/40194] fortran rules for optimizing

--- Comment #5 from jv244 at cam dot ac dot uk 2009-05-19 11:54 --- (In reply to comment #3) > Does > > SUBROUTINE S(I1,IP) > INTEGER,INTENT(IN) :: I1 > INTEGER, POINTER :: IP > END SUBROUTINE S > > allow that S stores the pointer to I1 to global memory? this is no

[Bug fortran/40196] F2003: Type parameter inquiry (str%len, a%kind) and Complex parts (z%re, z%im)

--- Comment #1 from burnus at gcc dot gnu dot org 2009-05-19 11:36 --- Another related item are complex parts; contrary to the type parameter inquiry above, those are lvalues and can be assigned to. (Again a F2003 feature, quote is however from F2008.) "R615 complex-part-designator is

[Bug fortran/40196] New: F2003: Type parameter inquiry: str%len, a%kind

Type parameter inquiry: str%len is equivalent to len(str) a%kind is equivalent to kind(a) The real fun part starts with user-defined kinds, e.g. type tp(dim) integer, KIND :: dim real :: dist(dim) end type tp type(tp) :: t(5) print *, t%dist%dim Quote from F2008 but F2003 should

[Bug target/40129] M16C invalid shift count used by pack_d -> ashldi3

--- Comment #5 from eightdot at hotmail dot com 2009-05-19 11:23 --- i agree but could find in which release they are first included.. but already fixed in what i now use (4.3.3)... -- eightdot at hotmail dot com changed: What|Removed |Added --

[Bug fortran/40195] New: ICE when compiling a file located in another directory

D:\test\bin>gfortran -c ..\source\t2.f90 Fatal Error: Can't delete module file 'm.mod': Permission denied gfortran: Internal error: Aborted (program f951) Please submit a full bug report. See for instructions. File ..\source\t2.f90 : MODULE m END MODULE --

[Bug fortran/38979] OpenMP extension: THREADPRIVATE for EQUIVALENCEd symbols

--- Comment #8 from arjen dot verweij at tass-safe dot com 2009-05-19 10:59 --- We use xlf 10.1.0.0 5724-M1300 on AIX and there is no problem there. The V10 manual[x] also prohibits it, but I don't see the V12 manual stating they broke backwards compatability, so I will assume that it w

[Bug middle-end/40194] fortran rules for optimizing

--- Comment #4 from rguenth at gcc dot gnu dot org 2009-05-19 10:39 --- Hmm, DECL_BY_REFERENCE is set too often. Maybe in addition set/check TREE_READONLY. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40194

[Bug middle-end/40194] fortran rules for optimizing

--- Comment #3 from rguenth at gcc dot gnu dot org 2009-05-19 10:20 --- Does SUBROUTINE S(I1,IP) INTEGER,INTENT(IN) :: I1 INTEGER, POINTER :: IP END SUBROUTINE S allow that S stores the pointer to I1 to global memory? I think that the easiest way to improve Fortran

[Bug middle-end/40194] fortran rules for optimizing

--- Comment #2 from jv244 at cam dot ac dot uk 2009-05-19 10:14 --- the context of the report is http://gcc.gnu.org/ml/gcc/2009-05/msg00465.html in particular, fortran variables are often not 'addressable' in the sense that seems to be important of the gcc optimizers -- http://gc

[Bug libgomp/40174] Memory leak when using '#pragma omp parallel'

--- Comment #2 from to dot my dot trociny at gmail dot com 2009-05-19 10:06 --- The patch works for me. Actually, calling mutex_destroy in gomp_thread_start() before return was the first my solution and it solved my problem too. But I am not very familiar with libgomp so I was not comp

[Bug middle-end/40194] fortran rules for optimizing

--- Comment #1 from jv244 at cam dot ac dot uk 2009-05-19 10:01 --- OK, updated testcase, while the argument still holds for the previous code, this was the intended code, and the generated code is even worse: INTEGER FUNCTION F1() INTEGER :: I1 INTEGER, TARGET :: I2 INTEGER, POIN

[Bug middle-end/40194] New: fortran rules for optimizing

The return value of this function is known at compile time, but from looking at dump-tree-optimized this seems not to be optimized as such. INTEGER FUNCTION F1() INTEGER :: I1 INTEGER, TARGET :: I2 INTEGER, POINTER :: IP INTERFACE SUBROUTINE S(I1,I2) INTEGER,INTENT(IN) :: I1

[Bug libfortran/40190] DATE_AND_TIME returns GMT hour sometimes with OpenMP

--- Comment #4 from dfranke at gcc dot gnu dot org 2009-05-19 09:11 --- (In reply to comment #3) > HJL is right, we should use the _r functions if available, if not we must > protect the calls with a mutex. Janne, if mutexes are added, could you also add a note to the docs of that these

[Bug target/35623] RTL check failure in arm_const_double_rtx

--- Comment #5 from mikpe at it dot uu dot se 2009-05-19 08:24 --- (In reply to comment #1) > I've been bootstrapping trunk pretty regularly for arm-linux-gnueabi on the > compile farm (though not building with latest libc) and haven't seen such a > problem . Note that the bug report is

[Bug libgomp/40174] Memory leak when using '#pragma omp parallel'

--- Comment #1 from jakub at gcc dot gnu dot org 2009-05-19 07:31 --- Created an attachment (id=17891) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17891&action=view) gcc45-pr40174.patch thr->release is owned by thread, not team, and is initialized by the thread, so it should be