[Bug fortran/37159] RANDOM_SEED: PUT= check array size at compile time

--- Comment #1 from burnus at gcc dot gnu dot org 2008-08-24 06:36 --- Patch: http://gcc.gnu.org/ml/fortran/2008-08/msg00190.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37159

[Bug rtl-optimization/37219] [4.3/4.4 Regression] fwprop1 is broken for addresses

--- Comment #1 from pinskia at gcc dot gnu dot org 2008-08-24 03:55 --- Here is the patch which I am testing: Index: fwprop.c === --- fwprop.c(revision 139496) +++ fwprop.c(working copy) @@ -1056,7 +1056,9 @@ fwprop

[Bug rtl-optimization/37219] New: [4.3/4.4 Regression] fwprop1 is broken for addresses

When looking into a regression for the PS3 toolchain (when I merged from 4.1.1 to 4.3.0), I noticed fwprop1 does not prop addresses at all since loop_father will always be non NULL as the "outer loop" always exists. The outer loop includes the whole function. I have a patch which fixes the issue

[Bug middle-end/37218] New: [4.4 Regression] Revision 139525 caused many SLP regressions

On Linux/ia32, Revision 139525 caused FAIL: gcc.dg/vect/slp-14.c scan-tree-dump-times vect "vectorized 1 loops" 1 FAIL: gcc.dg/vect/slp-14.c scan-tree-dump-times vect "vectorizing stmts using SLP" 2 FAIL: gcc.dg/vect/slp-15.c scan-tree-dump-times vect "vectorized 1 loops" 1 FAIL: gcc.dg/vect/slp-1

[Bug c++/37217] ICE on Valid Code

--- Comment #1 from mckelvey at maskull dot com 2008-08-24 01:41 --- Created an attachment (id=16135) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16135&action=view) Compressed preprocessed source -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37217

[Bug c++/37217] New: ICE on Valid Code

This code has been working forever: $ g++ -v Using built-in specs. Target: i686-pc-cygwin Configured with: /cygdrive/f/Home/cvsroot/gcc/configure --verbose --enable-threads --disable-nls --disable-win32-registry --enable-languages=c,c++ Thread model: posix gcc version 4.4.0 20080823 (experimental

[Bug bootstrap/25502] I64d format Werror problem in build

--- Comment #19 from aaronavay62 at aaronwl dot com 2008-08-24 01:17 --- Kai, I'm assigning this to you because you said on IRC a month or two ago that you were working on a patch for this. I've been working around this with a local patch that adds __extension__ everywhere that needs i

[Bug c/21920] aliasing violations

--- Comment #129 from schwab at suse dot de 2008-08-23 23:07 --- *** Bug 37214 has been marked as a duplicate of this bug. *** -- schwab at suse dot de changed: What|Removed |Added ---

[Bug c/37214] Weird operation reordering when compiling with -O3/O2 leading to errornous result

--- Comment #1 from schwab at suse dot de 2008-08-23 23:07 --- You are violating the C/C++ aliasing rules. *** This bug has been marked as a duplicate of 21920 *** -- schwab at suse dot de changed: What|Removed |Added -

[Bug c/37216] New: Invalid XMM instructions generated with -O3

GCC generates an XMM instruction with a memory operand not 16-byte aligned as it should be (i think), this generates a segmentation fault when run. Input file: (test.c) - int iarr[64]; int iint = 0; int main() { int i; for(i=0;i<64;i++)

[Bug preprocessor/37215] New: ICE on 'gcc -E -dM -fpreprocessed - < /dev/null'

Executing 'gcc -E -dM -fpreprocessed - < /dev/null' gives: :1: internal compiler error: Segmentation fault Please submit a full bug report, with preprocessed source if appropriate. See for instructions. Environment: System: L

[Bug c/37214] New: Weird operation reordering when compiling with -O3/O2 leading to errornous result

2 instruction are inverted in the compiled code so the result is wrong. The compilation is ok when using no optimization, but the problem happen with -O3 and -O2. Here is the function to compile: void test2(uint32_t* source, uint32_t* dest) { *dest=*source; *(uint16_t*)dest = (*(

[Bug target/37094] [4.4 Regression] Ada build broken for i586

--- Comment #7 from ebotcazou at gcc dot gnu dot org 2008-08-23 21:08 --- The Ada compiler builds again. -- ebotcazou at gcc dot gnu dot org changed: What|Removed |Added

[Bug c++/37213] New: Declaration/expression ambiguity resolution does not extend beyond initializer

When compiling the following program: struct S {int z;}; typedef S* (*FuncType)(int,int); int x,y; S* a() { FuncType(a)(x,y)->z = 0; // treated as declaration return 0; } This is the result: t.cpp: In function 'S* a()': t.cpp:5: error: initializer expression list treated as compound expres

[Bug target/31897] [4.3 Regression] 30% speed regression with -m32 on Opteron with rnflow

--- Comment #14 from ubizjak at gmail dot com 2008-08-23 20:07 --- Looking at http://users.physik.fu-berlin.de/~tburnus/gcc-trunk/benchmark/, it looks that the problem was mysteriously fixed in recent mainline. -- ubizjak at gmail dot com changed: What|Removed

[Bug target/37094] [4.4 Regression] Ada build broken for i586

--- Comment #6 from hubicka at gcc dot gnu dot org 2008-08-23 20:03 --- Subject: Bug 37094 Author: hubicka Date: Sat Aug 23 20:02:08 2008 New Revision: 139522 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=139522 Log: PR target/37094 * i386.c (standard_80387_con

[Bug c/36299] spurious and undocumented warning with -Waddress for a == 0 when a is an array

--- Comment #3 from vincent at vinc17 dot org 2008-08-23 20:00 --- (In reply to comment #2) > this warning was added on purpose, because probably someone requested it. I > don't see that it is very different from the documented case of using the > address of a function in a conditional.

[Bug fortran/37201] ICE in in gfc_conv_string_parameter

--- Comment #4 from burnus at gcc dot gnu dot org 2008-08-23 19:45 --- Actually, removing the assert --- /home/tob/projects/gcc/gcc/fortran/trans-expr.c (Revision 139520) +++ /home/tob/projects/gcc/gcc/fortran/trans-expr.c @@ -4008,2 +4008,0 @@ gfc_conv_string_parameter (gfc_se * se

[Bug fortran/37205] BIND(C): Character FUNCTION foo() -> ICE

--- Comment #1 from burnus at gcc dot gnu dot org 2008-08-23 19:13 --- Actually, this PR was first ... *** This bug has been marked as a duplicate of 37201 *** -- burnus at gcc dot gnu dot org changed: What|Removed |Added -

[Bug fortran/37201] ICE in in gfc_conv_string_parameter

--- Comment #3 from burnus at gcc dot gnu dot org 2008-08-23 19:13 --- *** Bug 37205 has been marked as a duplicate of this bug. *** -- burnus at gcc dot gnu dot org changed: What|Removed |Added -

[Bug fortran/37076] Concatenation of KIND=4 strings with KIND=4 parameters fails

--- Comment #2 from burnus at gcc dot gnu dot org 2008-08-23 18:51 --- Subject: Bug 37076 Author: burnus Date: Sat Aug 23 18:49:43 2008 New Revision: 139521 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=139521 Log: 2008-08-23 Tobias Burnus <[EMAIL PROTECTED]> PR fort

[Bug fortran/37076] Concatenation of KIND=4 strings with KIND=4 parameters fails

--- Comment #1 from burnus at gcc dot gnu dot org 2008-08-23 18:51 --- FIXED on the trunk (4.4). -- burnus at gcc dot gnu dot org changed: What|Removed |Added

[Bug c++/31246] -Wunreachable-code warnings for compiler-generated code

--- Comment #25 from manu at gcc dot gnu dot org 2008-08-23 18:50 --- This looks clearer to me. Maybe Jason or Mark have some idea where this code is generated. It should be clear that it is compiler-generated and we can set DECL_ARTIFICIAL or TREE_NO_WARNING. Then we just have to make s

[Bug c++/31246] Strange -Wunreachable-code warnings

--- Comment #24 from paolo dot carlini at oracle dot com 2008-08-23 18:45 --- I'm going to tweak a bit the Summary, seems misleading now. -- paolo dot carlini at oracle dot com changed: What|Removed |Added -

[Bug c++/31246] Strange -Wunreachable-code warning with _GLIBCXX_DEBUG

--- Comment #23 from paolo dot carlini at oracle dot com 2008-08-23 18:43 --- To be clear, there are no #pragma GCC system_header at all in the entire libsupc++ directory. I hope we don't have to begin... -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31246

[Bug middle-end/37170] [4.4 Regression]: gcc.dg/weak/weak-1.c

--- Comment #32 from hp at gcc dot gnu dot org 2008-08-23 18:38 --- Thanks, I got everything I need. The problem seen for the Darwin bootstrap is caused not by the output_operand call to assemble_external, but by another call, in cp/decl2.c:mark_used. Plainly treating that (as now) the

[Bug fortran/37025] ICE with TRANSFER to non-default-kind character: transfer(int(z'bde4'),4_'a')

--- Comment #2 from burnus at gcc dot gnu dot org 2008-08-23 18:21 --- FIXED on the trunk (4.4). -- burnus at gcc dot gnu dot org changed: What|Removed |Added

[Bug c/30260] Enumeration types and enumeration constants erroneously given unsigned types

--- Comment #6 from manu at gcc dot gnu dot org 2008-08-23 18:20 --- In GCC 4.4 we produce the same output independently of -pedantic: (a < 0) = 1, (A2 < 0) = 1, A{1,2} = +0, -1 (b < 0) = 0, (B2 < 0) = 0, B{1,2} = +0, -1 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30260

[Bug fortran/37025] ICE with TRANSFER to non-default-kind character: transfer(int(z'bde4'),4_'a')

--- Comment #1 from burnus at gcc dot gnu dot org 2008-08-23 18:13 --- Subject: Bug 37025 Author: burnus Date: Sat Aug 23 18:12:30 2008 New Revision: 139520 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=139520 Log: 2008-08-23 Tobias Burnus <[EMAIL PROTECTED]> PR fort

[Bug c++/37004] [C++ only] Wconversion warns for short y = 0x7fff; short z = (short) x & y;

--- Comment #3 from manu at gcc dot gnu dot org 2008-08-23 18:06 --- In C: /* Wrapper around c_common_type that is used by c-common.c and other front end optimizations that remove promotions. ENUMERAL_TYPEs are allowed here and are converted to their compatible integer types.

[Bug tree-optimization/36218] [4.2/4.3/4.4 regression] VRP causes stack overflow while building libgcj

--- Comment #16 from aaronavay62 at aaronwl dot com 2008-08-23 18:06 --- (In reply to comment #15) > This should be fixed on the trunk by > 2008-08-20 Richard Guenther <[EMAIL PROTECTED]> > can someone verify this? Thanks. Yes and no. On revision 139510 (2008-08-23), the compilati

[Bug c++/31246] Strange -Wunreachable-code warning with _GLIBCXX_DEBUG

--- Comment #22 from manu at gcc dot gnu dot org 2008-08-23 17:24 --- In addition, __cxa_call_unexpected should probably have both TREE_NO_WARNING and DECL_ARTIFICIAL set but this is orthogonal because at the point of the warning we should not be testing that. -- http://gcc.gnu.org/

[Bug middle-end/37161] [4.4 Regression]: Revision 139225 caused gfortran.dg/vect/pr33301.f -O

--- Comment #2 from irar at gcc dot gnu dot org 2008-08-23 17:05 --- Subject: Bug 37161 Author: irar Date: Sat Aug 23 17:04:12 2008 New Revision: 139518 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=139518 Log: PR tree-optimization/37161 * tree-vectorizer.h (vec

[Bug fortran/37212] New: TRANSFER: Simplify array argument

In the following program, transfer could be simplified at compile time, however, this does not happen. Additionally is the following is not needed: - Call to _gfortran_internal_pack. There is no way the array could be noncontiguous. - Call to _gfortran_internal_unpack. There is no need to un

[Bug fortran/37211] New: TRANSFER to characters: Size checking

For the following gfortran should print: "Intrinsic TRANSFER at %L has partly undefined result: " "source size %ld < result size %ld but this does not work. character(len=20) :: str str = transfer(10,str) end Ditto for character( KIND=4 ,len=20) -- Summary: TRANSFER to characte

[Bug fortran/37201] ICE in in gfc_conv_string_parameter

--- Comment #2 from jvdelisle at gcc dot gnu dot org 2008-08-23 16:54 --- Needed a little better summary -- jvdelisle at gcc dot gnu dot org changed: What|Removed |Added

[Bug c++/31246] Strange -Wunreachable-code warning with _GLIBCXX_DEBUG

--- Comment #21 from manu at gcc dot gnu dot org 2008-08-23 16:21 --- If gimple stmts do not have the equivalent of DECL_ARTIFICIAL, then the C++ front-end should use gimple_set_no_warning(stmt) when generating such constructs. So, anyone knows where this comes from? -- http://gcc.g

[Bug c++/31246] Strange -Wunreachable-code warning with _GLIBCXX_DEBUG

--- Comment #20 from manu at gcc dot gnu dot org 2008-08-23 16:13 --- For testcase in comment #4 I get 2 warnings now: home/manuel/test2/src/gcc/testsuite/g++.dg/warn/pr31246-2.C: In function ‘int* get_ptr(void*)’: /home/manuel/test2/src/gcc/testsuite/g++.dg/warn/pr31246-2.C:8: warning:

[Bug c++/31246] Strange -Wunreachable-code warning with _GLIBCXX_DEBUG

--- Comment #19 from manu at gcc dot gnu dot org 2008-08-23 16:01 --- (In reply to comment #4) > Here is a minimal code example: > > #include > > int* get_ptr(void* ptr) > { > return new(ptr) int(); > } I can reproduce this, though. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?

[Bug c++/31246] Strange -Wunreachable-code warning with _GLIBCXX_DEBUG

--- Comment #18 from manu at gcc dot gnu dot org 2008-08-23 15:59 --- (In reply to comment #0) > Compiling the following with "-Wunreachable-code -D_GLIBCXX_DEBUG" > -- > #include > > int main() > { > std::vector::iterator a; > } > -- >

[Bug other/35648] -Wall includes -Wwrite-strings

--- Comment #4 from manu at gcc dot gnu dot org 2008-08-23 15:40 --- Fixed in GCC 4.4. Thanks for the report. -- manu at gcc dot gnu dot org changed: What|Removed |Added

[Bug other/35648] -Wall includes -Wwrite-strings

--- Comment #3 from manu at gcc dot gnu dot org 2008-08-23 15:37 --- Subject: Bug 35648 Author: manu Date: Sat Aug 23 15:36:32 2008 New Revision: 139517 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=139517 Log: 2008-08-23 Manuel Lopez-Ibanez <[EMAIL PROTECTED]> PR 35

[Bug fortran/37203] Check ORDER= of RESHAPE

--- Comment #1 from tkoenig at gcc dot gnu dot org 2008-08-23 14:11 --- Confirmed. We should also have a run-time check for this: [EMAIL PROTECTED]:/tmp$ gfortran -fbounds-check foo.f90 [EMAIL PROTECTED]:/tmp$ ./a.out 1 6 2 0 3

[Bug c/7543] no warning for always-false "if (!a & 0x4)" bitwise and on boolean value

--- Comment #13 from manu at gcc dot gnu dot org 2008-08-23 13:49 --- (In reply to comment #8) > Thanks. (By the way, if there a gcc person interested in such a list, please > contact me.) I am interested in such a list. Thanks in advance. -- http://gcc.gnu.org/bugzilla/show_bug.

[Bug fortran/37131] inline matmul for small matrix sizes

--- Comment #4 from tkoenig at gcc dot gnu dot org 2008-08-23 13:18 --- Created an attachment (id=16134) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16134&action=view) test case Actually, the test cases were a bit unfair, because the middle-end decided not to calculate the valu

[Bug fortran/37201] ICE

--- Comment #1 from tkoenig at gcc dot gnu dot org 2008-08-23 13:07 --- Confirmed. Reduced test case: program test INTERFACE FUNCTION cdir() BIND(C,name="cdir") RESULT(r) CHARACTER(kind=1) :: r END FUNCTION END INTERFACE WRITE(*,*) ICHAR(cdir()) END PROGRAM -- t

[Bug c/36299] spurious and undocumented warning with -Waddress for a == 0 when a is an array

--- Comment #2 from manu at gcc dot gnu dot org 2008-08-23 12:53 --- Andrew, how could we detect that it is a decayed array? I think we would like to warn for if (a == (void *) 0) but not for if ((void *)a == 0) or even if possible not for if (&a[0] == 0) Vincent, this warni

[Bug c++/13358] long long and C++ do not mix well

--- Comment #20 from manu at gcc dot gnu dot org 2008-08-23 12:37 --- *** Bug 33736 has been marked as a duplicate of this bug. *** -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=13358

[Bug c++/33736] "error: integer constant is too large for �long� type" incorrect for C++0x

--- Comment #2 from manu at gcc dot gnu dot org 2008-08-23 12:37 --- I think this is a duplicate of 13358. The warning should be conditional on Wlong-long and Wlong-long should be disabled in -std=c++0x (in fact it is already). I am testing a patch btw. *** This bug has been marked as a

[Bug c++/13358] long long and C++ do not mix well

--- Comment #19 from manu at gcc dot gnu dot org 2008-08-23 12:26 --- OK, sorry, I needed -m32 in the command line to reproduce it. Is there a consensus here? It seems too pedantic to warn for something that GCC can handle perfectly well. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?

[Bug other/37210] New: Prohibit Default Builds in the GCC Source Tree

The gcc configuration instructions *highly* recommend building outside the gcc source tree, and often, following the gcc-help list, I see that doing so causes problems. I propose that the build process be modified so as to default to *failing* to build under those circumstances. Add a configurati

[Bug middle-end/37174] [4.4 Regression] ICE: in vinfo_for_stmt, at tree-vectorizer.h:546

--- Comment #9 from burnus at gcc dot gnu dot org 2008-08-23 11:41 --- *** Bug 37209 has been marked as a duplicate of this bug. *** -- burnus at gcc dot gnu dot org changed: What|Removed |Added -

[Bug middle-end/37209] [4.4 Regression] ICE in vinfo_for_stmt, at tree-vectorizer.h:546

--- Comment #2 from burnus at gcc dot gnu dot org 2008-08-23 11:41 --- Solved by the patch for PR 37174. *** This bug has been marked as a duplicate of 37174 *** -- burnus at gcc dot gnu dot org changed: What|Removed |Added ---

[Bug middle-end/37174] [4.4 Regression] ICE: in vinfo_for_stmt, at tree-vectorizer.h:546

--- Comment #8 from irar at il dot ibm dot com 2008-08-23 11:32 --- Fixed. -- irar at il dot ibm dot com changed: What|Removed |Added Status|ASSIGNED

[Bug c++/13358] long long and C++ do not mix well

--- Comment #18 from manu at gcc dot gnu dot org 2008-08-23 11:31 --- I cannot reproduce the warning in C or C++. It seems this got "fixed" silently. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=13358

[Bug middle-end/37209] [4.4 Regression] ICE in vinfo_for_stmt, at tree-vectorizer.h:546

--- Comment #1 from irar at il dot ibm dot com 2008-08-23 11:31 --- I think it's a duplicate of pr37174. I've just committed the fix. Ira -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37209

[Bug middle-end/37209] New: [4.4 Regression] ICE in vinfo_for_stmt, at tree-vectorizer.h:546

Works here with: 2008-08-19-r139224 fails here with: 2008-08-20-r139252 (Note both had some patches applied, but looking at the diffs to the trunk at that time, they should not affect the failure.) $ gfortran -O3 test.f90 test.f90: In function 'euler': test.f90:1: internal compiler error: in vin

[Bug middle-end/37151] [4.4 Regression] ICE with -fprofile-use and -ftree-loop-linear

--- Comment #3 from burnus at gcc dot gnu dot org 2008-08-23 11:16 --- Platform: x86-64-linux (openSUSE Factory on AMD Athlon64). However, I cannot reproduce it anymore with the current trunk -> Close as WORKSFORME. -- burnus at gcc dot gnu dot org changed: What|Remov

[Bug middle-end/37174] [4.4 Regression] ICE: in vinfo_for_stmt, at tree-vectorizer.h:546

--- Comment #7 from irar at gcc dot gnu dot org 2008-08-23 10:43 --- Subject: Bug 37174 Author: irar Date: Sat Aug 23 10:42:34 2008 New Revision: 139508 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=139508 Log: PR tree-optimization/37174 * tree-vect-analyze.c (v

[Bug c++/37208] C++0x deleted functions and SFINAE

--- Comment #2 from paolo dot carlini at oracle dot com 2008-08-23 09:31 --- Let's CC Jason... -- paolo dot carlini at oracle dot com changed: What|Removed |Added

[Bug middle-end/37170] [4.4 Regression]: gcc.dg/weak/weak-1.c

--- Comment #31 from andreast at gcc dot gnu dot org 2008-08-23 08:17 --- /Volumes/development/gcc/head/objdir-x86_64/./gcc/cc1plus -fpreprocessed prims.ii -fPIC -feliminate-unused-debug-symbols -quiet -dumpbase prims.cc -mmacosx-version-min=10.5.4 -mtune=generic -auxbase-strip .libs/p

[Bug fortran/35937] Wrong type for charlength of function

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

[Bug fortran/36534] Bogus: '__convert_s1_s4' at (1) is obsolescent in fortran 95

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

[Bug target/36722] ICE with inline asm in 64bit mode because of type size

--- Comment #4 from schwab at suse dot de 2008-08-23 07:58 --- It's still an ice-on-invalid, and as such a valid bug. -- schwab at suse dot de changed: What|Removed |Added

[Bug target/36722] ICE with inline asm in 64bit mode because of type size

--- Comment #3 from ubizjak at gmail dot com 2008-08-23 07:21 --- (In reply to comment #2) > looks like a PR37191 No. Register constraints in the testcase are just not what they look like. "=rax" in fact specifies multiple constraints, and that includes: "r" for general integer reg "