[Bug ada/56909] [4.8 regression] s-atopri.adb:multiple undefined references on mingw32 --with-arch=i486

[ebotcazou at gcc dot gnu.org]

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



--- Comment #9 from Eric Botcazou  2013-04-14 
06:45:18 UTC ---

> On MinGW, GCC 4.7.x Ada built successfully with default (no -with-arch or

> -with-tune) configure.

> 

> GCC 4.8.0 s-atopri.* changes breaks same configure:

> 

> 1. with default (no -with-arch or -with-tune):

>   failed with five undefined reference (as the top of this ticket)



OK, I missed that, then configure with --build=i686-pc-mingw32.

[Bug c++/56951] New: Poor diagnostics for error: invalid abstract return type 'XXX'

[ppluzhnikov at google dot com]

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

 Bug #: 56951
   Summary: Poor diagnostics for error: invalid abstract return
type 'XXX'
Classification: Unclassified
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: ppluzhni...@google.com


Consider the following test case:

#include 

using std::vector;
using std::iterator_traits;

template  struct remove_pointer;
template  struct remove_pointer { typedef T type; };

template 
class iterator_ptr {
  typedef typename remove_pointer<
typename iterator_traits::value_type>::type value_type;
  value_type Get();
};

class Table;

class F {
  typedef iterator_ptr::iterator> iterator;
  iterator tables_begin() {}
};

class Table {
  virtual void Fn() = 0;
};


This code is accepted by gcc-4.7.x, rejected by current trunk with:

g++ -c tt.cc
tt.cc:13:14: error: invalid abstract return type ‘Table’
   value_type Get();
  ^
tt.cc:23:7: note:   because the following virtual functions are pure within
‘Table’:
 class Table {
   ^
tt.cc:24:16: note: virtual void Table::Fn()
   virtual void Fn() = 0;
^


I believe the code is in fact invalid.

Note that the error tells me the template line (13), but doesn't tell
what parameters this template was instantiated with, nor what triggered
the instantiation.

Compare to much better error produced when I move 'class Table'
definition ahead of F:


#include 

using std::vector;
using std::iterator_traits;

template  struct remove_pointer;
template  struct remove_pointer { typedef T type; };

template 
class iterator_ptr {
  typedef typename remove_pointer<
typename iterator_traits::value_type>::type value_type;
  value_type Get();
};

class Table {
  virtual void Fn() = 0;
};

class F {
  typedef iterator_ptr::iterator> iterator;
  iterator tables_begin() {}
};


g++ -c tt2.cc
tt2.cc: In instantiation of ‘class
iterator_ptr<__gnu_cxx::__normal_iterator > >’:
tt2.cc:22:27:   required from here
tt2.cc:13:14: error: invalid abstract return type ‘Table’
   value_type Get();
  ^
tt2.cc:16:7: note:   because the following virtual functions are pure within
‘Table’:
 class Table {
   ^
tt2.cc:17:16: note: virtual void Table::Fn()
   virtual void Fn() = 0;
^

[Bug ada/56909] [4.8 regression] s-atopri.adb:multiple undefined references on mingw32 --with-arch=i486

[pinskia at gcc dot gnu.org]

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



--- Comment #8 from Andrew Pinski  2013-04-14 
04:51:20 UTC ---

(In reply to comment #7)

> 3. with '--with-arch=i686':

>   build successfully (as comment 3). this may slow the compiler, and leave

> i384/i486 arch not be supported so we are looking for a better build 
> workaround

> or even better a fix from gcc/ada/libgnat.



I doubt i384/i486 are supported in any modern Windows OS; even 686 is

questionable too.

[Bug ada/56909] [4.8 regression] s-atopri.adb:multiple undefined references on mingw32 --with-arch=i486

[mail2arthur at gmail dot com]

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



--- Comment #7 from Arthur Zhang  2013-04-14 
04:12:35 UTC ---

clarification:



On MinGW, GCC 4.7.x Ada built successfully with default (no -with-arch or

-with-tune) configure.



GCC 4.8.0 s-atopri.* changes breaks same configure:



1. with default (no -with-arch or -with-tune):

  failed with five undefined reference (as the top of this ticket)



2. with '--with-arch=i486 --with-tune=i686':

  failed with two undefined reference (as comment 1)



3. with '--with-arch=i686':

  build successfully (as comment 3). this may slow the compiler, and leave

i384/i486 arch not be supported so we are looking for a better build workaround

or even better a fix from gcc/ada/libgnat.

[Bug debug/56950] compare-debug failure for gcc.dg/pr41345.c with fschedule-insns

[steven at gcc dot gnu.org]

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



Steven Bosscher  changed:



   What|Removed |Added



   Keywords||build, wrong-debug

 Status|UNCONFIRMED |NEW

   Last reconfirmed||2013-04-13

 CC||aoliva at gcc dot gnu.org,

   ||jakub at gcc dot gnu.org

 Ever Confirmed|0   |1



--- Comment #1 from Steven Bosscher  2013-04-13 
23:15:07 UTC ---

Breaks bootstrap with -fschedule-insn on i686.

[Bug debug/56950] New: compare-debug failure for gcc.dg/pr41345.c with fschedule-insns

[steven at gcc dot gnu.org]

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



 Bug #: 56950

   Summary: compare-debug failure for gcc.dg/pr41345.c with

fschedule-insns

Classification: Unclassified

   Product: gcc

   Version: 4.9.0

Status: UNCONFIRMED

  Severity: normal

  Priority: P3

 Component: debug

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

ReportedBy: ste...@gcc.gnu.org





$ cat pr41345.c 

/* PR bootstrap/41345 */

/* { dg-do compile } */

/* { dg-options "-O2 -g -fcompare-debug" } */

/* { dg-xfail-if "" { powerpc-ibm-aix* } { "*" } { "" } } */



void

foo (int *x)

{

  int a;

  for (a = 0; a < 2; a++)

if (x[a])

  goto lab;

  __builtin_unreachable ();

lab:;

}



$ ./xgcc -B. -S -O2 -g -fcompare-debug pr41345.c -fschedule-insns

xgcc: error: pr41345.c: -fcompare-debug failure (length)

$



The problem appears to be an extra NOTE_INSN_DELETED, inserted in

the sched1 pass:



@@ -42,8 +54,11 @@

 ;;  exit block uses 6 [bp] 7 [sp] 20 [frame]

 ;;  regs ever live

 ;;  ref usage  r0={1d} r1={1d} r2={1d} r4={1d} r5={1d} r6={1d,2u} r7={1d,2u}

r16={1d,1u} r20={1d,2u} r21={1d} r22={1d} r23={1d} r24={1d} r25={1d} r26={1d}

r27={1d} r28={1d} r37={1d} r38={1d}

-;;total ref usage 26{19d,7u,0e} in 0{0 regular + 0 call} insns.

+;;total ref usage 26{19d,7u,0e} in 1{1 regular + 0 call} insns.

 (note 1 0 4 NOTE_INSN_DELETED)

 (note 4 1 3 2 [bb 2] NOTE_INSN_BASIC_BLOCK)

-(note 3 4 10 2 NOTE_INSN_FUNCTION_BEG)

-(note 10 3 0 ("lab") NOTE_INSN_DELETED_LABEL 2)

+(note 3 4 7 2 NOTE_INSN_FUNCTION_BEG)

+(debug_insn 7 3 18 2 (var_location:SI a (const_int 0 [0])) -1

+ (nil))

+(note 18 7 14 NOTE_INSN_DELETED)

+(note 14 18 0 ("lab") NOTE_INSN_DELETED_LABEL 2)



The note 18 comes from haifa-sched.c:sched_extend_bb.

[Bug c++/56949] Internal compiler error

[paolo.carlini at oracle dot com]

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



Paolo Carlini  changed:



   What|Removed |Added



 Status|UNCONFIRMED |NEW

   Last reconfirmed||2013-04-13

 Ever Confirmed|0   |1

  Known to fail||4.8.0, 4.9.0



--- Comment #1 from Paolo Carlini  2013-04-13 
21:24:07 UTC ---

Confirmed. First blush, it seems related to PR52282 (I wanted to spend more

time on the latter, but got distracted).

[Bug fortran/56872] [4.8/4.9 Regression] Incorrect SUM evaluation, involving implied-do loop, with -ffrontend-optimize

[tkoenig at gcc dot gnu.org]

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



--- Comment #11 from Thomas Koenig  2013-04-13 
20:56:49 UTC ---

Created attachment 29869

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

Updated patch

[Bug other/56881] Miscompilation (optimisation failure?) causing NULL dereference and segfault at runtime

[mikpe at it dot uu.se]

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



--- Comment #7 from Mikael Pettersson  2013-04-13 
20:39:03 UTC ---

Started with Bernd Schmidt's "Optimize calls to functions that return one of

their arguments" patch in http://gcc.gnu.org/r187459, originally proposed in

.

[Bug c++/56949] New: Internal compiler error

[gessos.paul at yahoo dot gr]

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



 Bug #: 56949

   Summary: Internal compiler error

Classification: Unclassified

   Product: gcc

   Version: 4.8.0

Status: UNCONFIRMED

  Severity: normal

  Priority: P3

 Component: c++

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

ReportedBy: gessos.p...@yahoo.gr





Created attachment 29868

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

the source



Command Line:

-

g++ -std=c++11 2.cpp



Output:

---

2.cpp: In instantiation of 'struct MatrixRef':

2.cpp:61:24:   required from here

2.cpp:54:8: internal compiler error: in finish_decltype_type, at

cp/semantics.c:

5365

 struct MatrixRef : public row_vector_helper

^

Please submit a full bug report,

with preprocessed source if appropriate.

See  for instructions.



Version:



..

Target: x86_64-w64-mingw32

..

Thread model: win32

gcc version 4.8.0 (rubenvb-4.8.0)

[Bug target/56948] PPC V2DI ICE when loading zero into GPRs

[dje at gcc dot gnu.org]

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



David Edelsohn  changed:



   What|Removed |Added



   Target Milestone|--- |4.8.1

[Bug target/56948] PPC V2DI ICE when loading zero into GPRs

[dje at gcc dot gnu.org]

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



David Edelsohn  changed:



   What|Removed |Added



 Status|UNCONFIRMED |ASSIGNED

   Last reconfirmed||2013-04-13

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

   |gnu.org |

 Ever Confirmed|0   |1



--- Comment #1 from David Edelsohn  2013-04-13 19:26:21 
UTC ---

Created attachment 29867

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

Add V2DI alternative for const 0 in GPRs

[Bug target/56948] New: PPC V2DI ICE when loading zero into GPRs

[dje at gcc dot gnu.org]

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



 Bug #: 56948

   Summary: PPC V2DI ICE when loading zero into GPRs

Classification: Unclassified

   Product: gcc

   Version: 4.8.0

Status: UNCONFIRMED

  Severity: normal

  Priority: P3

 Component: target

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

ReportedBy: d...@gcc.gnu.org





error: insn does not satisfy its constraints:

(insn 1660 219 207 21 (set (reg:V2DI 9 9)

(const_vector:V2DI [

(const_int 0 [0])

(const_int 0 [0])

]))

/gsa/yktgsa-p4/06/gnu/aix/7.1/power/include/c++/4.8.1/bits/stl_vector.h:87 686

{*vsx_movv2di}

 (nil))

internal compiler error: in reload_cse_simplify_operands, at postreload.c:411

[Bug lto/54078] Bytemark 46% bigger binary with -flto

[wbrana at gmail dot com]

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



--- Comment #8 from wbrana  2013-04-13 17:59:47 UTC ---

lto/gold



-finline-limit=43

99960 bytes

NUMERIC SORT:  1471.2  :  37.73  :  12.39



-finline-limit=44

149136 bytes

NUMERIC SORT:  1705.2  :  43.73  :  14.36

[Bug other/56881] Miscompilation (optimisation failure?) causing NULL dereference and segfault at runtime

[mikpe at it dot uu.se]

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



Mikael Pettersson  changed:



   What|Removed |Added



 CC||mikpe at it dot uu.se



--- Comment #6 from Mikael Pettersson  2013-04-13 
17:53:30 UTC ---

Thanks for the complete test case.  I can reproduce the apparent wrong-code

(runtime SEGV) on x86_64-linux w/ glibc-2.15 with gcc 4.9-20130407 and

4.8-20130411, but not with 4.7-20130406 or 4.6-20130405.

[Bug lto/54078] Bytemark 46% bigger binary with -flto

[wbrana at gmail dot com]

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



--- Comment #7 from wbrana  2013-04-13 17:34:23 UTC ---

-fno-inline-functions makes same tests 12% or 6% slower with lto/gold



NUMERIC SORT:  1689.2  :  43.32  :  14.23

NUMERIC SORT:  1483.2  :  38.04  :  12.49



IDEA:9932  : 151.91  :  45.10

IDEA:9360  : 143.16  :  42.50

[Bug target/56940] internal compiler error: unrecognizable insn:

[pinskia at gcc dot gnu.org]

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



Andrew Pinski  changed:



   What|Removed |Added



 Status|UNCONFIRMED |RESOLVED

 Resolution||FIXED

   Target Milestone|--- |4.7.3



--- Comment #4 from Andrew Pinski  2013-04-13 
17:33:22 UTC ---

So fixed for 4.7.3.

[Bug lto/54078] Bytemark 46% bigger binary with -flto

[wbrana at gmail dot com]

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



--- Comment #6 from wbrana  2013-04-13 17:01:27 UTC ---

executable is smaller with lto when I add -fno-inline-functions 

95928 vs 93880

[Bug c/56946] assignment expression work wired

[jiez at gcc dot gnu.org]

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



--- Comment #4 from Jie Zhang  2013-04-13 16:50:19 UTC 
---

(In reply to comment #3)

> (In reply to comment #2)

> > You need to add -lm to your command line. 

> gcc -lm -Wall assignment.c

> 

> This is right?But it can't compile neither



gcc -Wall assignment.c -lm

[Bug lto/54078] Bytemark 46% bigger binary with -flto

[wbrana at gmail dot com]

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



--- Comment #5 from wbrana  2013-04-13 16:43:10 UTC ---

branch 4.9



without lto 

101462 bytes



with -flto -fwhole-program

157243 bytes - linker bfd

155488 bytes - linker gold



other CFLAGS = -O3 -g0 -march=corei7 -fomit-frame-pointer -funroll-loops

-ffast-math -fno-PIE -fno-exceptions -fno-stack-protector

[Bug c++/56947] New: [4.7.3 regression] Bogus 'XX' was not declared in this scope

[ppluzhnikov at google dot com]

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

 Bug #: 56947
   Summary: [4.7.3 regression] Bogus 'XX' was not declared in this
scope
Classification: Unclassified
   Product: gcc
   Version: 4.7.3
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: ppluzhni...@google.com


This is a recent gcc-4_7-branch regression.

The case builds with trunk (r197936), fails with 4.7 branch (r197941):


struct A
{
A (int);
};

template < typename >
void Fn ()
{
const int kCapacity = 0;
struct Q:A
{
Q ():A (kCapacity) { }
};
Q q;
}
template void Fn < int >();


$ trunk/bin/g++ -c t.cc && echo ok
ok

$ 4.7/bin/g++ -c t.cc
t.cc: In instantiation of ‘Fn()::Q::Q() [with  = int]’:
t.cc:14:7:   required from ‘void Fn() [with  = int]’
t.cc:16:26:   required from here
t.cc:12:26: error: ‘kCapacity’ was not declared in this scope

[Bug fortran/56929] [OOP] [F08] ICE on dummy argument child class with coarray inside parent

[damian at rouson dot net]

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



--- Comment #5 from Damian Rouson  2013-04-13 
15:53:51 UTC ---

Thanks for the amazingly fast response!  Possibly this sets a record: 11.5

hours from submitting the report to the application of a patch to the trunk. 

Any chance this patch can also be applied to the 4.8 branch?

[Bug driver/46501] Relocatable toolchains still search --prefix

[lrn1986 at gmail dot com]

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



LRN  changed:



   What|Removed |Added



 CC||lrn1986 at gmail dot com



--- Comment #5 from LRN  2013-04-13 15:31:21 UTC ---

A gcc toolchain built on W32 for W32 (using MSys shell and make to run the

buildsystem) also suffers from this. In all and any mingw builds (except for

TDM's, they are patched somehow) that are built with --prefix=/mingw, the

directory "/mingw/include" ends up in cpp_include_defaults list, and

"/mingw/lib" - in the list that -print-search-dirs outputs for libraries.



W32 interprets "/mingw" as "mingw subdirectory in the root directory of the

drive on which current working directory is", so having headers in

"c:/mingw/include", "d:/mingw/include", ... etc (and libraries in

"c:/mingw/lib", ... etc) was, and is, strongly advised against by all

gcc-for-w32 toolchain suppliers for _years_. Which likely means that this issue

is old.

[Bug rtl-optimization/52139] [4.5 Regression] ICE: in remove_insn, at emit-rtl.c:3960 with -O -fPIC -fno-tree-dominator-opts -fno-tree-fre

[steven at gcc dot gnu.org]

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



Steven Bosscher  changed:



   What|Removed |Added



 Status|REOPENED|NEW

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

   |gnu.org |



--- Comment #12 from Steven Bosscher  2013-04-13 
14:58:53 UTC ---

Created attachment 29866

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

Corrected fix



In cfglayout mode, header and footer insns should not be inserted in

the insn chain.



The real bug here turns out to be in cfg_layout_delete_block: It deletes

the basic block by re-attaching the header and footer to the insn chain

and uses rtl_delete_block to actually delete the basic block.  But at that

point, try_redirect_by_replacing_jump has already removed the tablejump

instruction, so get_last_bb_insn doesn't extend the basic block to include

the jump table data.  I will address that in a separate patch, but I'm not

sure yet how :-)

[Bug driver/46501] Relocatable toolchains still search --prefix

[nightstrike at gmail dot com]

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



nightstrike  changed:



   What|Removed |Added



   See Also||http://gcc.gnu.org/bugzilla

   ||/show_bug.cgi?id=17621,

   ||http://gcc.gnu.org/bugzilla

   ||/show_bug.cgi?id=35300



--- Comment #4 from nightstrike  2013-04-13 
14:51:32 UTC ---

Adding the two related bugs to See Also, and updating the last reconfirmed

date.

[Bug middle-end/52472] ICE: in convert_debug_memory_address, at cfgexpand.c:2491

[gjl at gcc dot gnu.org]

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



Georg-Johann Lay  changed:



   What|Removed |Added



 CC||Sergey.Belyashov at gmail

   ||dot com



--- Comment #8 from Georg-Johann Lay  2013-04-13 
14:33:19 UTC ---

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

[Bug target/56792] AVR, internal compiler error on build avr-libc

[gjl at gcc dot gnu.org]

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



Georg-Johann Lay  changed:



   What|Removed |Added



   Keywords||addr-space,

   ||ice-on-valid-code

 Target||avr

 Status|UNCONFIRMED |RESOLVED

 Resolution||DUPLICATE



--- Comment #4 from Georg-Johann Lay  2013-04-13 
14:33:19 UTC ---

Duplicate according to comment #3



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

[Bug c/56946] assignment expression work wired

[zhabgyuan1993 at gmail dot com]

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



--- Comment #3 from shia  2013-04-13 14:13:08 
UTC ---

(In reply to comment #2)

> You need to add -lm to your command line. 

gcc -lm -Wall assignment.c



This is right?But it can't compile neither

[Bug c/56946] assignment expression work wired

[jiez at gcc dot gnu.org]

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



Jie Zhang  changed:



   What|Removed |Added



 Status|UNCONFIRMED |RESOLVED

 CC||jiez at gcc dot gnu.org

 Resolution||INVALID



--- Comment #2 from Jie Zhang  2013-04-13 13:10:43 UTC 
---

You need to add -lm to your command line. cos(0) is OK because gcc optimizes it

away when compiling.

[Bug fortran/56945] internal compiler error: in lhd_set_decl_assembler_name, at langhooks.c:158

[burnus at gcc dot gnu.org]

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



Tobias Burnus  changed:



   What|Removed |Added



 Status|UNCONFIRMED |RESOLVED

 CC||burnus at gcc dot gnu.org

  Known to work||4.8.0, 4.9.0

 Resolution||FIXED

  Known to fail||4.6.3, 4.7.3



--- Comment #4 from Tobias Burnus  2013-04-13 
12:45:15 UTC ---

(In reply to comment #2)

> AFAICT the code compiles with gfortran 4.8.0, but not with 4.7.3.



Yes, there were lots of bug fixes for "character(len=:)" around mid-2012;

please update to 4.8 (4.8.0 has been recently released) or try the current

developer version 4.9.



Unofficial builds of GCC can be found at

http://gcc.gnu.org/wiki/GFortranBinaries





As it is no regression and as it works in both the latest release and in the

development version, I close this bug now.  See bug 45170 comment 39 for the

outstanding issues.  (Using "len=:" as component of a derived type will likely

be supported in 4.9; maybe in a month?)





In any case: Thanks for the report! And sorry that it doesn't work with

4.6/4.7.



-> Close as FIXED (in 4.8/4.9).

[Bug fortran/56945] internal compiler error: in lhd_set_decl_assembler_name, at langhooks.c:158

[janus at gcc dot gnu.org]

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



janus at gcc dot gnu.org changed:



   What|Removed |Added



 CC||janus at gcc dot gnu.org



--- Comment #3 from janus at gcc dot gnu.org 2013-04-13 12:37:17 UTC ---

With 4.5 and earlier I get:



character(len=:), allocatable :: errtxt

  1

Error: Syntax error in CHARACTER declaration at (1)





4.6 and 4.7 both give the error in the subject line. 4.8 and trunk accept it

without error.

[Bug fortran/56765] [OOP] compilation errors/ICE with polymorphic array

[janus at gcc dot gnu.org]

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



--- Comment #5 from janus at gcc dot gnu.org 2013-04-13 12:31:42 UTC ---

Note: The patch in comment 3 regtests cleanly.

[Bug target/48576] wrong code when accessing variables in a large stack frame

[mikpe at it dot uu.se]

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



--- Comment #7 from Mikael Pettersson  2013-04-13 
12:26:24 UTC ---

This bug still occurs with gcc 4.9-20130407, 4.8-20130411, and 4.7-20130406.

[Bug c/56946] assignment expression work wired

[zhabgyuan1993 at gmail dot com]

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



--- Comment #1 from shia  2013-04-13 12:16:47 
UTC ---

Created attachment 29865

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

.i

[Bug c++/51577] dependent name lookup finds operator in global namespace

[paolo.carlini at oracle dot com]

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



--- Comment #7 from Paolo Carlini  2013-04-13 
12:10:58 UTC ---

Essentially in gcc-english at least, wrong code means wrong assembly code, what

the back end emits. Normally for wrong C++ code we say invalid code, hard to

confuse.

[Bug fortran/56945] internal compiler error: in lhd_set_decl_assembler_name, at langhooks.c:158

[dominiq at lps dot ens.fr]

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



--- Comment #2 from Dominique d'Humieres  2013-04-13 
12:10:21 UTC ---

AFAICT the code compiles with gfortran 4.8.0, but not with 4.7.3.

[Bug c/56946] New: assignment expression work wired

[zhabgyuan1993 at gmail dot com]

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



 Bug #: 56946

   Summary: assignment expression work wired

Classification: Unclassified

   Product: gcc

   Version: 4.7.2

Status: UNCONFIRMED

  Severity: minor

  Priority: P3

 Component: c

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

ReportedBy: zhabgyuan1...@gmail.com





Source code 

--



#include

#include

int main(int argc,char *argv[])

{

int a,b;

b = ({int cos(i){return 0;};a = 0;cos(a);});

printf("%d\n%d\n",a,b);

b = cos(a);

printf("%d\n%d\n",a,b);

return 0;

}





It can't compile

--

gcc -Wall assignment.c

/tmp/ccKTyKpY.o: In function `main':

assignment.c:(.text+0x53): undefined reference to `cos'

collect2: error: ld returned 1 exit status



However this one will work only changing `b = cos(0);`

--

#include

#include

int main(int argc,char *argv[])

{

int a,b;

b = ({int cos(i){return 0;};a = 0;cos(a);});

printf("%d\n%d\n",a,b);

//only this line diffrent

b = cos(0);

printf("%d\n%d\n",a,b);

return 0;

}

[Bug c++/51577] dependent name lookup finds operator in global namespace

[daniel.kruegler at googlemail dot com]

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

--- Comment #6 from Daniel Krügler  
2013-04-13 11:55:36 UTC ---
(In reply to comment #5)
> and G++ calls the global one, returning the wrong result, so it's wrong-code
OK, I misunderstood the meaning of "wrong-code": I thought that was intended to
mean a code that should not compile. I see now that wrong-code is a specific
keyword here (never used it before).

[Bug c++/51577] dependent name lookup finds operator in global namespace

[redi at gcc dot gnu.org]

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



--- Comment #5 from Jonathan Wakely  2013-04-13 
11:52:51 UTC ---

(In reply to comment #4)

> (In reply to comment #3)

> > The example in PR 56943 gives a wrong-code example

> 

> Could you explain why? It looks valid to me. According to my understanding, 
> the

> free operator+ overload in global namespace is no valid candidate, but the

> member operator+ of N::A is one.



and G++ calls the global one, returning the wrong result, so it's wrong-code

[Bug fortran/56945] internal compiler error: in lhd_set_decl_assembler_name, at langhooks.c:158

[jszhao at yeah dot net]

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



--- Comment #1 from Jinsong Zhao  2013-04-13 11:42:53 
UTC ---

I also test it using gfortran 4.7.2, it gives the same error.

[Bug fortran/56945] New: internal compiler error: in lhd_set_decl_assembler_name, at langhooks.c:158

[jszhao at yeah dot net]

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



 Bug #: 56945

   Summary: internal compiler error: in

lhd_set_decl_assembler_name, at langhooks.c:158

Classification: Unclassified

   Product: gcc

   Version: 4.6.3

Status: UNCONFIRMED

  Severity: normal

  Priority: P3

 Component: fortran

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

ReportedBy: jsz...@yeah.net





when compile the following code, gfortran give the above error message.



module errmsg

character(len=:), allocatable :: errtxt

end module errmsg



gfortran -c -Wall -Wextra errmsg.f90

f951.exe: internal compiler error: in lhd_set_decl_assembler_name, at

langhooks.

c:158

Please submit a full bug report,

with preprocessed source if appropriate.

See  for instructions.

[Bug c++/51577] dependent name lookup finds operator in global namespace

[daniel.kruegler at googlemail dot com]

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

--- Comment #4 from Daniel Krügler  
2013-04-13 11:26:25 UTC ---
(In reply to comment #3)
> The example in PR 56943 gives a wrong-code example

Could you explain why? It looks valid to me. According to my understanding, the
free operator+ overload in global namespace is no valid candidate, but the
member operator+ of N::A is one.

[Bug c++/51577] dependent name lookup finds operator in global namespace

[redi at gcc dot gnu.org]

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



Jonathan Wakely  changed:



   What|Removed |Added



   Keywords||wrong-code

 Status|UNCONFIRMED |NEW

   Last reconfirmed||2013-04-13

 Ever Confirmed|0   |1



--- Comment #3 from Jonathan Wakely  2013-04-13 
11:17:55 UTC ---

The example in PR 56943 gives a wrong-code example

[Bug fortran/44978] extended derived types are resolved more than once

[janus at gcc dot gnu.org]

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



--- Comment #1 from janus at gcc dot gnu.org 2013-04-13 11:15:01 UTC ---

Similar problems of multiple error messages occur also with non-extended types

which have type-bound procedures. Reduced example from PR 55959 comment 4:



module pdfs



type :: pdf_point

contains

procedure :: pdf_point_getx

end type



contains



function pdf_point_getx (this)

class(pdf_point), intent(in) :: this

real, dimension(x) :: pdf_point_getx

end function



end module







The following error message occurs three times here:





real, dimension(x) :: pdf_point_getx

1

Error: Expression at (1) must be of INTEGER type, found REAL

[Bug c++/56936] gcc don't show error when accessing to missing member of current instantiation

[vanyacpp at gmail dot com]

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



--- Comment #4 from Ivan Sorokin  2013-04-13 
11:06:35 UTC ---

(In reply to comment #3)

> [temp.res]/8 "If no valid specialization can be generated for a template, and

> that template is not instantiated, the template is ill-formed, no diagnostic

> required."

> 

> No diagnostic required.



Yes, but diagnostic would be very helpful.



Moreover clang prints error on this code.

[Bug fortran/55959] [OOP] ICE in in gfc_simplify_expr, at fortran/expr.c:1920

[janus at gcc dot gnu.org]

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



janus at gcc dot gnu.org changed:



   What|Removed |Added



 Status|NEW |RESOLVED

 Resolution||FIXED

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

   |gnu.org |



--- Comment #6 from janus at gcc dot gnu.org 2013-04-13 11:06:15 UTC ---

r197943 fixes the original ICE and makes comment 1 work as expected on 4.9

trunk:



gcc.gnu.org/viewcvs/gcc?view=revision&revision=197943





Author: janus

Date: Sat Apr 13 10:52:31 2013 UTC

Changed paths: 4

Log Message: 



2013-04-13  Janus Weil  



PR fortran/55959

* expr.c (gfc_simplify_expr): Branch is not unreachable.





2013-04-13  Janus Weil  



PR fortran/55959

* gfortran.dg/typebound_proc_29.f03: New.







Since the remaining issue of comment 0 is tracked by PR56939, I think we can

close this one (apart from the duplicate error messages mentioned in comment 4,

but similar problems are tracked by PR 44978, where I will leave a note about

the test case here).

[Bug target/56940] internal compiler error: unrecognizable insn:

[mikpe at it dot uu.se]

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



--- Comment #3 from Mikael Pettersson  2013-04-13 
10:55:21 UTC ---

I can reproduce the ICE with gcc 4.6.4, but not with 4.7.3 or 4.8.0, all built

as crosses to arm-linux-gnueabi from unmodified FSF releases.

[Bug c++/56936] gcc don't show error when accessing to missing member of current instantiation

[redi at gcc dot gnu.org]

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



Jonathan Wakely  changed:



   What|Removed |Added



   Keywords||diagnostic



--- Comment #3 from Jonathan Wakely  2013-04-13 
10:52:55 UTC ---

[temp.res]/8 "If no valid specialization can be generated for a template, and

that template is not instantiated, the template is ill-formed, no diagnostic

required."



No diagnostic required.

[Bug target/56657] [4.7 Regression] ICE - error: unrecognizable insn.

[nkbj1970 at hotmail dot com]

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



Niels Kristian Bech Jensen  changed:



   What|Removed |Added



 Status|NEW |RESOLVED

  Known to work||4.6.4, 4.7.3

 Resolution||FIXED



--- Comment #9 from Niels Kristian Bech Jensen  
2013-04-13 10:34:27 UTC ---

This bug is fixed in both GCC 4.6.4 and 4.7.3. Thanks.



Best regards,

Niels Kristian Bech Jensen

[Bug fortran/56937] Unnecessarily temporary with array-vector assignments

[mikael at gcc dot gnu.org]

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



--- Comment #5 from Mikael Morin  2013-04-13 
10:32:46 UTC ---

(In reply to comment #0)

>   tmp(2) = r(1) + 0.25  ! r(1:4) == 0

>   tmp(2) = r(2) + 0.25

>   tmp(3) = r(3) + 0.25

>   tmp(2) = r(4) + 0.25

>   r(2) = tmp(2) ! = 0.25

>   r(2) = tmp(2) ! = 0.25

>   r(3) = tmp(3) ! = 0.25

>   r(2) = tmp(2) ! = 0.25

> -> sum(r) = 0.5

> 



By the way, it's rather:

   tmp(1) = r(2) + 0.25  ! r(1:4) == 0

   tmp(2) = r(2) + 0.25

   tmp(3) = r(3) + 0.25

   tmp(4) = r(2) + 0.25

   r(2) = tmp(1) ! = 0.25

   r(2) = tmp(2) ! = 0.25

   r(3) = tmp(3) ! = 0.25

   r(2) = tmp(4) ! = 0.25

-> sum(r) = 0.5

[Bug fortran/56937] Unnecessarily temporary with array-vector assignments

[mikael at gcc dot gnu.org]

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



--- Comment #4 from Mikael Morin  2013-04-13 
10:26:05 UTC ---

The following variant is valid, and gives 1.0 as expected.

But it doesn't avoid the temporary either.





real :: r(4), p(4)

integer :: idx(4)

p = [0.25, 0.25, 0.25, 0.25]

idx = [4,2,3,1]

r = 0

r(idx) = r(idx) + p

print *, sum(r)

end

[Bug fortran/56937] Unnecessarily temporary with array-vector assignments

[mikael at gcc dot gnu.org]

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



Mikael Morin  changed:



   What|Removed |Added



 CC||mikael at gcc dot gnu.org



--- Comment #3 from Mikael Morin  2013-04-13 
10:15:03 UTC ---

(In reply to comment #0)

> In other words, the following program should print "1.0" and not "0.5". 



Technically, the program is invalid (for the reason you quote), so there isn't 

any valid result.

[Bug target/56944] New: Better isfinite in some cases?

[glisse at gcc dot gnu.org]

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



 Bug #: 56944

   Summary: Better isfinite in some cases?

Classification: Unclassified

   Product: gcc

   Version: 4.9.0

Status: UNCONFIRMED

  Keywords: missed-optimization

  Severity: enhancement

  Priority: P3

 Component: target

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

ReportedBy: gli...@gcc.gnu.org

Target: x86_64-linux-gnu





Hello,



for isfinite, gcc typically generates this sequence:



movsd.LC0(%rip), %xmm1

andpd%xmm1, %xmm0

movsd.LC1(%rip), %xmm1

ucomisd%xmm0, %xmm1

setae%al



With -fno-trapping-math, I tried this shorter sequence instead, which should be

valid:



subsd%xmm0, %xmm0

ucomisd%xmm0, %xmm0

setnp%al



Depending on the tests, it seemed to be either the same speed or 15% faster,

whether the argument is normal, infinite or nan. For a denormal argument, it is

15% slower (but then both codes take 100 times as long as the normal case). The

results might also be different on a more recent processor.



I don't know if we want to try and generate this code when -fno-trapping-math

is present.



(related to PR 30652)

[Bug target/56940] internal compiler error: unrecognizable insn:

[gcc.hall at gmail dot com]

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



--- Comment #2 from Jeremy  2013-04-13 07:58:24 UTC 
---



> You should report this failure to where you got the binary from really.



Yes, sorry.  They should be distributing a supported version too.



I suspect this is an ARM issue.

The problem does not occur with GCC 4.3.2, 4.7.0 (x86) and 4.8.0 (x64)



I was unable to build GCC on the Raspberry Pi so I cant (yet) test 4.6.4.



Note the problem happens with -O3 and not -O2.