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

[tkoenig at gcc dot gnu dot org]

>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(b))
  deallocate(a,b)
end program mat
$ gfortran -g mat-2.f90
$ gdb ./a.out
GNU gdb 6.8-debian
Copyright (C) 2008 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later 
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "i486-linux-gnu"...
(gdb) r
Starting program: /home/ig25/Krempel/Matmul/a.out
 (  0.000,  4.250)
a.out: ../../../../gcc/trunk/libgfortran/generated/matmul_c4.c:96: matmul_c4:
Assertion `((a)->dtype & 0x07) == 2 || ((b)->dtype & 0x07) == 2' failed.

Program received signal SIGABRT, Aborted.
0xe410 in __kernel_vsyscall ()
(gdb) up
#1  0xb7d41640 in raise () from /lib/i686/cmov/libc.so.6
(gdb) up
#2  0xb7d43018 in abort () from /lib/i686/cmov/libc.so.6
(gdb) up
#3  0xb7d3a5be in __assert_fail () from /lib/i686/cmov/libc.so.6
(gdb) up
#4  0xb7f45d7d in *_gfortran_matmul_c4 (retarray=0xbfd6661c, a=0xbfd6680c,
b=0xbfd667b4,
try_blas=0, blas_limit=0, gemm=0)
at ../../../../gcc/trunk/libgfortran/generated/matmul_c4.c:95
95assert (GFC_DESCRIPTOR_RANK (a) == 2
(gdb) p/x a->dtype
$1 = 0x4088
(gdb) p/x b->dtype
$2 = 0x0
(gdb)


-- 
   Summary: [4.4 Regression] array descriptors for matmul messed up?
   Product: gcc
   Version: 4.4.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
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=37802

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

[jakub at gcc dot gnu dot org]

--- 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_legitimize_address): Only create
LO_SUM on Darwin if mode has just one unit.

* gcc.c-torture/compile/pr35760.c: New test.

Added:
trunk/gcc/testsuite/gcc.c-torture/compile/pr35760.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/rs6000/rs6000.c
trunk/gcc/testsuite/ChangeLog
trunk/gcc/tree-switch-conversion.c


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35760

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

[burnus at gcc dot gnu dot org]

--- 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
that the program crashes at some point.

With -fbounds-check I get the following error with gfortran 4.3 and 4.4:

Fortran runtime error: Incorrect extent in return array in MATMUL intrinsic for
dimension 1: is 1, should be 4

Thus marked as INVALID.


-- 

burnus at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||burnus at gcc dot gnu dot
   ||org
 Status|UNCONFIRMED |RESOLVED
 Resolution||INVALID


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37802

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

[pault at gcc dot gnu dot org]

--- 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

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35680

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

[dominiq at lps dot ens dot fr]

--- 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

[pault at gcc dot gnu dot org]

--- 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 as obvious on trunk and 4.3, after the usual incantations.

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-10-10 11:26:20 |2008-10-11 10:40:11
   date||


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37794

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

[burnus at gcc dot gnu dot org]

--- 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/fortran/2008-10/msg00066.html ) And Thomas' bug report
gave a completely different impression.

> > Since the code is invalid (d = matmul...), gfortran is indeed allowed to do
> > whatever is happening, but I'ld like to understand the new behavior
> > and be sure that it cannot happen for valid codes.

I think it only gets triggered due to the overwritten memory.

> Note 1: I think the error message with -fbounds-check is misleading:
> Note3: I think the same misleading error message happens for mat-2.f90 in

OK. I changed the bug summary and reopened the bug.


-- 

burnus at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|RESOLVED|UNCONFIRMED
   Keywords||diagnostic
 Resolution|INVALID |
Summary|[4.4 Regression] array  |Improve wording for matmul
   |descriptors for matmul  |bound checking
   |messed up?  |


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37802

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

[jakub at gcc dot gnu dot org]

--- 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

 Status|UNCONFIRMED |RESOLVED
 Resolution||FIXED


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35760

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

[pault at gcc dot gnu dot org]

--- 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/37794
* module.c (check_for_ambiguous): Remove redundant code.

2008-10-11  Paul Thomas  <[EMAIL PROTECTED]>

PR fortran/37794
* gfortran.dg/used_types_24.f90: New test.

Added:
branches/gcc-4_3-branch/gcc/testsuite/gfortran.dg/used_types_24.f90
Modified:
branches/gcc-4_3-branch/gcc/fortran/ChangeLog
branches/gcc-4_3-branch/gcc/fortran/module.c
branches/gcc-4_3-branch/gcc/testsuite/ChangeLog


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37794

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

[dominiq at lps dot ens dot fr]

--- 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 like to understand the new behavior
> and be sure that it cannot happen for valid codes.

I suggest to remove the "Regression" keyword, but leave the pr open until the
two questions are answered.

Note 1: I think the error message with -fbounds-check is misleading:

> With -fbounds-check I get the following error with gfortran 4.3 and 4.4:
> 
> Fortran runtime error: Incorrect extent in return array in MATMUL intrinsic 
> for
> dimension 1: is 1, should be 4

The problem is not with MATMUL, but with the assignment to d, so the error
should be something like:

Error: Different shape for array assignment at (1) on dimension 1 (1 and 4)

Note2: the code is coming from pr29572.

Note3: I think the same misleading error message happens for mat-2.f90 in
comment #2 of pr29572, as shown by the following run-time errors:

[ibook-dhum] f90/bug% a.out 
Fortran runtime error: dimension of array B incorrect in MATMUL intrinsic
[ibook-dhum] f90/bug% gfc -fbounds-check pr29572_1.f90
[ibook-dhum] f90/bug% a.out
Fortran runtime error: Incorrect extent in return array in MATMUL intrinsic for
dimension 1: is 1, should be 4

The first message is right and could be improved with something like:

"for dimension 1: is 4, should be 1"


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37802

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

[rguenth at gcc dot gnu dot org]

--- 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 inject a declaration of B into the global namespace

B some_function();  // B should not be declared here


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever Confirmed|0   |1
   Keywords||accepts-invalid
   Last reconfirmed|-00-00 00:00:00 |2008-10-11 13:07:05
   date||
Summary|Nested type leaks to global |friend declaration leaks
   |scope   |into global scope at
   ||template instantiation


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37804

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

[therealfroggey at gmail dot com]

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 no warnings.



template 
class A
{
private:
  class Internal_A
  {
friend class Internal_B;
  };
  class Internal_B { };
  Internal_A a;
};

A a;

Internal_B some_function();


-- 
   Summary: Nested type leaks to global scope
   Product: gcc
   Version: 4.4.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: therealfroggey at gmail dot com
 GCC build triplet: x86_64-linux-gnu
  GCC host triplet: x86_64-linux-gnu
GCC target triplet: x86_64-linux-gnu


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37804

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

[pault at gcc dot gnu dot org]

--- 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/35680
* gfortran.h : Add 'error' bit field to gfc_expr structure.
* expr.c (check_inquiry): When checking a restricted expression
check that arguments are either variables or restricted.
(check_restricted): Do not emit error if the expression has
'error' set.  Clean up detection of host-associated variable.

2008-10-11  Paul Thomas  <[EMAIL PROTECTED]>

PR fortran/35680
* gfortran.dg/transfer_array_intrinsic_5.f90: New test.

Added:
   
branches/gcc-4_3-branch/gcc/testsuite/gfortran.dg/transfer_array_intrinsic_5.f90
Modified:
branches/gcc-4_3-branch/gcc/fortran/ChangeLog
branches/gcc-4_3-branch/gcc/fortran/expr.c
branches/gcc-4_3-branch/gcc/fortran/gfortran.h
branches/gcc-4_3-branch/gcc/testsuite/ChangeLog


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35680

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

[burnus at gcc dot gnu dot org]

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 (result->value.real, 0, GMP_RNDU);
[...]
+ mpfr_check_range (q, 0, GFC_RND_MODE);

See http://gcc.gnu.org/ml/fortran/2008-04/msg00300.html


-- 
   Summary: Call mpfr_check_range after setting emin/emax
   Product: gcc
   Version: 4.4.0
Status: UNCONFIRMED
  Keywords: patch
  Severity: normal
  Priority: P3
 Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: burnus at gcc dot gnu dot org


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37803

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

[simartin at gcc dot gnu dot org]

--- 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

 CC||simartin at gcc dot gnu dot
   ||org
  Known to work||4.3.0
Summary|[4.2/4.3/4.4 Regression]|[4.2 Regression] Access
   |Access violation diagnostic |violation diagnostic given
   |given twice |twice


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21312

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

[jakub at gcc dot gnu dot org]

--- 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 |RESOLVED
 Resolution||FIXED


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37002

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

[pault at gcc dot gnu dot org]

--- 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/37794
* module.c (check_for_ambiguous): Remove redundant code.

2008-10-11  Paul Thomas  <[EMAIL PROTECTED]>

PR fortran/37794
* gfortran.dg/used_types_24.f90: New test.

Added:
trunk/gcc/testsuite/gfortran.dg/used_types_24.f90
Modified:
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/module.c
trunk/gcc/testsuite/ChangeLog


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37794

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

[dominiq at lps dot ens dot fr]

--- 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 to it tomorrow night if nobody beats me to it.

If I am not mistaken nothing happened since then.  Could the patch in
http://gcc.gnu.org/ml/gcc-patches/2008-09/msg01410.html be committed?


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19925

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

[pault at gcc dot gnu dot org]

--- 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

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37794

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

[danglin at gcc dot gnu dot org]

--- 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 |RESOLVED
 Resolution||FIXED


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37535

[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

[danglin at gcc dot gnu dot org]

--- 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

[danglin at gcc dot gnu dot org]

--- 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

 Status|UNCONFIRMED |RESOLVED
 Resolution||DUPLICATE


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37299

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

[jvdelisle at gcc dot gnu dot org]

--- 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

 AssignedTo|unassigned at gcc dot gnu   |jvdelisle at gcc dot gnu dot
   |dot org |org
 Status|NEW |ASSIGNED
   Last reconfirmed|2008-04-06 21:03:01 |2008-10-11 15:32:03
   date||


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35840

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

[burnus at gcc dot gnu dot org]

--- 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

[jvdelisle at gcc dot gnu dot org]

--- 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

 AssignedTo|unassigned at gcc dot gnu   |jvdelisle at gcc dot gnu dot
   |dot org |org
 Status|UNCONFIRMED |ASSIGNED
 Ever Confirmed|0   |1
   Last reconfirmed|-00-00 00:00:00 |2008-10-11 15:54:29
   date||


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37472

[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

[danglin at gcc dot gnu dot org]

--- 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): Generate an rtx for register r4 and pass
it to PIC call patterns.
(call_symref_pic): Revise pattern to expose PIC register save.  Remove
code generation and attributes from pattern.  Change peephole2 to split
for noreturn case.  Revise split pattern for non noreturn case.
(call_symref_64bit, call_reg_pic, call_reg_64bit, call_val_symref_pic,
call_val_symref_64bit, call_val_reg_pic, call_val_reg_64bit): Likewise.
* pa.c (attr_length_call): Simplify extraction of call rtx.  Add some
asserts.


Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/pa/pa.c
trunk/gcc/config/pa/pa.md


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37608

[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

[danglin at gcc dot gnu dot org]

--- 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

 Status|UNCONFIRMED |RESOLVED
 Resolution||FIXED


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37608

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

[hans dot buchmann at fhnw dot ch]

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 instructions.

gcc -v

Using built-in specs.
Target: i686-pc-linux-gnu
Configured with:
/var/tmp/portage/sys-devel/gcc-4.3.1-r1/work/gcc-4.3.1/configure --prefix=/usr
--bindir=/usr/i686-pc-linux-gnu/gcc-bin/4.3.1
--includedir=/usr/lib/gcc/i686-pc-linux-gnu/4.3.1/include
--datadir=/usr/share/gcc-data/i686-pc-linux-gnu/4.3.1
--mandir=/usr/share/gcc-data/i686-pc-linux-gnu/4.3.1/man
--infodir=/usr/share/gcc-data/i686-pc-linux-gnu/4.3.1/info
--with-gxx-include-dir=/usr/lib/gcc/i686-pc-linux-gnu/4.3.1/include/g++-v4
--host=i686-pc-linux-gnu --build=i686-pc-linux-gnu --disable-altivec
--enable-nls --without-included-gettext --with-system-zlib --disable-checking
--disable-werror --enable-secureplt --disable-multilib --enable-libmudflap
--disable-libssp --enable-cld --disable-libgcj --with-arch=i686
--enable-languages=c,c++,treelang,fortran --enable-shared
--enable-threads=posix --enable-__cxa_atexit --enable-clocale=gnu
--with-bugurl=http://bugs.gentoo.org/ --with-pkgversion='Gentoo 4.3.1-r1 p1.1'
Thread model: posix
gcc version 4.3.1 (Gentoo 4.3.1-r1 p1.1) 

Best regards

Hans Buchmann


-- 
   Summary: gcc --help=separate
   Product: gcc
   Version: 4.3.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: hans dot buchmann at fhnw dot ch
 GCC build triplet: i686-pc-linux-gnu
  GCC host triplet: i686-pc-linux-gnu
GCC target triplet: i686-pc-linux-gnu


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37805

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

[jvdelisle at gcc dot gnu dot org]

--- 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.org/bugzilla/show_bug.cgi?id=37472

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

[burnus at gcc dot gnu dot org]

--- 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><1fc>: Abbrev Number: 5 (DW_TAG_pointer_type)
<1fd>   DW_AT_type: <0x207>
<201>   DW_AT_associated  : 5 byte block: 97 6 10 0 2e 
(DW_OP_push_object_address; DW_OP_deref; DW_OP_constu: 0; DW_OP_ne)
 <1><207>: Abbrev Number: 6 (DW_TAG_array_type)

The DW_TAG_pointer_type and the DW_AT_associated should be there; gfortran has
DW_AT_allocated which should not be there as there is no allocatable variable.

Or do I miss something? My DWARF knowledge is limited.


(In reply to comment #3)
> With gdb on i686-apple-darwin9, I get either

You know that gdb does not yet support variable-length arrays such as Fortran's
assumed-shape arrays and C's (or was it C++'s?) VLA? This is work in progress
(thanks, Jan!), see:
  http://sourceware.org/ml/gdb-patches/2008-10/msg00248.html
  http://people.redhat.com/jkratoch/vla/
Thus I was testing with the Intel Debugger (idb).


-- 

burnus at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||jakub at redhat dot com


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30249

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

[Andrew Thomas Pinski]

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 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 no warnings.



template 
class A
{
private:
 class Internal_A
 {
   friend class Internal_B;


The above friend class refers to the class in containing namespace and  
not to the class inside the class.




 };
 class Internal_B { };
 Internal_A a;
};

A a;

Internal_B some_function();


The above should not compile but it is not because the inner class is  
leaking though. It is because the friend statement is causing an  
injection when it should not.






--
  Summary: Nested type leaks to global scope
  Product: gcc
  Version: 4.4.0
   Status: UNCONFIRMED
 Severity: normal
 Priority: P3
Component: c++
   AssignedTo: unassigned at gcc dot gnu dot org
   ReportedBy: therealfroggey at gmail dot com
GCC build triplet: x86_64-linux-gnu
 GCC host triplet: x86_64-linux-gnu
GCC target triplet: x86_64-linux-gnu


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37804

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

[pinskia at gmail dot com]

--- Comment #2 from pinskia at gmail dot com  2008-10-11 17:05 ---
Subject: Re:   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 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 no warnings.
>
> 
>
> template 
> class A
> {
> private:
>  class Internal_A
>  {
>friend class Internal_B;

The above friend class refers to the class in containing namespace and  
not to the class inside the class.

>
>  };
>  class Internal_B { };
>  Internal_A a;
> };
>
> A a;
>
> Internal_B some_function();

The above should not compile but it is not because the inner class is  
leaking though. It is because the friend statement is causing an  
injection when it should not.

>
>
>
> -- 
>   Summary: Nested type leaks to global scope
>   Product: gcc
>   Version: 4.4.0
>Status: UNCONFIRMED
>  Severity: normal
>  Priority: P3
> Component: c++
>AssignedTo: unassigned at gcc dot gnu dot org
>ReportedBy: therealfroggey at gmail dot com
> GCC build triplet: x86_64-linux-gnu
>  GCC host triplet: x86_64-linux-gnu
> GCC target triplet: x86_64-linux-gnu
>
>
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37804
>


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37804

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

[rguenth at gcc dot gnu dot org]

--- 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:

   What|Removed |Added

 CC||jason at redhat dot com
  BugsThisDependsOn||31336, 34827, 37775


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37804

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

[spop at gcc dot gnu dot org]

--- 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/bugzilla/show_bug.cgi?id=37485

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

[andrew at nelless dot net]

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 below code demonstrates the problem: with NS_SCOPE defined the code
compiles fine with "-Wall -Wextra -pedantic" on 4.3.2 but when NS_SCOPE is
undefined, the const qualifier is ignored with "error: ignoring ‘const’
qualifiers added to function type". To me this seems completely inconsistent
and there is no explaination as to why the qualifer is ignored.

---snip---
#include 

#ifdef NS_SCOPE
typedef void (function_type)(int) const;
#endif

template 
struct S1
{
#ifndef NS_SCOPE
typedef void (function_type)(int) const;
#endif  
};


struct S2: public S1
{
virtual function_type f = 0;
};


struct S3: public S2
{
void 
f (int i) const
{
std::cout << "Hello world: " << i << std::endl;
}
};


int
main()
{
S3 s;
s.f(5);
}
---snip---


I did find a C++ defect report that may be relevent, but to be honest, i'm not 
certain what is going on with regard to the standard here

http://open-std.org/JTC1/SC22/WG21/docs/cwg_defects.html#295

I hope this can be resolved because it will allow for some really groovy
template
generated interfaces.

Visual Studio 2005 (the only other compiler I have to hand) seems to compile
this
code without NS_SCOPE defined, but I'm uncertain how to thoroughly test this
there.


-- 
   Summary: CV-qualifiers on function typedef's are inconsistently
accepted depending on typedef scope
   Product: gcc
   Version: 4.3.2
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: andrew at nelless dot net
  GCC host triplet: x86_64


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37806

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

[rguenth at gcc dot gnu dot org]

--- 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 virtual functions are pure within ‘S3’:
t.C:16: note:   virtual void S2::f(int)

GCC 4.2 has this in addition to the CV error.  Of course the reason is the
same.

GCC never accepted the code, so this is not a regression.


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever Confirmed|0   |1
   Keywords||rejects-valid
   Last reconfirmed|-00-00 00:00:00 |2008-10-11 19:58:47
   date||


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37806

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

[ebotcazou at gcc dot gnu dot org]

--- 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

 CC||ebotcazou at gcc dot gnu dot
   ||org
 Status|UNCONFIRMED |WAITING
  GCC build triplet|sparcv9-sun-solaris2.11 |sparc64-sun-solaris2.11
   GCC host triplet|sparcv9-sun-solaris2.11 |sparc64-sun-solaris2.11
 GCC target triplet|sparcv9-sun-solaris2.11 |sparc64-sun-solaris2.11
Summary|SEGV compiling ada/ada.ads  |SIGBUS compiling ada/ada.ads
   |in stage2   |in stage2


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37799

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

[suckfish at ihug dot co dot nz]

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 Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.


-- 
   Summary: Exponential compile time with MMX builtins.
   Product: gcc
   Version: 4.3.2
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: suckfish at ihug dot co dot nz
 GCC build triplet: x86-64
  GCC host triplet: x86-64
GCC target triplet: x86-64


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37807

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

[suckfish at ihug dot co dot nz]

--- 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.

[suckfish at ihug dot co dot nz]

--- 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 cc1 to tell me what pass it's running when?]


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37807

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

[rguenth at gcc dot gnu dot org]

--- 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})));
}


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37807

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

[suckfish at ihug dot co dot nz]

--- 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.

[suckfish at ihug dot co dot nz]

--- 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.

[suckfish at ihug dot co dot nz]

--- 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) 0x8000ll;
return x;
}

to

foo:
pxor%xmm0, %xmm0
ret

The psrad is preserving the sign bit we are returning, so the compiler should
not assume it to be zero.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37807

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

[zadeck at gcc dot gnu dot org]

--- 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-optimization/37448
* df.h: (df_ref_class): New enum.
(DF_REF_TYPE_NAMES, df_ref_extract): Removed.
(struct df_ref): Replaced with union df_ref_d.
(df_base_ref, df_artificial_ref, df_regular_ref, df_extract_ref):
New members of df_ref_d union.
(DF_REF_REAL_REG, DF_REF_REGNO, DF_REF_REAL_LOC, DF_REF_REG,
DF_REF_LOC, DF_REF_BB, DF_REF_INSN_INFO, DF_REF_INSN,
DF_REF_CLASS, DF_REF_TYPE, DF_REF_CHAIN, DF_REF_ID, DF_REF_FLAGS,
DF_REF_ORDER, DF_REF_IS_ARTIFICIAL, DF_REF_NEXT_REG,
DF_REF_PREV_REG, DF_REF_EXTRACT_WIDTH, DF_REF_EXTRACT_OFFSET,
DF_REF_EXTRACT_MODE): Replaced definition to access union
df_ref_d.
(DF_MWS_REG_DEF_P, DF_MWS_REG_USE_P, DF_MWS_TYPE): New macros.
(df_scan_bb_info, df_bb_regno_first_def_find,
df_bb_regno_last_def_find, df_find_def, df_find_use,
df_refs_chain_dump, df_regs_chain_dump, df_ref_debug,
debug_df_ref, df_chain_create, df_chain_unlink, df_chain_copy,
df_ref_create, df_ref_remove, df_compute_accessed_bytes,
df_get_artificial_defs, df_get_artificial_uses, union_defs)
Replaced struct df_ref * with df_ref.
* df-scan.c (df_collection_rec, df_null_ref_rec,
df_ref_chain_delete_du_chain, df_ref_chain_delete, df_install_ref,
df_grow_ref_info, df_ref_create, df_reg_chain_unlink,
df_ref_compress_rec, df_ref_remove, df_ref_chain_delete_du_chain,
df_ref_chain_delete, df_free_collection_rec, df_insn_rescan,
df_reorganize_refs_by_reg_by_reg,
df_reorganize_refs_by_reg_by_insn, df_reorganize_refs_by_reg,
df_ref_change_reg_with_loc_1, df_notes_rescan, df_swap_refs,
df_sort_and_compress_refs, df_install_ref, df_install_refs,
df_ref_record, df_get_conditional_uses, df_get_call_refs,
df_bb_refs_record, df_exit_block_uses_collect,
df_record_exit_block_uses, df_reg_chain_mark,
df_reg_chain_verify_unmarked, df_refs_verify): Replaced struct
df_ref * with df_ref.
(df_ref_record, df_uses_record, df_ref_create_structure): Added
df_ref_class parameter.
(df_scan_problem_data): Added new pools for different types of
refs.
(df_scan_free_internal, df_scan_alloc, df_free_ref,
df_ref_create_structure): Processed new ref pools.
(df_scan_start_dump): Added counts of refs and insns.
(df_ref_create, df_notes_rescan, df_def_record_1, df_uses_record,
df_get_call_refs, df_insn_refs_collect, df_bb_refs_collect,
df_entry_block_defs_collect, df_exit_block_uses_collect): Added
code to pass df_ref_class down to ref creation functions.
(df_reg_chain_unlink, df_ref_remove, df_ref_change_reg_with_loc_1,
df_reg_chain_mark): Use macros to hide references to df_refs.
(df_ref_chain_change_bb): Removed.
(df_insn_change_bb): Remove calls to df_ref_insn_change_bb.
(df_ref_equal_p, df_ref_compare, df_ref_create_structure):
Enhanced to understand df_ref union structure.
* fwprop.c (local_ref_killed_between_p, use_killed_between,
all_uses_available_at, update_df, try_fwprop_subst,
forward_propagate_subreg, forward_propagate_and_simplify,
forward_propagate_into, fwprop, fwprop_addr): Replaced struct
df_ref * with df_ref.
(use_killed_between, all_uses_available_at): Use macros to hide
references to df_refs.
* regstat.c (regstat_bb_compute_ri,
regstat_bb_compute_calls_crossed): Replaced struct df_ref * with
df_ref.
* see.c (see_handle_relevant_defs, see_handle_relevant_uses,
see_handle_relevant_refs, see_analyze_one_def,
see_update_relevancy, see_propagate_extensions_to_uses): Replaced
struct df_ref * with df_ref.
* ra-conflict.c (record_one_conflict, clear_reg_in_live,
global_conflicts): Replaced struct df_ref * with df_ref.
* ddg.c (create_ddg_dep_from_intra_loop_link,
add_cross_iteration_register_deps, build_inter_loop_deps):
Replaced struct df_ref * with df_ref.
(create_ddg_dep_from_intra_loop_link,
add_cross_iteration_register_deps): Use macros to hide references
to df_refs.
* auto-inc-dec.c (find_inc, merge_in_block): Replaced struct
df_ref * with df_ref.
* df-core.c (df_bb_regno_first_def_find,
df_bb_regno_last_def_find, df_find_def, df_find_use,
df_refs_chain_dump, df_regs_chain_dump, df_ref_debug,
debug_df_ref): Replaced struct df_ref * with df_ref.
(df_mws_dump, df_ref_debug): Use macros to hide references to

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

[hjl dot tools at gmail dot com]

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-gnu/lib/ -isystem
/usr/local/x86_64-unknown-linux-gnu/include -isystem
/usr/local/x86_64-unknown-linux-gnu/sys-include -g -O2 -m32 -O2  -g -O2
-DIN_GCC   -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes
-Wcast-qual -Wold-style-definition  -isystem ./include  -fPIC -g
-DHAVE_GTHR_DEFAULT -DIN_LIBGCC2 -D__GCC_FLOAT_NOT_NEEDED   -I. -I.
-I../../.././gcc -I../../../../src-trunk/libgcc
-I../../../../src-trunk/libgcc/. -I../../../../src-trunk/libgcc/../gcc
-I../../../../src-trunk/libgcc/../include
-I../../../../src-trunk/libgcc/config/libbid -DENABLE_DECIMAL_BID_FORMAT
-DHAVE_CC_TLS -DUSE_TLS -o _muldc3.o -MT _muldc3.o -MD -MP -MF _mulsc3.dep
-DL_mulsc3 -c ../../../../src-trunk/libgcc/../gcc/libgcc2.c \
> -fvisibility=hidden -DHIDE_EXPORTS
../../../../src-trunk/libgcc/../gcc/libgcc2.c: In function â__mulsc3â:
../../../../src-trunk/libgcc/../gcc/libgcc2.c:1890: internal compiler error:
Segmentation fault
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.
[EMAIL PROTECTED] libgcc]$


-- 
   Summary: [4.4 Regression]: Revision 141067 breaks Linux/x86
   Product: gcc
   Version: 4.4.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: bootstrap
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: hjl dot tools at gmail dot com


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37808

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

[hjl dot tools at gmail dot com]

--- 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,
bb->index);
(gdb) bt
#0  0x0063d28e in df_set_bb_dirty (bb=0x0)
at ../../src-trunk/gcc/df-core.c:1427
#1  0x00659318 in df_ref_change_reg_with_loc_1 (old_df=0x255ebd8,
new_df=0x255ec08, new_regno=3, loc=0x7331cf80)
at ../../src-trunk/gcc/df-scan.c:1983
#2  0x00659451 in df_ref_change_reg_with_loc (old_regno=2,
new_regno=3, loc=0x7331cf80) at ../../src-trunk/gcc/df-scan.c:2027
#3  0x0118e246 in ix86_output_function_epilogue (file=0x249ca40,
size=36) at ../../src-trunk/gcc/config/i386/i386.c:8323
#4  0x007188d4 in final_end_function ()
at ../../src-trunk/gcc/final.c:1636
#5  0x0071c5e4 in rest_of_handle_final ()
at ../../src-trunk/gcc/final.c:4153
#6  0x008e55e6 in execute_one_pass (pass=0x234f0e0)
at ../../src-trunk/gcc/passes.c:1279
#7  0x008e5773 in execute_pass_list (pass=0x234f0e0)
at ../../src-trunk/gcc/passes.c:1327
#8  0x008e5791 in execute_pass_list (pass=0x23d0780)
at ../../src-trunk/gcc/passes.c:1328
#9  0x008e5791 in execute_pass_list (pass=0x23d0720)
at ../../src-trunk/gcc/passes.c:1328
#10 0x00c647dc in tree_rest_of_compilation (fndecl=0x7340f600)
at ../../src-trunk/gcc/tree-optimize.c:418
---Type  to continue, or q  to quit---
#11 0x011f06a2 in cgraph_expand_function (node=0x72fd9400)
at ../../src-trunk/gcc/cgraphunit.c:1038
#12 0x011f0856 in cgraph_expand_all_functions ()
at ../../src-trunk/gcc/cgraphunit.c:1097
#13 0x011f0de8 in cgraph_optimize ()
at ../../src-trunk/gcc/cgraphunit.c:1302
#14 0x0043524a in c_write_global_declarations ()
at ../../src-trunk/gcc/c-decl.c:8073
#15 0x00ae761f in compile_file () at ../../src-trunk/gcc/toplev.c:979
#16 0x00ae923d in do_compile () at ../../src-trunk/gcc/toplev.c:2190
#17 0x00ae92a1 in toplev_main (argc=15, argv=0x7fffe388)
at ../../src-trunk/gcc/toplev.c:
#18 0x00509e6b in main (argc=15, argv=0x7fffe388)
at ../../src-trunk/gcc/main.c:35
(gdb)


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37808

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

[pinskia at gcc dot gnu dot org]

--- 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

  Component|bootstrap   |target
 GCC target triplet||i?86-*-* x86_64-*-*
   Keywords||build, ice-on-valid-code
   Target Milestone|--- |4.4.0


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37808

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

[suckfish at ihug dot co dot nz]

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 &= (v2si) 0xll;
x = __builtin_ia32_psradi (x, 1);
x &= (v2si) 0x8000ll;
return x;
}


The compile incorrectly assumes that bit 31 of the shift result always ends up
as zero:

foo:
pxor%xmm0, %xmm0
ret


Presumeably, some optimiseration is incorrectly treating the v2si right shift
as a 64-bit right shift.

[It appears to me that both nonzero_bits1 and num_sign_bit_copies1 can
incorrectly optimise vector operation as if they were scalar ops, which is what
inspired this example, however, attempting to fix those did not fix this bug,
which makes me think the problem is elsewhere.]


-- 
   Summary: Incorrect code with MMX right shift
__builtin_ia32_psradi
   Product: gcc
   Version: 4.3.2
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: suckfish at ihug dot co dot nz
 GCC build triplet: x86_64-unknown-linux-gnu
  GCC host triplet: x86_64-unknown-linux-gnu
GCC target triplet: x86_64-unknown-linux-gnu


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37809

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

[suckfish at ihug dot co dot nz]

--- 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

[suckfish at ihug dot co dot nz]

--- 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

[witalic7]

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

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

[suckfish at ihug dot co dot nz]

--- 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 inlining is less aggressive
there.

Making some functions inline causes compile time to blow up with trunk also.

Updated test case attached also.

PS.  The correct fix for the rotate on trunk was to use
__builtin_ia32_psrldi/pslldi.


-- 

suckfish at ihug dot co dot nz changed:

   What|Removed |Added

  Attachment #16482|0   |1
is obsolete||


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37807

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

[zadeck at naturalbridge dot com]

--- 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


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37808

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

[suckfish at ihug dot co dot nz]

--- 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 types.

This fixes the problem & looking at those functions, they were not written with
vector types in mind.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37807

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

[suckfish at ihug dot co dot nz]

--- 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
exponential time recursion.
(num_sign_bit_copies1): Likewise.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37807