Re: at exit alternative for AIX

2012-08-19 Thread Perry Smith

On Aug 18, 2012, at 7:48 PM, Perry Smith wrote:

 Hi Gang,
 
 I'm having an unforeseen issue.  Hopefully I'm just doing something wrong.
 
 I'm on gcc 4.5.2.  I started with a fresh build tree. I'm passing in 
 --enable-__cxa_atexit:
 
  configure \
--with-gmp=${PUBLIC_BASE} \
--with-mpfr=${PUBLIC_BASE} \
--with-mpc=${PUBLIC_BASE} \
--disable-nls \
--enable-threads=aix \
--with-libiconv-prefix=/usr \
--enable-__cxa_atexit \   
--enable-languages=c,c++

Well... found where I'm going wrong...

 fgrep cxa_atexit ../../logs/gcc-4.5.2/Make | grep target
 __cxa_atexit can't be enabled on this target
 __cxa_atexit can't be enabled on this target
 __cxa_atexit can't be enabled on this target

I guess I need to convince gcc/configure that I've added cxa_atexit




Re: at exit alternative for AIX

2012-08-19 Thread Ian Lance Taylor
On Sat, Aug 18, 2012 at 5:48 PM, Perry Smith pedz...@gmail.com wrote:

 I'm on gcc 4.5.2.  I started with a fresh build tree. I'm passing in 
 --enable-__cxa_atexit:

   configure \
 --with-gmp=${PUBLIC_BASE} \
 --with-mpfr=${PUBLIC_BASE} \
 --with-mpc=${PUBLIC_BASE} \
 --disable-nls \
 --enable-threads=aix \
 --with-libiconv-prefix=/usr \
 --enable-__cxa_atexit \   
 --enable-languages=c,c++

 config.log confirms this:

   $ /usr/work/src/gcc-4.5.2/configure --prefix=/gsa/ausgsa/projects/r/ruby 
 --with-gmp=/gsa/ausgsa/projects/r/ruby 
 --with-mpfr=/gsa/ausgsa/projects/r/ruby 
 --with-mpc=/gsa/ausgsa/projects/r/ruby --disable-nls --enable-threads=aix 
 --with-libiconv-prefix=/usr --enable-__cxa_atexit --enable-languages=c,c++

 But when I look at

 nm -Bx powerpc-ibm-aix6.1.0.0/pthread/libstdc++-v3/src/.libs/future.o

 There is still a reference to atexit.  mt_allocator.o also has a reference to 
 atexit.  It is coming from the destructor.

 .line   60
 bl .__cxa_guard_release
 nop
 lwz 3,LC..20(2)
 bl .atexit
 nop

 If I explicitly add the -fuse-cxa-atexit, then it uses cxa_atexit.  I got the 
 idea (perhaps mistaken) that the config time option flipped the default.

Look closely at the output from gcc/configure.  Does it include the
line __cxa_atexit can't be enabled on this target?  That will be
displayed if the configure script determines that your target does not
provide a __cxa_atexit function, and will override
--enable-__cxa_atexit.

Ian


Re: at exit alternative for AIX

2012-08-19 Thread Ian Lance Taylor
On Sun, Aug 19, 2012 at 11:28 AM, Ian Lance Taylor i...@google.com wrote:

 Look closely at the output from gcc/configure.  Does it include the
 line __cxa_atexit can't be enabled on this target?  That will be
 displayed if the configure script determines that your target does not
 provide a __cxa_atexit function, and will override
 --enable-__cxa_atexit.

Oh, sorry, I see that you figured that out.  To fix it, look for the
relevant string in gcc/configure.ac and add a special case as
appropriate.

Ian


Problem running the libgomp testsuite

2012-08-19 Thread Jiří Paleček

Hello,

I tried to run make check-c++ from the top directory of the source code.  
During the run, all of the libgomp tests run by it failed. From the log  
file, you can see that the gcc from the system (rather than the gcc  
currently built) was run:


Executing on host: gcc  -B/mnt/extras/src/gcc2/i686-pc-linux-gnu/libgomp/  
-B/mnt/extras/src ...

...
gcc: error: unrecognized command line option '-fno-diagnostics-show-caret'

Other tests (like libstdc++) correctly use the currently built gcc:

Executing on host: /mnt/extras/src/gcc2/host-i686-pc-linux-gnu/gcc/g++  
-shared-libgcc ...

   ^^^

Any ideas how this could be fixed?

Regards
Jiri Palecek


gcc-4.8-20120819 is now available

2012-08-19 Thread gccadmin
Snapshot gcc-4.8-20120819 is now available on
  ftp://gcc.gnu.org/pub/gcc/snapshots/4.8-20120819/
and on various mirrors, see http://gcc.gnu.org/mirrors.html for details.

This snapshot has been generated from the GCC 4.8 SVN branch
with the following options: svn://gcc.gnu.org/svn/gcc/trunk revision 190518

You'll find:

 gcc-4.8-20120819.tar.bz2 Complete GCC

  MD5=632c7dddc6b701fb190e8da0a847140b
  SHA1=210e2af10e7b8d9c957f414861d69f36bfe2

Diffs from 4.8-20120812 are available in the diffs/ subdirectory.

When a particular snapshot is ready for public consumption the LATEST-4.8
link is updated and a message is sent to the gcc list.  Please do not use
a snapshot before it has been announced that way.


internal compiler error in find_costs_and_classes

2012-08-19 Thread Xinyu Qi
Hi,

I did some iwmmxt intrinsic test for mainline gcc with this check-in
r190511 | nickc | 2012-08-19 15:11:35 +0800 (Sun, 19 Aug 2012) | 3 lines

PR target/54306
* config/arm/mmintrin.h: Remove spurious #endif.

and encountered an internal compiler error for this simple case, with option 
-march=iwmmxt2 -S
#includemmintrin.h
__m64 foo(__m64 r, int i)
{
r = _mm_slli_si64(r, i);
return r;
}
internal compiler error: in find_costs_and_classes, at ira-costs.c:1711

While with -O, compiling could pass.

File a bug?

Tnahks,
Xinyu


[Bug c/54306] ARM iwmmxt2 commit adds imbalanced #endif in mmintrin.h

2012-08-19 Thread nickc at redhat dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54306

--- Comment #1 from Nick Clifton nickc at redhat dot com 2012-08-19 07:10:01 
UTC ---
Created attachment 28049
  -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=28049
Remove offending #endif


[Bug c/54306] ARM iwmmxt2 commit adds imbalanced #endif in mmintrin.h

2012-08-19 Thread nickc at gcc dot gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54306

--- Comment #2 from Nick Clifton nickc at gcc dot gnu.org 2012-08-19 07:11:42 
UTC ---
Author: nickc
Date: Sun Aug 19 07:11:35 2012
New Revision: 190511

URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=190511
Log:
PR target/54306
* config/arm/mmintrin.h: Remove spurious #endif.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/arm/mmintrin.h


[Bug libstdc++/54320] New: [c++11] range access to VLA

2012-08-19 Thread vincenzo.innocente at cern dot ch
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54320

 Bug #: 54320
   Summary: [c++11] range access to VLA
Classification: Unclassified
   Product: gcc
   Version: 4.8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: vincenzo.innoce...@cern.ch


is range access to VLA supported?

I get compilation error for

 c++ -O3 -std=gnu++11 -c vla.cpp -DVLA

with

#includealgorithm
#ifdef VLA
int foo(int N) {
  int v[N];
  auto a = std::begin(v);
  return *a;
}
#endif

int bar() {
  int v[10];
  auto a = std::begin(v);
  return *a;
}


[Bug c/54306] ARM iwmmxt2 commit adds imbalanced #endif in mmintrin.h

2012-08-19 Thread nickc at redhat dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54306

--- Comment #3 from Nick Clifton nickc at redhat dot com 2012-08-19 07:13:25 
UTC ---
Hi Daniel,

  Thanks for catching this.  It was a snafu, corrected with the obvious fix you
suggested.

Cheers
  Nick


[Bug libstdc++/54320] [c++11] range access to VLA

2012-08-19 Thread pinskia at gcc dot gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54320

--- Comment #1 from Andrew Pinski pinskia at gcc dot gnu.org 2012-08-19 
07:17:04 UTC ---
I don't think they can ever be as std::begin is defined as a template with one
of the template arguments being the size of the array.


[Bug libstdc++/54320] [c++11] range access to VLA

2012-08-19 Thread pinskia at gcc dot gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54320

--- Comment #2 from Andrew Pinski pinskia at gcc dot gnu.org 2012-08-19 
07:18:25 UTC ---
See http://gcc.gnu.org/bugzilla/show_bug.cgi?id=5435


[Bug libstdc++/54320] [c++11] range access to VLA

2012-08-19 Thread vincenzo.innocente at cern dot ch
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54320

--- Comment #3 from vincenzo Innocente vincenzo.innocente at cern dot ch 
2012-08-19 07:24:52 UTC ---
int foo2(int N) {
  int v[N];
  for ( auto a : v)
if (a) return a;
  return 0;
}

works, though was similar to std::begin(v) std::end(v)


[Bug c++/54319] Assignment to rvalue

2012-08-19 Thread daniel.kruegler at googlemail dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54319

Daniel Krügler daniel.kruegler at googlemail dot com changed:

   What|Removed |Added

 CC||daniel.kruegler at
   ||googlemail dot com

--- Comment #1 from Daniel Krügler daniel.kruegler at googlemail dot com 
2012-08-19 07:30:30 UTC ---
Just for the record: This problem does no longer exist in gcc 4.8 (tested for 
4.8.0 20120729 (experimental))


[Bug target/54246] Bytemark FOURIER 54% slower with glibc 2.16

2012-08-19 Thread wbrana at gmail dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54246

wbrana wbrana at gmail dot com changed:

   What|Removed |Added

Summary|Bytemark FOURIER 54% slower |Bytemark FOURIER 54% slower
   |in X32 chroot   |with glibc 2.16

--- Comment #2 from wbrana wbrana at gmail dot com 2012-08-19 08:20:06 UTC ---
It isn't related to X32, but glibc 2.16.
Bug submitted: http://sourceware.org/bugzilla/show_bug.cgi?id=14496


[Bug c++/54214] (corrected copyright notes in source file)please help to determine whether it is an PostgreSQL error or a GCC error (combobox and SQL data sorting)

2012-08-19 Thread redi at gcc dot gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54214

Jonathan Wakely redi at gcc dot gnu.org changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||INVALID

--- Comment #18 from Jonathan Wakely redi at gcc dot gnu.org 2012-08-19 
10:54:13 UTC ---
Gcc cannot alter results of an SQL query, it's a bug in your program. This is
the wrong place to get help debugging your code.


[Bug c/54321] New: ice in tree_low_cst at -O3

2012-08-19 Thread dcb314 at hotmail dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54321

 Bug #: 54321
   Summary: ice in tree_low_cst at -O3
Classification: Unclassified
   Product: gcc
   Version: 4.8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: dcb...@hotmail.com


Created attachment 28050
  -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=28050
C source code

I just tried to compile the package fcron-3.0.6-5
on gcc-4.8 trunk dated 20120819 on an AMD x86_64 box.

The compiler said

fileconf.c: In function 'read_period':
fileconf.c:1317:1: internal compiler error: in tree_low_cst, at tree.c:6546
 read_period(char *ptr, cf_t *cf)
 ^
Please submit a full bug report,
with preprocessed source if appropriate.
See http://gcc.gnu.org/bugs.html for instructions.

Preprocessed source code attached. Flag -O3 required.


[Bug c/54321] ice in tree_low_cst at -O3

2012-08-19 Thread markus at trippelsdorf dot de
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54321

Markus Trippelsdorf markus at trippelsdorf dot de changed:

   What|Removed |Added

 CC||markus at trippelsdorf dot
   ||de

--- Comment #1 from Markus Trippelsdorf markus at trippelsdorf dot de 
2012-08-19 11:08:45 UTC ---
typedef struct
{
char cl_mins[0];
}
cl_t;
cl_t *a;
void fn1 ()
{
char *b = a-cl_mins;
int c = 0;
b[0] = 0;
while (++c  9)
b[c] = 255;
}


[Bug libstdc++/54320] [c++11] range access to VLA

2012-08-19 Thread paolo.carlini at oracle dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54320

--- Comment #4 from Paolo Carlini paolo.carlini at oracle dot com 2012-08-19 
11:29:15 UTC ---
Would be an extension requiring front-end support. I don't think we want it.


[Bug libstdc++/54320] [c++11] range access to VLA

2012-08-19 Thread vincenzo.innocente at cern dot ch
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54320

vincenzo Innocente vincenzo.innocente at cern dot ch changed:

   What|Removed |Added

   Severity|normal  |enhancement

--- Comment #5 from vincenzo Innocente vincenzo.innocente at cern dot ch 
2012-08-19 11:34:06 UTC ---
a good candidate for c++17 then!


[Bug c++/54320] [c++11] range access to VLA

2012-08-19 Thread paolo.carlini at oracle dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54320

Paolo Carlini paolo.carlini at oracle dot com changed:

   What|Removed |Added

 CC||jason at gcc dot gnu.org
  Component|libstdc++   |c++

--- Comment #6 from Paolo Carlini paolo.carlini at oracle dot com 2012-08-19 
11:47:25 UTC ---
In case we wanted to support this, it would essentially boil down to the C++
front-end bits introspecting the size. Let's ask Jason in CC, if it would make
sense.


[Bug c++/54319] Assignment to rvalue

2012-08-19 Thread paolo.carlini at oracle dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54319

Paolo Carlini paolo.carlini at oracle dot com changed:

   What|Removed |Added

 CC|aschepler at gmail dot com  |

--- Comment #2 from Paolo Carlini paolo.carlini at oracle dot com 2012-08-19 
11:55:16 UTC ---
Daniel can you double check? Did we regress between the end of July and now or
what? Because with today's mainline the static_assert for X fires for me.


[Bug c++/54320] [c++11] range access to VLA

2012-08-19 Thread paolo.carlini at oracle dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54320

--- Comment #7 from Paolo Carlini paolo.carlini at oracle dot com 2012-08-19 
12:05:57 UTC ---
Frankly I'm also not sure about the signature of the begin and end overloads
themselves, is it even possible to tell apart VLAs??


[Bug c++/54276] Lambda in a Template Function Undefined Reference to local static

2012-08-19 Thread paolo.carlini at oracle dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54276

Paolo Carlini paolo.carlini at oracle dot com changed:

   What|Removed |Added

 CC|travis at gockelhut dot com |

--- Comment #2 from Paolo Carlini paolo.carlini at oracle dot com 2012-08-19 
12:09:54 UTC ---
Daniel can you please double check this one too? Today I'm definitely seeing
the undefined reference.


[Bug c++/54319] Assignment to rvalue

2012-08-19 Thread daniel.kruegler at googlemail dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54319

--- Comment #3 from Daniel Krügler daniel.kruegler at googlemail dot com 
2012-08-19 12:13:32 UTC ---
(In reply to comment #2)
 Daniel can you double check? 

Good that you ask. There must by some problem with my gcc installation, because
I get different results from different contexts calling gcc. I can confirm that
gcc 4.8 invoked from my command line also fires the static assertion. I
apologize for any confusion.


[Bug c++/54276] Lambda in a Template Function Undefined Reference to local static

2012-08-19 Thread daniel.kruegler at googlemail dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54276

--- Comment #3 from Daniel Krügler daniel.kruegler at googlemail dot com 
2012-08-19 12:14:53 UTC ---
(In reply to comment #2)
 Daniel can you please double check this one too? Today I'm definitely seeing
 the undefined reference.

It seems that I need to fix my gcc installation as described in bug 54319 - my
apologies.


[Bug c++/54319] Assignment to rvalue

2012-08-19 Thread paolo.carlini at oracle dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54319

Paolo Carlini paolo.carlini at oracle dot com changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2012-08-19
 Ever Confirmed|0   |1

--- Comment #4 from Paolo Carlini paolo.carlini at oracle dot com 2012-08-19 
12:43:25 UTC ---
No problem, let's confirm these two bugs and, hey, privately maybe let me know
how it goes, maybe we can ask the help of a mingw maintainer, or something.


[Bug c++/54276] Lambda in a Template Function Undefined Reference to local static

2012-08-19 Thread paolo.carlini at oracle dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54276

Paolo Carlini paolo.carlini at oracle dot com changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2012-08-19
 Ever Confirmed|0   |1


[Bug c++/53488] Incorrect code generated when capturing a constant by reference in a lambda

2012-08-19 Thread jpalecek at web dot de
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53488

Jiří Paleček jpalecek at web dot de changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||DUPLICATE

--- Comment #10 from Jiří Paleček jpalecek at web dot de 2012-08-19 14:04:34 
UTC ---
I found a similar preceding bugreport 52026. Therefore, I'm marking as
duplicate.

*** This bug has been marked as a duplicate of bug 52026 ***


[Bug c++/52026] [c++0x] g++: Constexpr Variable Appears Uninitialized in Lambda

2012-08-19 Thread jpalecek at web dot de
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52026

--- Comment #5 from Jiří Paleček jpalecek at web dot de 2012-08-19 14:04:34 
UTC ---
*** Bug 53488 has been marked as a duplicate of this bug. ***


[Bug c++/53488] Incorrect code generated when capturing a constant by reference in a lambda

2012-08-19 Thread jpalecek at web dot de
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53488

--- Comment #11 from Jiří Paleček jpalecek at web dot de 2012-08-19 14:11:22 
UTC ---
BTW I have proposed a patch that fixes this problem here:
http://gcc.gnu.org/ml/gcc-patches/2012-08/msg01252.html. Please take a look at
it.


[Bug c++/52026] [c++0x] g++: Constexpr Variable Appears Uninitialized in Lambda

2012-08-19 Thread jpalecek at web dot de
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52026

--- Comment #6 from Jiří Paleček jpalecek at web dot de 2012-08-19 14:13:44 
UTC ---
BTW I have proposed a patch that fixes this problem here:
http://gcc.gnu.org/ml/gcc-patches/2012-08/msg01252.html. Please take a look at
it.


[Bug c++/52026] [c++0x] g++: Constexpr Variable Appears Uninitialized in Lambda

2012-08-19 Thread paolo.carlini at oracle dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52026

--- Comment #7 from Paolo Carlini paolo.carlini at oracle dot com 2012-08-19 
14:38:36 UTC ---
Do you have a copyright assignment on file?


[Bug fortran/54298] Add warning when doing equal/nonequal floating-point comparisons

2012-08-19 Thread tkoenig at gcc dot gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54298

--- Comment #3 from Thomas Koenig tkoenig at gcc dot gnu.org 2012-08-19 
15:05:49 UTC ---
Author: tkoenig
Date: Sun Aug 19 15:05:41 2012
New Revision: 190516

URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=190516
Log:
2012-08-19  Thomas König  tkoe...@gcc.gnu.org

PR fortran/54298
* gfortran.h (struct gfc_option_t): Add warn_compare_reals.
* lang.opt:  Add Wcompare-reals.
* invoke.texi:  Document -Wcompare-reals.
* resolve.c (resolve_operator):  If -Wcompare-reals is in effect,
warn about equality/inequality comparisions for REAL and COMPLEX.
* options.c (gfc_init_options):  Set warn_compare_reals.
(set_Wall):  Include warn_compare_reals in Wall.
(gfc_handle_option):  Handle Wcompare_reals.

2012-08-19  Thomas König  tkoe...@gcc.gnu.org

PR fortran/54298
* gfortran.dg/real_compare_1.f90:  New test case.
* gfortran.dg/bessel_5.f90  Add -Wno-compare-reals to options.


Added:
trunk/gcc/testsuite/gfortran.dg/real_compare_1.f90
Modified:
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/gfortran.h
trunk/gcc/fortran/invoke.texi
trunk/gcc/fortran/lang.opt
trunk/gcc/fortran/options.c
trunk/gcc/fortran/resolve.c
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gfortran.dg/bessel_5.f90


[Bug fortran/54322] New: [OOP] Wrong TARGET-attribute handling with CLASS IS/TYPE IS

2012-08-19 Thread burnus at gcc dot gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54322

 Bug #: 54322
   Summary: [OOP] Wrong TARGET-attribute handling with CLASS
IS/TYPE IS
Classification: Unclassified
   Product: gcc
   Version: 4.8.0
Status: UNCONFIRMED
  Keywords: accepts-invalid, diagnostic
  Severity: normal
  Priority: P3
 Component: fortran
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: bur...@gcc.gnu.org
CC: ja...@gcc.gnu.org


Reported at comp.lang.fortran,
https://groups.google.com/forum/?fromgroups#!topic/comp.lang.fortran/11t7gAgUGD4
 


The following piece of the program is invalid if PC_ALLOC is not a TARGET,
however, gfortran accepts it:

   select type ( AN = pc_alloc )
  type is ( POINT_3D )
 p3d_poi=AN


Note that this possibly not only affects pointer assignment but also passing as
actual argument to an INTENT(IN) pointer dummy, and possibly other cases.


!- LONG TEST CASE ---

module mymod

type POINT
   real :: X, Y

   contains
  procedure :: s1 = sub1

end type POINT

type, extends(POINT) :: POINT_3D
   real :: Z
end type POINT_3D

type, extends(POINT) :: COLOR_POINT
   integer :: COLOR
end type COLOR_POINT


contains

subroutine sub1(this)
   class(POINT) :: this
end subroutine sub1

end module mymod


!
program hello

   use mymod
   implicit none

   type(POINT), target :: P
   type(POINT_3D), target :: P3D
   type(COLOR_POINT), target :: CP
   class(POINT), pointer :: P_OR_CP

   class(POINT),allocatable::pc_alloc  !NO TARGET
   class(POINT_3D),pointer ::p3d_poi


   P_OR_CP= CP
   allocate (POINT_3D :: pc_alloc)

   pc_alloc%X=1.
   pc_alloc%Y=2.

   select type ( AN = pc_alloc )
  class is ( POINT )
!  print *, AN%X, AN%Y

  type is ( POINT_3D )
 AN%Z=3.
 p3d_poi=AN  ! INVALID if PC_ALLOC is not a TARGET
   end select

   print *, p3d_poi%X, p3d_poi%Y, p3d_poi%Z
end program


[Bug c++/52026] [c++0x] g++: Constexpr Variable Appears Uninitialized in Lambda

2012-08-19 Thread jpalecek at web dot de
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52026

--- Comment #8 from Jiří Paleček jpalecek at web dot de 2012-08-19 15:38:33 
UTC ---
(In reply to comment #7)
 Do you have a copyright assignment on file?

I don't know what you're talking about, so probably no. (BTW which file?)


[Bug c++/54323] New: Friend function declaration not correctly identified with CRTP + enable_if

2012-08-19 Thread vince.rev at gmail dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54323

 Bug #: 54323
   Summary: Friend function declaration not correctly identified
with CRTP + enable_if
Classification: Unclassified
   Product: gcc
   Version: 4.7.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: vince@gmail.com


Created attachment 28051
  -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=28051
.cpp bug example

The following example involving a friend function in a Curiously Recurring
Template Pattern base class with an enable_if default template argument is not
working :

// 
#include type_traits

// Base class definition
templatetemplatetypename class CRTP, typename T class Base
{
// Friend function declaration
public:
templatetemplatetypename class CRTP0, typename T0, class
friend int func(const BaseCRTP0, T0 rhs);

// Protected test variable
protected:
 int n;
};

// Friend function definition
templatetemplatetypename class CRTP0, typename T0,
class = typename std::enable_iftrue::type
int func(const BaseCRTP0, T0 rhs)
{
return rhs.n;
}

// Derived class definition
templatetypename T class Derived : public BaseDerived, T {};

// Main
int main()
{
Derivedint x;
func(x);
return 0;
}
// 

g++ (tested with 4.6.1, 4.6.2 and 4.7.1) seems not to be able to match the
definition with the declaration of the function and return the following error
:
int BaseDerived, int::n' is protected


[Bug fortran/54298] Add warning when doing equal/nonequal floating-point comparisons

2012-08-19 Thread tkoenig at gcc dot gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54298

Thomas Koenig tkoenig at gcc dot gnu.org changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED

--- Comment #4 from Thomas Koenig tkoenig at gcc dot gnu.org 2012-08-19 
16:08:37 UTC ---
Fixed on trunk, closing.


[Bug fortran/54302] Add optional warning when declaring a identifier in a nested scope, which matches on otherwise available one

2012-08-19 Thread tkoenig at gcc dot gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54302

Thomas Koenig tkoenig at gcc dot gnu.org changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2012-08-19
 Ever Confirmed|0   |1

--- Comment #1 from Thomas Koenig tkoenig at gcc dot gnu.org 2012-08-19 
17:01:37 UTC ---
In other words, implement -Wshadow in gfortran. Makes sense.

Confirmed.


[Bug fortran/54301] Add optional warning if pointer assigning a local variable to a nonlocal pointer

2012-08-19 Thread tkoenig at gcc dot gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54301

Thomas Koenig tkoenig at gcc dot gnu.org changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2012-08-19
 Ever Confirmed|0   |1

--- Comment #4 from Thomas Koenig tkoenig at gcc dot gnu.org 2012-08-19 
17:10:28 UTC ---
(In reply to comment #3)

 Given the potential badness, I still think one should warn for (a) to (d).
 Though, one probably should think of not warning if the target has the SAVE
 attribute.

If the target has the SAVE attribute or is allocatable, we shouldn't warn.

 The other question is whether the warning should be enabled by -Wall or not. 
 (I
 would enable it with -Wall.)

At least. Because the behavior is very likely to lead to difficult to
detect bugs, I would even consider warning by default.


[Bug fortran/54301] Add optional warning if pointer assigning a local variable to a nonlocal pointer

2012-08-19 Thread burnus at gcc dot gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54301

--- Comment #5 from Tobias Burnus burnus at gcc dot gnu.org 2012-08-19 
17:27:14 UTC ---
(In reply to comment #4)
 (In reply to comment #3)
 If the target has the SAVE attribute or is allocatable, we shouldn't warn.

Why shouldn't one warn for ALLOCATABLE? See first example in comment 2 for a
code for which I would like to warn!


Submitted patch: http://gcc.gnu.org/ml/fortran/2012-08/msg00094.html


[Bug middle-end/54321] [4.8 Regression] ice in tree_low_cst at -O3

2012-08-19 Thread pinskia at gcc dot gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54321

Andrew Pinski pinskia at gcc dot gnu.org changed:

   What|Removed |Added

   Keywords||ice-on-valid-code
  Component|c   |middle-end
   Target Milestone|--- |4.8.0
Summary|ice in tree_low_cst at -O3  |[4.8 Regression] ice in
   ||tree_low_cst at -O3


[Bug c++/54214] (corrected copyright notes in source file)please help to determine whether it is an PostgreSQL error or a GCC error (combobox and SQL data sorting)

2012-08-19 Thread lirex.software at gmail dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54214

--- Comment #19 from Denis Kolesnik lirex.software at gmail dot com 
2012-08-19 18:15:49 UTC ---
(In reply to comment #18)
 Gcc cannot alter results of an SQL query, it's a bug in your program. This is
 the wrong place to get help debugging your code.

You are right: I consider now, that it is a PostgreSQL SQL bug.

limit 1 offset ... order byt str_last_name
filters data wrong...


[Bug other/54324] New: GCC install document does not list minimum required g++ versions

2012-08-19 Thread gary at intrepid dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54324

 Bug #: 54324
   Summary: GCC install document does not list minimum required
g++ versions
Classification: Unclassified
   Product: gcc
   Version: 4.8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: other
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: g...@intrepid.com


Ref: http://gcc.gnu.org/ml/gcc-patches/2012-08/msg01223.html

Currently, install.texi states:

@heading Tools/packages necessary for building GCC
@table @asis
@item ISO C90 compiler
Necessary to bootstrap GCC, although versions of GCC prior
to 3.4 also allow bootstrapping with a traditional (KR) C compiler.

To build all languages in a cross-compiler or other configuration where
3-stage bootstrap is not performed, you need to start with an existing
GCC binary (version 2.95 or later) because source code for language
frontends other than C might use GCC extensions.

This appears to be out-of-date with respect to new GCC 4.8 C++ stage 1
build requirement.


[Bug c++/54214] (corrected copyright notes in source file)please help to determine whether it is an PostgreSQL error or a GCC error (combobox and SQL data sorting)

2012-08-19 Thread lirex.software at gmail dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54214

--- Comment #20 from Denis Kolesnik lirex.software at gmail dot com 
2012-08-19 18:21:08 UTC ---
sure: I found, that the bug is if I use limit 1 clause.

It is surelly a bug.


[Bug c++/54325] New: C++11 uniform initialization syntax for argument-less abstract base class constructor fails

2012-08-19 Thread moritz at bunkus dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54325

 Bug #: 54325
   Summary: C++11 uniform initialization syntax for argument-less
abstract base class constructor fails
Classification: Unclassified
   Product: gcc
   Version: 4.7.1
Status: UNCONFIRMED
  Severity: minor
  Priority: P3
 Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: mor...@bunkus.org


Using {} syntax for base class initialization fails with cannot allocate an
object of abstract type 'Base' for abstract base classes with argument-less
constructors. I'll include two code samples. The first one does work with g++
4.6.1 (Ubuntu 11.10), g++ 4.6.3 (Ubuntu 12.04) and clang 3.1 but does NOT work
with g++ 4.7.0 (Ubuntu 12.04) and g++ 4.7.1 (self-compiled). The second one
works with 4.7.0 and 4.7.1 as well.

Example code that does NOT work with 4.7.x but does with older versions/other
compilers:

class Base {
public:
  Base() {};
  virtual ~Base() {};

  virtual void do_stuff() = 0;
};

class Derived: public Base {
public:
  Derived() : Base{} {};
  virtual ~Derived() {};

  virtual void do_stuff() {};
};

int
main() {
  Derived d;

  return 0;
}


Changing Base's constructor to take an additional argument lets it work
suddenly:

class Base {
public:
  int m_dummy;

  Base(int dummy): m_dummy{dummy} {};
  virtual ~Base() {};

  virtual void do_stuff() = 0;
};

class Derived: public Base {
public:
  Derived() : Base{42}  {};
  virtual ~Derived() {};

  virtual void do_stuff() {};
};

int
main() {
  Derived d;

  return 0;
}

$ ~/opt/gcc/4.7.1/bin/g++ -v
Using built-in specs.
COLLECT_GCC=/home/mosu/opt/gcc/4.7.1/bin/g++
COLLECT_LTO_WRAPPER=/home/mosu/opt/gcc/4.7.1/libexec/gcc/x86_64-unknown-linux-gnu/4.7.1/lto-wrapper
Target: x86_64-unknown-linux-gnu
Configured with: ./configure --enable-checking=release --enable-languages=c,c++
--prefix=/home/mosu/opt/gcc/4.7.1
Thread model: posix
gcc version 4.7.1 (GCC)

Actual error message:

$ ~/opt/gcc/4.7.1/bin/g++ -std=c++11 -o fails fails.cpp
fails.cpp: In constructor ‘Derived::Derived()’:
fails.cpp:11:20: error: cannot allocate an object of abstract type ‘Base’
fails.cpp:1:7: note:   because the following virtual functions are pure within
‘Base’:
fails.cpp:6:16: note:   virtual void Base::do_stuff()


[Bug target/54308] [4.8 regression] build regression in 190498 on ppc64/linux: legitimate_indirect_address_p undefined

2012-08-19 Thread hp at gcc dot gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54308

--- Comment #7 from Hans-Peter Nilsson hp at gcc dot gnu.org 2012-08-19 
18:29:27 UTC ---
(In reply to comment #6)
 I was unable to build 4.1.2-27.fc7 from the SRPM.

I'm not sure it would have helped, seeing as the breakage was in
rs6000-specific parts.

 So, I've given up on finding the lowest supported compiler.

Ok, but see comment 4; try just removing the inline there.  If necessary, the
inline can be wrapped in some #ifdef construct.  It depends on the maintainer
to deem it acceptable of course.


[Bug other/54326] New: GCC does not build with G++ version 3.4.0

2012-08-19 Thread gary at intrepid dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54326

 Bug #: 54326
   Summary: GCC does not build with G++ version 3.4.0
Classification: Unclassified
   Product: gcc
   Version: 4.8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: other
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: g...@intrepid.com


Ref: http://gcc.gnu.org/ml/gcc-patches/2012-08/msg01223.html
See also: Bug #54324 (install documentation does not list the minimum required
g++ version)

Paul Hargrove noted the following build failure on an older x86-32 Linux
(Redhat 8.0) system.

The g++ version is: g++ (GCC) 3.4.0

g++ -c   -g -O2 -DIN_GCC   -fno-exceptions -fno-rtti -W -Wall
-Wwrite-strings -Wcast-qual -Wmissing-format-attribute -fno-common
 -DHAVE_CONFIG_H -DGENERATOR_FILE -I. -Ibuild
-I/usr/local/pkg/upc/nightly/compiler/gupc-src/gcc
-I/usr/local/pkg/upc/nightly/compiler/gupc-src/gcc/build
-I/usr/local/pkg/upc/nightly/compiler/gupc-src/gcc/../include
-I/usr/local/pkg/upc/nightly/compiler/gupc-src/gcc/../libcpp/include
-I/usr/local/pkg/gmp-4.2.4/include -I/usr/local/pkg/mpfr-2.4.2/include
-I/usr/local/pkg/mpc-0.8/include
 -I/usr/local/pkg/upc/nightly/compiler/gupc-src/gcc/../libdecnumber
-I/usr/local/pkg/upc/nightly/compiler/gupc-src/gcc/../libdecnumber/bid
-I../libdecnumber\
-o build/genoutput.o
/usr/local/pkg/upc/nightly/compiler/gupc-src/gcc/genoutput.c
/usr/local/pkg/upc/nightly/compiler/gupc-src/gcc/genoutput.c: In function
`void note_constraint(rtx_def*, int)':
/usr/local/pkg/upc/nightly/compiler/gupc-src/gcc/genoutput.c:1178: error:
reinterpret_cast from type `const char (*)[1]' to type `char*' casts away
constness
make[2]: *** [build/genoutput.o] Error 1
make[2]: Leaving directory `/usr/local/pkg/upc/nightly/compiler/bld/gcc'
make[1]: *** [all-gcc] Error 2


[Bug middle-end/54321] [4.8 Regression] ice in tree_low_cst at -O3

2012-08-19 Thread hjl.tools at gmail dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54321

H.J. Lu hjl.tools at gmail dot com changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2012-08-19
 CC||rguenth at gcc dot gnu.org
 Ever Confirmed|0   |1

--- Comment #2 from H.J. Lu hjl.tools at gmail dot com 2012-08-19 18:53:56 
UTC ---
It is caused by revision 188232:

http://gcc.gnu.org/ml/gcc-cvs/2012-06/msg00142.html


[Bug c/54327] New: Segmentation fault in init_ggc

2012-08-19 Thread dcb314 at hotmail dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54327

 Bug #: 54327
   Summary: Segmentation fault in init_ggc
Classification: Unclassified
   Product: gcc
   Version: 4.8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: dcb...@hotmail.com


I just tried to compile the package httrack-3.43.9-5
on gcc-4.8 trunk dated 20120819 on an AMD x86_64 box.

The compiler said

htslib.c: In function 'treathead':
htslib.c:1246:6: internal compiler error: Segmentation fault
 void treathead(t_cookie* cookie,char* adr,char* fil,htsblk* retour,char* rcvd)
{
  ^
Please submit a full bug report,
with preprocessed source if appropriate.
See http://gcc.gnu.org/bugs.html for instructions.

Here is valgrind with some more details

==13706== Invalid read of size 4
==13706==at 0xD4FF90: linemap_location_from_macro_expansion_p(line_maps*,
un
signed int) (line-map.c:796)
==13706==by 0xD4FFCF: linemap_lookup(line_maps*, unsigned int)
(line-map.c:5
12)
==13706==by 0x8E6534:
virt_loc_aware_diagnostic_finalizer(diagnostic_context
*, diagnostic_info*) (tree-diagnostic.c:113)
==13706==by 0xD3A263: diagnostic_report_diagnostic(diagnostic_context*,
diag
nostic_info*) (diagnostic.c:652)
==13706==by 0xD3B03F: internal_error(char const*, ...) (diagnostic.c:957)
==13706==by 0x8B800F: crash_signal(int) (toplev.c:335)
==13706==by 0x3809C3599F: ??? (in /usr/lib64/libc-2.15.so)
==13706==by 0x5A7625: init_ggc() (hwint.h:264)
==13706==by 0x8B967F: toplev_main(int, char**) (toplev.c:1137)
==13706==by 0x3809C21734: (below main) (in /usr/lib64/libc-2.15.so)
==13706==  Address 0x24 is not stack'd, malloc'd or (recently) free'd
==13706==

Preprocessed source code attached. Flag -O2 required.


[Bug c/54327] Segmentation fault in init_ggc

2012-08-19 Thread dcb314 at hotmail dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54327

--- Comment #1 from David Binderman dcb314 at hotmail dot com 2012-08-19 
20:14:08 UTC ---
Created attachment 28052
  -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=28052
gzipped C source code


[Bug middle-end/54321] [4.8 Regression] ice in tree_low_cst at -O3

2012-08-19 Thread jakub at gcc dot gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54321

Jakub Jelinek jakub at gcc dot gnu.org changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
 AssignedTo|unassigned at gcc dot   |jakub at gcc dot gnu.org
   |gnu.org |

--- Comment #3 from Jakub Jelinek jakub at gcc dot gnu.org 2012-08-19 
20:22:39 UTC ---
Created attachment 28053
  -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=28053
gcc48-pr54321.patch

The bug is pretty much obvious, val2 is first checked for host_integerp (val2,
0) but then tree_low_cst (val2, 1) is used.  As the middle argument to memset
is int, we should use tree_low_cst (val2, 0).

I'll bootstrap/regtest this momentarily.


[Bug other/54326] GCC does not build with G++ version 3.4.0

2012-08-19 Thread gary at intrepid dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54326

--- Comment #1 from Gary Funck gary at intrepid dot com 2012-08-19 20:54:51 
UTC ---
Don't know if this is relevant, but a recent thread on the clang-dev list
explored the differences between GCC and clang in the handling of const and
constexpr.
clang vs GCC error case: both ‘const’ and ‘constexpr’ cannot be used here
http://lists.cs.uiuc.edu/pipermail/cfe-dev/2012-August/023565.html


[Bug c/52991] attribute packed broken on mingw32?

2012-08-19 Thread mikpe at it dot uu.se
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52991

Mikael Pettersson mikpe at it dot uu.se changed:

   What|Removed |Added

 CC||kkojima at gcc dot gnu.org

--- Comment #4 from Mikael Pettersson mikpe at it dot uu.se 2012-08-19 
20:56:19 UTC ---
The problem started with the PR27942 fix in r114552:
http://gcc.gnu.org/ml/gcc-patches/2006-06/msg00569.html
http://gcc.gnu.org/ml/gcc-cvs/2006-06/msg00268.html
and it affects gcc-4.2.0 up to current trunk.

The problem isn't mingw-specific, it can be reproduced natively on e.g.
x86_64-linux.  Take this C test case, reduced from #c1:

struct A {
short s;
struct { int i; } x;
} __attribute__((__packed__));

struct C {
struct { int i; } x;
short s;
} __attribute__((__packed__));

int foo(void)
{
return sizeof(struct A) == sizeof(struct C);
}

Compiling this with -mno-ms-bitfields makes foo() return 1, but compiling with
-mms-bitfields makes foo() return 0 because sizeof(struct A) then is 8 while
sizeof(struct C) still is 6.


[Bug target/28896] -fstack-limit-symbol and m68k and non 68020

2012-08-19 Thread baker at usgs dot gov
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28896

Larry Baker baker at usgs dot gov changed:

   What|Removed |Added

  Attachment #28048|0   |1
is obsolete||

--- Comment #18 from Larry Baker baker at usgs dot gov 2012-08-19 21:18:23 
UTC ---
Created attachment 28054
  -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=28054
Patch for trunk version 2012-08-12 of gcc/config/m68k/m68k.md

Change 16-bit word offset (the default) Bcc .+6 instruction to 8-bit short
offset Bcc.S .+4 instruction (saves 2 bytes in every procedure prologue).


[Bug c/54327] [4.8 Regression] Segmentation fault in init_ggc

2012-08-19 Thread hjl.tools at gmail dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54327

H.J. Lu hjl.tools at gmail dot com changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2012-08-19
   Target Milestone|--- |4.8.0
Summary|Segmentation fault in   |[4.8 Regression]
   |init_ggc|Segmentation fault in
   ||init_ggc
 Ever Confirmed|0   |1


[Bug middle-end/54327] [4.8 Regression] Segmentation fault in init_ggc

2012-08-19 Thread hjl.tools at gmail dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54327

H.J. Lu hjl.tools at gmail dot com changed:

   What|Removed |Added

 CC||rguenth at gcc dot gnu.org
  Component|c   |middle-end

--- Comment #2 from H.J. Lu hjl.tools at gmail dot com 2012-08-19 23:22:32 
UTC ---
It is caused by revision 189915:

http://gcc.gnu.org/ml/gcc-cvs/2012-07/msg00820.html


[Bug middle-end/54327] [4.8 Regression] Segmentation fault in init_ggc

2012-08-19 Thread markus at trippelsdorf dot de
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54327

Markus Trippelsdorf markus at trippelsdorf dot de changed:

   What|Removed |Added

 CC||markus at trippelsdorf dot
   ||de

--- Comment #3 from Markus Trippelsdorf markus at trippelsdorf dot de 
2012-08-20 03:40:24 UTC ---
Small testcase:

#include string.h
#include stdlib.h
void treathead ()
{
char *a = ';' == '\0' ? : 0;
if (*a == '=')
{
while (*a == (*a == 0) || *a == '\'')
a++;
if (strlen (a)  2)
abort ();
}
}


[Bug fortran/54301] Add optional warning if pointer assigning a local variable to a nonlocal pointer

2012-08-19 Thread burnus at gcc dot gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54301

--- Comment #6 from Tobias Burnus burnus at gcc dot gnu.org 2012-08-20 
05:47:55 UTC ---
Author: burnus
Date: Mon Aug 20 05:47:46 2012
New Revision: 190522

URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=190522
Log:
2012-08-20  Tobias Burnus  bur...@net-b.de

PR fortran/54301
* expr.c (gfc_check_pointer_assign): Warn when the pointer
might outlive its target.
* gfortran.h (struct gfc_option_t): Add warn_target_lifetime.
* options.c (gfc_init_options, set_wall, gfc_handle_option):
handle it.
* invoke.texi (-Wtarget-lifetime): Document it.
(-Wall): Implied it.
* lang.opt (-Wtarget-lifetime): New flag.

2012-08-20  Tobias Burnus  bur...@net-b.de

PR fortran/54301
* gfortran.dg/warn_target_lifetime_1.f90: New.


Added:
trunk/gcc/testsuite/gfortran.dg/warn_target_lifetime_1.f90
Modified:
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/expr.c
trunk/gcc/fortran/gfortran.h
trunk/gcc/fortran/invoke.texi
trunk/gcc/fortran/lang.opt
trunk/gcc/fortran/options.c
trunk/gcc/testsuite/ChangeLog


[Bug fortran/54301] Add optional warning if pointer assigning a local variable to a nonlocal pointer

2012-08-19 Thread burnus at gcc dot gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54301

Tobias Burnus burnus at gcc dot gnu.org changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED

--- Comment #7 from Tobias Burnus burnus at gcc dot gnu.org 2012-08-20 
05:52:31 UTC ---
FIXED on the 4.8 trunk.


Re: [PATCH] Fix AVR fallout

2012-08-19 Thread Denis Chertykov
2012/8/18 Jan-Benedict Glaw jbg...@lug-owl.de:
 Hi!

 I see these warnings/errors right now:

 g++ -c   -g -O2 -DIN_GCC -DCROSS_DIRECTORY_STRUCTURE  -W -Wall -Wno-narrowing 
 -Wwrite-strings -Wcast-qual -Wstrict-prototypes -Wmissing-prototypes 
 -Wmissing-format-attribute -pedantic -Wno-long-long -Wno-variadic-macros 
 -Wno-overlength-strings -Wold-style-definition -Wc++-compat -fno-common  
 -DHAVE_CONFIG_H -I. -I. -I../../../../gcc/gcc -I../../../../gcc/gcc/. 
 -I../../../../gcc/gcc/../include -I../../../../gcc/gcc/../libcpp/include  
 -I../../../../gcc/gcc/../libdecnumber 
 -I../../../../gcc/gcc/../libdecnumber/dpd -I../libdecnumber-I. -I. 
 -I../../../../gcc/gcc -I../../../../gcc/gcc/. 
 -I../../../../gcc/gcc/../include -I../../../../gcc/gcc/../libcpp/include  
 -I../../../../gcc/gcc/../libdecnumber 
 -I../../../../gcc/gcc/../libdecnumber/dpd -I../libdecnumber   
 ../../../../gcc/gcc/config/avr/avr-log.c
 cc1plus: warning: command line option ‘-Wstrict-prototypes’ is valid for 
 C/ObjC but not for C++ [enabled by default]
 cc1plus: warning: command line option ‘-Wmissing-prototypes’ is valid for 
 C/ObjC but not for C++ [enabled by default]
 cc1plus: warning: command line option ‘-Wold-style-definition’ is valid for 
 C/ObjC but not for C++ [enabled by default]
 cc1plus: warning: command line option ‘-Wc++-compat’ is valid for C/ObjC but 
 not for C++ [enabled by default]
 ../../../../gcc/gcc/config/avr/avr-log.c: In function ‘void 
 avr_log_vadump(FILE*, const char*, va_list)’:
 ../../../../gcc/gcc/config/avr/avr-log.c:287:22: warning: ‘machine_mode’ is 
 promoted to ‘int’ when passed through ‘...’ [enabled by default]
 ../../../../gcc/gcc/config/avr/avr-log.c:287:22: note: (so you should pass 
 ‘int’ not ‘machine_mode’ to ‘va_arg’)
 ../../../../gcc/gcc/config/avr/avr-log.c:287:22: note: if this code is 
 reached, the program will abort
 ../../../../gcc/gcc/config/avr/avr-log.c:291:31: warning: ‘rtx_code’ is 
 promoted to ‘int’ when passed through ‘...’ [enabled by default]
 ../../../../gcc/gcc/config/avr/avr-log.c:291:31: note: if this code is 
 reached, the program will abort
 ../../../../gcc/gcc/config/avr/avr-log.c:295:38: warning: ‘reg_class’ is 
 promoted to ‘int’ when passed through ‘...’ [enabled by default]
 ../../../../gcc/gcc/config/avr/avr-log.c:295:38: note: if this code is 
 reached, the program will abort

 [...]

 g++   -g -O2 -DIN_GCC -DCROSS_DIRECTORY_STRUCTURE  -W -Wall -Wno-narrowing 
 -Wwrite-strings -Wcast-qual -Wstrict-prototypes -Wmissing-prototypes 
 -Wmissing-format-attribute -pedantic -Wno-long-long -Wno-variadic-macros 
 -Wno-overlength-strings -Wold-style-definition -Wc++-compat -fno-common  
 -DHAVE_CONFIG_H -I. -I. -I../../../../gcc/gcc -I../../../../gcc/gcc/. 
 -I../../../../gcc/gcc/../include -I../../../../gcc/gcc/../libcpp/include  
 -I../../../../gcc/gcc/../libdecnumber 
 -I../../../../gcc/gcc/../libdecnumber/dpd -I../libdecnumber-I. -I. 
 -I../../../../gcc/gcc -I../../../../gcc/gcc/. 
 -I../../../../gcc/gcc/../include -I../../../../gcc/gcc/../libcpp/include  
 -I../../../../gcc/gcc/../libdecnumber 
 -I../../../../gcc/gcc/../libdecnumber/dpd -I../libdecnumber   
 ../../../../gcc/gcc/config/avr/gen-avr-mmcu-texi.c -o gen-avr-mmcu-texi
 cc1plus: warning: command line option ‘-Wstrict-prototypes’ is valid for 
 C/ObjC but not for C++ [enabled by default]
 cc1plus: warning: command line option ‘-Wmissing-prototypes’ is valid for 
 C/ObjC but not for C++ [enabled by default]
 cc1plus: warning: command line option ‘-Wold-style-definition’ is valid for 
 C/ObjC but not for C++ [enabled by default]
 cc1plus: warning: command line option ‘-Wc++-compat’ is valid for C/ObjC but 
 not for C++ [enabled by default]
 ../../../../gcc/gcc/config/avr/gen-avr-mmcu-texi.c: In function ‘int main()’:
 ../../../../gcc/gcc/config/avr/gen-avr-mmcu-texi.c:53:24: error: invalid 
 conversion from ‘int’ to ‘avr_arch’ [-fpermissive]
 ../../../../gcc/gcc/config/avr/gen-avr-mmcu-texi.c:75:23: error: invalid 
 conversion from ‘int’ to ‘avr_arch’ [-fpermissive]
 make[3]: *** [gen-avr-mmcu-texi] Error 1
 make[3]: Leaving directory `/mnt/devel/src/linux/build/avr/gcc-stage1/gcc'
 make[2]: *** [all-gcc] Error 2
 make[2]: Leaving directory `/mnt/devel/src/linux/build/avr/gcc-stage1'


 I suggest this patch. Okay?



 2012-08-17  Jan-Benedict Glaw  jbg...@lug-owl.de

 gcc/Changelog:
 * config/avr/avr-log.c (avr_log_vadump): Properly use
 int-promoted enum values.
 * config/avr/avr.h (struct mcu_type_s): Change `arch' from
 int to enum avr_arch.
 * config/avr/gen-avr-mmcu-texi.c (main): Use correct initializer.



Thank you for the fix.
Committed.

Denis.


[PATCH, Committed] Fix ChangeLog (was: [PATCH] Fix AVR fallout)

2012-08-19 Thread Jan-Benedict Glaw
On Sun, 2012-08-19 10:19:37 +0400, Denis Chertykov cherty...@gmail.com wrote:
 2012/8/18 Jan-Benedict Glaw jbg...@lug-owl.de:
[...]
  gcc/Changelog:
  * config/avr/avr-log.c (avr_log_vadump): Properly use
  int-promoted enum values.
  * config/avr/avr.h (struct mcu_type_s): Change `arch' from
  int to enum avr_arch.
  * config/avr/gen-avr-mmcu-texi.c (main): Use correct initializer.
 
 Thank you for the fix.
 Committed.

I fixed ChangeLog's whitespace (probably cut'n'paste error), committed
as obvious.

2012-08-19  Jan-Benedict Glaw  jbg...@lug-owl.de

* ChangeLog: Fix whitespace.


Index: ChangeLog
===
--- ChangeLog   (revision 190511)
+++ ChangeLog   (working copy)
@@ -5,11 +5,11 @@
 
 2012-08-18  Jan-Benedict Glaw  jbg...@lug-owl.de
 
-* config/avr/avr-log.c (avr_log_vadump): Properly use
-int-promoted enum values.
-* config/avr/avr.h (struct mcu_type_s): Change `arch' from
-int to enum avr_arch.
-* config/avr/gen-avr-mmcu-texi.c (main): Use correct initializer.
+   * config/avr/avr-log.c (avr_log_vadump): Properly use
+   int-promoted enum values.
+   * config/avr/avr.h (struct mcu_type_s): Change `arch' from
+   int to enum avr_arch.
+   * config/avr/gen-avr-mmcu-texi.c (main): Use correct initializer.
 
 2012-08-18  Jan Hubicka  j...@suse.cz
 
-- 
  Jan-Benedict Glaw  jbg...@lug-owl.de  +49-172-7608481
  Signature of:  Zensur im Internet? Nein danke!
  the second  :


signature.asc
Description: Digital signature


Re: [bootstrap] Tentative fix for PR 54281

2012-08-19 Thread Eric Botcazou
[Sorry for the delay]

 So, I had failed to include Ada in my testing and my patch breaks it.
 In several ada/*.c files, we forcefully include system.h as a C header:
 
 #ifdef __cplusplus
 extern C {
 #endif
 ...
 #include system.h
 ...
 #ifdef __cplusplus
 }
 #endif
 
 
 Eric, is this really needed now?  We are including gmp.h from system.h
 due to PR 54281.  This is causing Ada builds to fail.
 
 Would it be OK to remove all the '#ifdef __cplusplus' conditionals from
 ada/*.c or is there something I'm missing?

The conditionals cannot be removed for the time being because the foreign 
language interface of the Ada part of the compiler is hardcoded for C.

Barring a massive switch to the Ada language for the GNU project, we would need 
to switch the foreign language interface to C++, which might introduce various 
maintenance issues in the short term (Arno CCed).

-- 
Eric Botcazou


[committed] cp/Make-lang.in typo fix

2012-08-19 Thread Mikael Morin
Hello,

this is outside my area of maintainership, but I thought it was obvious
enough.

Mikael


Index: Make-lang.in
===
--- Make-lang.in	(révision 190512)
+++ Make-lang.in	(révision 190513)
@@ -337,7 +337,7 @@ cp/mangle.o: cp/mangle.c $(CXX_TREE_H) $(TM_H) $(R
   gt-cp-mangle.h $(TARGET_H) $(TM_P_H) $(CGRAPH_H)
 cp/parser.o: cp/parser.c $(CXX_TREE_H) $(TM_H) $(DIAGNOSTIC_CORE_H) \
   gt-cp-parser.h $(TARGET_H) $(PLUGIN_H) intl.h \
-  c-family/c-objc.h tree-pretty-print.h $(CXX_PARSER_H) $(TIMEVAR.H)
+  c-family/c-objc.h tree-pretty-print.h $(CXX_PARSER_H) $(TIMEVAR_H)
 cp/cp-gimplify.o: cp/cp-gimplify.c $(CXX_TREE_H) $(C_COMMON_H) \
 	$(TM_H) coretypes.h pointer-set.h tree-iterator.h $(SPLAY_TREE_H)
 
Index: ChangeLog
===
--- ChangeLog	(révision 190512)
+++ ChangeLog	(révision 190513)
@@ -1,3 +1,7 @@
+2012-08-19  Mikael Morin  mik...@gcc.gnu.org
+
+	* Make-lang.in: Fix typo.
+
 2012-08-17  Jakub Jelinek  ja...@redhat.com
 
 	* cp-tree.def (SIZEOF_EXPR): Move to c-common.def.




[patch, fortran] Warning for feal / complex equality / inequality comparisons

2012-08-19 Thread Thomas Koenig

Hello world,

the attached patch warns about comparisions for equality and inequality
of real and complex values if -Wcompare-reals is given. The new
compiler option is included in -Wall.

Regression-tested, tested with make info and make dvi.

OK for trunk?

Thomas

2012-08-19  Thomas König  tkoe...@gcc.gnu.org

PR fortran/54298
* gfortran.h (struct gfc_option_t): Add warn_compare_reals.
* lang.opt:  Add Wcompare-reals.
* invoke.texi:  Document -Wcompare-reals.
* resolve.c (resolve_operator):  If -Wcompare-reals is in effect,
warn about equality/inequality comparisions for REAL and COMPLEX.
* options.c (gfc_init_options):  Set warn_compare_reals.
(set_Wall):  Include warn_compare_reals in Wall.
(gfc_handle_option):  Handle Wcompare_reals.

2012-08-19  Thomas König  tkoe...@gcc.gnu.org

PR fortran/54298
* gfortran.dg/real_compare_1.f90:  New test case.
* gfortran.dg/bessel_5.f90  Add -Wno-compare-reals to options.
Index: testsuite/gfortran.dg/bessel_5.f90
===
--- testsuite/gfortran.dg/bessel_5.f90	(Revision 190442)
+++ testsuite/gfortran.dg/bessel_5.f90	(Arbeitskopie)
@@ -1,5 +1,5 @@
 ! { dg-do run }
-! { dg-options -Wall -fno-range-check }
+! { dg-options -Wall -fno-range-check -Wno-compare-reals }
 !
 ! PR fortran/36158 - Transformational BESSEL_JN/YN
 ! PR fortran/33197 - F2008 math functions
Index: fortran/gfortran.h
===
--- fortran/gfortran.h	(Revision 190442)
+++ fortran/gfortran.h	(Arbeitskopie)
@@ -2225,6 +2225,7 @@ typedef struct
   int warn_unused_dummy_argument;
   int warn_realloc_lhs;
   int warn_realloc_lhs_all;
+  int warn_compare_reals;
   int max_errors;
 
   int flag_all_intrinsics;
Index: fortran/lang.opt
===
--- fortran/lang.opt	(Revision 190442)
+++ fortran/lang.opt	(Arbeitskopie)
@@ -218,6 +218,10 @@ Wcharacter-truncation
 Fortran Warning
 Warn about truncated character expressions
 
+Wcompare-reals
+Fortran Warning
+Warn about equality comparisons involving REAL or COMPLEX expressions
+
 Wconversion
 Fortran Warning
 ; Documented in C
Index: fortran/invoke.texi
===
--- fortran/invoke.texi	(Revision 190442)
+++ fortran/invoke.texi	(Arbeitskopie)
@@ -726,10 +726,11 @@ warnings.
 @cindex warnings, all
 Enables commonly used warning options pertaining to usage that
 we recommend avoiding and that we believe are easy to avoid.
-This currently includes @option{-Waliasing}, @option{-Wampersand}, 
-@option{-Wconversion}, @option{-Wsurprising}, @option{-Wintrinsics-std},
-@option{-Wno-tabs}, @option{-Wintrinsic-shadow}, @option{-Wline-truncation},
-@option{-Wreal-q-constant} and @option{-Wunused}.
+This currently includes @option{-Waliasing}, @option{-Wampersand},
+@option{-Wconversion}, @option{-Wcompare-reals}, @option{-Wsurprising},
+@option{-Wintrinsics-std}, @option{-Wno-tabs}, @option{-Wintrinsic-shadow},
+@option{-Wline-truncation}, @option{-Wreal-q-constant} and
+@option{-Wunused}.
 
 @item -Waliasing
 @opindex @code{Waliasing}
@@ -935,6 +936,11 @@ a scalar.  See also @option{-frealloc-lhs}.
 Warn when the compiler inserts code to for allocation or reallocation of an
 allocatable variable; this includes scalars and derived types.
 
+@item -Wcompare-reals
+@opindex @code{Wcompare-reals}
+Warn when comparing real or complex types for equality or inequality.
+Enabled by @option{-Wall}.
+
 @item -Werror
 @opindex @code{Werror}
 @cindex warnings, to errors
Index: fortran/resolve.c
===
--- fortran/resolve.c	(Revision 190442)
+++ fortran/resolve.c	(Arbeitskopie)
@@ -4034,6 +4034,27 @@ resolve_operator (gfc_expr *e)
 
 	  e-ts.type = BT_LOGICAL;
 	  e-ts.kind = gfc_default_logical_kind;
+
+	  if (gfc_option.warn_compare_reals)
+	{
+	  gfc_intrinsic_op op = e-value.op.op;
+	  
+	  if ((op1-ts.type == BT_REAL || op1-ts.type == BT_COMPLEX)
+		   (op == INTRINSIC_EQ || op == INTRINSIC_EQ_OS
+		  || op == INTRINSIC_NE || op == INTRINSIC_NE_OS))
+		{
+		  bool equality;
+
+		  equality = op == INTRINSIC_EQ || op == INTRINSIC_EQ_OS;
+		  
+		  /* Type conversion has made sure that the types
+		 of op1 and op2 agree.  */
+		  gfc_warning (%s comparison for %s at %L,
+			   equality ? Equality : Inequality,
+			   gfc_typename (op1-ts), op1-where);
+		}
+	}
+
 	  break;
 	}
 
Index: fortran/options.c
===
--- fortran/options.c	(Revision 190442)
+++ fortran/options.c	(Arbeitskopie)
@@ -113,6 +113,7 @@ gfc_init_options (unsigned int decoded_options_cou
   gfc_option.warn_unused_dummy_argument = 0;
   gfc_option.warn_realloc_lhs = 0;
   gfc_option.warn_realloc_lhs_all = 0;
+  

Re: [bootstrap] Tentative fix for PR 54281

2012-08-19 Thread Arnaud Charlet

 The conditionals cannot be removed for the time being because the foreign 
 language interface of the Ada part of the compiler is hardcoded for C.
 
 Barring a massive switch to the Ada language for the GNU project, we would 
 need 
 to switch the foreign language interface to C++, which might introduce 
 various 
 maintenance issues in the short term (Arno CCed).

Yes, that would be a large hearthquake for both the compiler and the run-time, 
which is unwanted at this stage. I guess the solution for now is to more 
selectively export the various symbols as C symbols and include header files as 
is.

Arno


Re: [patch, fortran] Warning for feal / complex equality / inequality comparisons

2012-08-19 Thread Tobias Burnus

Thomas Koenig wrote:

the attached patch warns about comparisions for equality and inequality
of real and complex values if -Wcompare-reals is given. The new
compiler option is included in -Wall.

Regression-tested, tested with make info and make dvi.
OK for trunk?


Thanks for the patch. It's okay, after fixing the nits below.


+ if (gfc_option.warn_compare_reals)
+   {
+ gfc_intrinsic_op op = e-value.op.op;
+   
+ if ((op1-ts.type == BT_REAL || op1-ts.type == BT_COMPLEX)
+  (op == INTRINSIC_EQ || op == INTRINSIC_EQ_OS
+ || op == INTRINSIC_NE || op == INTRINSIC_NE_OS))
+   {
+ bool equality;
+
+ equality = op == INTRINSIC_EQ || op == INTRINSIC_EQ_OS;
+   
+ /* Type conversion has made sure that the types
+of op1 and op2 agree.  */
+ gfc_warning (%s comparison for %s at %L,
+  equality ? Equality : Inequality,
+  gfc_typename (op1-ts), op1-where);


Can you move up the comment before the (op1-ts.type? When reading the 
patch, I stumbled over that, before reading 8 lines later that checking 
op1 is sufficient.


Additionally, your gfc_warning is rather unfriendly to translators (try 
yourself to translate it, taking into account that the Equality string 
might be re-used elsewhere). I think it is better to have two separate 
strings, one for equality and one for inequality.


Tobias


[Ada] Fix temporary incorrectly-typed COMPONENT_REF

2012-08-19 Thread Eric Botcazou
We generate a temporary incorrectly-typed COMPONENT_REF in gigi when building a 
derived tagged type with discriminant.  That's essentially harmless, but breaks 
the invariant that the type of the first operand of COMPONENT_REF is aggregate.

Tested on x86_64-suse-linux, applied on the mainline.


2012-08-19  Eric Botcazou  ebotca...@adacore.com

* gcc-interface/decl.c (gnat_to_gnu_entity) E_Record_Type: Use proper
dummy type for the temporary COMPONENT_REF built for a derived tagged
type with discriminant.


-- 
Eric Botcazou
Index: gcc-interface/decl.c
===
--- gcc-interface/decl.c	(revision 190510)
+++ gcc-interface/decl.c	(working copy)
@@ -2988,6 +2988,7 @@ gnat_to_gnu_entity (Entity_Id gnat_entit
 	if (Present (Parent_Subtype (gnat_entity)))
 	  {
 	Entity_Id gnat_parent = Parent_Subtype (gnat_entity);
+	tree gnu_dummy_parent_type = make_node (RECORD_TYPE);
 	tree gnu_parent;
 
 	/* A major complexity here is that the parent subtype will
@@ -2999,11 +3000,11 @@ gnat_to_gnu_entity (Entity_Id gnat_entit
 	   each of those discriminants to a COMPONENT_REF of the above
 	   dummy parent referencing the corresponding discriminant of the
 	   base type of the parent subtype.  */
-	gnu_get_parent = build3 (COMPONENT_REF, void_type_node,
+	gnu_get_parent = build3 (COMPONENT_REF, gnu_dummy_parent_type,
  build0 (PLACEHOLDER_EXPR, gnu_type),
  build_decl (input_location,
 		 FIELD_DECL, NULL_TREE,
-		 void_type_node),
+		 gnu_dummy_parent_type),
  NULL_TREE);
 
 	if (has_discr)


[Ada] Avoid unnecessarily overaligned access types

2012-08-19 Thread Eric Botcazou
This changes the default alignment of all access types to that of access types
with standard size (Standard'Address_Size) on non-strict-alignment platforms.
This in particular means that access-to-unconstrained-array types, whose size
is twice as large as that of regular access types, are not overaligned by
default anymore and therefore don't cause unnecessary padding in record types.

The following program must run quietly on these platforms:

procedure P is
  type Array_T is array (Positive range ) of Integer;
  type Access_Array_T is access Array_T;
  type Thin_Access_Array_T is access Array_T;
  for Thin_Access_Array_T'Size use Standard'Address_Size;
begin
  if Access_Array_T'Alignment /= Thin_Access_Array_T'Alignment then
raise Program_Error;
  end if;
end;

Tested on x86_64-suse-linux, applied on the mainline.


2012-08-19  Eric Botcazou  ebotca...@adacore.com

* layout.adb (Set_Elem_Alignment): Cap the alignment of access types to
that of a regular access type for non-strict-alignment platforms.
* gcc-interface/utils.c (finish_fat_pointer_type): Do not set the
alignment for non-strict-alignment platforms.


-- 
Eric Botcazou
Index: layout.adb
===
--- layout.adb	(revision 190510)
+++ layout.adb	(working copy)
@@ -3118,6 +3118,19 @@ package body Layout is
 
  if Esize (E) / SSU  Ttypes.Maximum_Alignment then
 S := Ttypes.Maximum_Alignment;
+
+ --  If this is an access type and the target doesn't have strict
+ --  alignment and we are not doing front end layout, then cap the
+ --  alignment to that of a regular access type. This will avoid
+ --  giving fat pointers twice the usual alignment for no practical
+ --  benefit since the misalignment doesn't really matter.
+
+ elsif Is_Access_Type (E)
+   and then not Target_Strict_Alignment
+   and then not Frontend_Layout_On_Target
+ then
+S := System_Address_Size / SSU;
+
  else
 S := UI_To_Int (Esize (E)) / SSU;
  end if;
Index: gcc-interface/utils.c
===
--- gcc-interface/utils.c	(revision 190510)
+++ gcc-interface/utils.c	(working copy)
@@ -1369,7 +1369,8 @@ void
 finish_fat_pointer_type (tree record_type, tree field_list)
 {
   /* Make sure we can put it into a register.  */
-  TYPE_ALIGN (record_type) = MIN (BIGGEST_ALIGNMENT, 2 * POINTER_SIZE);
+  if (STRICT_ALIGNMENT)
+TYPE_ALIGN (record_type) = MIN (BIGGEST_ALIGNMENT, 2 * POINTER_SIZE);
 
   /* Show what it really is.  */
   TYPE_FAT_POINTER_P (record_type) = 1;


[Patch, Fortran] PR54301 - add warning for pointer might outlive its target

2012-08-19 Thread Tobias Burnus
As suggested in the draft Fortran appendix to ISO/IEC Technical Report 
24772 Guidance for Avoiding Vulnerabilities through Language Selection 
and Use*


Future standardization efforts should consider:
...
* Requiring that processors have the ability to detect and report the
occurrence within a submitted program unit of pointer assignment of
a pointer whose lifetime is known to be longer than the lifetime of the
target.

The new flag -Wtarget-lifetime implements this; it is enabled by -Wall. 
(Well, at least kind of; the suggested requirement is only implementable 
by a complicated run-time check. However, the attached compile-time 
warning is a good approximation, which should help to find real bugs 
with only few false positives.)


Build and regtested on x86-64-gnu-linux.
OK for the trunk?

Tobias

* See 
http://gcc.gnu.org/wiki/GFortranStandards#ISO.2BAC8-IEC_Project_22.24772:_Guidance_for_Avoiding_Vulnerabilities_through_Language_Selection_and_Use
2012-08-19  Tobias Burnus  bur...@net-b.de

	PR fortran/54301
	* expr.c (gfc_check_pointer_assign): Warn when the pointer
	might outlive its target.
	* gfortran.h (struct gfc_option_t): Add warn_target_lifetime.
	* options.c (gfc_init_options, set_wall, gfc_handle_option):
	handle it.
	* invoke.texi (-Wtarget-lifetime): Document it.
	(-Wall): Implied it.
	* lang.opt (-Wtarget-lifetime): New flag.

2012-08-19  Tobias Burnus  bur...@net-b.de

	PR fortran/54301
	* gfortran.dg/warn_target_lifetime_1.f90: New.

diff --git a/gcc/fortran/expr.c b/gcc/fortran/expr.c
index 7d74528..d94afb7 100644
--- a/gcc/fortran/expr.c
+++ b/gcc/fortran/expr.c
@@ -3659,6 +3659,37 @@ gfc_check_pointer_assign (gfc_expr *lvalue, gfc_expr *rvalue)
 	  }
 }
 
+  /* Warn if it is the LHS pointer may lives longer than the RHS target.  */
+  if (gfc_option.warn_target_lifetime
+   rvalue-expr_type == EXPR_VARIABLE
+   !rvalue-symtree-n.sym-attr.save
+   !attr.pointer  !rvalue-symtree-n.sym-attr.host_assoc
+   !rvalue-symtree-n.sym-attr.in_common
+   !rvalue-symtree-n.sym-attr.use_assoc
+   !rvalue-symtree-n.sym-attr.dummy)
+{
+  bool warn;
+  gfc_namespace *ns;
+
+  warn = lvalue-symtree-n.sym-attr.dummy
+	 || lvalue-symtree-n.sym-attr.result
+	 || lvalue-symtree-n.sym-attr.host_assoc
+	 || lvalue-symtree-n.sym-attr.use_assoc
+	 || lvalue-symtree-n.sym-attr.in_common;
+
+  if (rvalue-symtree-n.sym-ns-proc_name
+	   rvalue-symtree-n.sym-ns-proc_name-attr.flavor != FL_PROCEDURE)
+   for (ns = rvalue-symtree-n.sym-ns;
+	ns-proc_name  ns-proc_name-attr.flavor != FL_PROCEDURE;
+	ns = ns-parent)
+	if (ns-parent == lvalue-symtree-n.sym-ns)
+	  warn = true;
+
+  if (warn)
+	gfc_warning (Pointer at %L in pointer assignment might outlive the 
+		 pointer target, lvalue-where);
+}
+
   return SUCCESS;
 }
 
diff --git a/gcc/fortran/gfortran.h b/gcc/fortran/gfortran.h
index 7c4c0a4..308dbc1 100644
--- a/gcc/fortran/gfortran.h
+++ b/gcc/fortran/gfortran.h
   unsigned select_type_temporary:1;
@@ -2225,6 +2226,7 @@ typedef struct
   int warn_unused_dummy_argument;
   int warn_realloc_lhs;
   int warn_realloc_lhs_all;
+  int warn_target_lifetime;
   int max_errors;
 
   int flag_all_intrinsics;
diff --git a/gcc/fortran/invoke.texi b/gcc/fortran/invoke.texi
index 658ed23..edd9183 100644
--- a/gcc/fortran/invoke.texi
+++ b/gcc/fortran/invoke.texi
@@ -147,7 +147,7 @@ and warnings}.
 -Wimplicit-procedure -Wintrinsic-shadow -Wintrinsics-std @gol
 -Wline-truncation -Wno-align-commons -Wno-tabs -Wreal-q-constant @gol
 -Wsurprising -Wunderflow -Wunused-parameter -Wrealloc-lhs Wrealloc-lhs-all @gol
--fmax-errors=@var{n} -fsyntax-only -pedantic -pedantic-errors
+-Wtarget-lifetime -fmax-errors=@var{n} -fsyntax-only -pedantic -pedantic-errors
 }
 
 @item Debugging Options
@@ -729,7 +729,7 @@ we recommend avoiding and that we believe are easy to avoid.
 This currently includes @option{-Waliasing}, @option{-Wampersand}, 
 @option{-Wconversion}, @option{-Wsurprising}, @option{-Wintrinsics-std},
 @option{-Wno-tabs}, @option{-Wintrinsic-shadow}, @option{-Wline-truncation},
-@option{-Wreal-q-constant} and @option{-Wunused}.
+@option{-Wreal-q-constant}, @option{-Wtarget-lifetime} and @option{-Wunused}.
 
 @item -Waliasing
 @opindex @code{Waliasing}
@@ -935,6 +935,11 @@ a scalar.  See also @option{-frealloc-lhs}.
 Warn when the compiler inserts code to for allocation or reallocation of an
 allocatable variable; this includes scalars and derived types.
 
+@item -Wtarget-lifetime
+@opindex @code{Wtargt-lifetime}
+Warn if the pointer in a pointer assignment might be longer than the its
+target. This option is implied by @option{-Wall}.
+
 @item -Werror
 @opindex @code{Werror}
 @cindex warnings, to errors
diff --git a/gcc/fortran/lang.opt b/gcc/fortran/lang.opt
index 3b9d29b..a721187 100644
--- a/gcc/fortran/lang.opt
+++ b/gcc/fortran/lang.opt
@@ -258,6 +258,10 @@ Wrealloc-lhs-all
 Fortran Warning
 Warn when a left-hand-side variable is 

Re: [graphds.h] Allocate graph from obstack

2012-08-19 Thread Richard Guenther
On Sat, Aug 18, 2012 at 8:10 PM, Dimitrios Apostolou ji...@gmx.net wrote:
 Initially I had one obstack per struct graph, which was better than using
 XNEW for every edge, but still obstack_init() called from new_graph() was
 too frequent.

 So in this iteration of the patch the obstack is static global, initialised
 once and never freed. Please advise on whether this is acceptable, and also
 where I should initialise the obstack once, and avoid checking if it's NULL
 in every use.

 Minor speed gains (couple of ms), tested with pre-C++ conversion snapshot,
 I'll retest soon and post update.

Either an obstack per graph or the ability to specify an obstack for allocation.
A global obstack with global lifetime is bad IMHO.

Richard.



 Thanks,
 Dimitris


Re: [PATCH/MIPS] Use ins/dins instruction when written manually

2012-08-19 Thread Richard Sandiford
Andrew Pinski andrew.pin...@caviumnetworks.com writes:
   Right now we only produce ins when a zero_extract is used on the
 right hand side.  We can do better by adding some patterns which
 combine for the ins instruction.  This patch adds those patterns and a
 testcase which shows a simple example where the code is improved.

Sorry for the delay in reviewing this.  Had you thought about trying to
teach combine.c about this instead?  It doesn't look like any of the
patterns are really providing more information about the underlying
instruction.

At the moment the patch has things like:

 +(define_insn *insvmode_internal1
 +  [(set (match_operand:GPR 0 register_operand =d)
 +(ior:GPR (and:GPR (match_operand:GPR 1 register_operand 0)
 +  (match_operand:GPR 2 const_int_operand i))
 + (and:GPR (match_operand:GPR 3 register_operand d)
 +  (match_operand:GPR 4 const_int_operand i]
 +  ISA_HAS_EXT_INS  mips_bottom_bitmask_p (INTVAL (operands[4]))
 +INTVAL(operands[2]) == ~INTVAL(operands[4])
 +{
 +  int len, pos;
 +  pos = mips_bitmask (INTVAL (operands[4]), len, MODEmode);
 +  operands[2] = GEN_INT (pos);
 +  operands[4] = GEN_INT (len);
 +  return dins\t%0,%3,%2,%4;
 +}
 +  [(set_attr type arith)
 +   (set_attr mode MODE)])

but AFAIK there's nothing to guarantee that the bottom bitmask
will be operand 2 rather than operand 4, so if we really do need
do this via patterns, I think we'd need both orderrs.

But if we do it this way, I assume every backend that provides
an insv pattern will need to cut--paste these patterns too.

Richard



Re: [wwwdocs] SH 4.8 changes update

2012-08-19 Thread Gerald Pfeifer
On Sun, 19 Aug 2012, Oleg Endo wrote:
 This is what has been done so far on the SH side for 4.8.
 I hope it's OK.

Wow, that is quite impressive (and a nice write-up also)!

I see this was already approved, but allow me to suggest some
minor editorial comments...

Index: htdocs/gcc-4.8/changes.html
===
+liThe default alignment settings have been reduced to be less aggresive.

aggressive

+  liMinor tweaks for code around software atomic sequences that are
+  enabled by code-msoft-atomic/code./li

code for?  Not sure...

+  liA new option code-menable-tas/code will make the compiler
+  generate the codetas.b/code instruction for the
+  code__atomic_test_and_set/code built-in function./li

A naive question: Why is this not on by default?  Or is it under
certain circumstances?

+liThe codefmac/code instruction will now be emitted by the
+codefmaf/code standard and built-in function./li

built-in standard function, perhaps?

+liThe code-mfused-madd/code option has been depricated in favor of

deprecated

+liAdded new options code-mfsrra/code and code-mfsca/code to allow
+the compiler using the codefsrra/code and codefsca/code
+instructions on CPUs other than SH4A./li

How about adding ...SH4A (where they are already on by default) or
similar?

Gerald


Re: [PATCH, MIPS] add new peephole for 74k dspr2

2012-08-19 Thread Richard Sandiford
Sandra Loosemore san...@codesourcery.com writes:
 This patch adds a peephole optimization to use a clever trick to 
 zero-initialize the two halves of an accumulator register with one 
 instruction instead of a mtlo/mthi pair.  OK to check in?

 -Sandra

 2012-08-16  Sandra Loosemore  san...@codesourcery.com
   Julian Brown  jul...@codesourcery.com
   MIPS Technologies, Inc.

   gcc/
   * config/mips/mips-dspr2.md (UNSPEC_ACC_INIT): Declare.
   (mult peephole2): Add peephole that converts
   mtlo $ac[1-3],$0; mthi $ac[1-3],$0 into
  mult $ac[1-3],$0,$0.
   (*mips_acc_init): New insn for above.

Not sure whether a peephole is the right choice here.  In practice,
I'd imagine these opportunities would only come from a DImode move of
$0 into a doubleword register, so we could simply emit the pattern in
mips_split_doubleword_move.

That would also allow us to use it for plain HI and LO.  It wasn't
obvious from the patch why it was restricted to the DSP extension
registers.

Please also add a scan-assembler test.

Richard


Re: Commit: BFIN: Fix use of VEC_last macro in bfin.c

2012-08-19 Thread Gerald Pfeifer
On Fri, 17 Aug 2012, Diego Novillo wrote:
 Thanks.  We need a much better mechanism for documenting and advertising 
 the stuff in contrib/.

I see that contrib/ does not even have a README file.  How about
starting one with your contributions at least (and of course what-
ever else you'd like to mention, though I don't want to sign you
up for everything already there)?

And we'll take it from there?

Or is it something else you have in mind?

Gerald


Re: [PING][PATCH,dejagnu] Allow dg-skip-if to use compiler flags specified through set_board_info cflags

2012-08-19 Thread Senthil Kumar Selvaraj
Hello

On Sat, Aug 11, 2012 at 11:09:03PM +0530, Senthil Kumar Selvaraj wrote:
 This patch allows cflags set in board config files using 
 set_board_info cflags to be used in the selectors of
 dg-skip-if and other dejagnu commands that use the check-flags
 proc.
 
 The code merely adds cflags to compiler_flags in the check-flags proc, 
 exactly the same way as multilib_flags is added.
 
 Regards
 Senthil
 
 * lib/target-supports-dg.exp (check-flags): Add cflags from board
   config to compiler_flags
 
 
 diff --git a/gcc/testsuite/lib/target-supports-dg.exp 
 b/gcc/testsuite/lib/target-supports-dg.exp
 index 2f6c4c2..bdf7476 100644
 --- a/gcc/testsuite/lib/target-supports-dg.exp
 +++ b/gcc/testsuite/lib/target-supports-dg.exp
 @@ -304,6 +304,9 @@ proc check-flags { args } {
  # If running a subset of the test suite, $TEST_ALWAYS_FLAGS may not 
 exist.
  catch {append compiler_flags  $TEST_ALWAYS_FLAGS }
  set dest [target_info name]
 +if [board_info $dest exists cflags] {
 +append compiler_flags [board_info $dest cflags] 
 +}
  if [board_info $dest exists multilib_flags] {
   append compiler_flags [board_info $dest multilib_flags] 
  }

Does the patch look ok?

Regards
Senthil


Re: [Fortran] PR37336 - FIINAL patch [1/n]: Implement the finalization wrapper subroutine

2012-08-19 Thread Tobias Burnus

Dear all,

attached is a slightly updated patch:

* Call finalizers of nonallocatable, nonpointer components
* Generate FINAL wrapper for abstract types which have a finalizer. (The 
allocatable components are deallocated in the first type (abstract or 
not) which has a finalizer, i.e. abstract + finalizer or first 
nonabstract type.)


I had to disable some resolve warning; I did so by introducing an 
attr.artificial. I used it to also fix PR 51632, where we errored out 
for __def_init and __copy where there were coarray components.


Build and regtested on x86-64-linux.
OK for the trunk?

Tobias
2012-08-19  Alessandro Fanfarillo  fanfarillo@gmail.com
Tobias Burnus  bur...@net-b.de

	PR fortran/37336
	* gfortran.h (symbol_attribute): Add artifical and final_comp.
	* parse.c (parse_derived): Set final_comp.
	* module.c (mio_symbol_attribute): Handle final.comp.
	* class.c (gfc_build_class_symbol): Defer creation of the vtab
	if the DT has finalizers, mark generated symbols as
	attr.artificial.
	(finalize_component, finalization_scalarizer,
	generate_finalization_wrapper): New static functions.
	(gfc_find_derived_vtab): Add _final component and call
	generate_finalization_wrapper.
* dump-parse-tree.c (show_f2k_derived): Use resolved
	proc_tree-n.sym rather than unresolved proc_sym.
	* resolve.c (gfc_resolve_finalizers): Remove not-implemented
	error and ensure that the vtab exists.
	(resolve_fl_derived): Resolve finalizers before
	generating the vtab.
	(resolve_symbol): Also allow assumed-rank arrays with CONTIGUOUS;
	skip artificial symbols.
	(resolve_fl_derived0): Skip artificial symbols.

2012-08-19  Alessandro Fanfarillo  fanfarillo@gmail.com
Tobias Burnus  bur...@net-b.de

	PR fortran/51632
	* gfortran.dg/coarray_class_1.f90: New.

	PR fortran/37336
	* gfortran.dg/coarray_poly_3.f90: Update dg-error.
 	* gfortran.dg/auto_dealloc_2.f90: Update scan-tree-dump-times.
	* gfortran.dg/class_19.f03: Ditto.
	* gfortran.dg/finalize_4.f03: Remove dg-excess-errors
	for not implemented.
	* gfortran.dg/finalize_5.f03: Ditto.
	* gfortran.dg/finalize_7.f03: Ditto.

diff --git a/gcc/fortran/class.c b/gcc/fortran/class.c
index 21a91ba..122cc43 100644
--- a/gcc/fortran/class.c
+++ b/gcc/fortran/class.c
@@ -34,7 +34,7 @@ along with GCC; see the file COPYING3.  If not see
  declared type of the class variable and its attributes
  (pointer/allocatable/dimension/...).
 * _vptr: A pointer to the vtable entry (see below) of the dynamic type.
-
+
For each derived type we set up a vtable entry, i.e. a structure with the
following fields:
 * _hash: A hash value serving as a unique identifier for this type.
@@ -42,6 +42,9 @@ along with GCC; see the file COPYING3.  If not see
 * _extends:  A pointer to the vtable entry of the parent derived type.
 * _def_init: A pointer to a default initialized variable of this type.
 * _copy: A procedure pointer to a copying procedure.
+* _final:A procedure pointer to a wrapper function, which frees
+		 allocatable components and calls FINAL subroutines.
+
After these follow procedure pointer components for the specific
type-bound procedures.  */
 
@@ -572,7 +575,9 @@ gfc_build_class_symbol (gfc_typespec *ts, symbol_attribute *attr,
   if (gfc_add_component (fclass, _vptr, c) == FAILURE)
 	return FAILURE;
   c-ts.type = BT_DERIVED;
-  if (delayed_vtab)
+  if (delayed_vtab
+	  || (ts-u.derived-f2k_derived
+	   ts-u.derived-f2k_derived-finalizers))
 	c-ts.u.derived = NULL;
   else
 	{
@@ -689,6 +694,672 @@ copy_vtab_proc_comps (gfc_symbol *declared, gfc_symbol *vtype)
 }
 
 
+/* Call DEALLOCATE for the passed component if it is allocatable, if it is
+   neither allocatable nor a pointer but has a finalizer, call it. If it
+   is a nonpointer component with allocatable or finalizes components, walk
+   them. Either of the is required; other nonallocatables and pointers aren't
+   handled gracefully.
+   Note: The DEALLOCATE handling takes care of finalizers, coarray
+   deregistering and allocatable components of the allocatable.  */
+
+void
+finalize_component (gfc_expr *expr, gfc_symbol *derived, gfc_component *comp,
+		gfc_expr *stat, gfc_code **code)
+{
+  gfc_expr *e;
+  e = gfc_copy_expr (expr);
+  e-ref = gfc_get_ref ();
+  e-ref-type = REF_COMPONENT;
+  e-ref-u.c.sym = derived;
+  e-ref-u.c.component = comp;
+  e-ts = comp-ts;
+
+  if (comp-attr.dimension
+  || (comp-ts.type == BT_CLASS  CLASS_DATA (comp)
+	   CLASS_DATA (comp)-attr.dimension))
+{
+  e-ref-next = gfc_get_ref ();
+  e-ref-next-type = REF_ARRAY;
+  e-ref-next-u.ar.type = AR_FULL;
+  e-ref-next-u.ar.dimen = 0;
+  e-ref-next-u.ar.as = comp-ts.type == BT_CLASS ? CLASS_DATA (comp)-as
+			: comp-as;
+  e-rank = e-ref-next-u.ar.as-rank;
+}
+
+  if (comp-attr.allocatable
+  || (comp-ts.type == BT_CLASS  CLASS_DATA (comp)
+	   CLASS_DATA 

Re: Inheritance of gfc_symbol / gfc_component

2012-08-19 Thread Mikael Morin
On 18/08/2012 19:25, Tobias Schlüter wrote:
 I thought I could work around this problem without introducing a
 constructor by:
 1) using 0 instead of -1 as value for this fake label (which is also
 not a valid value for a label, so it can't collide
 2) setting ST_LABEL_FORMAT = 0
 and then
 3) not initializing at all, assuming that as for a C struct
 format_asterisk would end up in .bss and thus be zero initialized.
Initialization doesn't seem to be that important after all as only the
address of the variable is used.
It would be safer, I think, to define the variable as a pointer with
invalid (non-NULL) value.

 The benefit over the
 STL's map or a hashtable (which is better suited) is that we can
 traverse a tree in defined order.  We use this property to write
 reproducible module files.
Indeed.

 Could you post the not-yet-finished patch?
 
 Please find it attached.  Note that two void* remain:
 gfc_{insert|delete}_bbt still need it, and I don't think there's a way
 around this without templates and without significantly changing the
 code.  As I said before, I think a change needs to have a benefit.  I'm
 disappointed by this outcome, but think this patch fails this
 requirement mainly because of the format_asterisk issue.
I'm not so much concerned about format_asterisk (see above).
My main concern is this: the increased type safety by changing the
(void*) - (gfc_bbt*) change is balanced by the reduced type safety for
all the types inherited from gfc_bbt as the left and right pointer have
now gfc_bbt type instead of the derived type. And we better have type
safety for gfc_symtree which is used all over the place.

After digging some information on the web about C++ and casts, I'm not
even sure the casts are correct because of the following quote from the
standard:
The order in which the base class subobjects are allocated in the most
derived object (1.8) is unspecified.
This tells me we shouldn't rely on the gfc_symtree, pointer_info,
etc having the same address as the corresponding gfc_bbt they derive
from (unless the explicit casts add/substract the necessary offset if
needed though).
We're probably safe with single inheritance, but still...

Mikael


Re: [wwwdocs] SH 4.8 changes update

2012-08-19 Thread Oleg Endo
On Sun, 2012-08-19 at 19:20 +0200, Gerald Pfeifer wrote:
 On Sun, 19 Aug 2012, Oleg Endo wrote:
  This is what has been done so far on the SH side for 4.8.
  I hope it's OK.
 
 Wow, that is quite impressive (and a nice write-up also)!

Thanks.  Let's hope that I can squeeze in some more stuff while stage 1
lasts. :T

 I see this was already approved, but allow me to suggest some
 minor editorial comments...

Thanks for those!  Since I've just committed the thing as it was, please
find the correcting patch in the attachments.

 
 Index: htdocs/gcc-4.8/changes.html
 ===
 +liThe default alignment settings have been reduced to be less 
 aggresive.
 
 aggressive

Fixed.

 +  liMinor tweaks for code around software atomic sequences that are
 +  enabled by code-msoft-atomic/code./li
 
 code for?  Not sure...

Rephrased.

 +  liA new option code-menable-tas/code will make the compiler
 +  generate the codetas.b/code instruction for the
 +  code__atomic_test_and_set/code built-in function./li
 
 A naive question: Why is this not on by default?  Or is it under
 certain circumstances?

SH's tas.b insn can potentially confuse caches under certain HW
configurations and result in data corruption.  Moreover, it flushes the
operand cache line for the variable in question and then does its thing.
There might be problems when it's used together with other ways of doing
atomics, so maybe it's better not to surprise people by enabling it by
default.
But now that you mention it, maybe it would be better to rename the
'-menable-tas' option to '-mtas', since other instruction related
options do not have 'enabled' in the name.

 +liThe codefmac/code instruction will now be emitted by the
 +codefmaf/code standard and built-in function./li
 
 built-in standard function, perhaps?

Clarified.

 
 +liThe code-mfused-madd/code option has been depricated in favor of
 
 deprecated

Fixed.

 +liAdded new options code-mfsrra/code and code-mfsca/code to 
 allow
 +the compiler using the codefsrra/code and codefsca/code
 +instructions on CPUs other than SH4A./li
 
 How about adding ...SH4A (where they are already on by default) or
 similar?

Added.

OK to install?

Cheers,
Oleg
Index: htdocs/gcc-4.8/changes.html
===
RCS file: /cvs/gcc/wwwdocs/htdocs/gcc-4.8/changes.html,v
retrieving revision 1.14
diff -u -r1.14 changes.html
--- htdocs/gcc-4.8/changes.html	19 Aug 2012 17:16:04 -	1.14
+++ htdocs/gcc-4.8/changes.html	19 Aug 2012 18:07:37 -
@@ -159,14 +159,14 @@
 
 h3SH/h3
   ul
-liThe default alignment settings have been reduced to be less aggresive.
+liThe default alignment settings have been reduced to be less aggressive.
 This results in more compact code for optimization levels other than
 code-Os/code./li
 
 liImproved support for the code__atomic/code built-in functions:
 ul
-  liMinor tweaks for code around software atomic sequences that are
-  enabled by code-msoft-atomic/code./li
+  liMinor improvements to code generated for software atomic sequences
+  that are enabled by code-msoft-atomic/code./li
 
   liA new option code-menable-tas/code will make the compiler
   generate the codetas.b/code instruction for the
@@ -197,9 +197,10 @@
 code__builtin_prefetch/code built-in function for SH3./li
 
 liThe codefmac/code instruction will now be emitted by the
-codefmaf/code standard and built-in function./li
+codefmaf/code standard function and the code__builtin_fmaf/code
+built-in function./li
 
-liThe code-mfused-madd/code option has been depricated in favor of
+liThe code-mfused-madd/code option has been deprecated in favor of
 the machine-independent code-ffp-contract/code option.  Notice that the
 codefmac/code instruction will now be generated by default for
 expressions like codea * b + c/code.  This is due to the compiler
@@ -207,7 +208,8 @@
 
 liAdded new options code-mfsrra/code and code-mfsca/code to allow
 the compiler using the codefsrra/code and codefsca/code
-instructions on CPUs other than SH4A./li
+instructions on CPUs other than SH4A (where they are already enabled by
+default)./li
 
 liAdded support for the code__builtin_bswap32/code built-in function.
 It is now expanded as a sequence of codeswap.b/code and


Re: Inheritance of gfc_symbol / gfc_component

2012-08-19 Thread Tobias Schlüter


Hi Mikael,

On 2012-08-19 19:57, Mikael Morin wrote:

My main concern is this: the increased type safety by changing the
(void*) - (gfc_bbt*) change is balanced by the reduced type safety for
all the types inherited from gfc_bbt as the left and right pointer have
now gfc_bbt type instead of the derived type. And we better have type
safety for gfc_symtree which is used all over the place.


An interesting and valid point.  I don't think there's a way around this 
without using templates (or macros).  In a way, inheriting from gfc_bbt 
is also not really the purpose of inheritance, which is meant to express 
an any A is also a B relationship.  An object that can be stored in a 
tree is not the same as the tree itself.  This distinction is not made 
by my patch.  Since my interest was purely to get an equivalent 
alternative to the macro magic and void*'s, I wasn't too worried about 
this, but it's another wart.



After digging some information on the web about C++ and casts, I'm not
even sure the casts are correct because of the following quote from the
standard:
The order in which the base class subobjects are allocated in the most
derived object (1.8) is unspecified.
This tells me we shouldn't rely on the gfc_symtree, pointer_info,
etc having the same address as the corresponding gfc_bbt they derive
from (unless the explicit casts add/substract the necessary offset if
needed though).
We're probably safe with single inheritance, but still...


To my knowledge it's perfectly valid to cast from a base class to a 
derived class, even though 'static_cast' would be the preferred C++ 
operator for the conversion.  The resulting pointer may only be 
dereferenced if the types of the objects in memory are correct, though. 
 The cast can take care of the issues with different offsets, multiple 
inheritance and so on because the compiler knows the whole class hierarchy.


Anyway, all this is academic, as the patch brings no benefit IMO.

Cheers,
- Tobi



obstack for equiv_class_label, more vectors on stack

2012-08-19 Thread Dimitrios Apostolou




2012-08-19  Dimitrios Apostolou  ji...@gmx.net

* gcc/tree-ssa-structalias.c: Change declaration of ce_s type
vector from heap to stack. Update all relevant functions to
VEC_alloc() such vector upfront with enough (32) slots so that
malloc() calls are mostly avoided.
(equiv_class_obstack) New global static obstack for allocating
struct equiv_class_label.
(equiv_class_add): Use the above instead of malloc().
(perform_var_substitution): Don't allow entries of
location_equiv_class_table to be freed, because they are free'd...
(free_var_substitution_info): ...here by freeing the obstack.
* gcc/vecir.h: Add declaration of stack allocated tree type vector.
* gcc/tree-ssa-sccvn.c (vn_phi_insert, print_scc, compare_ops)
(sort_scc, copy_reference, extract_and_process_scc_for_name): Use
it, instead of heap allocated vector.



Not all of these places are hot on the profiler, but since I changed a few 
I had to change them all to remove complete the heap ce_s vector. Passes 
tests and offers small gains (couple of ms), but expect a more thorough 
report and testing against a new snapshot by next week.



Thanks,
Dimitris2012-08-19  Dimitrios Apostolou  ji...@gmx.net

* gcc/tree-ssa-structalias.c: Change declaration of ce_s type
vector from heap to stack. Update all relevant functions to
VEC_alloc() such vector upfront with enough (32) slots so that
malloc() calls are mostly avoided.
(equiv_class_obstack) New global static obstack for allocating
struct equiv_class_label.
(equiv_class_add): Use the above instead of malloc().
(perform_var_substitution): Don't allow entries of
location_equiv_class_table to be freed, because they are free'd...
(free_var_substitution_info): ...here by freeing the obstack.
* gcc/vecir.h: Add declaration of stack allocated tree type vector.
* gcc/tree-ssa-sccvn.c (vn_phi_insert, print_scc, compare_ops)
(sort_scc, copy_reference, extract_and_process_scc_for_name): Use
it, instead of heap allocated vector.


=== modified file 'gcc/tree-ssa-structalias.c'
--- gcc/tree-ssa-structalias.c  2012-08-16 14:27:51 +
+++ gcc/tree-ssa-structalias.c  2012-08-18 16:43:02 +
@@ -472,11 +472,14 @@ struct constraint_expr
 
 typedef struct constraint_expr ce_s;
 DEF_VEC_O(ce_s);
-DEF_VEC_ALLOC_O(ce_s, heap);
-static void get_constraint_for_1 (tree, VEC(ce_s, heap) **, bool, bool);
-static void get_constraint_for (tree, VEC(ce_s, heap) **);
-static void get_constraint_for_rhs (tree, VEC(ce_s, heap) **);
-static void do_deref (VEC (ce_s, heap) **);
+DEF_VEC_ALLOC_O_STACK(ce_s);
+#define VEC_ce_s_stack_alloc(alloc) \
+  VEC_stack_alloc (ce_s, alloc)
+
+static void get_constraint_for_1 (tree, VEC(ce_s, stack) **, bool, bool);
+static void get_constraint_for (tree, VEC(ce_s, stack) **);
+static void get_constraint_for_rhs (tree, VEC(ce_s, stack) **);
+static void do_deref (VEC (ce_s, stack) **);
 
 /* Our set constraints are made up of two constraint expressions, one
LHS, and one RHS.
@@ -1893,6 +1896,9 @@ static htab_t pointer_equiv_class_table;
classes.  */
 static htab_t location_equiv_class_table;
 
+/* Pool of memory for storing the above */
+static struct obstack equiv_class_obstack;
+
 /* Hash function for a equiv_class_label_t */
 
 static hashval_t
@@ -1942,7 +1948,7 @@ equiv_class_add (htab_t table, unsigned
 bitmap labels)
 {
   void **slot;
-  equiv_class_label_t ecl = XNEW (struct equiv_class_label);
+  equiv_class_label_t ecl = XOBNEW (equiv_class_obstack, struct 
equiv_class_label);
 
   ecl-labels = labels;
   ecl-equivalence_class = equivalence_class;
@@ -2153,10 +2159,12 @@ perform_var_substitution (constraint_gra
   struct scc_info *si = init_scc_info (size);
 
   bitmap_obstack_initialize (iteration_obstack);
+  gcc_obstack_init (equiv_class_obstack);
+  /* NULL free function, we'll free the whole pool at the end of the pass. */
   pointer_equiv_class_table = htab_create (511, equiv_class_label_hash,
-  equiv_class_label_eq, free);
+  equiv_class_label_eq, NULL);
   location_equiv_class_table = htab_create (511, equiv_class_label_hash,
-   equiv_class_label_eq, free);
+   equiv_class_label_eq, NULL);
   pointer_equiv_class = 1;
   location_equiv_class = 1;
 
@@ -2263,6 +2271,7 @@ free_var_substitution_info (struct scc_i
   sbitmap_free (graph-direct_nodes);
   htab_delete (pointer_equiv_class_table);
   htab_delete (location_equiv_class_table);
+  obstack_free (equiv_class_obstack, NULL);
   bitmap_obstack_release (iteration_obstack);
 }
 
@@ -2741,7 +2750,7 @@ new_scalar_tmp_constraint_exp (const cha
If address_p is true, the result will be taken its address of.  */
 
 static 

alloc_pool for tree-ssa-pre.c:phi_translate_table

2012-08-19 Thread Dimitrios Apostolou



2012-08-19  Dimitrios Apostolou  ji...@gmx.net

* gcc/tree-ssa-pre.c (phi_translate_pool): New static global
alloc_pool, used for allocating struct expr_pred_trans_d for
phi_translate_table.
(phi_trans_add, init_pre, fini_pre): Use it, avoids thousand of
malloc() and free() calls.


This avoids lots of malloc/free calls and slow iterations during numerous 
htab_delete() in fini_pre(). Tested on pre C++-snapshot, will update info 
as soon as a post C++ one is available.



Thanks,
Dimitris2012-08-19  Dimitrios Apostolou  ji...@gmx.net

* gcc/tree-ssa-pre.c (phi_translate_pool): New static global
alloc_pool, used for allocating struct expr_pred_trans_d for
phi_translate_table.
(phi_trans_add, init_pre, fini_pre): Use it, avoids thousand of
malloc() and free() calls.

=== modified file 'gcc/tree-ssa-pre.c'
--- gcc/tree-ssa-pre.c  2012-08-17 08:03:54 +
+++ gcc/tree-ssa-pre.c  2012-08-18 16:43:02 +
@@ -486,7 +486,7 @@ static bitmap need_ab_cleanup;
 /* A three tuple {e, pred, v} used to cache phi translations in the
phi_translate_table.  */
 
-typedef struct expr_pred_trans_d : typed_free_removeexpr_pred_trans_d
+typedef struct expr_pred_trans_d : typed_noop_removeexpr_pred_trans_d
 {
   /* The expression.  */
   pre_expr e;
@@ -508,6 +508,12 @@ typedef struct expr_pred_trans_d : typed
 } *expr_pred_trans_t;
 typedef const struct expr_pred_trans_d *const_expr_pred_trans_t;
 
+/* Pool of memory for the above */
+
+static alloc_pool phi_translate_pool;
+
+/* Return the hash value for a phi translation table entry.  */
+
 inline hashval_t
 expr_pred_trans_d::hash (const expr_pred_trans_d *e)
 {
@@ -561,7 +567,8 @@ static inline void
 phi_trans_add (pre_expr e, pre_expr v, basic_block pred)
 {
   expr_pred_trans_t *slot;
-  expr_pred_trans_t new_pair = XNEW (struct expr_pred_trans_d);
+  expr_pred_trans_t new_pair =
+(expr_pred_trans_t) pool_alloc (phi_translate_pool);
   new_pair-e = e;
   new_pair-pred = pred;
   new_pair-v = v;
@@ -570,7 +577,8 @@ phi_trans_add (pre_expr e, pre_expr v, b
 
   slot = phi_translate_table.find_slot_with_hash (new_pair,
   new_pair-hashcode, INSERT);
-  free (*slot);
+  if (*slot)
+pool_free (phi_translate_pool, *slot);
   *slot = new_pair;
 }
 
@@ -4798,6 +4806,9 @@ init_pre (bool do_fre)
   calculate_dominance_info (CDI_DOMINATORS);
 
   bitmap_obstack_initialize (grand_bitmap_obstack);
+  phi_translate_pool = create_alloc_pool (phi_translate_table,
+ sizeof (struct expr_pred_trans_d),
+ 512);
   phi_translate_table.create (5110);
   expression_to_id.create (num_ssa_names * 3);
   bitmap_set_pool = create_alloc_pool (Bitmap sets,
@@ -4832,6 +4843,7 @@ fini_pre (bool do_fre)
   free_alloc_pool (bitmap_set_pool);
   free_alloc_pool (pre_expr_pool);
   phi_translate_table.dispose ();
+  free_alloc_pool (phi_translate_pool);
   expression_to_id.dispose ();
   VEC_free (unsigned, heap, name_to_id);
 



enlarge hot allocation pools

2012-08-19 Thread Dimitrios Apostolou

Hello,

2012-08-19  Dimitrios Apostolou  ji...@gmx.net

* gcc/cselib.c (cselib_init): Make allocation pools larger since
they are too hot and show to expand often on the profiler.
* gcc/df-problems.c (df_chain_alloc): Same.
* gcc/et-forest.c (et_new_occ, et_new_tree): Same.
* gcc/tree-ssa-pre.c (init_pre): Same


These allocation pools are the ones that I've noticed calling malloc() too 
often, for expanding their size. Also I don't like the way the pools are 
created in et_new_{occ,tree}() but couldn't find a single point to move 
the initialisation either. Any ideas on this one?



Thanks,
Dimitris2012-08-19  Dimitrios Apostolou  ji...@gmx.net

* gcc/cselib.c (cselib_init): Make allocation pools larger since
they are too hot and show to expand often on the profiler.
* gcc/df-problems.c (df_chain_alloc): Same.
* gcc/et-forest.c (et_new_occ, et_new_tree): Same.
* gcc/tree-ssa-pre.c (init_pre): Same


=== modified file 'gcc/cselib.c'
--- gcc/cselib.c2012-08-02 22:39:57 +
+++ gcc/cselib.c2012-08-19 15:13:28 +
@@ -2659,12 +2659,12 @@ void
 cselib_init (int record_what)
 {
   elt_list_pool = create_alloc_pool (elt_list,
-sizeof (struct elt_list), 10);
+sizeof (struct elt_list), 128);
   elt_loc_list_pool = create_alloc_pool (elt_loc_list,
-sizeof (struct elt_loc_list), 10);
+sizeof (struct elt_loc_list), 128);
   cselib_val_pool = create_alloc_pool (cselib_val_list,
-  sizeof (cselib_val), 10);
-  value_pool = create_alloc_pool (value, RTX_CODE_SIZE (VALUE), 100);
+  sizeof (cselib_val), 128);
+  value_pool = create_alloc_pool (value, RTX_CODE_SIZE (VALUE), 128);
   cselib_record_memory = record_what  CSELIB_RECORD_MEMORY;
   cselib_preserve_constants = record_what  CSELIB_PRESERVE_CONSTANTS;
   cselib_any_perm_equivs = false;

=== modified file 'gcc/df-problems.c'
--- gcc/df-problems.c   2012-08-17 09:42:06 +
+++ gcc/df-problems.c   2012-08-19 15:29:37 +
@@ -1993,7 +1993,7 @@ df_chain_alloc (bitmap all_blocks ATTRIB
 {
   df_chain_remove_problem ();
   df_chain-block_pool = create_alloc_pool (df_chain_block pool,
-sizeof (struct df_link), 50);
+sizeof (struct df_link), 128);
   df_chain-optional_p = true;
 }
 

=== modified file 'gcc/et-forest.c'
--- gcc/et-forest.c 2012-05-31 16:43:31 +
+++ gcc/et-forest.c 2012-08-19 15:50:25 +
@@ -444,8 +444,8 @@ et_new_occ (struct et_node *node)
 {
   struct et_occ *nw;
 
-  if (!et_occurrences)
-et_occurrences = create_alloc_pool (et_occ pool, sizeof (struct et_occ), 
300);
+  if (!et_occurrences)
+et_occurrences = create_alloc_pool (et_occ pool, sizeof (struct et_occ), 
1024);
   nw = (struct et_occ *) pool_alloc (et_occurrences);
 
   nw-of = node;
@@ -467,8 +467,8 @@ et_new_tree (void *data)
 {
   struct et_node *nw;
 
-  if (!et_nodes)
-et_nodes = create_alloc_pool (et_node pool, sizeof (struct et_node), 
300);
+  if (!et_nodes)
+et_nodes = create_alloc_pool (et_node pool, sizeof (struct et_node), 
512);
   nw = (struct et_node *) pool_alloc (et_nodes);
 
   nw-data = data;

=== modified file 'gcc/tree-ssa-pre.c'
--- gcc/tree-ssa-pre.c  2012-08-18 06:31:26 +
+++ gcc/tree-ssa-pre.c  2012-08-19 15:28:21 +
@@ -4812,9 +4812,9 @@ init_pre (bool do_fre)
   phi_translate_table.create (5110);
   expression_to_id.create (num_ssa_names * 3);
   bitmap_set_pool = create_alloc_pool (Bitmap sets,
-  sizeof (struct bitmap_set), 30);
+  sizeof (struct bitmap_set), 128);
   pre_expr_pool = create_alloc_pool (pre_expr nodes,
-sizeof (struct pre_expr_d), 30);
+sizeof (struct pre_expr_d), 32);
   FOR_ALL_BB (bb)
 {
   EXP_GEN (bb) = bitmap_set_new ();



Re: CXX conversion: min g++ version pre-requisite?

2012-08-19 Thread Gary Funck
I filed two bug reports:

GCC install document does not list minimum required g++ version
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54324

GCC does not build with G++ version 3.4.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54326

Re: the latter bug report (54326), it might be further
divided into two bug reports: one documenting the failure
to build with g++ 3.4.0 and the other having to do with
the use of casts in genoutput.c.  Let me know if you
recommend that I separate the bug reports.

- Gary


Re: [PATCH][RFC] Extend memset recognition

2012-08-19 Thread H.J. Lu
On Tue, Jun 5, 2012 at 2:21 AM, Richard Guenther rguent...@suse.de wrote:
 On Thu, 31 May 2012, Richard Guenther wrote:

 On Wed, 30 May 2012, Richard Guenther wrote:

 
  The patch below extents memset recognition to cover a few more
  non-byte-size store loops and all byte-size store loops.  This exposes
  issues with our builtins.exp testsuite which has custom memset
  routines like
 
  void *
  my_memset (void *d, int c, size_t n)
  {
char *dst = (char *) d;
while (n--)
  *dst++ = c;
return (char *) d;
  }
 
  Now, for LTO we have papered over similar issues by attaching
  the used attribute to the functions.  But the general question is - when
  can we be sure the function we are dealing with are not the actual
  implementation for the builtin call we want to generate?  A few
  things come to my mind:
 
   1) the function already calls the function we want to generate (well,
  it might be a tail-recursive memset implementation ...)
 
   2) the function availability is AVAIL_LOCAL
 
   3) ... ?
 
  For sure 2) would work, but it would severely restrict the transform
  (do we care?).
 
  We have a similar issue with sin/cos - sincos transform and a
  trivial sincos implementation.
 
  Any ideas?
 
  Bootstrapped (with memset recognition enabled by default) and tested
  on x86_64-unknown-linux-gnu with the aforementioned issues.

 The following fixes it by simply always adding
 -fno-tree-loop-distribute-patterns to builtins.exp.

 Bootstrapped and tested on x86_64-unknown-linux-gnu.

 If there are no further comments I'll go with the local advise from
 Micha who says who cares.

 Now done with the much simpler patch below (after all the loop
 distribution TLC).

 Bootstrapped and tested on x86_64-unknown-linux-gnu, applied.

 Richard.

 2012-06-05  Richard Guenther  rguent...@suse.de

 PR tree-optimization/53081
 * tree-loop-distribution.c (generate_memset_builtin): Handle all
 kinds of byte-sized stores.
 (classify_partition): Likewise.
 (tree_loop_distribution): Adjust seed statements used for
 !flag_tree_loop_distribution.

 * gcc.dg/tree-ssa/ldist-19.c: New testcase.
 * gcc.c-torture/execute/builtins/builtins.exp: Always pass
 -fno-tree-loop-distribute-patterns.


This caused:

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


-- 
H.J.


Re: [PATCH, Committed] Fix ChangeLog (was: [PATCH] Fix AVR fallout)

2012-08-19 Thread Ian Lance Taylor
On Sun, Aug 19, 2012 at 1:34 AM, Jan-Benedict Glaw jbg...@lug-owl.de wrote:

 I fixed ChangeLog's whitespace (probably cut'n'paste error), committed
 as obvious.

 2012-08-19  Jan-Benedict Glaw  jbg...@lug-owl.de

 * ChangeLog: Fix whitespace.

Note that fixes to the ChangeLog files do not themselves get ChangeLog entries.

Ian


Re: [PATCH, Committed] Fix ChangeLog (was: [PATCH] Fix AVR fallout)

2012-08-19 Thread Jan-Benedict Glaw
On Sun, 2012-08-19 11:58:49 -0700, Ian Lance Taylor i...@google.com wrote:
 On Sun, Aug 19, 2012 at 1:34 AM, Jan-Benedict Glaw jbg...@lug-owl.de wrote:
  I fixed ChangeLog's whitespace (probably cut'n'paste error), committed
  as obvious.
 
  2012-08-19  Jan-Benedict Glaw  jbg...@lug-owl.de
 
  * ChangeLog: Fix whitespace.
 
 Note that fixes to the ChangeLog files do not themselves get
 ChangeLog entries.

Fixed.

Thanks for the notice, JBG

-- 
  Jan-Benedict Glaw  jbg...@lug-owl.de  +49-172-7608481
 Signature of:  http://perl.plover.com/Questions.html
 the second  :


signature.asc
Description: Digital signature


Re: [Patch, Fortran] PR54301 - add warning for pointer might outlive its target

2012-08-19 Thread Thomas Koenig

Hi Tobias,


Build and regtested on x86-64-gnu-linux.
OK for the trunk?


I would exclude pointers on the lhs of the pointer assignment, to make
sure that warnings for code such as

program main
  integer :: i
  integer, pointer :: ip
  block
integer, pointer :: jp
allocate (jp)
jp = 3
ip = jp
  end block
  i = ip
  print *,i
end program main

are not emitted.

Thomas


Re: [Patch, Fortran] PR54301 - add warning for pointer might outlive its target

2012-08-19 Thread Tobias Burnus

Am 19.08.2012 21:19, schrieb Thomas Koenig:

Build and regtested on x86-64-gnu-linux.
OK for the trunk?


I would exclude pointers on the lhs of the pointer assignment,


I assume you mean RHS – excluding LHS pointers in pointer assignments is 
kind of difficult ;-)


RHS pointers are excluded via:

+ if (gfc_option.warn_target_lifetime
+  rvalue-expr_type == EXPR_VARIABLE
+  !rvalue-symtree-n.sym-attr.save
+  !attr.pointer  !rvalue-symtree-n.sym-attr.host_assoc

the attr is set via:
attr = gfc_expr_attr (rvalue);


to make sure that warnings for code such as
are not emitted.


There is no warning with the patch.

Tobias


Re: [wwwdocs] SH 4.8 changes update

2012-08-19 Thread Gerald Pfeifer
On Sun, 19 Aug 2012, Oleg Endo wrote:
 Thanks.  Let's hope that I can squeeze in some more stuff while
 stage 1 lasts. :T

You know that for backend-specific changes (especially for smaller
ports) you actually have some more leeway?

 But now that you mention it, maybe it would be better to rename the
 '-menable-tas' option to '-mtas', since other instruction related
 options do not have 'enabled' in the name.

Now still would be time to do so without worrying about compatibility. ;-)

 OK to install?

Oh, yes.  Thanks!

Gerald


Re: enlarge hot allocation pools

2012-08-19 Thread Steven Bosscher
On Sun, Aug 19, 2012 at 8:31 PM, Dimitrios Apostolou ji...@gmx.net wrote:
 Hello,

 2012-08-19  Dimitrios Apostolou  ji...@gmx.net

 * gcc/cselib.c (cselib_init): Make allocation pools larger since
 they are too hot and show to expand often on the profiler.
 * gcc/df-problems.c (df_chain_alloc): Same.
 * gcc/et-forest.c (et_new_occ, et_new_tree): Same.
 * gcc/tree-ssa-pre.c (init_pre): Same


 These allocation pools are the ones that I've noticed calling malloc() too
 often, for expanding their size.

I don't like the way these pools are sized with a seemingly arbitrary
initial size. They're there to hold something, and they grow because
there are more somethings than initially guessed. I think you should
look at what the pools hold and choose an initial size based on some
representative measure. E.g. if a pool holds some kind of expressions,
then you should be able to make an initial guess of the size of the
pool based on the number of pseudos or ssa names. Ideally you'd simply
derive the initial pool size by a regression analysis of the final
pool size and some potential representative measures (# of regs, basic
blocks, edges, whatever).


 Also I don't like the way the pools are
 created in et_new_{occ,tree}() but couldn't find a single point to move the
 initialisation either. Any ideas on this one?

Just create a new function to initialize (destroy) the pools and call
it from calculate_dominance_info (free_dominance_info).

Ciao!
Steven


Re: [Patch, Fortran] PR54301 - add warning for pointer might outlive its target

2012-08-19 Thread Thomas Koenig

Hi Tobias,


Am 19.08.2012 21:19, schrieb Thomas Koenig:

Build and regtested on x86-64-gnu-linux.
OK for the trunk?


I would exclude pointers on the lhs of the pointer assignment,


I assume you mean RHS – excluding LHS pointers in pointer assignments is
kind of difficult ;-)


Sometimes I have a weak right-left weakness :-)


RHS pointers are excluded via:


...


There is no warning with the patch.


OK for trunk then.  You'll find your patch no longer applies
cleanly, because I have changed the same spot(s) in invoke.texi
and gfortran.h with my recent commit, but I think you'll manage :-)

Thomas



[SH] PR 51244 - Use more zero displacement branches

2012-08-19 Thread Oleg Endo
Hello,

This adds two new patterns to undo an optimization that is done by ifcvt
and is not beneficial if zero displacement branches are available on SH.
Tested on rev 190459 with
make -k check RUNTESTFLAGS=--target_board=sh-sim
\{-m2/-ml,-m2/-mb,-m2a/-mb,-m4/-ml,-m4/-mb,-m4a/-ml,-m4a/-mb}

and no new failures.
OK?

Cheers,
Oleg

ChangeLog:

PR target/51244
* config/sh/sh.md (*cset_zero): New insns.

testsuite/ChangeLog:

PR target/51244
* gcc.target/sh/pr51244-11.c: New.
Index: gcc/config/sh/sh.md
===
--- gcc/config/sh/sh.md	(revision 190459)
+++ gcc/config/sh/sh.md	(working copy)
@@ -10409,6 +10409,41 @@
   operands[0] = gen_reg_rtx (SImode);
 })
 
+;; The *cset_zero patterns convert optimizations such as
+;;	if (test) x = 0; to x = -(test == 0);
+;; back to conditional branch sequences if zero-displacement branches
+;; are enabled.
+;; FIXME: These patterns can be removed when conditional execution patterns
+;; are implemented, since ifcvt will not perform these optimizations if
+;; conditional execution is supported.
+(define_insn *cset_zero
+  [(set (match_operand:SI 0 arith_reg_dest =r)
+	(and:SI (plus:SI (match_operand:SI 1 t_reg_operand)
+			 (const_int -1))
+		(match_operand:SI 2 arith_reg_operand 0)))]
+  TARGET_SH1  TARGET_ZDCBRANCH
+{
+  return   bf	0f	\n
+	 	mov	#0,%0	\n
+	 0:;
+}
+  [(set_attr type arith) ;; poor approximation
+   (set_attr length 4)])
+
+(define_insn *cset_zero
+  [(set (match_operand:SI 0 arith_reg_dest =r)
+	(if_then_else:SI (match_operand:SI 1 t_reg_operand)
+			 (match_operand:SI 2 arith_reg_operand 0)
+			 (const_int 0)))]
+  TARGET_SH1  TARGET_ZDCBRANCH
+{
+  return   bt	0f	\n
+	 	mov	#0,%0	\n
+	 0:;
+}
+  [(set_attr type arith) ;; poor approximation
+   (set_attr length 4)])
+
 (define_expand cstoresf4
   [(set (match_operand:SI 0 register_operand =r)
 	(match_operator:SI 1 sh_float_comparison_operator
Index: gcc/testsuite/gcc.target/sh/pr51244-11.c
===
--- gcc/testsuite/gcc.target/sh/pr51244-11.c	(revision 0)
+++ gcc/testsuite/gcc.target/sh/pr51244-11.c	(revision 0)
@@ -0,0 +1,24 @@
+/* Check that zero-displacement branches are used instead of branch-free
+   execution patterns.  */
+/* { dg-do compile { target sh*-*-* } } */
+/* { dg-options -O1 -mzdcbranch } */
+/* { dg-skip-if  { sh*-*-* } { -m5* } {  } } */
+/* { dg-final { scan-assembler-not subc|and } } */
+
+int*
+test_00 (int* s)
+{
+  if (s[0] == 0)
+if (!s[3])
+  s = 0;
+  return s;
+}
+
+int*
+test_01 (int* s)
+{
+  if (s[0] == 0)
+if (s[3])
+  s = 0;
+  return s;
+}


[SH] PR 54089 - Add support for rotcr insn

2012-08-19 Thread Oleg Endo
Hello,

This adds support for SH's rotcr insn.
Tested on rev 190459 with
make -k check RUNTESTFLAGS=--target_board=sh-sim
\{-m2/-ml,-m2/-mb,-m2a/-mb,-m4/-ml,-m4/-mb,-m4a/-ml,-m4a/-mb}

and no new failures.
OK?

Cheers,
Oleg

ChangeLog:

PR target/50489
* config/sh/sh.md (rotcr, *rotcr, shar, shlr): New insns and 
splits.
(ashrdi3_k, lshrdi3_k): Rewrite as insn_and_split.
* config/sh/sh.c (sh_lshrsi_clobbers_t_reg_p): New function.
* config/sh/sh-protos.h (sh_lshrsi_clobbers_t_reg_p): Declare 
it.

testsuite/ChangeLog:

PR target/50489
* gcc.target/sh/pr54089-1.c: New.

Index: gcc/config/sh/sh.md
===
--- gcc/config/sh/sh.md	(revision 190459)
+++ gcc/config/sh/sh.md	(working copy)
@@ -3827,6 +3827,100 @@
 FAIL;
 })
 
+;; The rotcr insn is used primarily in DImode right shifts (arithmetic
+;; and logical).  It can also be used to implement things like
+;;	bool t = a == b;
+;;	int x = (y  1) | (t  31);
+(define_insn rotcr
+  [(set (match_operand:SI 0 arith_reg_dest =r)
+	(ior:SI (lshiftrt:SI (match_operand:SI 1 arith_reg_operand 0)
+			 (const_int 1))
+		(ashift:SI (match_operand:SI 2 t_reg_operand)
+			   (const_int 31
+   (set (reg:SI T_REG)
+	(and:SI (match_dup 1) (const_int 1)))]
+  TARGET_SH1
+  rotcr	%0
+  [(set_attr type arith)])
+
+;; Simplified rotcr version for combine, which allows arbitrary shift
+;; amounts for the reg.  If the shift amount is '1' rotcr can be used
+;; directly.  Otherwise we have to insert a shift in between.
+(define_insn_and_split *rotcr
+  [(set (match_operand:SI 0 arith_reg_dest)
+	(ior:SI (lshiftrt:SI (match_operand:SI 1 arith_reg_operand)
+			 (match_operand:SI 2 const_int_operand))
+		(ashift:SI (match_operand:SI 3 t_reg_operand)
+			   (const_int 31
+   (clobber (reg:SI T_REG))]
+  TARGET_SH1
+  #
+   can_create_pseudo_p ()
+  [(const_int 0)]
+{
+  if (INTVAL (operands[2])  1)
+{
+  /* use plus_constant function ?? */
+  const int shift_count = INTVAL (operands[2]) - 1;
+  const rtx shift_count_rtx = GEN_INT (shift_count);
+  rtx shift_res = gen_reg_rtx (SImode);
+
+  rtx prev_set_t_insn = NULL_RTX;
+  rtx tmp_t_reg = NULL_RTX;
+
+  /* If we're going to emit a shift sequence that clobbers the T_REG,
+	 try to find the previous insn that sets the T_REG and emit the 
+	 shift insn before that insn, to remove the T_REG dependency.
+	 If the insn that sets the T_REG cannot be found, store the T_REG
+	 in a temporary reg and restore it after the shift.  */
+  if (sh_lshrsi_clobbers_t_reg_p (shift_count_rtx)
+	   ! sh_dynamicalize_shift_p (shift_count_rtx))
+	{
+	  prev_set_t_insn = prev_nonnote_insn_bb (curr_insn);
+	  if (! (prev_set_t_insn != NULL_RTX
+		  reg_set_p (get_t_reg_rtx (), prev_set_t_insn)
+		  ! reg_referenced_p (get_t_reg_rtx (),
+	PATTERN (prev_set_t_insn
+	{
+	  prev_set_t_insn = NULL_RTX;
+	  tmp_t_reg = gen_reg_rtx (SImode);
+	  emit_insn (gen_move_insn (tmp_t_reg, get_t_reg_rtx ()));
+	} 
+	}
+
+  rtx shift_rtx = gen_lshrsi3 (shift_res, operands[1], shift_count_rtx);
+  operands[1] = shift_res;
+
+  /* Emit the shift insn before the insn that sets T_REG, if possible.  */
+  if (prev_set_t_insn != NULL_RTX)
+	emit_insn_before (shift_rtx, prev_set_t_insn);
+  else
+	emit_insn (shift_rtx);
+
+  /* Restore T_REG if it has been saved before.  */
+  if (tmp_t_reg != NULL_RTX)
+	emit_insn (gen_cmpgtsi_t (tmp_t_reg, const0_rtx));
+}
+
+  emit_insn (gen_rotcr (operands[0], operands[1], operands[3]));
+  DONE;
+})
+
+;; rotcr combine bridge pattern which will make combine try out more
+;; complex patterns.
+(define_insn_and_split *rotcr
+  [(set (match_operand:SI 0 arith_reg_dest)
+	(ashift:SI (match_operand:SI 1 t_reg_operand) (const_int 31)))]
+  TARGET_SH1
+  #
+   1
+  [(set (match_dup 0) (match_dup 1))
+   (parallel [(set (match_dup 0)
+		   (ior:SI (lshiftrt:SI (match_dup 0) (const_int 1))
+			   (ashift:SI (match_dup 1) (const_int 31
+	  (set (reg:SI T_REG)
+		   (and:SI (match_dup 0) (const_int 1)))])])
+
 ;; . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
 ;; SImode shift left
 
@@ -4146,6 +4240,16 @@
 FAIL;
 })
 
+(define_insn shar
+  [(set (match_operand:SI 0 arith_reg_dest =r)
+	(ashiftrt:SI (match_operand:SI 1 arith_reg_operand 0)
+		 (const_int 1)))
+   (set (reg:SI T_REG)
+	(and:SI (match_dup 1) (const_int 1)))]
+  TARGET_SH1
+  shar	%0
+  [(set_attr type arith)])
+
 (define_insn ashrsi3_k
   [(set (match_operand:SI 0 arith_reg_dest =r)
 	(ashiftrt:SI (match_operand:SI 1 arith_reg_operand 0)
@@ -4233,16 +4337,22 @@
 FAIL;
 })
 
-;; This should be a define_insn_and_split
-(define_insn ashrdi3_k
+(define_insn_and_split ashrdi3_k
   [(set (match_operand:DI 0 arith_reg_dest =r)
 	(ashiftrt:DI (match_operand:DI 1 arith_reg_operand 0)
 		   

Re: [PATCH][3/n] into-SSA TLC

2012-08-19 Thread H.J. Lu
On Fri, Jul 27, 2012 at 5:16 AM, Richard Guenther rguent...@suse.de wrote:

 This tries to more clearly separate per-SSA name held information
 from per-DECL held information during update-ssa.  We already have
 a global array of SSA name informations so it is pointless to
 have a hashtable mapping SSA names to yet another piece of information
 (a bitmap).  This patch simply puts the bitmap into that SSA name
 auxiliar vector.  Lifetime is managed by using a separate obstack
 and the aux vector age.

 Bootstrap and regtest pending on x86_64-unknown-linux-gnu.

 Richard.

 2012-07-27  Richard Guenther  rguent...@suse.de

 * tree-cfg.c (gimple_can_merge_blocks_p): Do more fine-grained
 check whether SSA form is not up-to-date.
 * tree-flow.h (name_mappings_registered_p): Remove.
 * tree-into-ssa.c (struct repl_map_d): Remove.
 (repl_tbl): Likewise.
 (struct ssa_name_info): Add repl_set member.
 (update_ssa_obstack): New static global.
 (get_ssa_name_ann): Initialize repl_set.
 (clear_ssa_name_info): Assert age did not wrap.
 (repl_map_hash, repl_map_eq, repl_map_free): Remove.
 (names_replaced_by): Adjust.
 (add_to_repl_tbl): Likewise.
 (dump_tree_ssa_stats): Likewise.
 (init_update_ssa): Initialize update_ssa_obstack.
 (delete_update_ssa): Free update_ssa_obstack.
 (name_mappings_registered_p): Remove.
 (update_ssa): Adjust.


This caused:

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


-- 
H.J.


Re: [wwwdocs] SH 4.8 changes update

2012-08-19 Thread Oleg Endo
On Sun, 2012-08-19 at 21:43 +0200, Gerald Pfeifer wrote:
 On Sun, 19 Aug 2012, Oleg Endo wrote:
  Thanks.  Let's hope that I can squeeze in some more stuff while
  stage 1 lasts. :T
 
 You know that for backend-specific changes (especially for smaller
 ports) you actually have some more leeway?

You mean, since SH is neither a primary nor a secondary platform, there
are no particular release criteria for it?  What does that actually
mean?

  But now that you mention it, maybe it would be better to rename the
  '-menable-tas' option to '-mtas', since other instruction related
  options do not have 'enabled' in the name.
 
 Now still would be time to do so without worrying about compatibility. ;-)

True.

Cheers,
Oleg



Re: [PATCH] Combine location with block using block_locations

2012-08-19 Thread Dehao Chen
ping

Thanks,
Dehao

On Tue, Aug 14, 2012 at 10:13 AM, Dehao Chen de...@google.com wrote:
 Hi, Dodji,

 Thanks for the review. I've fixed all the addressed issues. I'm
 attaching the related changes:

 Thanks,
 Dehao

 libcpp/ChangeLog:
 2012-08-01  Dehao Chen  de...@google.com

 * include/line-map.h (MAX_SOURCE_LOCATION): New value.
 (location_adhoc_data_init): New.
 (location_adhoc_data_fini): New.
 (get_combined_adhoc_loc): New.
 (get_data_from_adhoc_loc): New.
 (get_location_from_adhoc_loc): New.
 (COMBINE_LOCATION_DATA): New.
 (IS_ADHOC_LOC): New.
 (expanded_location): New field.
 * line-map.c (location_adhoc_data): New.
 (location_adhoc_data_htab): New.
 (curr_adhoc_loc): New.
 (location_adhoc_data): New.
 (allocated_location_adhoc_data): New.
 (location_adhoc_data_hash): New.
 (location_adhoc_data_eq): New.
 (location_adhoc_data_update): New.
 (get_combined_adhoc_loc): New.
 (get_data_from_adhoc_loc): New.
 (get_location_from_adhoc_loc): New.
 (location_adhoc_data_init): New.
 (location_adhoc_data_fini): New.
 (linemap_lookup): Change to use new location.
 (linemap_ordinary_map_lookup): Likewise.
 (linemap_macro_map_lookup): Likewise.
 (linemap_macro_map_loc_to_def_point): Likewise.
 (linemap_macro_map_loc_unwind_toward_spel): Likewise.
 (linemap_get_expansion_line): Likewise.
 (linemap_get_expansion_filename): Likewise.
 (linemap_location_in_system_header_p): Likewise.
 (linemap_location_from_macro_expansion_p): Likewise.
 (linemap_macro_loc_to_spelling_point): Likewise.
 (linemap_macro_loc_to_def_point): Likewise.
 (linemap_macro_loc_to_exp_point): Likewise.
 (linemap_resolve_location): Likewise.
 (linemap_unwind_toward_expansion): Likewise.
 (linemap_unwind_to_first_non_reserved_loc): Likewise.
 (linemap_expand_location): Likewise.
 (linemap_dump_location): Likewise.

 Index: libcpp/line-map.c
 ===
 --- libcpp/line-map.c   (revision 190209)
 +++ libcpp/line-map.c   (working copy)
 @@ -25,6 +25,7 @@
  #include line-map.h
  #include cpplib.h
  #include internal.h
 +#include hashtab.h

  static void trace_include (const struct line_maps *, const struct line_map 
 *);
  static const struct line_map * linemap_ordinary_map_lookup (struct line_maps 
 *,
 @@ -50,6 +51,135 @@
  extern unsigned num_expanded_macros_counter;
  extern unsigned num_macro_tokens_counter;

 +/* Data structure to associate an arbitrary data to a source location.  */
 +struct location_adhoc_data {
 +  source_location locus;
 +  void *data;
 +};
 +
 +/* The following data structure encodes a location with some adhoc data
 +   and maps it to a new unsigned integer (called an adhoc location)
 +   that replaces the original location to represent the mapping.
 +
 +   The new adhoc_loc uses the highest bit as the enabling bit, i.e. if the
 +   highest bit is 1, then the number is adhoc_loc. Otherwise, it serves as
 +   the original location. Once identified as the adhoc_loc, the lower 31
 +   bits of the integer is used to index the location_adhoc_data array,
 +   in which the locus and associated data is stored.  */
 +
 +static htab_t location_adhoc_data_htab;
 +static source_location curr_adhoc_loc;
 +static struct location_adhoc_data *location_adhoc_data;
 +static unsigned int allocated_location_adhoc_data;
 +
 +/* Hash function for location_adhoc_data hashtable.  */
 +
 +static hashval_t
 +location_adhoc_data_hash (const void *l)
 +{
 +  const struct location_adhoc_data *lb =
 +  (const struct location_adhoc_data *) l;
 +  return (hashval_t) lb-locus + (size_t) lb-data;
 +}
 +
 +/* Compare function for location_adhoc_data hashtable.  */
 +
 +static int
 +location_adhoc_data_eq (const void *l1, const void *l2)
 +{
 +  const struct location_adhoc_data *lb1 =
 +  (const struct location_adhoc_data *) l1;
 +  const struct location_adhoc_data *lb2 =
 +  (const struct location_adhoc_data *) l2;
 +  return lb1-locus == lb2-locus  lb1-data == lb2-data;
 +}
 +
 +/* Update the hashtable when location_adhoc_data is reallocated.  */
 +
 +static int
 +location_adhoc_data_update (void **slot, void *data)
 +{
 +  *((char **) slot) += ((char *) location_adhoc_data - (char *) data);
 +  return 1;
 +}
 +
 +/* Combine LOCUS and DATA to a combined adhoc loc.  */
 +
 +source_location
 +get_combined_adhoc_loc (source_location locus, void *data)
 +{
 +  struct location_adhoc_data lb;
 +  struct location_adhoc_data **slot;
 +
 +  linemap_assert (data);
 +
 +  if (IS_ADHOC_LOC (locus))
 +locus = location_adhoc_data[locus  MAX_SOURCE_LOCATION].locus;
 +  if (locus == 0  data == NULL)
 +return 0;
 +  lb.locus = locus;
 +  lb.data = data;
 +  slot = (struct 

Re: enlarge hot allocation pools

2012-08-19 Thread Dimitrios Apostolou

Hi Steven,

On Sun, 19 Aug 2012, Steven Bosscher wrote:

On Sun, Aug 19, 2012 at 8:31 PM, Dimitrios Apostolou ji...@gmx.net wrote:

Hello,

2012-08-19  Dimitrios Apostolou  ji...@gmx.net

* gcc/cselib.c (cselib_init): Make allocation pools larger since
they are too hot and show to expand often on the profiler.
* gcc/df-problems.c (df_chain_alloc): Same.
* gcc/et-forest.c (et_new_occ, et_new_tree): Same.
* gcc/tree-ssa-pre.c (init_pre): Same


These allocation pools are the ones that I've noticed calling malloc() too
often, for expanding their size.


I don't like the way these pools are sized with a seemingly arbitrary
initial size. They're there to hold something, and they grow because
there are more somethings than initially guessed. I think you should
look at what the pools hold and choose an initial size based on some
representative measure. E.g. if a pool holds some kind of expressions,
then you should be able to make an initial guess of the size of the
pool based on the number of pseudos or ssa names. Ideally you'd simply
derive the initial pool size by a regression analysis of the final
pool size and some potential representative measures (# of regs, basic
blocks, edges, whatever).


Some time ago I tried changing the pool allocator growth strategy from 
linear to exponential, doubling the size of the pool chunk every time it 
needed another chunk. It was for the exact same reason, to set the pool 
size according to their contents. Unfortunately I remember it didn't make 
a difference so I dumped it and only manually changed the important pools, 
which made a small difference. I'll now try deducing information on the 
size at runtime, thanks for the tip.



Dimitris



Re: [PATCH] Fix PR 52631 (VN does not use simplified expression for lookup)

2012-08-19 Thread Andrew Pinski
On Wed, Jul 25, 2012 at 4:39 AM, Richard Guenther
richard.guent...@gmail.com wrote:
 On Tue, Jul 24, 2012 at 5:50 PM, Andrew Pinski
 andrew.pin...@caviumnetworks.com wrote:
 Hi,
   Before tuples was introduced, VN used to lookup the simplified
 expression to see if it was available already and use that instead of
 the non simplified one.  This patch adds the support back to VN to do
 exactly that.

 OK? Bootstrapped and tested on x86_64-linux-gnu with no regressions.

 I think this should be done for all RHS and SSA name LHS, not only
 for UNARY/BINARY/TERNARY - because even for SINGLE rhs we
 can end up simplifying (for REALPART_EXPR for example which we
 handle as nary, too).  I think we constrain try_to_simplify enough
 so that

 + /* First try to lookup the simplified expression. */
 + if (simplified  valid_gimple_rhs_p (simplified))
 +   {
 + tree result = vn_nary_op_lookup (simplified, NULL);
 + if (result)
 +   {
 + changed = set_ssa_val_to (lhs, result);
 + goto done;
 +   }
 + changed = set_ssa_val_to (lhs, lhs);
 + vn_nary_op_insert (simplified, lhs);
 +   }
   switch (get_gimple_rhs_class (code))
 {
 case GIMPLE_UNARY_RHS:
 case GIMPLE_BINARY_RHS:
 ...

 should work.  As you also insert the simplified variant I think we really
 (finally) want to have a valid_nary_op routine rather than relying on
 valid_gimple_rhs_p which is way too generic.

I don't see valid_gimple_rhs_p being that generic as it checks to make
sure the operands of the gimple are valid.
Maybe I am missing something here though.

Thanks,
Andrew Pinski



 Thanks,
 Richard.

 Thanks,
 Andrew Pinski

 ChangeLog:

 * tree-ssa-sccvn.c (visit_use): Look up the simplified
 expression before visting the original one.

 * gcc.dg/tree-ssa/ssa-fre-9.c: Update the number of
 eliminatations that happen.


Re: [PATCH] Add working-set size and hotness information to fdo summary (issue6465057)

2012-08-19 Thread Teresa Johnson
On Sat, Aug 18, 2012 at 1:19 AM, Jan Hubicka hubi...@ucw.cz wrote:

  +{
  +  cs_prg-num = cs_tprg-num;
  +  /* Allocate the working set array for the merged 
  summary.  */
  +  if (ws_cnt)
  +{
  +  cs_prg-working_set_count = ws_cnt;
  +  cs_prg-working_sets = (gcov_ws_info_t *) malloc (
  +  ws_cnt * sizeof (gcov_ws_info_t));
  +}
  +}
  +  else if (cs_prg-num != cs_tprg-num
  +   || ws_cnt != cs_prg-working_set_count)
  +goto read_mismatch;
  +  /* Copy over this run's working set information if either 
  this is
  + the first run, the total size of the profile (sum_all) is 
  much
  + (50%) larger for this run (need to check this before 
  updating
  + cs_prg-sum_all below), or this run has a larger working
  + set in the largest (99.99% of sum_all) bucket.  */
  +  if (ws_cnt
  +   (cs_prg-runs == 1
  +  || (cs_tprg-sum_all
  +   (cs_prg-sum_all + cs_prg-sum_all / 2))
  +  || (cs_tprg-working_sets[ws_cnt - 1].num_counters
  +   cs_prg-working_sets[ws_cnt - 
  1].num_counters)))
  +memcpy (cs_prg-working_sets,
  +cs_tprg-working_sets,
  +ws_cnt * sizeof (gcov_ws_info_t));
  cs_prg-sum_all += cs_tprg-sum_all;

 Hmm, when you run i.e. gcc bootstrap  where the program is run couple hundred
 times, this will end up really inaccurate, since it will probably just store
 the histogram of insn-attrtab compilation, right?


Well, it should store the largest working set in BBs, or one that came
from a much longer run. But I see the issue you are pointing out. The
num_counters (the number of hot bbs) should be reasonable, as the
total number of BBs is the same between all runs, and I want to show
the largest or more dominant working set in terms of the number of hot
bbs. But the min_bb_counter will become more and more inaccurate as
the number of runs increases, since the counter values are
accumulated.

I typed up a detailed email below on why getting this right would be
difficult, but then I realized there might be a fairly simple accurate
solution, which I'll describe first:

The only way I see to do this completely accurately is to take two
passes through the existing gcda files that we are merging into, one
to read in all the counter values and merge them into all the counter
values in the arrays from the current run (after which we can do the
histogramming/working set computation accurately from the merged
counters), and the second to rewrite them. In libgcov this doesn't
seem like it would be too difficult to do, although it is a little bit
of restructuring of the main merging loop and needs some special
handling for buffered functions (which could increase the memory
footprint a bit if there are many of these since they will all need to
be buffered across the iteration over all the gcda files).

The summary merging in coverage.c confuses me a bit as it seems to be
handling the case when there are multiple program summaries in a
single gcda file. When would this happen? It looks like the merge
handling in libgcov should always produce a single program summary per
gcda file.



 Why you don't simply write the histogram into gcov file and don't merge the 
 values
 here (i.e. doing the cummulation loop in GCC instead of within libgcov)?

That doesn't completely solve the problem, unfortunately. The reason
is that you don't know which histogram entry contains a particular
block each run, and therefore you don't know how to compute the new
combined histogram value and index for that bb counter. For example, a
particular histogram index may have 5 counters (bbs) in it for one run
and 2 counters (bbs) in it for a second run, so the question is how to
compute the new entry for all of those bb counters, as the 5 bbs from
the first run may or may not be a superset of the 2 from the second
run. You could assume that the bbs have the same relative order of
hotness between runs, and combine the bb counters accordingly, but
there is still some trickiness because you have to apportion the
cumulative counter sum stored in the histogram entry between new
entries. For example, assume the highest indexed non-zero entries (the
histogram buckets containing the largest counter values) in the two
incoming histograms are:

histogram 1:

index 100: 4 counters, cumulative value X, min counter value minx
...

histogram 2:

index 100: 2 counters, cumulative value Y, min counter value miny
index 99: 3 counters, cumulative value W, min counter value minw
...

To merge, you could assume something like 2 counters with a new
cumulative value (Y + 

  1   2   >