[Bug c/44554] New: Stack space after sigsetjmp is reused

[christian dot eggers at kathrein dot de]

This bug has originally been reported on Glibc bugtracker:
http://sourceware.org/bugzilla/show_bug.cgi?id=11670
Please look here first for a detailed description.

The __sigsetjmp function returns twice so it's not allowed to reuse stack space
of existing automatic variables after this function has been called.

C-Code:
-
void *x = malloc(something);
do {
  __pthread_unwind_buf_t __cancel_buf;
  void *y = x;

  int not_first_call = __sigsetjmp((struct __jmp_buf_tag *) (void *)
 __cancel_buf.__cancel_jmp_buf, 0);
  if (not_first_call) {
free(y);
__pthread_unwind_next (&__cancel_buf);
/* NOTREACHED */
  }

  do {
...
  } while (0);
  free(y);
} while(0);

In the resulting assembler code the second "free(y)" is "replaced" by "free(x)"
and the stack space for y is used for something else. This causes problems when
__sigsetjmp() returns the second time because the stack memory for "y" may
already contain the value of another variable at this time.

ASM output:
-
 120:   ebfebl  0 
 124:   e50b0280str r0, [fp, #-640] ; 0x280   <-- x is @ fp,0x280
 128:   e51bc280ldr ip, [fp, #-640] ; 0x280
 12c:   e3a01000mov r1, #0
 130:   e24b0f53sub r0, fp, #332; 0x14c
 134:   e50bc2b8str ip, [fp, #-696] ; 0x2b8   <-- y is @ fp,0x2b8
 138:   ebfebl  0 <__sigsetjmp>
...
 1f4:   e50b52b8str r5, [fp, #-696] ; 0x2b8   <-- y is overwritten
...
 408:   e51b0280ldr r0, [fp, #-640] ; 0x280   <-- y has been
 40c:   eb15bl  68replaced by x
-


-- 
   Summary: Stack space after sigsetjmp is reused
   Product: gcc
   Version: 4.4.4
Status: UNCONFIRMED
  Severity: major
  Priority: P3
 Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: christian dot eggers at kathrein dot de
 GCC build triplet: x86_64-unknown-linux-gnu
  GCC host triplet: x86_64-unknown-linux-gnu
GCC target triplet: arm-linux-gnueabi


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

[Bug c/44554] Stack space after sigsetjmp is reused

[christian dot eggers at kathrein dot de]

--- Comment #1 from christian dot eggers at kathrein dot de  2010-06-16 
07:17 ---
Created an attachment (id=20925)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20925&action=view)
Preprocessed source

compile with arm-linux-gnueabi-gcc -mcpu=arm920t -Os -o test.o -c test.i

This file is a stripped down version of the original source. Here __sigsetjmp
is used twice because pthread_cleanup_push()/pthread_cleanup_pop() are used
nested:

a = malloc();
pthread_cleanup_push(handler, a);
x = malloc() 
pthread_cleanup_push(handler, x)
...
pthread_cleanup_pop(1);
pthread_cleanup_pop(1);

The code is arranged in a way the the problem happens for both instances of
__cancel_arg are affected.

The bug is little bit "volatile", if you change the source it will usually
disappear or move to another position. For instance you may try removing the
marked line:

  comp_1 = 0.0;
  comp_2 = 0.0;
  for (i = 0; i < num_1 - delay1; ++i)
  {
-->   comp_1 += conj(comp_out[i]) * comp_out[i];
  comp_2 += conj(comp_out[i]) * comp_in[i];
  }

siglongjmp() is only used for demonstration purposes. You can also link with
"-pthreads -lm" to a full executable demo.


-- 


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

[Bug c/44554] Stack space after sigsetjmp is reused

[christian dot eggers at kathrein dot de]

--- Comment #2 from christian dot eggers at kathrein dot de  2010-06-16 
07:18 ---
Created an attachment (id=20926)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20926&action=view)
Object file (for reference)


-- 


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

[Bug bootstrap/44456] [4.6 Regression] bootstrap fails on mips-linux CHOOSE_DYNAMIC_LINKER macro

[mkuvyrkov at gcc dot gnu dot org]

--- Comment #1 from mkuvyrkov at gcc dot gnu dot org  2010-06-16 08:31 
---
Fixed in revision 160824.


-- 

mkuvyrkov at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||FIXED


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

[Bug libstdc++/44480] [C++0x] Linear performance of begin() in unordered associative containers

[paolo dot carlini at oracle dot com]

--- Comment #3 from paolo dot carlini at oracle dot com  2010-06-16 08:48 
---
Joaquin, I'm trying to investigate this in some detail, and I think it would be
good if the LWG knew also about this performance issue with begin(), besides
579, I cannot find anywhere a discussion about constant begin() vs linear
begin() and I'm afraid other implementors may not have noticed it. Can you send
a message to the reflector?


-- 


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

[Bug c/44554] Stack space after sigsetjmp is reused

[rguenth at gcc dot gnu dot org]

--- Comment #3 from rguenth at gcc dot gnu dot org  2010-06-16 08:58 ---
you need to mark y and x volatile.


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||INVALID


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

[Bug target/44551] [missed optimization] AVX vextractf128 after vinsertf128

[rguenth at gcc dot gnu dot org]

--- Comment #1 from rguenth at gcc dot gnu dot org  2010-06-16 09:02 ---
This is probably missing combiner patterns in sse.md.


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||rguenth at gcc dot gnu dot
   ||org, hjl at gcc dot gnu dot
   ||org
   Severity|normal  |enhancement
 Status|UNCONFIRMED |NEW
  Component|middle-end  |target
 Ever Confirmed|0   |1
   Last reconfirmed|-00-00 00:00:00 |2010-06-16 09:02:24
   date||


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

[Bug c/44554] Stack space after sigsetjmp is reused

[schwab at linux-m68k dot org]

--- Comment #4 from schwab at linux-m68k dot org  2010-06-16 09:06 ---
If the variable is not modified between setjmp and longjmp the compiler is
required to preserve its value.


-- 

schwab at linux-m68k dot org changed:

   What|Removed |Added

 Status|RESOLVED|UNCONFIRMED
 Resolution|INVALID |


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

[Bug tree-optimization/44545] [4.5/4.6 Regression] internal compiler error: in remove_unreachable_handlers, at tree-eh

[rguenth at gcc dot gnu dot org]

--- Comment #2 from rguenth at gcc dot gnu dot org  2010-06-16 09:07 ---
CallTip.cxx: In member function 'void CallTip::DrawChunk(Surface*, int&, const
char*, int, int, int, PRectangle, bool, bool)':
CallTip.cxx:87:6: error: control flow in the middle of basic block 64
CallTip.cxx:87:6: internal compiler error: verify_flow_info failed
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.

Reducing.


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever Confirmed|0   |1
  Known to work||4.4.4
   Last reconfirmed|-00-00 00:00:00 |2010-06-16 09:07:16
   date||
Summary|internal compiler error: in |[4.5/4.6 Regression]
   |remove_unreachable_handlers,|internal compiler error: in
   |at tree-eh  |remove_unreachable_handlers,
   ||at tree-eh
   Target Milestone|--- |4.5.1


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

[Bug bootstrap/44509] [4.6 Regression] Revision 160626 breaks bootstrap on *-apple-darwin*

[dominiq at lps dot ens dot fr]

--- Comment #22 from dominiq at lps dot ens dot fr  2010-06-16 09:13 ---
(In reply to comment #20)
> Could the patch in comment #17 explain the following failures? ...

False alarm! AFAICT the failures where due to messed up libs for mpfr and mpc
while trying to update to mpfr 3.0. Sorry for the noise.


-- 


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

[Bug c/44555] New: Pointer evalutions, is that expected ?

[zilvinas dot valinskas at gmail dot com]

$ cat ptr.c
#include 

struct a {
charb[100];
int a;
};

int main(int argc, char *argv[])
{
struct a *a = NULL;
void *ptr;

if (&a->b)
puts("ok, not null #1");

if (&a->b == NULL)
puts("ok, null ? #1");

ptr = &a->b;
if (ptr)
puts("ok, not null #2");

if (ptr == NULL)
puts("ok, null ? #2");

return 0;
}

$ gcc ptr.c -o ptr
$ ./ptr
ok, not null #1
ok, null ? #1
ok, null ? #2

The same results with gcc 4.4.3, gcc 4.5.0 (ubuntu gcc-snapshot package).
Did not try gcc 3.x series.

$ clang ptr.c -o clang-ptr
$ ./clang-ptr 
ok, null ? #1
ok, null ? #2



Tried with gcc 4.4.3:
$ gcc -v
Using built-in specs.
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Ubuntu 4.4.3-4ubuntu5'
--with-bugurl=file:///usr/share/doc/gcc-4.4/README.Bugs
--enable-languages=c,c++,fortran,objc,obj-c++ --prefix=/usr --enable-shared
--enable-multiarch --enable-linker-build-id --with-system-zlib
--libexecdir=/usr/lib --without-included-gettext --enable-threads=posix
--with-gxx-include-dir=/usr/include/c++/4.4 --program-suffix=-4.4 --enable-nls
--enable-clocale=gnu --enable-libstdcxx-debug --enable-plugin --enable-objc-gc
--disable-werror --with-arch-32=i486 --with-tune=generic
--enable-checking=release --build=x86_64-linux-gnu --host=x86_64-linux-gnu
--target=x86_64-linux-gnu
Thread model: posix
gcc version 4.4.3 (Ubuntu 4.4.3-4ubuntu5)

$ gcc-snapshot -v
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/lib/gcc-snapshot/libexec/gcc/x86_64-linux-gnu/4.5.0/lto-wrapper
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Ubuntu
20100414-0ubuntu1' --with-bugurl=file:///usr/share/doc/gcc-snapshot/README.Bugs
--enable-languages=c,ada,c++,java,fortran,objc,obj-c++
--prefix=/usr/lib/gcc-snapshot --enable-shared --enable-multiarch
--enable-linker-build-id --with-system-zlib --disable-nls --enable-clocale=gnu
--enable-libstdcxx-debug --enable-libstdcxx-time=yes --enable-plugin
--enable-gold --with-plugin-ld=ld.gold --disable-browser-plugin
--enable-java-awt=gtk --enable-gtk-cairo
--with-java-home=/usr/lib/jvm/java-1.5.0-gcj-4.5-snap/jre --enable-java-home
--with-jvm-root-dir=/usr/lib/jvm/java-1.5.0-gcj-4.5-snap
--with-jvm-jar-dir=/usr/lib/jvm-exports/java-1.5.0-gcj-4.5-snap
--with-arch-directory=amd64 --with-ecj-jar=/usr/share/java/eclipse-ecj.jar
--enable-objc-gc --disable-werror --with-arch-32=i686 --with-tune=generic
--enable-checking=yes --build=x86_64-linux-gnu --host=x86_64-linux-gnu
--target=x86_64-linux-gnu
Thread model: posix
gcc version 4.5.0 (Ubuntu 20100414-0ubuntu1) 

$ clang -v
clang version 1.1 (branches/release_27)
Target: x86_64-pc-linux-gnu
Thread model: posix


-- 
   Summary: Pointer evalutions, is that expected ?
   Product: gcc
   Version: 4.4.3
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: zilvinas dot valinskas at gmail dot com


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

[Bug lto/44533] [4.6 Regression] Revision 160679 miscompiles capacita.f90 with -O3 -finline-limit=600 -flto

[dominiq at lps dot ens dot fr]

--- Comment #1 from dominiq at lps dot ens dot fr  2010-06-16 09:21 ---
The miscompilation occurs between -finline-limit=300 (works) and =400
(Segmentation fault). This seems related to the inlining of the subroutine
'fourir2d' (called 4 times with =400) instead of  'fourir' (called 14 times
with =300).


-- 


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

[Bug tree-optimization/44545] [4.5/4.6 Regression] internal compiler error: in remove_unreachable_handlers, at tree-eh

[rguenth at gcc dot gnu dot org]

--- Comment #3 from rguenth at gcc dot gnu dot org  2010-06-16 09:30 ---
class CallTip {
int tabSize;
int DrawChunk(int &x);
int NextTabPos(int x);
};
int CallTip::NextTabPos(int x) 
{
if (tabSize > 0) {
x -= 5;
x = (x + tabSize) / tabSize;
}
}
int CallTip::DrawChunk(int &x) 
{
const int numEnds = 10;
int ends[numEnds + 2];
return NextTabPos(x);
}


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||ebotcazou at gcc dot gnu dot
   ||org


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

[Bug c/44555] Pointer evalutions, is that expected ?

[schwab at linux-m68k dot org]

--- Comment #1 from schwab at linux-m68k dot org  2010-06-16 09:35 ---
The first operand of -> must be a valid pointer to an object.


-- 

schwab at linux-m68k dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||INVALID


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

[Bug c/44554] Stack space after sigsetjmp is reused

[jakub at gcc dot gnu dot org]

--- Comment #5 from jakub at gcc dot gnu dot org  2010-06-16 09:45 ---
The __cancel_arg variables are pseudos until ira, apparently during IRA the 2
stack slots chosen for those are shared between __cancel_arg vars and other
vars used later in the function.  Do we need to act as if
-fno-ira-share-spill-slots
is set in cfun->calls_setjmp functions?


-- 


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

[Bug fortran/44556] New: incorrect error: Stat-variable at (1) shall not be DEALLOCATEd within the same DEALLOCATE statement

[jonathan dot hogg at stfc dot ac dot uk]

Attempting to compile the following code:

module dealloc_test
   implicit none

   type test_type
  integer, dimension(:), allocatable :: array
  integer :: st
   end type test_type
contains

   subroutine test
  type(test_type) :: foo

  deallocate(foo%array, stat=foo%st)

   end subroutine test
end module dealloc_test

generates the following result:
[jh...@jhogg] ~/src/ma77_ic$ gfortran-4.5 -c temp.f90 
temp.f90:13.33:

  deallocate(foo%array, stat=foo%st)
 1
Error: Stat-variable at (1) shall not be DEALLOCATEd within the same DEALLOCATE
statement

This seems to be legal code to me, and is used throughout our Fortran library.

Version information (debian expt package):
[jh...@jhogg] ~/src/ma77_ic$ gfortran-4.5 -v
Using built-in specs.
COLLECT_GCC=gfortran-4.5
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/4.5.1/lto-wrapper
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Debian 4.5.0-5'
--with-bugurl=file:///usr/share/doc/gcc-4.5/README.Bugs
--enable-languages=c,c++,java,fortran,objc,obj-c++ --prefix=/usr
--enable-shared --enable-multiarch --enable-linker-build-id --with-system-zlib
--libexecdir=/usr/lib --without-included-gettext --enable-threads=posix
--with-gxx-include-dir=/usr/include/c++/4.5 --program-suffix=-4.5 --enable-nls
--enable-clocale=gnu --enable-libstdcxx-debug --enable-libstdcxx-time=yes
--enable-plugin --enable-gold --with-plugin-ld=ld.gold --disable-browser-plugin
--enable-java-awt=gtk --enable-gtk-cairo
--with-java-home=/usr/lib/jvm/java-1.5.0-gcj-4.5/jre --enable-java-home
--with-jvm-root-dir=/usr/lib/jvm/java-1.5.0-gcj-4.5
--with-jvm-jar-dir=/usr/lib/jvm-exports/java-1.5.0-gcj-4.5
--with-arch-directory=amd64 --with-ecj-jar=/usr/share/java/eclipse-ecj.jar
--enable-objc-gc --with-arch-32=i486 --with-tune=generic --enable-checking=yes
--build=x86_64-linux-gnu --host=x86_64-linux-gnu --target=x86_64-linux-gnu
Thread model: posix
gcc version 4.5.1 20100602 (prerelease) (Debian 4.5.0-5)

Thanks,
Jonathan


-- 
   Summary: incorrect error:  Stat-variable at (1) shall not be
DEALLOCATEd within the same DEALLOCATE statement
   Product: gcc
   Version: 4.5.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: jonathan dot hogg at stfc dot ac dot uk
  GCC host triplet: x86_64-linux-gnu
GCC target triplet: x86_64-linux-gnu


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

[Bug c/44555] Pointer evalutions, is that expected ?

[zilvinas dot valinskas at gmail dot com]

--- Comment #2 from zilvinas dot valinskas at gmail dot com  2010-06-16 
10:29 ---
I don't agree. This is an optimizer bug ("dead code elimination" don't know
much of GCC). Consider that there is a function like this:


$ cat ptr.h
struct a {
charb[100];
int a;
};

$ cat ptr.c

$ cat ptr.c 
#include 
#include "ptr.h"

int main(int argc, char *argv[])
{
struct a *a = NULL;

function(a);
return 0;
}


$ cat func.c 
#include 
#include "ptr.h"

void function(struct a *a)
{
void *ptr;

if (&a->b)
puts("ok, not null #1");

if (&a->b == NULL)
puts("ok, null ? #1");

ptr = &a->b;
if (ptr)
puts("ok, not null #2");

if (ptr == NULL)
puts("ok, null ? #2");
}

$ gcc ptr.c func.c -o ptr
$ ./ptr

$ ./ptr 
ok, not null #1
ok, null ? #1
ok, null ? #2


Still the same problem (maybe not a problem). But how does GCC is able to tell
that in this particular case func() is invoked with a NULL pointer as parameter
(not valid pointer) and eliminates code just like that ???

Mind you this code is an approximation of bug I was tracking not so long time
ago.


-- 

zilvinas dot valinskas at gmail dot com changed:

   What|Removed |Added

 Status|RESOLVED|UNCONFIRMED
 Resolution|INVALID |


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

[Bug fortran/43945] [OOP] Derived type with GENERIC: resolved to the wrong specific TBP

[sfilippone at uniroma2 dot it]

--- Comment #18 from sfilippone at uniroma2 dot it  2010-06-16 10:32 ---
(In reply to comment #17)
Dear All, 
The attached source file contains the same kind of test as the original
testd15, and yet it fails. So, there's something missing from the patch, even
without considering the allocatable issue; perhaps in producing the original
test case I reduced a bit too much, and a more complicated example still fails.
By the same token, I dared not reduce the new test case below its current size. 
compiling and running gives the following: 

[sfili...@localhost bug15]$ gfortran -v
Using built-in specs.
COLLECT_GCC=gfortran
COLLECT_LTO_WRAPPER=/home/local/gnu46/bin/../libexec/gcc/i686-pc-linux-gnu/4.6.0/lto-wrapper
Target: i686-pc-linux-gnu
Configured with: ../gcc/configure --prefix=/usr/local/gnu46
--enable-languages=c,c++,fortran : (reconfigured) ../gcc/configure
--prefix=/usr/local/gnu46 --enable-languages=c,c++,fortran : (reconfigured)
../gcc/configure --prefix=/usr/local/gnu46 --enable-languages=c,c++,fortran :
(reconfigured) ../gcc/configure --prefix=/usr/local/gnu46
--enable-languages=c,c++,fortran
Thread model: posix
gcc version 4.6.0 20100612 (experimental) (GCC) 
[sfili...@localhost bug15]$ gfortran -o test_coo test_coo.f03 
[sfili...@localhost bug15]$ ./test_coo 
 Error: Missing ovverriding impl for allocate in class COO  


-- 


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

[Bug fortran/43945] [OOP] Derived type with GENERIC: resolved to the wrong specific TBP

[sfilippone at uniroma2 dot it]

--- Comment #19 from sfilippone at uniroma2 dot it  2010-06-16 10:32 ---
Created an attachment (id=20927)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20927&action=view)
test-case


-- 


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

[Bug c/44555] Pointer evalutions, is that expected ?

[redi at gcc dot gnu dot org]

--- Comment #3 from redi at gcc dot gnu dot org  2010-06-16 10:43 ---
can you say "undefined behaviour" ?


-- 


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

[Bug c/44555] Pointer evalutions, is that expected ?

[schwab at linux-m68k dot org]

--- Comment #4 from schwab at linux-m68k dot org  2010-06-16 10:53 ---
Undefined behaviour.


-- 

schwab at linux-m68k dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||INVALID


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

[Bug testsuite/44538] [4.5/4.6 regression] PR43949 fix caused gcc.dg/vect/slp-perm-{5,6}.c to fail

[rguenth at gcc dot gnu dot org]

--- Comment #2 from rguenth at gcc dot gnu dot org  2010-06-16 11:04 ---
Subject: Bug 44538

Author: rguenth
Date: Wed Jun 16 11:04:08 2010
New Revision: 160827

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=160827
Log:
2010-06-16  Mikael Pettersson  

PR testsuite/44538
* gcc.dg/vect/slp-perm-5.c (main): Prevent
initialization loop from being vectorized.
* gcc.dg/vect/slp-perm-6.c (main): Likewise.

Modified:
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gcc.dg/vect/slp-perm-5.c
trunk/gcc/testsuite/gcc.dg/vect/slp-perm-6.c


-- 


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

[Bug libstdc++/32618] std::vector calls uneccessary constructors instead of inplace construction of first object

[paolo dot carlini at oracle dot com]

--- Comment #10 from paolo dot carlini at oracle dot com  2010-06-16 11:04 
---
On it.


-- 

paolo dot carlini at oracle dot com changed:

   What|Removed |Added

 AssignedTo|unassigned at gcc dot gnu   |paolo dot carlini at oracle
   |dot org |dot com
 Status|NEW |ASSIGNED


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

[Bug testsuite/44538] [4.5/4.6 regression] PR43949 fix caused gcc.dg/vect/slp-perm-{5,6}.c to fail

[rguenth at gcc dot gnu dot org]

--- Comment #3 from rguenth at gcc dot gnu dot org  2010-06-16 11:05 ---
Subject: Bug 44538

Author: rguenth
Date: Wed Jun 16 11:05:40 2010
New Revision: 160828

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=160828
Log:
2010-06-16  Mikael Pettersson  

PR testsuite/44538
* gcc.dg/vect/slp-perm-5.c (main): Prevent
initialization loop from being vectorized.
* gcc.dg/vect/slp-perm-6.c (main): Likewise.

Modified:
branches/gcc-4_5-branch/gcc/testsuite/ChangeLog
branches/gcc-4_5-branch/gcc/testsuite/gcc.dg/vect/slp-perm-5.c
branches/gcc-4_5-branch/gcc/testsuite/gcc.dg/vect/slp-perm-6.c


-- 


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

[Bug c/44555] Pointer evalutions, is that expected ?

[rguenth at gcc dot gnu dot org]

--- Comment #5 from rguenth at gcc dot gnu dot org  2010-06-16 11:23 ---
I'd argue it's a QOI issue that the C frontend via
c_objc_common_truthvalue_conversion should not convert

  if (&a->b)

to

  if (0)

if the offset of b is zero.


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|RESOLVED|UNCONFIRMED
 Resolution|INVALID |


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

[Bug testsuite/44538] [4.5/4.6 regression] PR43949 fix caused gcc.dg/vect/slp-perm-{5,6}.c to fail

[rguenth at gcc dot gnu dot org]

--- Comment #4 from rguenth at gcc dot gnu dot org  2010-06-16 11:23 ---
Fixed.


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED


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

[Bug c/44555] Pointer evalutions, is that expected ?

[rguenth at gcc dot gnu dot org]

--- Comment #6 from rguenth at gcc dot gnu dot org  2010-06-16 11:31 ---
Mine.


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

 AssignedTo|unassigned at gcc dot gnu   |rguenth at gcc dot gnu dot
   |dot org |org
 Status|UNCONFIRMED |ASSIGNED
 Ever Confirmed|0   |1
   Last reconfirmed|-00-00 00:00:00 |2010-06-16 11:31:09
   date||


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

[Bug c/44555] Pointer evalutions, is that expected ?

[rguenth at gcc dot gnu dot org]

--- Comment #7 from rguenth at gcc dot gnu dot org  2010-06-16 11:35 ---
Obvious patch, removing the premature (and bogus) optimization:

Index: c-common.c
===
--- c-common.c  (revision 160826)
+++ c-common.c  (working copy)
@@ -3825,23 +3825,7 @@ c_common_truthvalue_conversion (location
inner);
return truthvalue_true_node;
  }
-
-   /* If we still have a decl, it is possible for its address to
-  be NULL, so we cannot optimize.  */
-   if (DECL_P (inner))
- {
-   gcc_assert (DECL_WEAK (inner));
-   break;
- }
-
-   if (TREE_SIDE_EFFECTS (inner))
- {
-   expr = build2 (COMPOUND_EXPR, truthvalue_type_node,
-  inner, truthvalue_true_node);
-   goto ret;
- }
-   else
- return truthvalue_true_node;
+   break;
   }

 case COMPLEX_EXPR:


-- 


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

[Bug target/43703] Unexpected floating point precision loss due to ARM NEON autovectorization

[jules at gcc dot gnu dot org]

--- Comment #5 from jules at gcc dot gnu dot org  2010-06-16 11:41 ---
I am working on this.


-- 

jules at gcc dot gnu dot org changed:

   What|Removed |Added

 AssignedTo|unassigned at gcc dot gnu   |jules at gcc dot gnu dot org
   |dot org |
 Status|NEW |ASSIGNED
   Last reconfirmed|2010-04-12 09:17:11 |2010-06-16 11:41:32
   date||


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

[Bug tree-optimization/44547] -Wuninitialized reports false warning in nested switch statements

[manu at gcc dot gnu dot org]

--- Comment #1 from manu at gcc dot gnu dot org  2010-06-16 11:54 ---
Value range-propagation (VRP) does not work on disjoint ranges, so the compiler
does not actually know that argc can only be 1, 2 or 4. I think there is
already a PR about this but I cannot find it right now.


-- 

manu at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||manu at gcc dot gnu dot org
OtherBugsDependingO||24639
  nThis||


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

[Bug c++/44548] Link error when defining templated static const variable

[manu at gcc dot gnu dot org]

--- Comment #4 from manu at gcc dot gnu dot org  2010-06-16 11:58 ---
(In reply to comment #3)
> > but it is an explicit specialization of the *definition* of the variable
> 
> No it is a specialization of the declaration.  There are only specialization 
> of
> declarations; never definitions.  Re-read the link you gave and you will see
> the following: "Explicit specialization declaration syntax" .

So what the above code actually means? Is it valid?


-- 

manu at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||manu at gcc dot gnu dot org


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

[Bug c++/44548] Link error when defining templated static const variable

[redi at gcc dot gnu dot org]

--- Comment #5 from redi at gcc dot gnu dot org  2010-06-16 12:11 ---
(In reply to comment #4) 
> So what the above code actually means? Is it valid?

Yes, it's valid. It declares an explicit specialization, which inhibits the
implicit instantiation of the default specialization.

In order for the code to be valid a definition must be provided. It isn't, so
you get a link error.


-- 


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

[Bug fortran/44556] [4.5/4.6 Regression] incorrect error: Stat-variable at (1) shall not be DEALLOCATEd within the same DEALLOCATE statement

[burnus at gcc dot gnu dot org]

--- Comment #1 from burnus at gcc dot gnu dot org  2010-06-16 12:21 ---
The following check is to simplistic, it does not work for structures but only
for simple object names. - with structures, it gets more complicated as also
comparing the name of the last part-ref won't work - but one needs to walk
through the whole structure references. 


Alternatively, one disables the check "if (stat->symtree->n.sym->ts.type !=
BT_INTEGER)" - that's maybe too simple, but it would fix this problem. (Maybe
that's _the_ solution for the 4.5 branch?)

[When using stat=foo%array(1), NAG, pgf95, and g95 do not print a
warning/error, but ifort, openf95, pathf95, sunf95, and Cray print an error.]


In resolve.c's resolve_allocate_deallocate:

  for (p = code->ext.alloc.list; p; p = p->next)
if (p->expr->symtree->n.sym->name == stat->symtree->n.sym->name)
  gfc_error ("Stat-variable at %L shall not be %sd within "
 "the same %s statement", &stat->where, fcn, fcn);


-- 

burnus at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||kargl at gcc dot gnu dot org
 Status|UNCONFIRMED |NEW
 Ever Confirmed|0   |1
   GCC host triplet|x86_64-linux-gnu|
 GCC target triplet|x86_64-linux-gnu|
   Keywords||rejects-valid
  Known to fail||4.5.1 4.6.0
  Known to work||4.4.0
   Last reconfirmed|-00-00 00:00:00 |2010-06-16 12:21:06
   date||
Summary|incorrect error:  Stat- |[4.5/4.6 Regression]
   |variable at (1) shall not be|incorrect error:  Stat-
   |DEALLOCATEd within the same |variable at (1) shall not be
   |DEALLOCATE statement|DEALLOCATEd within the same
   ||DEALLOCATE statement
   Target Milestone|--- |4.5.1


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

[Bug tree-optimization/43905] [4.5/4.6 Regression] duplicate __PRETTY_FUNCTION__ symbol for functions differing in const-ness

[jamborm at gcc dot gnu dot org]

--- Comment #7 from jamborm at gcc dot gnu dot org  2010-06-16 12:22 ---
Subject: Bug 43905

Author: jamborm
Date: Wed Jun 16 12:21:56 2010
New Revision: 160832

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=160832
Log:
2010-06-16  Martin Jambor  

PR tree-optimization/43905
* tree-sra.c: Include tree-inline.h.
(create_abstract_origin): Removed.
(modify_function): Version the call graph node instead of creating
abstract origins and dealing with same_body aliases.
* tree-sra.c (ipa_sra_preliminary_function_checks): Check whether the
function is versionable.
* Makefile.in (tree-sra.o): Add TREE_INLINE_H to dependencies.

* testsuite/g++.dg/torture/pr43905.C: New test.


Added:
trunk/gcc/testsuite/g++.dg/torture/pr43905.C
Modified:
trunk/gcc/ChangeLog
trunk/gcc/Makefile.in
trunk/gcc/testsuite/ChangeLog
trunk/gcc/tree-sra.c


-- 


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

[Bug c++/44548] Link error when defining templated static const variable

[redi at gcc dot gnu dot org]

--- Comment #6 from redi at gcc dot gnu dot org  2010-06-16 12:31 ---
(In reply to comment #3)
> > but it is an explicit specialization of the *definition* of the variable
> 
> No it is a specialization of the declaration.

It is a declaration of a specialization :)

> There are only specialization of declarations; never definitions.

Not true.

This is a definition of an explicit specialization:

template<>
const int MyTraits::kValue = 1;

Such a definition must only occur in a single translation unit, otherwise you
get duplicate symbols.  To use it from multiple translation units you must
declare it in all and define it in one.

Here is a complete example:

template class MyTraits {
 public:
  static const T kValue;
};

// define the default specialization
template
const T MyTraits::kValue = 0;

// declare an explicit specialization
template<>
const int MyTraits::kValue;

int main(){
  const void * a = &(MyTraits::kValue);
}

// define the explicit specialization
template<>
const int MyTraits::kValue = 1;


-- 


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

[Bug fortran/44549] [OOP][F2008] Type-bound procedure: bogus error from list after PROCEDURE

[janus at gcc dot gnu dot org]

--- Comment #2 from janus at gcc dot gnu dot org  2010-06-16 12:55 ---
Subject: Bug 44549

Author: janus
Date: Wed Jun 16 12:54:54 2010
New Revision: 160834

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=160834
Log:
2010-06-16  Janus Weil  

PR fortran/44549
* gfortran.h (gfc_get_typebound_proc): Modified Prototype.
* decl.c (match_procedure_in_type): Give a unique gfc_typebound_proc
structure to each procedure in a procedure list.
* module.c (mio_typebound_proc): Add NULL argument to
'gfc_get_typebound_proc'.
* symbol.c (gfc_get_typebound_proc): Add a new argument, which is used
to initialize the new structure.


2010-06-16  Janus Weil  

PR fortran/44549
* gfortran.dg/typebound_proc_16.f03: New.

Added:
trunk/gcc/testsuite/gfortran.dg/typebound_proc_16.f03
Modified:
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/decl.c
trunk/gcc/fortran/gfortran.h
trunk/gcc/fortran/module.c
trunk/gcc/fortran/symbol.c
trunk/gcc/testsuite/ChangeLog


-- 


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

[Bug fortran/44549] [OOP][F2008] Type-bound procedure: bogus error from list after PROCEDURE

[janus at gcc dot gnu dot org]

--- Comment #3 from janus at gcc dot gnu dot org  2010-06-16 12:56 ---
Fixed with r160834. Closing.


-- 

janus at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED


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

[Bug target/43902] suboptimal MIPS widening multiply accumulate

[bernds at gcc dot gnu dot org]

--- Comment #11 from bernds at gcc dot gnu dot org  2010-06-16 13:29 ---
Yes, the check for MULT is for cases where the definition is after the use in
basic-block order; I'd expect this can happen with crazy gotos and maybe in
other cases as well.

Could you retest the MIPS fixed-point testcases with the obvious fix?  You
probably have the MIPS toolchain set up already and it would probably take me
more time.

After that, I'm happy to approve your parts of the patch if you'll approve mine
:-) so I can then check it in if you like.  We could post it for review by the
gimple crowd first though.


-- 


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

[Bug target/44557] New: internal compiler error: in gen_thumb_movhi_clobber, at config/arm/arm.md:5811

[raj dot khem at gmail dot com]

X-Bugzilla-Reason: CC

gcc built from recent gcc-4_5-branch ICE's compiling attached testcase for arm
with following options

-mthumb -O1 -fno-omit-frame-pointer

$ arm-oe-linux-uclibceabi-gcc -v
Using built-in specs.
COLLECT_GCC=arm-oe-linux-uclibceabi-gcc
COLLECT_LTO_WRAPPER=/home/kraj/work/oe/tmp/cross/armv5te/libexec/gcc/arm-oe-linux-uclibceabi/4.5.1/lto-wrapper
Target: arm-oe-linux-uclibceabi
Configured with:
/home/kraj/work/oe/tmp/work/armv5te-oe-linux-uclibceabi/gcc-cross-4.5-r1+svnr160764/gcc-4.5/configure
--build=x86_64-linux --host=x86_64-linux --target=arm-oe-linux-uclibceabi
--prefix=/home/kraj/work/oe/tmp/cross/armv5te
--exec_prefix=/home/kraj/work/oe/tmp/cross/armv5te
--bindir=/home/kraj/work/oe/tmp/cross/armv5te/bin
--sbindir=/home/kraj/work/oe/tmp/cross/armv5te/bin
--libexecdir=/home/kraj/work/oe/tmp/cross/armv5te/libexec
--datadir=/home/kraj/work/oe/tmp/cross/armv5te/share
--sysconfdir=/home/kraj/work/oe/tmp/cross/armv5te/etc
--sharedstatedir=/home/kraj/work/oe/tmp/cross/armv5te/com
--localstatedir=/home/kraj/work/oe/tmp/cross/armv5te/var
--libdir=/home/kraj/work/oe/tmp/cross/armv5te/lib
--includedir=/home/kraj/work/oe/tmp/cross/armv5te/include
--oldincludedir=/home/kraj/work/oe/tmp/cross/armv5te/include
--infodir=/home/kraj/work/oe/tmp/cross/armv5te/share/info
--mandir=/home/kraj/work/oe/tmp/cross/armv5te/share/man
--enable-clocale=generic --with-gnu-ld --enable-shared --enable-languages=c,c++
--enable-threads=posix --enable-multilib --enable-c99 --enable-long-long
--enable-symvers=gnu --enable-libstdcxx-pch
--program-prefix=arm-oe-linux-uclibceabi- --enable-lto --enable-libssp
--disable-bootstrap --disable-libgomp --disable-libmudflap --with-float=soft
--with-local-prefix=/home/kraj/work/oe/tmp/sysroots/armv5te-oe-linux-uclibceabi/usr
--with-gxx-include-dir=/home/kraj/work/oe/tmp/sysroots/armv5te-oe-linux-uclibceabi//usr/include/c++
--with-sysroot=/home/kraj/work/oe/tmp/sysroots/armv5te-oe-linux-uclibceabi
--with-build-sysroot=/home/kraj/work/oe/tmp/sysroots/armv5te-oe-linux-uclibceabi
--disable-libunwind-exceptions
--with-mpfr=/home/kraj/work/oe/tmp/sysroots/x86_64-linux/usr --with-system-zlib
--disable-decimal-float --program-prefix=arm-oe-linux-uclibceabi-
--disable-__cxa_atexit --disable-nls
Thread model: posix
gcc version 4.5.1 20100614 (prerelease) (GCC)


-- 
   Summary: internal compiler error: in gen_thumb_movhi_clobber, at
config/arm/arm.md:5811
   Product: gcc
   Version: 4.5.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: raj dot khem at gmail dot com
 GCC build triplet: x86_64-linux
  GCC host triplet: x86_64-linux
GCC target triplet: arm-oe-linux-uclibceabi


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

[Bug target/44557] internal compiler error: in gen_thumb_movhi_clobber, at config/arm/arm.md:5811

[raj dot khem at gmail dot com]

X-Bugzilla-Reason: CC



--- Comment #1 from raj dot khem at gmail dot com  2010-06-16 14:04 ---
Created an attachment (id=20928)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20928&action=view)
testcase


-- 


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

[Bug c/44555] Pointer evalutions, is that expected ?

[rguenth at gcc dot gnu dot org]

--- Comment #8 from rguenth at gcc dot gnu dot org  2010-06-16 14:11 ---
Subject: Bug 44555

Author: rguenth
Date: Wed Jun 16 14:11:03 2010
New Revision: 160836

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=160836
Log:
2010-06-16  Richard Guenther  

PR c/44555
* c-common.c (c_common_truthvalue_conversion): Remove
premature and wrong optimization concering ADDR_EXPRs.

* gcc.c-torture/execute/pr44555.c: New testcase.

Added:
trunk/gcc/testsuite/gcc.c-torture/execute/pr44555.c
Modified:
trunk/gcc/c-family/ChangeLog
trunk/gcc/c-family/c-common.c
trunk/gcc/testsuite/ChangeLog


-- 


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

[Bug c/44555] [4.3/4.4/4.5 Regression] Pointer evalutions, is that expected ?

[rguenth at gcc dot gnu dot org]

--- Comment #9 from rguenth at gcc dot gnu dot org  2010-06-16 14:12 ---
Fixed on trunk, 3.3 works, so this is a regression.


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

  Known to fail||4.1.2
  Known to work||3.3.3 4.6.0
Summary|Pointer evalutions, is that |[4.3/4.4/4.5 Regression]
   |expected ?  |Pointer evalutions, is that
   ||expected ?
   Target Milestone|--- |4.3.6


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

[Bug fortran/44556] [4.5/4.6 Regression] incorrect error: Stat-variable at (1) shall not be DEALLOCATEd within the same DEALLOCATE statement

[kargl at gcc dot gnu dot org]

--- Comment #2 from kargl at gcc dot gnu dot org  2010-06-16 14:34 ---
(In reply to comment #1)
> The following check is to simplistic, it does not work for structures but only
> for simple object names. - with structures, it gets more complicated as also
> comparing the name of the last part-ref won't work - but one needs to walk
> through the whole structure references.

Not sure how I got added to the CC list.  Remove myself.


-- 

kargl at gcc dot gnu dot org changed:

   What|Removed |Added

 CC|kargl at gcc dot gnu dot org|


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

[Bug target/44542] expand_one_stack_var_at may set DECL_ALIGN to a too high value

[hjl dot tools at gmail dot com]

--- Comment #14 from hjl dot tools at gmail dot com  2010-06-16 14:36 
---
The code in question is

  offset -= frame_phase;
  align = offset & -offset;
  align *= BITS_PER_UNIT;
  if (align == 0)
align = STACK_BOUNDARY;
  else if (align > MAX_SUPPORTED_STACK_ALIGNMENT)
align = MAX_SUPPORTED_STACK_ALIGNMENT;

offset is computed from

  align = get_decl_align_unit (SSAVAR (var));
  offset = alloc_stack_frame_space (size, align);

If you compute alignment from offset again, you
will get a number >= requested alignment. That is
when we allocate 8byte aligned at 8byte from stack,
we may get offset 8, 16, 24, 32, 40, 48, 56, 64,
... depending on how much we have allocated on stack.

As for MAX_SUPPORTED_STACK_ALIGNMENT, I doubt we
will hit it since it is a huge number.


-- 


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

[Bug target/44542] expand_one_stack_var_at may set DECL_ALIGN to a too high value

[jakub at gcc dot gnu dot org]

--- Comment #15 from jakub at gcc dot gnu dot org  2010-06-16 14:57 ---
1) all the world isn't ix86/x86_64, this is generic code, so
MAX_SUPPORTED_STACK_ALIGNMENT is small on many targets
2) even when get_decl_align_unit returns something small, the decl might still
get a nicely aligned slot (say offset 64).  If it is known at this point
that virtual_stack_vars_rtx will be at least 32 byte aligned, we shouldn't hide
that fact from the expanders.


-- 


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

[Bug fortran/44558] New: [OOP] ICE on invalid code: called TBP subroutine as TBP function

[boschmann at tp1 dot physik dot uni-siegen dot de]

module ice5
  type::a_type
   contains  
 procedure::a_subroutine_1
 procedure::a_subroutine_2
  end type a_type
contains
  subroutine a_subroutine_1(this)
class(a_type)::this
real::res
res=this%a_subroutine_2()
  end subroutine a_subroutine_1
  subroutine a_subroutine_2(this)
class(a_type)::this
  end subroutine a_subroutine_2
end module ice5


gfortran -c ice5.f03
ice5.f03:11.8:

res=this%a_subroutine_2()
1
Fehler: 'a_subroutine_2' at (1) should be a FUNCTION
f951: interner Compiler-Fehler: in gfc_add_component_ref, bei
fortran/class.c:77


Obvioulsly the code is nonsense and the compiler generates a proper error
message, so there is little need to fix this ICE. However, it is an ICE.


-- 
   Summary: [OOP] ICE on invalid code: called TBP subroutine as TBP
function
   Product: gcc
   Version: 4.6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: boschmann at tp1 dot physik dot uni-siegen dot de


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

[Bug target/44542] expand_one_stack_var_at may set DECL_ALIGN to a too high value

[hjl dot tools at gmail dot com]

--- Comment #16 from hjl dot tools at gmail dot com  2010-06-16 15:38 
---
(In reply to comment #15)
> 2) even when get_decl_align_unit returns something small, the decl might still
> get a nicely aligned slot (say offset 64).  If it is known at this point
> that virtual_stack_vars_rtx will be at least 32 byte aligned, we shouldn't 
> hide
> that fact from the expanders.
> 

I just pointed out where "expand_one_stack_var_at may set DECL_ALIGN to
a too high value" came from. To guarantee "virtual_stack_vars_rtx will
be at least 32 byte aligned", stack has to be aligned at 32byte to begin
with. Otherwise, you may not get 32byte alignment.

The current code looks correct to me if you want to use stack offset
as alignment.


-- 


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

[Bug middle-end/44505] [4.6 Regression] gcc.c-torture/execute/frame-address.c

[hubicka at ucw dot cz]

--- Comment #4 from hubicka at ucw dot cz  2010-06-16 16:13 ---
Subject: Re:  [4.6 Regression]
gcc.c-torture/execute/frame-address.c

> Confirmed on powerpc-linux.  check_fa tail calls check_fa_mid, ignoring the
> fact that check_fa_mid is passed the address of a check_fa local var.

This seems like valid transform to me.  check_fa_mid is recognized as const so
caller know that even if local variable is passed, it is not going to read it.
So i would say that the testcase is semi-invalid at least.

What about adding a asm statement clobbering memory to check_fa_work
to avoid the failure?

On the other hand I was worng to assume that built_in_frame_address does not
make function not-const or pure since it returns address of local frame
that is useless after returning from function.  With parameter greater than
0 it is not true.
I wonder if we care enough about builtin_eh_frame to make it worthwhile to
special case this in ipa-pure-const? It does not 100% fit into the framework
since the calling statement is available only to non-WPA compilation.

Honza


-- 


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

[Bug middle-end/44505] [4.6 Regression] gcc.c-torture/execute/frame-address.c

[hubicka at gcc dot gnu dot org]

--- Comment #5 from hubicka at gcc dot gnu dot org  2010-06-16 16:14 ---
mine.


-- 

hubicka at gcc dot gnu dot org changed:

   What|Removed |Added

 AssignedTo|unassigned at gcc dot gnu   |hubicka at gcc dot gnu dot
   |dot org |org
 Status|NEW |ASSIGNED
   Last reconfirmed|2010-06-16 05:59:52 |2010-06-16 16:14:34
   date||


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

[Bug fortran/44448] 32-bit gfortran.dg/atan2_1.f90 fails on Solaris 1[01]/x86 at -O0

[ro at gcc dot gnu dot org]

--- Comment #4 from ro at gcc dot gnu dot org  2010-06-16 16:16 ---
Created an attachment (id=20929)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20929&action=view)
gfortran -fdump-tree-original output 


-- 


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

[Bug c++/44535] [4.6 Regression] g++ -O[ 23] generates undefined symbol

[jamborm at gcc dot gnu dot org]

--- Comment #5 from jamborm at gcc dot gnu dot org  2010-06-16 16:25 ---
Patch posted to the mailing list:
http://gcc.gnu.org/ml/gcc-patches/2010-06/msg01653.html


-- 


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

[Bug c++/44559] New: you can't use a typedef from a typename scope in a template

[gcc at razorcam dot com]

You can't use a typedef from a typename scope in a template
This is obviously a major bug and it means you can't access the typedefs of the
ISO standard library containers in order to use safe types to manipulate those
containers, when typename is such a container.

Here is the output of the command g++ bug_report_typedef.cc 
bug_report_typedef.cc: In function ‘void f(T)’:
bug_report_typedef.cc:3: error: expected ‘;’ before ‘i’
g++ -v follows the source code of bug_report_typedef.cc

template 
void f(T t){
T::type i;
}

g++ -v bug_report_typedef.cc 
Using built-in specs.
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Debian 4.4.4-3'
--with-bugurl=file:///usr/share/doc/gcc-4.4/README.Bugs
--enable-languages=c,c++,fortran,objc,obj-c++ --prefix=/usr --enable-shared
--enable-multiarch --enable-linker-build-id --with-system-zlib
--libexecdir=/usr/lib --without-included-gettext --enable-threads=posix
--with-gxx-include-dir=/usr/include/c++/4.4 --program-suffix=-4.4 --enable-nls
--enable-clocale=gnu --enable-libstdcxx-debug --enable-objc-gc
--with-arch-32=i486 --with-tune=generic --enable-checking=release
--build=x86_64-linux-gnu --host=x86_64-linux-gnu --target=x86_64-linux-gnu
Thread model: posix
gcc version 4.4.4 (Debian 4.4.4-3) 
COLLECT_GCC_OPTIONS='-v' '-shared-libgcc' '-mtune=generic'
 /usr/lib/gcc/x86_64-linux-gnu/4.4.4/cc1plus -quiet -v -D_GNU_SOURCE
bug_report_typedef.cc -quiet -dumpbase bug_report_typedef.cc -mtune=generic
-auxbase bug_report_typedef -version -o /tmp/ccgt4Dk8.s
GNU C++ (Debian 4.4.4-3) version 4.4.4 (x86_64-linux-gnu)
compiled by GNU C version 4.4.4, GMP version 4.3.2, MPFR version
2.4.2-p1.
GGC heuristics: --param ggc-min-expand=57 --param ggc-min-heapsize=51739
ignoring nonexistent directory "/usr/local/include/x86_64-linux-gnu"
ignoring nonexistent directory
"/usr/lib/gcc/x86_64-linux-gnu/4.4.4/../../../../x86_64-linux-gnu/include"
ignoring nonexistent directory "/usr/include/x86_64-linux-gnu"
#include "..." search starts here:
#include <...> search starts here:
 /usr/include/c++/4.4
 /usr/include/c++/4.4/x86_64-linux-gnu
 /usr/include/c++/4.4/backward
 /usr/local/include
 /usr/lib/gcc/x86_64-linux-gnu/4.4.4/include
 /usr/lib/gcc/x86_64-linux-gnu/4.4.4/include-fixed
 /usr/include
End of search list.
GNU C++ (Debian 4.4.4-3) version 4.4.4 (x86_64-linux-gnu)
compiled by GNU C version 4.4.4, GMP version 4.3.2, MPFR version
2.4.2-p1.
GGC heuristics: --param ggc-min-expand=57 --param ggc-min-heapsize=51739
Compiler executable checksum: a92c574e76687c18572fdbea97434cec
bug_report_typedef.cc: In function ‘void f(T)’:
bug_report_typedef.cc:3: error: expected ‘;’ before ‘i’


-- 
   Summary: you can't use a typedef from a typename scope in a
template
   Product: gcc
   Version: 4.4.4
Status: UNCONFIRMED
  Severity: major
  Priority: P3
 Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: gcc at razorcam dot com


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

[Bug lto/44464] ICE during linux kernel whopr build

[jamborm at gcc dot gnu dot org]

--- Comment #21 from jamborm at gcc dot gnu dot org  2010-06-16 17:01 
---
Subject: Bug 44464

Author: jamborm
Date: Wed Jun 16 17:01:06 2010
New Revision: 160852

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=160852
Log:
2010-06-15  Martin Jambor  

PR lto/44464
* tree-sra.c (replace_removed_params_ssa_names): Call release_ssa_name
on the newly dead SSA name.


Modified:
branches/gcc-4_5-branch/gcc/ChangeLog
branches/gcc-4_5-branch/gcc/tree-sra.c


-- 


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

[Bug lto/44464] ICE during linux kernel whopr build

[jamborm at gcc dot gnu dot org]

--- Comment #22 from jamborm at gcc dot gnu dot org  2010-06-16 17:02 
---
This is now fixed on both the trunk and the 4.5 branch.


-- 

jamborm at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED


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

Re: [Bug c++/44559] New: you can't use a typedef from a typename scope in a template

[Andrew Pinski]

On Jun 16, 2010, at 9:57 AM, "gcc at razorcam dot com" > wrote:



You can't use a typedef from a typename scope in a template
This is obviously a major bug and it means you can't access the  
typedefs of the
ISO standard library containers in order to use safe types to  
manipulate those

containers, when typename is such a container.

Here is the output of the command g++ bug_report_typedef.cc
bug_report_typedef.cc: In function ‘void f(T)’:
bug_report_typedef.cc:3: error: expected ‘;’ before ‘i’
g++ -v follows the source code of bug_report_typedef.cc

template 
void f(T t){
   T::type i;


You are missing the keyword typename. The standard requires this  
keyword on dependent names because it could be either a variable or a  
type. The standard assumes a variable name without the keyword.



}

g++ -v bug_report_typedef.cc
Using built-in specs.
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Debian  
4.4.4-3'

--with-bugurl=file:///usr/share/doc/gcc-4.4/README.Bugs
--enable-languages=c,c++,fortran,objc,obj-c++ --prefix=/usr --enable- 
shared

--enable-multiarch --enable-linker-build-id --with-system-zlib
--libexecdir=/usr/lib --without-included-gettext --enable- 
threads=posix
--with-gxx-include-dir=/usr/include/c++/4.4 --program-suffix=-4.4 -- 
enable-nls

--enable-clocale=gnu --enable-libstdcxx-debug --enable-objc-gc
--with-arch-32=i486 --with-tune=generic --enable-checking=release
--build=x86_64-linux-gnu --host=x86_64-linux-gnu --target=x86_64- 
linux-gnu

Thread model: posix
gcc version 4.4.4 (Debian 4.4.4-3)
COLLECT_GCC_OPTIONS='-v' '-shared-libgcc' '-mtune=generic'
/usr/lib/gcc/x86_64-linux-gnu/4.4.4/cc1plus -quiet -v -D_GNU_SOURCE
bug_report_typedef.cc -quiet -dumpbase bug_report_typedef.cc - 
mtune=generic

-auxbase bug_report_typedef -version -o /tmp/ccgt4Dk8.s
GNU C++ (Debian 4.4.4-3) version 4.4.4 (x86_64-linux-gnu)
   compiled by GNU C version 4.4.4, GMP version 4.3.2, MPFR  
version

2.4.2-p1.
GGC heuristics: --param ggc-min-expand=57 --param ggc-min- 
heapsize=51739

ignoring nonexistent directory "/usr/local/include/x86_64-linux-gnu"
ignoring nonexistent directory
"/usr/lib/gcc/x86_64-linux-gnu/4.4.4/../../../../x86_64-linux-gnu/ 
include"

ignoring nonexistent directory "/usr/include/x86_64-linux-gnu"
#include "..." search starts here:
#include <...> search starts here:
/usr/include/c++/4.4
/usr/include/c++/4.4/x86_64-linux-gnu
/usr/include/c++/4.4/backward
/usr/local/include
/usr/lib/gcc/x86_64-linux-gnu/4.4.4/include
/usr/lib/gcc/x86_64-linux-gnu/4.4.4/include-fixed
/usr/include
End of search list.
GNU C++ (Debian 4.4.4-3) version 4.4.4 (x86_64-linux-gnu)
   compiled by GNU C version 4.4.4, GMP version 4.3.2, MPFR  
version

2.4.2-p1.
GGC heuristics: --param ggc-min-expand=57 --param ggc-min- 
heapsize=51739

Compiler executable checksum: a92c574e76687c18572fdbea97434cec
bug_report_typedef.cc: In function ‘void f(T)’:
bug_report_typedef.cc:3: error: expected ‘;’ before ‘i’


--
  Summary: you can't use a typedef from a typename scope in a
   template
  Product: gcc
  Version: 4.4.4
   Status: UNCONFIRMED
 Severity: major
 Priority: P3
Component: c++
   AssignedTo: unassigned at gcc dot gnu dot org
   ReportedBy: gcc at razorcam dot com


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

[Bug c++/44559] you can't use a typedef from a typename scope in a template

[pinskia at gmail dot com]

--- Comment #1 from pinskia at gmail dot com  2010-06-16 17:04 ---
Subject: Re:   New: you can't use a typedef from a typename scope in a template



On Jun 16, 2010, at 9:57 AM, "gcc at razorcam dot com"
 wrote:

> You can't use a typedef from a typename scope in a template
> This is obviously a major bug and it means you can't access the  
> typedefs of the
> ISO standard library containers in order to use safe types to  
> manipulate those
> containers, when typename is such a container.
>
> Here is the output of the command g++ bug_report_typedef.cc
> bug_report_typedef.cc: In function ‘void f(T)’:
> bug_report_typedef.cc:3: error: expected ‘;’ before ‘i’
> g++ -v follows the source code of bug_report_typedef.cc
>
> template 
> void f(T t){
>T::type i;

You are missing the keyword typename. The standard requires this  
keyword on dependent names because it could be either a variable or a  
type. The standard assumes a variable name without the keyword.

> }
>
> g++ -v bug_report_typedef.cc
> Using built-in specs.
> Target: x86_64-linux-gnu
> Configured with: ../src/configure -v --with-pkgversion='Debian  
> 4.4.4-3'
> --with-bugurl=file:///usr/share/doc/gcc-4.4/README.Bugs
> --enable-languages=c,c++,fortran,objc,obj-c++ --prefix=/usr --enable- 
> shared
> --enable-multiarch --enable-linker-build-id --with-system-zlib
> --libexecdir=/usr/lib --without-included-gettext --enable- 
> threads=posix
> --with-gxx-include-dir=/usr/include/c++/4.4 --program-suffix=-4.4 -- 
> enable-nls
> --enable-clocale=gnu --enable-libstdcxx-debug --enable-objc-gc
> --with-arch-32=i486 --with-tune=generic --enable-checking=release
> --build=x86_64-linux-gnu --host=x86_64-linux-gnu --target=x86_64- 
> linux-gnu
> Thread model: posix
> gcc version 4.4.4 (Debian 4.4.4-3)
> COLLECT_GCC_OPTIONS='-v' '-shared-libgcc' '-mtune=generic'
> /usr/lib/gcc/x86_64-linux-gnu/4.4.4/cc1plus -quiet -v -D_GNU_SOURCE
> bug_report_typedef.cc -quiet -dumpbase bug_report_typedef.cc - 
> mtune=generic
> -auxbase bug_report_typedef -version -o /tmp/ccgt4Dk8.s
> GNU C++ (Debian 4.4.4-3) version 4.4.4 (x86_64-linux-gnu)
>compiled by GNU C version 4.4.4, GMP version 4.3.2, MPFR  
> version
> 2.4.2-p1.
> GGC heuristics: --param ggc-min-expand=57 --param ggc-min- 
> heapsize=51739
> ignoring nonexistent directory "/usr/local/include/x86_64-linux-gnu"
> ignoring nonexistent directory
> "/usr/lib/gcc/x86_64-linux-gnu/4.4.4/../../../../x86_64-linux-gnu/ 
> include"
> ignoring nonexistent directory "/usr/include/x86_64-linux-gnu"
> #include "..." search starts here:
> #include <...> search starts here:
> /usr/include/c++/4.4
> /usr/include/c++/4.4/x86_64-linux-gnu
> /usr/include/c++/4.4/backward
> /usr/local/include
> /usr/lib/gcc/x86_64-linux-gnu/4.4.4/include
> /usr/lib/gcc/x86_64-linux-gnu/4.4.4/include-fixed
> /usr/include
> End of search list.
> GNU C++ (Debian 4.4.4-3) version 4.4.4 (x86_64-linux-gnu)
>compiled by GNU C version 4.4.4, GMP version 4.3.2, MPFR  
> version
> 2.4.2-p1.
> GGC heuristics: --param ggc-min-expand=57 --param ggc-min- 
> heapsize=51739
> Compiler executable checksum: a92c574e76687c18572fdbea97434cec
> bug_report_typedef.cc: In function ‘void f(T)’:
> bug_report_typedef.cc:3: error: expected ‘;’ before ‘i’
>
>
> -- 
>   Summary: you can't use a typedef from a typename scope in a
>template
>   Product: gcc
>   Version: 4.4.4
>Status: UNCONFIRMED
>  Severity: major
>  Priority: P3
> Component: c++
>AssignedTo: unassigned at gcc dot gnu dot org
>ReportedBy: gcc at razorcam dot com
>
>
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44559
>


-- 


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

[Bug fortran/44556] [4.5/4.6 Regression] incorrect error: Stat-variable at (1) shall not be DEALLOCATEd within the same DEALLOCATE statement

[sgk at troutmask dot apl dot washington dot edu]

--- Comment #3 from sgk at troutmask dot apl dot washington dot edu  
2010-06-16 17:10 ---
Subject: Re:  [4.5/4.6 Regression] incorrect error:  Stat-variable at (1) shall
not be DEALLOCATEd within the same DEALLOCATE statement

On Wed, Jun 16, 2010 at 02:34:34PM -, kargl at gcc dot gnu dot org wrote:
> 
> --- Comment #2 from kargl at gcc dot gnu dot org  2010-06-16 14:34 ---
> (In reply to comment #1)
> > The following check is to simplistic, it does not work for structures but 
> > only
> > for simple object names. - with structures, it gets more complicated as also
> > comparing the name of the last part-ref won't work - but one needs to walk
> > through the whole structure references.
> 
> Not sure how I got added to the CC list.  Remove myself.
> 

BTW, this won't work either.

program oh_my

   type a
  integer, allocatable :: b(:), d(:)
  character(len=80) :: err
  integer :: src
   end type a

   integer j
   type(a) :: c

   c%err = 'ok'

   allocate(c%b(2), errmsg=c%err, stat=j)

   deallocate(c%b, errmsg=c%err, stat=j)

end program oh_my

gfortran does not walk the components of a derived type.


-- 


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

[Bug c++/44559] you can't use a typedef from a typename scope in a template

[redi at gcc dot gnu dot org]

--- Comment #2 from redi at gcc dot gnu dot org  2010-06-16 17:13 ---
(In reply to comment #0)
> This is obviously a major bug and it means you can't access the typedefs of 
> the
> ISO standard library containers in order to use safe types to manipulate those
> containers, when typename is such a container.

If that was true I think someone would have noticed that by now!

As Andrew said, you need to use "typename"
This has been the case for years
http://gcc.gnu.org/gcc-3.4/changes.html#cplusplus


-- 

redi at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||INVALID


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

[Bug c++/44559] you can't use a typedef from a typename scope in a template

[gcc at razorcam dot com]

--- Comment #3 from gcc at razorcam dot com  2010-06-16 17:20 ---
I apologize. Thanks for your quick answers.


-- 


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

[Bug c++/44548] Link error when defining templated static const variable

[dpovey at gmail dot com]

--- Comment #7 from dpovey at gmail dot com  2010-06-16 17:57 ---
The key thing here is that the value was initialized inside the class.  So
there is no way to syntactically disambiguate a definition and a declaration of
the  value outside the class  (because normally C++ uses the initialization to
tell that you are defining it, but if you initialized it inside the class then
it doesn't let you initialize it again outside the class).  For non-specialized
"declarations/definitions", if they're initialized inside the class C++ is
forced to treat the (declaration/definition) without initializer as a
definition (I guess because it's more important to be able to define it to
declare it).  I assumed that when you specialize it, C++ also treats this
syntax as a definition.  It's possible that I was wrong.  If so I think it's a
misfeature in the C++ standard.  But I really don't know how it's interpreting
it.  

Suppose you do:

template  class C{
  int i = 1;
};
template<> int C::i;

Let's suppose it treats this as a declaration.  What is it declaring?  There is
no syntax available to *define* the value (because it looks the same as a
declaration).  Conceivably you could later override the class itself, e.g.:

template <> class C {
int i = 0;
};

But I don't know whether C++ would treat the declaration statement above as
somehow relating to this.


-- 


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

[Bug debug/44560] New: gcc.dg/pr43058.c timeout

[danglin at gcc dot gnu dot org]

This test takes too long:

# time sh xxx.sh

real17m10.313s
user12m25.690s
sys 0m1.420s
# cat xxx.sh
/mnt/gnu/gcc/objdir-test/gcc/xgcc -B/mnt/gnu/gcc/objdir-test/gcc/
/mnt/gnu/gcc/gcc/gcc/testsuite/gcc.dg/pr43058.c   -g -O2 -S  -o pr43058.s


-- 
   Summary: gcc.dg/pr43058.c timeout
   Product: gcc
   Version: 4.6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: debug
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: danglin at gcc dot gnu dot org
 GCC build triplet: hppa64-hp-hpux11.11
  GCC host triplet: hppa64-hp-hpux11.11
GCC target triplet: hppa64-hp-hpux11.11


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

[Bug target/44551] [missed optimization] AVX vextractf128 after vinsertf128

[hjl dot tools at gmail dot com]

--- Comment #2 from hjl dot tools at gmail dot com  2010-06-16 19:50 ---
The problem is UNSPEC_CAST.  There is no good way to model it.


-- 


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

[Bug target/44551] [missed optimization] AVX vextractf128 after vinsertf128

[pinskia at gcc dot gnu dot org]

--- Comment #3 from pinskia at gcc dot gnu dot org  2010-06-16 20:00 ---
Well for one, you could have a splitter if the case which_alternative == 0 so
that an reg rename can do its magic.

Also what does UNSPEC_CAST really do?  From the looks of it is just a move
which you could use a splitter on.  At least for after reload.


-- 


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

[Bug c++/44561] New: using nullptr_t with -flto/-fwhopr causes ICE: tree code 'lang_type' is not supported in gimple streams

[zsojka at seznam dot cz]

Command line:
$ g++ -std=gnu++0x -flto testcase.C
testcase.C:2:12: internal compiler error: tree code 'lang_type' is not
supported in gimple streams

 testcase.C 
typedef decltype(nullptr) nullptr_t;
nullptr_t a;


Tested revisions:
r160687 - crash
r159696 - crash
r159387 - crash
r158969 - nullptr is not recognized

The problem is that almost any code using C++0x mode fails to compile with
-flto -fkeep-inline-functions.


-- 
   Summary: using nullptr_t with -flto/-fwhopr causes ICE: tree code
'lang_type' is not supported in gimple streams
   Product: gcc
   Version: 4.6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: zsojka at seznam dot cz


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

[Bug c++/44561] using nullptr_t with -flto/-fwhopr causes ICE: tree code 'lang_type' is not supported in gimple streams

[rguenth at gcc dot gnu dot org]

--- Comment #1 from rguenth at gcc dot gnu dot org  2010-06-16 20:39 ---
Confirmed.

It isn't valid for LANG_TYPE node to leak to the middle-end.

gdb) call debug_tree (expr)
 
constant 32>
unit size  constant 4>
align 8 symtab 0 alias set -1 canonical type 0xb7799000>


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||jason at gcc dot gnu dot org
 Status|UNCONFIRMED |NEW
 Ever Confirmed|0   |1
   Last reconfirmed|-00-00 00:00:00 |2010-06-16 20:39:38
   date||


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

[Bug target/44551] [missed optimization] AVX vextractf128 after vinsertf128

[hjl dot tools at gmail dot com]

--- Comment #4 from hjl dot tools at gmail dot com  2010-06-16 20:42 ---
You can cast 256bit to 128bit to get the lower 128bit. You can also
cast 128bit to 256bit with upper 128bit undefined. If I use union,
it will always generate 2 moves via memory.


-- 


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

[Bug target/44551] [missed optimization] AVX vextractf128 after vinsertf128

[pinskia at gcc dot gnu dot org]

--- Comment #5 from pinskia at gcc dot gnu dot org  2010-06-16 20:46 ---
(In reply to comment #4)
> You can cast 256bit to 128bit to get the lower 128bit.

This way can be represented using vec_select.  And then later on using a split
(after reload) turned into a move.

> You can also cast 128bit to 256bit with upper 128bit undefined. 
Still use an UNSPEC but use define_insn_and_split which does a splitting (after
reload) to turn it into a move.  Since it is a move after all (the registers
are overlapping).

This should improve code generation.  Also penalize the non matching 0 operand
case in both insn.


-- 


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

[Bug fortran/44558] [OOP] ICE on invalid code: called TBP subroutine as TBP function

[janus at gcc dot gnu dot org]

--- Comment #1 from janus at gcc dot gnu dot org  2010-06-16 20:50 ---
Confirmed. Btw the same thing happens if you treat a type-bound function as if
it were a subroutine:

module ice5
  type::a_type
   contains  
 procedure::a_subroutine_1
 procedure::a_subroutine_2
  end type a_type
contains
  real function a_subroutine_1(this)
class(a_type)::this
real::res
!res=this%a_subroutine_2()
  end function
  subroutine a_subroutine_2(this)
class(a_type)::this
call this%a_subroutine_1()
  end subroutine
end module ice5



Error: 'a_subroutine_1' at (1) should be a SUBROUTINE
f951: internal compiler error: in gfc_add_component_ref, at fortran/class.c:77


-- 

janus at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever Confirmed|0   |1
   Last reconfirmed|-00-00 00:00:00 |2010-06-16 20:50:20
   date||


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

[Bug fortran/44558] [OOP] ICE on invalid code: called TBP subroutine as TBP function

[janus at gcc dot gnu dot org]

--- Comment #2 from janus at gcc dot gnu dot org  2010-06-16 20:58 ---
This is easily fixed by the following patch:


Index: gcc/fortran/resolve.c
===
--- gcc/fortran/resolve.c   (revision 160833)
+++ gcc/fortran/resolve.c   (working copy)
@@ -5498,7 +5498,8 @@ resolve_typebound_function (gfc_expr* e)

   /* Treat the call as if it is a typebound procedure, in order to roll
  out the correct name for the specific function.  */
-  resolve_compcall (e, &name);
+  if (resolve_compcall (e, &name) == FAILURE)
+return FAILURE;
   ts = e->ts;

   /* Then convert the expression to a procedure pointer component call.  */
@@ -5571,7 +5572,8 @@ resolve_typebound_subroutine (gfc_code *code)
   if (code->expr1->value.compcall.tbp->is_generic)
 genname = code->expr1->value.compcall.name;

-  resolve_typebound_call (code, &name);
+  if (resolve_typebound_call (code, &name) == FAILURE)
+return FAILURE;
   ts = code->expr1->ts;

   /* Then convert the expression to a procedure pointer component call.  */



I will regtest this now and in case of success commit it as obvious later ...


-- 

janus at gcc dot gnu dot org changed:

   What|Removed |Added

 AssignedTo|unassigned at gcc dot gnu   |janus at gcc dot gnu dot org
   |dot org |
 Status|NEW |ASSIGNED
   Last reconfirmed|2010-06-16 20:50:20 |2010-06-16 20:58:37
   date||


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

[Bug tree-optimization/44562] New: ICE: in get_alias_set, at alias.c:716 with -flto -fstrict-aliasing -fgraphite-identity

[zsojka at seznam dot cz]

The ICE looks similiar to PR43221, but it may be different issue - this one
needs only one file to crash.

Command line:
$ gcc -O1 -flto -fstrict-aliasing -fgraphite-identity testcase.c

Compiler output:
$ gcc -O1 -flto -fstrict-aliasing -fgraphite-identity testcase.c -m32
testcase.c: In function 'foo':
testcase.c:2:6: internal compiler error: in get_alias_set, at alias.c:716
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.


-- 
   Summary: ICE: in get_alias_set, at alias.c:716 with -flto -
fstrict-aliasing -fgraphite-identity
   Product: gcc
   Version: 4.6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: zsojka at seznam dot cz
GCC target triplet: i686-pc-linux-gnu


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

[Bug tree-optimization/44562] ICE: in get_alias_set, at alias.c:716 with -flto -fstrict-aliasing -fgraphite-identity

[zsojka at seznam dot cz]

--- Comment #1 from zsojka at seznam dot cz  2010-06-16 21:04 ---
Created an attachment (id=20930)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20930&action=view)
reduced testcase

To make it crash at x86_64-linux, the typedef has to be changed to:
typedef long long ll;

Command line (i686):
$ gcc -O1 -flto -fstrict-aliasing -fgraphite-identity pr44562.c


-- 


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

[Bug target/44551] [missed optimization] AVX vextractf128 after vinsertf128

[kretz at kde dot org]

--- Comment #6 from kretz at kde dot org  2010-06-16 21:21 ---
(In reply to comment #4)
> You can also cast 128bit to 256bit with upper 128bit undefined.
If you cast from xmm to ymm after a 128bit instruction coded with VEX prefix
then the upper 128bit are actually guaranteed to be zero. If the SSE
instruction does not use the VEX prefix then the upper 128 bits are not
modified. Thus there is never really an undefined state. That might be useful
information for other optimizations?

> If I use union, it will always generate 2 moves via memory.
Yes, I noticed that unions are not a good choice for performance critical code.
It results in way more memory moves than necessary. BTW ICC also generates
memory moves when implementing the testcase with unions.

PS: Thanks a lot for looking into this!


-- 


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

[Bug fortran/44448] 32-bit gfortran.dg/atan2_1.f90 fails on Solaris 1[01]/x86 at -O0

[fxcoudert at gcc dot gnu dot org]

--- Comment #5 from fxcoudert at gcc dot gnu dot org  2010-06-16 21:30 
---
This makes no sense at all. Rainer, I'm really sorry if it seems that I'm
shooting questions a bit at random, but I have a hard time imagining how to
narrow it down.

Can you try the following equivalent C code (at -O0):


#include 
#include 

int main (void)
{
  int i;
  float x;
  double y;

  for (i = 1; i <= 10; i++)
  {
x = __builtin_atan2f (1.f, (float) i / 10.f)
- __builtin_atan2f (1.f, (float) i / 10.f);
printf ("%g\n", x);

x = atan2f (1.f, (float) i / 10.f)
- atan2f (1.f, (float) i / 10.f);
printf ("%g\n", x);

y = __builtin_atan2 (1., (double) i / 10.)
- __builtin_atan2 (1., (double) i / 10.);
printf ("%lg\n", y);

y = atan2 (1., (double) i / 10.)
- atan2 (1., (double) i / 10.);
printf ("%lg\n", y);
  }

  return 0;
}


Right now, the only thing I can see make sense is numerically instability in
the libm. Also, how are atan2f and atan2 defined in the system's math.h header?
Do they have simple prototypes? Are they actually macros?


-- 


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

[Bug fortran/44448] 32-bit gfortran.dg/atan2_1.f90 fails on Solaris 1[01]/x86 at -O0

[kargl at gcc dot gnu dot org]

--- Comment #6 from kargl at gcc dot gnu dot org  2010-06-16 21:51 ---
(In reply to comment #5)
> This makes no sense at all. Rainer, I'm really sorry if it seems that I'm
> shooting questions a bit at random, but I have a hard time imagining how to
> narrow it down.
> 
> Can you try the following equivalent C code (at -O0):
> 
>

(Code)

> 
> 
> Right now, the only thing I can see make sense is numerically instability in
> the libm. Also, how are atan2f and atan2 defined in the system's math.h 
> header?
> Do they have simple prototypes? Are they actually macros?
> 

Does -ffloat-store change the outcome?  This looks to possibly
be an excess precision problem and the difference between something
in a register and main memory.


-- 


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

[Bug target/44557] internal compiler error: in gen_thumb_movhi_clobber, at config/arm/arm.md:5811

[mikpe at it dot uu dot se]

--- Comment #2 from mikpe at it dot uu dot se  2010-06-16 21:25 ---
With crosses to armv5tel-unknown-linux-gnueabi, gcc-4.3 and 4.4 work but a
recent 4.5 ICEs as described here.

This stopped ICEing in 4.6 with r160260, an ira/reload patch.  However, that
was just an improvement fixing a number of missed-optimization PRs (PR39871,
R40615, PR42500, PR42502) with no ARM backend changes, so I suspect there's a
bug here still latent on trunk.

I'll try a bisect next to see which revision introduced the ICE.


-- 

mikpe at it dot uu dot se changed:

   What|Removed |Added

 CC||mikpe at it dot uu dot se
Summary|internal compiler error: in |internal compiler error: in
   |gen_thumb_movhi_clobber, at |gen_thumb_movhi_clobber, at
   |config/arm/arm.md:5811  |config/arm/arm.md:5811


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

[Bug tree-optimization/44562] ICE: in get_alias_set, at alias.c:716 with -flto -fstrict-aliasing -fgraphite-identity

[rguenth at gcc dot gnu dot org]

--- Comment #2 from rguenth at gcc dot gnu dot org  2010-06-16 22:18 ---
Hm.  Confirmed.


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever Confirmed|0   |1
   Keywords||lto
   Last reconfirmed|-00-00 00:00:00 |2010-06-16 22:18:04
   date||


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

[Bug tree-optimization/44547] -Wuninitialized reports false warning in nested switch statements

[anthony dot penniston at hotmail dot com]

--- Comment #2 from anthony dot penniston at hotmail dot com  2010-06-17 
01:14 ---
(In reply to comment #1)
> Value range-propagation (VRP) does not work on disjoint ranges, so the 
> compiler
> does not actually know that argc can only be 1, 2 or 4. I think there is
> already a PR about this but I cannot find it right now.
> 

I'm not sure VRP is the issue here (the values being range-like was merely a
coincidence). Consider the following two equivalent examples:

int main( int argc, char *argv[] )
{
 if( argc == 111 || argc == 999 )
 {
  int n;
  if( argc == 111 || argc == 999 )
   n = argc;
  return n;
 }
}

int main( int argc, char *argv[] )
{
 switch( argc )
 {
  case 111:
  case 999:
  {
   int n;
   switch( argc )
   {
case 111:
case 999:
 n = argc;
   }
   return n;
  }
 }
}

In both examples - as with the example in the original report -  the compiler
is given the exact same information, namely that after the first switch/if
statement, the values on argc are constrained to either 111 or 999 (and thus
the following switch/if must necessarily cover all values of argc and n is
always used initialized). The only difference is that, in the example using
switch statements, the compiler seems to "forget" these constraints on argc.


-- 


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

[Bug tree-optimization/43924] [4.6 Regression] FAIL: gfortran.dg/array_constructor_11.f90 -O3 -g (internal compiler error)

[hp at gcc dot gnu dot org]

--- Comment #11 from hp at gcc dot gnu dot org  2010-06-17 02:20 ---
Disappeared for cris-elf in (160828:r160836], which agrees i686-linux results
on gcc100 at 
(160820) and 
(160836).  A deliberate fix (perhaps as a side-effect of fixing PR43905) or
just accidental cover-up?


-- 


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

[Bug c/44563] New: GCC uses a lot of RAM when compiling a large numbers of functions

[jvoss at altsci dot com]

When compiling a 5 MB C file with 65337 functions, gcc takes over 700 MB of ram
compiling the file to assembly. Files with fewer functions (32769 and 16385)
take exponentially less time. A workaround is to split the file into multiple c
files and compile into intermediate files seperately.

tinycc aka tcc takes 0.5 seconds to compile the same file.

I'd be happy to provide more information and justifications for such a large
number of functions, but I assume that the bug can be fixed without it.


-- 
   Summary: GCC uses a lot of RAM when compiling a large numbers of
functions
   Product: gcc
   Version: 4.3.4
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: jvoss at altsci dot com
  GCC host triplet: x86_64-pc-linux-gnu
GCC target triplet: x86_64-pc-linux-gnu


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

[Bug middle-end/44505] [4.6 Regression] gcc.c-torture/execute/frame-address.c

[amodra at gmail dot com]

--- Comment #6 from amodra at gmail dot com  2010-06-17 04:13 ---
Hmm.  Well, perhaps the thing to do is ensure we don't get a tail call by
making the same change as in
http://gcc.gnu.org/ml/gcc-patches/2005-08/msg01726.html

Index: gcc/testsuite/gcc.c-torture/execute/frame-address.c
===
--- gcc/testsuite/gcc.c-torture/execute/frame-address.c (revision 160820)
+++ gcc/testsuite/gcc.c-torture/execute/frame-address.c (working copy)
@@ -25,7 +25,7 @@ int check_fa (char *unused)
 {
   const char c = 0;

-  return check_fa_mid (&c);
+  return check_fa_mid (&c) != 0;
 }

 int how_much (void)


-- 


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

[Bug tree-optimization/44563] GCC uses a lot of RAM when compiling a large numbers of functions

[jvoss at altsci dot com]

--- Comment #1 from jvoss at altsci dot com  2010-06-17 04:14 ---
Created an attachment (id=20931)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20931&action=view)
A c file that generates a c file that is the test case.

gcc -o gcc_64kgen1 gcc_64kgen1.c -Wall
./gcc_64kgen1 > gcc_64k3.c
gcc -o gcc_64k3 gcc_64k3.c -Wall
# seven or so minutes later, it finishes.


-- 


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

[Bug target/43902] suboptimal MIPS widening multiply accumulate

[wilson at codesourcery dot com]

--- Comment #12 from wilson at codesourcery dot com  2010-06-17 04:29 
---
Subject: Re:  suboptimal MIPS widening multiply accumulate

On Wed, 2010-06-16 at 13:29 +, bernds at gcc dot gnu dot org wrote:
> Could you retest the MIPS fixed-point testcases with the obvious fix?  You
> probably have the MIPS toolchain set up already and it would probably take me
> more time.

Unfortunately, the fix is not quite that easy.  We need to handle
saturating types in the optab check.  I already wrote the multiply add
check that way, but the widening-multiply check needs to be fixed. It
turns out that there isn't any obtab for saturating widening multiply,
so we have to add one.  Also, there is also no pattern for it in the
mips-fixed.md file. There is only the saturating widening multiply
accumulate pattern.  I believe I can fix this by adding a multiply
accumulate pattern that adds zero, but now I'm starting to get cascading
patches here.  This could take a few days.

Since I was looking at adding zero, I couldn't help but notice that the
MIPS fixed point support seems incomplete.
_Sat long _Fract  f1 (void) { return 0; }
gives me
j   $31
lw  $2,.LC0
.LC0:
.word   0x0
But this can be split off into a separate bug report.

Jim


-- 


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

[Bug tree-optimization/43924] [4.6 Regression] FAIL: gfortran.dg/array_constructor_11.f90 -O3 -g (internal compiler error)

[kargl at gcc dot gnu dot org]

--- Comment #12 from kargl at gcc dot gnu dot org  2010-06-17 04:43 ---
(In reply to comment #11)
> Disappeared for cris-elf in (160828:r160836], which agrees i686-linux results
> on gcc100 at 
> (160820) and 
> (160836).  A deliberate fix (perhaps as a side-effect of fixing PR43905) or
> just accidental cover-up?
> 

I see the same thing with i686-*-freebsd.


-- 


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

[Bug tree-optimization/43924] [4.6 Regression] FAIL: gfortran.dg/array_constructor_11.f90 -O3 -g (internal compiler error)

[kargl at gcc dot gnu dot org]

--- Comment #13 from kargl at gcc dot gnu dot org  2010-06-17 05:08 ---
(In reply to comment #12)
> (In reply to comment #11)
> > Disappeared for cris-elf in (160828:r160836], which agrees i686-linux 
> > results
> > on gcc100 at 
> > (160820) and 
> > (160836).  A deliberate fix (perhaps as a side-effect of fixing PR43905) or
> > just accidental cover-up?
> > 
> 
> I see the same thing with i686-*-freebsd.

REverting the patch for 43905 with

svn merge -r 160832:160831 .

indeed shows that the ICE returns.


-- 


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

[Bug middle-end/44505] [4.6 Regression] gcc.c-torture/execute/frame-address.c

[hubicka at ucw dot cz]

--- Comment #7 from hubicka at ucw dot cz  2010-06-17 06:41 ---
Subject: Re:  [4.6 Regression]
gcc.c-torture/execute/frame-address.c

> Hmm.  Well, perhaps the thing to do is ensure we don't get a tail call by
> making the same change as in
> http://gcc.gnu.org/ml/gcc-patches/2005-08/msg01726.html
This seems fine with me ;)

Honza


-- 


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