[Bug c++/48646] New: [C++0x] SFINAE does not handle comparisons between incompatible pointer types well

[gintensubaru at gmail dot com]

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

   Summary: [C++0x] SFINAE does not handle comparisons between
incompatible pointer types well
   Product: gcc
   Version: 4.7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: gintensub...@gmail.com


template< class T >
T&& declval();

template< class T, class U >
struct is_equality_comparable
{
  typedef char one_;
  typedef struct { char a[2]; } two_;

  template< class T_, class U_ >
  static decltype( declval() == declval(), one_() ) test_( int );

  template< class T_, class U_ >
  static two_ test_( ... );

  static const bool value = ( sizeof( test_( 0 ) ) == 1 );

};

int main()
{
  static_assert( is_equality_comparable::value, "OK." );
  static_assert( is_equality_comparable::value, "shall be
false." );
}


---

This code should be ill-formed, but gcc (-std=c++0x) accepts it, on all of
following versions:

4.5.1
4.6.0
4.6.1-20110415
4.7.0-20110416

[Bug fortran/48624] gfortran DECL issues in function declaration

[burnus at gcc dot gnu.org]

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

--- Comment #4 from Tobias Burnus  2011-04-17 
07:34:40 UTC ---
Author: burnus
Date: Sun Apr 17 07:34:35 2011
New Revision: 172604

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=172604
Log:
2011-05-17  Tobias Burnus  

PR fortran/48624
* trans-decl.c (gfc_get_extern_function_decl): Fix decl
for external procedures with proc arguments.


Modified:
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/trans-decl.c

[Bug fortran/48624] gfortran DECL issues in function declaration

[burnus at gcc dot gnu.org]

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

Tobias Burnus  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||FIXED

--- Comment #5 from Tobias Burnus  2011-04-17 
07:36:35 UTC ---
FIXED on the 4.7 trunk.

Thanks Thomas for the review!

[Bug c++/48647] New: [C++0x] SFINAE does not handle incompatible pointer types well in conditional operator

[gintensubaru at gmail dot com]

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

   Summary: [C++0x] SFINAE does not handle incompatible pointer
types well in conditional operator
   Product: gcc
   Version: 4.7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: gintensub...@gmail.com


template< class T >
T&& declval();

template< class T, class U >
decltype( true ? declval() : declval() ) test( int );

template< class T, class U >
void test( ... );


template< class T, class U >
struct is_same {
  static const bool value = false;
};

template< class T >
struct is_same {
  static const bool value = true;
};

int main()
{
  typedef decltype( test(0) ) void_expected;
  static_assert( is_same::value,  "This should be true,
and" );
  static_assert( is_same::value, "this should be false."
);
}

---


In this code, type of expression 'test(0)' should be void,
but gcc (-std=c++0x) says it's void*, on all of following versions:

4.5.1
4.6.0
4.6.1-20110415
4.7.0-20110416

[Bug target/47596] internal compiler error: in print_reg, at config/i386/i386.c:10894

[sezeroz at gmail dot com]

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

--- Comment #7 from Ozkan Sezer  2011-04-17 09:07:24 
UTC ---
Possibly related: PR target/47626.  This doesn't seem mingw-specific and is
_incorrectly_ marked as WORKSFORME.

[Bug target/47626] internal compiler error: in print_reg (only for i686, and i486, not x86_64)

[sezeroz at gmail dot com]

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

Ozkan Sezer  changed:

   What|Removed |Added

 CC||sezeroz at gmail dot com

--- Comment #2 from Ozkan Sezer  2011-04-17 09:07:34 
UTC ---
Possibly related: PR target/47596 (which is incorrectly marked as WORKSFORME at
present...)

[Bug tree-optimization/48648] New: internal compiler error: in translate_clast, at graphite-clast-to-gimple.c:1123

[bero at arklinux dot org]

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

   Summary: internal compiler error: in translate_clast, at
graphite-clast-to-gimple.c:1123
   Product: gcc
   Version: 4.6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: b...@arklinux.org
  Host: i586-pc-linux-gnu
Target: i586-pc-linux-gnu
 Build: i586-pc-linux-gnu


Trying to build postgresql 9.0.4 with gcc 4.6.0 with graphite optimizations
enabled results in

i586-pc-linux-gnu-gcc -O -fgraphite-identity -I../../../src/include
-D_GNU_SOURCE -I/usr/include/libxml2   -c -o ip.o ip.c
ip.c: In function ‘pg_sockaddr_cidr_mask’:
ip.c:343:1: internal compiler error: in translate_clast, at
graphite-clast-to-gimple.c:1123
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.

[Bug tree-optimization/48648] internal compiler error: in translate_clast, at graphite-clast-to-gimple.c:1123

[bero at arklinux dot org]

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

--- Comment #1 from bero at arklinux dot org 2011-04-17 09:48:04 UTC ---
Created attachment 24015
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=24015
Full preprocessed source

[Bug lto/48538] GCC build fails with -flto in BOOT_CFLAGS

[jafb at tinet dot org]

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

--- Comment #4 from jafb at tinet dot org 2011-04-17 09:59:35 UTC ---
Mmmm I'm afraid using --with-build-config=bootstrap-lto crashes at the same
point with the same error.
As a workaround, can I compile the ada frontend after installing the rest,
without lto? How?
I have one doubt about compiling the ada frontend (sorry if I shouldn't be
asking this here). Documentation of --enable-threads config option looks to
tell that the correct option for ada targets is --enable-threads=gnat, but this
is equivalent to single for other targets. Should I compile everything except
ada with default threading library (I guess posix) and separately the ada
frontend with --enable-threads=gnat? Or am I misunderstanding?

By the way, make doesn't look to honor --with-build-config=bootstrap-O3. I'm
not an expert at all in Makefiles, but looking at the generated Makefile, the
file is included after setting STAGE_CFLAGS to the value of BUILD_CFLAGS (and
other variables from STAGE_CFLAGS). Of course, if BUILD_CFLAGS is altered after
that, these variables are not correspondingly altered.

More things I've found in my adventure of trying nonstandard options for
building:

- When using make -jn, when linking it claims to go back to -j1 because
(something about jobserver, if I remember right) and says that '+' should be
added to the top-level rule of the Makefile. Is this on purpose or '+' should
have automatically been added?

- Adding -mcmodel=large to BOOT_CFLAGS crashes (I think it's the assembler).
-mcmodel=medium works. But I don't understand very well how these options work.
Will the compiler have more available memory for data if I use medium model?
Does this afect the heap or only static memory? And more important, will the
compiler work correctly if it's compiled with these options?

Thanks a lot, and sorry again if any of my comments should not be here,

Juan

[Bug tree-optimization/48648] internal compiler error: in translate_clast, at graphite-clast-to-gimple.c:1123

[bero at arklinux dot org]

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

bero at arklinux dot org changed:

   What|Removed |Added

  Attachment #24015|0   |1
is obsolete||

--- Comment #2 from bero at arklinux dot org 2011-04-17 10:08:36 UTC ---
Created attachment 24016
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=24016
Somewhat reduced test case

[Bug fortran/48636] Enable more inlining with -O2 and higher

[dominiq at lps dot ens.fr]

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

--- Comment #2 from Dominique d'Humieres  2011-04-17 
10:23:03 UTC ---
As shown by the following results it seems that --param max-inline-insns-auto=*
is the way to go.

Date & Time : 17 Apr 2011 11:22:05
Test Name   : pbharness
Compile Command : gfc %n.f90 -Ofast -funroll-loops -ftree-loop-linear
-fomit-frame-pointer --param max-inline-insns-auto=400 -fwhole-program -flto
-fstack-arrays -o %n
Benchmarks  : ac aermod air capacita channel doduc fatigue gas_dyn induct
linpk mdbx nf protein rnflow test_fpu tfft
Maximum Times   :  300.0
Target Error %  :  0.200
Minimum Repeats : 2
Maximum Repeats : 5

   Benchmark   Compile  Executable   Ave Run  Number   Estim
Name(secs) (bytes)(secs) Repeats   Err %
   -   ---  --   --- ---  --
  ac  8.07   54576  8.11   2  0.0062
  aermod175.22 1472624 18.83   2  0.1647
 air 25.65   89992  6.78   5  0.1871
capacita 14.02  109536 40.36   2  0.0483
 channel  3.11   34448  2.94   5  0.6012
   doduc 29.46  224584 27.44   2  0.0437
 fatigue  9.85   77032  2.74   2  0.0365
 gas_dyn 26.09  144112  4.68   5  0.6928
  induct 24.32  189696 14.24   2  0.1193
   linpk  3.13   21536 21.69   2  0.0254
mdbx  9.18   84776 12.55   2  0.0678
  nf 34.14  124640 18.38   2  0.1034
 protein 28.14  155624 35.48   2  0.0789
  rnflow 43.93  204176 26.70   2  0.0262
test_fpu 21.90  141696 11.18   2  0.0045
tfft  1.71   22072  3.29   5  0.1369

Geometric Mean Execution Time =  11.60 seconds



Date & Time : 17 Apr 2011 11:50:20
Test Name   : pbharness
Compile Command : gfc %n.f90 -Ofast -funroll-loops -ftree-loop-linear
-fomit-frame-pointer -finline-limit=600 -fwhole-program -flto -fstack-arrays -o
%n
Benchmarks  : ac aermod air capacita channel doduc fatigue gas_dyn induct
linpk mdbx nf protein rnflow test_fpu tfft
Maximum Times   :  300.0
Target Error %  :  0.200
Minimum Repeats : 2
Maximum Repeats : 5

   Benchmark   Compile  Executable   Ave Run  Number   Estim
Name(secs) (bytes)(secs) Repeats   Err %
   -   ---  --   --- ---  --
  ac  8.06   54576  8.11   2  0.0062
  aermod175.54 1480632 18.92   2  0.0106
 air 25.36   89992  6.76   2  0.0740
capacita 13.95  109536 40.32   2  0.0161
 channel  3.13   34448  2.95   5  0.1703
   doduc 27.31  212280 27.18   2  0.0331
 fatigue  9.82   77032  2.74   2  0.0182
 gas_dyn 24.86  144112  4.67   5  0.3052
  induct 24.25  189696 14.21   2  0.0035
   linpk  2.55   21536 21.69   2  0.0023
mdbx  9.17   84776 12.53   2  0.0239
  nf 34.21  124640 18.41   4  0.1634
 protein 28.01  155624 35.46   2  0.0310
  rnflow 38.11  183696 26.74   2  0.0037
test_fpu 19.63  141720 10.84   2  0.0323
tfft  1.69   22072  3.29   2  0.0152

Geometric Mean Execution Time =  11.57 seconds

[Bug tree-optimization/48648] internal compiler error: in translate_clast, at graphite-clast-to-gimple.c:1123

[bero at arklinux dot org]

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

bero at arklinux dot org changed:

   What|Removed |Added

  Attachment #24016|0   |1
is obsolete||

--- Comment #3 from bero at arklinux dot org 2011-04-17 10:34:17 UTC ---
Created attachment 24017
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=24017
Reduced test case

[Bug tree-optimization/48648] internal compiler error: in translate_clast, at graphite-clast-to-gimple.c:1123

[bero at arklinux dot org]

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

--- Comment #4 from bero at arklinux dot org 2011-04-17 10:34:52 UTC ---
void *foo(const void *a);

void bug48648()
{
unsigned char a[2];
long b;
int i;

for(i = 0; i < 2; i++) {
if (b <= 0)
a[i] = 0;
else if (b >= 8)
a[i] = 0;
else
a[i] = 0;
b -= 8;
}
foo(&a);
}

[Bug fortran/48636] Enable more inlining with -O2 and higher

[hubicka at gcc dot gnu.org]

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

--- Comment #3 from Jan Hubicka  2011-04-17 
10:44:23 UTC ---
I am slowly starting to look into fortran issues now.  For years it was
non-issue since we had the non-one-decl-per-function problem. This is finally
solved

One additional problem is that we often hit large-stack frame limits because
the fortran i/o drops large datastructure on stack.  Consequently any functions
that do i/o (for debug purposes, for example) are not inlined into functions
that doesn't.  We will need to relax this.

- Consider heuristics to mark functions as inline in the front end:

- If it has many arguments (argument processing has a lot of effect)

- If it uses assumed-shape arrays (setting up that array descriptor
  may take a lot of time

- Mark everything as inline

I briefly discussed option of marking everything as inline on IRC for 4.6.x
series but it did not go well with Richard. Observation is that dominating
coding style in fortran is to not care that much about code size if perfomrance
improve and inlining do help here.

In longer term it would be cool if inliner was able to work out as much as
possible himself w/o frontend help.
The first item you mention is something backend can do at its own (and it
already knows how to benefit many arguments, but it proably does not do it
enough to make difference for fortran). I am just about commit patch that makes
backend by hair more sensitive on this.

The second item is interesting - it would be cool if backend was able to work
out that the code is supposed to simplify after inlining. Either by itself or
by frontend hint.
Can you provide me very simple testcase for that I can look into how it looks
like in backend?  Perhaps some kind of frontend hinting would work well here.

Honza

[Bug lto/48538] GCC build fails with -flto in BOOT_CFLAGS

[ebotcazou at gcc dot gnu.org]

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

Eric Botcazou  changed:

   What|Removed |Added

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

--- Comment #5 from Eric Botcazou  2011-04-17 
10:44:30 UTC ---
> Mmmm I'm afraid using --with-build-config=bootstrap-lto crashes at the 
> same point with the same error.

Weird, LTO bootstrap for Ada is supposed to work (with default options).

> I have one doubt about compiling the ada frontend (sorry if I shouldn't be
> asking this here). Documentation of --enable-threads config option looks to
> tell that the correct option for ada targets is --enable-threads=gnat, but
> this is equivalent to single for other targets. Should I compile everything
> except ada with default threading library (I guess posix) and separately the 
> ada frontend with --enable-threads=gnat? Or am I misunderstanding?

Yes, you are, there is nothing special about Ada here.

[Bug rtl-optimization/44194] struct returned by value generates useless stores

[rguenther at suse dot de]

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

--- Comment #16 from rguenther at suse dot de  
2011-04-17 10:44:02 UTC ---
On Fri, 15 Apr 2011, eraman at google dot com wrote:

> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44194
> 
> --- Comment #15 from Easwaran Raman  2011-04-15 
> 22:22:15 UTC ---
> (In reply to comment #14)
> > On Fri, 15 Apr 2011, eraman at google dot com wrote:
> > 
> > > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44194
> > > 
> > > Easwaran Raman  changed:
> > > 
> > >What|Removed |Added
> > > 
> > >  CC||eraman at google dot com
> > > 
> > > --- Comment #13 from Easwaran Raman  2011-04-15 
> > > 19:18:25 UTC ---
> > > Richard, did you mean to write
> > > 
> > > static bool
> > > can_escape (tree expr)
> > > {
> > >   tree base;
> > >   if (!expr)
> > > return true;
> > >   base = get_base_address (expr);
> > >   if (DECL_P (base)
> > >   && (!may_be_aliased (base)
> > >   && !pt_solution_includes (&cfun->gimple_df->escaped, base)))
> > > return false;
> > >   return true;
> > > }
> > > 
> > > Only case when we know it doesn't escape is if bas is a DECL_P and is not 
> > > in
> > > cfun->gimple_df->escaped and not aliased, right? Actually, I'm wondering 
> > > if it
> > > is sufficient to test just
> > > DECL_P (base) && !pt_solution_includes (&cfun->gimple_df->escaped, base).
> > 
> > No, because if the escaped solution for example includes ANYTHING then
> > the test will return true.  That !may-aliased variables are not
> > contained in ANYTHING isn't known w/o context.
> > 
> > Richard.
> 
> Correct me if I am wrong. If I understand you right, just using DECL_P (base)
> && !pt_solution_includes is conservative since pt_solution_includes may return
> true if the escaped solution contains ANYTHING. To make it less conservative,
> you're suggesting
> 
>   if (DECL_P (base)
>   && (!may_be_aliased (base)
>   || !pt_solution_includes (&cfun->gimple_df->escaped, base)))
> return false;
> 
>  I tried that and most Fortran tests are failing. One of the tests
> (default_format_1.f90) has the following RTL sequence:
> 
> 
> (insn 30 29 32 4 (set (mem/s/c:SI (plus:DI (reg/f:DI 20 frame)
> (const_int -608 [0xfda0])) [2
> dt_parm.0.common.flags+0 S4 A64])
> (const_int 16512 [0x4080])) default_format_1.inc:56 64
> {*movsi_internal}
>  (nil))
> 
> (insn 32 30 33 4 (set (reg:DI 5 di)
> (reg/f:DI 106)) default_format_1.inc:56 62 {*movdi_internal_rex64}
>  (expr_list:REG_EQUAL (plus:DI (reg/f:DI 20 frame)
> (const_int -608 [0xfda0]))
> (nil)))
> 
> (call_insn 33 32 36 4 (call (mem:QI (symbol_ref:DI ("_gfortran_st_write")
> [flags 0x41]  ) [0
> _gfortran_st_write S1 A8])
> (const_int 0 [0])) default_format_1.inc:56 618 {*call_0}
>  (expr_list:REG_DEAD (reg:DI 5 di)
> (nil))
> (expr_list:REG_DEP_TRUE (use (reg:DI 5 di))
> (nil)))
> 
> For the DECL dt_parm, pt_solution_includes (&cfun->gimple_df->escaped, base)
> returns false, even though its location is passed as a parameter to
> _gfortran_st_write.
> 
> I did test  with 
> if (DECL_P (base)
>   && (!may_be_aliased (base)
>   && !pt_solution_includes (&cfun->gimple_df->escaped, base)))
> 
> which has no regressions. Is that what you suggest?

No, the version with || should be ok.  The dt_parm argument does
not escape at the _gfortran_st_write call site because this
intrinsic function has a ".wW" fnspec attribute which specifies
the arguments do not escape.  What you indeed need to do in
addition to the escaped solution query is walk over all function
arguments and see if there is one that aliases 'base'.  That
may not be easily possible on RTL though.  On the tree level
we have a separate points-to set for such call clobbers/uses
but we do not preserve it for RTL.

[Bug c/48649] New: cannot find space to spill in GENERAL REGISTERS

[vasco at icpnet dot pl]

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

   Summary: cannot find space to spill in GENERAL REGISTERS
   Product: gcc
   Version: 4.3.5
Status: UNCONFIRMED
  Severity: critical
  Priority: P3
 Component: c
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: va...@icpnet.pl


Created attachment 24018
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=24018
error message during compilation

1)Operating system Coherent 4.2.x, 32 bit, coff binary format
2)stage 1 compiler gcc-4.3.5 built with gcc-3.2.3.
3)Compiling any program with optimization turned on (-O2 etc) brings the
message about spilling GENERAL registers in sreal at line 503
4)Compiling and linking of simple programs like "hallo world" works fine , when
any optimization is turned off. The above means , that I could not build
libgcc.a, I am using libgcc.a from gcc-3.2.3
5) I am attaching output of compilation of a test program with optimization
turned off , which produces this "spill" error message.
6) gas 2.14 is used
7) ThinkCentre with Pentium 4 2.8 GHZ is used

The similar behaviour is observed with gcc-4.2.2 and gcc-3.4.3, also built with
gcc-3.2.3.

[Bug c++/43601] Enormous increase in DLL object files size in 4.5

[xunxun1982 at gmail dot com]

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

--- Comment #59 from PcX  2011-04-17 11:06:13 UTC 
---
Yea, I review the patch(In reply to comment #57)
> (In reply to comment #56)
> > What works for me on Cygwin, and so may well also work for anyone using 
> > MSYS,
> > is setting the heap_chunk_in_mb registry parameter to some value in the 
> > range
> > 1024 - 1536.  I use 1024 myself and that gives me sufficient headroom to 
> > link
> > libgcj dll, which is huge; if it works for that, it's likely to help with wx
> > dll as well.
> > 
> > http://cygwin.com/cygwin-ug-net/setup-maxmem.html
> 
> I don't think so. Because I observed ld.exe use memory over 1.7GB, so link wx
> monolithic library require use more memory than 32 bit OS limit. For cross
> compile under Linux, link wx can use near 3G memory, it still failed.
> 
> Then link wx require 4G or more memory, maybe someone can try use 64bit linker
> to build single huge monolithic library, tell us the max memory ld used.

I review the patch, and found that we can add "-fno-keep-inline-dllexport" to
the compiler option, and then, the compiler and linker stage works well. But
the wxWidgets release mono dll's size is so large.(about 17M)

[Bug c/48649] cannot find space to spill in GENERAL REGISTERS

[vasco at icpnet dot pl]

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

--- Comment #1 from Popielewicz  2011-04-17 11:17:51 
UTC ---
Created attachment 24019
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=24019
test program

This is the test program , which produced the mentioned error message.

[Bug lto/48538] GCC build fails with -flto in BOOT_CFLAGS

[jafb at tinet dot org]

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

--- Comment #6 from jafb at tinet dot org 2011-04-17 11:21:58 UTC ---
(In reply to comment #5)
> > Mmmm I'm afraid using --with-build-config=bootstrap-lto crashes at the 
> > same point with the same error.
> 
> Weird, LTO bootstrap for Ada is supposed to work (with default options).
> 

Well, I don't think it's difficult to reproduce, if you just compile with the
options I described initially.
I believe that it happens when I use profiledbootstrap together with lto, and
for the Ada frontend. But I'm not 100% sure, as the long time it takes to test
it every time prevents me from trying many combinations of options. I also
don't know if things like -O3 or -march=corei7 have something to do with it or
it would fail anyway. If I bound the minimal conditions that trigger this
problem better, I'll let you know.

[Bug lto/48538] profiled LTO bootstrap failure with Ada

[ebotcazou at gcc dot gnu.org]

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

Eric Botcazou  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2011.04.17 11:24:24
 AssignedTo|unassigned at gcc dot   |ebotcazou at gcc dot
   |gnu.org |gnu.org
Summary|GCC build fails with -flto  |profiled LTO bootstrap
   |in BOOT_CFLAGS  |failure with Ada
 Ever Confirmed|0   |1

--- Comment #7 from Eric Botcazou  2011-04-17 
11:24:24 UTC ---
Investigating.

[Bug c/48649] cannot find space to spill in GENERAL REGISTERS

[vasco at icpnet dot pl]

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

--- Comment #2 from Popielewicz  2011-04-17 11:42:30 
UTC ---
Created attachment 24020
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=24020
error meesages during compilation with optimization turned on

Error messages produced during compilation of the attached test program when
optimization is turned on. The messages are identical for all types of
optimization : -O2, -Os, -O3, -O4 etc.

[Bug tree-optimization/48498] Several gcc.dg/vect tests XPASS on SPARC

[irar at il dot ibm.com]

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

Ira Rosen  changed:

   What|Removed |Added

 CC||irar at il dot ibm.com

--- Comment #2 from Ira Rosen  2011-04-17 12:15:29 UTC 
---
Could you please attach vect dumps before the XPASSes? From the current dumps I
can only understand that unaligned accesses get vectorized by forcing alignment
of local arrays.

Thanks,
Ira

[Bug c/48649] cannot find space to spill in GENERAL REGISTERS

[vasco at icpnet dot pl]

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

--- Comment #3 from Popielewicz  2011-04-17 12:28:52 
UTC ---
Created attachment 24021
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=24021
error messages when an extra patch applied

After applying the following patch in sreal.h

#ifndef COHERENT
#define SREAL_MAX_EXP (INT_MAX /4)
#endif

#ifdef COHERENT
#define coh_int_max 0x7f00
#define SREAL_MAX_EXP (coh_int_max/4)
#endif

the error now occurs in cfgrtl.c 
Notice , that optimization is turned on.Without optimization , as before one
observes "spill" messages.

BTW , the similar patch as above but for gcc-4.2.2 moves the error to reload1.c
at line 19xx, which is similar to some known bug in the past.It was mentioned
there that this bug was fixed in 4.3.4 and above, but probably (?) not quite.

[Bug libfortran/48602] Invalid F conversion of G descriptor for values close to powers of 10

[jvdelisle at gcc dot gnu.org]

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

--- Comment #16 from Jerry DeLisle  2011-04-17 
12:39:25 UTC ---
I see another rounding issue with this:

integer, parameter :: RT=8
print *, 0.09_RT, " RD:"
print "(RD,G15.2)", 0.09_RT
print "(RD,E15.2)", 0.09_RT
print "(RD,D15.2)", 0.09_RT
print "(RD,F15.2)", 0.09_RT
end
Gives:

  8.99967E-002  RD:
   0.89E-01
   0.90E-01
   0.90D-01
   0.08

I believe the E and D case should be 0.89E-01 and 0.89E-01

[Bug c/48650] New: valgrind: Invalid write of size 8 in build_string (tree.c:1524)

[zsojka at seznam dot cz]

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

   Summary: valgrind: Invalid write of size 8 in build_string
(tree.c:1524)
   Product: gcc
   Version: 4.7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: zso...@seznam.cz
  Host: x86_64-pc-linux-gnu
Target: x86_64-pc-linux-gnu


While building with valgrind checking, one gets many of these errors:
==28100== Invalid write of size 8
==28100==at 0x838128: build_string (string3.h:86)
==28100==by 0x4EE6E3: lex_string (c-lex.c:998)
==28100==by 0x4EF974: c_lex_with_flags (c-lex.c:432)
==28100==by 0x4B517D: c_lex_one_token (c-parser.c:216)
==28100==by 0x4C1834: c_parser_statement_after_labels (c-parser.c:398)
==28100==by 0x4C22D7: c_parser_compound_statement_nostart (c-parser.c:4114)
==28100==by 0x4C3828: c_parser_compound_statement (c-parser.c:3951)
==28100==by 0x4C19D1: c_parser_statement_after_labels (c-parser.c:4530)
==28100==by 0x4C22D7: c_parser_compound_statement_nostart (c-parser.c:4114)
==28100==by 0x4C3828: c_parser_compound_statement (c-parser.c:3951)
==28100==by 0x4C19D1: c_parser_statement_after_labels (c-parser.c:4530)
==28100==by 0x4C22D7: c_parser_compound_statement_nostart (c-parser.c:4114)
==28100==by 0x4C3828: c_parser_compound_statement (c-parser.c:3951)
==28100==by 0x4BFE5E: c_parser_declaration_or_fndef (c-parser.c:1721)
==28100==by 0x4C490D: c_parser_external_declaration (c-parser.c:1334)
==28100==by 0x4C54D7: c_parse_file (c-parser.c:1222)
==28100==by 0x4F31F4: c_common_parse_file (c-opts.c:1092)
==28100==by 0x725A67: toplev_main (toplev.c:579)
==28100==by 0x6222B6C: (below main) (in /lib64/libc-2.11.3.so)
==28100==  Address 0x77afe08 is not stack'd, malloc'd or (recently) free'd
==28100== 

The problem seems to be that the allocated memory is sometimes smaller than
sizeof struct tree_common:

Breakpoint 5, build_string (len=2, str=0x12ac700 "0") at
/mnt/svn/gcc-trunk/gcc/tree.c:1522
1522  s = ggc_alloc_tree_node (length);
(gdb) p length
$5 = 23
(gdb) p sizeof (struct tree_common)
$15 = 24

so ggc_alloc_tree_node (ggc_internal_alloc_stat) is called with parameter value
23, but memset at tree.c:1524 overwrites 24 bytes.

[Bug libfortran/48602] Invalid F conversion of G descriptor for values close to powers of 10

[thenlich at users dot sourceforge.net]

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

--- Comment #17 from Thomas Henlich  
2011-04-17 13:25:25 UTC ---
(In reply to comment #16)
> I see another rounding issue with this:
> 
> integer, parameter :: RT=8
> print *, 0.09_RT, " RD:"
> print "(RD,G15.2)", 0.09_RT
> print "(RD,E15.2)", 0.09_RT
> print "(RD,D15.2)", 0.09_RT
> print "(RD,F15.2)", 0.09_RT
> end
> Gives:
> 
>   8.99967E-002  RD:
>0.89E-01
>0.90E-01
>0.90D-01
>0.08
> 
> I believe the E and D case should be 0.89E-01 and 0.89E-01

I agree.

Let's open a new bug for this. This bug is about the correct choice of format,
not about rounding (this is somewhere else in the code).

[Bug fortran/48636] Enable more inlining with -O2 and higher

[tkoenig at gcc dot gnu.org]

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

--- Comment #4 from Thomas Koenig  2011-04-17 
13:32:11 UTC ---
(In reply to comment #3)

> The second item is interesting - it would be cool if backend was able to work
> out that the code is supposed to simplify after inlining. Either by itself or
> by frontend hint.
> Can you provide me very simple testcase for that I can look into how it looks
> like in backend?  Perhaps some kind of frontend hinting would work well here.

Here is some sample code (extreme, I admit) which profits a lot from
inlining:

- Strides are known to be one when inlining (a common case, but you can
  never be sure if the user doesn't call a(1:5:2))

- Expensive setting up of, and reading from the array descriptor

- Loops can be completely unrolled

module foo
  implicit none
contains
  subroutine bar(a,x)
real, dimension(:,:), intent(in) :: a
real, intent(out) :: x
integer :: i,j

x = 0
do j=1,ubound(a,2)
   do i=1,ubound(a,1)
  x = x + a(i,j)**2
   end do
end do
  end subroutine bar
end module foo

program main
  use foo
  implicit none
  real, dimension(2,3) :: a
  real :: x

  data a /1.0, 2.0, 3.0, -1.0, -2.0, -3.0/

  call bar(a,x)
  print *,x
end program main

Re: [Bug libfortran/48602] Invalid F conversion of G descriptor for values close to powers of 10

[Jerry DeLisle]

On 04/17/2011 06:25 AM, thenlich at users dot sourceforge.net wrote:
--- snip ---



I agree.

Let's open a new bug for this. This bug is about the correct choice of format,
not about rounding (this is somewhere else in the code).



Yes, new PR.  We are using builtin snprintf for DTOA.

#define DTOA \
snprintf (buffer, size, "%+-#" STR(MIN_FIELD_WIDTH) ".*" \
  "e", ndigits - 1, tmp);

By examining the buffer returned, we are getting an exact value back before we 
even begin processing the string for our libgfortran needs. The buffer for this 
case contains:


buffer=990e-02

The first digit is an artifact of shifting the buffer for decimal point 
placement and is ignored. I still need to check the code between the call to 
snprintf and where I have placed a printf to view it.


snprintf may be rounding the value up. Testing continues.

[Bug libfortran/48602] Invalid F conversion of G descriptor for values close to powers of 10

[jvdelisle at frontier dot com]

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

--- Comment #18 from jvdelisle at frontier dot com 2011-04-17 13:47:06 UTC ---
On 04/17/2011 06:25 AM, thenlich at users dot sourceforge.net wrote:
--- snip ---

>
> I agree.
>
> Let's open a new bug for this. This bug is about the correct choice of format,
> not about rounding (this is somewhere else in the code).
>

Yes, new PR.  We are using builtin snprintf for DTOA.

#define DTOA \
snprintf (buffer, size, "%+-#" STR(MIN_FIELD_WIDTH) ".*" \
  "e", ndigits - 1, tmp);

By examining the buffer returned, we are getting an exact value back before we 
even begin processing the string for our libgfortran needs. The buffer for this 
case contains:

buffer=990e-02

The first digit is an artifact of shifting the buffer for decimal point 
placement and is ignored. I still need to check the code between the call to 
snprintf and where I have placed a printf to view it.

snprintf may be rounding the value up. Testing continues.

[Bug libfortran/48651] New: DTOA float conversion issue

[jvdelisle at gcc dot gnu.org]

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

   Summary: DTOA float conversion issue
   Product: gcc
   Version: 4.7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libfortran
AssignedTo: jvdeli...@gcc.gnu.org
ReportedBy: jvdeli...@gcc.gnu.org


See pr48602 comment #17 and #18

Confirmed the DTOA issue. Placed the print of buffer immediately after the DTOA
call

 ---
buffer=8.971e-02  
  8.971E-0002  RD:
buffer=8.971e-02  
   0.89E-01
buffer=9.0e-02
   0.90E-01
buffer=9.0e-02
   0.90D-01
buffer=8.971e-02  
   0.08

The problem only occurs with real(8)

[Bug fortran/48636] Enable more inlining with -O2 and higher

[dominiq at lps dot ens.fr]

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

--- Comment #5 from Dominique d'Humieres  2011-04-17 
14:12:30 UTC ---
I have investigated why test_fpu is slower with --param
max-inline-insns-auto=400 (11.18s) compared to -finline-limit=600 (10.84s) in
the timings of comment #2. This is due to the inlining of dgemm in the fourth
test Lapack 2:

[macbook] lin/test% gfc -Ofast -funroll-loops -fstack-arrays --param
max-inline-insns-auto=385 test_lap.f90
[macbook] lin/test% time a.out
  Benchmark running, hopefully as only ACTIVE task
Test4 - Lapack 2 (1001x1001) inverts  2.6 sec  Err= 0.250
 total =  2.6 sec

2.824u 0.081s 0:02.90 100.0%0+0k 0+0io 0pf+0w
[macbook] lin/test% gfc -Ofast -funroll-loops -fstack-arrays --param
max-inline-insns-auto=386 test_lap.f90
[macbook] lin/test% time a.out
  Benchmark running, hopefully as only ACTIVE task
Test4 - Lapack 2 (1001x1001) inverts  3.0 sec  Err= 0.250
 total =  3.0 sec

3.214u 0.082s 0:03.29 100.0%0+0k 0+0io 0pf+0w

Looking at the assembly, I see 'call_dgemm_' three times for 385 and none
for 386 (note there are only two calls in the code one in dgetri always inlined
and one in dgetrf not inlined). It would be interesting to understand why
inlining dgemm slows down the code.

[Bug lto/48538] profiled LTO bootstrap failure with Ada

[ebotcazou at gcc dot gnu.org]

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

--- Comment #8 from Eric Botcazou  2011-04-17 
14:57:17 UTC ---
Author: ebotcazou
Date: Sun Apr 17 14:57:14 2011
New Revision: 172611

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=172611
Log:
PR lto/48538
* lto-cgraph.c (merge_profile_summaries): Check that lto_file_data
is non-null before accessing it.
(input_cgraph): Remove trailing spaces.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/lto-cgraph.c

[Bug lto/48538] profiled LTO bootstrap failure with Ada

[ebotcazou at gcc dot gnu.org]

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

--- Comment #9 from Eric Botcazou  2011-04-17 
14:58:07 UTC ---
Author: ebotcazou
Date: Sun Apr 17 14:58:03 2011
New Revision: 172612

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=172612
Log:
PR lto/48538
* lto-cgraph.c (merge_profile_summaries): Check that lto_file_data
is non-null before accessing it.
(input_cgraph): Remove trailing spaces.

Modified:
branches/gcc-4_6-branch/gcc/ChangeLog
branches/gcc-4_6-branch/gcc/lto-cgraph.c

[Bug fortran/48588] [4.6/4.7 Regression] ICE (segfault) in gfc_get_nodesc_array_type

[pault at gcc dot gnu.org]

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

Paul Thomas  changed:

   What|Removed |Added

 CC||pault at gcc dot gnu.org

--- Comment #3 from Paul Thomas  2011-04-17 15:00:27 
UTC ---
(In reply to comment #2)
> Confirmed on fairly recent trunk:
> GNU Fortran (GCC) 4.7.0 20110404 (experimental)
> 

The problem goes away if -fno-whole-file is used or the subroutine DGESV_F90 is
removed.  Clearly there is some difference between the interface abstracted
from the subroutine itself and that from the interface.

-fno-whole-file is a temporary workaround.

Paul

[Bug lto/48538] profiled LTO bootstrap failure with Ada

[ebotcazou at gcc dot gnu.org]

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

Eric Botcazou  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED
   Target Milestone|--- |4.6.1

--- Comment #10 from Eric Botcazou  2011-04-17 
15:06:03 UTC ---
The segfault should be eliminated now.  As for the other issues:
  - you don't need to special-case the Ada compiler for anything,
  - the message issued with 'make -jn' is a known problem,
  - fiddling with -mcmodel isn't trivial because you need external support.

[Bug lto/48538] profiled LTO bootstrap failure with Ada

[jafb at tinet dot org]

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

--- Comment #11 from jafb at tinet dot org 2011-04-17 16:01:29 UTC ---
That was fast, thank you :)

[Bug bootstrap/48652] New: [4.7 Regression] LTO profiledbootstrap failure

[hjl.tools at gmail dot com]

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

   Summary: [4.7 Regression] LTO profiledbootstrap failure
   Product: gcc
   Version: 4.7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: bootstrap
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: hjl.to...@gmail.com


On Linux/x86-64, revision 172612 failed LTO profiledbootstrap with

../../src-trunk/gcc/sel-sched.c: In function 'sel_sched_region_2':
../../src-trunk/gcc/sel-sched.c:3723:7: error: 'need_stall' may be used
uninitialized in this function [-Werror=uninitialized]
../../src-trunk/gcc/sel-sched.c:5520:11: note: 'need_stall' was declared here

Revision 172607 passed that point.

[Bug bootstrap/48652] [4.7 Regression] LTO profiledbootstrap failure

[hjl.tools at gmail dot com]

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

--- Comment #1 from H.J. Lu  2011-04-17 16:16:49 
UTC ---
I think it is a real bug detected by LTO.

[Bug c/48649] cannot find space to spill in GENERAL REGISTERS

[vasco at icpnet dot pl]

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

--- Comment #4 from Popielewicz  2011-04-17 16:17:21 
UTC ---
It seems that in this specific case the gcc 4.3.5 has problems with modulo
operation. Even more simpler program using modulo alone produces spill message
.

If in the supplied program one removes modulo, for example replaces it with
addition ,then program compiles and links OK,
but of course aborts at free call.
Of course all the time optimizations are switched off.

BTW I could compile about 50% of functions in libgcc. 

So the compiler is not absolutely useless but rather not usable.

[Bug bootstrap/48653] New: Bootstrap comparison failure with bootstrap-lto

[jafb at tinet dot org]

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

   Summary: Bootstrap comparison failure with bootstrap-lto
   Product: gcc
   Version: 4.6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: bootstrap
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: j...@tinet.org


I'm trying to bootstrap gcc with the option --with-build-config=bootstrap-lto
and bootstrap comparison fails.
I'm compiling the sources in gcc-4.6.0.tar.bz2 (the full bundle).

My machine is a Core i7 920 (non-AVX)

My OS is Fedora 14 linux x86_64, with all packages updated to latest versions.
Some libraries are not the right version, so I compiled the following:

gmp-4.3.2
ppl-0.11.2
cloog-ppl-0.15.11
mpfr-2.4.2
mpc-0.8.1

My configuration is:

../gcc/configure --enable-threads --with-arch=corei7 --with-tune=corei7
--with-fpmath=sse --enable-__cxa_atexit --enable-indirect-function
--enable-languages=c,c++,java,lto,objc,obj-c++,fortran,go,ada
--enable-libgcj-multifile --enable-java-home --with-arch-directory=x86_64
--enable-aot-compile-rpm --enable-browser-plugin --with-x
--enable-java-awt=gtk,xlib --enable-gtk-cairo --with-gmp=/usr/local
--with-gmp-lib=/usr/local/lib64 --with-ppl=/usr/local
--with-ppl-lib=/usr/local/lib64 --with-cloog=/usr/local
--with-cloog-lib=/usr/local/lib64 --with-mpfr=/usr/local
--with-mpfr-lib=/usr/local/lib64 --with-mpc=/usr/local
--with-mpc-lib=/usr/local/lib64 --with-build-config='bootstrap-O3
bootstrap-lto'

And I'm building with:

make BOOT_CFLAGS=-O2 -j16 bootstrap

The error I get is the following:

Comparing stages 2 and 3
warning: gcc/cc1obj-checksum.o differs
warning: gcc/cc1objplus-checksum.o differs
warning: gcc/cc1plus-checksum.o differs
warning: gcc/cc1-checksum.o differs
Bootstrap comparison failure!
gcc/real.o differs
gcc/graphite-cloog-util.o differs
gcc/graphite-flattening.o differs
gcc/graphite-blocking.o differs
gcc/graphite-interchange.o differs
gcc/builtins.o differs
gcc/tree.o differs
gcc/graphite-dependences.o differs
gcc/fold-const.o differs
gcc/graphite-sese-to-poly.o differs
gcc/graphite-poly.o differs
gcc/double-int.o differs
gcc/graphite-scop-detection.o differs
gcc/tree-ssa-loop-niter.o differs
gcc/fortran/trans-array.o differs
gcc/fortran/constructor.o differs
gcc/fortran/interface.o differs
gcc/fortran/trans-intrinsic.o differs
gcc/fortran/dump-parse-tree.o differs
gcc/fortran/primary.o differs
gcc/fortran/expr.o differs
gcc/fortran/array.o differs
gcc/fortran/iresolve.o differs
gcc/fortran/st.o differs
gcc/fortran/arith.o differs
gcc/fortran/module.o differs
gcc/fortran/check.o differs
gcc/fortran/dependency.o differs
gcc/fortran/trans-decl.o differs
gcc/fortran/simplify.o differs
gcc/fortran/trans-stmt.o differs
gcc/fortran/io.o differs
gcc/fortran/decl.o differs
gcc/fortran/data.o differs
gcc/fortran/trans-const.o differs
gcc/fortran/class.o differs
gcc/fortran/frontend-passes.o differs
gcc/fortran/openmp.o differs
gcc/fortran/parse.o differs
gcc/fortran/match.o differs
gcc/fortran/trans-openmp.o differs
gcc/fortran/intrinsic.o differs
gcc/fortran/trans.o differs
gcc/fortran/misc.o differs
gcc/fortran/matchexp.o differs
gcc/fortran/trans-expr.o differs
gcc/fortran/trans-io.o differs
gcc/fortran/trans-common.o differs
gcc/fortran/trans-types.o differs
gcc/fortran/resolve.o differs
gcc/fortran/symbol.o differs
gcc/fortran/target-memory.o differs
gcc/graphite.o differs
gcc/toplev.o differs
gcc/go/unsafe.o differs
gcc/go/statements.o differs
gcc/go/lex.o differs
gcc/go/go.o differs
gcc/go/dataflow.o differs
gcc/go/gogo.o differs
gcc/go/expressions.o differs
gcc/go/types.o differs
gcc/go/import-archive.o differs
gcc/go/export.o differs
gcc/go/parse.o differs
gcc/go/gogo-tree.o differs
gcc/graphite-clast-to-gimple.o differs
gcc/realmpfr.o differs
gcc/graphite-ppl.o differs

Without bootstrap-lto, comparison succeeds.

Thanks,

Juan

[Bug fortran/48462] [4.6/4.7 Regression] realloc on assignment: matmul Segmentation Fault with Allocatable Array

[pcpa at mandriva dot com.br]

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

Paulo César Pereira de Andrade  changed:

   What|Removed |Added

 CC||pcpa at mandriva dot com.br

--- Comment #8 from Paulo César Pereira de Andrade  2011-04-17 17:54:26 UTC ---
I am using the suggested solution in the Mandriva
gcc-4.6.0 package, to correct a bug report from
an user at

https://qa.mandriva.com/show_bug.cgi?id=63047

with the test case:

-%<-
program segmatmul

  implicit none

  integer :: i,j
  integer :: nsize
  real, dimension(:,:), allocatable :: matrixA, matrixB

  nsize=10

  allocate(matrixA(nsize,nsize),matrixB(nsize,nsize))

  do i=1,nsize
 do j=1,nsize
matrixA = real(i+j)
matrixB = real(i-j)
 enddo
  enddo

!segfaults
  matrixA = matmul(matmul(transpose(matrixB),matrixA),matrixB)



  deallocate(matrixA, matrixB)

end program segmatmul
-%<-
and compiled as:

$ gfortran -g segmatmul.f90 -o segmatmul.bin

that would cause a segfault due to matrixA being an
argument and also output value of the call.

Adding -std=f95 appeared to correct the issue in
the above sample.

[Bug libfortran/48651] DTOA float conversion issue

[jvdelisle at gcc dot gnu.org]

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

Jerry DeLisle  changed:

   What|Removed |Added

 CC||thenlich at users dot
   ||sourceforge.net

--- Comment #1 from Jerry DeLisle  2011-04-17 
18:07:27 UTC ---
Well, this is not a libgfortran issue. I am not convinced it is actually a
problem either.  The resulting value from printf swings to the other side for
double or long double.

#include 

int
main ()
{
  float num = 0.9;
  double dnum = 0.9;
  long double ldnum = 0.0;
  printf("%30.28f\n", num);
  printf("%30.28lf\n", num);
  printf("%30.28f\n", dnum);
  printf("%30.28lf\n", dnum);
  printf("%30.28f\n", ldnum);
  printf("%30.28lf\n", ldnum);
}

Gives:

$ ./a.out 
0.89976158142089843750
0.89976158142089843750
0.9000222044604925
0.9000222044604925
0.9000222044604925
0.9000222044604925

The result flips to the other side of .9 which is not necessarily wrong.

0.9 - 0.89976158142089843750 = 2.384185791×10⁻⁸

0.9 - 0.9000222044604925 = −2.220446049×10⁻¹⁷

[Bug libfortran/48651] DTOA float conversion issue

[jvdelisle at gcc dot gnu.org]

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

--- Comment #2 from Jerry DeLisle  2011-04-17 
18:28:55 UTC ---
hmm, notice the typo! i have set ldnum to 0.0 but it still is printing the
value of dnum. What am I doing wrong.

$ cat sprint.c 
#include 

int
main ()
{
  float num = 0.9;
  double dnum = 0.9;
  long double ldnum = 25.6;
  printf("%50.48f\n", num);
  printf("%50.48lf, %d\n", num, sizeof(num));
  printf("%80.78f\n", dnum);
  printf("%80.78lf, %d\n", dnum, sizeof(dnum));
  printf("%80.78f\n", ldnum);
  printf("%80.78lf, %d\n", ldnum, sizeof(ldnum));
}
[jerry@quattro pr48602]$ cat sprint.c 
#include 

int
main ()
{
  float num = 0.9;
  double dnum = 0.9;
  long double ldnum = 25.6;
  printf("%50.48f\n", num);
  printf("%50.48lf, %d\n", num, sizeof(num));
  printf("%80.78f\n", dnum);
  printf("%80.78lf, %d\n", dnum, sizeof(dnum));
  printf("%80.78f\n", ldnum);
  printf("%80.78lf, %d\n", ldnum, sizeof(ldnum));
}
[jerry@quattro pr48602]$ ./a.out 
0.89976158142089843750
0.89976158142089843750, 4
0.900022204460492503130808472633361816406250
0.900022204460492503130808472633361816406250,
8
0.900022204460492503130808472633361816406250
0.900022204460492503130808472633361816406250,
16

The value of ldnum is not surviving.

[Bug libfortran/48651] DTOA float conversion issue

[thenlich at users dot sourceforge.net]

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

--- Comment #3 from Thomas Henlich  
2011-04-17 18:34:15 UTC ---
(In reply to comment #2)
> hmm, notice the typo! i have set ldnum to 0.0 but it still is printing the
> value of dnum. What am I doing wrong.
> 
> $ cat sprint.c 
> #include 
> 
> int
> main ()
> {
>   float num = 0.9;
>   double dnum = 0.9;
>   long double ldnum = 25.6;
>   printf("%50.48f\n", num);
>   printf("%50.48lf, %d\n", num, sizeof(num));
>   printf("%80.78f\n", dnum);
>   printf("%80.78lf, %d\n", dnum, sizeof(dnum));
>   printf("%80.78f\n", ldnum);
>   printf("%80.78lf, %d\n", ldnum, sizeof(ldnum));

Check your format strings, use "lf" only for long double.

[Bug libfortran/48651] DTOA float conversion issue

[jvdelisle at gcc dot gnu.org]

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

--- Comment #4 from Jerry DeLisle  2011-04-17 
19:03:00 UTC ---
OK Format string needs capital 'L' for long double.

$ cat sprint.c 
#include 

int
main ()
{
  long double ldnum;
  ldnum = 25.6;
  printf("%30.24Lf, %d\n", ldnum, sizeof(ldnum));
}
$ gcc sprint.c 
$ ./a.out 
   25.601421085472, 16

[Bug libstdc++/48635] [C++0x] unique_ptr moves the deleter instead of copying it

[daniel.kruegler at googlemail dot com]

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

--- Comment #6 from Daniel Krügler  
2011-04-17 19:18:01 UTC ---
(In reply to comment #5)
> Done. Fixed mainline and 4_6-branch.

Looks good, thanks, but I just recognize that there is a library issue in
regard to the template version. The FDIS correctly applied the corresponding
proposal, but for some reason that is unclear, [unique.ptr.single.asgn] p. 6
describes the effects as "std::forward(u.get_deleter())". I verified with
discussion with Howard that this should have been
"std::forward(u.get_deleter())" instead, as it was suggested in

http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#983

[Bug fortran/48419] Reduce gfortran stack usage for procedures doing IO

[jb at gcc dot gnu.org]

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

Janne Blomqvist  changed:

   What|Removed |Added

 Depends on||45715

--- Comment #3 from Janne Blomqvist  2011-04-17 19:26:24 
UTC ---
See also PR 45715.

[Bug fortran/45715] [ABI cleanup] Move runtime parsing of I/O control list to front end

[tkoenig at gcc dot gnu.org]

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

Thomas Koenig  changed:

   What|Removed |Added

 Blocks||37577

--- Comment #3 from Thomas Koenig  2011-04-17 
19:27:47 UTC ---
Actually, for many strings, we would need
'yes', 'no" and a value for 'not specified', so four bits instead of 32.
Still better by a factor of 8, though :-)

[Bug libstdc++/48635] [C++0x] unique_ptr moves the deleter instead of copying it

[paolo.carlini at oracle dot com]

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

--- Comment #7 from Paolo Carlini  2011-04-17 
19:44:51 UTC ---
Ok... Do we have testcases for that?

By the way, I noticed that in the templated *constructor* we have been using D
instead of E in the forward, and that doesn't seem correct vs the FDIS itself.
What do you think? The below regtests fine:

Index: include/bits/unique_ptr.h
===
--- include/bits/unique_ptr.h(revision 172616)
+++ include/bits/unique_ptr.h(working copy)
@@ -153,7 +153,7 @@
&& std::is_convertible<_Ep, _Dp>::value))>
  ::type>
 unique_ptr(unique_ptr<_Up, _Ep>&& __u)
-: _M_t(__u.release(), std::forward(__u.get_deleter()))
+: _M_t(__u.release(), std::forward<_Ep>(__u.get_deleter()))
 { }

 #if _GLIBCXX_USE_DEPRECATED
@@ -186,7 +186,7 @@
 operator=(unique_ptr<_Up, _Ep>&& __u)
 {
   reset(__u.release());
-  get_deleter() = std::forward(__u.get_deleter());
+  get_deleter() = std::forward<_Ep>(__u.get_deleter());
   return *this;
 }

@@ -306,7 +306,7 @@

   template
 unique_ptr(unique_ptr<_Up, _Ep>&& __u)
-: _M_t(__u.release(), std::forward(__u.get_deleter()))
+: _M_t(__u.release(), std::forward<_Ep>(__u.get_deleter()))
 { }

   // Destructor.
@@ -326,7 +326,7 @@
 operator=(unique_ptr<_Up, _Ep>&& __u)
 {
   reset(__u.release());
-  get_deleter() = std::forward(__u.get_deleter());
+  get_deleter() = std::forward<_Ep>(__u.get_deleter());
   return *this;
 }

[Bug fortran/48654] New: ICE on return of derived type with allocatable-length character component

[damian at rouson dot net]

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

   Summary: ICE on return of derived type with allocatable-length
character component
   Product: gcc
   Version: 4.6.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: dam...@rouson.net


Created attachment 24022
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=24022
A more involved example that is closer to the intended use.

gfortran 4.6 give an ICE on the code below (and on the attached more involved
example):

$ cat message.F90
module message_module
  type message
character(:) ,allocatable :: string
  end type
contains
  type(message) function new_message()
  end function
end module

$ gfortran -c message.F90
message.F90:6:0: internal compiler error: in gfc_get_derived_type, at
fortran/trans-types.c:2298
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.

$ gfortran --version
GNU Fortran (GCC) 4.6.1 20110325 (prerelease)
Copyright (C) 2011 Free Software Foundation, Inc.

[Bug libstdc++/48635] [C++0x] unique_ptr moves the deleter instead of copying it

[daniel.kruegler at googlemail dot com]

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

--- Comment #8 from Daniel Krügler  
2011-04-17 20:12:09 UTC ---
(In reply to comment #7)
> Ok... Do we have testcases for that?

I have two test cases for the *assignment* situation, I invented them out of my
head and I hope the code below does not too many typos and thinkos:

1) This program should be well-formed according to FDIS wording, but ill-formed
according to the intended wording:

#include 
#include 

struct D;

struct B {
 B& operator=(D&) = delete;
 template
   void operator()(T*) const {}
};

struct D : B {};

int main()
{
 B b;
 D d;
 std::unique_ptr ub(nullptr, b);
 std::unique_ptr ud(nullptr, d);
 ub = std::move(ud); // Should be rejected
}

2) The same scenario here:

struct D2;

struct B2 {
 B2& operator=(D2&) = delete;
 template
   void operator()(T*) const {}
};

struct D2 {
 B2 b;
 operator B2&() { return b; }
 template
   void operator()(T*) const {}
};

int main()
{
 B2 b;
 D2 d;
 std::unique_ptr ub(nullptr, b);
 std::unique_ptr ud(nullptr, d);
 ub = std::move(ud); // Should be rejected
}

> By the way, I noticed that in the templated *constructor* we have been using D
> instead of E in the forward, and that doesn't seem correct vs the FDIS itself.
> What do you think? The below regtests fine:

I agree that the suggested fixes are necessary and they look correct to me.

[Bug fortran/48655] New: False positive with -Warray-temporaries and a=transpose(a)

[tkoenig at gcc dot gnu.org]

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

   Summary: False positive with -Warray-temporaries and
a=transpose(a)
   Product: gcc
   Version: 4.7.0
Status: UNCONFIRMED
  Severity: enhancement
  Priority: P3
 Component: fortran
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: tkoe...@gcc.gnu.org


Well, the front end generates the temporary, but the middle end removes it
again.

ig25@linux-fd1f:~/Dokumente/ig25/Transpose> cat foo.f90   
subroutine foo(a,x)   
  real, dimension(3,3), intent(out) :: a   
  real, intent(in) :: x

  a(1,1) = 1.0
  a(2,1) = 1.3 + x
  a(3,1) = 1.0
  a(1,2) = 1.43   
  a(2,2) = 2*x
  a(3,2) = x**2   
  a(1,3) = -x 
  a(2,3) = -x**2  
  a(3,3) = 2.1
  a = transpose(a)
end subroutine foo

ig25@linux-fd1f:~/Dokumente/ig25/Transpose> gfortran -O3 -c
-fdump-tree-optimized -fdump-tree-original -Warray-temporaries foo.f90  
foo.f90:14.6:   

  a = transpose(a)
  1
Warnung: Creating array temporary at (1)
ig25@linux-fd1f:~/Dokumente/ig25/Transpose> cat foo.f90.142t.optimized

;; Function foo (foo_)

foo (real(kind=4)[9] * restrict a, real(kind=4) & restrict x)
{
  real(kind=4) D.1549;
  real(kind=4) D.1586;
  real(kind=4) D.1585;
  real(kind=4) D.1584;
  real(kind=4) D.1583;
  real(kind=4) D.1582;

:
  *a_5(D)[0] = 1.0e+0;
  D.1582_7 = *x_6(D);
  D.1583_8 = D.1582_7 + 1.299523162841796875e+0;
  D.1584_10 = D.1582_7 * 2.0e+0;
  *a_5(D)[4] = D.1584_10;
  D.1549_12 = D.1582_7 * D.1582_7;
  D.1585_14 = -D.1582_7;
  D.1586_17 = -D.1549_12;
  *a_5(D)[8] = 2.09904632568359375e+0;
  *a_5(D)[1] = 1.4294754791259765625e+0;
  *a_5(D)[2] = D.1585_14;
  *a_5(D)[3] = D.1583_8;
  *a_5(D)[5] = D.1586_17;
  *a_5(D)[6] = 1.0e+0;
  *a_5(D)[7] = D.1549_12;
  return;

}

[Bug libstdc++/48521] [4.5/4.6/4.7 Regression] [C++0x] std::result_of doesn't work with pointer to member

[redi at gcc dot gnu.org]

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

--- Comment #4 from Jonathan Wakely  2011-04-17 
20:28:36 UTC ---
I'm just trying to figure out whether to enumerate every type of member
function w.r.t cv-qualifiers and ref-qualifiers and varargs as I think that's 8
partial specializations (24 when we get support for ref-qualifiers on member
functions!) some of which are missing for mem_fn/_Mem_fn (see my mails to the
reflector)

[Bug debug/48540] [4.7 Regression] FAIL: 20_util/typeindex/comparison_operators.cc on powerpc-apple-darwin9

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||FIXED

--- Comment #1 from Dominique d'Humieres  2011-04-17 
21:05:28 UTC ---
This ICE has disappeared at revision 172592. Closing as fixed.

[Bug c++/48656] New: [C++0x] cannot call member function without object

[harald at gigawatt dot nl]

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

   Summary: [C++0x] cannot call member function without object
   Product: gcc
   Version: 4.6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: har...@gigawatt.nl


Very similar to bug 47174:

struct A {
 int f();
 int f(int);
};
template  struct B : A
{
};
template  struct C : B
{
 void g() {
   A::f();
 }
};

This still fails with GCC 4.6.0 and -std=c++0x:
a.ii: In member function ‘void C::g()’:
a.ii:11:11: error: cannot call member function ‘int A::f()’ without object

[Bug c++/48656] [C++0x] cannot call member function without object

[harald at gigawatt dot nl]

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

--- Comment #1 from Harald van Dijk  2011-04-17 
21:14:07 UTC ---
Er... That's bug 47172, not bug 47174.

[Bug fortran/47545] ICE: in gfc_get_derived_type, at fortran/trans-types.c:2145

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

 CC||damian at rouson dot net

--- Comment #3 from Dominique d'Humieres  2011-04-17 
21:22:15 UTC ---
*** Bug 48654 has been marked as a duplicate of this bug. ***

[Bug fortran/48654] ICE on return of derived type with allocatable-length character component

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||DUPLICATE

--- Comment #1 from Dominique d'Humieres  2011-04-17 
21:22:15 UTC ---
I don't know where I grabbed your code, but I have already opened pr47545 for
it. Comment #2 says

> Deferred-length components are not yet supported, cf. bug 45170 comment 9.
>
> Nevertheless, gfortran should not ICE.

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

[Bug fortran/47545] ICE: in gfc_get_derived_type, at fortran/trans-types.c:2145

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2011.04.17 21:23:44
 Ever Confirmed|0   |1

--- Comment #4 from Dominique d'Humieres  2011-04-17 
21:23:44 UTC ---
Confirmed by pr48654.

[Bug c++/48656] [C++0x] cannot call member function without object

[paolo.carlini at oracle dot com]

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

Paolo Carlini  changed:

   What|Removed |Added

 CC||dodji at gcc dot gnu.org

--- Comment #2 from Paolo Carlini  2011-04-17 
21:25:48 UTC ---
Dodji, can you have a look? Thanks.

[Bug libstdc++/48635] [C++0x] unique_ptr moves the deleter instead of copying it

[paolo at gcc dot gnu.org]

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

--- Comment #9 from paolo at gcc dot gnu.org  
2011-04-17 21:46:15 UTC ---
Author: paolo
Date: Sun Apr 17 21:46:11 2011
New Revision: 172619

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=172619
Log:
2011-04-17  Daniel Krugler  
Paolo Carlini  

PR libstdc++/48635 (again)
* include/bits/unique_ptr.h (unique_ptr<>::unique_ptr(unique_ptr<>&&),
unique_ptr<_Tp[]>::unique_ptr(unique_ptr<>&&),
unique_ptr<>::operator=(unique_ptr<>&&),
unique_ptr<_Tp[]>::operator=(unique_ptr<>&&)): Use forward<_Ep>, not
forward<_Dp>, to forward the deleter.
* testsuite/20_util/unique_ptr/assign/48635_neg.cc: New.

Added:
trunk/libstdc++-v3/testsuite/20_util/unique_ptr/assign/48635_neg.cc
Modified:
trunk/libstdc++-v3/ChangeLog
trunk/libstdc++-v3/include/bits/unique_ptr.h

[Bug libstdc++/48635] [C++0x] unique_ptr moves the deleter instead of copying it

[paolo at gcc dot gnu.org]

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

--- Comment #10 from paolo at gcc dot gnu.org  
2011-04-17 21:46:23 UTC ---
Author: paolo
Date: Sun Apr 17 21:46:20 2011
New Revision: 172620

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=172620
Log:
2011-04-17  Daniel Krugler  
Paolo Carlini  

PR libstdc++/48635 (again)
* include/bits/unique_ptr.h (unique_ptr<>::unique_ptr(unique_ptr<>&&),
unique_ptr<_Tp[]>::unique_ptr(unique_ptr<>&&),
unique_ptr<>::operator=(unique_ptr<>&&),
unique_ptr<_Tp[]>::operator=(unique_ptr<>&&)): Use forward<_Ep>, not
forward<_Dp>, to forward the deleter.
* testsuite/20_util/unique_ptr/assign/48635_neg.cc: New.

Added:
   
branches/gcc-4_6-branch/libstdc++-v3/testsuite/20_util/unique_ptr/assign/48635_neg.cc
Modified:
branches/gcc-4_6-branch/libstdc++-v3/ChangeLog
branches/gcc-4_6-branch/libstdc++-v3/include/bits/unique_ptr.h

[Bug c++/48646] [C++0x] SFINAE does not handle comparisons between incompatible pointer types well

[paolo.carlini at oracle dot com]

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

Paolo Carlini  changed:

   What|Removed |Added

 CC||jason at gcc dot gnu.org

--- Comment #1 from Paolo Carlini  2011-04-17 
21:48:46 UTC ---
Maybe Jason can have a look (after 48531, preferably ;)

[Bug c++/48647] [C++0x] SFINAE does not handle incompatible pointer types well in conditional operator

[paolo.carlini at oracle dot com]

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

Paolo Carlini  changed:

   What|Removed |Added

 CC||jason at gcc dot gnu.org

--- Comment #1 from Paolo Carlini  2011-04-17 
21:49:18 UTC ---
Likewise...

[Bug middle-end/36550] Wrong "may be used uninitialized" warning (conditional PHIs)

[vincent.riviere at freesbee dot fr]

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

--- Comment #12 from Vincent Riviere  
2011-04-17 22:17:35 UTC ---
Created attachment 24023
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=24023
Very simple testcase

I hit the "may be used uninitialized in this function" bug when compiling this
small testcase. I think it is the same as the bug described here.

$ gcc -c bug.c -Os -Wuninitialized
bug.c: In function 'f':
bug.c:9: warning: 'b' may be used uninitialized in this function

This happens with:
- GCC 4.4.5 (Debian 4.4.5-8) for the target i486-linux-gnu
- GCC 4.5.2 for the target m68k-atari-mint

[Bug libstdc++/48559] parallel-mode vs C++0x

[paolo.carlini at oracle dot com]

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

--- Comment #5 from Paolo Carlini  2011-04-17 
23:17:00 UTC ---
Actually, the parallel-mode std::partition seems already ok, in any case I just
enabled its moveable.cc to actually run in parallel-mode.

[Bug libfortran/48651] DTOA float conversion issue

[kargl at gcc dot gnu.org]

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

kargl at gcc dot gnu.org changed:

   What|Removed |Added

 CC||kargl at gcc dot gnu.org

--- Comment #5 from kargl at gcc dot gnu.org 2011-04-17 23:38:48 UTC ---
(In reply to comment #3)
> (In reply to comment #2)
> > hmm, notice the typo! i have set ldnum to 0.0 but it still is printing the
> > value of dnum. What am I doing wrong.
> > 
> > $ cat sprint.c 
> > #include 
> > 
> > int
> > main ()
> > {
> >   float num = 0.9;
> >   double dnum = 0.9;
> >   long double ldnum = 25.6;
> >   printf("%50.48f\n", num);
> >   printf("%50.48lf, %d\n", num, sizeof(num));
> >   printf("%80.78f\n", dnum);
> >   printf("%80.78lf, %d\n", dnum, sizeof(dnum));
> >   printf("%80.78f\n", ldnum);
> >   printf("%80.78lf, %d\n", ldnum, sizeof(ldnum));
> 
> Check your format strings, use "lf" only for long double.

man 3 printf

 Modifiera, A, e, E, f, F, g, G
 l (ell) double (ignored, same behavior as without it)
 L   long double

L is for long double.  f and lf are essentially identical for double.

[Bug c++/48531] [C++0x][SFINAE] Hard errors with arrays of unknown bound

[jason at gcc dot gnu.org]

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

--- Comment #6 from Jason Merrill  2011-04-18 
00:50:37 UTC ---
Author: jason
Date: Mon Apr 18 00:50:31 2011
New Revision: 172632

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=172632
Log:
PR c++/48531
* typeck2.c (build_functional_cast): Disallow array type.

Added:
trunk/gcc/testsuite/g++.dg/cpp0x/sfinae16.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/init.c
trunk/gcc/cp/typeck2.c
trunk/gcc/testsuite/ChangeLog

[Bug c++/48657] New: could not convert template argument ‘VectorDimension’ to ‘unsigned int’

[daviddoria at gmail dot com]

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

   Summary: could not convert template argument ‘VectorDimension’
to ‘unsigned int’
   Product: gcc
   Version: 4.6.0
Status: UNCONFIRMED
  Severity: major
  Priority: P3
 Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: daviddo...@gmail.com


Please see this code:

http://stackoverflow.com/questions/5697546/converting-const-unsigned-int-to-unsigned-int-in-template-parameter

This works fine:

typedef Vector< int, 4 > VectorPixelType;

Where this produces the error:

  const unsigned int VectorDimension = 4;
  typedef Vector< int, VectorDimension > VectorPixelType;

[Bug libfortran/48651] DTOA float conversion issue

[jvdelisle at gcc dot gnu.org]

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

Jerry DeLisle  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||INVALID

--- Comment #6 from Jerry DeLisle  2011-04-18 
02:48:03 UTC ---
OK,

After reading the manual.

#include 

int
main ()
{
  float num1 = 0.90;
  double num2 = 0.90l;
  long double num3 = 0.90L;
  printf("%+-#48.*e\n", 46, num1);
  printf("%+-#48.*le\n", 46, num2);
  printf("%+-#48.*Le\n", 46, num3);
}

Gives:

$ ./a.out 
+8.997615814208984375e-01
+9.0002220446049250313080847263336182e-01
+8.997831595655028991131985094398e-01

This is rounding to nearest which for double, just happens to be slightly above
.9 rather than slightly below.  I conclude this is correct and not a bug in
either libgfortran or libc.

Its an artifact of inexact biray representation of a decimal number.  Closing
this PR as invalid.

[Bug rtl-optimization/48658] New: [4.3 Regression]: ICE in reload_cse_simplify_operands, at postreload.c:395

[hp at gcc dot gnu.org]

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

   Summary: [4.3 Regression]: ICE in reload_cse_simplify_operands,
at postreload.c:395
   Product: gcc
   Version: 4.3.6
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: rtl-optimization
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: h...@gcc.gnu.org
Target: sparc64-*-*


Created attachment 24024
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=24024
Preprocessed test-case; repeat with "gcc -m32  -O2 -mcpu=ultrasparc  -mvis"

I'm unfortunately just going to park this report here, not reducing it or
analyzing it or anything.  While I believe it is somewhat related to
concatenating vectors to form a larger (supported) vector and thereby enticing
register allocation to use a suitable separable multi register accessible in
the wider mode (which works for trivial code), I haven't analyzed it enough to
state it as a fact.

Anyway, the following code does not ICE with "GNU C version 4.1.3 20080704
(prerelease) (Debian 4.1.2-25) (sparc-linux-gnu)". It does ICE with gcc-4.3.x
at least up to and including the "GNU C (GCC) version 4.3.6 20110410
(prerelease) (sparc64-unknown-linux-gnu)" snapshot.  It does not ICE with
gcc-4.4.0. It does ICE with "GNU C (GCC) version 4.4.0 20080820 (experimental)
[trunk revision 139269] (sparc64-unknown-linux-gnu)" (trunk before the 4.4
branch) so bisecting trunk from that revision up to the 4.0 branch should find
a commit that fixes or hides the bug.

It is not trivially identical to bug 37053, because this bug does not appear
for gcc-4.4.0, and bug 37053 was not fixed until gcc-4.5.0 (the fix has not
been backported to the 4.4 branch IIUC).

[Bug libfortran/48602] Invalid F conversion of G descriptor for values close to powers of 10

[jvdelisle at gcc dot gnu.org]

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

--- Comment #19 from Jerry DeLisle  2011-04-18 
03:48:28 UTC ---
Author: jvdelisle
Date: Mon Apr 18 03:48:25 2011
New Revision: 172634

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=172634
Log:
2011-04-17  Jerry DeLisle  

PR libgfortran/48602
* io/write_float.def (output_float_FMT_G): Use current rounding mode
to set the rounding parameters. (output_float): Skip rounding
if value is zero.

Modified:
trunk/libgfortran/ChangeLog
trunk/libgfortran/io/write_float.def

[Bug c++/43601] Enormous increase in DLL object files size in 4.5

[dongsheng.song at gmail dot com]

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

--- Comment #60 from Dongsheng Song  
2011-04-18 03:48:19 UTC ---
With Kai's great work on binutils, after ld running 172 minutes
(usr + sys), and the memory usage growing to:

VmPeak:  5995156 kB
VmSize:  5995156 kB
VmHWM:   1900732 kB
VmRSS:   1219200 kB
VmData:  5986232 kB

The link finished:
-rwxr-xr-x 1 dongsheng dba 10499584 Apr 18 11:27 wxmsw28u_gcc.dll

I think the memory usage (6GB) and CPU time consume (172 minutes)
have a great room for improvement.

[Bug libfortran/48602] Invalid F conversion of G descriptor for values close to powers of 10

[jvdelisle at gcc dot gnu.org]

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

--- Comment #20 from Jerry DeLisle  2011-04-18 
03:53:02 UTC ---
Author: jvdelisle
Date: Mon Apr 18 03:52:59 2011
New Revision: 172635

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=172635
Log:
2011-04-17  Jerry DeLisle  

PR libgfortran/48602
* gfortran.dg/fmt_g0_6.f08: New test.

Added:
trunk/gcc/testsuite/gfortran.dg/fmt_g0_6.f08
Modified:
trunk/gcc/testsuite/ChangeLog

[Bug libfortran/48602] Invalid F conversion of G descriptor for values close to powers of 10

[jvdelisle at gcc dot gnu.org]

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

--- Comment #21 from Jerry DeLisle  2011-04-18 
03:58:25 UTC ---
Fixed on trunk. Shall we close?

[Bug rtl-optimization/48658] [4.3 Regression]: ICE in reload_cse_simplify_operands, at postreload.c:395

[hp at gcc dot gnu.org]

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

Hans-Peter Nilsson  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2011.04.18 04:12:52
  Known to work||4.4.0
Version|4.3.6   |4.3.5
   Target Milestone|--- |4.3.6
 Ever Confirmed|0   |1
  Known to fail||4.3.5

[Bug c++/48531] [C++0x][SFINAE] Hard errors with arrays of unknown bound

[jason at gcc dot gnu.org]

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

Jason Merrill  changed:

   What|Removed |Added

 Status|REOPENED|RESOLVED
 Resolution||FIXED

--- Comment #7 from Jason Merrill  2011-04-18 
04:22:32 UTC ---
Testcases in comment 4 fixed as well (apart from the separate deleted dtor
issue).

[Bug fortran/48462] [4.6/4.7 Regression] realloc on assignment: matmul Segmentation Fault with Allocatable Array

[pault at gcc dot gnu.org]

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

--- Comment #9 from Paul Thomas  2011-04-18 05:07:44 
UTC ---
Author: pault
Date: Mon Apr 18 05:07:38 2011
New Revision: 172636

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=172636
Log:
2011-04-18  Paul Thomas  

PR fortran/48462
* trans-expr.c (fcncall_realloc_result): Renamed version of
realloc_lhs_bounds_for_intrinsic_call that does not touch the
descriptor bounds anymore but makes a temporary descriptor to
hold the result.
(gfc_trans_arrayfunc_assign): Modify the reference to above
renamed function.

2011-04-18  Paul Thomas  

PR fortran/48462
* gfortran.dg/realloc_on_assign_7.f03: New test.

Added:
trunk/gcc/testsuite/gfortran.dg/realloc_on_assign_7.f03
Modified:
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/trans-expr.c
trunk/gcc/testsuite/ChangeLog

[Bug libfortran/48602] Invalid F conversion of G descriptor for values close to powers of 10

[thenlich at users dot sourceforge.net]

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

--- Comment #23 from Thomas Henlich  
2011-04-18 05:59:55 UTC ---
Created attachment 24025
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=24025
Updated test

[Bug libfortran/48602] Invalid F conversion of G descriptor for values close to powers of 10

[thenlich at users dot sourceforge.net]

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

--- Comment #22 from Thomas Henlich  
2011-04-18 05:59:14 UTC ---
(In reply to comment #7)

> +  case ROUND_ZERO:\
> +r = sign_bit ? 0.0 : 1.0;\

This should read:
r = sign_bit ? 1.0 : 0.0;\

Attaching modified test.

[Bug fortran/18918] Eventually support Fortran 2008's coarrays [co-arrays]

[burnus at gcc dot gnu.org]

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

--- Comment #37 from Tobias Burnus  2011-04-18 
05:56:08 UTC ---
Author: burnus
Date: Mon Apr 18 05:56:05 2011
New Revision: 172637

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=172637
Log:
2011-04-18  Tobias Burnus  

PR fortran/18918
* iresolve.c (gfc_resolve_image_index): Set ts.type.
* simplify.c (gfc_simplify_image_index): Don't abort if the
* bounds
are not known at compile time and handle -fcoarray=lib.
* trans-intrinsics.c (gfc_conv_intrinsic_function): Handle
IMAGE_INDEX.
(conv_intrinsic_cobound): Fix comment typo.
(trans_this_image): New function.
* trans-array.c (gfc_unlikely): Move to trans.c.
* trans.c (gfc_unlikely): Function moved from trans-array.c.
(gfc_trans_runtime_check): Use it.
* trans-io.c (gfc_trans_io_runtime_check): Ditto.
* trans.h (gfc_unlikely): Add prototype.

2011-04-18  Tobias Burnus  

PR fortran/18918
* gfortran.dg/coarray_16.f90: New.


Added:
trunk/gcc/testsuite/gfortran.dg/coarray_16.f90
Modified:
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/iresolve.c
trunk/gcc/fortran/simplify.c
trunk/gcc/fortran/trans-array.c
trunk/gcc/fortran/trans-intrinsic.c
trunk/gcc/fortran/trans-io.c
trunk/gcc/fortran/trans.c
trunk/gcc/fortran/trans.h
trunk/gcc/testsuite/ChangeLog

Re: Optimisation Problem

[vikramsp]

Thanks Eric

Eric Botcazou-3 wrote:
> 
>> But i wanted to try them indivisually. Is there any method to do so?
> 
> The compiler doesn't optimize anything if you don't pass at least -O.
> 
> -- 
> Eric Botcazou
> 
> 

-- 
View this message in context: 
http://old.nabble.com/Optimisation-Problem-tp31332686p31420992.html
Sent from the gcc - bugs mailing list archive at Nabble.com.

[Bug libfortran/48602] Invalid F conversion of G descriptor for values close to powers of 10

[thenlich at users dot sourceforge.net]

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

--- Comment #24 from Thomas Henlich  
2011-04-18 06:32:06 UTC ---
call check_all(0.995_RT, 15, 2, 0)

This still fails (with RC,G15.2 /= RC,F11.1). We need to look at why.

I am aware that N=.995 is .994... internally, but so is the value 1 - r x
10^-d

and 1 - r x 10^-d <= N must still be true.

[Bug tree-optimization/48616] -ftree-vectorize -mxop miscompiles right shift

[jakub at gcc dot gnu.org]

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

--- Comment #11 from Jakub Jelinek  2011-04-18 
06:55:17 UTC ---
Author: jakub
Date: Mon Apr 18 06:55:13 2011
New Revision: 172638

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=172638
Log:
PR tree-optimization/48616
* tree-vect-stmts.c (vectorizable_shift): If SLP, determine
whether the shift is by scalar or vector based on whether all SLP
scalar stmts have the same rhs.

* gcc.dg/pr48616.c: New test.

Added:
trunk/gcc/testsuite/gcc.dg/pr48616.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/testsuite/ChangeLog
trunk/gcc/tree-vect-stmts.c

[Bug c++/48659] New: Segmentation fault when using openMP and SSE

[npozar at quick dot cz]

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

   Summary: Segmentation fault when using openMP and SSE
   Product: gcc
   Version: 4.5.2
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: npo...@quick.cz


Created attachment 24026
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=24026
A code snippet that reproduces the error

g++ tries to save an xmm register using MOVAPD (SSE instruction) to the stack
when switching between working chunks during openMP multithreading. This
obviously causes a random segmentation fault when the stack pointer happens not
be aligned to a 16-byte boundary. 

Please see the attached code. I compile it with g++ 4.5.2 (I'm using MinGW) and
flags -O3 -msse3 -fopenmp.

It is important that the optimization is on and the compiler tries to save the
xmm register containing the constant zero between working chunks. This is the
instruction that causes the segmentation fault if ebp-0x48 is not divisible by
0x10:

0040143a:   movapd %xmm1,-0x48(%ebp) // right here
0040143f:   call 0x4014bc 



PS. I have to admit that I'm completely new to GCC, openMP or SSE (I just
learned about openMP today and I've playing with them for a couple hours only),
so I might be just doing something really stupid.