[Bug middle-end/58041] New: Unaligned access to arrays in packed structure

[bernd.edlinger at hotmail dot de]

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

Bug ID: 58041
   Summary: Unaligned access to arrays in packed structure
   Product: gcc
   Version: 4.9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
  Assignee: unassigned at gcc dot gnu.org
  Reporter: bernd.edlinger at hotmail dot de

the attached test case shows unaligned accesses can be generated
on arm architecture, despite the -mno-unaligned-access option.
This does not happen at -O0 and -Og,
but it always happens at at -Os -O1 -O2 and -O3 to name a few.

assembler output for foo shows unaligned opcodes:

foo:
@ Function supports interworking.
@ args = 0, pretend = 0, frame = 0
@ frame_needed = 0, uses_anonymous_args = 0
@ link register save eliminated.
add ip, r0, r1, asl #3
add r1, ip, #1
ldmia   r1, {r0-r1}
str r2, [ip, #1]
str r3, [ip, #5]
bx  lr

reproduced with latest trunk:

  $ ../gcc-4.9-20130728/configure --target=arm-eabi
--prefix=/home/ed/gnu/arm-eabi --with-newlib --enable-languages=c,c++
--disable-hosted-libstdcxx --disable-__cxa_atexit

[Bug middle-end/58041] Unaligned access to arrays in packed structure

[bernd.edlinger at hotmail dot de]

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

--- Comment #1 from Bernd Edlinger  ---
Created attachment 30579
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=30579&action=edit
test case to show the bug

[Bug c++/58040] Cannot take address-of public using-declaration of member from protected base class

[daniel.kruegler at googlemail dot com]

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

Daniel Krügler  changed:

   What|Removed |Added

 CC||daniel.kruegler@googlemail.
   ||com

--- Comment #1 from Daniel Krügler  ---
The same problem occurs for gcc 4.9.0 20130616 (experimental)

[Bug middle-end/58041] Unaligned access to arrays in packed structure

[bernd.edlinger at hotmail dot de]

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

--- Comment #2 from Bernd Edlinger  ---
Sandra,

this seems to be unrelated to your strict-volatile-bitfields patch,
as it happens with or without that patch.

[Bug lto/58042] New: MinGW GCC produces problematic x64 executable with -O2 -static -flto -m64

[stanley82521 at gmail dot com]

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

Bug ID: 58042
   Summary: MinGW GCC produces problematic x64 executable with -O2
-static -flto -m64
   Product: gcc
   Version: 4.8.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: lto
  Assignee: unassigned at gcc dot gnu.org
  Reporter: stanley82521 at gmail dot com

The toolchain I use is MinGW-builds from Sourceforge, which uses runtime lib
provided by MinGW-w64 project, and this issue also appears in Ruben's build
from MinGW-w64. The code snipe below can be used to reproduce the problem:

#include
int main(){
std::cout << "Foo = " << 101 << std::endl;
return 0;
}

With "-O2 -flto -static -m64", GCC can produce a problematic x64 executable,
which will crash during execution. It will crash after output "Foo = ". This
issue appeared before the GCC 4.8.0 release and lasts till now, existing in the
4.8.1 and testing 4.9.0 build provided by MinGW-builds project. This problem
seems not a bug of MinGW-w64 runtime because compiling the source file without
any option described above can't reproduce the problem.

[Bug fortran/58043] New: Incorrect behaviour of polymorphic array

[frank.otto at pci dot uni-heidelberg.de]

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

Bug ID: 58043
   Summary: Incorrect behaviour of polymorphic array
   Product: gcc
   Version: 4.8.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: frank.otto at pci dot uni-heidelberg.de

Created attachment 30580
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=30580&action=edit
test case

The following test case (also attached) produces incorrect output using
gfortran 4.8.1 (also tested: 4.8.0, 4.7.3). It uses a polymorphic array
[dofs(:)] where the polymorphic type [dof_t] contains an allocatable array
[grd(:)]. When accessed through an element of the polymorphic array, the
array descriptor of grd(:) seems wrong.

 testcase.f90 

module types_m
implicit none

type,abstract :: dof_t
   integer :: gdim
   real(kind=8),allocatable :: grd(:)
   contains
   procedure(dofinit_if),deferred :: init
end type dof_t

type,extends(dof_t) :: adof_t
   contains
   procedure :: init => adofinit
end type adof_t

abstract interface
   subroutine dofinit_if(dof,gdim,xi,xf)
  import :: dof_t
  class(dof_t) :: dof
  integer  :: gdim
  real(kind=8) :: xi,xf
   end subroutine dofinit_if
end interface

contains

subroutine adofinit(dof,gdim,xi,xf)
   class(adof_t) :: dof
   integer   :: gdim,g
   real(kind=8)  :: xi,xf,dx
   dof%gdim = gdim
   allocate(dof%grd(gdim))
   dx = (xf-xi)/(gdim-1)
   do g=1,gdim
  dof%grd(g) = xi + (g-1)*dx
   enddo
   write (*,'(a)') " grd in adofinit "
   do g=1,gdim
  write (*,'(i5,f12.4)') g, dof%grd(g)
   enddo
end subroutine adofinit

end module types_m


program main
use types_m
implicit none

class(dof_t),pointer :: dofs(:)
integer  :: g

allocate(adof_t :: dofs(1))
call dofs(1)%init(17, -8.d0, 8.d0)

write (*,'(a)') " grd in main "
do g=1,dofs(1)%gdim
   write (*,'(i5,f12.4)') g, dofs(1)%grd(g)
enddo

end program main



 gfortran version 

$ gfortran -v
Using built-in specs.
COLLECT_GCC=gfortran
COLLECT_LTO_WRAPPER=/cvos/shared/apps/gcc/4.8.1/libexec/gcc/x86_64-unknown-linux-gnu/4.8.1/lto-wrapper
Target: x86_64-unknown-linux-gnu
Configured with: ../gcc-4.8.1/configure --prefix=/cvos/shared/apps/gcc/4.8.1
--enable-languages=c,c++,fortran,go,objc
--with-gmp=/cvos/shared/apps/gcc/4.8/support
--with-mpfr=/cvos/shared/apps/gcc/4.8/support
--with-mpc=/cvos/shared/apps/gcc/4.8/support
--with-isl=/cvos/shared/apps/gcc/4.8/support
--with-cloog=/cvos/shared/apps/gcc/4.8/support --disable-nls --enable-shared
--enable-threads=posix --with-system-zlib --with-tune=native
Thread model: posix
gcc version 4.8.1 (GCC) 



 Compilation 

$ gfortran -Wall testcase.f90 
(no messages)



 Observed Output 

$ ./a.out
 grd in adofinit 
1 -8.
2 -7.
3 -6.
4 -5.
5 -4.
6 -3.
7 -2.
8 -1.
9  0.
   10  1.
   11  2.
   12  3.
   13  4.
   14  5.
   15  6.
   16  7.
   17  8.
 grd in main 
1 -8.
2 -1.
3  6.
4  0.
5  0.
6  0.
7  0.
8  0.
9  0.
   10  0.
   11  0.
   12  0.
   13  0.
   14  0.
   15  0.
   16  0.
   17  0.



 Expected Output 

Both blocks of numbers should be the same.

When compiled with Intel Fortran 13.1.0, the test case produces the expected
output, and also no warnings are produced.



 Comments 

What also doesn't work:
* dof_t%grd as pointer instead of allocatable (same output)
* in main, dofs(:) as allocatable instead of pointer (same output)

What does work:
* Using a scalar [class(dof_t),pointer::dof] polymorphic variable instead
  of the polymorphic array.

The observed behaviour looks like something is wrong with the array
descriptor of grd(:), because this array is (in main) traversed with
a too large stride -- only every 7th element is visited. In a larger
program, this behaviour eventually leads to invalid memory access.

[Bug middle-end/58041] Unaligned access to arrays in packed structure

[mikpe at it dot uu.se]

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

Mikael Pettersson  changed:

   What|Removed |Added

 CC||mikpe at it dot uu.se

--- Comment #3 from Mikael Pettersson  ---
Running this program throws loads of alignment exceptions when it's compiled by
gcc-4.9 or gcc-4.8, targeting armv5tel-linux-gnueabi -O2 -marm.  Adding
-mno-unaligned-access makes no difference.

When compiled by gcc-4.7 it runs cleanly without any exceptions.

[Bug c++/58040] Cannot take address-of public using-declaration of member from protected base class

[paolo.carlini at oracle dot com]

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

Paolo Carlini  changed:

   What|Removed |Added

 CC||fabien at gcc dot gnu.org

--- Comment #2 from Paolo Carlini  ---
Fabien, are you interested in this?

[Bug c++/57734] Returning template alias to enum class fails with "invalid declarator"

[paolo.carlini at oracle dot com]

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

--- Comment #1 from Paolo Carlini  ---
This isn't just about returning, eg:

typedef eclass_alias test;

[Bug c++/32197] ICE when compiling with gcov options

[paolo.carlini at oracle dot com]

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

Paolo Carlini  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |INVALID

--- Comment #3 from Paolo Carlini  ---
Feedback not forthcoming. Testcase doesn't compile anymore.

[Bug c++/34624] templated code is rejected different type in nontype template argument

[paolo.carlini at oracle dot com]

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

Paolo Carlini  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 CC|gcc-bugs at gcc dot gnu.org|
 Resolution|--- |INVALID
  Known to fail||

--- Comment #12 from Paolo Carlini  ---
Closing.

[Bug c++/36266] C++ typedef misplaced in DWARF information

[paolo.carlini at oracle dot com]

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

Paolo Carlini  changed:

   What|Removed |Added

 CC|gcc-bugs at gcc dot gnu.org|ccoutant at gcc dot 
gnu.org

--- Comment #2 from Paolo Carlini  ---
Cary, could you please double check this is already fixed?

[Bug c++/37140] type inherited from base class not recognized

[paolo.carlini at oracle dot com]

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

Paolo Carlini  changed:

   What|Removed |Added

 CC|fabien at gcc dot gnu.org  |

--- Comment #7 from Paolo Carlini  ---
Any news on this?

[Bug c++/37140] type inherited from base class not recognized

[paolo.carlini at oracle dot com]

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

Paolo Carlini  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2013-08-01
 Ever confirmed|0   |1

[Bug middle-end/58041] Unaligned access to arrays in packed structure

[mikpe at it dot uu.se]

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

Mikael Pettersson  changed:

   What|Removed |Added

 CC||wschmidt at gcc dot gnu.org

--- Comment #4 from Mikael Pettersson  ---
Started with Bill Schmidt's PR46556 patch in r190037.  (Author CC:d.)

Comparing the generated code between 190036 and 190037 clearly shows how the
misaligned accesses were wrongly replaced by aligned accesses:

--- pr58041.s-r190036   2013-08-01 13:30:59.264514025 +0200
+++ pr58041.s-r190037   2013-08-01 13:27:38.874840851 +0200
@@ -18,37 +18,11 @@
@ args = 0, pretend = 0, frame = 0
@ frame_needed = 0, uses_anonymous_args = 0
@ link register save eliminated.
-   stmfd   sp!, {r4, r5, r6, r7, r8, r9, r10, fp}
add ip, r0, r1, asl #3
-   ldrbr7, [ip, #2]@ zero_extendqisi2
-   ldrbr6, [ip, #6]@ zero_extendqisi2
-   ldrbr0, [ip, #1]@ zero_extendqisi2
-   ldrbr1, [ip, #5]@ zero_extendqisi2
-   ldrbr5, [ip, #3]@ zero_extendqisi2
-   ldrbr4, [ip, #7]@ zero_extendqisi2
-   orr r0, r0, r7, asl #8
-   orr r1, r1, r6, asl #8
-   ldrbr10, [ip, #4]   @ zero_extendqisi2
-   ldrbr6, [ip, #8]@ zero_extendqisi2
-   mov fp, r2, lsr #8
-   orr r0, r0, r5, asl #16
-   mov r9, r2, lsr #16
-   mov r8, r2, lsr #24
-   mov r7, r3, lsr #8
-   orr r1, r1, r4, asl #16
-   mov r5, r3, lsr #16
-   mov r4, r3, lsr #24
-   strbfp, [ip, #2]
-   strbr2, [ip, #1]
-   strbr9, [ip, #3]
-   strbr8, [ip, #4]
-   strbr7, [ip, #6]
-   strbr3, [ip, #5]
-   strbr5, [ip, #7]
-   strbr4, [ip, #8]
-   orr r0, r0, r10, asl #24
-   orr r1, r1, r6, asl #24
-   ldmfd   sp!, {r4, r5, r6, r7, r8, r9, r10, fp}
+   ldr r0, [ip, #1]
+   ldr r1, [ip, #5]
+   str r2, [ip, #1]
+   str r3, [ip, #5]
bx  lr
.size   foo, .-foo
.section.text.startup,"ax",%progbits

[Bug middle-end/58041] Unaligned access to arrays in packed structure

[mikpe at it dot uu.se]

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

--- Comment #5 from Mikael Pettersson  ---
I see the exact same failure pattern on sparc64-linux: 4.7 generates working
code, 4.8 and 4.9 generate code that SIGBUS:es, failure starts with r190037, 
-m32 or -m64 makes no difference.

[Bug libfortran/58020] Code for handling IEEE exceptions

[dominiq at lps dot ens.fr]

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

--- Comment #11 from Dominique d'Humieres  ---
> The issues have hopefully been resolved and are now in the package. 
> See http://mathalacarte.com/hpcconsult

> Thanks for the comments made above.  Give feedback where it makes sense.

When c_control.c is compiled with -O3 or above, IEEE_tests_gfortran.f90 aborts
at run time with:

 Computing (w/x87) D=sqrt(A/B+C), D=0., A=0., B=0., C=0., correctly signals 
 IEEE_INVALID using gfortran  

Program received signal SIGFPE: Floating-point exception - erroneous arithmetic
operation.

Backtrace for this error:
#0  0x1000240c2
#1  0x100025a1e
#2  0x7fff80df91b9
Floating exception

The test runs without problem with -O2.

[Bug middle-end/58041] Unaligned access to arrays in packed structure

[wschmidt at gcc dot gnu.org]

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

--- Comment #6 from Bill Schmidt  ---
I'll investigate.  It may be a day or two before I can get to it, but this is
pretty clearly my issue.

Thanks,
Bill

[Bug testsuite/55956] Multiple failures on powerpc-apple-darwin9 in the acats test if the check-ada is run from the gcc directory

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

 Status|SUSPENDED   |WAITING

--- Comment #5 from Dominique d'Humieres  ---
> This is another manifestation of 44107.

Confirmed.

How difficult would it be to prevent testing Ada from the gcc directory for
pre-darwin10?

Where could this behavior be documented?

[Bug inline-asm/58044] New: -mno-see2avx does not seems to work

[jerome.pouiller at gmail dot com]

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

Bug ID: 58044
   Summary: -mno-see2avx does not seems to work
   Product: gcc
   Version: 4.7.2
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: inline-asm
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jerome.pouiller at gmail dot com

Created attachment 30581
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=30581&action=edit
Test case

It looks like gcc alway translate sse instruction in avx instruction whatever
the use of option -mno-see2avx. 

If  you compile attached tests case with
  gcc -Wall -mtune=generic -mavx2 intrinsics.c -o avx.out 
and with 
  gcc -Wall -mtune=generic -mavx2 -mno-sse2avx intrinsics.c -o noavx.out 

the assembly is the same. Maybe I do something wrong?

--
Jérôme Pouiller

[Bug fortran/58043] [OOP] Incorrect behaviour of polymorphic array

[janus at gcc dot gnu.org]

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

janus at gcc dot gnu.org changed:

   What|Removed |Added

   Keywords||wrong-code
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2013-08-01
 CC||janus at gcc dot gnu.org
Summary|Incorrect behaviour of  |[OOP] Incorrect behaviour
   |polymorphic array   |of polymorphic array
 Ever confirmed|0   |1

--- Comment #1 from janus at gcc dot gnu.org ---
I can confirm the described behavior with gfortran 4.7, 4.8 and trunk.

In principle -fdump-tree-original should show what goes wrong ...

[Bug c++/58045] New: gcc 4.8 produces an undefined reference to an inline function

[rafael.espindola at gmail dot com]

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

Bug ID: 58045
   Summary: gcc 4.8 produces an undefined reference to an inline
function
   Product: gcc
   Version: 4.8.2
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: rafael.espindola at gmail dot com
CC: hubicka at gcc dot gnu.org, jason at redhat dot com

Created attachment 30582
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=30582&action=edit
testcase

This may or may not be a duplicate of bug 53808.

When compiling this testcase with

cc1plus llvm-ar.ii -quiet -std=c++11 -fprofile-arcs -o test.s -O2

The produced assembly has an undefined reference to
_ZNK4llvm14raw_fd_ostream11current_posEv, but this function is defined inline:

virtual uint64_t current_pos() const {
return pos;
}

This causes the link to fail when building with -fvisibility-inlines-hidden and
shared libraries.

GCC should avoid devirtualizing or emit a copy of the callee.

[Bug middle-end/57748] [4.8/4.9 Regression] ICE when expanding assignment to unaligned zero-sized array

[jamborm at gcc dot gnu.org]

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

--- Comment #13 from Martin Jambor  ---
Created attachment 30583
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=30583&action=edit
Untested fix

This is how I'd like to fix the problem if the patch passes bootstrap
and testing (on x86_64-linux, any additional testing welcome).

I believe that the problem is that while compute_record_mode in
stor-layout.c makes sure it assigns BLK mode to structs with flexible
arrays, it has no such provisions for zero length arrays
(http://gcc.gnu.org/onlinedocs/gcc-4.8.1/gcc/Zero-Length.html).  I
think that in order to avoid problems and surprises like this one, we
should assign both variable array possibilities the same mode.

[Bug fortran/58043] [OOP] Incorrect behaviour of polymorphic array

[janus at gcc dot gnu.org]

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

--- Comment #2 from janus at gcc dot gnu.org ---
Here is a reduced test case, which demonstrates the same problem in a somewhat
more compact manner:


program main

  implicit none

  type :: adof_t
real :: grd(1:2)
  end type

  class(adof_t), allocatable :: dofs(:)

  allocate(dofs(1))
  call adofinit(dofs(1))

  write (*,'(a)') " grd in main "
  write (*,'(2f12.4)') dofs(1)%grd(1), dofs(1)%grd(2)

contains

  subroutine adofinit (dof)
class(adof_t) :: dof
dof%grd = (/ 1., 2. /)
write (*,'(a)') " grd in adofinit "
write (*,'(2f12.4)') dof%grd(1), dof%grd(2)
  end subroutine adofinit

end


The output is

 grd in adofinit 
  1.  2.
 grd in main 
  1.  0.

[Bug fortran/58043] [OOP] Incorrect behaviour of polymorphic array

[janus at gcc dot gnu.org]

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

--- Comment #3 from janus at gcc dot gnu.org ---
The WRITE of the second element in main is translated into: 

_gfortran_transfer_real_write (&dt_parm.7, (real(kind=4) *) &((struct adof_t *)
dofs._data.data + (sizetype) ((dofs._data.offset + 1) * (integer(kind=8))
dofs._vptr->_size))->grd + (sizetype) dofs._vptr->_size, 4);


The problem is apparently that "grd" does not receive the correct indexing
here, but instead "dofs._vptr->_size" is added to the address, which however is
the element size of the "dofs" array and not of "grd"!

[Bug fortran/55207] Automatic deallocation of variables declared in the main program

[janus at gcc dot gnu.org]

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

--- Comment #9 from janus at gcc dot gnu.org ---
(In reply to janus from comment #8)
> I think we need the patch in comment 6 after all. But how do we get rid of
> the remaining regressions?

Simplest solution: Move the code in these test cases from the main program into
a subroutine (or similar). Then the variables will not be SAVEd and all
optimizations can be applied as before. (However, it's a bit unfortunate that
we lose the possibility to do these optimizations in the main program.)

[Bug fortran/55207] Automatic deallocation of variables declared in the main program

[janus at gcc dot gnu.org]

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

janus at gcc dot gnu.org changed:

   What|Removed |Added

  Attachment #28620|0   |1
is obsolete||

--- Comment #10 from janus at gcc dot gnu.org ---
Created attachment 30584
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=30584&action=edit
new patch

Here is a new version of the patch which regtests cleanly.

The trans-decl.c parts are not strictly necessary. They just do some clean-up.

[Bug c++/58046] New: template operator= in SFINAE class

[suibaka at gmail dot com]

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

Bug ID: 58046
   Summary: template operator= in SFINAE class
   Product: gcc
   Version: 4.7.2
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: suibaka at gmail dot com

I think the following code should be compile error,
but the result is ICE in gcc-4.7.2.

The error still exists in gcc HEAD.

$ gcc -v
Using built-in specs.
COLLECT_GCC=C:\MinGW\bin\gcc.exe
COLLECT_LTO_WRAPPER=c:/mingw/bin/../libexec/gcc/mingw32/4.7.2/lto-wrapper.exe
Target: mingw32
Configured with: ../gcc-4.7.2/configure
--enable-languages=c,c++,ada,fortran,obj
c,obj-c++ --disable-sjlj-exceptions --with-dwarf2 --enable-shared
--enable-libgo
mp --disable-win32-registry --enable-libstdcxx-debug
--disable-build-poststage1-
with-cxx --enable-version-specific-runtime-libs --build=mingw32 --prefix=/mingw
Thread model: win32
gcc version 4.7.2 (GCC)


The code:

#include 

extern void* enabler; 

template ::value>::type*& = enabler>
class A
{
public:
A()
{}
template 
A& operator=( A&& rhs )
{
return *this;
}
};

int main()
{
A a_i;
A a_d;

a_i = a_d;
}


The error(in 4.7.2):

$ g++ main.cc -Wall -std=c++11
main.cc: In function 'int main()':
main.cc:24:11: internal compiler error: in unify, at cp/pt.c:16956
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.


The error(in HEAD):

prog.cc: In substitution of 'template A >& A >::operator=(A&&) [with U = ]':
prog.cc:24:9:   required from here
prog.cc:24:9: internal compiler error: in unify, at cp/pt.c:17384
 a_i = a_d;

[Bug libfortran/58020] Code for handling IEEE exceptions

[richard.koolhans at gmail dot com]

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

--- Comment #12 from richard.koolhans at gmail dot com ---
Thanks for doing the test with -O3.  That is what I see, also.  My tests show:

With -O0 everything works.
With -O1 everything runs but there are some failures.
With -O2 everything runs but there are some failures.
With -O3 there is a crash, as noted.

I searched and found a suggestion about suppressing optimization within a C
code, using the gcc compiler:

http://stackoverflow.com/questions/2219829/how-to-prevent-gcc-optimizing-some-statements-in-c

I gave my local variables the additional *volatile* attribute and that solved
the optimization problem. This is preferred to requiring that -O0 be used in
the compile line.  That way other optimizations are not suppressed. My
understanding ends there.

[Bug c++/58047] New: parse error with typedef introduced from base class

[roshan.shariff at gmail dot com]

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

Bug ID: 58047
   Summary: parse error with typedef introduced from base class
   Product: gcc
   Version: 4.8.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: roshan.shariff at gmail dot com

Created attachment 30585
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=30585&action=edit
Test case exhibiting parse error

Trying to compile the attached code with g++ 4.8.1 gives an error. The code
compiles and works fine with clang.

template 
struct print_arg {
  void print () { std::cout << N << '\n'; }
};

struct const_holder {
  static constexpr int CONSTANT = 42;
};

template 
struct identity {
  using type = T;
};

template 
struct test_case : public identity {
  using typename identity::type;
  print_arg printer; // <- parse error
};

int main () {
  // Should print 42
  test_case().printer.print();
}

The attached file contains two variants of the above code that do work fine.
Trying to compile it produces the following error message:

$ g++ -std=c++11 gccbug.cpp -o gccbug
gccbug.cpp:31:3: error: parse error in template argument list
   print_arg printer;
   ^
gccbug.cpp: In instantiation of 'struct test_case':
gccbug.cpp:46:27:   required from here
gccbug.cpp:31:29: error: expected primary-expression
   print_arg printer;
 ^
gccbug.cpp: In function 'int main()':
gccbug.cpp:46:29: error: 'struct test_case' has no member named
'printer'
   test_case().printer.print();

[Bug middle-end/58041] Unaligned access to arrays in packed structure

[wschmidt at gcc dot gnu.org]

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

Bill Schmidt  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2013-08-01
   Assignee|unassigned at gcc dot gnu.org  |wschmidt at gcc dot 
gnu.org
 Ever confirmed|0   |1

--- Comment #7 from Bill Schmidt  ---
This shouldn't be too hard to fix.  Looks like we are missing a check for
possibly unaligned data when STRICT_ALIGNMENT is set.  The logic for unaligned
data can be exposed from a static routine in tree-ssa-ivopts.c.  I'll work up a
trial patch.

[Bug middle-end/58041] Unaligned access to arrays in packed structure

[jamborm at gcc dot gnu.org]

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

--- Comment #8 from Martin Jambor  ---
I believe that you need to set alignment of the type of MEM_REFs you
create in replace_ref along the lines it is done in
build_ref_for_offset in tree-sra.c.

I wonder whether STRICT_ALIGNMENT has really any meaning nowadays,
given that for example x86_64 is not a strict-alignment platform
except for SSE vectors.

[Bug c/58048] New: internal compiler error: Max. number of generated reload insns per insn is achieved (90)

[n-gcc at nn dot kiev.ua]

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

Bug ID: 58048
   Summary: internal compiler error: Max. number of generated
reload insns per insn is achieved (90)
   Product: gcc
   Version: 4.8.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: n-gcc at nn dot kiev.ua

Created attachment 30586
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=30586&action=edit
preprocessed input file

Observed both on 4.8.1 and 4.9.0. It gives the same message as #55247 but the
latter is declared fixed for 4.8.0. Compiler versions are from FreeBSD ports.

Example for gcc 4.8.1. Command:

gcc48 -v -c d.c -Wall -Wextra -g3 -Og -save-temps

Its output:

Using built-in specs.
COLLECT_GCC=gcc48
Target: i386-portbld-freebsd9.1
Configured with: ./../gcc-4.8-20130418/configure --disable-nls
--libdir=/usr/local/lib/gcc48 --libexecdir=/usr/local/libexec/gcc48
--program-suffix=48 --with-as=/usr/local/bin/as --with-gmp=/usr/local
--with-gxx-include-dir=/usr/local/lib/gcc48/include/c++/
--with-ld=/usr/local/bin/ld --with-libiconv-prefix=/usr/local
--with-pkgversion='FreeBSD Ports Collection' --with-system-zlib
--disable-libgcj --enable-languages=c,c++,objc,fortran --prefix=/usr/local
--mandir=/usr/local/man --infodir=/usr/local/info/gcc48
--build=i386-portbld-freebsd9.1
Thread model: posix
gcc version 4.8.1 20130418 (prerelease) (FreeBSD Ports Collection) 
COLLECT_GCC_OPTIONS='-v' '-c' '-Wall' '-Wextra' '-g3' '-Og' '-save-temps'
'-mtune=generic' '-march=i486'
 /usr/local/libexec/gcc48/gcc/i386-portbld-freebsd9.1/4.8.1/cc1 -E -quiet -v
-dD d.c -mtune=generic -march=i486 -Wall -Wextra -g3 -fworking-directory -Og
-fpch-preprocess -o d.i
ignoring nonexistent directory
"/usr/local/lib/gcc48/gcc/i386-portbld-freebsd9.1/4.8.1/../../../../../i386-portbld-freebsd9.1/include"
#include "..." search starts here:
#include <...> search starts here:
 /usr/local/lib/gcc48/gcc/i386-portbld-freebsd9.1/4.8.1/include
 /usr/local/include
 /usr/local/lib/gcc48/gcc/i386-portbld-freebsd9.1/4.8.1/include-fixed
 /usr/include
End of search list.
COLLECT_GCC_OPTIONS='-v' '-c' '-Wall' '-Wextra' '-g3' '-Og' '-save-temps'
'-mtune=generic' '-march=i486'
 /usr/local/libexec/gcc48/gcc/i386-portbld-freebsd9.1/4.8.1/cc1 -fpreprocessed
d.i -quiet -dumpbase d.c -mtune=generic -march=i486 -auxbase d -g3 -Og -Wall
-Wextra -version -o d.s
GNU C (FreeBSD Ports Collection) version 4.8.1 20130418 (prerelease)
(i386-portbld-freebsd9.1)
compiled by GNU C version 4.8.1 20130418 (prerelease), GMP version
5.1.1, MPFR version 3.1.2, MPC version 0.9
warning: GMP header version 5.1.1 differs from library version 5.1.2.
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
GNU C (FreeBSD Ports Collection) version 4.8.1 20130418 (prerelease)
(i386-portbld-freebsd9.1)
compiled by GNU C version 4.8.1 20130418 (prerelease), GMP version
5.1.1, MPFR version 3.1.2, MPC version 0.9
warning: GMP header version 5.1.1 differs from library version 5.1.2.
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
Compiler executable checksum: b4e187455a377c1d9edc9370c28ad081
d.c: In function 'div3':
d.c:93:15: warning: unused parameter 'n' [-Wunused-parameter]
 div3(unsigned n, unsigned d, unsigned *qp, unsigned *rp, unsigned *t)
   ^
d.c:93:40: warning: unused parameter 'qp' [-Wunused-parameter]
 div3(unsigned n, unsigned d, unsigned *qp, unsigned *rp, unsigned *t)
^
d.c:93:54: warning: unused parameter 'rp' [-Wunused-parameter]
 div3(unsigned n, unsigned d, unsigned *qp, unsigned *rp, unsigned *t)
  ^
d.c:107:1: internal compiler error: Max. number of generated reload insns per
insn is achieved (90)

 }
 ^
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.

Output for 4.9.0:

Using built-in specs.
COLLECT_GCC=gcc49
Target: i386-portbld-freebsd9.1
Configured with: ./../gcc-4.9-20130630/configure --disable-nls
--libdir=/usr/loc
al/lib/gcc49 --libexecdir=/usr/local/libexec/gcc49 --program-suffix=49
--with-as
=/usr/local/bin/as --with-gmp=/usr/local
--with-gxx-include-dir=/usr/local/lib/g
cc49/include/c++/ --with-ld=/usr/local/bin/ld --with-libiconv-prefix=/usr/local 
--with-pkgversion='FreeBSD Ports Collection' --with-system-zlib
--disable-libgcj
 --enable-languages=c,c++,objc,fortran --prefix=/usr/local
--mandir=/usr/local/m
an --infodir=/usr/local/info/gcc49 --build=i386-portbld-freebsd9.1
Thread model: posix
gcc version 4.9.0 20130630 (experimental) (FreeBSD Ports Collection) 
COLLECT_GCC_OPTIONS='-v' '-c' '-Wall' '-Wextra' '-g3' '-Og' '-save-temps'
'-mtun
e=generic' '-march=i486'
 /usr/local/libexec/gcc49/gcc/i386-portbld-freebsd9.1/4.9.0/cc1 -E -quiet -v
-dD
 d.c -mtune=generic -march

[Bug c/58048] internal compiler error: Max. number of generated reload insns per insn is achieved (90)

[mikpe at it dot uu.se]

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

Mikael Pettersson  changed:

   What|Removed |Added

 CC||mikpe at it dot uu.se

--- Comment #1 from Mikael Pettersson  ---
The ICE reproduces on x86_64-linux with gcc-4.9-20130728 and gcc-4.8-20130725,
both -m32 and -m64.

[Bug middle-end/58041] Unaligned access to arrays in packed structure

[jamborm at gcc dot gnu.org]

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

--- Comment #9 from Martin Jambor  ---
More specifically, if I am correct assuming that the MEM_REF
replace_ref builds always accesses exactly the same memory as the
previous access *expr does (and only the address is computed better)
and that *expr is how the function accessed that memory before, then I
think what you need is the following (untested, except that I know it
seems to fix the testcase, at least the assembly looks very different
:-)

*** /tmp/heQHTs_gimple-ssa-strength-reduction.c Thu Aug  1 18:43:45 2013
--- gcc/gimple-ssa-strength-reduction.c Thu Aug  1 18:38:31 2013
*** dump_incr_vec (void)
*** 1728,1738 
  static void
  replace_ref (tree *expr, slsr_cand_t c)
  {
!   tree add_expr = fold_build2 (POINTER_PLUS_EXPR, TREE_TYPE (c->base_expr),
!  c->base_expr, c->stride);
!   tree mem_ref = fold_build2 (MEM_REF, TREE_TYPE (*expr), add_expr,
! double_int_to_tree (c->cand_type, c->index));
!   
/* Gimplify the base addressing expression for the new MEM_REF tree.  */
gimple_stmt_iterator gsi = gsi_for_stmt (c->cand_stmt);
TREE_OPERAND (mem_ref, 0)
--- 1728,1748 
  static void
  replace_ref (tree *expr, slsr_cand_t c)
  {
!   tree add_expr, mem_ref, acc_type = TREE_TYPE (*expr);
!   unsigned HOST_WIDE_INT misalign;
!   unsigned align;
! 
!   get_object_alignment_1 (*expr, &align, &misalign);
!   if (misalign != 0)
! align = (misalign & -misalign);
!   if (align < TYPE_ALIGN (acc_type))
! acc_type = build_aligned_type (acc_type, align);
! 
!   add_expr = fold_build2 (POINTER_PLUS_EXPR, TREE_TYPE (c->base_expr),
! c->base_expr, c->stride);
!   mem_ref = fold_build2 (MEM_REF, acc_type, add_expr,
!double_int_to_tree (c->cand_type, c->index));
! 
/* Gimplify the base addressing expression for the new MEM_REF tree.  */
gimple_stmt_iterator gsi = gsi_for_stmt (c->cand_stmt);
TREE_OPERAND (mem_ref, 0)

[Bug libstdc++/57997] Segmentation fault after returning valarray expression from an auto function

[roystgnr at ices dot utexas.edu]

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

--- Comment #6 from Roy Stogner  ---
Copyright assignment shouldn't be a problem.  The one serious non-technical
problem is going to be finding time to work on a patch.

The only technical issue I've discovered so far is that making this robust with
no efficiency penalty seems to be impossible without operator overloads that
take rvalue references.  libstdc++ policy is that C++11 features are fine to
use if wrapped in
#if __cplusplus >= 201103L
and C++03 compatibility is maintained?

[Bug middle-end/58041] Unaligned access to arrays in packed structure

[jamborm at gcc dot gnu.org]

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

--- Comment #10 from Martin Jambor  ---
Created attachment 30587
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=30587&action=edit
x86_64-linux testcase

To prove the point, this is an x86_64-linux testcase.  I will
bootstrap and test the patch overnight and if it passes, I will submit
it to the mailing list.

Still, please confirm my assumptions outlined above are correct.
Thanks.

[Bug middle-end/58041] Unaligned access to arrays in packed structure

[wschmidt at gcc dot gnu.org]

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

--- Comment #11 from Bill Schmidt  ---
Hi Martin,

Your assumptions are correct, but I'm not sure this is the best place to handle
it.  It looks like what you are doing is replacing one already correct memory
reference with another, both of which will generate somewhat nasty code. 
Therefore there isn't much reason to do the transformation at all in the first
place.  I think I would rather analyze the reference when considering adding
the reference to the candidate table, and leaving it out of consideration
altogether.  What do you think?

For example, I'm looking at adding the following ahead of the call to
restructure_reference in slsr_process_ref:

  /* If this reference doesn't meet alignment restrictions, don't
 make it a candidate.  Logic similar to that in tree-ssa-loop-ivopts.c:
 may_be_unaligned_p(), without the STEP check.  */
  if (mode != BLKmode)
{
  tree base_type = TREE_TYPE (base);
  unsigned base_align = get_object_alignment (base);
  unsigned mode_align = GET_MODE_ALIGNMENT (mode);
  base_align = MAX (base_align, TYPE_ALIGN (base_type));

  if (base_align < mode_align
  || (bitpos % mode_align) != 0
  || (bitpos % BITS_PER_UNIT) != 0)
return;

  if (offset
  && (highest_pow2_factor (offset) * BITS_PER_UNIT) < mode_align)
return;
}

[Bug middle-end/58041] Unaligned access to arrays in packed structure

[wschmidt at gcc dot gnu.org]

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

--- Comment #12 from Bill Schmidt  ---
...which apparently is not quite right, since the candidates still appear in
the table.  Hm.  But you get the idea -- do the check earlier.

[Bug middle-end/58041] Unaligned access to arrays in packed structure

[bernd.edlinger at hotmail dot de]

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

--- Comment #13 from Bernd Edlinger  ---
Hi,

just one question, how about the -m[no-]unaligned-access option?

If -munaligned-access had been given the code was almost right,
I mean AFAIK ldr/str should be handled in hardware but ldmia generates
an alignment exception and _may_ be emulated by an IRQ handler,
but that would not be very efficient.

When -mno-unaligned-access is given any ldr/str on unaligned
addresses have to be avoided.

[Bug middle-end/58041] Unaligned access to arrays in packed structure

[wschmidt at gcc dot gnu.org]

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

--- Comment #14 from Bill Schmidt  ---
(In reply to Bernd Edlinger from comment #13)
> Hi,
> 
> just one question, how about the -m[no-]unaligned-access option?
> 
> If -munaligned-access had been given the code was almost right,
> I mean AFAIK ldr/str should be handled in hardware but ldmia generates
> an alignment exception and _may_ be emulated by an IRQ handler,
> but that would not be very efficient.
> 
> When -mno-unaligned-access is given any ldr/str on unaligned
> addresses have to be avoided.

Well, unfortunately -mno-unaligned-access does not provide any information to
the middle end.  It's all handled in the ARM back end.  So without directly
checking an ARM-specific option in the middle-end (evil), we don't have a good
solution for that.  That's how I initially started looking at STRICT_ALIGNMENT,
which ARM and Sparc have in common.

However, since this is supposed to be an optimization and it is common for
misaligned memory accesses to suffer a penalty, I think it is better just to
not "optimize" when the memory access is misaligned, and leave it to the target
back ends to do their normal cleanups and workarounds.

[Bug middle-end/58041] Unaligned access to arrays in packed structure

[wschmidt at gcc dot gnu.org]

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

--- Comment #15 from Bill Schmidt  ---
Bernd, Mikael, Martin:  Could you please test this on your respective targets?

Index: gcc/gimple-ssa-strength-reduction.c
===
--- gcc/gimple-ssa-strength-reduction.c(revision 201413)
+++ gcc/gimple-ssa-strength-reduction.c(working copy)
@@ -845,6 +845,8 @@ slsr_process_ref (gimple gs)
   int unsignedp, volatilep;
   double_int index;
   slsr_cand_t c;
+  unsigned HOST_WIDE_INT misalign;
+  unsigned align;

   if (gimple_vdef (gs))
 ref_expr = gimple_assign_lhs (gs);
@@ -857,6 +859,16 @@ slsr_process_ref (gimple gs)
   && DECL_BIT_FIELD (TREE_OPERAND (ref_expr, 1
 return;

+  /* If this reference doesn't meet alignment restrictions, don't
+ make it a candidate.  */
+  get_object_alignment_1 (ref_expr, &align, &misalign);
+
+  if (misalign != 0)
+align = (misalign & -misalign);
+
+  if (align < TYPE_ALIGN (TREE_TYPE (ref_expr)))
+return;
+
   base = get_inner_reference (ref_expr, &bitsize, &bitpos, &offset, &mode,
   &unsignedp, &volatilep, false);
   index = double_int::from_uhwi (bitpos);

Thanks,
Bill

[Bug libstdc++/57997] Segmentation fault after returning valarray expression from an auto function

[paolo.carlini at oracle dot com]

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

--- Comment #7 from Paolo Carlini  ---
I think so, yes. Your help is welcome anyway, worst case, we'll apply the
changes for the next release series instead of 4.9. In a few hours I will send
you privately the questionnaire to request the official Copyright Assignment
forms to FSF.

[Bug middle-end/58041] Unaligned access to arrays in packed structure

[bernd.edlinger at hotmail dot de]

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

--- Comment #16 from Bernd Edlinger  ---
(In reply to Bill Schmidt from comment #15)
> Bernd, Mikael, Martin:  Could you please test this on your respective
> targets?

Congatulations!

it works.

If I compile with -mno-unaligned-access all accesses are
ldrb/strb as it should be.
And if I compile with -mcpu=cortex-a9 -munaligned-access
the code is also OK, no ldmia's any more. The back end seems to
have fixed that for us.

foo:
@ args = 0, pretend = 0, frame = 0
@ frame_needed = 0, uses_anonymous_args = 0
@ link register save eliminated.
add ip, r0, r1, asl #3
ldr r0, [ip, #1]@ unaligned
ldr r1, [ip, #5]@ unaligned
str r2, [ip, #1]@ unaligned
str r3, [ip, #5]@ unaligned
bx  lr

which is perfectly OK for cortex-a9.

[Bug middle-end/58041] Unaligned access to arrays in packed structure

[wschmidt at gcc dot gnu.org]

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

--- Comment #17 from Bill Schmidt  ---
Excellent!  Thanks for the confirmation.

[Bug middle-end/58041] Unaligned access to arrays in packed structure

[mikpe at it dot uu.se]

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

--- Comment #18 from Mikael Pettersson  ---
(In reply to Bill Schmidt from comment #15)
> Bernd, Mikael, Martin:  Could you please test this on your respective
> targets?

This patch eliminates the misalignment faults for me on both ARMv5TE and SPARC.

[Bug c++/54537] undiagnosed using-declaration conflicting with used function

[bergner at gcc dot gnu.org]

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

Peter Bergner  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
URL||http://gcc.gnu.org/ml/gcc-p
   ||atches/2012-11/msg01166.htm
   ||l
 CC||bergner at gcc dot gnu.org
 Resolution|--- |FIXED

--- Comment #1 from Peter Bergner  ---
Given the OK by Paolo, I retested the patch from:

http://gcc.gnu.org/ml/gcc-patches/2012-11/msg01166.html

It needed a small change to the expected error message from using9.C, but
otherwise bootstrapped and regtested with no errors.  Committed to mainline as
revision 201414.

I have also asked about the appropriateness of backporting it to the FSF 4.8
branch.

[Bug c++/54537] undiagnosed using-declaration conflicting with used function

[bergner at gcc dot gnu.org]

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

Peter Bergner  changed:

   What|Removed |Added

 Status|RESOLVED|CLOSED

--- Comment #2 from Peter Bergner  ---
Fixed in mainline.

[Bug fortran/57710] [OOP] [F08] _vptr not set for allocatable CLASS component inside BLOCK

[burnus at gcc dot gnu.org]

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

--- Comment #5 from Tobias Burnus  ---
(In reply to janus from comment #2)
> Can't we do a 'static' initialization (of _vptr *and* _data) in both cases?

Well, you need to free and finalize the variable - hence, it cannot be static.

[Bug rtl-optimization/57963] LRA S/390: esa mode failure memcpy-chk

[vmakarov at gcc dot gnu.org]

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

--- Comment #1 from Vladimir Makarov  ---
Thanks, Andreas.  I've reproduced the bug.  I hope to fix it on this week.

[Bug tree-optimization/57994] Constant folding of infinity

[vincent-gcc at vinc17 dot net]

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

--- Comment #13 from Vincent Lefèvre  ---
A difference that may occur in the future if the C library adds a rsqrt
function (based on the IEEE 754-2008 rSqrt function) or constant folding is
used on builtins: in MPFR, mpfr_rec_sqrt on -0 gives +Inf, not -Inf.

[Bug fortran/55207] Automatic deallocation of variables declared in the main program

[burnus at gcc dot gnu.org]

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

Tobias Burnus  changed:

   What|Removed |Added

 CC||burnus at gcc dot gnu.org

--- Comment #11 from Tobias Burnus  ---
(In reply to janus from comment #10)
> Created attachment 30584 [details]
> new patch

+  if ((gfc_current_state () == COMP_MODULE
+   || gfc_current_state () == COMP_PROGRAM)

I haven't tried the patch, but does it work correctly with BLOCK? (It might
well be valid.) For instance, "i" in the following code shouldn't acquire the
SAVE attribute:

  program main
block
  integer :: i
end block
  end program main

[Bug fortran/57306] [OOP] [F08] ICE on valid with class pointer initialization

[burnus at gcc dot gnu.org]

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

--- Comment #10 from Tobias Burnus  ---
> Putting this inside a subroutine, one gets:
> 
>   class(c), pointer :: px => x
>   1
> Error: Pointer initialization target at (1) must have the SAVE attribute

That sounds like a bug:

"Explicit initialization of a variable that is not in a common block implies
the SAVE attribute, which may be confirmed by explicit specification." (5.2.3
Initialization, F2008)

And "px" is clearly initialized - see R505 and "The appearance of
initialization in an entity-decl for an entity without the PARAMETER attribute
species that
the entity is a variable with explicit initialization."

[Bug fortran/55207] Automatic deallocation of variables declared in the main program

[janus at gcc dot gnu.org]

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

--- Comment #12 from janus at gcc dot gnu.org ---
(In reply to Tobias Burnus from comment #11)
> 
> +  if ((gfc_current_state () == COMP_MODULE
> +   || gfc_current_state () == COMP_PROGRAM)
> 
> I haven't tried the patch, but does it work correctly with BLOCK? (It might
> well be valid.)

Without actually trying it: I would say it should work, since a BLOCK construct
would imply COMP_BLOCK here, so that the save attribute is not set ...

[Bug fortran/57306] [OOP] [F08] ICE on valid with class pointer initialization

[janus at gcc dot gnu.org]

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

--- Comment #11 from janus at gcc dot gnu.org ---
(In reply to Tobias Burnus from comment #10)
> > Putting this inside a subroutine, one gets:
> > 
> >   class(c), pointer :: px => x
> >   1
> > Error: Pointer initialization target at (1) must have the SAVE attribute
> 
> That sounds like a bug:

Ah, good point. Clearly we need to make sure that px gets marked as
SAVE_IMPLICIT here! Somehow I missed this on the first glance ...

[Bug c++/58046] template operator= in SFINAE class

[paolo.carlini at oracle dot com]

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

Paolo Carlini  changed:

   What|Removed |Added

   Keywords||ice-on-invalid-code
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2013-08-01
 Ever confirmed|0   |1

[Bug c++/58047] parse error with typedef introduced from base class

[paolo.carlini at oracle dot com]

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

Paolo Carlini  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2013-08-01
 CC|roshan.shariff at gmail dot com|
 Ever confirmed|0   |1

[Bug libstdc++/57779] vector insert fails to diagnose iterators pointing into *this in debug mode

[paolo.carlini at oracle dot com]

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

Paolo Carlini  changed:

   What|Removed |Added

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

--- Comment #4 from Paolo Carlini  ---
Done for 4.9.0 then.

[Bug middle-end/58041] Unaligned access to arrays in packed structure

[jamborm at gcc dot gnu.org]

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

--- Comment #19 from Martin Jambor  ---
(In reply to Bill Schmidt from comment #15)
> Bernd, Mikael, Martin:  Could you please test this on your respective
> targets?

Well, "my target" is x86_64 but yes, it works.  

(In reply to Bill Schmidt from comment #11)
> Hi Martin,
> 
> Your assumptions are correct, but I'm not sure this is the best place to
> handle it.  It looks like what you are doing is replacing one already
> correct memory reference with another, both of which will generate somewhat
> nasty code.  Therefore there isn't much reason to do the transformation at
> all in the first place.  I think I would rather analyze the reference when
> considering adding the reference to the candidate table, and leaving it out
> of consideration altogether.  What do you think?

I don't know, at least in theory the optimization might help somewhat
anyway, especially on targets that can handle misalignment memory
accesses.  But you are right that generally misaligned access will be
slow either way.

Anyway, I don't really care, I assume you contributed the code so you
are more qualified to make a judgment and if you prefer one way over
the other, go for it.

I'll leave it to you and won't submit any patch then.  Please make
sure that the two testcases are added to the testsuite before you
close the bug.  The x86_64-linux tetcase from comment #10 is generic
enough that it can go to gcc.dg/torture/, the original ARM one needs
to go to some arm-specific place.

[Bug libstdc++/58049] New: [4.9 Regression] libstdc++ bootstrap failure for fix to PR libstdc++/57779

[dje at gcc dot gnu.org]

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

Bug ID: 58049
   Summary: [4.9 Regression] libstdc++ bootstrap failure for fix
to PR libstdc++/57779
   Product: gcc
   Version: 4.9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: dje at gcc dot gnu.org

In file included from
/tmp/20130801/powerpc-ibm-aix7.1.0.0/libstdc++-v3/include/
debug/safe_sequence.h:34:0,
 from
/nasfarm/edelsohn/src/src/libstdc++-v3/src/c++11/debug.cc:
26:
/tmp/20130801/powerpc-ibm-aix7.1.0.0/libstdc++-v3/include/debug/functions.h: In 
function 'bool __gnu_debug::__foreign_iterator_aux4(const
__gnu_debug::_Safe_ite
rator<_Iterator, _Sequence>&, _InputIterator, _PointerType1, _PointerType2)':
/tmp/20130801/powerpc-ibm-aix7.1.0.0/libstdc++-v3/include/debug/functions.h:189:
6: error: 'addressof' is not a member of 'std'
  __l(std::addressof(*__other),
  ^
/tmp/20130801/powerpc-ibm-aix7.1.0.0/libstdc++-v3/include/debug/functions.h:190:
6: error: 'addressof' is not a member of 'std'
  std::addressof(*(__it._M_get_sequence()->_M_base().begin(
  ^
/tmp/20130801/powerpc-ibm-aix7.1.0.0/libstdc++-v3/include/debug/functions.h:191:
10: error: 'addressof' is not a member of 'std'
  || __ge(std::addressof(*__other),
  ^
/tmp/20130801/powerpc-ibm-aix7.1.0.0/libstdc++-v3/include/debug/functions.h:192:
3: error: 'addressof' is not a member of 'std'
   std::addressof(*(__it._M_get_sequence()->_M_base().end() - 1)) + 1);
   ^
/tmp/20130801/powerpc-ibm-aix7.1.0.0/libstdc++-v3/include/debug/functions.h: In 
function 'bool __gnu_debug::__foreign_iterator_aux3(const
__gnu_debug::_Safe_ite
rator<_Iterator, _Sequence>&, _InputIterator, std::true_type)':
/tmp/20130801/powerpc-ibm-aix7.1.0.0/libstdc++-v3/include/debug/functions.h:208:
6: error: '__addressof' is not a member of 'std'
  if (std::__addressof(*(__it._M_get_sequence()->_M_base().end() - 1))
  ^
/tmp/20130801/powerpc-ibm-aix7.1.0.0/libstdc++-v3/include/debug/functions.h:209:
8: error: '__addressof' is not a member of 'std'
  - std::__addressof(*(__it._M_get_sequence()->_M_base().begin()))
^
/tmp/20130801/powerpc-ibm-aix7.1.0.0/libstdc++-v3/include/debug/functions.h:212:
4: error: 'addressof' is not a member of 'std'
std::addressof(*(__it._M_get_sequence()->_M_base().begin())),
^
/tmp/20130801/powerpc-ibm-aix7.1.0.0/libstdc++-v3/include/debug/functions.h:213:
4: error: 'addressof' is not a member of 'std'
std::addressof(*__other));
^

[Bug libstdc++/58049] [4.9 Regression] libstdc++ bootstrap failure for fix to PR libstdc++/57779

[dje at gcc dot gnu.org]

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

David Edelsohn  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2013-08-02
 CC||fdumont at gcc dot gnu.org,
   ||paolo.carlini at oracle dot 
com,
   ||redi at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #1 from David Edelsohn  ---
Confirmed.

[Bug c++/58050] New: RVO fails when calling static function through unnamed temporary

[scovich at gmail dot com]

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

Bug ID: 58050
   Summary: RVO fails when calling static function through unnamed
temporary
   Product: gcc
   Version: 4.8.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: scovich at gmail dot com

Return value optimization is not applied when calling a static member function
via an unnamed temporary (value or pointer, it doesn't matter). Calling the
function directly, or through a named value/pointer, works as expected:

// <<<--- bug.cpp --->>>
extern "C" int puts(char const*);
struct B {
~B() { puts("\t~B"); }
};
struct A {
static B make() { return B(); }
} a;
A *ap() { return &a; }
int main () {
puts("b1");
{B b = A::make();}
puts("b2");
{B B = a.make();}
puts("b3");
{B b = ap()->make();}
puts("b4");
{B b = A().make();}
}
// <<<--- end bug.cpp --->>>

Output is (same for both 4.8.1 and 4.6.3):
$ g++ bug.cpp && ./a.out
b1
~B
b2
~B
b3
~B
~B
b4
~B
~B

The workaround is simple enough to apply, if you happen to notice all the extra
object copies being made; I isolated the test case from an app that used 5x
more malloc bandwidth than necessary because a single static function called
the wrong way returned a largish STL object by value.

[Bug c++/58051] New: No named return value optimization when returned object is implicitly converted

[scovich at gmail dot com]

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

Bug ID: 58051
   Summary: No named return value optimization when returned
object is implicitly converted
   Product: gcc
   Version: 4.8.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: scovich at gmail dot com

The following test case introduces an extra object copy, even though none
should be required:

// <<<--- bug.cpp --->>>
extern "C" void puts(char const *);
struct A {
A()=default;
A(A &&)=default;
A(A const &) { puts("copy"); }
~A() { puts("~A"); }
};
struct B {
A _a;
B(A a) : _a((A&&)(a)) { }
};
B go() {
A rval;
return rval;
}
int main () { go(); }
// <<<--- end bug.cpp --->>>

(when compiled with both `gcc-4.8.1 -std=gnu++11' and `gcc-4.6.3 -std=gnu++0x')

RVO works properly if go() returns A() or std::move(rval).

[Bug c++/58052] New: Copy initialization using conversion operator does not find correct candidates for initialization of final result

[hstong at ca dot ibm.com]

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

Bug ID: 58052
   Summary: Copy initialization using conversion operator does not
find correct candidates for initialization of final
result
   Product: gcc
   Version: 4.8.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: hstong at ca dot ibm.com

I have a reduced test case.
MSVC seems to work fine (online compiler test: http://rise4fun.com/Vcpp/2sQ).

The copy initialization of an object of type A from a class object of type
C is expected to find C::operator B &() as the function selected by overload
resolution.

The result of the call, an lvalue of type B, is then used to direct-initialize
the object that is the destination of the copy-initialization.
See C++11 subclause 8.5 [dcl.init] paragraph 16.

Note that the result of the call is specified to be used, not the result of the
user-defined conversion sequence which was considered for overload resolution.

The direct initialization from the lvalue of type B has for its candidates all
of the constructors for A (13.3.1.3 [over.match.ctor]).

Note that A(B &) has a standard conversion sequence from the lvalue of type B
to
its sole argument (the identity conversion).

GCC seems to be fixated with the copy constructors for A instead of performing
the overload resolution for the direct initialization.

## Self-contained test case (main.cpp):
struct B;
struct A {
   A();
   A(const A &, bool = 0);
   A(const A &, short = 0);
   A(B &);
};

struct B : A { };

struct C {
   operator B &();
};

int main() {
   C c;
   A a = c;
}

## Compiler invocation:
g++ -std=c++11 -c main.cpp

## Compiler output:
main.cpp: In function 'int main()':
main.cpp:17:10: error: call of overloaded 'A(A)' is ambiguous
A a = c;
  ^
main.cpp:17:10: note: candidates are:
main.cpp:5:4: note: A::A(const A&, short int)
A(const A &, short = 0); 
^   
main.cpp:4:4: note: A::A(const A&, bool)
A(const A &, bool = 0); 
^   

## Expected behaviour:
Clean compile.

## g++ -v:
Using built-in specs.
COLLECT_GCC=g++
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/4.8/lto-wrapper
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Ubuntu
4.8.1-2ubuntu1~12.04' --with-bugurl=file:///usr/share/doc/gcc-4.8/README.Bugs
--enable-languages=c,c++,java,go,d,fortran,objc,obj-c++ --prefix=/usr
--program-suffix=-4.8 --enable-shared --enable-linker-build-id
--libexecdir=/usr/lib --without-included-gettext --enable-threads=posix
--with-gxx-include-dir=/usr/include/c++/4.8 --libdir=/usr/lib --enable-nls
--with-sysroot=/ --enable-clocale=gnu --enable-libstdcxx-debug
--enable-libstdcxx-time=yes --enable-gnu-unique-object --enable-plugin
--with-system-zlib --disable-browser-plugin --enable-java-awt=gtk
--enable-gtk-cairo --with-java-home=/usr/lib/jvm/java-1.5.0-gcj-4.8-amd64/jre
--enable-java-home --with-jvm-root-dir=/usr/lib/jvm/java-1.5.0-gcj-4.8-amd64
--with-jvm-jar-dir=/usr/lib/jvm-exports/java-1.5.0-gcj-4.8-amd64
--with-arch-directory=amd64 --with-ecj-jar=/usr/share/java/eclipse-ecj.jar
--enable-objc-gc --enable-multiarch --disable-werror --with-arch-32=i686
--with-abi=m64 --with-multilib-list=m32,m64 --with-tune=generic
--enable-checking=release --build=x86_64-linux-gnu --host=x86_64-linux-gnu
--target=x86_64-linux-gnu
Thread model: posix
gcc version 4.8.1 (Ubuntu 4.8.1-2ubuntu1~12.04)

[Bug c++/58053] New: Bogus "error ... is private ... within this context"

[ppluzhnikov at google dot com]

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

Bug ID: 58053
   Summary: Bogus "error ... is private ... within this context"
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: ppluzhnikov at google dot com

Test case:

class Foo {
  struct Bar { };
  friend class F;
};

class F
#ifdef BUG
  : public Foo::Bar
#endif
{
  void Fn() { Foo::Bar b; }
};

Using "g++ (GCC) 4.9.0 20130730 (experimental)", the test compiles (clearly
Foo::Bar is accessible to F::Fn()), but fails with -DBUG:

t.cc:2:10: error: ‘struct Foo::Bar’ is private
   struct Bar { };
  ^
t.cc:8:17: error: within this context
   : public Foo::Bar
 ^

[Bug c++/58053] Bogus "error ... is private ... within this context"

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |INVALID

--- Comment #1 from Andrew Pinski  ---
Copied from bug 14281:

[class.friend]/2 in the C++ 1998 
Standard, which says: "Also, because the base-clause of the friend class is not 
part of its member declarations, the base-clause of the friend class cannot 
access the names of the private and protected members from the class granting 
friendship."

So this is invalid code unless this changed for C++11 or C++14.

[Bug fortran/57306] [OOP] [F08] ICE on valid with class pointer initialization

[janus at gcc dot gnu.org]

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

--- Comment #12 from janus at gcc dot gnu.org ---
(In reply to Tobias Burnus from comment #10)
> > Putting this inside a subroutine, one gets:
> > 
> >   class(c), pointer :: px => x
> >   1
> > Error: Pointer initialization target at (1) must have the SAVE attribute
> 
> That sounds like a bug:
> 
> "Explicit initialization of a variable that is not in a common block implies
> the SAVE attribute, which may be confirmed by explicit specification."
> (5.2.3 Initialization, F2008)
> 
> And "px" is clearly initialized

Oh, wait: The error is about the *target*, not the pointer. Therefore I think
it's indeed correct and there is no bug!

[Bug c++/58054] New: 11.3 Friends, example from standard not compiled

[dushistov at mail dot ru]

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

Bug ID: 58054
   Summary: 11.3 Friends, example from standard not compiled
   Product: gcc
   Version: 4.8.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: dushistov at mail dot ru

Here is example from standard (page 250-251),

class A {
  class B { };
  friend class X;
};

struct X : A::B { // OK: A::B accessible to friend
  A::B mx; // OK: A::B accessible to member of friend
  class Y {
A::B my; // OK: A::B accessible to nested member of friend
  };
};


$ g++ -std=c++11 -Wall -c test_friend.cc 
test_friend.cc:2:9: error: 'class A::B' is private
   class B { };
 ^
test_friend.cc:6:15: error: within this context
 struct X : A::B { // OK: A::B accessible to friend
   ^
I suppose that lines marked as OK in C++11 standard should
not emit any errors.

[Bug c++/58054] 11.3 Friends, example from standard not compiled

[pinskia at gcc dot gnu.org]

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

--- Comment #1 from Andrew Pinski  ---
Looks like they changed how base classes are handled in C++ for C++11.
98 says this:
[class.friend]/2 

"Also, because the base-clause of the friend class is not 
part of its member declarations, the base-clause of the friend class cannot 
access the names of the private and protected members from the class granting 
friendship."

Or is this just in a need for a defect report.