[Bug fortran/37802] New: [4.4 Regression] array descriptors for matmul messed up?

>From Dominique, a potential wrong-code: $ cat mat-2.f90 program mat implicit none complex, allocatable :: a(:,:),b(:,:) complex :: d(1,1) allocate(a(4,1),b(4,1)) a = cmplx(0.5,2.0) b = cmplx(2.0,0.5) d = matmul(a,transpose(b)) print *, d print *, matmul(a,transpose(

[Bug target/35760] [4.4 Regression] ICE with complex types and -static on PPC darwin

--- Comment #3 from jakub at gcc dot gnu dot org 2008-10-11 08:57 --- Subject: Bug 35760 Author: jakub Date: Sat Oct 11 08:55:43 2008 New Revision: 141055 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=141055 Log: PR target/35760 * config/rs6000/rs6000.c (rs6000_

[Bug fortran/37802] [4.4 Regression] array descriptors for matmul messed up?

--- Comment #1 from burnus at gcc dot gnu dot org 2008-10-11 09:31 --- I don't think this is a regression. In any case matmul(a,transpose(b)) produces a 4x4 array (16 elements), however, d is a 1x1 array. As one writes 8*15 = 120 bytes somewhere into the memory, it is not surprising t

[Bug fortran/35680] [4.3/4.4 regression] ICE on invalid transfer in variable declaration

--- Comment #17 from pault at gcc dot gnu dot org 2008-10-11 10:02 --- Fixed on trunk and 4.3 Thanks for the report, FX (I hope that you still keep an eye on the PRs!) Paul -- pault at gcc dot gnu dot org changed: What|Removed |Added

[Bug fortran/35840] ICE for character expression in I/O specifier

--- Comment #15 from dominiq at lps dot ens dot fr 2008-10-11 10:35 --- Ping! -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35840

[Bug fortran/37794] [4.3/4.4 Regression] Fortran module overloading regression

--- Comment #3 from pault at gcc dot gnu dot org 2008-10-11 10:40 --- This is my doing - see fix for PRs36374 and 37274. The offending block of code is redundant. The subsequently developed elements of the patch covered the problems and I just had not twigged the redundancy. I'll fix

[Bug fortran/37802] Improve wording for matmul bound checking

--- Comment #3 from burnus at gcc dot gnu dot org 2008-10-11 11:11 --- (In reply to comment #2) > In the original post I wrote: > > Between revisions 140923 and 140951 the following (invalid) code: I had not read the mailing list when I reading this PR. (See: http://gcc.gnu.org/ml/fortr

[Bug target/35760] [4.4 Regression] ICE with complex types and -static on PPC darwin

--- Comment #4 from jakub at gcc dot gnu dot org 2008-10-11 09:00 --- Fixed. Thanks Andreas for testing. -- jakub at gcc dot gnu dot org changed: What|Removed |Added

[Bug fortran/37794] [4.3/4.4 Regression] Fortran module overloading regression

--- Comment #5 from pault at gcc dot gnu dot org 2008-10-11 12:37 --- Subject: Bug 37794 Author: pault Date: Sat Oct 11 12:36:13 2008 New Revision: 141058 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=141058 Log: 2008-10-11 Paul Thomas <[EMAIL PROTECTED]> PR fortran/

[Bug fortran/37802] [4.4 Regression] array descriptors for matmul messed up?

--- Comment #2 from dominiq at lps dot ens dot fr 2008-10-11 10:09 --- In the original post I wrote: > Between revisions 140923 and 140951 the following (invalid) code: > ... > Since the code is invalid (d = matmul...), gfortran is indeed allowed to do > whatever is happening, but I'ld

[Bug c++/37804] friend declaration leaks into global scope at template instantiation

--- Comment #1 from rguenth at gcc dot gnu dot org 2008-10-11 13:07 --- Confirmed. The friend declaration seems to inject Internal_B into the global namespace at the point of instantiating the template A. Reduced testcase: template struct A { friend class B; }; A a; // here we inj

[Bug c++/37804] New: Nested type leaks to global scope

GCC versions used: gcc version 4.1.2 gcc version 4.4.0 20081011 (experimental) (GCC) svn revision 141055 Command line used: g++ -Wall -Wextra bug.cc The following code should fail to compile as Internal_B is a private class within class A. Both tested version of gcc successfully compile it with

[Bug fortran/35680] [4.3/4.4 regression] ICE on invalid transfer in variable declaration

--- Comment #16 from pault at gcc dot gnu dot org 2008-10-11 09:59 --- Subject: Bug 35680 Author: pault Date: Sat Oct 11 09:58:38 2008 New Revision: 141056 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=141056 Log: 2008-10-11 Paul Thomas <[EMAIL PROTECTED]> PR fortran

[Bug fortran/37803] New: Call mpfr_check_range after setting emin/emax

FX wrote: > For a few months now, I've seen a failure of gfortran.dg/ nearest_4.f90 on my > x86_64-linux build machine; the fact that noone else saw it, I suppose, is > because I use GMP and MPFR built with internal checking (assertions) enabled. > The following patch fixes it: + mpfr_check_range

[Bug c++/21312] [4.2 Regression] Access violation diagnostic given twice

--- Comment #11 from simartin at gcc dot gnu dot org 2008-10-11 13:17 --- This has been fixed in 4.3.0 with the fix for PR29048 (similar patch as the one I had submitted here). -- simartin at gcc dot gnu dot org changed: What|Removed |Added --

[Bug debug/37002] [4.4 Regression] No debug info on unreferenced parameters after stack alignment

--- Comment #5 from jakub at gcc dot gnu dot org 2008-10-11 09:01 --- Fixed. -- jakub at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED

[Bug fortran/37794] [4.3/4.4 Regression] Fortran module overloading regression

--- Comment #4 from pault at gcc dot gnu dot org 2008-10-11 12:10 --- Subject: Bug 37794 Author: pault Date: Sat Oct 11 12:09:23 2008 New Revision: 141057 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=141057 Log: 2008-10-11 Paul Thomas <[EMAIL PROTECTED]> PR fortran/

[Bug fortran/19925] Implied do-loop in an initialization expression is broken

--- Comment #29 from dominiq at lps dot ens dot fr 2008-10-11 10:31 --- On Sat, 20 Sep 2008 08:20:29 +0200, Paul Richard Thomas wrote (http://gcc.gnu.org/ml/gcc-patches/2008-09/msg01415.html): > It looks good to me - I'm just out of the door for the weekend (for > once!) - I'll attend t

[Bug fortran/37794] [4.3/4.4 Regression] Fortran module overloading regression

--- Comment #6 from pault at gcc dot gnu dot org 2008-10-11 14:17 --- Fixed on trunk and 4.3 as obvious. Thanks for the report Paul -- pault at gcc dot gnu dot org changed: What|Removed |Added -

[Bug middle-end/37535] [4.4 Regression] gcc/libgcc2.c:404: internal compiler error: Floating point exception

--- Comment #17 from danglin at gcc dot gnu dot org 2008-10-11 15:11 --- Fixed. -- danglin at gcc dot gnu dot org changed: What|Removed |Added Status|NEW

[Bug middle-end/37608] [4.4 Regression] libgcc2.c:1981: ICE: vector VEC(m em_ref_p,base) index domain error, in create_vop_ref_mapping_loop at tree-ssa-lo op-im.c:1519

--- Comment #8 from danglin at gcc dot gnu dot org 2008-10-11 15:18 --- *** Bug 37299 has been marked as a duplicate of this bug. *** -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37608

[Bug tree-optimization/37299] [4.4 Regression] libgcc2.c:806: ICE: vector VEC(me m_ref_p,base) index domain error, in create_vop_ref_mapping_loop at tree-ssa-loop-im.c:1519

--- Comment #5 from danglin at gcc dot gnu dot org 2008-10-11 15:18 --- *** This bug has been marked as a duplicate of 37608 *** -- danglin at gcc dot gnu dot org changed: What|Removed |Added --

[Bug fortran/35840] ICE for character expression in I/O specifier

--- Comment #16 from jvdelisle at gcc dot gnu dot org 2008-10-11 15:32 --- I will see if I can finalize this patch. Mikael, are you still with us? Your approach was fine. -- jvdelisle at gcc dot gnu dot org changed: What|Removed |Added ---

[Bug fortran/37792] ICE in gfc_conv_array_initializer; works with -fno-range-check

--- Comment #1 from burnus at gcc dot gnu dot org 2008-10-11 15:32 --- Approved Patch: http://gcc.gnu.org/ml/fortran/2008-10/msg00084.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37792

[Bug fortran/37472] bad output on default-format write of double in common block with -m64 flag i

--- Comment #6 from jvdelisle at gcc dot gnu dot org 2008-10-11 15:54 --- I will be looking at this. -- jvdelisle at gcc dot gnu dot org changed: What|Removed |Added

[Bug middle-end/37608] [4.4 Regression] libgcc2.c:1981: ICE: vector VEC(m em_ref_p,base) index domain error, in create_vop_ref_mapping_loop at tree-ssa-lo op-im.c:1519

--- Comment #9 from danglin at gcc dot gnu dot org 2008-10-11 15:55 --- Subject: Bug 37608 Author: danglin Date: Sat Oct 11 15:54:27 2008 New Revision: 141063 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=141063 Log: PR middle-end/37608 * pa.md (call, call_value

[Bug middle-end/37608] [4.4 Regression] libgcc2.c:1981: ICE: vector VEC(m em_ref_p,base) index domain error, in create_vop_ref_mapping_loop at tree-ssa-lo op-im.c:1519

--- Comment #10 from danglin at gcc dot gnu dot org 2008-10-11 16:01 --- The revised call patterns avoid the hard register clobber bug. -- danglin at gcc dot gnu dot org changed: What|Removed |Added

[Bug c/37805] New: gcc --help=separate

calling gcc with the inaccurate option '--help=separate' (gcc --help=separate) yields: cc1: internal compiler error: unrecognized include_flags 0x400 passed to print_specific_help Please submit a full bug report, with preprocessed source if appropriate. See for instr

[Bug fortran/37472] bad output on default-format write of double in common block with -m64 flag i

--- Comment #7 from jvdelisle at gcc dot gnu dot org 2008-10-11 15:59 --- Response to comment #4. We added 1 to the default width in 4.3. The rest has to do with the rounding logic. I dropped this bug in the crack, so assigned to myself so i will not forget it. -- http://gcc.gnu.

[Bug fortran/30249] Pointers not given target type in GFORTRAN

--- Comment #4 from burnus at gcc dot gnu dot org 2008-10-11 16:32 --- Jakub, I think GCC sets the wrong type for "rd". It has: <1><1bb>: Abbrev Number: 7 (DW_TAG_array_type) <1bc> DW_AT_name : (indirect string, offset: 0xf9): array2_real(kind=4) whereas for ifort I get: <1><

Re: [Bug c++/37804] New: Nested type leaks to global scope

Sent from my iPhone On Oct 11, 2008, at 5:28 AM, "therealfroggey at gmail dot com" <[EMAIL PROTECTED] > wrote: GCC versions used: gcc version 4.1.2 gcc version 4.4.0 20081011 (experimental) (GCC) svn revision 141055 Command line used: g++ -Wall -Wextra bug.cc The follo

[Bug c++/37804] friend declaration leaks into global scope at template instantiation

cc version 4.1.2 > gcc version 4.4.0 20081011 (experimental) (GCC) svn revision 141055 > Command line used: g++ -Wall -Wextra bug.cc > > The following code should fail to compile as Internal_B is a private > class > within class A. > Both tested version of g

[Bug c++/37804] friend declaration leaks into global scope at template instantiation

--- Comment #3 from rguenth at gcc dot gnu dot org 2008-10-11 18:46 --- Related to PR37775, PR34827 and PR31336. (search for accepts-invalid and 'friend') Seems like friend declarations are not an uncommon source for problems... -- rguenth at gcc dot gnu dot org changed:

[Bug middle-end/37485] [graphite] Disconnecting exit edge in process of code generation

--- Comment #13 from spop at gcc dot gnu dot org 2008-10-11 19:26 --- Subject: Re: [graphite] Disconnecting exit edge in process of code generation >Are there any overlapping scops with the current code? I haven't seen overlapping scops anymore. Thanks. -- http://gcc.gnu.org/bugz

[Bug c++/37806] New: CV-qualifiers on function typedef's are inconsistently accepted depending on typedef scope

Hi, First of all this is my first bug report to GNU GCC so please bare with me. The issue I having is with typedef assisted declarations of class/struct member functions. It seems to me that cv-qualifiers on function typedef's are treated inconsistantly depending on the scope of the typedef. The

[Bug c++/37806] CV-qualifiers on function typedef's are inconsistently accepted depending on typedef scope

--- Comment #1 from rguenth at gcc dot gnu dot org 2008-10-11 19:58 --- EDG accepts the code. With GCC 4.3 and newer we reject the code with t.C: In function ‘int main()’: t.C:32: error: cannot declare variable ‘s’ to be of abstract type ‘S3’ t.C:21: note: because the following virtu

[Bug ada/37799] SIGBUS compiling ada/ada.ads in stage2

--- Comment #1 from ebotcazou at gcc dot gnu dot org 2008-10-11 20:56 --- This works for me with GCC 4.4.0 20081011 + GAS 2.18.92 + Sun ld on Solaris 9. -- ebotcazou at gcc dot gnu dot org changed: What|Removed |Added

[Bug c/37807] New: Exponential compile time with MMX builtins.

Using MMX bultins in a sizeable but not extreme function leads to exponential compile time. Attached code will take an excessive compile time [I think hours]. Similar code using SSE compiles quickly for me. $ gcc --version gcc (GCC) 4.3.2 20081007 (Red Hat 4.3.2-6) Copyright (C) 2008 Free Softwa

[Bug c/37807] Exponential compile time with MMX builtins.

--- Comment #1 from suckfish at ihug dot co dot nz 2008-10-11 21:21 --- Created an attachment (id=16482) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16482&action=view) Code showing exponential compile time. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37807

[Bug c/37807] Exponential compile time with MMX builtins.

--- Comment #2 from suckfish at ihug dot co dot nz 2008-10-11 21:35 --- Using '-da' it looks like the 'combine' pass is the culprit: $ pidof cc1 6410 $ ls -l /proc/6410/fd ... 4 -> ... slow.c.162r.combine $ ls -s slow.c.162r.combine 0 slow.c.162r.combine [is there an easier way to get

[Bug c/37807] Exponential compile time with MMX builtins.

--- Comment #3 from rguenth at gcc dot gnu dot org 2008-10-11 22:06 --- On the trunk it's fast if you fix the testcase to do static INLINE value_t ROTATE_LEFT (value_t a, unsigned count) { return OR (LEFT (a, ((value_t){count, count})), RIGHT (a, ((value_t){32-count,32-count}))); }

[Bug c/37807] Exponential compile time with MMX builtins.

--- Comment #4 from suckfish at ihug dot co dot nz 2008-10-11 22:23 --- BTW, __builtin_ia32_psrld and __builtin_ia32_pslld are not documented on the 'X86 built-in functions' page of the manual. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37807

[Bug c/37807] Exponential compile time with MMX builtins.

--- Comment #5 from suckfish at ihug dot co dot nz 2008-10-11 23:02 --- It looks like nonzero_bits1 in rtlanal.c is going into an exponential recursion. AFAICS, that function doesn't deal properly with vector arithmetic anyway? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37807

[Bug c/37807] Exponential compile time with MMX builtins.

--- Comment #6 from suckfish at ihug dot co dot nz 2008-10-11 23:24 --- I think this function actually gets miscompiled: typedef int v2si __attribute__ ((vector_size (8))); v2si foo (v2si x) { x &= (v2si) 0xll; x = __builtin_ia32_psrad (x, 1); x &= (v2si) 0x800

[Bug middle-end/37448] [4.3 Regression] gcc 4.3.1 cannot compile big function

--- Comment #26 from zadeck at gcc dot gnu dot org 2008-10-11 23:40 --- Subject: Bug 37448 Author: zadeck Date: Sat Oct 11 23:39:21 2008 New Revision: 141067 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=141067 Log: 2008-10-11 Kenneth Zadeck <[EMAIL PROTECTED]> PR rtl

[Bug bootstrap/37808] New: [4.4 Regression]: Revision 141067 breaks Linux/x86

Revision 141067 http://gcc.gnu.org/ml/gcc-cvs/2008-10/msg00270.html breaks bootstrap on Linux/x86: [EMAIL PROTECTED] libgcc]$ /export/gnu/import/svn/gcc-test/bld/./gcc/xgcc -B/export/gnu/import/svn/gcc-test/bld/./gcc/ -B/usr/local/x86_64-unknown-linux-gnu/bin/ -B/usr/local/x86_64-unknown-linux-g

[Bug bootstrap/37808] [4.4 Regression]: Revision 141067 breaks Linux/x86

--- Comment #1 from hjl dot tools at gmail dot com 2008-10-12 02:02 --- Program received signal SIGSEGV, Segmentation fault. 0x0063d28e in df_set_bb_dirty (bb=0x0) at ../../src-trunk/gcc/df-core.c:1427 1427bitmap_set_bit (dflow->out_of_date_transfer_functions,

[Bug target/37808] [4.4 Regression]: Revision 141067 breaks Linux/x86

--- Comment #2 from pinskia at gcc dot gnu dot org 2008-10-12 02:20 --- This a target specific failure. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added

[Bug c/37809] New: Incorrect code with MMX right shift __builtin_ia32_psradi

Bug on both trunk and 4.3.2 [for the latter, change psradi to psrad as the builtin function name changed]. Compiling the following code with -O2 -flax-vector-conversions -mmmx -msse -msse2 generates incorrect code: typedef int v2si __attribute__ ((vector_size (8))); v2si foo (v2si x) { x &

[Bug c/37807] Exponential compile time with MMX builtins.

--- Comment #7 from suckfish at ihug dot co dot nz 2008-10-12 02:39 --- Bug 37809 opened for the issue in internal comment 6, as it is different. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37807

[Bug c/37809] Incorrect code with MMX right shift __builtin_ia32_psradi

--- Comment #1 from suckfish at ihug dot co dot nz 2008-10-12 02:47 --- Created an attachment (id=16483) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16483&action=view) Test case as a complete program. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37809

eEX For Stay Hard Longer During Sxen

WP http://spaces.live.com/rnwizscmivje?dxdnwnpbayf

[Bug c/37807] Exponential compile time with MMX builtins.

--- Comment #8 from suckfish at ihug dot co dot nz 2008-10-12 04:46 --- Created an attachment (id=16484) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16484&action=view) Test-case modfied to take exponential time on trunk too. It turns out that it was fast on trunk because inlinin

[Bug target/37808] [4.4 Regression]: Revision 141067 breaks Linux/x86

--- Comment #3 from zadeck at naturalbridge dot com 2008-10-12 04:56 --- Created an attachment (id=16485) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16485&action=view) possible patch to fix the problem I am pretty sure that this fixes it, but i need to do more testing. kenny

[Bug c/37807] Exponential compile time with MMX builtins.

--- Comment #9 from suckfish at ihug dot co dot nz 2008-10-12 05:22 --- Created an attachment (id=16486) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16486&action=view) Possible fix for 37807 Patch above essentially stops nonzero_bits1 and num_sign_bit_copies1 processing vector t

[Bug c/37807] Exponential compile time with MMX builtins.

--- Comment #10 from suckfish at ihug dot co dot nz 2008-10-12 05:27 --- Changelog for patch if accepted [will do full bootstrap & make test]: 2008-10-12 Ralph Loader <[EMAIL PROTECTED]> PR 37807 * rtlanal.c (numzero_bits1): Return early on vector types, avoiding