[Bug fortran/56806] make: *** [spher_harm.o] Error 1

[pinskia at gcc dot gnu.org]

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



Andrew Pinski  changed:



   What|Removed |Added



Version|unknown |4.1.2



--- Comment #1 from Andrew Pinski  2013-04-02 
07:06:23 UTC ---

Since you are using a CentOS supplied GCC, you should report it there first. 

Also the CentOS/redhat version of GCC you are using is over 4 years old now,

you might want to think about upgrading it as I think this has since been

fixed.

[Bug target/56807] New: mingw32: Conflict between stack realignment and stack probe destroys function argument in EAX

[achurch+gcc at achurch dot org]

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



 Bug #: 56807

   Summary: mingw32: Conflict between stack realignment and stack

probe destroys function argument in EAX

Classification: Unclassified

   Product: gcc

   Version: 4.7.2

Status: UNCONFIRMED

  Severity: normal

  Priority: P3

 Component: target

AssignedTo: unassig...@gcc.gnu.org

ReportedBy: achurch+...@achurch.org





When compiling for mingw32 with an incoming stack boundary less than the

preferred stack boundary, if a non-leaf function with a large (>4000 bytes)

stack size takes arguments in registers, the first argument may be destroyed

depending on the actual stack alignment:



 <_bar>:

   0:   55  push   %ebp

   1:   89 e5   mov%esp,%ebp

   3:   83 e4 f0and$0xfff0,%esp

   6:   50  push   %eax

   7:   b8 1c 10 00 00  mov$0x101c,%eax

   c:   e8 00 00 00 00  call   11 <_bar+0x11>

d: DISP32   ___chkstk_ms

  11:   29 c4   sub%eax,%esp

  13:   8b 45 f4mov-0xc(%ebp),%eax



Note that the stack realignment (at 3) takes place after the frame pointer is

saved (at 1) but before the first argument is pushed to the stack (at 6), so

the offset from the frame pointer to the saved first argument is unknown, yet

GCC tries to reload the argument using the frame pointer as a base (at 13).  If

the stack is not aligned to a multiple of 16 bytes before the function is

called, the reload will get some random value from the stack instead of the

first argument.



Configure options: --prefix=/usr

--bindir=/usr/i686-pc-linux-gnu/mingw32/gcc-bin/4.7.2

--includedir=/usr/lib/gcc/mingw32/4.7.2/include

--datadir=/usr/share/gcc-data/mingw32/4.7.2

--mandir=/usr/share/gcc-data/mingw32/4.7.2/man

--infodir=/usr/share/gcc-data/mingw32/4.7.2/info

--with-gxx-include-dir=/usr/lib/gcc/mingw32/4.7.2/include/g++-v4

--host=i686-pc-linux-gnu --target=mingw32 --build=i686-pc-linux-gnu

--disable-altivec --disable-fixed-point --without-ppl --without-cloog

--enable-lto --disable-nls --with-system-zlib --enable-obsolete

--disable-werror --enable-secureplt --disable-multilib --disable-libmudflap

--disable-libssp --disable-libgomp

--with-python-dir=/share/gcc-data/mingw32/4.7.2/python

--enable-poison-system-directories --enable-checking=release --disable-libgcj

--enable-libstdcxx-time --disable-libquadmath --enable-languages=c,c++

--with-sysroot=/usr/mingw32

[Bug target/56807] mingw32: Conflict between stack realignment and stack probe destroys function argument in EAX

[achurch+gcc at achurch dot org]

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



--- Comment #1 from Andrew Church  2013-04-02 
07:47:41 UTC ---

Created attachment 29773

  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=29773

testcase-1.c



This file contains the bulk of the testcase.  The function foo() has to be

defined in a separate file to trigger the bug.



Compile with: mingw32-gcc -mincoming-stack-boundary=2

-mpreferred-stack-boundary=4 testcase-1.c testcase-2.c -o testcase.exe

[Bug target/56807] mingw32: Conflict between stack realignment and stack probe destroys function argument in EAX

[achurch+gcc at achurch dot org]

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



--- Comment #2 from Andrew Church  2013-04-02 
07:48:35 UTC ---

Created attachment 29774

  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=29774

testcase-2.c



Contains the definition of foo().

[Bug fortran/50269] Wrongly rejects element of assumed-shape array in C_LOC

[burnus at gcc dot gnu.org]

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



Tobias Burnus  changed:



   What|Removed |Added



 Status|RESOLVED|NEW

   Last reconfirmed||2013-04-02

 Resolution|FIXED   |

 Ever Confirmed|0   |1



--- Comment #7 from Tobias Burnus  2013-04-02 
07:52:26 UTC ---

REOPEN



(In reply to comment #5)

> Is this going to be ported back to earlier releases? It's kind of a biggie for

> me...



Probably not - it is a rather large change - and, hence, it might cause

regressions.





(In reply to comment #6)

> Are we sure? When running the code example given in comment #1, I get a

> segfault.



Yes, something seems to be still broken.





> Moreover, the following subroutine won't compile when using the '-std=f2008'

> flag:

>   real, intent(in), contiguous, target :: a(:)

>   b = C_LOC(a)

> 

> The error message is:

> test_contig.f90:9.12:

>   b = C_LOC(a)

> 1

> Error: TS 29113: Noninteroperable array at (1) as argument to C_LOC: Only

> explicit-size and assumed-size arrays are interoperable

> 

> My understanding of the F2008 standard is that assumed-shape arrays with the

> contiguous attribute are interoperable





Well, Fortran 2008 has:



"A Fortran variable that is a named array is interoperable if and only if its

type and type parameters are interoperable, it is not a coarray, it is of

explicit shape or assumed size, and if it is of type character its length is

not

^^

assumed or declared by an expression that is not a constant expression."

("15.3.6 Interoperability of array variables")





Thus, it is definitely not interoperable. But the real question is whether it

is permitted for C_LOC. From "15.2.3.6 C_LOC(X)":



"Argument. X shall have either the POINTER or TARGET attribute. It shall not be

a coindexed object. It shall either be a variable with interoperable type and

kind type parameters, or be a scalar, nonpolymorphic variable with no length

type parameters. If it is allocatable, it shall be allocated. If it is a

pointer, it shall be associated. If it is an array, it shall be contiguous and

have nonzero size. It shall not be a zero-length string."







I think the crucial part is: "with interoperable type and kind type parameter"

- which is different to the other intrinsics, which require "an interoperable

data entity". Thus, it seems to be permitted in C_LOC.





Thanks for testing.

[Bug target/56807] mingw32: Conflict between stack realignment and stack probe destroys function argument in EAX

[achurch+gcc at achurch dot org]

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



--- Comment #3 from Andrew Church  2013-04-02 
07:53:08 UTC ---

The __chkstk_ms call comes from allocate_stack_worker_probe_ in i386.md,

which is used in allocate_stack if the CHECK_STACK_LIMIT symbol is defined to a

nonzero value.  CHECK_STACK_LIMIT defaults to zero, but it's set to 4000 for

mingw32.

[Bug tree-optimization/54200] copyrename generates wrong debuginfo

[rguenther at suse dot de]

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



--- Comment #13 from rguenther at suse dot de  
2013-04-02 07:56:26 UTC ---

On Fri, 29 Mar 2013, jakub at gcc dot gnu.org wrote:



> 

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

> 

> Jakub Jelinek  changed:

> 

>What|Removed |Added

> 

>  CC||jakub at gcc dot gnu.org

> 

> --- Comment #12 from Jakub Jelinek  2013-03-29 
> 15:36:15 UTC ---

> This patch regressed code quality on find_vma function in Linux kernel on

> s390x:

> struct rb_node

> {

>   unsigned long __rb_parent_color;

>   struct rb_node *rb_right;

>   struct rb_node *rb_left;

> } __attribute__ ((aligned (sizeof (long;

> struct rb_root {

>   struct rb_node *rb_node;

> };

> struct vm_area_struct

> {

>   unsigned long vm_start;

>   unsigned long vm_end;

>   struct vm_area_struct *vm_next, *vm_prev;

>   struct rb_node vm_rb;

> };

> struct mm_struct

> {

>   struct vm_area_struct *mmap;

>   struct rb_root mm_rb;

>   struct vm_area_struct *mmap_cache;

> };

> struct vm_area_struct *

> find_vma (struct mm_struct *mm, unsigned long addr)

> {

>   struct vm_area_struct *vma = ((void *) 0);

>   static _Bool __attribute__ ((__section__ (".data.unlikely"))) __warned;

>   int __ret_warn_once = !!(!mm);

>   if (__builtin_expect (!!(__ret_warn_once), 0))

> {

>   int __ret_warn_on = !!(!__warned);

>   if (__builtin_expect (!!(__ret_warn_on), 0))

> asm volatile ("": :"i" (1920), "i" (((1 << 0) | ((9) << 8))), "i" (64));

>   if (__builtin_expect (!!(__ret_warn_on), 0))

> __warned = 1;

> }

>   if (__builtin_expect (!!(__ret_warn_once), 0))

> return ((void *) 0);

>   vma = mm->mmap_cache;

>   if (!(vma && vma->vm_end > addr && vma->vm_start <= addr))

> {

>   struct rb_node *rb_node;

>   rb_node = mm->mm_rb.rb_node;

>   vma = ((void *) 0);

>   while (rb_node)

> {

>   struct vm_area_struct *vma_tmp;

>   const typeof (((struct vm_area_struct *)0)->vm_rb) *__mptr = rb_node;

>   vma_tmp = (struct vm_area_struct *) ((char *) __mptr - 
> __builtin_offsetof

> (struct vm_area_struct, vm_rb));

>   if (vma_tmp->vm_end > addr)

> {

>   vma = vma_tmp;

>   if (vma_tmp->vm_start <= addr)

> break;

>   rb_node = rb_node->rb_left;

> }

>   else

> rb_node = rb_node->rb_right;

> }

>   if (vma)

> mm->mmap_cache = vma;

> }

>   return vma;

> }

> 

> with:

> -fno-strict-aliasing -fno-common -fno-delete-null-pointer-checks -O2 -m64

> -mbackchain -msoft-float -march=z9-109 -mpacked-stack -mstack-size=16384

> -fno-strength-reduce -fno-stack-protector -fomit-frame-pointer

> -fno-inline-functions-called-once -fconserve-stack

> 

> The difference in *.optimized is just:

> -  # vma_5 = PHI <0B(18), vma_2(15), vma_20(6), vma_2(16), 0B(7)>

> -  return vma_5;

> +  # _5 = PHI <0B(18), vma_2(15), vma_20(6), vma_2(16), 0B(7)>

> +  return _5;

> but later on CSE2 decides to use REG_EQUAL somewhere for some reason, and we

> end up reading mm->mmap_cache twice, first into a register to do the

> comparisons of it, and then when we know it is the value we actually want to

> return, we just forget we have it in a pseudo and read it again from memory.



Surely not a bug with the patch but a bug in CSE.  What the patch can

change is how pseudos are coalesced.  A "fix" may be in the coalescing

code, not restrict coalescing to SSA names with the same underlying

decl (with the cost issue of a bigger conflict map).

[Bug fortran/56808] New: Coarray: Wrongly accepts coindexed arguments to INTENT(OUT) dummies

[burnus at gcc dot gnu.org]

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



 Bug #: 56808

   Summary: Coarray: Wrongly accepts coindexed arguments to

INTENT(OUT) dummies

Classification: Unclassified

   Product: gcc

   Version: 4.9.0

Status: UNCONFIRMED

  Keywords: accepts-invalid

  Severity: normal

  Priority: P3

 Component: fortran

AssignedTo: unassig...@gcc.gnu.org

ReportedBy: bur...@gcc.gnu.org





Found at

https://groups.google.com/forum/?fromgroups=#!topic/comp.lang.fortran/-oUZRIdRCcg





For obvious reasons, the following is invalid, but it is accepted:



"If the actual argument is a coindexed object with an allocatable ultimate

component, the dummy argument shall have the INTENT (IN) or the VALUE

attribute." (12.5.2.4 Ordinary dummy variables)



 real(kind=4),allocatable :: grt(:,:,:)[:,:,:]

 call cgca_rt(grt(i,:,:)[1,1,1])

contains

 subroutine cgca_rt(r)

 real(kind=4),intent(out) :: r(3,3)

end

end

[Bug c/56809] New: Revision 197266 causes trunk ICE for arm-none-eabi targets

[terry.guo at arm dot com]

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



 Bug #: 56809

   Summary: Revision 197266 causes trunk ICE for arm-none-eabi

targets

Classification: Unclassified

   Product: gcc

   Version: 4.9.0

Status: UNCONFIRMED

  Severity: critical

  Priority: P3

 Component: c

AssignedTo: unassig...@gcc.gnu.org

ReportedBy: terry@arm.com





After build a tool chain from trunk@r197266 for arm-none-eabi, then use it to

compile a simple case with switch statement, I got below ICE:



terguo01@terry-pc01:bad$ ../../install-native/bin/arm-none-eabi-gcc -O2 -S

test.c 

test.c: In function 'foo':

test.c:29:1: internal compiler error: in thumb2_output_casesi, at

config/arm/arm.c:25830

 }

 ^

0x87f9da3 thumb2_output_casesi(rtx_def**)

/work/terguo01/build-toolchain/latest/src/gcc/gcc/config/arm/arm.c:25830

0x83265d6 final_scan_insn(rtx_def*, _IO_FILE*, int, int, int*)

/work/terguo01/build-toolchain/latest/src/gcc/gcc/final.c:2854

0x83271c5 final(rtx_def*, _IO_FILE*, int)

/work/terguo01/build-toolchain/latest/src/gcc/gcc/final.c:1958

0x832740a rest_of_handle_final

/work/terguo01/build-toolchain/latest/src/gcc/gcc/final.c:4333

Please submit a full bug report,

with preprocessed source if appropriate.

Please include the complete backtrace with any bug report.

See  for instructions.



It seems r197266 made some changes to jump table which then causes such error.



Here are the full configure options of my GCC:



terguo01@terry-pc01:bad$ ../../install-native/bin/arm-none-eabi-gcc -v

Using built-in specs.

COLLECT_GCC=../../install-native/bin/arm-none-eabi-gcc

COLLECT_LTO_WRAPPER=/work/terguo01/build-toolchain/latest/install-native/lib/gcc/arm-none-eabi/4.9.0/lto-wrapper

Target: arm-none-eabi

Configured with: /work/terguo01/build-toolchain/latest/src/gcc/configure

--target=arm-none-eabi

--prefix=/work/terguo01/build-toolchain/latest/install-native

--libexecdir=/work/terguo01/build-toolchain/latest/install-native/lib

--infodir=/work/terguo01/build-toolchain/latest/install-native/share/doc/gcc-arm-none-eabi/info

--mandir=/work/terguo01/build-toolchain/latest/install-native/share/doc/gcc-arm-none-eabi/man

--htmldir=/work/terguo01/build-toolchain/latest/install-native/share/doc/gcc-arm-none-eabi/html

--pdfdir=/work/terguo01/build-toolchain/latest/install-native/share/doc/gcc-arm-none-eabi/pdf

--enable-languages=c --disable-decimal-float --disable-libffi --disable-libgomp

--disable-libmudflap --disable-libquadmath --disable-libssp

--disable-libstdcxx-pch --disable-nls --disable-shared --disable-threads

--disable-tls --with-newlib --without-headers --with-gnu-as --with-gnu-ld

--with-python-dir=share/gcc-arm-none-eabi

--with-sysroot=/work/terguo01/build-toolchain/latest/install-native/arm-none-eabi

--with-host-libstdcxx='-static-libgcc -Wl,-Bstatic,-lstdc++,-Bdynamic -lm'

--with-pkgversion='GNU Tools for ARM Embedded Processors' --disable-multilib

--with-mode=thumb --with-cpu=cortex-m4

Thread model: single

gcc version 4.9.0 20130330 (experimental) (GNU Tools for ARM Embedded

Processors) 



Among them, the important ones are "--target=arm-none-eabi --disable-multilib

--with-mode=thumb --with-cpu=cortex-m4".



Here is my test case:

terguo01@terry-pc01:bad$ cat test.c 



int

foo (int mode, int i)

{

  int x;



  switch (mode)

{

case 0:

  x = i + 1;

  break;

case 1:

  x = i / 2;

  break;

case 2:

  x = i * 3;

  break;

case 3:

  x = i + 3;

  break;

case 4:

  x = i + 5;

  break;

default:

  x = i - 1;

}



  return x;

}

[Bug c++/22488] C++ frontend generates RECORD_TYPEs with overlapping FIELD_DECLs

[rguenth at gcc dot gnu.org]

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



Richard Biener  changed:



   What|Removed |Added



   Target Milestone|4.6.4   |---

Summary|[4.6/4.7/4.8/4.9|C++ frontend generates

   |Regression] |RECORD_TYPEs with

   |push_fields_onto_fieldstack |overlapping FIELD_DECLs

   |calculates offset   |

   |incorrectly |



--- Comment #57 from Richard Biener  2013-04-02 
08:04:05 UTC ---

Re-confirmed and summary adjusted.  The code in tree-ssa-structalias.c is

still there:



  /* We can't sort them if we have a field with a variable sized type,

 which will make notokay = true.  In that case, we are going to return

 without creating varinfos for the fields anyway, so sorting them is a

 waste to boot.  */

  if (!notokay)

{

  sort_fieldstack (fieldstack);

  /* Due to some C++ FE issues, like PR 22488, we might end up

 what appear to be overlapping fields even though they,

 in reality, do not overlap.  Until the C++ FE is fixed,

 we will simply disable field-sensitivity for these cases.  */

  notokay = check_for_overlaps (fieldstack);



I am not aware of other code in the middle-end that might be confused

about this issue (well, SRA maybe, but it handles overlaps well as it

also handles accesses to unions).



I believe that the C++ frontend issue might not be a regression after all,

the tree-ssa-structalias.c "regression" was fixed by the above kludge.



The C++ frontend issue makes it impossible to implement a GENERIC verifier

for RECORD_TYPEs (verify FIELD_DECLs are sorted after offset and not

overlapping).

[Bug fortran/56808] Coarray: Wrongly accepts coindexed arguments to INTENT(OUT) dummies

[burnus at gcc dot gnu.org]

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



Tobias Burnus  changed:



   What|Removed |Added



 CC||burnus at gcc dot gnu.org



--- Comment #1 from Tobias Burnus  2013-04-02 
08:06:54 UTC ---

Actually, that example is probably okay. Steven Lionel wrote:



"But reading this I wonder if it's intended to mean actual arguments of derived

type with allocatable components, rather than a regular allocatable array,

since there's no issue of making copies of subcomponents here. Let me discuss

it with my

team here."





However, the following code should be invalid (due to the implicit deallocating

the allocatable component *on the remote image*):



type t

  integer, allocatable :: x

end type t

class(t), allocatable :: x[:]

 call bar(x[1]) ! <<< Wrongly accepted.

! call foo(x[1]) ! OK: Rejected coindexed polymorphic -> polymorphic not

allowed

contains

 subroutine bar(r)

   type(t) :: r

 end

 subroutine foo(r)

   class(t) :: r

 end

end

[Bug rtl-optimization/56766] Fails to combine (vec_select (vec_concat ...)) to (vec_merge ...)

[rguenth at gcc dot gnu.org]

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



--- Comment #1 from Richard Biener  2013-04-02 
08:08:34 UTC ---

Btw, vec_merge is a special-case of a non-existing vec_shuffle2.

vec_merge (and a vec_suffle2) as opposed to a vec_select (vec_concat (...))

combination has the advantage that we don't need intermediate vector

modes of double size.



So in the long run it might be most profitable to remove vec_merge

and instead introduce vec_shuffle to catch almost all vec_select (vec_concat

())

cases.

[Bug c/56809] Revision 197266 causes trunk ICE for arm-none-eabi targets

[terry.guo at arm dot com]

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



--- Comment #1 from Terry Guo  2013-04-02 08:12:32 
UTC ---

The latest trunk code still has this issue.

[Bug middle-end/52436] BIT_FIELD_REF > should be canonicalized for non-bitfield accesses

[rguenth at gcc dot gnu.org]

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



--- Comment #3 from Richard Biener  2013-04-02 
08:27:51 UTC ---

The patch looks fine to me, though it might be a bit expensive.  I'd

re-organize it like



  if (TREE_INT_CST_LOW (arg1) % BITS_PER_UNIT == 0

  && TREE_INT_CST_LOW (arg2) % BITS_PER_UNIT == 0)

{

  HOST_WIDE_INT coffset;

  tree base = get_addr_base_and_unit_offset (arg0, &coffset);

  if (base)

return fold_build2 (MEM_REF, type,

build_fold_addr_expr (base),

build_int_cst (build_pointer_type

(TYPE_MAIN_VARIANT (type)), coffset + TREE_INT_CST_LOW (arg1) /

BITS_PER_UNIT));

}



it avoids building a tree just to feed it into get_addr_base_and_unit_offset

It also avoids it if the access is not of byte-granularity which

get_addr_base_and_unit_offset does not even consider (it assumes it is fed

the argument of an ADDR_EXPR which obviously is byte-aligned).



The tree-flow-inline.h bits look ok.



I'm not sure what you need the forwprop / tree-ssa-propagate changes for.

[Bug c/51628] __attribute__((packed)) is unsafe in some cases

[rguenth at gcc dot gnu.org]

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



--- Comment #16 from Richard Biener  2013-04-02 
08:30:16 UTC ---

(In reply to comment #14)

> > What Ada does looks just like a workaround for what should be done properly 
> > in

> > the expander.  So no, IMHO we shouldn't be changing all other FEs and the

> > middle-end (when it wants to generate them e.g. for memcpy) to do what Ada

> > does, but we should change the expander.

> 

> Of course I have the exactly opposite viewpoint, since I think that we should

> keep the invariants we have: integral modes are naturally aligned and

> TYPE_ALIGN >= MODE_ALIGN (TYPE_MODE).  Breaking them for a few pathological

> cases that the C compiler has shun for years doesn't seem the best course of

> action.



Well.  I'm fine with forcing BLKmode for unaligned accesses, but not sure

if that is less invasive.  You'd basically have to change modes whenever

more precise knowledge about alignment appears ...

[Bug c/51628] __attribute__((packed)) is unsafe in some cases

[rguenth at gcc dot gnu.org]

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



--- Comment #17 from Richard Biener  2013-04-02 
08:30:54 UTC ---

(In reply to comment #15)

> I believe the discussion here is missing the point. Currently (at least with

> version 4.5 and ARM, which I am currently using) the situation is that the

> compiler generates broken code WITHOUT COMMENT when the address of something

> like an integer in a packed structure is assigned to a int* . Since the 
> pointer

> type does not provide any information about the actual alignment of the

> integer, it is obviously impractical to fix when accessing the integer and we

> certainly do not want to have extra code inserted for handling the possibility

> that the int may not be aligned correctly. Therefore the compiler MUST see 
> this

> as a type conflict and at least warn that the address of the member in a 
> packed

> struct is incompatible with the pointer type.

> 

> I have several projects which require the use of packed structures and I 
> simply

> cannot rule out that that I have not at some point accidentally assigned the

> address of a member variable to a pointer. It would therefore be very handy if

> the compiler could point this out. -Wcast-align certainly doesn't do this.



Because there is no cast involved.  And that's because the types of the fields

are "wrong" as well.

[Bug other/28315] gcc doesn't use locale for default input charset

[bonzini at gnu dot org]

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



Paolo Bonzini  changed:



   What|Removed |Added



 Status|UNCONFIRMED |RESOLVED

 Resolution||WONTFIX



--- Comment #2 from Paolo Bonzini  2013-04-02 08:47:26 
UTC ---

It took me a while to reconstruct what that patch did, and I couldn't find

quickly the discussion about the hunk between me and Zack.



What I did find out was that GCC's configure at the time lacked

AM_LANGINFO_CODESET:



http://gcc.gnu.org/git/?p=gcc.git;a=blob;f=gcc/configure.ac;h=45e5da59b7568804ce3a09551525acb3f43d9689;hb=d856c8a6



Hence that hunk was actually a no-op.



I agree with Laszlo's analysis, and I am closing this as WONTFIX.

[Bug c++/56768] [4.7] ICE in make_decl_rtl, at varasm.c:1147

[rguenth at gcc dot gnu.org]

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



Richard Biener  changed:



   What|Removed |Added



 Status|UNCONFIRMED |NEW

   Last reconfirmed||2013-04-02

  Known to work||4.8.0

Version|unknown |4.7.3

 Ever Confirmed|0   |1

  Known to fail||4.7.2



--- Comment #1 from Richard Biener  2013-04-02 
08:57:27 UTC ---

Confirmed.  4.6 does not accept the testcase.



../../gcc47-g/gcc/cc1plus  -quiet t.ii -std=c++0x -O2

t.ii: In constructor 'M::M(const Container&)':

t.ii:36:1: error: PHI argument is not SSA_NAME, or invariant

PHI argument

retvalptr.4

for PHI node

b_10 = PHI 

t.ii:36:1: internal compiler error: verify_ssa failed

Please submit a full bug report,

with preprocessed source if appropriate.

See  for instructions.



this is inline transform going wrong.



Bisecting what fixed this would be nice.

[Bug c++/56768] [4.7] ICE in make_decl_rtl, at varasm.c:1147

[rguenth at gcc dot gnu.org]

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



--- Comment #2 from Richard Biener  2013-04-02 
08:58:24 UTC ---

*** Bug 56769 has been marked as a duplicate of this bug. ***

[Bug c++/56769] [4.7] ICE in set_ssa_val_to, at tree-ssa-sccvn.c:2511

[rguenth at gcc dot gnu.org]

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



Richard Biener  changed:



   What|Removed |Added



 Status|UNCONFIRMED |RESOLVED

 Resolution||DUPLICATE



--- Comment #1 from Richard Biener  2013-04-02 
08:58:24 UTC ---

Yes, duplicate.



../../gcc47-g/gcc/cc1plus  -quiet t.ii -std=c++0x -O2

t.ii: In constructor 'M::M(const Container&)':

t.ii:36:1: error: PHI argument is not SSA_NAME, or invariant

PHI argument

retvalptr.7

for PHI node

b_10 = PHI 

t.ii:36:1: internal compiler error: verify_ssa failed

Please submit a full bug report,

with preprocessed source if appropriate.

See  for instructions.



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

[Bug gcov-profile/56773] Programs crash if compiled with --coverage, although they run correctly without --coverage

[rguenth at gcc dot gnu.org]

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



Richard Biener  changed:



   What|Removed |Added



 Status|UNCONFIRMED |RESOLVED

 Resolution||INVALID



--- Comment #3 from Richard Biener  2013-04-02 
08:59:32 UTC ---

The code is indeed not valid.  Also happens with 4.6 for me, btw.

[Bug lto/56775] -flto and -fprofile-generate together result in a link-time internal compiler error (in "add_symbol_to_partition")

[rguenth at gcc dot gnu.org]

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



Richard Biener  changed:



   What|Removed |Added



 Status|UNCONFIRMED |WAITING

   Last reconfirmed||2013-04-02

Version|unknown |4.8.0

 Ever Confirmed|0   |1



--- Comment #1 from Richard Biener  2013-04-02 
09:00:51 UTC ---

We need a testcase.

[Bug tree-optimization/56778] ICE on several benchmarks after r196775.

[rguenth at gcc dot gnu.org]

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



Richard Biener  changed:



   What|Removed |Added



 Status|UNCONFIRMED |ASSIGNED

   Last reconfirmed||2013-04-02

 AssignedTo|unassigned at gcc dot   |rguenth at gcc dot gnu.org

   |gnu.org |

 Ever Confirmed|0   |1



--- Comment #1 from Richard Biener  2013-04-02 
09:04:15 UTC ---

Confirmed.  I will have a look (there is a not properly removed stmt with

still has active immediate uses).

[Bug tree-optimization/56778] [4.9 Regression] ICE on several benchmarks after r196775.

[rguenth at gcc dot gnu.org]

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



Richard Biener  changed:



   What|Removed |Added



   Target Milestone|--- |4.9.0

Summary|ICE on several benchmarks   |[4.9 Regression] ICE on

   |after r196775.  |several benchmarks after

   ||r196775.

[Bug libstdc++/56779] [4.8/4.9 Regression] libstdc++.so: undefined reference to `libintl_textdomain'

[rguenth at gcc dot gnu.org]

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



Richard Biener  changed:



   What|Removed |Added



 CC||dnovillo at gcc dot gnu.org

   Target Milestone|--- |4.8.1

Summary|libstdc++.so: undefined |[4.8/4.9 Regression]

   |reference to|libstdc++.so: undefined

   |`libintl_textdomain'|reference to

   ||`libintl_textdomain'



--- Comment #1 from Richard Biener  2013-04-02 
09:05:57 UTC ---

Diego, this may be due to your patch as well.

[Bug libfortran/56786] [4.6/4.7/4.8/4.9 Regression] Namelist read fails with designators containing embedded spaces

[rguenth at gcc dot gnu.org]

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



Richard Biener  changed:



   What|Removed |Added



   Priority|P3  |P4

[Bug tree-optimization/56790] VEC_COND_EXPR not constant folded

[rguenth at gcc dot gnu.org]

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



Richard Biener  changed:



   What|Removed |Added



 Status|UNCONFIRMED |NEW

   Last reconfirmed||2013-04-02

 Ever Confirmed|0   |1



--- Comment #1 from Richard Biener  2013-04-02 
09:10:14 UTC ---

Confirmed.

[Bug middle-end/56791] [4.8/4.9 Regression] Segmentation fault in stage2 gengenrtl -- Incorrect instruction sequence generated by reload

[rguenth at gcc dot gnu.org]

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



Richard Biener  changed:



   What|Removed |Added



   Keywords||build, wrong-code

   Target Milestone|--- |4.8.1

Summary|Segmentation fault in   |[4.8/4.9 Regression]

   |stage2 gengenrtl -- |Segmentation fault in

   |Incorrect instruction   |stage2 gengenrtl --

   |sequence generated by   |Incorrect instruction

   |reload  |sequence generated by

   ||reload

[Bug plugins/56795] gimple_seq_alloc and gimple_seq_free are still present in gcc-4.8's gimple.h

[rguenth at gcc dot gnu.org]

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



Richard Biener  changed:



   What|Removed |Added



 Status|UNCONFIRMED |NEW

   Last reconfirmed||2013-04-02

 CC||matz at gcc dot gnu.org

 Ever Confirmed|0   |1



--- Comment #1 from Richard Biener  2013-04-02 
09:11:48 UTC ---

Confirmed.

[Bug lto/56804] lto1: internal compiler error: bytecode stream: found non-null terminated string

[rguenth at gcc dot gnu.org]

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



Richard Biener  changed:



   What|Removed |Added



 Target||x86_64-w64-mingw32

 Status|UNCONFIRMED |WAITING

   Last reconfirmed||2013-04-02

 Ever Confirmed|0   |1



--- Comment #3 from Richard Biener  2013-04-02 
09:15:19 UTC ---

You need to re-build all LTO objects after the change.  Please make sure

that happened.

[Bug middle-end/56809] [4.9 Regression] Revision 197266 causes trunk ICE for arm-none-eabi targets

[rguenth at gcc dot gnu.org]

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



Richard Biener  changed:



   What|Removed |Added



  Component|c   |middle-end

   Target Milestone|--- |4.9.0

Summary|Revision 197266 causes  |[4.9 Regression] Revision

   |trunk ICE for arm-none-eabi |197266 causes trunk ICE for

   |targets |arm-none-eabi targets

[Bug middle-end/56809] [4.9 Regression] Revision 197266 causes trunk ICE for arm-none-eabi targets

[ktkachov at gcc dot gnu.org]

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



--- Comment #2 from ktkachov at gcc dot gnu.org 2013-04-02 09:43:57 UTC ---

Similar problem on aarch64-none-elf. The testcase produces this ICE with

aarch64-none-elf-gcc ice.c -S





ice.c:28:1: internal compiler error: in aarch64_output_casesi, at

config/aarch64/aarch64.c:4098

 }

 ^

0xb171fe aarch64_output_casesi(rtx_def**)

$SOURCE/gcc/gcc/config/aarch64/aarch64.c:4098

0x6b9579 final_scan_insn(rtx_def*, _IO_FILE*, int, int, int*)

$SOURCE/gcc/gcc/final.c:2854

0x6b9faf final(rtx_def*, _IO_FILE*, int)

$SOURCE/gcc/gcc/final.c:1958

0x6ba1d9 rest_of_handle_final

$SOURCE/gcc/gcc/final.c:4333

Please submit a full bug report,

with preprocessed source if appropriate.

Please include the complete backtrace with any bug report.

See  for instructions.

[Bug lto/56804] lto1: internal compiler error: bytecode stream: found non-null terminated string

[vchou79 at gmail dot com]

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



--- Comment #4 from Vincent  2013-04-02 09:45:29 UTC 
---

After rebuild all LTO objects the same happened.

[Bug c++/56768] [4.7] ICE in make_decl_rtl, at varasm.c:1147

[jakub at gcc dot gnu.org]

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



Jakub Jelinek  changed:



   What|Removed |Added



 CC||jakub at gcc dot gnu.org



--- Comment #3 from Jakub Jelinek  2013-04-02 
10:11:25 UTC ---

http://gcc.gnu.org/r187593 fixed this on the trunk.

[Bug libfortran/56810] New: record-repeat fails kind check on complex read

[jonathan.hogg at stfc dot ac.uk]

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



 Bug #: 56810

   Summary: record-repeat fails kind check on complex read

Classification: Unclassified

   Product: gcc

   Version: unknown

Status: UNCONFIRMED

  Severity: normal

  Priority: P3

 Component: libfortran

AssignedTo: unassig...@gcc.gnu.org

ReportedBy: jonathan.h...@stfc.ac.uk





The following code:

program test

   implicit none



   integer :: i

   complex :: a(4)



   read(*,*) a(:)

end program test



Fails at runtime with the following line of input:

4*(0.0,0.0)



It is fine with:

(0.0,0.0) (0.0,0.0) (0.0,0.0) (0.0,0.0)



Error message is:

$ gfortran -g -o bug bug.f90 && ./bug < bugdata 

At line 6 of file bug.f90 (unit = 5, file = 'stdin')

Fortran runtime error: Read kind 8 COMPLEX where kind 4 is required for item 2



Version:

$ gfortran -v

Using built-in specs.

COLLECT_GCC=gfortran

COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/4.7/lto-wrapper

Target: x86_64-linux-gnu

Configured with: ../src/configure -v --with-pkgversion='Ubuntu/Linaro

4.7.2-4ubuntu1' --with-bugurl=file:///usr/share/doc/gcc-4.7/README.Bugs

--enable-languages=c,c++,go,fortran,objc,obj-c++ --prefix=/usr

--program-suffix=-4.7 --enable-shared --enable-linker-build-id

--with-system-zlib --libexecdir=/usr/lib --without-included-gettext

--enable-threads=posix --with-gxx-include-dir=/usr/include/c++/4.7

--libdir=/usr/lib --enable-nls --with-sysroot=/ --enable-clocale=gnu

--enable-libstdcxx-debug --enable-libstdcxx-time=yes --enable-gnu-unique-object

--enable-plugin --enable-objc-gc --disable-werror --with-arch-32=i686

--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.7.2 (Ubuntu/Linaro 4.7.2-4ubuntu1)



Regards,



Jonathan.

[Bug c++/56768] [4.7] ICE in make_decl_rtl, at varasm.c:1147

[rguenth at gcc dot gnu.org]

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



Richard Biener  changed:



   What|Removed |Added



 Status|NEW |ASSIGNED

 AssignedTo|unassigned at gcc dot   |rguenth at gcc dot gnu.org

   |gnu.org |



--- Comment #4 from Richard Biener  2013-04-02 
10:40:26 UTC ---

I have a patch to backport.

[Bug target/56771] Integer Overflow? Building arm-rtems libgcc2

[chris at contemporary dot net.au]

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



--- Comment #6 from Chris Johns  2013-04-02 
11:04:29 UTC ---

It looks to me like libcpp/configure.ac is not setting 'need_64bit_hwint' to

'yes'. It looks like the RTEMS ptch to change arm-rtems*eabi to arm-rtems*

needs to have this added.

[Bug middle-end/56809] [4.9 Regression] Revision 197266 causes trunk ICE for arm-none-eabi targets

[ktkachov at gcc dot gnu.org]

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



ktkachov at gcc dot gnu.org changed:



   What|Removed |Added



 Target|arm-none-eabi,  |arm-none-eabi,

   |aarch64-none-elf|aarch64-none-elf,

   ||arm-none-linux-gnueabihf,

   ||arm-none-linux-gnueabi



--- Comment #3 from ktkachov at gcc dot gnu.org 2013-04-02 11:05:00 UTC ---

Also, r197266 causes arm-none-linux-gnueabi targets to fail building glibc

with:



/tmp/ccJoCcvx.s: Assembler messages:

/tmp/ccJoCcvx.s:79: Error: bad immediate value for offset (4228)

make[2]: *** [$SOURCE/build-linux/obj/glibc/stdio-common/vfwscanf.o] Error 1

make[2]: *** Waiting for unfinished jobs

/tmp/ccRTqSyv.s: Assembler messages:

/tmp/ccRTqSyv.s:47: Error: bad immediate value for offset (4556)

make[2]: *** [$SOURCE/build-linux/obj/glibc/stdio-common/vfscanf.o] Error 1

/tmp/ccxxOo62.s: Assembler messages:

/tmp/ccxxOo62.s:72: Error: bad immediate value for offset (4244)

/tmp/ccxxOo62.s:88: Error: bad immediate value for offset (4208)

/tmp/ccxxOo62.s:95: Error: bad immediate value for offset (4196)

/tmp/ccxxOo62.s:127: Error: bad immediate value for offset (4228)

make[2]: *** [$SOURCE/build-linux/obj/glibc/stdio-common/vfwscanf.os] Error 1

/tmp/ccuTrEWO.s: Assembler messages:

/tmp/ccuTrEWO.s:57: Error: bad immediate value for offset (4136)

/tmp/ccuTrEWO.s:79: Error: bad immediate value for offset (4104)

make[2]: *** [$SOURCE/build-linux/obj/glibc/stdio-common/vfscanf.os] Error 1

make[2]: Leaving directory `$SOURCE/glibc/libc/stdio-common'

make[1]: *** [stdio-common/subdir_lib] Error 2

make[1]: Leaving directory `$SOURCE/glibc/libc'

make: *** [all] Error 2

make: Leaving directory `$SOURCE/build-linux/obj/glibc

[Bug c/56811] New: gcc build fails: Unsatisfied symbol "_Unwind_GetIPInfo"

[mrcs.gcc at mailnull dot com]

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



 Bug #: 56811

   Summary: gcc build fails: Unsatisfied symbol

"_Unwind_GetIPInfo"

Classification: Unclassified

   Product: gcc

   Version: 4.8.0

Status: UNCONFIRMED

  Severity: blocker

  Priority: P3

 Component: c

AssignedTo: unassig...@gcc.gnu.org

ReportedBy: mrcs@mailnull.com





Building gcc 4.8.0 on HP-UX 11.23 IA64 fails.



The c compiler used for building the gcc 4.8.0 is gcc 4.5.2.

The last lines of output from make are:



g++  -DUSE_LIBUNWIND_EXCEPTIONS  -g -DIN_GCC   -fno-exceptions -fno-rtti

-fasynchronous-unwind-tables -W -Wall -Wwrite-strings -Wcast-qual

-Wmissing-format-attribute -pedantic -Wno-long-long -Wno-variadic-macros

-Wno-overlength-strings -fno-common  -DHAVE_CONFIG_H -static-libstdc++

-static-libgcc -L/home/hendrik/gccgo1-HP-UX-B.11.23-ia64/lib

-L/home/hendrik/gccgo1-HP-UX-B.11.23-ia64/lib/hpux32 -o cc1 c/c-lang.o

c-family/stub-objc.o attribs.o c/c-errors.o c/c-decl.o c/c-typeck.o

c/c-convert.o c/c-aux-info.o c/c-objc-common.o c/c-parser.o c-family/c-common.o

c-family/c-cppbuiltin.o c-family/c-dump.o c-family/c-format.o

c-family/c-gimplify.o c-family/c-lex.o c-family/c-omp.o c-family/c-opts.o

c-family/c-pch.o c-family/c-ppoutput.o c-family/c-pragma.o

c-family/c-pretty-print.o c-family/c-semantics.o c-family/c-ada-spec.o

tree-mudflap.o ia64-c.o default-c.o \

  cc1-checksum.o libbackend.a main.o tree-browser.o libcommon-target.a

libcommon.a ../libcpp/libcpp.a ../libdecnumber/libdecnumber.a libcommon.a

../libcpp/libcpp.a ./../intl/libintl.a  ../libbacktrace/.libs/libbacktrace.a

../libiberty/libiberty.a ../libdecnumber/libdecnumber.a  

-L/home/hendrik/gccgo1-HP-UX-B.11.23-ia64/lib

-L/home/hendrik/gccgo1-HP-UX-B.11.23-ia64/lib

-L/home/hendrik/gccgo1-HP-UX-B.11.23-ia64/lib -lmpc -lmpfr -lgmp   -L../zlib

-lz

ld: Unsatisfied symbol "_Unwind_GetIPInfo" in file

../libbacktrace/.libs/libbacktrace.a[backtrace.o]

1 errors.

collect2: ld returned 1 exit status

make[3]: *** [cc1] Error 1

make[3]: Leaving directory

`/svnstore/unix/hendrik/git/gccgo/gccgo-build/build.HP-UX-B.11.23-ia64/gcc-4.8.0/host-ia64-hp-hpux11.23/gcc'

make[2]: *** [all-stage1-gcc] Error 2

make[2]: Leaving directory

`/svnstore/unix/hendrik/git/gccgo/gccgo-build/build.HP-UX-B.11.23-ia64/gcc-4.8.0'

make[1]: *** [stage1-bubble] Error 2

make[1]: Leaving directory

`/svnstore/unix/hendrik/git/gccgo/gccgo-build/build.HP-UX-B.11.23-ia64/gcc-4.8.0'

make: *** [all] Error 2

[Bug tree-optimization/56778] [4.9 Regression] ICE on several benchmarks after r196775.

[rguenth at gcc dot gnu.org]

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



--- Comment #2 from Richard Biener  2013-04-02 
11:19:35 UTC ---

The issue is that gimple_seq_add_seq updates stmts added.  But we update SSA

form _before_ adding the sequence into the IL stream:



  /* End loop-exit-fixes after versioning.  */



  update_ssa (TODO_update_ssa);

  if (cond_expr_stmt_list)

{

  cond_exp_gsi = gsi_last_bb (condition_bb);

  gsi_insert_seq_before (&cond_exp_gsi, cond_expr_stmt_list,

 GSI_SAME_STMT);

}



gimplify.c has a function that does gimple_seq_add_seq_without_update.



There are two ways to fix this, one is to insert the sequence before

updating SSA form, another is to consistently use

gimple_seq_add_seq_without_update.

Or to make gimple_seq_add_seq not update stmts (sequences are inserted

later anyway, which can do the update).  Not sure why it would make sense

at all to update stmt operands for sth not in the IL ...



Well.  I'm going for the first.



Which doesn't fix it because we create an alias-check for a load of a

load appearantly where the latter is not loop invariant.  I presume

this is GATHER support, and eventually the DDR mangling in data-ref

analysis I removed did avoid this to happen.

[Bug tree-optimization/56812] New: Simple loop is not SLP-vectorized after r196872

[ysrumyan at gmail dot com]

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



 Bug #: 56812

   Summary: Simple loop is not SLP-vectorized after r196872

Classification: Unclassified

   Product: gcc

   Version: 4.9.0

Status: UNCONFIRMED

  Severity: normal

  Priority: P3

 Component: tree-optimization

AssignedTo: unassig...@gcc.gnu.org

ReportedBy: ysrum...@gmail.com





A simple loop in attached test-case is not SLP-vectorized after this fix with

message:



t.cc:12: note: can't determine dependence between this_4(D)->data[0] and

this_4(D)->data[i_14]

t.cc:12: note: not vectorized: unhandled data dependence in basic block.



To reproduce the failure it is sufficient to compile this test on x86 with the

following options:

  -O3 -funroll-loops -march=IVB

[Bug tree-optimization/56812] Simple loop is not SLP-vectorized after r196872

[ysrumyan at gmail dot com]

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



--- Comment #1 from Yuri Rumyantsev  2013-04-02 
11:22:45 UTC ---

Created attachment 29775

  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=29775

testcase



Need to compile with -O3 -funroll-loops options.

[Bug tree-optimization/56778] [4.9 Regression] ICE on several benchmarks after r196775.

[rguenth at gcc dot gnu.org]

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



--- Comment #3 from Richard Biener  2013-04-02 
11:27:09 UTC ---

I have a fix.

[Bug tree-optimization/56812] Simple loop is not SLP-vectorized after r196872

[ysrumyan at gmail dot com]

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



--- Comment #2 from Yuri Rumyantsev  2013-04-02 
11:41:23 UTC ---

Sorry, i did a typo in -march option - it must be -march=corei7 -mavx.

[Bug tree-optimization/56787] [4.8/4.9 Regression] Vectorization fails because of CLOBBER statements

[rguenth at gcc dot gnu.org]

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



Richard Biener  changed:



   What|Removed |Added



 Status|UNCONFIRMED |NEW

   Keywords||missed-optimization

   Last reconfirmed||2013-04-02

  Component|c   |tree-optimization

 CC||matz at gcc dot gnu.org

 Ever Confirmed|0   |1

Summary|4.8.0 Vectorization |[4.8/4.9 Regression]

   |Regression Compared to  |Vectorization fails because

   |4.7.2   |of CLOBBER statements

   Target Milestone|--- |4.8.1



--- Comment #1 from Richard Biener  2013-04-02 
12:02:39 UTC ---

t.c:137: note: not vectorized: no vectype for stmt: u ={v} {CLOBBER};

 scalar_type: float[5]

t.c:137: note: bad data references.

t.c:137: note: * Re-trying analysis with vector size 16

[Bug rtl-optimization/55611] Operand swapping for commutative operators

[glisse at gcc dot gnu.org]

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



--- Comment #5 from Marc Glisse  2013-04-02 12:11:12 
UTC ---

See the discussion at:



http://gcc.gnu.org/ml/gcc-patches/2013-03/msg00692.html



which continues at:



http://gcc.gnu.org/ml/gcc-patches/2013-04/msg00049.html



for why we won't do arbitrary canonicalization.

[Bug c++/56768] [4.7] ICE in make_decl_rtl, at varasm.c:1147

[rguenth at gcc dot gnu.org]

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



Richard Biener  changed:



   What|Removed |Added



 Status|ASSIGNED|RESOLVED

  Known to work||4.7.3

 Resolution||FIXED

   Target Milestone|--- |4.7.3



--- Comment #5 from Richard Biener  2013-04-02 
12:25:59 UTC ---

Author: rguenth

Date: Tue Apr  2 12:23:13 2013

New Revision: 197349



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

Log:

2013-04-02  Richard Biener  



PR middle-end/56768

* g++.dg/torture/pr56768.C: New testcase.



Added:

trunk/gcc/testsuite/g++.dg/torture/pr56768.C

Modified:

trunk/gcc/testsuite/ChangeLog



Author: rguenth

Date: Tue Apr  2 12:24:04 2013

New Revision: 197350



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

Log:

2013-04-02  Richard Biener  



PR middle-end/56768

* g++.dg/torture/pr56768.C: New testcase.



Added:

branches/gcc-4_8-branch/gcc/testsuite/g++.dg/torture/pr56768.C

Modified:

branches/gcc-4_8-branch/gcc/testsuite/ChangeLog



Author: rguenth

Date: Tue Apr  2 12:25:00 2013

New Revision: 197351



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

Log:

2013-04-02  Richard Biener  



PR middle-end/56768

Backport from mainline

2012-05-16  Richard Guenther  



* tree-inline.c (declare_return_variable): Properly handle

DECL_BY_REFERENCE return vars in SSA form.



* g++.dg/torture/pr56768.C: New testcase.



Added:

branches/gcc-4_7-branch/gcc/testsuite/g++.dg/torture/pr56768.C

Modified:

branches/gcc-4_7-branch/gcc/ChangeLog

branches/gcc-4_7-branch/gcc/testsuite/ChangeLog

branches/gcc-4_7-branch/gcc/tree-inline.c

[Bug c++/56698] "array subscript is above array bounds" triggered on code that doesn't have that problem

[jason at gcc dot gnu.org]

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



Jason Merrill  changed:



   What|Removed |Added



 CC||jason at gcc dot gnu.org



--- Comment #2 from Jason Merrill  2013-04-02 
12:43:32 UTC ---

Could you attach a preprocessed file (compressed if needed) and the

configuration/flags that reproduce the issue?

[Bug c++/56698] "array subscript is above array bounds" triggered on code that doesn't have that problem

[jason at gcc dot gnu.org]

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



Jason Merrill  changed:



   What|Removed |Added



 Status|UNCONFIRMED |WAITING

   Last reconfirmed||2013-04-02

 Ever Confirmed|0   |1

[Bug tree-optimization/56799] Runfail after r197060+r197082.

[law at redhat dot com]

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



Jeffrey A. Law  changed:



   What|Removed |Added



 Status|UNCONFIRMED |ASSIGNED

   Last reconfirmed||2013-04-02

 AssignedTo|unassigned at gcc dot   |law at redhat dot com

   |gnu.org |

 Ever Confirmed|0   |1

[Bug gcov-profile/56773] Programs crash if compiled with --coverage, although they run correctly without --coverage

[peter.hans.froehlich at gmail dot com]

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



--- Comment #4 from peter.hans.froehlich at gmail dot com 2013-04-02 13:10:22 
UTC ---

I am fine with your decision to declare this INVALID, I'd just like to

understand the reasoning. You're saying that it's okay for code injected by gcc

to crash depending on the context in which it is injected? From the perspective

of a mere user, that seems entirely unsatisfying. After all fopen() doesn't

crash when I define a symbol called open in my code, and fopen() presumably

needs to use the open() syscall eventually just like the code injected by gcc

for --coverage does. If gcc would inject code with suitably mangled names,

wouldn't this issue disappear? (Thank you to whoever takes the time to explain

this to me. BTW, I understand *why* fopen() doesn't crash, that's not the

issue.)

[Bug tree-optimization/56812] Simple loop is not SLP-vectorized after r196872

[rguenth at gcc dot gnu.org]

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



Richard Biener  changed:



   What|Removed |Added



 Status|UNCONFIRMED |WAITING

   Last reconfirmed||2013-04-02

 Ever Confirmed|0   |1



--- Comment #3 from Richard Biener  2013-04-02 
13:20:47 UTC ---

It should not make a difference ... I see that vectorization is determined

to be not profitable though:



t.C:11: note: === vect_update_slp_costs_according_to_vf ===cost model: prologue

peel iters set to vf/2.cost model: epilogue peel iters set to vf/2 because

peeling for alignment is unknown.

t.C:11: note: Cost model analysis:

  Vector inside of loop cost: 1

  Vector prologue cost: 11

  Vector epilogue cost: 2

  Scalar iteration cost: 1

  Scalar outside cost: 0

  Vector outside cost: 13

  prologue iterations: 2

  epilogue iterations: 2

  Calculated minimum iters for profitability: 17



but it's not vectorized with 4.8 either.  -fno-vect-cost-model fixes this.



Are you sure you attached the correct testcase?

[Bug libfortran/56810] record-repeat fails kind check on complex read

[burnus at gcc dot gnu.org]

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



Tobias Burnus  changed:



   What|Removed |Added



   Keywords||wrong-code

 Status|UNCONFIRMED |NEW

   Last reconfirmed||2013-04-02

 CC||burnus at gcc dot gnu.org,

   ||jvdelisle at gcc dot

   ||gnu.org

 Ever Confirmed|0   |1

  Known to fail||4.1.2, 4.3.4, 4.5.3, 4.6.3,

   ||4.7.2, 4.8.0, 4.9.0



--- Comment #1 from Tobias Burnus  2013-04-02 
13:22:33 UTC ---

> Fortran runtime error: Read kind 8 COMPLEX where kind 4 is required for item 2



That's a rather odd message for I/O: The I/O system should be agnostic too the

keal kinds. (Besides, there is only kind=4 in the example.)



It's not a regression, I get the same failure with GCC/gfortran 4.1 to 4.9

[Bug lto/56804] lto1: internal compiler error: bytecode stream: found non-null terminated string

[rguenth at gcc dot gnu.org]

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



--- Comment #5 from Richard Biener  2013-04-02 
13:25:12 UTC ---

Works for me.  Are you sure -lvpx doesn't contain LTO bytecode?  Can you

reproduce it with -r -nostdlib?  Please provide the output of appending

-v to the link line - also look for the inputs to the WPA stage

(the lto1 command with -fwpa, there is a response file at the end,

save it with -save-temps and inspect it - there are all objects with

LTO bytecode listed).

[Bug tree-optimization/56812] Simple loop is not SLP-vectorized after r196872

[ysrumyan at gmail dot com]

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



--- Comment #4 from Yuri Rumyantsev  2013-04-02 
13:27:15 UTC ---

Yes, the test-case is correct. If we delete your changes we got thee following

(with -ftree-vectorizer-verbose-3):



t.cc:12: note: vectorizing stmts using SLP.BASIC BLOCK VECTORIZED



t.cc:12: note: basic block vectorized using SLP

[Bug fortran/50269] Wrongly rejects element of assumed-shape array in C_LOC

[burnus at gcc dot gnu.org]

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



--- Comment #8 from Tobias Burnus  2013-04-02 
13:28:00 UTC ---

(In reply to comment #7)

> (In reply to comment #6)

> > Are we sure? When running the code example given in comment #1, I get a

> > segfault.

> Yes, something seems to be still broken.



Actually, the compiler generates the correct code. The problem with the test

case of comment 0 and comment 1 is that "b" is a pointer but never allocated.



It works if one either removes "pointer" from the declaration of "b" or adds an

"allocate(b)".

[Bug tree-optimization/56778] [4.9 Regression] ICE on several benchmarks after r196775.

[rguenth at gcc dot gnu.org]

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



Richard Biener  changed:



   What|Removed |Added



 Status|ASSIGNED|RESOLVED

 Resolution||FIXED



--- Comment #4 from Richard Biener  2013-04-02 
13:31:40 UTC ---

Author: rguenth

Date: Tue Apr  2 13:31:05 2013

New Revision: 197355



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

Log:

2013-04-02  Richard Biener  



PR tree-optimization/56778

* tree-vect-data-refs.c (vect_analyze_data_ref_dependence):

Runtime alias tests are not supported for gather loads.

* tree-vect-loop-manip.c (vect_loop_versioning): Insert

stmts referenced from SSA operands before updating SSA form.



* gcc.dg/torture/pr56778.c: New testcase.



Added:

trunk/gcc/testsuite/gcc.dg/torture/pr56778.c

Modified:

trunk/gcc/ChangeLog

trunk/gcc/testsuite/ChangeLog

trunk/gcc/tree-vect-data-refs.c

trunk/gcc/tree-vect-loop-manip.c

[Bug tree-optimization/56812] Simple loop is not SLP-vectorized after r196872

[rguenth at gcc dot gnu.org]

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



Richard Biener  changed:



   What|Removed |Added



 Status|WAITING |ASSIGNED

 AssignedTo|unassigned at gcc dot   |rguenth at gcc dot gnu.org

   |gnu.org |



--- Comment #5 from Richard Biener  2013-04-02 
13:36:11 UTC ---

Ah, I see.  Confirmed.

[Bug tree-optimization/56812] Simple loop is not SLP-vectorized after r196872

[rguenth at gcc dot gnu.org]

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



--- Comment #6 from Richard Biener  2013-04-02 
14:06:12 UTC ---

The BB vectorization case ran into



  /* When vectorizing a basic block unknown depnedence can still mean

 grouped access.  */

  if (vect_check_interleaving (dra, drb))

 return false;



that is, whenever dra and drb are part of the same interleaving chain

it considers the accesses to be independent.  I'm not sure this is

a good idea in general, but it's easy to re-instantiate.



There is no reason why dependence analysis should fail here though

(it does because dr_may_alias_p does not use SCEV info as computed by

dr_analyze_innermost and used by interleaving chain analysis, but instead

it looks at the base DR_REF which is also used as DR_BASE_OBJECT).

[Bug middle-end/52436] BIT_FIELD_REF > should be canonicalized for non-bitfield accesses

[glisse at gcc dot gnu.org]

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



--- Comment #4 from Marc Glisse  2013-04-02 14:08:57 
UTC ---

(In reply to comment #3)

> I'd re-organize it like



Ok, I'll try something like that.



> it avoids building a tree just to feed it into get_addr_base_and_unit_offset



The idea was that there would be almost no cases where this was done and no

simplification occurred. If a transformation is indeed done, building one tree

is not that expensive, especially if it avoids code duplication.



> It also avoids it if the access is not of byte-granularity which

> get_addr_base_and_unit_offset does not even consider (it assumes it is fed

> the argument of an ADDR_EXPR which obviously is byte-aligned).

> 

> The tree-flow-inline.h bits look ok.



In get_addr_base_and_unit_offset_1 I already check if the offset is a multiple

of BITS_PER_UNIT, I should probably check that the size is a multiple as well,

no?



> I'm not sure what you need the forwprop / tree-ssa-propagate changes for.



I need something to call fold on a bit_field_ref of a mem_ref. For PR55266, the

vector lowering pass produces a mem_ref and a bit_field_ref in two distinct

gimple statements, and nothing tries to combine them.

[Bug middle-end/52436] BIT_FIELD_REF > should be canonicalized for non-bitfield accesses

[rguenther at suse dot de]

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



--- Comment #5 from rguenther at suse dot de  
2013-04-02 14:21:56 UTC ---

On Tue, 2 Apr 2013, glisse at gcc dot gnu.org wrote:



> 

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

> 

> --- Comment #4 from Marc Glisse  2013-04-02 
> 14:08:57 UTC ---

> (In reply to comment #3)

> > I'd re-organize it like

> 

> Ok, I'll try something like that.

> 

> > it avoids building a tree just to feed it into get_addr_base_and_unit_offset

> 

> The idea was that there would be almost no cases where this was done and no

> simplification occurred. If a transformation is indeed done, building one tree

> is not that expensive, especially if it avoids code duplication.



AFAIK it really doesn't.



> > It also avoids it if the access is not of byte-granularity which

> > get_addr_base_and_unit_offset does not even consider (it assumes it is fed

> > the argument of an ADDR_EXPR which obviously is byte-aligned).

> > 

> > The tree-flow-inline.h bits look ok.

> 

> In get_addr_base_and_unit_offset_1 I already check if the offset is a multiple

> of BITS_PER_UNIT, I should probably check that the size is a multiple as well,

> no?



No, get_addr_base_and_unit_offset_1 only is supposed to return the

addressable offset into an object - it doesn't care about access sizes.



> > I'm not sure what you need the forwprop / tree-ssa-propagate changes for.

> 

> I need something to call fold on a bit_field_ref of a mem_ref. For PR55266, 
> the

> vector lowering pass produces a mem_ref and a bit_field_ref in two distinct

> gimple statements, and nothing tries to combine them.



But you can't really do what you do there.  You are possibly

transforming



  vecreg_2 = MEM[...];



  MEM[...] = ; // clobber the memory location 



  scalreg_3 = BIT_FIELD_REF ;



into



  vecreg_2 = MEM[...]; // possibly unused

...

  MEM[...] = ; // clobber the memory location

...

  scalreg_3 = MEM[...];



which is not correct, obviously.  "combining" with memory

accesses isn't trivial, certainly not a task I would consider

for forwprop.  I can't think of a suitable existing pass

that would combine this, but value-numbering should eventually

value-number both cases the same at least.



Richard.

[Bug middle-end/52436] BIT_FIELD_REF > should be canonicalized for non-bitfield accesses

[glisse at gcc dot gnu.org]

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



--- Comment #6 from Marc Glisse  2013-04-02 14:36:59 
UTC ---

(In reply to comment #5)

> No, get_addr_base_and_unit_offset_1 only is supposed to return the

> addressable offset into an object - it doesn't care about access sizes.



It is also allowed to say "bad idea, I will return NULL", but ok.



> But you can't really do what you do there.  You are possibly

> transforming

[...]



Good point, thanks.



> which is not correct, obviously.  "combining" with memory

> accesses isn't trivial, certainly not a task I would consider

> for forwprop.  I can't think of a suitable existing pass

> that would combine this, but value-numbering should eventually

> value-number both cases the same at least.



I guess that leaves the vector lowering pass as the easiest alternative for

PR55266: split all unsupported memory reads into supported reads and a

constructor (and similarly, split writes into bit_field_refs and writes) and

hope that nothing does the reverse transformation.

[Bug c++/22488] C++ frontend generates RECORD_TYPEs with overlapping FIELD_DECLs

[ebotcazou at gcc dot gnu.org]

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



Eric Botcazou  changed:



   What|Removed |Added



 CC||ebotcazou at gcc dot

   ||gnu.org



--- Comment #58 from Eric Botcazou  2013-04-02 
14:37:43 UTC ---

> The C++ frontend issue makes it impossible to implement a GENERIC verifier

> for RECORD_TYPEs (verify FIELD_DECLs are sorted after offset and not

> overlapping).



To be fair, I think that the Ada front-end still has the same issue.  We fixed

the biggest source (constrained subtypes of record types with variant part) a

few releases ago, but there is still one problematic case (record type with

variant part and partial representation clause).

[Bug tree-optimization/56787] [4.8/4.9 Regression] Vectorization fails because of CLOBBER statements

[jakub at gcc dot gnu.org]

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



Jakub Jelinek  changed:



   What|Removed |Added



 CC||jakub at gcc dot gnu.org



--- Comment #2 from Jakub Jelinek  2013-04-02 
14:50:18 UTC ---

Somewhat reduced testcase:

inline void

bar (const float s[5], float z[3][5])

{

  float a = s[0], b = s[1], c = s[2], d = s[3], e = s[4];

  float f = 1.0f / a;

  float u = f * b, v = f * c, w = f * d;

  float p = 0.4f * (e - 0.5f * (b * u + c * v + d * w));

  z[0][3] = b * w;

  z[1][3] = c * w;

  z[2][3] = d * w + p;

}



void

foo (unsigned long n, const float *__restrict u0,

 const float *__restrict u1, const float *__restrict u2,

 const float *__restrict u3, const float *__restrict u4,

 const float *__restrict s0, const float *__restrict s1,

 const float *__restrict s2, float *__restrict t3,

 float *__restrict t4)

{

  unsigned long i;

  for (i = 0; i < n; i++)

{

  float u[5], f[3][5];

  u[0] = u0[i]; u[1] = u1[i]; u[2] = u2[i]; u[3] = u3[i]; u[4] = u4[i];

  bar (u, f);

  t3[i] = s0[i] * f[0][3] + s1[i] * f[1][3] + s2[i] * f[2][3];

}

}

[Bug bootstrap/56813] New: [4.9 regression] invalid assembly code for libiberty/cp-demangle.c on armv5tel-linux-gnueabi

[mikpe at it dot uu.se]

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



 Bug #: 56813

   Summary: [4.9 regression] invalid assembly code for

libiberty/cp-demangle.c on armv5tel-linux-gnueabi

Classification: Unclassified

   Product: gcc

   Version: 4.9.0

Status: UNCONFIRMED

  Severity: normal

  Priority: P3

 Component: bootstrap

AssignedTo: unassig...@gcc.gnu.org

ReportedBy: mi...@it.uu.se





Created attachment 29776

  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=29776

preprocessed source and generated assembly code



Attempting to bootstrap gcc-4.9-20130331 on armv5tel-linux-gnueabi fails with:



ln -s /mnt/scratch/gcc-4.9-20130331/libstdc++-v3/../libiberty/cp-demangle.c

cp-demangle.c

/bin/sh ../libtool --tag CC --tag disable-shared  --mode=compile

/mnt/scratch/objdir49/./gcc/xgcc -B/mnt/scratch/objdir49/./gcc/

-B/mnt/scratch/install49/armv5tel-unknown-linux-gnueabi/bin/

-B/mnt/scratch/install49/armv5tel-unknown-linux-gnueabi/lib/ -isystem

/mnt/scratch/install49/armv5tel-unknown-linux-gnueabi/include -isystem

/mnt/scratch/install49/armv5tel-unknown-linux-gnueabi/sys-include   

-DHAVE_CONFIG_H -I.. -I/mnt/scratch/gcc-4.9-20130331/libstdc++-v3/../libiberty

-I/mnt/scratch/gcc-4.9-20130331/libstdc++-v3/../include -prefer-pic

-D_GLIBCXX_SHARED

-I/mnt/scratch/objdir49/armv5tel-unknown-linux-gnueabi/libstdc++-v3/include/armv5tel-unknown-linux-gnueabi

-I/mnt/scratch/objdir49/armv5tel-unknown-linux-gnueabi/libstdc++-v3/include

-I/mnt/scratch/gcc-4.9-20130331/libstdc++-v3/libsupc++   -g -O2 -DIN_GLIBCPP_V3

-Wno-error -c cp-demangle.c

libtool: compile:  /mnt/scratch/objdir49/./gcc/xgcc

-B/mnt/scratch/objdir49/./gcc/

-B/mnt/scratch/install49/armv5tel-unknown-linux-gnueabi/bin/

-B/mnt/scratch/install49/armv5tel-unknown-linux-gnueabi/lib/ -isystem

/mnt/scratch/install49/armv5tel-unknown-linux-gnueabi/include -isystem

/mnt/scratch/install49/armv5tel-unknown-linux-gnueabi/sys-include

-DHAVE_CONFIG_H -I.. -I/mnt/scratch/gcc-4.9-20130331/libstdc++-v3/../libiberty

-I/mnt/scratch/gcc-4.9-20130331/libstdc++-v3/../include -D_GLIBCXX_SHARED

-I/mnt/scratch/objdir49/armv5tel-unknown-linux-gnueabi/libstdc++-v3/include/armv5tel-unknown-linux-gnueabi

-I/mnt/scratch/objdir49/armv5tel-unknown-linux-gnueabi/libstdc++-v3/include

-I/mnt/scratch/gcc-4.9-20130331/libstdc++-v3/libsupc++ -g -O2 -DIN_GLIBCPP_V3

-Wno-error -c cp-demangle.c  -fPIC -DPIC -o cp-demangle.o

/tmp/ccdHzBmd.s: Assembler messages:

/tmp/ccdHzBmd.s:13290: Error: bad immediate value for offset (4104)

make[5]: *** [cp-demangle.lo] Error 1

make[5]: Leaving directory

`/mnt/scratch/objdir49/armv5tel-unknown-linux-gnueabi/libstdc++-v3/libsupc++'

make[4]: *** [all-recursive] Error 1

make[4]: Leaving directory

`/mnt/scratch/objdir49/armv5tel-unknown-linux-gnueabi/libstdc++-v3'

make[3]: *** [all] Error 2

make[3]: Leaving directory

`/mnt/scratch/objdir49/armv5tel-unknown-linux-gnueabi/libstdc++-v3'

make[2]: *** [all-stage1-target-libstdc++-v3] Error 2

make[2]: Leaving directory `/mnt/scratch/objdir49'

make[1]: *** [stage1-bubble] Error 2

make[1]: Leaving directory `/mnt/scratch/objdir49'

make: *** [bootstrap] Error 2



This is a recent regression as the previous weekly snapshot, 4.9-20130324,

bootstrapped fine.



The preprocessed code for cp-demangle.c also compiles fine with current 4.8,

4.7, and 4.6 branches.



Binutils is based on 2.22.52.0.1 20120131.



Configuration options:

/mnt/scratch/gcc-4.9-20130331/configure --prefix=/mnt/scratch/install49

--enable-bootstrap --enable-shared --enable-threads=posix

--enable-checking=release --with-system-zlib --enable-__cxa_atexit

--disable-libunwind-exceptions --enable-languages=c,c++,fortran,ada

--disable-dssi --with-java-home=/usr/lib/jvm/java-1.5.0-gcj-1.5.0.0/jre

--enable-libgcj-multifile --disable-java-maintainer-mode

--with-ecj-jar=/usr/share/java/eclipse-ecj.jar --disable-libjava-multilib

--disable-sjlj-exceptions --with-arch=armv5te --with-tune=xscale

--build=armv5tel-unknown-linux-gnueabi --disable-plugin --disable-lto

--disable-libmudflap



I'll attach cp-demangle.{i,s}.

[Bug libfortran/56737] [4.6/4.7/4.8/4.9 Regression] Wrong I/O result with format cache for Hollerith strings

[burnus at gcc dot gnu.org]

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



--- Comment #7 from Tobias Burnus  2013-04-02 
15:43:19 UTC ---

Author: burnus

Date: Tue Apr  2 15:42:31 2013

New Revision: 197359



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

Log:

libgfortran/

2013-04-02  Tobias Burnus  



Backport from mainline:

2013-03-29  Tobias Burnus  



PR fortran/56737

* io/format.c (parse_format): With caching, copy

dtp->format string.

(save_parsed_format): Use dtp->format directly without

copying.



2012-03-29  Tobias Burnus  



PR fortran/56737

* io/format.c (parse_format_list): Also cache FMT_STRING.

(parse_format): Update call.



gcc/testsuite/

2013-04-02  Tobias Burnus  



Backport from mainline:

2013-03-29  Tobias Burnus  



PR fortran/56737

* testsuite/gfortran.dg/fmt_cache_3.f90: New.





Added:

branches/gcc-4_8-branch/gcc/testsuite/gfortran.dg/fmt_cache_3.f90

Modified:

branches/gcc-4_8-branch/gcc/testsuite/ChangeLog

branches/gcc-4_8-branch/libgfortran/ChangeLog

branches/gcc-4_8-branch/libgfortran/io/format.c

[Bug fortran/56814] New: [4.8/4.9 Regression] Bogus Interface mismatch in dummy procedure

[burnus at gcc dot gnu.org]

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



 Bug #: 56814

   Summary: [4.8/4.9 Regression] Bogus Interface mismatch in dummy

procedure

Classification: Unclassified

   Product: gcc

   Version: 4.9.0

Status: UNCONFIRMED

  Keywords: rejects-valid

  Severity: normal

  Priority: P3

 Component: fortran

AssignedTo: unassig...@gcc.gnu.org

ReportedBy: bur...@gcc.gnu.org

CC: ja...@gcc.gnu.org





The following code compiles with ifort and gfortran 4.5 to 4.7. With 4.8 and

4.9 it fails with:



Error: Interface mismatch in dummy procedure 'fun' at (1): PROCEDURE POINTER

mismatch in function result



However, to me the interfaces look the same.





Reported at comp.lang.fortran by Macro Restelli,

https://groups.google.com/forum/?fromgroups=#!topic/comp.lang.fortran/rfoD-brnIqI





module m1

 abstract interface

  pure function i_f(x) result(d)

   real, intent(in) :: x(:,:)

   real :: d(size(x,1),size(x,2))

  end function i_f

 end interface



 procedure(i_f), pointer :: f => null()

end module m1



module m2

contains

 pure subroutine ns_dirdata(fun)

  interface

   pure function fun(x) result(d)

real, intent(in) :: x(:,:)

real :: d(size(x,1),size(x,2))

   end function fun

  end interface

 end subroutine ns_dirdata

end module m2



program p

 use m1

 use m2

  call ns_dirdata(f)

end program p

[Bug fortran/56814] [4.8/4.9 Regression] Bogus Interface mismatch in dummy procedure

[burnus at gcc dot gnu.org]

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



Tobias Burnus  changed:



   What|Removed |Added



 CC||burnus at gcc dot gnu.org

   Target Milestone|--- |4.8.1

[Bug other/56811] [4.8 Regression] libbacktrace causes undefined symbol "_Unwind_GetIPInfo" on ia64-hpux

[pinskia at gcc dot gnu.org]

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



Andrew Pinski  changed:



   What|Removed |Added



  Component|c   |other

   Host||ia64-hpux

   Target Milestone|--- |4.8.1

Summary|gcc build fails:|[4.8 Regression]

   |Unsatisfied symbol  |libbacktrace causes

   |"_Unwind_GetIPInfo" |undefined symbol

   ||"_Unwind_GetIPInfo" on

   ||ia64-hpux

   Severity|blocker |normal

[Bug fortran/56735] [4.6/4.7/4.8/4.9 Regression] Namelist Read Error with question marks

[burnus at gcc dot gnu.org]

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



--- Comment #10 from Tobias Burnus  2013-04-02 
16:31:25 UTC ---

Author: burnus

Date: Tue Apr  2 16:30:26 2013

New Revision: 197361



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

Log:

libgfortran/

2013-04-02  Tobias Burnus  



Backport from mainline:

2013-03-28  Tobias Burnus  



PR fortran/56735

* io/list_read.c (nml_query): Only abort when

an error occured.

(namelist_read): Add goto instead of falling through.





gcc/testsuite/

2013-04-02  Tobias Burnus  



Backport from mainline:

2013-03-28  Tobias Burnus  



PR fortran/56735

* gfortran.dg/namelist_80.f90: New.





Added:

branches/gcc-4_8-branch/gcc/testsuite/gfortran.dg/namelist_80.f90

Modified:

branches/gcc-4_8-branch/gcc/testsuite/ChangeLog

branches/gcc-4_8-branch/libgfortran/ChangeLog

branches/gcc-4_8-branch/libgfortran/io/list_read.c

[Bug tree-optimization/50789] Gather vectorization

[vincenzo.innocente at cern dot ch]

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

vincenzo Innocente  changed:

   What|Removed |Added

 CC||vincenzo.innocente at cern
   ||dot ch

--- Comment #10 from vincenzo Innocente  
2013-04-02 16:49:53 UTC ---
I was trying to see how gcc behaves w.r.t. this example
http://software.intel.com/en-us/articles/bkm-coaxing-the-compiler-to-vectorize-structured-data-via-gathers

So I started from the example in comment 6 and "evolved" as follows
f21() and f22() are equivalent to my eyes
f21 vectorize, f22 not
also the variant f21b does not vectorize…

c++ -v
Using built-in specs.
COLLECT_GCC=c++
COLLECT_LTO_WRAPPER=/usr/local/libexec/gcc/x86_64-apple-darwin12.2.0/4.8.0/lto-wrapper
Target: x86_64-apple-darwin12.2.0
Configured with: ./configure --enable-languages=c,c++,fortran
--disable-multilib --disable-bootstrap --enable-lto -disable-libitm :
(reconfigured) ./configure --enable-languages=c,c++,fortran --disable-multilib
--disable-bootstrap --enable-lto -disable-libitm : (reconfigured) ./configure
--enable-languages=c,c++,fortran --disable-multilib --disable-bootstrap
--enable-lto -disable-libitm
Thread model: posix
gcc version 4.8.0 20130313 (experimental) [trunk revision 196633] (GCC) 

c++ -std=c++11 -Ofast -mavx2 -S gather.cc -ftree-vectorizer-verbose=2  

struct float3 {
  float x;
  float y;
  float z;
};

#define N 1024
float fx[N], g[N];
float fy[N];
float fz[N]; 
int k[N];

float ff[3*N];
float3 f3[N];
void
f20 (void)
{
  int i;
  for (i = 0; i < N; i++)
g[i] = fx[k[i]]+fy[k[i]]+fz[k[i]];
}

void
f21 (void)
{
  int i;
  for (i = 0; i < N; i++)
g[i] = ff[3*k[i]]+ff[3*k[i]+1]+ff[3*k[i]+2];
}
void
f22 (void)
{
  int i;
  for (i = 0; i < N; i++)
g[i] = f3[k[i]].x+f3[k[i]].y+f3[k[i]].z;
}


void
f21b (void)
{
  int i;
  for (i = 0; i < N; i++) {
auto j = ff+3*k[i];
g[i] = j[0]+j[1]+j[2];
  }
}

[Bug c++/56815] New: void pointer arithmetic

[d.v.a at ngs dot ru]

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



 Bug #: 56815

   Summary: void pointer arithmetic

Classification: Unclassified

   Product: gcc

   Version: 4.8.0

Status: UNCONFIRMED

  Severity: normal

  Priority: P3

 Component: c++

AssignedTo: unassig...@gcc.gnu.org

ReportedBy: d@ngs.ru





int main()

{

void *p = 0;

p += 1;

}



$ gcc -std=c++98 source.cpp



source.cpp: In function 'int main()':

source.cpp:4:7: warning: pointer of type 'void *' used in arithmetic

[-Wpedantic]

 p += 1;

   ^



Why only warning? It must be error. Other compilers reject this code.

[Bug c++/56815] void pointer arithmetic

[d.v.a at ngs dot ru]

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



--- Comment #1 from __vic  2013-04-02 17:00:23 UTC ---

Slightly modified:



int main()

{

void *p = 0;

p++;

}



$ gcc -std=c++98 source.cpp



source.cpp:4:6: error: arithmetic on a pointer to void

p++;

~^

[Bug c++/56815] void pointer arithmetic

[pinskia at gcc dot gnu.org]

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



--- Comment #2 from Andrew Pinski  2013-04-02 
17:04:31 UTC ---

Use -pedantic-errors if you want to have rejected invalid standard C++ code. 

void* arithmetic is a GCC extension.

[Bug c++/56815] void pointer arithmetic

[d.v.a at ngs dot ru]

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



--- Comment #3 from __vic  2013-04-02 17:10:15 UTC ---

(In reply to comment #2)

> void* arithmetic is a GCC extension.

But why my examples are treated differently?

[Bug fortran/56814] [4.8/4.9 Regression] Bogus Interface mismatch in dummy procedure

[burnus at gcc dot gnu.org]

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



--- Comment #1 from Tobias Burnus  2013-04-02 
17:25:18 UTC ---

The check is in interface.c's check_result_characteristics:



  /* Check PROCEDURE POINTER attribute.  */

  if (r1 != s1 && r1->attr.proc_pointer != r2->attr.proc_pointer)

{

  snprintf (errmsg, err_len, "PROCEDURE POINTER mismatch in "

"function result");





There are two things bogus here:

a) Passing a proc-pointer to a non-pointer procedure dummy is valid

b) There is no procedure(-pointer) function result, just a proc(-ptr)

actual/dummy argument.

[Bug debug/56805] DW_TAG_typedef missing when -fdebug-types-section is used (and -fno-eliminate-unused-debug-types)

[ccoutant at gcc dot gnu.org]

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



Cary Coutant  changed:



   What|Removed |Added



 CC||ccoutant at gcc dot gnu.org



--- Comment #2 from Cary Coutant  2013-04-02 
17:40:09 UTC ---

When generating separate type units with -fdebug-types-section, we always prune

unused types after splitting the types out. As implemented, I think

-fdebug-types-section is incompatible with -fno-eliminate-unused-debug-types,

and a diagnostic should be printed.



How important is it that these two options work together?

[Bug fortran/56816] New: f951.exe internal compiler error. segmentation fault

[dominique.pelletier at polymtl dot ca]

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



 Bug #: 56816

   Summary: f951.exe internal compiler error. segmentation fault

Classification: Unclassified

   Product: gcc

   Version: unknown

Status: UNCONFIRMED

  Severity: normal

  Priority: P3

 Component: fortran

AssignedTo: unassig...@gcc.gnu.org

ReportedBy: dominique.pellet...@polymtl.ca





Created attachment 29777

  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=29777

problem  occured trying to compile Metcalf example in MODERN FORTRAN EXPLAINED



DP@P-DP /cygdrive/c/users/dp/desktop/metcalf

$ gfortran -v -c myitem_list_module.f03

Using built-in specs.

COLLECT_GCC=C:\Program Files (x86)\gfortran\bin\gfortran.exe

Target: mingw32

Configured with: ../gcc-trunk/configure --prefix=/mingw

--enable-languages=c,fortran,lto --with-gmp=/home/brad/gfortran/dependencies

--disable-werror --enable-threads --enable-nls --build=i586-pc-mingw32

--enable-libgomp --enable-shared --disable-win32-registry --with-dwarf2

--disable-sjlj-exceptions --enable-lto --build=mingw32

--enable-version-specific-runtime-libs

Thread model: win32

gcc version 4.8.0 20130302 (experimental) [trunk revision 196403] (GCC)

COLLECT_GCC_OPTIONS='-v' '-c' '-mtune=i386' '-march=i386'

 c:/program files (x86)/gfortran/bin/../libexec/gcc/mingw32/4.8.0/f951.exe

myitem_list_module.f03 -quiet -dumpbase myitem_list_module.f03 -mtune=i386

-march=i386 -auxbase myitem_list_module -version -fintrinsic-modules-path

c:/program files (x86)/gfortran/bin/../lib/gcc/mingw32/4.8.0/finclude -o

C:\cygwin\tmp\cckGnVj1.s

GNU Fortran (GCC) version 4.8.0 20130302 (experimental) [trunk revision 196403]

(mingw32)

compiled by GNU C version 4.8.0 20130302 (experimental) [trunk revision

196403], GMP version 5.0.2, MPFR version 3.1.0, MPC version 0.9

GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096

GNU Fortran (GCC) version 4.8.0 20130302 (experimental) [trunk revision 196403]

(mingw32)

compiled by GNU C version 4.8.0 20130302 (experimental) [trunk revision

196403], GMP version 5.0.2, MPFR version 3.1.0, MPC version 0.9

GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096

f951.exe: internal compiler error: Segmentation fault

libbacktrace could not find executable to open

Please submit a full bug report,

with preprocessed source if appropriate.

See  for instructions.

[Bug fortran/56816] f951.exe internal compiler error. segmentation fault

[dominique.pelletier at polymtl dot ca]

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



Dominique Pelletier  changed:



   What|Removed |Added



Version|unknown |4.8.0



--- Comment #1 from Dominique Pelletier  
2013-04-02 17:49:18 UTC ---



DP@P-DP /cygdrive/c/users/dp/desktop/metcalf

$ gfortran -v -c myitem_list_module.f03

Using built-in specs.

COLLECT_GCC=C:\Program Files (x86)\gfortran\bin\gfortran.exe

Target: mingw32

Configured with: ../gcc-trunk/configure --prefix=/mingw

--enable-languages=c,fortran,lto --with-gmp=/home/brad/gfortran/dependencies

--disable-werror --enable-threads --enable-nls --build=i586-pc-mingw32

--enable-libgomp --enable-shared --disable-win32-registry --with-dwarf2

--disable-sjlj-exceptions --enable-lto --build=mingw32

--enable-version-specific-runtime-libs

Thread model: win32

gcc version 4.8.0 20130302 (experimental) [trunk revision 196403] (GCC)

COLLECT_GCC_OPTIONS='-v' '-c' '-mtune=i386' '-march=i386'

 c:/program files (x86)/gfortran/bin/../libexec/gcc/mingw32/4.8.0/f951.exe

myitem_list_module.f03 -quiet -dumpbase myitem_list_module.f03 -mtune=i386

-march=i386 -auxbase myitem_list_module -version -fintrinsic-modules-path

c:/program files (x86)/gfortran/bin/../lib/gcc/mingw32/4.8.0/finclude -o

C:\cygwin\tmp\cckGnVj1.s

GNU Fortran (GCC) version 4.8.0 20130302 (experimental) [trunk revision 196403]

(mingw32)

compiled by GNU C version 4.8.0 20130302 (experimental) [trunk revision

196403], GMP version 5.0.2, MPFR version 3.1.0, MPC version 0.9

GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096

GNU Fortran (GCC) version 4.8.0 20130302 (experimental) [trunk revision 196403]

(mingw32)

compiled by GNU C version 4.8.0 20130302 (experimental) [trunk revision

196403], GMP version 5.0.2, MPFR version 3.1.0, MPC version 0.9

GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096

f951.exe: internal compiler error: Segmentation fault

libbacktrace could not find executable to open

Please submit a full bug report,

with preprocessed source if appropriate.

See  for instructions.

[Bug fortran/56816] f951.exe internal compiler error. segmentation fault

[Joost.VandeVondele at mat dot ethz.ch]

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



Joost VandeVondele  changed:



   What|Removed |Added



 CC||Joost.VandeVondele at mat

   ||dot ethz.ch



--- Comment #2 from Joost VandeVondele  
2013-04-02 17:59:28 UTC ---

you'll need to provide also the sources of the files that define the modules,

otherwise we get:



bug.f90:3.8:



use any_list_module

1

Fatal Error: Can't open module file 'any_list_module.mod' for reading at (1):

No such file or directory

[Bug debug/56805] DW_TAG_typedef missing when -fdebug-types-section is used (and -fno-eliminate-unused-debug-types)

[jan.sm...@alcatel-lucent.com]

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



--- Comment #3 from Jan Smets  2013-04-02 
18:11:41 UTC ---

For me it's very important.  To briefly describe what we do: we have structures

that are sent to different platforms with configuration information for fail

over/redundancy/etc. First we use ccparse to parse our code and find all the

relevant types/structures/etc. We end up in the file where the type is defined,

not necessarily where it's used. Then we compile our entire project and parse

the objdump STABS output of these structures/files we found with ccparse. Then

that information is used to build a bunch of static asserts based on that

information. (eg, size of members, offsets, etc). This tool helps our software

designers.



I've just written a few thousand lines of perl code to parse DWARF output and

to  regenerate the compile time checks. GCC 4.6 seems to only support

type-sections anyway. Upgrading to 4.7 or 4.8 is not an option due to strict

release planning and limited test resources.



Anything you can do to make this work is appreciated. Thank you.

[Bug tree-optimization/56817] New: [4.8/4.9 Regression] ICE in hide_evolution_in_other_loops_than_loop

[jakub at gcc dot gnu.org]

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

 Bug #: 56817
   Summary: [4.8/4.9 Regression] ICE in
hide_evolution_in_other_loops_than_loop
Classification: Unclassified
   Product: gcc
   Version: 4.8.0
Status: UNCONFIRMED
  Keywords: ice-on-valid-code
  Severity: normal
  Priority: P3
 Component: tree-optimization
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: ja...@gcc.gnu.org


// { dg-do compile }
// { dg-options "-O3 --param max-unroll-times=32" }

struct A {};
A **q;
struct B
{
  A **j;
  B () { j = q; }
  A *& operator[] (unsigned long x) { return j[x]; }
};
struct C
{
  C (int r) : v (), s (r) {}
  A *& operator () (int i, int j) { return v[i * s + j]; }
  B v;
  int s;
};
struct D
{
  D ()
  {
unsigned h = 2;
for (int i = 0; i < 1; ++i, h *= 2)
  {
C w (h);
for (unsigned j = 0; j < h; ++j)
  for (unsigned k = 0; k < h; ++k)
w (j, k) = new A;
  }
  }
};
void
foo ()
{
  for (int i = 0; i < 3; i++)
A (), A (), D ();
}

ICEs with:
rh947433.C: In function ‘void foo()’:
rh947433.C:34:1: internal compiler error: in
hide_evolution_in_other_loops_than_loop, at tree-chrec.c:716
 foo ()
 ^

starting with http://gcc.gnu.org/r193098

[Bug fortran/56818] New: [meta-bug] fortran-dev bugs

[tkoenig at gcc dot gnu.org]

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



 Bug #: 56818

   Summary: [meta-bug] fortran-dev bugs

Classification: Unclassified

   Product: gcc

   Version: fortran-dev

Status: UNCONFIRMED

  Severity: normal

  Priority: P3

 Component: fortran

AssignedTo: unassig...@gcc.gnu.org

ReportedBy: tkoe...@gcc.gnu.org





This is a meta bug for bugs which should be fixed,

if possible, before fortran-dev is merged, either because

they are regressions or because the array descriptor reform

or other ABI changes.

[Bug fortran/56816] f951.exe internal compiler error. segmentation fault

[dominique.pelletier at polymtl dot ca]

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



Dominique Pelletier  changed:



   What|Removed |Added



  Attachment #29777|0   |1

is obsolete||



--- Comment #3 from Dominique Pelletier  
2013-04-02 19:02:07 UTC ---

Created attachment 29778

  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=29778

modules from metcalf's book Modern Fortran Explained



DP@P-DP /cygdrive/c/users/dp/Desktop/metcalf

$ gfortran -v -c bug_report.f03

Using built-in specs.

COLLECT_GCC=C:\Program Files (x86)\gfortran\bin\gfortran.exe

Target: mingw32

Configured with: ../gcc-trunk/configure --prefix=/mingw

--enable-languages=c,fortran,lto --with-gmp=/home/brad/gfortran/dependencies

--disable-werror --enable-threads --enable-nls --build=i586-pc-mingw32

--enable-libgomp --enable-shared --disable-win32-registry --with-dwarf2

--disable-sjlj-exceptions --enable-lto --build=mingw32

--enable-version-specific-runtime-libs

Thread model: win32

gcc version 4.8.0 20130302 (experimental) [trunk revision 196403] (GCC)

COLLECT_GCC_OPTIONS='-v' '-c' '-mtune=i386' '-march=i386'

 c:/program files (x86)/gfortran/bin/../libexec/gcc/mingw32/4.8.0/f951.exe

bug_report.f03 -quiet -dumpbase bug_report.f03 -mtune=i386 -march=i386 -auxbase

bug_report -version -fintrinsic-modules-path c:/program files

(x86)/gfortran/bin/../lib/gcc/mingw32/4.8.0/finclude -o

C:\cygwin\tmp\cc7RQyBk.s

GNU Fortran (GCC) version 4.8.0 20130302 (experimental) [trunk revision 196403]

(mingw32)

compiled by GNU C version 4.8.0 20130302 (experimental) [trunk revision

196403], GMP version 5.0.2, MPFR version 3.1.0, MPC version 0.9

GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096

GNU Fortran (GCC) version 4.8.0 20130302 (experimental) [trunk revision 196403]

(mingw32)

compiled by GNU C version 4.8.0 20130302 (experimental) [trunk revision

196403], GMP version 5.0.2, MPFR version 3.1.0, MPC version 0.9

GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096

f951.exe: internal compiler error: Segmentation fault

libbacktrace could not find executable to open

Please submit a full bug report,

with preprocessed source if appropriate.

See  for instructions.

[Bug fortran/56816] f951.exe internal compiler error. segmentation fault

[dominique.pelletier at polymtl dot ca]

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



--- Comment #4 from Dominique Pelletier  
2013-04-02 19:02:36 UTC ---

DP@P-DP /cygdrive/c/users/dp/Desktop/metcalf

$ gfortran -v -c bug_report.f03

Using built-in specs.

COLLECT_GCC=C:\Program Files (x86)\gfortran\bin\gfortran.exe

Target: mingw32

Configured with: ../gcc-trunk/configure --prefix=/mingw

--enable-languages=c,fortran,lto --with-gmp=/home/brad/gfortran/dependencies

--disable-werror --enable-threads --enable-nls --build=i586-pc-mingw32

--enable-libgomp --enable-shared --disable-win32-registry --with-dwarf2

--disable-sjlj-exceptions --enable-lto --build=mingw32

--enable-version-specific-runtime-libs

Thread model: win32

gcc version 4.8.0 20130302 (experimental) [trunk revision 196403] (GCC)

COLLECT_GCC_OPTIONS='-v' '-c' '-mtune=i386' '-march=i386'

 c:/program files (x86)/gfortran/bin/../libexec/gcc/mingw32/4.8.0/f951.exe

bug_report.f03 -quiet -dumpbase bug_report.f03 -mtune=i386 -march=i386 -auxbase

bug_report -version -fintrinsic-modules-path c:/program files

(x86)/gfortran/bin/../lib/gcc/mingw32/4.8.0/finclude -o

C:\cygwin\tmp\cc7RQyBk.s

GNU Fortran (GCC) version 4.8.0 20130302 (experimental) [trunk revision 196403]

(mingw32)

compiled by GNU C version 4.8.0 20130302 (experimental) [trunk revision

196403], GMP version 5.0.2, MPFR version 3.1.0, MPC version 0.9

GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096

GNU Fortran (GCC) version 4.8.0 20130302 (experimental) [trunk revision 196403]

(mingw32)

compiled by GNU C version 4.8.0 20130302 (experimental) [trunk revision

196403], GMP version 5.0.2, MPFR version 3.1.0, MPC version 0.9

GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096

f951.exe: internal compiler error: Segmentation fault

libbacktrace could not find executable to open

Please submit a full bug report,

with preprocessed source if appropriate.

See  for instructions.

[Bug fortran/56818] [meta-bug] fortran-dev bugs

[dominique.pelletier at polymtl dot ca]

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



Dominique Pelletier  changed:



   What|Removed |Added



 CC||dominique.pelletier at

   ||polymtl dot ca



--- Comment #1 from Dominique Pelletier  
2013-04-02 19:03:05 UTC ---

DP@P-DP /cygdrive/c/users/dp/Desktop/metcalf

$ gfortran -v -c bug_report.f03

Using built-in specs.

COLLECT_GCC=C:\Program Files (x86)\gfortran\bin\gfortran.exe

Target: mingw32

Configured with: ../gcc-trunk/configure --prefix=/mingw

--enable-languages=c,fortran,lto --with-gmp=/home/brad/gfortran/dependencies

--disable-werror --enable-threads --enable-nls --build=i586-pc-mingw32

--enable-libgomp --enable-shared --disable-win32-registry --with-dwarf2

--disable-sjlj-exceptions --enable-lto --build=mingw32

--enable-version-specific-runtime-libs

Thread model: win32

gcc version 4.8.0 20130302 (experimental) [trunk revision 196403] (GCC)

COLLECT_GCC_OPTIONS='-v' '-c' '-mtune=i386' '-march=i386'

 c:/program files (x86)/gfortran/bin/../libexec/gcc/mingw32/4.8.0/f951.exe

bug_report.f03 -quiet -dumpbase bug_report.f03 -mtune=i386 -march=i386 -auxbase

bug_report -version -fintrinsic-modules-path c:/program files

(x86)/gfortran/bin/../lib/gcc/mingw32/4.8.0/finclude -o

C:\cygwin\tmp\cc7RQyBk.s

GNU Fortran (GCC) version 4.8.0 20130302 (experimental) [trunk revision 196403]

(mingw32)

compiled by GNU C version 4.8.0 20130302 (experimental) [trunk revision

196403], GMP version 5.0.2, MPFR version 3.1.0, MPC version 0.9

GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096

GNU Fortran (GCC) version 4.8.0 20130302 (experimental) [trunk revision 196403]

(mingw32)

compiled by GNU C version 4.8.0 20130302 (experimental) [trunk revision

196403], GMP version 5.0.2, MPFR version 3.1.0, MPC version 0.9

GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096

f951.exe: internal compiler error: Segmentation fault

libbacktrace could not find executable to open

Please submit a full bug report,

with preprocessed source if appropriate.

See  for instructions.

[Bug fortran/56818] [meta-bug] fortran-dev bugs

[dominique.pelletier at polymtl dot ca]

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



--- Comment #2 from Dominique Pelletier  
2013-04-02 19:04:49 UTC ---

Created attachment 29779

  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=29779

modules from metcalf's modern fortran explainde



DP@P-DP /cygdrive/c/users/dp/Desktop/metcalf

$ gfortran -v -c bug_report.f03

Using built-in specs.

COLLECT_GCC=C:\Program Files (x86)\gfortran\bin\gfortran.exe

Target: mingw32

Configured with: ../gcc-trunk/configure --prefix=/mingw

--enable-languages=c,fortran,lto --with-gmp=/home/brad/gfortran/dependencies

--disable-werror --enable-threads --enable-nls --build=i586-pc-mingw32

--enable-libgomp --enable-shared --disable-win32-registry --with-dwarf2

--disable-sjlj-exceptions --enable-lto --build=mingw32

--enable-version-specific-runtime-libs

Thread model: win32

gcc version 4.8.0 20130302 (experimental) [trunk revision 196403] (GCC)

COLLECT_GCC_OPTIONS='-v' '-c' '-mtune=i386' '-march=i386'

 c:/program files (x86)/gfortran/bin/../libexec/gcc/mingw32/4.8.0/f951.exe

bug_report.f03 -quiet -dumpbase bug_report.f03 -mtune=i386 -march=i386 -auxbase

bug_report -version -fintrinsic-modules-path c:/program files

(x86)/gfortran/bin/../lib/gcc/mingw32/4.8.0/finclude -o

C:\cygwin\tmp\cc7RQyBk.s

GNU Fortran (GCC) version 4.8.0 20130302 (experimental) [trunk revision 196403]

(mingw32)

compiled by GNU C version 4.8.0 20130302 (experimental) [trunk revision

196403], GMP version 5.0.2, MPFR version 3.1.0, MPC version 0.9

GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096

GNU Fortran (GCC) version 4.8.0 20130302 (experimental) [trunk revision 196403]

(mingw32)

compiled by GNU C version 4.8.0 20130302 (experimental) [trunk revision

196403], GMP version 5.0.2, MPFR version 3.1.0, MPC version 0.9

GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096

f951.exe: internal compiler error: Segmentation fault

libbacktrace could not find executable to open

Please submit a full bug report,

with preprocessed source if appropriate.

See  for instructions.

[Bug c/51628] __attribute__((packed)) is unsafe in some cases

[peter at axium dot co.nz]

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



--- Comment #18 from incrediball  2013-04-02 20:21:06 
UTC ---

Not sure if I can agree with (or understand) this comment. If we use my example

of the address of an int in a packed structure being assigned to an int* then

one could argue that there is a kind of implicit cast happening. The pointer is

to an integer WITH the default alignment which would be 4 on the ARM system I

work with. The int in the struct has an alignment of 1 and so the two types

need to be regarded as being incompatible and there should be an unconditional

warning or at least -Wcast-align should enable such a warning.



I don't know what BLKmode is but if you're speaking of making an int* type

generally able to access the int regardless of its alignment, I think this is

the wrong way to go because code size will explode and efficiency will go out

the window. However if the int* would be declared with some special attribute

then, sure, generate whatever code that is necessary to access the int and the

above mentioned warning can be suppressed in this case (wouldn't the code

generated be much the same code that is used to directly access the int in the

packed struct anyway?) However this would be the second (optional) step, the

first thing is that the compiler needs to emit a warning explaining that the

code that it is generating is broken.

[Bug debug/56805] DW_TAG_typedef missing when -fdebug-types-section is used (and -fno-eliminate-unused-debug-types)

[ccoutant at gcc dot gnu.org]

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



--- Comment #4 from Cary Coutant  2013-04-02 
20:34:57 UTC ---

In GCC 4.6, type sections were the default for -gdwarf-4, but -gdwarf-2 was

still the default for 4.6, I think. If you explicitly ask for -gdwarf-4, you

can also add -gstrict-dwarf and it will not generate the type sections. The

-fdebug-types-section flag was added in 4.7 when -gdwarf-4 was made the

default.



So if all you need is DWARF-4 with GCC 4.6 and -fno-eliminate-unused-types, but

you don't need type sections, just add -gstrict-dwarf.

[Bug debug/56805] DW_TAG_typedef missing when -fdebug-types-section is used (and -fno-eliminate-unused-debug-types)

[ccoutant at gcc dot gnu.org]

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



Cary Coutant  changed:



   What|Removed |Added



 Status|UNCONFIRMED |ASSIGNED

   Last reconfirmed||2013-04-02

 AssignedTo|unassigned at gcc dot   |ccoutant at gcc dot gnu.org

   |gnu.org |

 Ever Confirmed|0   |1

[Bug fortran/56816] ICE in delete_root

[tkoenig at gcc dot gnu.org]

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



Thomas Koenig  changed:



   What|Removed |Added



 CC||mikael at gcc dot gnu.org,

   ||tkoenig at gcc dot gnu.org

Summary|f951.exe internal compiler  |ICE in delete_root

   |error. segmentation fault   |



--- Comment #5 from Thomas Koenig  2013-04-02 
20:41:03 UTC ---

The attachment at



http://gcc.gnu.org/bugzilla/attachment.cgi?id=29779



should really go to this bug.



The traceback (see below) makes me suspect



http://gcc.gnu.org/ml/gcc-cvs/2013-03/msg00054.html



Mikael, any idea?



Program received signal SIGSEGV, Segmentation fault.

0x0050005b in delete_root (t=0x165ac30) at

../../trunk/gcc/fortran/bbt.c:150

150   if (t->left->priority > t->right->priority)

(gdb) bt

#0  0x0050005b in delete_root (t=0x165ac30) at

../../trunk/gcc/fortran/bbt.c:150

#1  0x00500104 in delete_treap (old=old@entry=0x7fffd650,

t=, compare=compare@entry=

0x593140 ) at

../../trunk/gcc/fortran/bbt.c:185

#2  0x005000e9 in delete_treap (old=old@entry=0x7fffd650,

t=0x771ef678 , 

compare=compare@entry=0x593140 ) at

../../trunk/gcc/fortran/bbt.c:183

#3  0x005000e9 in delete_treap (old=old@entry=0x7fffd650,

t=0x165b8e0, 

compare=compare@entry=0x593140 ) at

../../trunk/gcc/fortran/bbt.c:183

#4  0x005000e9 in delete_treap (old=0x7fffd650, t=0x1656cd0,

compare=0x593140 )

at ../../trunk/gcc/fortran/bbt.c:183

#5  0x0050023f in gfc_delete_bbt (root=0x165ac40, old=,

compare=) at ../../trunk/gcc/fortran/bbt.c:197

#6  0x00595e88 in gfc_delete_symtree (root=0x165ac40,

name=0x771ef678  "\300$h\001")

at ../../trunk/gcc/fortran/symbol.c:2403

#7  0x005971ef in gfc_restore_last_undo_checkpoint () at

../../trunk/gcc/fortran/symbol.c:3123

#8  0x005623fb in reject_statement () at

../../trunk/gcc/fortran/parse.c:1745

#9  0x0056252d in match_word (subr=,

old_locus=old_locus@entry=0x7fffd760, str=0x0)

at ../../trunk/gcc/fortran/parse.c:70

#10 0x00562efc in match_word (old_locus=0x7fffd760, subr=, str=0x0) at ../../trunk/gcc/fortran/parse.c:366

#11 decode_statement () at ../../trunk/gcc/fortran/parse.c:366

#12 0x00564255 in next_free () at ../../trunk/gcc/fortran/parse.c:777

#13 next_statement () at ../../trunk/gcc/fortran/parse.c:970

#14 0x0056514d in parse_spec (st=, st@entry=ST_NONE) at

../../trunk/gcc/fortran/parse.c:2738

#15 0x00567149 in parse_progunit (st=st@entry=ST_NONE) at

../../trunk/gcc/fortran/parse.c:4118

#16 0x005674d1 in parse_contained (module=module@entry=1) at

../../trunk/gcc/fortran/parse.c:4057

#17 0x0056857a in parse_module () at

../../trunk/gcc/fortran/parse.c:4316

#18 gfc_parse_file () at ../../trunk/gcc/fortran/parse.c:4582

#19 0x005a40b6 in gfc_be_parse_file () at

../../trunk/gcc/fortran/f95-lang.c:189

#20 0x0094eca6 in compile_file () at ../../trunk/gcc/toplev.c:543

#21 0x00950b08 in do_compile () at ../../trunk/gcc/toplev.c:1864

#22 toplev_main (argc=2, argv=0x7fffdc08) at ../../trunk/gcc/toplev.c:1940

#23 0x76e71455 in __libc_start_main () from /lib64/libc.so.6

#24 0x004f9591 in _start () at ../sysdeps/x86_64/elf/start.S:113

[Bug c++/56819] New: [4.7/4.8/4.9 Regression] ICE: SIGSEGV in int_cst_value (tree.h:4013) with -fcompare-debug

[zsojka at seznam dot cz]

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



 Bug #: 56819

   Summary: [4.7/4.8/4.9 Regression] ICE: SIGSEGV in int_cst_value

(tree.h:4013) with -fcompare-debug

Classification: Unclassified

   Product: gcc

   Version: 4.8.0

Status: UNCONFIRMED

  Severity: normal

  Priority: P3

 Component: c++

AssignedTo: unassig...@gcc.gnu.org

ReportedBy: zso...@seznam.cz





Created attachment 29780

  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=29780

reduced testcase



This ICE happens quite often when running the testsuite with -fcompare-debug



Compiler output:

$ gcc -fcompare-debug testcase.C -wrapper

valgrind,-q,--num-callers=40,--track-origins=yes

==26928== Invalid read of size 2

==26928==at 0xDC0984: int_cst_value(tree_node const*) (tree.h:4013)

==26928==by 0x67D124: get_non_default_template_args_count(tree_node*, int)

(error.c:181)

==26928==by 0x685548: dump_template_argument_list(tree_node*, int)

(error.c:190)

==26928==by 0x67F24F: dump_decl(tree_node*, int) (error.c:1135)

==26928==by 0x68590A: dump_template_parms(tree_node*, int, int)

(error.c:1647)

==26928==by 0x685C0A: dump_typename(tree_node*, int) (error.c:569)

==26928==by 0x68590A: dump_template_parms(tree_node*, int, int)

(error.c:1647)

==26928==by 0x67E2F5: dump_type_prefix(tree_node*, int) (error.c:783)

==26928==by 0x68841B: dump_function_decl(tree_node*, int) (error.c:1406)

==26928==by 0x689D60: decl_as_string(tree_node*, int) (error.c:2613)

==26928==by 0x730E22: cxx_printable_name_internal(tree_node*, int, bool)

(tree.c:1879)

==26928==by 0xC5BE38: dump_function_header(_IO_FILE*, tree_node*, int)

(tree-pretty-print.c:3138)

==26928==by 0x943DFF: rest_of_clean_state() (final.c:4456)

==26928==by 0xAE2457: execute_one_pass(opt_pass*) (passes.c:2330)

==26928==by 0xAE2864: execute_pass_list(opt_pass*) (passes.c:2378)

==26928==by 0x8650B1: expand_function(cgraph_node*) (cgraphunit.c:1640)

==26928==by 0x86724D: compile() (cgraphunit.c:1833)

==26928==by 0x867509: finalize_compilation_unit() (cgraphunit.c:2119)

==26928==by 0x67C59E: cp_write_global_declarations() (decl2.c:4312)

==26928==by 0xBC9A1C: compile_file() (toplev.c:557)

==26928==by 0xBCB837: toplev_main(int, char**) (toplev.c:1864)

==26928==by 0x5A3C60C: (below main) (in /lib64/libc-2.15.so)

==26928==  Address 0x0 is not stack'd, malloc'd or (recently) free'd

==26928== 

==26928== 

==26928== Process terminating with default action of signal 11 (SIGSEGV)

==26928==  Access not within mapped region at address 0x0

==26928==at 0xDC0984: int_cst_value(tree_node const*) (tree.h:4013)

==26928==by 0x67D124: get_non_default_template_args_count(tree_node*, int)

(error.c:181)

==26928==by 0x685548: dump_template_argument_list(tree_node*, int)

(error.c:190)

==26928==by 0x67F24F: dump_decl(tree_node*, int) (error.c:1135)

==26928==by 0x68590A: dump_template_parms(tree_node*, int, int)

(error.c:1647)

==26928==by 0x685C0A: dump_typename(tree_node*, int) (error.c:569)

==26928==by 0x68590A: dump_template_parms(tree_node*, int, int)

(error.c:1647)

==26928==by 0x67E2F5: dump_type_prefix(tree_node*, int) (error.c:783)

==26928==by 0x68841B: dump_function_decl(tree_node*, int) (error.c:1406)

==26928==by 0x689DB9: decl_as_string_translate(tree_node*, int)

(error.c:2621)

==26928==by 0x730E22: cxx_printable_name_internal(tree_node*, int, bool)

(tree.c:1879)

==26928==by 0x6892AA: cp_diagnostic_starter(diagnostic_context*,

diagnostic_info*) (error.c:2959)

==26928==by 0x13505D2: diagnostic_report_diagnostic(diagnostic_context*,

diagnostic_info*) (diagnostic.c:759)

==26928==by 0x135141F: internal_error(char const*, ...) (diagnostic.c:1097)

==26928==by 0xBC99AF: crash_signal(int) (toplev.c:332)

==26928==by 0x5A4FC4F: ??? (in /lib64/libc-2.15.so)

==26928==by 0xDC0983: int_cst_value(tree_node const*) (tree.c:10247)

==26928==by 0x6336C07: ???

==26928==by 0x67D124: get_non_default_template_args_count(tree_node*, int)

(error.c:181)

==26928==by 0x685548: dump_template_argument_list(tree_node*, int)

(error.c:190)

==26928==by 0x67F24F: dump_decl(tree_node*, int) (error.c:1135)

==26928==by 0x68590A: dump_template_parms(tree_node*, int, int)

(error.c:1647)

==26928==by 0x685C0A: dump_typename(tree_node*, int) (error.c:569)

==26928==by 0x68590A: dump_template_parms(tree_node*, int, int)

(error.c:1647)

==26928==by 0x67E2F5: dump_type_prefix(tree_node*, int) (error.c:783)

==26928==by 0x68841B: dump_function_decl(tree_node*, int) (error.c:1406)

==26928==by 0x689D60: decl_as_string(tree_node*, int) (error.c:2613)

==26928==by 0x730E22: cxx_printable_name_internal(tree_node*, int, bool)

(tree.c:1879)

==26928==by 0xC5BE38: dump_function_he

[Bug c++/34949] Dead code in empty destructors.

[jason at gcc dot gnu.org]

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



Jason Merrill  changed:



   What|Removed |Added



 Status|NEW |RESOLVED

 CC||jason at gcc dot gnu.org

 Resolution||FIXED

   Target Milestone|--- |4.9.0



--- Comment #18 from Jason Merrill  2013-04-02 
21:10:55 UTC ---

Fixed for 4.9.

[Bug c++/56820] New: elaborated-type-specifier friend incorrectly looked up beyond innermost enclosing namespace

[wd11 at leicester dot ac.uk]

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



 Bug #: 56820

   Summary: elaborated-type-specifier friend incorrectly looked up

beyond innermost enclosing namespace

Classification: Unclassified

   Product: gcc

   Version: unknown

Status: UNCONFIRMED

  Severity: minor

  Priority: P3

 Component: c++

AssignedTo: unassig...@gcc.gnu.org

ReportedBy: w...@leicester.ac.uk





Created attachment 29781

  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=29781

errorneous C++ source which compiles



gcc (4.7 & 4.8) using -std=c++11 incorrectly looks up unqualified template

friends (not template-id) outside of the innermost enclosing namespace.

According to 7.3.1.2, 



"If the name in a friend declaration is neither qualified nor a template-id and

the declaration is a function or an elaborated-type-specifier, the lookup to

determine whether the entity has been previously declared shall not consider

any scopes outside the innermost enclosing namespace."



For example, in this simple code



namespace outer {

  template class A;

  namespace details {

template class B

{

  template friend class A;

};

  }

}



template class outer::details::B must not befriend (but does to with gcc)

template class outer::A, because the latter is not member of the innermost

inclosing namespace. In order to befriend outer::A, the friend declaration

would need to be qualified, i.e. template friend class outer::A;



---



I attach a simple test program which triggers the error: it compiles although

it shouldn't. output from g++ -v:



Using built-in specs.

COLLECT_GCC=/opt/local/bin/g++-mp-4.8

COLLECT_LTO_WRAPPER=/opt/local/libexec/gcc/x86_64-apple-darwin12/4.8.0/lto-wrapper

Target: x86_64-apple-darwin12

Configured with: ../gcc-4.8-20130321/configure --prefix=/opt/local

--build=x86_64-apple-darwin12

--enable-languages=c,c++,objc,obj-c++,fortran,java

--libdir=/opt/local/lib/gcc48 --includedir=/opt/local/include/gcc48

--infodir=/opt/local/share/info --mandir=/opt/local/share/man

--datarootdir=/opt/local/share/gcc-4.8 --with-local-prefix=/opt/local

--with-system-zlib --disable-nls --program-suffix=-mp-4.8

--with-gxx-include-dir=/opt/local/include/gcc48/c++/ --with-gmp=/opt/local

--with-mpfr=/opt/local --with-mpc=/opt/local --with-ppl=/opt/local

--with-cloog=/opt/local --enable-cloog-backend=isl

--disable-cloog-version-check --enable-stage1-checking --disable-multilib

--enable-lto --enable-libstdcxx-time --with-as=/opt/local/bin/as

--with-ld=/opt/local/bin/ld --with-ar=/opt/local/bin/ar

--with-bugurl=https://trac.macports.org/newticket --with-pkgversion='MacPorts

gcc48 4.8-20130321_0'

Thread model: posix

gcc version 4.8.0 20130321 (prerelease) (MacPorts gcc48 4.8-20130321_0) 



compilation command line (on max OS 10.8):

g++ -std=c++11 -Wextra -Wall -pedantic simple_test.cc



output: working executable writing

  a.foo(4) = 120

to stderr.

[Bug c++/50243] vtable for pure abstract class (interface) shouldn't be emitted

[jason at gcc dot gnu.org]

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



--- Comment #4 from Jason Merrill  2013-04-02 
21:19:18 UTC ---

Created attachment 29782

  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=29782

possible patch



The patches we checked in today for 34949 almost fix this bug as well, but not

quite; the vtable pointer assignment remains in the exception handler, because

optimize_clobbers in tree-eh.c is removing the clobber before it can be used to

optimize away the assignment.



This patch fixes that by skipping MEM_REF clobbers, but I suspect this isn't

really the right way to fix the issue.  Jakub?

[Bug debug/56805] DW_TAG_typedef missing when -fdebug-types-section is used (and -fno-eliminate-unused-debug-types)

[jan.sm...@alcatel-lucent.com]

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



--- Comment #5 from Jan Smets  2013-04-02 
21:28:37 UTC ---

-gstrict-dwarf does not disable type sections in GCC 4.6, the result is

unchanged. With 4.8 the behaviour is what you described. 



Is it really that much trouble to add a DW_TAG_typedef to the .debug_type

entry, regardless of -fno-eliminate-unused-types ?  Without it the debug entry

is incomplete, imho. I would really appreciate it. Thanks.

[Bug c++/56821] New: Unable to overload with references to 'this'.

[3dw4rd at verizon dot net]

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

 Bug #: 56821
   Summary: Unable to overload with references to 'this'.
Classification: Unclassified
   Product: gcc
   Version: 4.9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: 3dw...@verizon.net


Created attachment 29783
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=29783
This is a reference for 'this' toy.

Here is a busybox I wrote to play with the new feature in gcc-4.8.1 and trunk:

class Foo
{
public:
  Foo(int i) : _M_i(i) { }
  int bar() & { return _M_i /= 2; }
  int bar() const & { return _M_i; }
  int bar() && { return 2 * _M_i; }

private:
  int _M_i = 42;
};

int
main()
{
  Foo ph(333);
  ph.bar();

  const Foo ff(123);
  ff.bar();

  Foo(333).bar();
}


It looks to me reading the standard 8.3.5 that the three bar() methods should
be overloadable. I get a linker error though:


[ed@localhost ref_this]$ ../bin/bin/g++ -std=c++11 -o ref_this ref_this.cpp
/tmp/ccwPhzqr.s: Assembler messages:
/tmp/ccwPhzqr.s:73: Error: symbol `_ZN3Foo3barEv' is already defined


If I comment out 'int bar() const &' I am unable to resolve 'ff.bar()':


[ed@localhost ref_this]$ ../bin/bin/g++ -std=c++11 -o ref_this ref_this.cpp
ref_this.cpp: In function ‘int main()’:
ref_this.cpp:26:10: error: no matching function for call to ‘Foo::bar() const’
   ff.bar();
  ^
ref_this.cpp:26:10: note: candidates are:
ref_this.cpp:11:7: note: int Foo::bar() &
   int bar() & { return _M_i /= 2; }
   ^
ref_this.cpp:11:7: note:   no known conversion for implicit ‘this’ parameter
from ‘const Foo’ to ‘Foo&’
ref_this.cpp:13:7: note: int Foo::bar() &&
   int bar() && { return 2 * _M_i; }
   ^
ref_this.cpp:13:7: note:   no known conversion for implicit ‘this’ parameter
from ‘const Foo’ to ‘Foo&&’


I think this is gcc bug.

[Bug c++/56821] Unable to overload with references to 'this'.

[3dw4rd at verizon dot net]

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



Ed Smith-Rowland <3dw4rd at verizon dot net> changed:



   What|Removed |Added



 CC||jason at redhat dot com



--- Comment #1 from Ed Smith-Rowland <3dw4rd at verizon dot net> 2013-04-02 
21:57:22 UTC ---

Adding Jason.

[Bug tree-optimization/56799] Runfail after r197060+r197082.

[law at redhat dot com]

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



--- Comment #2 from Jeffrey A. Law  2013-04-02 22:18:39 
UTC ---

The test to verify we were doing a widening conversion was lost when I made the

tweaks Richi suggested.  I'll have a fix in the tree tomorrow.

[Bug lto/56804] lto1: internal compiler error: bytecode stream: found non-null terminated string

[vchou79 at gmail dot com]

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



--- Comment #6 from Vincent  2013-04-02 23:48:41 UTC 
---

bash-4.1$ cat test.res 

3

test.o 4

459 b27d8a298c16d07e PREVAILING_DEF_IRONLY_EXP check_vpx_codec_dec_init_ver

475 b27d8a298c16d07e PREVAILING_DEF_IRONLY_EXP main

463 b27d8a298c16d07e RESOLVED_IR vpx_codec_dec_init_ver

478 b27d8a298c16d07e RESOLVED_IR vpx_codec_control_

./libvpx.a@0x5b54 10

887 aa0ed57284137d70 PREVAILING_DEF_IRONLY_EXP vpx_codec_dec_init_ver

907 aa0ed57284137d70 PREVAILING_DEF_IRONLY_EXP vpx_codec_peek_stream_info

919 aa0ed57284137d70 PREVAILING_DEF_IRONLY_EXP vpx_codec_get_stream_info

927 aa0ed57284137d70 PREVAILING_DEF_IRONLY_EXP vpx_codec_decode

942 aa0ed57284137d70 PREVAILING_DEF_IRONLY_EXP vpx_codec_get_frame

951 aa0ed57284137d70 PREVAILING_DEF_IRONLY_EXP vpx_codec_register_put_frame_cb

962 aa0ed57284137d70 PREVAILING_DEF_IRONLY_EXP vpx_codec_register_put_slice_cb

972 aa0ed57284137d70 PREVAILING_DEF_IRONLY_EXP vpx_codec_get_mem_map

983 aa0ed57284137d70 PREVAILING_DEF_IRONLY_EXP vpx_codec_set_mem_map

994 aa0ed57284137d70 RESOLVED_IR vpx_codec_destroy

./libvpx.a@0x11d60 10

873 3ff73b4c7c71e571 PREVAILING_DEF_IRONLY_EXP vpx_codec_version

877 3ff73b4c7c71e571 PREVAILING_DEF_IRONLY_EXP vpx_codec_version_str

881 3ff73b4c7c71e571 PREVAILING_DEF_IRONLY_EXP vpx_codec_version_extra_str

884 3ff73b4c7c71e571 PREVAILING_DEF_IRONLY_EXP vpx_codec_iface_name

890 3ff73b4c7c71e571 PREVAILING_DEF_IRONLY_EXP vpx_codec_err_to_string

900 3ff73b4c7c71e571 PREVAILING_DEF_IRONLY_EXP vpx_codec_error

907 3ff73b4c7c71e571 PREVAILING_DEF_IRONLY_EXP vpx_codec_error_detail

911 3ff73b4c7c71e571 PREVAILING_DEF_IRONLY_EXP vpx_codec_destroy

917 3ff73b4c7c71e571 PREVAILING_DEF_IRONLY_EXP vpx_codec_get_caps

923 3ff73b4c7c71e571 PREVAILING_DEF_IRONLY_EXP vpx_codec_control_





bash-4.1$ nm test.o

 b .bss

 d .data

 r .gnu.lto_.decls.b27d8a298c16d07e

 r .gnu.lto_.inline.b27d8a298c16d07e

 r .gnu.lto_.opts

 r .gnu.lto_.refs.b27d8a298c16d07e

 r .gnu.lto_.symbol_nodes.b27d8a298c16d07e

 r .gnu.lto_.symtab.b27d8a298c16d07e

 r .gnu.lto_check_vpx_codec_dec_init_ver.b27d8a298c16d07e

 r .gnu.lto_main.b27d8a298c16d07e

 r

.gnu.lto_vpx_codec_control_VP8D_GET_FRAME_CORRUPTED.b27d8a298c16d07e

 r

.gnu.lto_vpx_codec_control_VP8D_GET_LAST_REF_UPDATES.b27d8a298c16d07e

 r

.gnu.lto_vpx_codec_control_VP8D_GET_LAST_REF_USED.b27d8a298c16d07e

 r

.gnu.lto_vpx_codec_control_VP8_COPY_REFERENCE.b27d8a298c16d07e

 r

.gnu.lto_vpx_codec_control_VP8_SET_DBG_COLOR_B_MODES.b27d8a298c16d07e

 r

.gnu.lto_vpx_codec_control_VP8_SET_DBG_COLOR_MB_MODES.b27d8a298c16d07e

 r

.gnu.lto_vpx_codec_control_VP8_SET_DBG_COLOR_REF_FRAME.b27d8a298c16d07e

 r

.gnu.lto_vpx_codec_control_VP8_SET_DBG_DISPLAY_MV.b27d8a298c16d07e

 r .gnu.lto_vpx_codec_control_VP8_SET_POSTPROC.b27d8a298c16d07e

 r

.gnu.lto_vpx_codec_control_VP8_SET_REFERENCE.b27d8a298c16d07e

 p .pdata

 r .rdata$zzz

 t .text

 r .xdata

0001 C __gnu_lto_v1

 U __main

01c8 T check_vpx_codec_dec_init_ver

01d5 T main

 U vpx_codec_control_

016c t vpx_codec_control_VP8D_GET_FRAME_CORRUPTED

013e t vpx_codec_control_VP8D_GET_LAST_REF_UPDATES

019a t vpx_codec_control_VP8D_GET_LAST_REF_USED

002e t vpx_codec_control_VP8_COPY_REFERENCE

00e4 t vpx_codec_control_VP8_SET_DBG_COLOR_B_MODES

00b7 t vpx_codec_control_VP8_SET_DBG_COLOR_MB_MODES

008a t vpx_codec_control_VP8_SET_DBG_COLOR_REF_FRAME

0111 t vpx_codec_control_VP8_SET_DBG_DISPLAY_MV

005c t vpx_codec_control_VP8_SET_POSTPROC

 t vpx_codec_control_VP8_SET_REFERENCE

 U vpx_codec_dec_init_ver