[Bug fortran/40678] Using a function as variable: ICE with 4.3, accepts invalid with 4.4/4.5

[janus at gcc dot gnu.org]

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

janus at gcc dot gnu.org changed:

   What|Removed |Added

 CC||janus at gcc dot gnu.org

--- Comment #3 from janus at gcc dot gnu.org 2011-11-03 07:07:34 UTC ---
The program is still accepted without error with 4.6 and 4.7 trunk.

However,

print *,sunshine

triggers the expected error:

  print *,sunshine
  1
Error: Function 'sunshine' requires an argument list at (1)

[Bug c/50975] New: Logical operators evaluated in wrong order if no side effects

[gcc.hall at gmail dot com]

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

 Bug #: 50975
   Summary: Logical operators evaluated in wrong order if no side
effects
Classification: Unclassified
   Product: gcc
   Version: 4.6.2
Status: UNCONFIRMED
  Severity: major
  Priority: P3
 Component: c
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: gcc.h...@gmail.com


gcc 4.6.2  -Os 

If the expressions either side of a logical operator (|| or &&) have no
side effects, gcc sometimes evaluates them in the wrong order.See
the example below.  Of course the code works, but the standard is clear,
logical operators GUARANTEE left to right evaluation.  In this case 
people use the feature as a micro optimization, putting the most likely to
succeed case first with || or vice-versa with &&.

---
#include 
int
main( int argc, char *argv[] )
{
  char *last = argv[1];

  if( *last == 10 || *last == 13 )
--last;

  printf("last = %p\n", last );
  return 0;
}
-
movb(%eax), %dl # *last_3, D.2517
cmpb$13, %dl#, D.2517
je  .L4 #,
cmpb$10, %dl#, D.2517
jne .L2 #,
.L4:
decl%eax# last
.L2:

[Bug tree-optimization/50955] [4.7 Regression] IVopts incorrectly rewrite the address of a global memory access into a local form.

[rguenther at suse dot de]

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

--- Comment #7 from rguenther at suse dot de  
2011-11-03 07:51:25 UTC ---
On Thu, 3 Nov 2011, duyuehai at gmail dot com wrote:

> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50955
> 
> --- Comment #6 from Yuehai Du  2011-11-03 06:24:58 
> UTC ---
> Let me see if i understand you correctly, you are saying that there isn't an
> easy way to fix it without hurting the performance(either consider less IV
> candidates or dumb down the alias analysis). 

Yes.

>  so this issue won't be fixed  in trunk now?

At least I can't see an easy way out.  What I was considering as _maybe_
a good final solution would be to remove TARGET_MEM_REF and instead
have TARGET_MEM_REF_ADDR, which would produce an SSA name where we
could in turn attach alias info to.  The minor downside of that is
that we lose the ability to directly specify a symbol as the base
for a TARGET_MEM_REF (which is ironically exactly the point where
things wreck in this testcase ...)

> if in that case, Avoiding the issue by set PARM isn't an option for me.  i
> still want to fix it in our private port even with an ugly patch. can we just
> add a new field in MEM_REF which specify it is local or non-nolocal
> store(enum{INVALID, LOCAL, NON-LOCAL}),  and only set it in IVOPTS before it
> rewrite the address. we will check this in is_hidden_global_store(). do this
> work in Gimple level? but i don't know if RTL optimization still delete this
> store because we don't keep points-to information.

The issue is not only in is_hidden_global_store (), but the issue
is that alias analysis thinks the store may only alias the local p1
array.  Thus you may as well get miscompiles from RTL scheduling as well.
You could already paper over the issue in question by checking
if a TARGET_MEM_REF has TMR_OFFSET or TMR_OFFSET2 != NULL_TREE in
is_hidden_global_store ().  Another way would be to make sure we
bias costs enough to make the situation less likely, for example
in get_computation_cost_at, make the address_p code unconditional.

[Bug tree-optimization/50955] [4.7 Regression] IVopts incorrectly rewrite the address of a global memory access into a local form.

[rakdver at kam dot mff.cuni.cz]

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

--- Comment #8 from rakdver at kam dot mff.cuni.cz  2011-11-03 08:06:52 UTC ---
> > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50955
> > 
> > --- Comment #6 from Yuehai Du  2011-11-03 
> > 06:24:58 UTC ---
> > Let me see if i understand you correctly, you are saying that there isn't an
> > easy way to fix it without hurting the performance(either consider less IV
> > candidates or dumb down the alias analysis). 
> 
> Yes.
> 
> >  so this issue won't be fixed  in trunk now?
> 
> At least I can't see an easy way out.  What I was considering as _maybe_
> a good final solution would be to remove TARGET_MEM_REF and instead
> have TARGET_MEM_REF_ADDR, which would produce an SSA name where we
> could in turn attach alias info to.  The minor downside of that is
> that we lose the ability to directly specify a symbol as the base
> for a TARGET_MEM_REF (which is ironically exactly the point where
> things wreck in this testcase ...)

or we could just start associating alias info with memory references instead
of with pointers.  Either way, this would be a major change.  Anyway, let
me have a look at this, perhaps I can come up with something less intrusive.

> > if in that case, Avoiding the issue by set PARM isn't an option for me.  i
> > still want to fix it in our private port even with an ugly patch. can we 
> > just
> > add a new field in MEM_REF which specify it is local or non-nolocal
> > store(enum{INVALID, LOCAL, NON-LOCAL}),  and only set it in IVOPTS before it
> > rewrite the address. we will check this in is_hidden_global_store(). do this
> > work in Gimple level? but i don't know if RTL optimization still delete this
> > store because we don't keep points-to information.
> 
> The issue is not only in is_hidden_global_store (), but the issue
> is that alias analysis thinks the store may only alias the local p1
> array.  Thus you may as well get miscompiles from RTL scheduling as well.
> You could already paper over the issue in question by checking
> if a TARGET_MEM_REF has TMR_OFFSET or TMR_OFFSET2 != NULL_TREE in
> is_hidden_global_store ().  Another way would be to make sure we
> bias costs enough to make the situation less likely, for example
> in get_computation_cost_at, make the address_p code unconditional.

Making a miscompilation "less likely" is really not a good idea; we need to
really fix the problem, even if it means some performance penalty.

[Bug c++/50976] New: [C++0x] literal operator with unsigned long long parameter not accepted

[daniel.kruegler at googlemail dot com]

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

 Bug #: 50976
   Summary: [C++0x] literal operator with unsigned long long
parameter not accepted
Classification: Unclassified
   Product: gcc
   Version: 4.7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: daniel.krueg...@googlemail.com
CC: 3dw...@verizon.net


gcc 4.7.0 20111029 (experimental) in C++0x mode rejects the following code:

//---
int operator "" _abc(unsigned long long int);
//---

with the message:

"error: 'int operator"" _abc(long long unsigned int)' has invalid argument
list"

but according to 13.5.8 p3 this should be a valid parameter-declaration-clause
and the code should be accepted.

[Bug ada/50934] Attribute Max_Size_In_Storage_Elements is wrong for controlled types

[simon at pushface dot org]

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

--- Comment #2 from simon at pushface dot org 2011-11-03 08:14:36 UTC ---
Created attachment 25699
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=25699
Simpler demonstrator

[Bug tree-optimization/50955] [4.7 Regression] IVopts incorrectly rewrite the address of a global memory access into a local form.

[rguenth at gcc dot gnu.org]

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

--- Comment #9 from Richard Guenther  2011-11-03 
08:18:05 UTC ---
(In reply to comment #8)
> > > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50955
> > > 
> > > --- Comment #6 from Yuehai Du  2011-11-03 
> > > 06:24:58 UTC ---
> > > Let me see if i understand you correctly, you are saying that there isn't 
> > > an
> > > easy way to fix it without hurting the performance(either consider less IV
> > > candidates or dumb down the alias analysis). 
> > 
> > Yes.
> > 
> > >  so this issue won't be fixed  in trunk now?
> > 
> > At least I can't see an easy way out.  What I was considering as _maybe_
> > a good final solution would be to remove TARGET_MEM_REF and instead
> > have TARGET_MEM_REF_ADDR, which would produce an SSA name where we
> > could in turn attach alias info to.  The minor downside of that is
> > that we lose the ability to directly specify a symbol as the base
> > for a TARGET_MEM_REF (which is ironically exactly the point where
> > things wreck in this testcase ...)
> 
> or we could just start associating alias info with memory references instead
> of with pointers.  Either way, this would be a major change.  Anyway, let
> me have a look at this, perhaps I can come up with something less intrusive.
> 
> > > if in that case, Avoiding the issue by set PARM isn't an option for me.  i
> > > still want to fix it in our private port even with an ugly patch. can we 
> > > just
> > > add a new field in MEM_REF which specify it is local or non-nolocal
> > > store(enum{INVALID, LOCAL, NON-LOCAL}),  and only set it in IVOPTS before 
> > > it
> > > rewrite the address. we will check this in is_hidden_global_store(). do 
> > > this
> > > work in Gimple level? but i don't know if RTL optimization still delete 
> > > this
> > > store because we don't keep points-to information.
> > 
> > The issue is not only in is_hidden_global_store (), but the issue
> > is that alias analysis thinks the store may only alias the local p1
> > array.  Thus you may as well get miscompiles from RTL scheduling as well.
> > You could already paper over the issue in question by checking
> > if a TARGET_MEM_REF has TMR_OFFSET or TMR_OFFSET2 != NULL_TREE in
> > is_hidden_global_store ().  Another way would be to make sure we
> > bias costs enough to make the situation less likely, for example
> > in get_computation_cost_at, make the address_p code unconditional.
> 
> Making a miscompilation "less likely" is really not a good idea; we need to
> really fix the problem, even if it means some performance penalty.

I agree.  I think the main difficulty is to detect this issue reliably
(and not too conservatively) - arranging for the TARGET_MEM_REF to look
ok from an aliasing point of view shouldn't be too difficult then
(simply use a INTEGER_CST zero TMR_BASE and shuffle the real base to
TMR_INDEX2).

[Bug tree-optimization/50969] 17% degradation in 168.wupwise for interleave via permutation

[rguenth at gcc dot gnu.org]

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

--- Comment #2 from Richard Guenther  2011-11-03 
08:19:01 UTC ---
Yes, sounds like a cost model issue.

[Bug middle-end/50971] Only one loop detected when there should be two

[rguenth at gcc dot gnu.org]

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

Richard Guenther  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2011-11-03
 CC||rakdver at gcc dot gnu.org
 Ever Confirmed|0   |1

--- Comment #1 from Richard Guenther  2011-11-03 
08:23:48 UTC ---
Confirmed.

[Bug fortran/50974] ICE on invalid on function used as variable

[rguenth at gcc dot gnu.org]

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

Richard Guenther  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2011-11-03
 Ever Confirmed|0   |1

--- Comment #1 from Richard Guenther  2011-11-03 
08:25:22 UTC ---
It looks like the function pointer is casted to FP in gimple.  That's
not allowed (obviously).

[Bug c/50975] Logical operators evaluated in wrong order if no side effects

[rguenth at gcc dot gnu.org]

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

--- Comment #1 from Richard Guenther  2011-11-03 
08:26:33 UTC ---
But ... you can't tell the difference.  So this is a valid optimization.

[Bug tree-optimization/50912] [4.7 regression] gimple assertion failure at gimple.h:1940 with -msse2

[irar at gcc dot gnu.org]

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

--- Comment #2 from irar at gcc dot gnu.org 2011-11-03 08:44:41 UTC ---
Author: irar
Date: Thu Nov  3 08:44:35 2011
New Revision: 180819

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=180819
Log:

PR tree-optimization/50912
* tree-vectorizer.h (slp_void_p): New.
(struct _slp_tree): Replace left and right with children.  Update
documentation.
(struct _slp_oprnd_info): New.
(vect_get_vec_defs): Declare.
(vect_get_slp_defs): Update arguments.
* tree-vect-loop.c (vect_create_epilog_for_reduction): Call
vect_get_vec_defs instead of vect_get_slp_defs.
(vectorizable_reduction): Likewise.
* tree-vect-stmts.c (vect_get_vec_defs): Remove static, add argument.
Update call to vect_get_slp_defs.
(vectorizable_conversion): Update call to vect_get_vec_defs.
(vectorizable_assignment, vectorizable_shift,
vectorizable_operation): Likewise.
(vectorizable_type_demotion): Call vect_get_vec_defs instead of
vect_get_slp_defs.
(vectorizable_type_promotion, vectorizable_store): Likewise.
(vect_analyze_stmt): Fix typo.
* tree-vect-slp.c (vect_free_slp_tree): Update SLP tree traversal.
(vect_print_slp_tree, vect_mark_slp_stmts,
vect_mark_slp_stmts_relevant, vect_slp_rearrange_stmts,
vect_detect_hybrid_slp_stmts, vect_slp_analyze_node_operations,
vect_schedule_slp_instance): Likewise.
(vect_create_new_slp_node): New.
(vect_create_oprnd_info, vect_free_oprnd_info): Likewise.
(vect_get_and_check_slp_defs): Pass information about defs using
oprnds_info, allow any number of operands.
(vect_build_slp_tree): Likewise.  Update calls to
vect_get_and_check_slp_defs.  Fix comments.
(vect_analyze_slp_instance): Move node creation to
vect_create_new_slp_node.
(vect_get_slp_defs): Allow any number of operands.


Added:
trunk/gcc/testsuite/gnat.dg/loop_optimization10.adb
trunk/gcc/testsuite/gnat.dg/loop_optimization10.ads
trunk/gcc/testsuite/gnat.dg/loop_optimization10_pkg.ads
Modified:
trunk/gcc/ChangeLog
trunk/gcc/testsuite/ChangeLog
trunk/gcc/tree-vect-data-refs.c
trunk/gcc/tree-vect-loop.c
trunk/gcc/tree-vect-slp.c
trunk/gcc/tree-vect-stmts.c
trunk/gcc/tree-vectorizer.h

[Bug tree-optimization/50912] [4.7 regression] gimple assertion failure at gimple.h:1940 with -msse2

[irar at il dot ibm.com]

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

Ira Rosen  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED

--- Comment #3 from Ira Rosen  2011-11-03 08:48:51 UTC 
---
Fixed.

[Bug tree-optimization/50730] SLP vectorization confused by unrelated DRs

[irar at il dot ibm.com]

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

Ira Rosen  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED

--- Comment #5 from Ira Rosen  2011-11-03 08:49:29 UTC 
---
Fixed.

[Bug tree-optimization/50819] missed SLP vectorization

[irar at il dot ibm.com]

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

Ira Rosen  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED

--- Comment #5 from Ira Rosen  2011-11-03 08:50:48 UTC 
---
Fixed.

[Bug libgomp/50977] New: non-deterministic failure in cactusADM using openmp

[razya at gcc dot gnu.org]

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

 Bug #: 50977
   Summary: non-deterministic failure in cactusADM using openmp
Classification: Unclassified
   Product: gcc
   Version: 4.7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libgomp
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: ra...@gcc.gnu.org


I have been exploring non-deterministic failures in cactusADM (when 
autopar is enabled with a low threshold).
The failures are actually the program getting stuck, when one of the 
threads exits and the others remain
waiting on a team barrier (futex_wait). 

I disabled autopar completely, and MANUALLY parallelized (using openmp 
pragmas) only one loop in cactusADM.
I attached below the code before and after my changes.
Running the code produces the exact same problem.
This makes me more confident that the problem is indeed with libgomp and 
not autopar, and is probably race condition.

One of the threads somehow passes the two barriers that it is supposed to 
be stuck on, (the team barrier and the docking barrier)
and exits while the other threads are waiting for its arrival on the team 
barrier.

The barriers in libgomp are implemented using futex:

static inline void
futex_wait (int *addr, int val)
{
  long err = sys_futex0 (addr, gomp_futex_wait, val);
  if (__builtin_expect (err == ENOSYS, 0))
{
  gomp_futex_wait &= ~FUTEX_PRIVATE_FLAG;
  gomp_futex_wake &= ~FUTEX_PRIVATE_FLAG;
  sys_futex0 (addr, gomp_futex_wait, val);
}
}


sys_futex0 (int *addr, int op, int val)
{
  register long int r0  __asm__ ("r0");
  register long int r3  __asm__ ("r3");
  register long int r4  __asm__ ("r4");
  register long int r5  __asm__ ("r5");
  register long int r6  __asm__ ("r6");

  r0 = SYS_futex;
  r3 = (long) addr;
  r4 = op;
  r5 = val;
  r6 = 0;

  /* ??? The powerpc64 sysdep.h file clobbers ctr; the powerpc32 sysdep.h
 doesn't.  It doesn't much matter for us.  In the interest of unity,
 go ahead and clobber it always.  */

  __asm volatile ("sc; mfcr %0"
  : "=r"(r0), "=r"(r3), "=r"(r4), "=r"(r5), "=r"(r6)
  : "r"(r0), "r"(r3), "r"(r4), "r"(r5), "r"(r6)
  : "r7", "r8", "r9", "r10", "r11", "r12",
"cr0", "ctr", "memory");
  if (__builtin_expect (r0 & (1 << 28), 0))
return r3;
  return 0;
}


Thanks,
Razys

[Bug libgomp/50977] non-deterministic failure in cactusADM using openmp

[razya at gcc dot gnu.org]

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

--- Comment #1 from razya at gcc dot gnu.org 2011-11-03 09:14:20 UTC ---
Created attachment 25700
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=25700
loop annotated with openmp prgmas

[Bug target/50978] New: libgcc build fails - unable to find unwind-arm-common.h

[mgretton at sourceware dot org]

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

 Bug #: 50978
   Summary: libgcc build fails - unable to find
unwind-arm-common.h
Classification: Unclassified
   Product: gcc
   Version: 4.7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: mgret...@sourceware.org
CC: ramana.radhakrish...@arm.com, rearn...@.arm.com,
r...@gcc.gnu.org
Target: arm-none-eabi


Current SVN fails to build libgcc for an arm-none-eabi target because it can't
find unwind-arm-common.h:

In file included from
/work/upstream-checkouts/gcc/libgcc/config/arm/unwind-arm.c:24:0:
./unwind.h:31:31: fatal error: unwind-arm-common.h: No such file or directory
compilation terminated.


I think that the recent move of source from gcc/config to libgcc/config failed
to move the EXTRA_HEADERS line from gcc/config/arm/t-bpabi and
gcc/config/arm/t-symbian to libgcc/config/arm/t-bpabi and
libgcc/config/arm/t-symbian respectively.

However, making the naive change doesn't work as unwind-arm-common.h lives in
gcc/ginclude.  Does the header have to move directory?

GCC is configured as follows:

/work/upstream-checkouts/gcc/configure --target=arm-master-eabi
--prefix=/work/builds/install
--with-sysroot=/work/builds/install/arm-master-eabi --with-newlib --with-gnu-as
--with-gnu-ld --enable-languages=c,c++ --with-gmp=.../linux_x86_64
--with-mpfr=.../linux_x86_64 --with-mpc=.../linux_x86_64
--with-libelf=.../linux_x86_64 --disable-lto --disable-shared --disable-nls
--disable-threads --disable-tls --enable-checking=yes --with-cpu=cortex-a9
--with-fpu=neon --with-float=softfp 

Checked against gcc trunk SVN revision 180820

[Bug rtl-optimization/50448] [4.5/4.6/4.7 Regression] Missed optimization accessing struct component with integer address

[gjl at gcc dot gnu.org]

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

--- Comment #5 from Georg-Johann Lay  2011-11-03 
11:01:55 UTC ---
(In reply to comment #0)

> foo:
> ldi r24,lo8(-86)
> ldi r30,lo8(2752)
> ldi r31,hi8(2752)
> std Z+3,r24
> .L2:
> lds r24,2754
> sbrs r24,7
> rjmp .L2
> ldi r24,lo8(-69)
> ldi r30,lo8(2752)
> ldi r31,hi8(2752)
> std Z+3,r24
> [...]

This is the code generated with Paolo's patch applied:

foo:
ldi r24,lo8(-86)
sts 2755,r24
.L2:
lds r24,2754
sbrs r24,7
rjmp .L2
ldi r24,lo8(-69)
sts 2755,r24
[...]

[Bug c++/50976] [C++0x] literal operator with unsigned long long parameter not accepted

[3dw4rd at verizon dot net]

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

--- Comment #1 from Ed Smith-Rowland <3dw4rd at verizon dot net> 2011-11-03 
11:49:46 UTC ---
I can't reproduce this error.
I have test cases in the tree that look exactly like this.
Look at udlit-args.C.  Grep "long long" in
gcc/testsuite/g++.dg/cpp0x/udlit-*.C.
I've had dozens of literal operators like this for months.

Could it be that there is a 'template' just above the declaration? 
Literal operator templates must have void argument.

[Bug c++/50976] [C++0x] literal operator with unsigned long long parameter not accepted

[daniel.kruegler at googlemail dot com]

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

--- Comment #2 from Daniel Krügler  
2011-11-03 12:03:51 UTC ---
Created attachment 25701
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=25701
Test case

[Bug c++/50976] [C++0x] literal operator with unsigned long long parameter not accepted

[daniel.kruegler at googlemail dot com]

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

--- Comment #3 from Daniel Krügler  
2011-11-03 12:05:06 UTC ---
(In reply to comment #1)
> Could it be that there is a 'template' just above the declaration? 
> Literal operator templates must have void argument.

No, there is nothing like this nearby. I compiled the code as written with the
flags

-std=c++0x -Wall

(with or without -pedantic), see attached test case. To give you more
information, here the result of the complete "-v -save-temps -std=c++0x -Wall"
compile step:

Built by Equation Solution .
Using built-in specs.
COLLECT_GCC=C:\Program Files\Develop\gcc\bin\gcc.exe
COLLECT_LTO_WRAPPER=c:/program
files/develop/gcc/bin/../libexec/gcc/x86_64-w64-mingw32/4.7.0/lto-wrapper.exe
Target: x86_64-w64-mingw32
Configured with: ../gcc-4.7-20111029-mingw/configure --host=x86_64-w64-mingw32
--build=x86_64-unknown-linux-gnu --target=x86_64-w6
4-mingw32
--prefix=/home/gfortran/gcc-home/binary/mingw32/native/x86_64/gcc/4.7-20111029
--with-sysroot=/home/gfortran/gcc-home/bi
nary/mingw32/cross/x86_64/gcc/4.7-20111029 --with-gcc --with-gnu-ld
--with-gnu-as --with-gmp=/home/gfortran/gcc-home/binary/mingw3
2/native/x86_64/gmp
--with-mpfr=/home/gfortran/gcc-home/binary/mingw32/native/x86_64/mpfr
--with-mpc=/home/gfortran/gcc-home/binar
y/mingw32/native/x86_64/mpc
--with-ppl=/home/gfortran/gcc-home/binary/mingw32/native/x86_64/ppl
--with-cloog=/home/gfortran/gcc-ho
me/binary/mingw32/native/x86_64/cloog --with-host-libstdcxx='-lstdc++ -lsupc++
-lm' --enable-targets=i686-w64-mingw32,x86_64-w64-m
ingw32 --enable-cloog-backend=ppl --enable-lto --enable-languages=c,c++,fortran
--enable-libgomp --enable-threads=win32 --enable-s
tatic --enable-shared=lto-plugin --enable-plugins --enable-ld=yes
--enable-libquadmath --enable-libquadmath-support --disable-nls
--disable-tls --disable-win32-registry
Thread model: win32
gcc version 4.7.0 20111029 (experimental) (GCC)
COLLECT_GCC_OPTIONS='-v' '-save-temps' '-std=c++0x' '-Wall' '-mtune=generic'
'-march=x86-64'
 c:/program
files/develop/gcc/bin/../libexec/gcc/x86_64-w64-mingw32/4.7.0/cc1plus.exe -E
-quiet -v -iprefix c:\program files\devel
op\gcc\bin\../lib/gcc/x86_64-w64-mingw32/4.7.0/ -U_REENTRANT main.cpp
-mtune=generic -march=x86-64 -std=c++0x -Wall -fpch-preproce
ss -o main.ii
ignoring duplicate directory "c:/program
files/develop/gcc/lib/gcc/../../lib/gcc/x86_64-w64-mingw32/4.7.0/../../../../include/c++/
4.7.0"
ignoring duplicate directory "c:/program
files/develop/gcc/lib/gcc/../../lib/gcc/x86_64-w64-mingw32/4.7.0/../../../../include/c++/
4.7.0/x86_64-w64-mingw32"
ignoring duplicate directory "c:/program
files/develop/gcc/lib/gcc/../../lib/gcc/x86_64-w64-mingw32/4.7.0/../../../../include/c++/
4.7.0/backward"
ignoring duplicate directory "c:/program
files/develop/gcc/lib/gcc/../../lib/gcc/x86_64-w64-mingw32/4.7.0/include"
ignoring nonexistent directory
"/home/gfortran/gcc-home/binary/mingw32/cross/x86_64/gcc/4.7-20111029/home/gfortran/gcc-home/binary
/mingw32/native/x86_64/gcc/4.7-20111029/lib/gcc/x86_64-w64-mingw32/4.7.0/../../../../include"
ignoring duplicate directory "c:/program
files/develop/gcc/lib/gcc/../../lib/gcc/x86_64-w64-mingw32/4.7.0/include-fixed"
ignoring duplicate directory "c:/program
files/develop/gcc/lib/gcc/../../lib/gcc/x86_64-w64-mingw32/4.7.0/../../../../x86_64-w64-m
ingw32/include"
ignoring nonexistent directory
"/home/gfortran/gcc-home/binary/mingw32/cross/x86_64/gcc/4.7-20111029/mingw/include"
#include "..." search starts here:
#include <...> search starts here:
 c:\program
files\develop\gcc\bin\../lib/gcc/x86_64-w64-mingw32/4.7.0/../../../../include/c++/4.7.0
 c:\program
files\develop\gcc\bin\../lib/gcc/x86_64-w64-mingw32/4.7.0/../../../../include/c++/4.7.0/x86_64-w64-mingw32
 c:\program
files\develop\gcc\bin\../lib/gcc/x86_64-w64-mingw32/4.7.0/../../../../include/c++/4.7.0/backward
 c:\program files\develop\gcc\bin\../lib/gcc/x86_64-w64-mingw32/4.7.0/include
 c:\program
files\develop\gcc\bin\../lib/gcc/x86_64-w64-mingw32/4.7.0/include-fixed
 c:\program
files\develop\gcc\bin\../lib/gcc/x86_64-w64-mingw32/4.7.0/../../../../x86_64-w64-mingw32/include
End of search list.
COLLECT_GCC_OPTIONS='-v' '-save-temps' '-std=c++0x' '-Wall' '-mtune=generic'
'-march=x86-64'
 c:/program
files/develop/gcc/bin/../libexec/gcc/x86_64-w64-mingw32/4.7.0/cc1plus.exe
-fpreprocessed main.ii -quiet -dumpbase main
.cpp -mtune=generic -march=x86-64 -auxbase main -Wall -std=c++0x -version -o
main.s
GNU C++ (GCC) version 4.7.0 20111029 (experimental) (x86_64-w64-mingw32)
compiled by GNU C version 4.7.0 20111029 (experimental), GMP version
5.0.1, MPFR version 3.0.0, MPC version 0.9
GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096
GNU C++ (GCC) version 4.7.0 20111029 (experimental) (x86_64-w64-mingw32)
compiled by GNU C version 4.7.0 20111029 (experimental), GMP version
5.0.1, MPFR version 3.0.0, MPC version 0.9
GGC heuristics: --param ggc-min-expand=30 --param ggc-mi

[Bug fortran/50960] [OOP] vtables not marked as constant

[janus at gcc dot gnu.org]

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

--- Comment #12 from janus at gcc dot gnu.org 2011-11-03 12:06:48 UTC ---
In summary, the combined patches of comment 1, comment 9 and comment 10:


Index: gcc/fortran/class.c
===
--- gcc/fortran/class.c(revision 180820)
+++ gcc/fortran/class.c(working copy)
@@ -424,7 +424,7 @@ gfc_find_derived_vtab (gfc_symbol *derived)
 {
   gfc_get_symbol (name, ns, &vtab);
   vtab->ts.type = BT_DERIVED;
-  if (gfc_add_flavor (&vtab->attr, FL_VARIABLE, NULL,
+  if (gfc_add_flavor (&vtab->attr, FL_PARAMETER, NULL,
   &gfc_current_locus) == FAILURE)
 goto cleanup;
   vtab->attr.target = 1;
Index: gcc/fortran/resolve.c
===
--- gcc/fortran/resolve.c(revision 180820)
+++ gcc/fortran/resolve.c(working copy)
@@ -9503,7 +9503,7 @@ resolve_values (gfc_symbol *sym)
 {
   gfc_try t;

-  if (sym->value == NULL)
+  if (sym->value == NULL || sym->attr.use_assoc)
 return;

   if (sym->value->expr_type == EXPR_STRUCTURE)
@@ -11971,7 +11971,7 @@ resolve_fl_parameter (gfc_symbol *sym)
   /* Make sure the types of derived parameters are consistent.  This
  type checking is deferred until resolution because the type may
  refer to a derived type from the host.  */
-  if (sym->ts.type == BT_DERIVED
+  if (sym->ts.type == BT_DERIVED && sym->value
   && !gfc_compare_types (&sym->ts, &sym->value->ts))
 {
   gfc_error ("Incompatible derived type in PARAMETER at %L",



show two remaining testsuite failures:

FAIL: gfortran.dg/extends_type_of_1.f03  -O0  (internal compiler error)
FAIL: gfortran.dg/extends_type_of_3.f90  -O  (internal compiler error)

(cf. comment 11)

[Bug c/50975] Logical operators evaluated in wrong order if no side effects

[gcc.hall at gmail dot com]

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

--- Comment #2 from Jeremy  2011-11-03 12:37:41 UTC 
---
(In reply to comment #1)
> But ... you can't tell the difference.  So this is a valid optimization.

You can tell the difference in execution time.

And why is this an "optimization"?  In this case, I cant see how it can improve
the code other than to lose any input from the programmer, who knows when the
data is biased.  I guess it might help in a more complex expression.

I think this is different from the controversy over the handling of signed
integer overflow.  There is no undefined behavior here.  The language standard
from K&R to the present day explicitly states the evaluation order is
guaranteed left to right with these operators.

[Bug c++/50976] [C++0x] literal operator with unsigned long long parameter not accepted

[3dw4rd at verizon dot net]

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

--- Comment #4 from Ed Smith-Rowland <3dw4rd at verizon dot net> 2011-11-03 
12:47:41 UTC ---
I wonder if the testsuite was run when the gcc was built.
It should have raised a boatload of flags there.

Your test case runs like a charm on x86_64-unknown-linux-gnu.
--
ed@bad-horse:~/udlit_debug$ ../bin/bin/g++ -v
Using built-in specs.
COLLECT_GCC=../bin/bin/g++
COLLECT_LTO_WRAPPER=/home/ed/bin/libexec/gcc/x86_64-unknown-linux-gnu/4.7.0/lto-wrapper
Target: x86_64-unknown-linux-gnu
Configured with: ../gcc/configure --prefix=/home/ed/bin --with-gmp=/usr/local
--with-mpfr=/usr/local --with-mpc=/usr/local --with-ppl=/usr/local
--with-cloog=/usr/local --enable-cloog-backend=isl --enable-lto
--enable-languages=c,c++,fortran,go,lto,objc,obj-c++
Thread model: posix
gcc version 4.7.0 20111031 (experimental) (GCC) 
ed@bad-horse:~/udlit_debug$ ../bin/bin/g++ -std=c++0x -c main.cpp 
ed@bad-horse:~/udlit_debug$ 
--

I can't imagine how this could be target dependent though.
I wonder if build logs could be found.

[Bug c++/50976] [C++0x] literal operator with unsigned long long parameter not accepted

[redi at gcc dot gnu.org]

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

--- Comment #5 from Jonathan Wakely  2011-11-03 
12:54:03 UTC ---
(In reply to comment #4)
> Your test case runs like a charm on x86_64-unknown-linux-gnu.

I can confirm that, using the 4.7-20111029 snapshot 

> I can't imagine how this could be target dependent though.

Yes, very strange.

[Bug target/50906] e500 exception unwinding under "-Os" causes SIGSEGV

[amodra at gmail dot com]

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

--- Comment #8 from Alan Modra  2011-11-03 12:54:32 
UTC ---
Created attachment 25702
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=25702
Proposed mainline fix

[Bug target/50906] e500 exception unwinding under "-Os" causes SIGSEGV

[amodra at gmail dot com]

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

--- Comment #9 from Alan Modra  2011-11-03 12:55:29 
UTC ---
Created attachment 25703
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=25703
gcc-4.6 fix

[Bug target/50906] e500 exception unwinding under "-Os" causes SIGSEGV

[amodra at gmail dot com]

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

--- Comment #10 from Alan Modra  2011-11-03 12:59:10 
UTC ---
Please test out these patches.  bootstrap and regression tests with -Os in
BOOT_CFLAGS on spe would be ideal.  I'll be running a powerpc-linux regression
test, but can't do that for spe.

[Bug c++/50976] [C++0x] literal operator with unsigned long long parameter not accepted

[daniel.kruegler at googlemail dot com]

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

--- Comment #6 from Daniel Krügler  
2011-11-03 13:04:57 UTC ---
(In reply to comment #4)
> gcc version 4.7.0 20111031 (experimental) (GCC) 

This difference shouldn't be essential, should it?

> I wonder if the testsuite was run when the gcc was built.
> It should have raised a boatload of flags there.
[..]
> I can't imagine how this could be target dependent though.
> I wonder if build logs could be found.

I wouldn't know where to find them :-(, but I always get my gcc installation
from

http://www.equation.com/servlet/equation.cmd?fa=fortran

and I cannot remember of having found a problem with them.

Could we possibly keep the bug open until - lets say - Monday? Hopefully a new
build is available then which I could try. Any other suggestion?

[Bug c++/50976] [C++0x] literal operator with unsigned long long parameter not accepted

[daniel.kruegler at googlemail dot com]

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

--- Comment #7 from Daniel Krügler  
2011-11-03 13:06:12 UTC ---
(In reply to comment #6)
> (In reply to comment #4)
> > gcc version 4.7.0 20111031 (experimental) (GCC) 
> 
> This difference shouldn't be essential, should it?

(Sorry, my reply conflicted with Jonathan, his answer makes this question mood)

[Bug lto/48217] lto mishandles quotes in command line defines

[rguenth at gcc dot gnu.org]

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

--- Comment #4 from Richard Guenther  2011-11-03 
13:13:39 UTC ---
Author: rguenth
Date: Thu Nov  3 13:13:33 2011
New Revision: 180822

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=180822
Log:
2011-11-03  Richard Guenther  

PR lto/48217
* lto-wrapper.c (get_options_from_collect_gcc_options): Properly
decode an encoded literal '.

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

[Bug lto/48217] lto mishandles quotes in command line defines

[rguenth at gcc dot gnu.org]

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

Richard Guenther  changed:

   What|Removed |Added

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

--- Comment #5 from Richard Guenther  2011-11-03 
13:14:23 UTC ---
Fixed.

[Bug c++/50976] [C++0x] literal operator with unsigned long long parameter not accepted

[redi at gcc dot gnu.org]

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

--- Comment #8 from Jonathan Wakely  2011-11-03 
13:23:24 UTC ---
(In reply to comment #6)
> http://www.equation.com/servlet/equation.cmd?fa=fortran

That page implies those binaries contain some source modifications, but it's
not clear what they are or if they're relevant to this case.  They're obliged
by the GPL to provide source, so you could try emailing their support address
to ask what changes they make.

[Bug target/50970] Function pointer dereferenced twice in if statement on Arm cpu

[emillbrandt at dekaresearch dot com]

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

--- Comment #3 from Eric Millbrandt  
2011-11-03 13:30:15 UTC ---
We found the problem in an implementation of a hierarchical state machine from
Practical Statecharts in C/C++ (CMP Books, 2002).  The supplied example is a
condensed reproduction of the code that produces the problem.  I can supply you
with the original code if you prefer.

[Bug c++/50976] [C++0x] literal operator with unsigned long long parameter not accepted

[3dw4rd at verizon dot net]

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

--- Comment #9 from Ed Smith-Rowland <3dw4rd at verizon dot net> 2011-11-03 
13:47:15 UTC ---
This may well happen if perhaps 'unsigned long long int' doesn't map to
long_long_unsigned_type_node for this target.

Daniel, just for fun, and as a possible work around for you, what happens if
you use 'unsigned long int' or 'unsigned int'?

Ed

[Bug target/50979] New: sparc mcpu=v8 libgcc2 "mul32" not enabled for "smul" or "umul"

[joel at gcc dot gnu.org]

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

 Bug #: 50979
   Summary: sparc mcpu=v8 libgcc2 "mul32" not enabled for "smul"
or "umul"
Classification: Unclassified
   Product: gcc
   Version: 4.7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: j...@gcc.gnu.org


Revision: Thu Nov  3 12:25:34 UTC 2011 (revision 180821)
Target: sparc-rtems4.11

home2/joel/build/b-sparc-gcc/./gcc/xgcc -B/home2/joel/build/b-sparc-gcc/./gcc/
-nostdinc -B/home2/joel/build/b-sparc-gcc/sparc-rtems4.11/newlib/ -isystem
/home2/joel/build/b-sparc-gcc/sparc-rtems4.11/newlib/targ-include -isystem
/users/joel/test-gcc/gcc-svn/newlib/libc/include
-B/users/joel/test-gcc/install-svn/sparc-rtems4.11/bin/
-B/users/joel/test-gcc/install-svn/sparc-rtems4.11/lib/ -isystem
/users/joel/test-gcc/install-svn/sparc-rtems4.11/include -isystem
/users/joel/test-gcc/install-svn/sparc-rtems4.11/sys-include-g -O2 -mcpu=v8
-O2  -g -O2 -DIN_GCC -DCROSS_DIRECTORY_STRUCTURE  -W -Wall -Wno-narrowing
-Wwrite-strings -Wcast-qual -Wstrict-prototypes -Wmissing-prototypes
-Wold-style-definition  -isystem ./include 
-I/users/joel/test-gcc/gcc-svn/libgcc/../newlib/libc/sys/rtems/include -g
-DIN_LIBGCC2 -fbuilding-libgcc -fno-stack-protector -Dinhibit_libc
-I/users/joel/test-gcc/gcc-svn/libgcc/../newlib/libc/sys/rtems/include -I. -I.
-I../../.././gcc -I/users/joel/test-gcc/gcc-svn/libgcc
-I/users/joel/test-gcc/gcc-svn/libgcc/.
-I/users/joel/test-gcc/gcc-svn/libgcc/../gcc
-I/users/joel/test-gcc/gcc-svn/libgcc/../include  -DHAVE_CC_TLS  -o _muldi3.o
-MT _muldi3.o -MD -MP -MF _muldi3.dep -DL_muldi3 -c
/users/joel/test-gcc/gcc-svn/libgcc/libgcc2.c 
/tmp/ccIMWbso.s: Assembler messages:
/tmp/ccIMWbso.s:16: Error: Hardware capability "mul32" not enabled for "smul".
/tmp/ccIMWbso.s:18: Error: Hardware capability "mul32" not enabled for "smul".
/tmp/ccIMWbso.s:22: Error: Hardware capability "mul32" not enabled for "umul".

[Bug target/50979] sparc mcpu=v8 libgcc2 "mul32" not enabled for "smul" or "umul"

[joel at gcc dot gnu.org]

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

--- Comment #1 from Joel Sherrill  2011-11-03 13:56:07 
UTC ---
Created attachment 25704
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=25704
Preprocessed source for failure case

Preprocessed source code which trips issue.  It can be reproduced with this
simplified command line.

/home2/joel/build/b-sparc-gcc/./gcc/xgcc \
   -B/home2/joel/build/b-sparc-gcc/./gcc/  \
   -mcpu=v8 -O2  \
   -c /tmp/pr50979.c

[Bug c++/50976] [C++0x] literal operator with unsigned long long parameter not accepted

[daniel.kruegler at googlemail dot com]

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

--- Comment #10 from Daniel Krügler  
2011-11-03 13:58:53 UTC ---
(In reply to comment #8)
I just send a corresponding email to the support address of this page. In
addition I removed my previous gcc installation completely and installed it
freshly, but no difference.

(In reply to comment #9)
> This may well happen if perhaps 'unsigned long long int' doesn't map to
> long_long_unsigned_type_node for this target.
> 
> Daniel, just for fun, and as a possible work around for you, what happens if
> you use 'unsigned long int' or 'unsigned int'?

I had the same idea and tested all these combinations including all signed
int/long/long long variants. I also validated that std::uintmax_t equals
unsigned long long. No difference: All forms are rejected in the same way. I
also tested all supported literal operator signatures. All of them work as
expected, except this one :-(.

[Bug fortran/50960] [OOP] vtables not marked as constant

[burnus at gcc dot gnu.org]

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

--- Comment #13 from Tobias Burnus  2011-11-03 
14:03:40 UTC ---
Patch for the issue of comment 5: Constants (PARAMETER) which are exists as
global static variables were not marked as TREE_READONLY.

With the patch below (not regtested), the function call is optimized away in:

module m
  integer, parameter :: PARA(*) = [1,2,3,4,5,6,7,8,9,10]
end module m

subroutine test()
use m
integer :: i
i = 1
if (para(i) /= 1) call I_am_optimized_away()
end


--- a/gcc/fortran/trans-decl.c
+++ b/gcc/fortran/trans-decl.c
@@ -517,6 +517,9 @@ gfc_finish_var_decl (tree decl, gfc_symbol * sym)
   /* If it wasn't used we wouldn't be getting it.  */
   TREE_USED (decl) = 1;

+  if (sym->attr.flavor == FL_PARAMETER)
+TREE_READONLY (decl) = 1;
+
   /* Chain this decl to the pending declarations.  Don't do pushdecl()
  because this would add them to the current scope rather than the
  function scope.  */

[Bug fortran/50960] [OOP] vtables not marked as constant

[rguenth at gcc dot gnu.org]

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

--- Comment #14 from Richard Guenther  2011-11-03 
14:17:52 UTC ---
(In reply to comment #13)
> Patch for the issue of comment 5: Constants (PARAMETER) which are exists as
> global static variables were not marked as TREE_READONLY.
> 
> With the patch below (not regtested), the function call is optimized away in:
> 
> module m
>   integer, parameter :: PARA(*) = [1,2,3,4,5,6,7,8,9,10]
> end module m
> 
> subroutine test()
> use m
> integer :: i
> i = 1
> if (para(i) /= 1) call I_am_optimized_away()
> end
> 
> 
> --- a/gcc/fortran/trans-decl.c
> +++ b/gcc/fortran/trans-decl.c
> @@ -517,6 +517,9 @@ gfc_finish_var_decl (tree decl, gfc_symbol * sym)
>/* If it wasn't used we wouldn't be getting it.  */
>TREE_USED (decl) = 1;
> 
> +  if (sym->attr.flavor == FL_PARAMETER)
> +TREE_READONLY (decl) = 1;
> +
>/* Chain this decl to the pending declarations.  Don't do pushdecl()
>   because this would add them to the current scope rather than the
>   function scope.  */

Yes, that should work iff Fortran does not allow parameter initializers
that require runtime init (like / foo() /, thus a function call result).

[Bug fortran/50981] New: [4.4/4.5/4.6/4.7 Regression] Wrong-code for scalarizing ELEMENTAL call with absent OPTIONAL argument

[burnus at gcc dot gnu.org]

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

 Bug #: 50981
   Summary: [4.4/4.5/4.6/4.7 Regression] Wrong-code for
scalarizing ELEMENTAL call with absent OPTIONAL
argument
Classification: Unclassified
   Product: gcc
   Version: 4.7.0
Status: UNCONFIRMED
  Keywords: wrong-code
  Severity: normal
  Priority: P3
 Component: fortran
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: bur...@gcc.gnu.org


Created attachment 25705
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=25705
test case

As reported by Andriy Kostyuk,
http://gcc.gnu.org/ml/fortran/2011-11/msg00035.html

There is a wrong-code issue with absent OPTIONAL arguments and ELEMENTAL.

It works for me with 4.1, 4.3, and
  4.4.0 20090206 (experimental) [trunk revision 143983] (SUSE Linux)
It fails for me with 4.5, 4.6 and 4.7
  4.4.6 20110219 (prerelease) [gcc-4_4-branch revision 170290]
and was reported to be broken in
  GNU Fortran (Ubuntu/Linaro 4.4.4-14ubuntu5) 4.4.5


If one looks at the dump, one finds:
  ff (real(kind=8) & restrict a, integer(kind=4) * b)
  {
  ...
  integer(kind=4) D.1747;
D.1747 = *b;
  ...
  while (1)
{
  if (S.1 > 2) goto L.2;
  val.0 = gg (&ac[S.1 + -1], &D.1747) + val.0;
  S.1 = S.1 + 1;
}

The "D.1747 = *b;" is a rather bad idea if "b == NULL".

[Bug target/50980] New: arm-rtems multilib not matching for -mfpu=vfp -mfloat-abi=soft

[joel at gcc dot gnu.org]

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

 Bug #: 50980
   Summary: arm-rtems multilib not matching for -mfpu=vfp
-mfloat-abi=soft
Classification: Unclassified
   Product: gcc
   Version: 4.7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: j...@gcc.gnu.org


This is a regression from 4.6 and older.

GCC Revision: Thu Nov  3 12:25:34 UTC 2011 (revision 180821)

The compiler builds and installs fine.  But a multilib mismatch has crept in.  
This worked in 4.6 and older.  The test program is a minimal "main() {}"

arm-rtems4.11-gcc -mstructure-size-boundary=8 -mcpu=arm920 -mfpu=vfp \
   -mfloat-abi=soft -O2 -g m.c

Now it gives this error:

/users/joel/test-gcc/install-svn/lib/gcc/arm-rtems4.11/4.7.0/../../../../arm-rtems4.11/bin/ld:
error: /tmp/ccNtArTU.o uses VFP instructions, whereas a.out does not

Adding -v it is easy to see that it is not using the "vfp" 
multilib like it was in 4.6.2

4.6.2
/opt/rtems-4.11/libexec/gcc/arm-rtems4.11/4.6.2/collect2 -X
/opt/rtems-4.11/lib/gcc/arm-rtems4.11/4.6.2/../../../../arm-rtems4.11/lib/vfp/crt0.o
-L/opt/rtems-4.11/lib/gcc/arm-rtems4.11/4.6.2/vfp
-L/opt/rtems-4.11/lib/gcc/arm-rtems4.11/4.6.2/../../../../arm-rtems4.11/lib/vfp
-L/opt/rtems-4.11/lib/gcc/arm-rtems4.11/4.6.2
-L/opt/rtems-4.11/lib/gcc/arm-rtems4.11/4.6.2/../../../../arm-rtems4.11/lib
/tmp/ccMcThnp.o -lgcc -lg -lc -lgcc
===

4.7-pre===
/users/joel/test-gcc/install-svn/libexec/gcc/arm-rtems4.11/4.7.0/collect2 -X
/users/joel/test-gcc/install-svn/lib/gcc/arm-rtems4.11/4.7.0/../../../../arm-rtems4.11/lib/crt0.o
-L/users/joel/test-gcc/install-svn/lib/gcc/arm-rtems4.11/4.7.0
-L/users/joel/test-gcc/install-svn/lib/gcc/arm-rtems4.11/4.7.0/../../../../arm-rtems4.11/lib
/tmp/ccxFgIuB.o -lgcc -lg -lc -lgcc
===

[Bug fortran/50960] [OOP] vtables not marked as constant

[burnus at gcc dot gnu.org]

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

--- Comment #15 from Tobias Burnus  2011-11-03 
14:23:59 UTC ---
(In reply to comment #14)
> Yes, that should work iff Fortran does not allow parameter initializers
> that require runtime init (like / foo() /, thus a function call result).

No, Fortran only has static initializers which are known at compile time. In
principle, the parameters could also be inlined by FE compiler (as it is done
for scalars), however, for large arrays, using a static global array seemed to
be the better choice (which matches other compilers).

Hence, TREE_READONLY should be correct.

[Bug fortran/50960] [OOP] vtables not marked as constant

[rguenth at gcc dot gnu.org]

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

--- Comment #16 from Richard Guenther  2011-11-03 
14:29:29 UTC ---
(In reply to comment #11)
> (In reply to comment #9)
> > FAIL: gfortran.dg/extends_type_of_1.f03  -O0  (internal compiler error)
> > FAIL: gfortran.dg/extends_type_of_3.f90  -O  (internal compiler error)
> 
> These two fail with:
> 
> internal compiler error: in fold_convert_loc, at fold-const.c:1894
> 
> Not quite sure what goes wrong there. Some typing problem?
> 
> 
> Reduced test case:
> 
>  type :: t1
>  end type
> 
>  type, extends(t1) :: t2
>  end type
> 
>  class(t1), pointer :: c1
>  type(t2) :: y
> 
>  if (.not. extends_type_of (y, c1)) call abort()
> 
> end

Looks like you are converting struct __vtype_MAIN___T1 to
struct __vtype_MAIN___T1 *.  Thus probably too many TREE_TYPE ()
wrappers somewhere or a forgotten address-taking.

Called from

4608{
4609  /* Scalar pointers.  */
4610  se.want_pointer = 1;
4611  gfc_conv_expr (&se, expr);
4612  gfc_add_block_to_block (&block, &se.pre);
4613  gfc_add_modify (&block, dest,
4614   fold_convert (TREE_TYPE (dest),
se.expr))

where se.want_pointer (whatever it means) is not honored and se.expr
is a variable of type struct __vtype_MAIN___T1.

[Bug fortran/50960] [OOP] vtables not marked as constant

[rguenth at gcc dot gnu.org]

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

--- Comment #17 from Richard Guenther  2011-11-03 
14:34:02 UTC ---
(In reply to comment #16)
> (In reply to comment #11)
> > (In reply to comment #9)
> > > FAIL: gfortran.dg/extends_type_of_1.f03  -O0  (internal compiler error)
> > > FAIL: gfortran.dg/extends_type_of_3.f90  -O  (internal compiler error)
> > 
> > These two fail with:
> > 
> > internal compiler error: in fold_convert_loc, at fold-const.c:1894
> > 
> > Not quite sure what goes wrong there. Some typing problem?
> > 
> > 
> > Reduced test case:
> > 
> >  type :: t1
> >  end type
> > 
> >  type, extends(t1) :: t2
> >  end type
> > 
> >  class(t1), pointer :: c1
> >  type(t2) :: y
> > 
> >  if (.not. extends_type_of (y, c1)) call abort()
> > 
> > end
> 
> Looks like you are converting struct __vtype_MAIN___T1 to
> struct __vtype_MAIN___T1 *.  Thus probably too many TREE_TYPE ()
> wrappers somewhere or a forgotten address-taking.
> 
> Called from
> 
> 4608{
> 4609  /* Scalar pointers.  */
> 4610  se.want_pointer = 1;
> 4611  gfc_conv_expr (&se, expr);
> 4612  gfc_add_block_to_block (&block, &se.pre);
> 4613  gfc_add_modify (&block, dest,
> 4614   fold_convert (TREE_TYPE (dest),
> se.expr))
> 
> where se.want_pointer (whatever it means) is not honored and se.expr
> is a variable of type struct __vtype_MAIN___T1.

Missing handling of se.want_pointer at least here:

void
gfc_conv_structure (gfc_se * se, gfc_expr * expr, int init)
{
...
  if (!init)
{
  /* Create a temporary variable and fill it in.  */
  se->expr = gfc_create_var (type, expr->ts.u.derived->name);
  tmp = gfc_trans_structure_assign (se->expr, expr);
  gfc_add_expr_to_block (&se->pre, tmp);
  return;

but what's the desire of the caller?  Is it to get &expr?  Something
seems to be seriously wrong.

[Bug lto/44965] lto option code breaks file format with each added option

[rguenth at gcc dot gnu.org]

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

--- Comment #6 from Richard Guenther  2011-11-03 
14:46:40 UTC ---
Author: rguenth
Date: Thu Nov  3 14:46:26 2011
New Revision: 180827

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=180827
Log:
2011-11-03  Richard Guenther  

PR lto/44965
* lto-opts.c: Re-implement.
* lto-streamer.h (lto_register_user_option): Remove.
(lto_read_file_options): Likewise.
(lto_reissue_options): Likewise.
(lto_clear_user_options): Likewise.
(lto_clear_file_options): Likewise.
* opts-global.c (post_handling_callback): Remove.
(set_default_handlers): Do not set post_handling_callback.
(decode_options): Remove LTO specific code.
* lto-wrapper.c (merge_and_complain): New function.
(run_gcc): Read all input file options and
prepend a merged set before the linker driver options.
* gcc.c (driver_post_handling_callback): Remove.
(set_option_handlers): Do not set post_handling_callback.
* opts-common.c (handle_option): Do not call post_handling_callback.
* opts.h (struct cl_option_handlers): Remove post_handling_callback.

lto/
* lto-lang.c (lto_post_options): Do not read file options.
* lto.c (lto_read_all_file_options): Remove.
(lto_init): Call lto_set_in_hooks here.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/gcc.c
trunk/gcc/lto-opts.c
trunk/gcc/lto-streamer.h
trunk/gcc/lto-wrapper.c
trunk/gcc/lto/ChangeLog
trunk/gcc/lto/lto-lang.c
trunk/gcc/lto/lto.c
trunk/gcc/opts-common.c
trunk/gcc/opts-global.c
trunk/gcc/opts.h

[Bug bootstrap/50882] [4.6 Regression] internal compiler error: in extract_insn, at recog.c:2109 on powerpc-ibm-aix5.3.0.0

[greed at pobox dot com]

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

--- Comment #9 from Graham Reed  2011-11-03 14:50:48 
UTC ---
(In reply to comment #8)

If I compile the testcase of comment #6 with -fdump-final-insns, there are no
"...:DI" instructions in the output from 4.6.1, or 4.6.2 with rs6000.md from
before SVN revision 178978.

So I suspect there's something that's generating a 64-bit call or epilogue in a
32-bit context.  I'm also in way over my head in these .md files

[Bug fortran/50974] [4.7 regression] ICE on invalid on function used as variable

[kargl at gcc dot gnu.org]

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

kargl at gcc dot gnu.org changed:

   What|Removed |Added

 CC||kargl at gcc dot gnu.org
  Known to work||4.5.4, 4.6.3
Summary|ICE on invalid on function  |[4.7 regression] ICE on
   |used as variable|invalid on function used as
   ||variable
  Known to fail||4.7.0

--- Comment #2 from kargl at gcc dot gnu.org 2011-11-03 14:55:53 UTC ---
Here's a reduced testcase.

module test_mod

  implicit none

  contains

  function func1()
real func1
func1 = func2
  end function func1

  function func2()
real func2
func2 = 1 
  end function func2

end module test_mod

Note, if func2 is moved above func1 in the file, then we get
the expected error.

foo.f90:16.17:

func1 = func2
 1
Error: Function 'func2' requires an argument list at (1)


Also, note that the code compiles with 4.5.4 and 4.6.3,
so this is a regression.

[Bug bootstrap/50982] New: gthr reorganization breakage

[dje at gcc dot gnu.org]

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

 Bug #: 50982
   Summary: gthr reorganization breakage
Classification: Unclassified
   Product: gcc
   Version: 4.7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: bootstrap
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: d...@gcc.gnu.org


The reorganization of gthr files into libgcc breaks bootstrap because some
header files include other files, but look in the wrong directory.

libgcc/config/rs6000/gthr-aix.h
#include "config/gthr-posix.h"

libgcc/config/gthr-vxworks.h
#include "config/gthr-posix.h"

libgcc/config/gthr-lynx.h
#include "config/gthr-posix.h"

However, gthr-posix.h is installed in the same directory as gthr-default.h. 
The header files were edited to include other headers based on the new source
tree hierarchy, but that is not where the files are installed.

[Bug target/50979] sparc mcpu=v8 libgcc2 "mul32" not enabled for "smul" or "umul"

[ro at gcc dot gnu.org]

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

Rainer Orth  changed:

   What|Removed |Added

 CC||davem at davemloft dot net,
   ||ebotcazou at gcc dot
   ||gnu.org, ro at gcc dot
   ||gnu.org

--- Comment #2 from Rainer Orth  2011-11-03 15:00:06 UTC 
---
Are you sure this was introduced by my libgcc series?  I'd like to avoid
hunting down unrelated issues.

The gas error was only introduced in a very recent gas (september 22nd), btw.

  Rainer

[Bug bootstrap/50982] gthr reorganization breakage

[dje at gcc dot gnu.org]

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

David Edelsohn  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2011-11-03
 CC||ro at CeBiTec dot
   ||Uni-Bielefeld.DE
 Ever Confirmed|0   |1

[Bug fortran/50974] ICE on invalid on function used as variable

[kargl at gcc dot gnu.org]

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

kargl at gcc dot gnu.org changed:

   What|Removed |Added

  Known to work|4.5.4, 4.6.3|
Summary|[4.7 regression] ICE on |ICE on invalid on function
   |invalid on function used as |used as variable
   |variable|

--- Comment #3 from kargl at gcc dot gnu.org 2011-11-03 15:01:39 UTC ---
(In reply to comment #2)

> Also, note that the code compiles with 4.5.4 and 4.6.3,
> so this is a regression.

Now that I think about the situation.  This isn't 
a regression per se.  With 4.5 and 4.6, the situation
is accepts-invalid. Removing regression in subj line
and updating 'Known to work' field.

[Bug lto/44965] lto option code breaks file format with each added option

[rguenth at gcc dot gnu.org]

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

Richard Guenther  changed:

   What|Removed |Added

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

--- Comment #7 from Richard Guenther  2011-11-03 
15:06:45 UTC ---
Fixed for 4.7.

[Bug bootstrap/50982] gthr reorganization breakage

[ro at gcc dot gnu.org]

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

Rainer Orth  changed:

   What|Removed |Added

 CC||bonzini at gnu dot org, ro
   ||at gcc dot gnu.org

--- Comment #1 from Rainer Orth  2011-11-03 15:10:00 UTC 
---
Could you please provide details how exactly the bootstrap fails?  With
the exception of the libstdc++ include//bits directory, the
gthr* files aren't supposed to be installed at all.

I suppose that e.g. on AIX gthr-default.h's (really, gthr-aix.h's)
#include "config/gthr-posix.h" fails to find the latter?  In that case,
gthr-posix.h should be moved up to libgcc itself, as my original patch
had it, before Paolo objected.

Thanks.
Rainer

[Bug middle-end/50040] [4.5/4.6 Regression] missed warning: ‘x.y’ is used uninitialized in this function

[rguenth at gcc dot gnu.org]

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

--- Comment #8 from Richard Guenther  2011-11-03 
15:14:38 UTC ---
Patch doesn't apply to the 4.6 branch.  Don't hold your breath.

[Bug middle-end/50079] [4.7 Regression] FAIL: g++.dg/init/copy7.C execution test

[rguenth at gcc dot gnu.org]

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

--- Comment #8 from Richard Guenther  2011-11-03 
15:17:08 UTC ---
Author: rguenth
Date: Thu Nov  3 15:16:57 2011
New Revision: 180829

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=180829
Log:
2011-11-03  Richard Guenther  

PR middle-end/50079
* g++.dg/init/copy7.C: Remove testcase.

Removed:
trunk/gcc/testsuite/g++.dg/init/copy7.C
Modified:
trunk/gcc/testsuite/ChangeLog

[Bug middle-end/50079] [4.7 Regression] FAIL: g++.dg/init/copy7.C execution test

[rguenth at gcc dot gnu.org]

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

Richard Guenther  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED

--- Comment #9 from Richard Guenther  2011-11-03 
15:17:20 UTC ---
Fixed.

[Bug bootstrap/50882] [4.6 Regression] internal compiler error: in extract_insn, at recog.c:2109 on powerpc-ibm-aix5.3.0.0

[greed at pobox dot com]

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

--- Comment #10 from Graham Reed  2011-11-03 15:23:45 
UTC ---
Created attachment 25706
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=25706
Fix wrong mode in call_value_indirect_aix32

(In reply to comment #9)

And that 'DI' was the key (but the integer constant 20 was the easier thing to
find); patch attached.

call_value_indirect_aix32 was doing gen_rtx_MEM (DImode, ... ), when it should
be using SImode for 32-bit.  Looks like a simple copy-and-paste error;
call_indirect_aix32 uses SImode.

Restarting bootstrap now

[Bug target/50978] libgcc build fails - unable to find unwind-arm-common.h

[ro at CeBiTec dot Uni-Bielefeld.DE]

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

--- Comment #1 from ro at CeBiTec dot Uni-Bielefeld.DE  2011-11-03 15:27:19 UTC ---
> Current SVN fails to build libgcc for an arm-none-eabi target because it can't
> find unwind-arm-common.h:
>
> In file included from
> /work/upstream-checkouts/gcc/libgcc/config/arm/unwind-arm.c:24:0:
> ./unwind.h:31:31: fatal error: unwind-arm-common.h: No such file or directory
> compilation terminated.

Could you please provide the complete failing command line?  Thanks.

> I think that the recent move of source from gcc/config to libgcc/config failed
> to move the EXTRA_HEADERS line from gcc/config/arm/t-bpabi and
> gcc/config/arm/t-symbian to libgcc/config/arm/t-bpabi and
> libgcc/config/arm/t-symbian respectively.
>
> However, making the naive change doesn't work as unwind-arm-common.h lives in
> gcc/ginclude.  Does the header have to move directory?

No, EXTRA_HEADERS has to remain in gcc until the target headers are
moved to either libgcc or their own toplevel directory.  They are
supposed to be installed into gcc/include during the build (and before
building libgcc is attempted), and should be findable from there.
That's why I'm asking for the complete command line to see where gcc is
looking for headers.

Rainer

[Bug target/50979] sparc mcpu=v8 libgcc2 "mul32" not enabled for "smul" or "umul"

[joel at gcc dot gnu.org]

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

--- Comment #3 from Joel Sherrill  2011-11-03 15:32:12 
UTC ---
(In reply to comment #2)
> Are you sure this was introduced by my libgcc series?  I'd like to avoid
> hunting down unrelated issues.

No.  I just know it is the next breakage in the sparc. 

> The gas error was only introduced in a very recent gas (september 22nd), btw.

I am building with the binutils head.  So this is likely the cause.

Thanks.

[Bug target/50978] libgcc build fails - unable to find unwind-arm-common.h

[mgretton at sourceware dot org]

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

--- Comment #2 from Matthew Gretton-Dann  
2011-11-03 15:45:57 UTC ---
(In reply to comment #1)
> > Current SVN fails to build libgcc for an arm-none-eabi target because it 
> > can't
> > find unwind-arm-common.h:
> >
> > In file included from
> > /work/upstream-checkouts/gcc/libgcc/config/arm/unwind-arm.c:24:0:
> > ./unwind.h:31:31: fatal error: unwind-arm-common.h: No such file or 
> > directory
> > compilation terminated.
> 
> Could you please provide the complete failing command line?  Thanks.

/work/builds/arm-master-eabi/gcc2/./gcc/xgcc
-B/work/builds/arm-master-eabi/gcc2/./gcc/
-B/work/builds/install/arm-master-eabi/bin/
-B/work/builds/install/arm-master-eabi/lib/ -isystem
/work/builds/install/arm-master-eabi/include -isystem
/work/builds/install/arm-master-eabi/sys-include-g -O2 -mthumb -O2  -g -O2
-DIN_GCC -DCROSS_DIRECTORY_STRUCTURE  -W -Wall -Wno-narrowing -Wwrite-strings
-Wcast-qual -Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition 
-isystem ./include  -fno-inline -g -DIN_LIBGCC2 -fbuilding-libgcc
-fno-stack-protector -Dinhibit_libc -fno-inline -I. -I. -I../../.././gcc
-I/work/upstream-checkouts/gcc/libgcc -I/work/upstream-checkouts/gcc/libgcc/.
-I/work/upstream-checkouts/gcc/libgcc/../gcc
-I/work/upstream-checkouts/gcc/libgcc/../include-o unwind-arm.o -MT
unwind-arm.o -MD -MP -MF unwind-arm.dep -fexceptions -c
/work/upstream-checkouts/gcc/libgcc/config/arm/unwind-arm.c 

GCC configured as:


/work/upstream-checkouts/gcc/configure --target=arm-master-eabi
--prefix=/work/builds/install
--with-sysroot=/work/builds/install/arm-master-eabi --with-newlib --with-gnu-as
--with-gnu-ld --enable-languages=c,c++ --with-gmp=.../linux_x86_64
--with-mpfr=.../linux_x86_64 --with-mpc=.../linux_x86_64
--with-libelf=.../linux_x86_64 --disable-lto --disable-shared --disable-nls
--disable-threads --disable-tls --enable-checking=yes --with-cpu=cortex-a9
--with-fpu=neon --with-float=softfp 

Build directory: /work/builds/arm-master-eabi/gcc2

[Bug target/50979] sparc mcpu=v8 libgcc2 "mul32" not enabled for "smul" or "umul"

[ebotcazou at gcc dot gnu.org]

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

--- Comment #4 from Eric Botcazou  2011-11-03 
16:06:42 UTC ---
Probably everywhere but Solaris.

[Bug target/50979] sparc mcpu=v8 libgcc2 "mul32" not enabled for "smul" or "umul"

[ebotcazou at gcc dot gnu.org]

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

Eric Botcazou  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2011-11-03
 Ever Confirmed|0   |1

[Bug target/50979] architecture mismatch: "mul32" not enabled for "smul" or "umul"

[ebotcazou at gcc dot gnu.org]

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

Eric Botcazou  changed:

   What|Removed |Added

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

--- Comment #5 from Eric Botcazou  2011-11-03 
16:16:21 UTC ---
Created attachment 25707
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=25707
Tentative fix

[Bug target/50978] libgcc build fails - unable to find unwind-arm-common.h

[ro at gcc dot gnu.org]

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

Rainer Orth  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2011-11-03
 AssignedTo|unassigned at gcc dot   |ro at gcc dot gnu.org
   |gnu.org |
   Target Milestone|--- |4.7.0
 Ever Confirmed|0   |1

--- Comment #3 from Rainer Orth  2011-11-03 16:20:21 UTC 
---
I think I found it: an incredibly stupid error.  The contents of arm/t-bpabi
was moved to libgcc, with the exception of EXTRA_HEADERS.  I missed that and
removed the file.  Please try the attached patch.

  Rainer

[Bug target/50978] libgcc build fails - unable to find unwind-arm-common.h

[ro at gcc dot gnu.org]

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

--- Comment #4 from Rainer Orth  2011-11-03 16:21:34 UTC 
---
Created attachment 25708
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=25708
proposed patch

[Bug fortran/50981] [4.4/4.5/4.6/4.7 Regression] Wrong-code for scalarizing ELEMENTAL call with absent OPTIONAL argument

[mikael at gcc dot gnu.org]

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

Mikael Morin  changed:

   What|Removed |Added

 CC||mikael at gcc dot gnu.org

--- Comment #1 from Mikael Morin  2011-11-03 
16:39:10 UTC ---
No bootstraped compiler at hand; does this work?

diff --git a/trans-array.c b/trans-array.c
index 3472804..c48f718 100644
--- a/trans-array.c
+++ b/trans-array.c
@@ -2180,6 +2180,7 @@ gfc_add_loop_ss_code (gfc_loopinfo * loop, gfc_ss * ss,
bool subscript,
   /* Scalar argument to elemental procedure.  Evaluate this
  now.  */
   gfc_init_se (&se, NULL);
+  se->want_pointer = 1;
   gfc_conv_expr (&se, ss->expr);
   gfc_add_block_to_block (&loop->pre, &se.pre);
   gfc_add_block_to_block (&loop->post, &se.post);
diff --git a/trans-expr.c b/trans-expr.c
index 09b98d0..9e9ceea 100644
--- a/trans-expr.c
+++ b/trans-expr.c
@@ -4823,8 +4823,6 @@ gfc_conv_expr (gfc_se * se, gfc_expr * expr)
   /* Substitute a scalar expression evaluated outside the scalarization
  loop.  */
   se->expr = se->ss->data.scalar.expr;
-  if (se->ss->type == GFC_SS_REFERENCE)
-se->expr = gfc_build_addr_expr (NULL_TREE, se->expr);
   se->string_length = se->ss->string_length;
   gfc_advance_se_ss_chain (se);
   return;

[Bug target/50978] libgcc build fails - unable to find unwind-arm-common.h

[mgretton at sourceware dot org]

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

--- Comment #5 from Matthew Gretton-Dann  
2011-11-03 16:43:41 UTC ---
(In reply to comment #3)
> I think I found it: an incredibly stupid error.  The contents of arm/t-bpabi
> was moved to libgcc, with the exception of EXTRA_HEADERS.  I missed that and
> removed the file.  Please try the attached patch.

After applying the patch I have managed a successful build.

Thanks,

Matt

[Bug target/50978] libgcc build fails - unable to find unwind-arm-common.h

[ro at CeBiTec dot Uni-Bielefeld.DE]

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

--- Comment #6 from ro at CeBiTec dot Uni-Bielefeld.DE  2011-11-03 16:46:23 UTC ---
Thanks for the confirmation.  I'll submit the patch now.

Rainer

[Bug target/50906] e500 exception unwinding under "-Os" causes SIGSEGV

[Kyle.D.Moffett at boeing dot com]

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

--- Comment #11 from Kyle Moffett  2011-11-03 
16:48:43 UTC ---
Ok, I'm running a "bootstrap-lean" + "make check" by way of a full Debian GCC
package build with this patch added.  The first build will just do
C/C++/ObjC/ObjC++/Fortran; if that works out OK I will also do a Java build in
a little while.

I applied a 1-line patch to make the package build set "BOOT_CFLAGS := -g -O2"
as you requested, so hopefully any fallout will be obvious during the GCC build
itself.

There are 2 other patches I have applied on top of the Debian GCC 4.6.2-3
package to fix the SPE build:
  * http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=647288
  * http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=647324

The libffi one applies on top of these patches already in the Debian package:
  * http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=644338

Based on the speed of this board and the fact that I am using it for other
testing as well, I expect to have the test results in roughly 6-8 hours.

Cheers,
Kyle Moffett

--
Curious about my work on the Debian powerpcspe port?
I'm keeping a blog here: http://pureperl.blogspot.com/

[Bug target/50979] architecture mismatch: "mul32" not enabled for "smul" or "umul"

[joel at gcc dot gnu.org]

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

--- Comment #6 from Joel Sherrill  2011-11-03 17:06:52 
UTC ---
(In reply to comment #5)
> Created attachment 25707 [details]
> Tentative fix

That seems to have done the trick enough to complete the build of gcc.

Please commit it.

Thanks.

[Bug fortran/50981] [4.4/4.5/4.6/4.7 Regression] Wrong-code for scalarizing ELEMENTAL call with absent OPTIONAL argument

[burnus at gcc dot gnu.org]

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

Tobias Burnus  changed:

   What|Removed |Added

   Target Milestone|--- |4.4.7

--- Comment #2 from Tobias Burnus  2011-11-03 
17:12:15 UTC ---
(In reply to comment #1)
> No bootstraped compiler at hand; does this work?

Does not help. (Nit: in trans-array.c "se.want..." instead of "se->".)

Now the segfaults already for "ff" where the "b" argument is present. The
segfault occurs at
ELEMENTAL REAL(KIND=8) FUNCTION gg(a,b)
  ...
  IF(PRESENT(b)) THEN
b1=b  ! <<< here

While "ff" now looks reasonable:

ff (real(kind=8) & restrict a, integer(kind=4) * b)
integer(kind=4) * D.1747;
D.1747 = b;
  val.0 = gg (&ac[S.1 + -1], D.1747) + val.0;

one has an issue with the call:
rr[S.5 + -1] = ff (&aa[S.5 + -1], 1);

as it is probably not a good idea to dereference the literal "1", unless you
really want to access the memory address 0x1 ...

 * * *

Works:
   4.4.5 20100627 (prerelease) [gcc-4_4-branch revision 161471]
Fails:
   4.4.5 20100627 (prerelease) [gcc-4_4-branch revision 161472]

Unless I made a mistake with building those versions, the regression is caused
by:

Rev. 161472 (PR fortran/43841 and PR 43843).
http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=161472

* trans-expr.c (gfc_conv_expr): Supply an address expression for
GFC_SS_REFERENCE.
(gfc_conv_expr_reference): Call gfc_conv_expr and return for
GFC_SS_REFERENCE.
* trans-array.c (gfc_add_loop_ss_code): Store the value rather
than the address of a GFC_SS_REFERENCE.
* trans.h : Change comment on GFC_SS_REFERENCE.

[Bug bootstrap/50857] [4.7 Regression] The compiler is built with exceptions and RTTI enabled

[matz at gcc dot gnu.org]

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

--- Comment #4 from Michael Matz  2011-11-03 17:17:11 
UTC ---
Author: matz
Date: Thu Nov  3 17:17:07 2011
New Revision: 180833

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=180833
Log:
libcpp/
PR bootstrap/50857
* configure.ac: Check for -fno-exceptions -fno-rtti.
* configure: Regenerate.
* Makefile.in (NOEXCEPTION_FLAGS): New flag.
(ALL_CXXFLAGS): Use it.

gcc/
PR bootstrap/50857
* configure.ac: Check for -fno-exceptions -fno-rtti.
* configure: Regenerate.
* Makefile.in (NOEXCEPTION_FLAGS): New flag.
(ALL_CXXFLAGS): Use it.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/Makefile.in
trunk/gcc/configure
trunk/gcc/configure.ac
trunk/libcpp/ChangeLog
trunk/libcpp/Makefile.in
trunk/libcpp/configure
trunk/libcpp/configure.ac

[Bug bootstrap/50857] [4.7 Regression] The compiler is built with exceptions and RTTI enabled

[matz at gcc dot gnu.org]

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

Michael Matz  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 CC||matz at gcc dot gnu.org
 Resolution||FIXED

--- Comment #5 from Michael Matz  2011-11-03 17:22:02 
UTC ---
Fixed.

[Bug bootstrap/50982] gthr reorganization breakage

[ro at gcc dot gnu.org]

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

--- Comment #3 from Rainer Orth  2011-11-03 17:25:59 UTC 
---
Created attachment 25709
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=25709
proposed patch

[Bug bootstrap/50982] gthr reorganization breakage

[ro at gcc dot gnu.org]

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

Rainer Orth  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
 CC|ro at CeBiTec dot   |
   |Uni-Bielefeld.DE|
 AssignedTo|unassigned at gcc dot   |ro at gcc dot gnu.org
   |gnu.org |
   Target Milestone|--- |4.7.0

--- Comment #2 from Rainer Orth  2011-11-03 17:24:53 UTC 
---
Assuming my analysis is right, could you please try the attached (yet untested)
patch?

Thanks.
  Rainer

[Bug ada/50934] Attribute Max_Size_In_Storage_Elements is wrong for controlled types

[simon at pushface dot org]

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

--- Comment #3 from simon at pushface dot org 2011-11-03 17:34:01 UTC ---
(In reply to comment #1)

> It seems to me that this new approach is a remarkably non-Ada way of 
> addressing
> the problem; the original design is precisely the way that it should be
> addressed. Of course I have absolutely no objection to delegating this
> management to Ada.Finalization.Heap_Management (I think this should now in 
> fact
> be System.Finalization_Masters). But System.Finalization_Root.Root_Controlled
> should contain a System.Finalization_Masters.FM_Node.

Apologies all round; this isn't correct, because a type with a component of a
controlled type also needs finalization support; for example,

   type E is record
  Str : Ada.Strings.Unbounded.Unbounded_String;
   end record;
   type E_P is access E;
   for E_P'Storage_Size use E'Max_Size_In_Storage_Elements * 4;

[Bug debug/50983] New: [4.7 Regression] incorrect DW_LNS_negate_stmt

[ravitillo at lbl dot gov]

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

 Bug #: 50983
   Summary: [4.7 Regression] incorrect DW_LNS_negate_stmt
Classification: Unclassified
   Product: gcc
   Version: 4.7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: debug
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: raviti...@lbl.gov
CC: ja...@redhat.com


An incorrect DW_LNS_negate_stmt doesn't allow to set breakpoints in some cases,
e.g. given

struct Base {
  Base(bool foo){
static bool bar;
if (foo) bar = false; else bar = true;}
};

void fun()
{
  return;
}

int main(int argc, char *argv[])
{
  Base *b = new Base(true);
  fun();
  return 0;
}

and compiling with -g, is_stmt is set to 0 after the end of the first sequence:

  readelf --debug-dump=rawline ./a.out
  ...
  Special opcode 103: advance Address by 7 to 0x40058d and Line by 0 to 4
  Advance PC by 2 to 0x40058f
  Extended opcode 1: End of Sequence

  Set is_stmt to 0
  Extended opcode 2: set Address to 0x400524
  Special opcode 12: advance Address by 0 to 0x400524 and Line by 7 to 8
  ...

making it impossible to set a breakpoint on line 9 for instance. The proposed
fix:


gcc/Changelog:
2011-11-03 Roberto Agostino Vitillo 
* dwarf2out.c (set_cur_line_info_table): Restore the last is_stmt value in
the current line table.

Index: gcc/gcc/dwarf2out.c
===
--- gcc/gcc/dwarf2out.c(revision 180817)
+++ gcc/gcc/dwarf2out.c(working copy)
@@ -20363,6 +20363,9 @@
   VEC_safe_push (dw_line_info_table_p, gc, separate_line_info, table);
 }

+  if (DWARF2_ASM_LINE_DEBUG_INFO)
+table->is_stmt = cur_line_info_table ? cur_line_info_table->is_stmt
+ : DWARF_LINE_DEFAULT_IS_STMT_START;
   cur_line_info_table = table;
 }



Tested on x86_64-linux.
r

[Bug tree-optimization/50984] New: Boolean return value expression clears register too often

[drepper.fsp at gmail dot com]

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

 Bug #: 50984
   Summary: Boolean return value expression clears register too
often
Classification: Unclassified
   Product: gcc
   Version: 4.7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: drepper@gmail.com
Target: x86_64-linux


Compile this code with the current HEAD gcc (or 4.5, I tried that as well) and
you see less than optimal code:

int
f(int a, int b)
{
  return a & 8 && b & 4;
}

For x86-64 I see this asm code:
xorl%eax, %eax
andl$8, %edi
je.L2
xorl%eax, %eax  <- Unnecessary !!!
andl$4, %esi
setne%al
.L2:
rep
ret

The compiler should realize that the second xor is unnecessary.

[Bug target/50984] Boolean return value expression clears register too often

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

   Keywords||missed-optimization
  Component|tree-optimization   |target

--- Comment #1 from Andrew Pinski  2011-11-03 
18:11:22 UTC ---
IIRC this is a target issue.

[Bug bootstrap/50982] gthr reorganization breakage

[dje at gcc dot gnu.org]

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

--- Comment #4 from David Edelsohn  2011-11-03 18:11:40 
UTC ---
The failure is config/gthr-posix.h is not found in the search path when
building libstdc++ during bootstrap.

Paolo's suggestion probably was not well thought through.

I tried editing gthr-aix.h to remove config/, but that was not sufficient and
failed in another way.  I will try with the other parts of your patch.

[Bug target/50978] libgcc build fails - unable to find unwind-arm-common.h

[ro at gcc dot gnu.org]

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

--- Comment #7 from Rainer Orth  2011-11-03 18:19:57 UTC 
---
Author: ro
Date: Thu Nov  3 18:19:54 2011
New Revision: 180839

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=180839
Log:
Restore arm-eabi bootstrap (PR target/50978)

PR target/50978
* config/arm/t-bpabi: New file.
* config.gcc (arm*-*-linux*): Add arm/t-bpabi to tmake_file for
arm*-*-linux-*eabi.
(arm*-*-uclinux*): Add arm/t-bpabi to tmake_file for
arm*-*-uclinux*eabi.
(arm*-*-eabi*, arm*-*-symbianelf*): Add arm/t-bpabi to tmake_file
for arm*-*-eabi*.

Added:
trunk/gcc/config/arm/t-bpabi
Modified:
trunk/gcc/ChangeLog
trunk/gcc/config.gcc

[Bug middle-end/50598] [4.7 Regression] Undefined symbols: "___emutls_v.*", ... on *-apple-darwin*

[iains at gcc dot gnu.org]

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

--- Comment #7 from Iain Sandoe  2011-11-03 18:22:05 
UTC ---
$ more ../gcc-live-trunk/libgomp/testsuite/libgomp.c++/pr24455-1.C 
// { dg-do compile }
// { dg-require-effective-target tls }
extern int i;
#pragma omp threadprivate (i)

int i;

===
if this is compiled with  "-x c "  we get:

$ more pr24455-1.s .text
__GLOBAL__sub_I_65535_0_pr24455_1.C:
pushl   %ebx
subl$24, %esp
call___x86.get_pc_thunk.bx
L001$pb:
movl$0, 12(%esp)
movl$4, 8(%esp)
movl$4, 4(%esp)
movlL___emutls_v.i$non_lazy_ptr-L001$pb(%ebx), %eax
movl%eax, (%esp)
call___emutls_register_common
addl$24, %esp
popl%ebx
ret
.mod_init_func
.align 2
.long   __GLOBAL__sub_I_65535_0_pr24455_1.C
.comm   ___emutls_v.i,16,2
.section __TEXT,__textcoal_nt,coalesced,pure_instructions
.weak_definition___x86.get_pc_thunk.bx
.private_extern ___x86.get_pc_thunk.bx
___x86.get_pc_thunk.bx:
movl(%esp), %ebx
ret
.section __IMPORT,__pointers,non_lazy_symbol_pointers
L___emutls_v.i$non_lazy_ptr:
.indirect_symbol ___emutls_v.i
.long   0
.subsections_via_symbols



if compiled with g++ we get an empty body (as per comment #4).

the tree-dumps are not very interesting - because the tu shows as empty ...

I'm guessing that somehow g++ is dropping the extern .. which allows the
revised version of cgraphunit to prune the variable .. but I'm not sure how to
go about debugging this at the moment ...

[Bug bootstrap/50982] gthr reorganization breakage

[ro at CeBiTec dot Uni-Bielefeld.DE]

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

--- Comment #5 from ro at CeBiTec dot Uni-Bielefeld.DE  2011-11-03 18:22:16 UTC ---
> --- Comment #4 from David Edelsohn  2011-11-03 
> 18:11:40 UTC ---
> The failure is config/gthr-posix.h is not found in the search path when
> building libstdc++ during bootstrap.
>
> Paolo's suggestion probably was not well thought through.
>
> I tried editing gthr-aix.h to remove config/, but that was not sufficient and
> failed in another way.  I will try with the other parts of your patch.

You will also need the the libstdc++-v3/include/Makefile.{am, in} part.
git GNU patch can apply git-style patches, but there's no release yet.
I think svn 1.7 can, too.  This makes it much easier than dealing with
such patches manually.

Rainer

[Bug target/50978] libgcc build fails - unable to find unwind-arm-common.h

[ro at gcc dot gnu.org]

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

Rainer Orth  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
URL||http://gcc.gnu.org/ml/gcc-p
   ||atches/2011-11/msg00351.htm
   ||l
 Resolution||FIXED

--- Comment #8 from Rainer Orth  2011-11-03 18:23:14 UTC 
---
Fixed for 4.7.0.

[Bug bootstrap/50982] gthr reorganization breakage

[bonzini at gnu dot org]

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

--- Comment #6 from Paolo Bonzini  2011-11-03 18:27:23 
UTC ---
> Paolo's suggestion probably was not well thought through.

Yes, it assumed that the patch would be tested by maintainers...

The patch looks good.

[Bug c++/32534] gcc fails to initialize template's static data members before their use in some cases

[richard-gccbugzilla at metafoo dot co.uk]

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

Richard Smith  changed:

   What|Removed |Added

 CC||richard-gccbugzilla at
   ||metafoo dot co.uk

--- Comment #5 from Richard Smith  
2011-11-03 18:26:57 UTC ---
This does not look like a valid bug: static data members of class template
instantiations have unordered initialization, so gcc is permitted to initialize
B::a after it initializes c.

[Bug libfortran/50985] New: FAIL: gfortran.fortran-torture/execute/entry_4.f90 execution, at -O2 and above

[danglin at gcc dot gnu.org]

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

 Bug #: 50985
   Summary: FAIL: gfortran.fortran-torture/execute/entry_4.f90
execution,  at -O2 and above
Classification: Unclassified
   Product: gcc
   Version: 4.7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libfortran
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: dang...@gcc.gnu.org
  Host: hppa64-hp-hpux11.11
Target: hppa64-hp-hpux11.11
 Build: hppa64-hp-hpux11.11


Executing on host: /test/gnu/gcc/objdir/gcc/testsuite/gfortran/../../gfortran
-B
/test/gnu/gcc/objdir/gcc/testsuite/gfortran/../../
-B/test/gnu/gcc/objdir/hppa64
-hp-hpux11.11/./libgfortran/
/test/gnu/gcc/gcc/gcc/testsuite/gfortran.fortran-to
rture/execute/entry_4.f90   -w  -O2  
-B/test/gnu/gcc/objdir/hppa64-hp-hpux11.11
/./libgfortran/.libs
-L/test/gnu/gcc/objdir/hppa64-hp-hpux11.11/./libgfortran/.l
ibs -L/test/gnu/gcc/objdir/hppa64-hp-hpux11.11/./libgfortran/.libs
-B/test/gnu/g
cc/objdir/hppa64-hp-hpux11.11/./libquadmath/.libs
-L/test/gnu/gcc/objdir/hppa64-
hp-hpux11.11/./libquadmath/.libs
-L/test/gnu/gcc/objdir/hppa64-hp-hpux11.11/./li
bquadmath/.libs  -lm   -o /test/gnu/gcc/objdir/gcc/testsuite/gfortran/entry_4.x
   (timeout = 300)
PASS: gfortran.fortran-torture/execute/entry_4.f90 compilation,  -O2
Setting LD_LIBRARY_PATH to
.:/test/gnu/gcc/objdir/hppa64-hp-hpux11.11/./libgfort
ran/.libs:/test/gnu/gcc/objdir/hppa64-hp-hpux11.11/./libgfortran/.libs:/test/gnu
/gcc/objdir/hppa64-hp-hpux11.11/./libquadmath/.libs:/test/gnu/gcc/objdir/hppa64-
hp-hpux11.11/./libquadmath/.libs:/test/gnu/gcc/objdir/gcc:.:/test/gnu/gcc/objdir
/hppa64-hp-hpux11.11/./libgfortran/.libs:/test/gnu/gcc/objdir/hppa64-hp-hpux11.1
1/./libgfortran/.libs:/test/gnu/gcc/objdir/hppa64-hp-hpux11.11/./libquadmath/.li
bs:/test/gnu/gcc/objdir/hppa64-hp-hpux11.11/./libquadmath/.libs:/test/gnu/gcc/ob
jdir/gcc

Backtrace for this error:
  unable to produce a backtrace, sorry!
FAIL: gfortran.fortran-torture/execute/entry_4.f90 execution,  -O2

-bash-3.2$ ./xgcc -B./ -v
Reading specs from ./specs
COLLECT_GCC=./xgcc
COLLECT_LTO_WRAPPER=./lto-wrapper
Target: hppa64-hp-hpux11.11
Configured with: ../gcc/configure --with-gnu-as --with-as=/opt/gnu64/bin/as
--with-ld=/usr/ccs/bin/ld --enable-shared --with-local-prefix=/opt/gnu64
--prefix=/opt/gnu64/gcc/gcc-4.7 --build=hppa64-hp-hpux11.11
--enable-threads=posix --disable-nls --with-gmp=/opt/gnu64/gcc/gmp
--with-libelf=/opt/gnu64 --enable-languages=c,c++,objc,obj-c++,fortran
Thread model: posix
gcc version 4.7.0 2001 (experimental) [trunk revision 180738] (GCC)

[Bug c++/50986] New: weak static data members with constant initializers emitted in .rodata, leading to segfault on startup

[richard-gccbugzilla at metafoo dot co.uk]

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

 Bug #: 50986
   Summary: weak static data members with constant initializers
emitted in .rodata, leading to segfault on startup
Classification: Unclassified
   Product: gcc
   Version: 4.6.3
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: richard-gccbugzi...@metafoo.co.uk


It's possible for a weak variable K (either a static data member of a class
template or a static variable in an inline function) to have a constant
initializer in one translation unit (call it TU1) and a non-constant
initializer in another translation unit (call it TU2), without an ODR
violation. This can happen, for instance, if the initializer for an extern
const int X whose value is used in K's initializer is visible in one TU but not
the other.

In this case, in TU1, g++ uses static initialization and puts the variable in
.rodata. In TU2, it uses dynamic initialization. If these TUs are linked
together in the wrong order, the linker will put the variable in .rodata but
the binary will still try to dynamically initialize it. This causes the program
to segfault on startup (trying to write to read-only memory).

Testcase:

$ cat repro.cpp
struct S {
  static const int x;
};
template struct U {
  static const int k;
};
#ifdef TU1
const int S::x = 42;
#endif
template const int U::k = T::x;

#ifdef TU1
extern const int *f();
const int *g() { return &U::k; }
int main() {
  return *f() + U::k;
}
#endif

#ifdef TU2
const int *f() { return &U::k; }
#endif
$ g++ repro.cpp -DTU1 -c -o tu1.o
$ g++ repro.cpp -DTU2 -c -o tu2.o
$ g++ tu1.o tu2.o
$ ./a.out
Segmentation fault


clang has the same issue (which is how this was discovered), and the current
proposed solution there is to never put weak constants in .rodata.

[Bug middle-end/50628] [4.7 Regression] gfortran.fortran-torture/execute/entry_4.f90 fails

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

 CC||danglin at gcc dot gnu.org

--- Comment #9 from Dominique d'Humieres  2011-11-03 
18:45:34 UTC ---
*** Bug 50985 has been marked as a duplicate of this bug. ***

[Bug libfortran/50985] FAIL: gfortran.fortran-torture/execute/entry_4.f90 execution, at -O2 and above

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||DUPLICATE

--- Comment #1 from Dominique d'Humieres  2011-11-03 
18:45:34 UTC ---
Duplicate of pr50628.

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

[Bug c++/32534] gcc fails to initialize template's static data members before their use in some cases

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||INVALID

--- Comment #6 from Jonathan Wakely  2011-11-03 
18:47:32 UTC ---
Indeed, [basic.start.init] p2 says so, thanks.

An ordering could be enforced by explicitly specializing the static data
member:
  template<> A B::a = A();
or in C++11
  template<> A B::a{};

Or in C++11 by making A's constructor constexpr

[Bug libgomp/50977] non-deterministic failure in cactusADM using openmp

[jakub at gcc dot gnu.org]

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

--- Comment #2 from Jakub Jelinek  2011-11-03 
18:50:42 UTC ---
Without a small self-contained reproducer hard to do anything about it.

[Bug target/50968] ICE on armhf building gcc-snapshot

[ramana at gcc dot gnu.org]

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

Ramana Radhakrishnan  changed:

   What|Removed |Added

 CC||ramana at gcc dot gnu.org

--- Comment #4 from Ramana Radhakrishnan  2011-11-03 
19:11:53 UTC ---
For the record and future reference, unwind-dw2.c should never be compiled in
this configuration. The arm*eabi port uses the ARM format exception tables for
exception handling rather than the generic DWARF exception handling tables.



Ramana

[Bug middle-end/50890] [4.7 Regression] ICE in fold_convert_loc, at fold-const.c:1894

[ebotcazou at gcc dot gnu.org]

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

Eric Botcazou  changed:

   What|Removed |Added

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

--- Comment #5 from Eric Botcazou  2011-11-03 
19:18:06 UTC ---
The fix has introduced 1 ACATS regression and 1 gnat.dg regression on x86-64.

[Bug fortran/50981] [4.4/4.5/4.6/4.7 Regression] Wrong-code for scalarizing ELEMENTAL call with absent OPTIONAL argument

[mikael at gcc dot gnu.org]

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

--- Comment #3 from Mikael Morin  2011-11-03 
19:19:51 UTC ---
(In reply to comment #2)
> Unless I made a mistake with building those versions, the regression is caused
> by:
> 
> Rev. 161472 (PR fortran/43841 and PR 43843).
> http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=161472
> 
Makes sense.
The patch I have proposed is more or less a revert of that change.

[Bug bootstrap/50982] gthr reorganization breakage

[dje at gcc dot gnu.org]

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

--- Comment #7 from David Edelsohn  2011-11-03 19:28:16 
UTC ---
It's better.  It now finds gthr-posix.h.  But now it fails with a C++ failure:

In file included from /farm/dje/src/src/libstdc++-v3/src/atomic.cc:28:0:
/tmp/20111103/powerpc-ibm-aix5.3.0.0/pthread/libstdc++-v3/include/mutex: In
cons
tructor 'constexpr std::once_flag::once_flag()':
/tmp/2003/powerpc-ibm-aix5.3.0.0/pthread/libstdc++-v3/include/mutex:767:65: 
error: no matching function for call to
'pthread_once_t::pthread_once_t()'
/tmp/2003/powerpc-ibm-aix5.3.0.0/pthread/libstdc++-v3/include/mutex:767:65: 
note: candidates are:
In file included from
/tmp/2003/powerpc-ibm-aix5.3.0.0/pthread/libstdc++-v3/
include/gstdint.h:6:0,
 from /farm/dje/src/src/libstdc++-v3/src/atomic.cc:26:
/tmp/2003/./gcc/include-fixed/sys/types.h:451:1: note:
pthread_once_t::pthre
ad_once_t()
/tmp/2003/./gcc/include-fixed/sys/types.h:451:1: note:   candidate expects
0
 arguments, 1 provided
/tmp/2003/./gcc/include-fixed/sys/types.h:451:1: note: constexpr
pthread_onc
e_t::pthread_once_t(const pthread_once_t&)
/tmp/2003/./gcc/include-fixed/sys/types.h:451:1: note:   no known
conversion
 for argument 1 from '' to 'const
pthread_once_
t&'
/tmp/2003/./gcc/include-fixed/sys/types.h:451:1: note: constexpr
pthread_onc
e_t::pthread_once_t(pthread_once_t&&)
/tmp/2003/./gcc/include-fixed/sys/types.h:451:1: note:   no known
conversion
 for argument 1 from '' to 'pthread_once_t&&'
In file included from /farm/dje/src/src/libstdc++-v3/src/atomic.cc:28:0:
/tmp/2003/powerpc-ibm-aix5.3.0.0/pthread/libstdc++-v3/include/mutex:767:69: 
error: uninitialized member 'std::once_flag::_M_once' in 'constexpr'
constructor
/tmp/2003/powerpc-ibm-aix5.3.0.0/pthread/libstdc++-v3/include/mutex: In
func
tion 'void std::call_once(std::once_flag&, _Callable&&, _Args&& ...)':
/tmp/2003/powerpc-ibm-aix5.3.0.0/pthread/libstdc++-v3/include/mutex:818:64: 
error: invalid conversion from 'void (*)(...)' to 'void (*)()' [-fpermissive]
make[9]: *** [atomic.lo] Error 1

[Bug bootstrap/50982] gthr reorganization breakage

[ro at CeBiTec dot Uni-Bielefeld.DE]

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

--- Comment #8 from ro at CeBiTec dot Uni-Bielefeld.DE  2011-11-03 19:40:31 UTC ---
> --- Comment #7 from David Edelsohn  2011-11-03 
> 19:28:16 UTC ---
> It's better.  It now finds gthr-posix.h.  But now it fails with a C++ failure:

Fine.  I'm running Solaris and Linux/x64 bootstraps with that patch now.

> In file included from /farm/dje/src/src/libstdc++-v3/src/atomic.cc:28:0:
> /tmp/2003/powerpc-ibm-aix5.3.0.0/pthread/libstdc++-v3/include/mutex: In
> cons
> tructor 'constexpr std::once_flag::once_flag()':
> /tmp/2003/powerpc-ibm-aix5.3.0.0/pthread/libstdc++-v3/include/mutex:767:65:
>  
> error: no matching function for call to
> 'pthread_once_t::pthread_once_t( nclosed initializer list>)'
> /tmp/2003/powerpc-ibm-aix5.3.0.0/pthread/libstdc++-v3/include/mutex:767:65:
>  
> note: candidates are:
> In file included from
> /tmp/2003/powerpc-ibm-aix5.3.0.0/pthread/libstdc++-v3/
> include/gstdint.h:6:0,
>  from /farm/dje/src/src/libstdc++-v3/src/atomic.cc:26:
> /tmp/2003/./gcc/include-fixed/sys/types.h:451:1: note:
> pthread_once_t::pthre
> ad_once_t()
> /tmp/2003/./gcc/include-fixed/sys/types.h:451:1: note:   candidate expects
> 0
>  arguments, 1 provided
> /tmp/2003/./gcc/include-fixed/sys/types.h:451:1: note: constexpr
> pthread_onc
> e_t::pthread_once_t(const pthread_once_t&)
> /tmp/2003/./gcc/include-fixed/sys/types.h:451:1: note:   no known
> conversion
>  for argument 1 from '' to 'const
> pthread_once_
> t&'
> /tmp/2003/./gcc/include-fixed/sys/types.h:451:1: note: constexpr
> pthread_onc
> e_t::pthread_once_t(pthread_once_t&&)
> /tmp/2003/./gcc/include-fixed/sys/types.h:451:1: note:   no known
> conversion
>  for argument 1 from '' to 'pthread_once_t&&'
> In file included from /farm/dje/src/src/libstdc++-v3/src/atomic.cc:28:0:
> /tmp/2003/powerpc-ibm-aix5.3.0.0/pthread/libstdc++-v3/include/mutex:767:69:
>  
> error: uninitialized member 'std::once_flag::_M_once' in 'constexpr'
> constructor
> /tmp/2003/powerpc-ibm-aix5.3.0.0/pthread/libstdc++-v3/include/mutex: In
> func
> tion 'void std::call_once(std::once_flag&, _Callable&&, _Args&& ...)':
> /tmp/2003/powerpc-ibm-aix5.3.0.0/pthread/libstdc++-v3/include/mutex:818:64:
>  
> error: invalid conversion from 'void (*)(...)' to 'void (*)()' [-fpermissive]
> make[9]: *** [atomic.lo] Error 1

This doesn't ring a bell for me.  Could you please try a bootstrap at
rev 180765 (i.e. immediately before my libgcc patches) to make sure this
isn't a different issue.

Thanks.
Rainer

[Bug c++/50976] [C++0x] literal operator with unsigned long long parameter not accepted

[daniel.kruegler at googlemail dot com]

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

--- Comment #11 from Daniel Krügler  
2011-11-03 19:44:02 UTC ---
(In reply to comment #4)
> I can't imagine how this could be target dependent though.

I have a bit more information now: If I'm using the 32-bit version from
http://www.equation.com/servlet/equation.cmd?fa=fortran on a 32-bit system, I
have not this problem. I wonder whether this could be a mingw problem - I
remember that this caused problems once in a while. Is there a mingw subgroup
which could be asked about that?