[Bug rtl-optimization/58048] [4.8/4.9 Regression] internal compiler error: Max. number of generated reload insns per insn is achieved (90)

[bernd.edlinger at hotmail dot de]

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

--- Comment #11 from Bernd Edlinger  ---
hmm, this test compiles correctly if -msse2 is used.
gcc -O2 -msse2 -mno-avx -S intrinsics_4.c

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

[janus at gcc dot gnu.org]

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

--- Comment #5 from janus at gcc dot gnu.org ---
(In reply to janus from comment #3)
> To get rid of all of them, I would propose to use the gfc_symbol.resolved
> field (this is already done for ordinary symbols in 'resolve_symbol'). For
> derived types, however, one may have to add another value of this flag
> (other than '0' and '1') to distinguish between the two different resolution
> levels of resolve_fl_derived0 vs resolve_fl_derived.

The following draft patch does exactly this and gets the error count down to
one for comment 1 and down to two for comment 1 and 4:


Index: gcc/fortran/gfortran.h
===
--- gcc/fortran/gfortran.h(revision 201576)
+++ gcc/fortran/gfortran.h(working copy)
@@ -1250,7 +1250,7 @@ typedef struct gfc_symbol
   /* Set if this variable is used as an index name in a FORALL.  */
   unsigned forall_index:1;
   /* Used to avoid multiple resolutions of a single symbol.  */
-  unsigned resolved:1;
+  unsigned resolved:2;

   int refs;
   struct gfc_namespace *ns;/* namespace containing this symbol */
Index: gcc/fortran/resolve.c
===
--- gcc/fortran/resolve.c(revision 201576)
+++ gcc/fortran/resolve.c(working copy)
@@ -11962,6 +11962,10 @@ resolve_fl_derived0 (gfc_symbol *sym)
   gfc_symbol* super_type;
   gfc_component *c;

+  if (sym->resolved>1)
+return true;
+  sym->resolved = 2;
+
   if (sym->attr.unlimited_polymorphic)
 return true;

@@ -12381,6 +12385,13 @@ resolve_fl_derived (gfc_symbol *sym)
 {
   gfc_symbol *gen_dt = NULL;

+  if (!resolve_fl_derived0 (sym))
+return false;
+
+  if (sym->resolved>2)
+return true;
+  sym->resolved = 3;
+
   if (sym->attr.unlimited_polymorphic)
 return true;

@@ -12422,9 +12433,6 @@ resolve_fl_derived (gfc_symbol *sym)
 }
 }

-  if (!resolve_fl_derived0 (sym))
-return false;
-
   /* Resolve the type-bound procedures.  */
   if (!resolve_typebound_procedures (sym))
 return false;
@@ -12624,16 +12632,13 @@ resolve_symbol (gfc_symbol *sym)
   gfc_array_spec *as;
   bool saved_specification_expr;

-  if (sym->resolved)
+  if (sym->resolved>0)
 return;
   sym->resolved = 1;

-  if (sym->attr.artificial)
+  if (sym->attr.artificial || sym->attr.unlimited_polymorphic)
 return;

-  if (sym->attr.unlimited_polymorphic)
-return;
-
   if (sym->attr.flavor == FL_UNKNOWN
   || (sym->attr.flavor == FL_PROCEDURE && !sym->attr.intrinsic
   && !sym->attr.generic && !sym->attr.external

[Bug rtl-optimization/58048] [4.8/4.9 Regression] internal compiler error: Max. number of generated reload insns per insn is achieved (90)

[bernd.edlinger at hotmail dot de]

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

--- Comment #10 from Bernd Edlinger  ---
(In reply to Vladimir Makarov from comment #9)
so this test case has no chance to pass on a target without avx.
maybe this should be added to the test case then?

/* { dg-require-effective-target avx } */

[Bug libstdc++/58104] std::call_once appears to fail on standard code

[barto at visionpro dot com]

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

--- Comment #6 from barto at visionpro dot com ---
Compiling the code listed in the original bug report with gcc4.8 using the
-pthread flag the program fails to complete execution due to a segmentation
fault while attempting to acquire a std::once_flag object in a call to
std::call_once.

This but only occurs on MacOS X builds.

The code works correctly on Linux with the -pthread option to the compiler.

[Bug libstdc++/58104] std::call_once appears to fail on standard code

[redi at gcc dot gnu.org]

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

--- Comment #5 from Jonathan Wakely  ---
"Failed to execute" and "segmentation fault" are not the same thing, it would
help if you actually say what the problem is!

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

[janus at gcc dot gnu.org]

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

--- Comment #4 from janus at gcc dot gnu.org ---
(In reply to janus from comment #3)
> For another example, see PR 51945. In this case, the double resolution seems
> to be related to the default initialization.

Here is a reduced test case from this PR:


type t
end type

type ::  t2
end type

type my_t
  type(t) :: y = t2() ! Invalid
end type

type(my_t) :: a
end


It gives three times the error message:

  type(t) :: y = t2() ! Invalid
1
Error: Can't convert TYPE(t2) to TYPE(t) at (1)

[Bug fortran/51945] Diagnose wrong default initialization of DTs in a DT declaration

[janus at gcc dot gnu.org]

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

--- Comment #6 from janus at gcc dot gnu.org ---
Btw, here is a variant which triggers an internal error similar to comment 3,
but already with a clean trunk:


type t
integer :: i = 3
end type t

type my_t
  integer :: i = t()
end type

type(my_t) :: a
end

[Bug driver/42955] undecorated cross-compiler gcc fails to find cc1

[brooks at gcc dot gnu.org]

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

--- Comment #9 from Brooks Moses  ---
Patch posted:
http://gcc.gnu.org/ml/gcc-patches/2013-08/msg00490.html

[Bug rtl-optimization/58048] [4.8/4.9 Regression] internal compiler error: Max. number of generated reload insns per insn is achieved (90)

[vmakarov at redhat dot com]

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

Vladimir Makarov  changed:

   What|Removed |Added

 CC||vmakarov at redhat dot com

--- Comment #9 from Vladimir Makarov  ---
(In reply to Bernd Edlinger from comment #8)
> I see the same error with recent 4.9 i686-pc-linux-gnu in the following
> test case:
> 
> gcc -O2 -msse -mno-avx -S testsuite/gcc.target/i386/intrinsics_4.c
> intrinsics_4.c: In function 'foo':
> intrinsics_4.c:14:1: internal compiler error: Max. number of generated
> reload insns per insn is achieved (90)
> 
>  }
>  ^
> 0x849e4c3 lra_constraints(bool)
> ../../gcc-4.9-20130728/gcc/lra-constraints.c:3724
> 0x849136c lra(_IO_FILE*)
> ../../gcc-4.9-20130728/gcc/lra.c:2319
> 0x8456beb do_reload
> ../../gcc-4.9-20130728/gcc/ira.c:4689
> 0x8456beb rest_of_handle_reload
> ../../gcc-4.9-20130728/gcc/ira.c:4801
> Please submit a full bug report,
> with preprocessed source if appropriate.

It is the same diagnostic but it has different reason for this.

I guess it is not LRA problem.  This test should be not run for i686 as it
tries to use non-avx and avx insns (which is absent for i686 architecture).

Reload pass also finishes badly by assert (internal error) on this test as
reload can not find insns to generate correct code.

Still GCC should have a better diagnostic for this case (may be by checking
correct architecture/attribute pairs).  Although I have no idea how to do it
right.

[Bug fortran/51945] Diagnose wrong default initialization of DTs in a DT declaration

[janus at gcc dot gnu.org]

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

janus at gcc dot gnu.org changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
   Assignee|unassigned at gcc dot gnu.org  |janus at gcc dot gnu.org

--- Comment #5 from janus at gcc dot gnu.org ---
(In reply to janus from comment #4)
> The following patch should somewhat improve the situation:

... and regtests cleanly.

[Bug middle-end/58101] Wrong out-of-bounds warning under -Os

[llozano at google dot com]

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

--- Comment #3 from Luis A Lozano  ---
(In reply to Marek Polacek from comment #2)
> Perhaps a dup of PR41847.  Fails even with -O2, -O3, -Ofast, no only -Os. 
> -fno-tree-vrp makes it go away...

I dont think it is a duplicate of this issue. 
This problem does not happen with GCC 4.7.2

[Bug c++/58107] New: missing destructor call after thrown exception in lambda capture

[mmehlich at semanticdesigns dot com]

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

Bug ID: 58107
   Summary: missing destructor call after thrown exception in
lambda capture
   Product: gcc
   Version: 4.9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: mmehlich at semanticdesigns dot com

Code:

extern "C" int printf(const char *,...);

struct A {
A() { printf("A()\n"); }
A(const A&) { printf("A(const A&)\n"); }
~A() { printf("~A()\n"); }
operator int() const;
};
struct B {
B() { printf("B()\n"); }
B(const B&) { printf("B(const B&)\n"); }
~B() { printf("~B()\n"); }
operator int() const;
};

int main() {
A a;
B b;
try { auto lll ( [a,c = (throw 7, 9),b]()->int { return a+c+b; } ); // gcc
doesn't destroy copy-captured a...
} catch (...) {
}
};

Compile command line:
  gcc -std=c++1y lambda.cpp -lstdc++

Actual output:
  A()
  B()
  A(const A&)
  ~B()
  ~A()

Expected output:
  A()
  B()
  A(const A&)
  ~A()
  ~B()
  ~A()

The destructor call for the copy captured a is missing.

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

[janus at gcc dot gnu.org]

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

janus at gcc dot gnu.org changed:

   What|Removed |Added

Summary|extended derived types are  |derived types are resolved
   |resolved more than once |more than once

--- Comment #3 from janus at gcc dot gnu.org ---
For another example, see PR 51945. In this case, the double resolution seems to
be related to the default initialization.

So, there are at least three distinct causes of multiple resolution of type
symbols:
1) type extension
2) type-bound procedures
3) default initialization


To get rid of all of them, I would propose to use the gfc_symbol.resolved field
(this is already done for ordinary symbols in 'resolve_symbol'). For derived
types, however, one may have to add another value of this flag (other than '0'
and '1') to distinguish between the two different resolution levels of
resolve_fl_derived0 vs resolve_fl_derived.

[Bug fortran/51945] Diagnose wrong default initialization of DTs in a DT declaration

[janus at gcc dot gnu.org]

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

--- Comment #4 from janus at gcc dot gnu.org ---
The following patch should somewhat improve the situation:


Index: gcc/fortran/resolve.c
===
--- gcc/fortran/resolve.c(revision 201576)
+++ gcc/fortran/resolve.c(working copy)
@@ -1178,7 +1178,7 @@ resolve_structure_cons (gfc_expr *expr, int init)
  gfc_basic_typename (comp->ts.type));
   t = false;
 }
-  else
+  else if (!init)
 {
   bool t2 = gfc_convert_type (cons->expr, &comp->ts, 1);
   if (t)
@@ -12344,7 +12344,7 @@ resolve_fl_derived0 (gfc_symbol *sym)

   if (c->initializer && !sym->attr.vtype
   && !gfc_check_assign_symbol (sym, c, c->initializer))
-return false;
+continue;
 }

   check_defined_assignments (sym);



The first hunk suppresses the errors in the resolution of the symbol 'a', since
they should already be thrown in the resolution of the type.

The second hunk makes sure one gets the error in both components when resolving
the type (a similar thing is also done in PR 58023 comment 5).


With the above patch I get the expected result on the original test case in
comment 0:

Error: Can't convert TYPE(t2) to TYPE(t) at (1)
Error: Can't convert TYPE(t3) to TYPE(t) at (1)

On the version with the uncommented line, each error unfortunately still
appears twice, but that is due to the fact that the type symbol is resolved
twice (cf. also PR 44978).

[Bug rtl-optimization/58079] internal compiler error: in do_SUBST, at combine.c:711

[rsandifo at gcc dot gnu.org]

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

rsandifo at gcc dot gnu.org  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution|--- |FIXED

--- Comment #6 from rsandifo at gcc dot gnu.org  
---
...which means I should close the thing.

[Bug rtl-optimization/58079] internal compiler error: in do_SUBST, at combine.c:711

[rsandifo at gcc dot gnu.org]

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

--- Comment #5 from rsandifo at gcc dot gnu.org  
---
Patch applied to trunk.

[Bug fortran/51945] Diagnose wrong default initialization of DTs in a DT declaration

[janus at gcc dot gnu.org]

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

--- Comment #3 from janus at gcc dot gnu.org ---
Applying the patches from PR 49213 (comments 8, 10 and 16), I get the
following:


1) test case with comment: same as before (error with t2)


2) test case with uncommented line:

c0.f90:15.16:

  type(t) :: y = t2() ! Invalid
1
Error: Can't convert TYPE(t2) to TYPE(t) at (1)
c0.f90:2.6:

type t
  1
Internal Error at (1):
c0.f90:15.16:

  type(t) :: y = t2() ! Invalid
1
Can't convert TYPE(t2) to TYPE(t) at (1)


As noted by Dominique, this seems to be due to PR 49213 comment 16, in
particular.

[Bug c/56824] pragma GCC diagnostic push/pop regression for GCC diagnostic ignored "-Waggregate-return"

[magnus.reftel at gmail dot com]

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

Magnus Reftel  changed:

   What|Removed |Added

  Known to work||4.7.3
  Known to fail||4.8.1, 4.9.0

--- Comment #6 from Magnus Reftel  ---
Re-tested with 4.8.1 and MacPorts experimental gcc49 version 4.9-20130728_1.
Both fail. 4.7.3 works.

[Bug fortran/51945] Diagnose wrong default initialization of DTs in a DT declaration

[janus at gcc dot gnu.org]

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

janus at gcc dot gnu.org changed:

   What|Removed |Added

 CC||janus at gcc dot gnu.org

--- Comment #2 from janus at gcc dot gnu.org ---
With current trunk as well as 4.8, the test case with comment gives me:

Error: Can't convert TYPE(t2) to TYPE(t) at (1)

(but not the corresponding error with 't3'). When uncommenting the line I get:

Error: Can't convert TYPE(t2) to TYPE(t) at (1)
Error: Can't convert TYPE(t2) to TYPE(t) at (1)
Error: Can't convert TYPE(t2) to TYPE(t) at (1)
Error: Can't convert TYPE(t3) to TYPE(t) at (1)

(i.e. three times the error about t2 and once about t3).


I guess the expected result would be to get each error once!

[Bug libstdc++/58104] std::call_once appears to fail on standard code

[barto at visionpro dot com]

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

--- Comment #4 from barto at visionpro dot com ---
Adding the -pthread flag allows the code to compile and execute on Linux.

MacOS still fails to execute.

[Bug driver/42955] undecorated cross-compiler gcc fails to find cc1

[brooks at gcc dot gnu.org]

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

--- Comment #8 from Brooks Moses  ---
FWIW, there was some interesting discussion of this on
http://sourceware.org/bugzilla/show_bug.cgi?id=15823.

In particular, Joseph Myers argues that "the bug is installing the files in
$target/bin/ at all ... That directory contains executables from binutils for
internal use by GCC; that's its sole purpose.  The files installed by GCC there
aren't used by GCC (rather, the public installed copy of the driver gets used 
when collect2 needs to call back to the driver), so shouldn't be 
installed."

Given the attention this bug has received in the past three years, and the fact
that this was broken for at least three years before the bug was filed, I'm
inclined to agree.

(There are two or three references online to making the $target/bin/gcc
programs work by setting PATH variables to the relevant libexec subdirectory,
so they're not _completely_ unused.  But nothing ever is.)

[Bug fortran/58064] Cannot compile gcc-4.8.1 by gcc-3.4.6

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

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

--- Comment #2 from Dominique d'Humieres  ---
> seems your mpfr library is broken

Then closing as invalid.

[Bug fortran/58085] Wrong indexing of an array in ASSOCIATE

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

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

--- Comment #1 from Dominique d'Humieres  ---
Confirmed.

[Bug fortran/49213] [OOP] gfortran rejects structure constructor expression

[dominiq at lps dot ens.fr]

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

--- Comment #18 from Dominique d'Humieres  ---
With the patch in comment #16 the 'Internal Error' when compiling the code in
comment #15 disappears, but appears when compiling the test in pr51945 with the
type-declaration line 'type(my_t) :: a' is uncommented.

[Bug fortran/51945] Diagnose wrong default initialization of DTs in a DT declaration

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

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

--- Comment #1 from Dominique d'Humieres  ---
Between revisions 194897 (2013-01-04: no error) and 195140 (2013-01-14),
gfortran has started to emit the following error for the original test:

pr51945.f90:14.16:

  type(t) :: y = t2() ! Invalid
1
Error: Can't convert TYPE(t2) to TYPE(t) at (1)

If the type-declaration line 'type(my_t) :: a' is uncommented, the errors
appear once for r194897, but twice for r195140.

[Bug middle-end/58106] ICE: in ipa_edge_duplication_hook, at ipa-prop.c:2839

[ktkachov at gcc dot gnu.org]

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

ktkachov at gcc dot gnu.org changed:

   What|Removed |Added

   Target Milestone|--- |4.9.0

[Bug libstdc++/58104] std::call_once appears to fail on standard code

[DBarto at visionpro dot com]

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

--- Comment #3 from DBarto at visionpro dot com ---
/opt/local/bin/g++-mp-4.7 -std=c++11 -Wall -Wextra  -pthread -g use_once.cpp -o
use_once
./use_once
571_ ./use_once
Segmentation fault: 11

gdb use_once
(gdb) r
Starting program: /Users/barto/mvp/trunk/unit_test/use_once 
Reading symbols for shared libraries +++.. done

Program received signal EXC_BAD_ACCESS, Could not access memory.
Reason: 13 at address: 0x
[Switching to process 22829 thread 0x1203]
0x000100074b20 in __once_proxy ()
(gdb) where
#0  0x000100074b20 in __once_proxy ()
#1  0x7fff8f7e0ff0 in pthread_once ()
#2  0x00011165 in __gthread_once (__once=0x155e0,
__func=0x100074b10 <__once_proxy>) at gthr-default.h:718
#3  0x0001142d in call_once >
(__once=@0x155e0, __f=@0x100293e6f) at mutex:822
#4  0x00011247 in do_once () at use_once.cpp:47
#5  0x00012a29 in
_ZNSt12_Bind_simpleIFPFvvEvEE9_M_invokeIIEEEvSt12_Index_tupleIIXspT_EEE
(this=0x100303aa0) at functional:1598
#6  0x00012979 in std::_Bind_simple::operator()
(this=0x100303aa0) at functional:1586
#7  0x00012912 in std::thread::_Impl
>::_M_run (this=0x100303a88) at thread:115
#8  0x0001000754b0 in execute_native_thread_routine ()
#9  0x7fff8f7cc1e1 in thread_start ()

On Aug 8, 2013, at 9:10 AM, redi at gcc dot gnu.org 
 wrote:

> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58104
> 
> --- Comment #1 from Jonathan Wakely  ---
> Works for me.
> 
> Are you using the -pthread flag?
> 
> You haven't actually said what fails, what fails to execute?
> 
> -- 
> You are receiving this mail because:
> You reported the bug.

[Bug libstdc++/58104] std::call_once appears to fail on standard code

[DBarto at visionpro dot com]

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

--- Comment #2 from DBarto at visionpro dot com ---
I added the -pthread flag and nothing changed.

The code failed to execute at the point noted in the assembly output.

David

On Aug 8, 2013, at 9:10 AM, redi at gcc dot gnu.org 
 wrote:

> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58104
> 
> --- Comment #1 from Jonathan Wakely  ---
> Works for me.
> 
> Are you using the -pthread flag?
> 
> You haven't actually said what fails, what fails to execute?
> 
> -- 
> You are receiving this mail because:
> You reported the bug.

[Bug middle-end/58106] New: ICE: in ipa_edge_duplication_hook, at ipa-prop.c:2839

[ktkachov at gcc dot gnu.org]

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

Bug ID: 58106
   Summary: ICE: in ipa_edge_duplication_hook, at ipa-prop.c:2839
   Product: gcc
   Version: 4.9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
  Assignee: unassigned at gcc dot gnu.org
  Reporter: ktkachov at gcc dot gnu.org

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

Given the attached testcase, gcc ICEs with:

besttry.c:45:1: internal compiler error: in ipa_edge_duplication_hook, at
ipa-prop.c:2839
 }
 ^
0x61b31b cgraph_call_edge_duplication_hooks(cgraph_edge*, cgraph_edge*)
$TOP/gcc/gcc/cgraph.c:438
0xd7f357 clone_inlined_nodes(cgraph_edge*, bool, bool, int*)
$TOP/gcc/gcc/ipa-inline-transform.c:178
0xd7e9b8 recursive_inlining
$TOP/gcc/gcc/ipa-inline.c:1320
0xd7e9b8 inline_small_functions
$TOP/gcc/gcc/ipa-inline.c:1571
0xd7ed3d ipa_inline
$TOP/gcc/gcc/ipa-inline.c:1796
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.


Bisection shows it started with r200368:

2013-06-24  Martin Jambor  

PR tree-optimization/57539
* cgraphclones.c (cgraph_clone_node): Add parameter new_inlined_to, set
global.inlined_to of the new node to it.  All callers changed.
* ipa-inline-transform.c (clone_inlined_nodes): New variable
inlining_into, pass it to cgraph_clone_node.
* ipa-prop.c (ipa_propagate_indirect_call_infos): Do not call
ipa_free_edge_args_substructures.
(ipa_edge_duplication_hook): Only add edges from inlined nodes to
rdesc linked list.  Do not assert rdesc edges have inlined caller.
Assert we have found an rdesc in the rdesc list.

compiled with gcc -O3.

Thanks to James Greenhalgh for spotting this.
Seems like fallout or an incomplete fix for PR57539

[Bug c++/58105] New: wrong code generation for multiversioned functions

[bernd.edlinger at hotmail dot de]

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

Bug ID: 58105
   Summary: wrong code generation for multiversioned functions
   Product: gcc
   Version: 4.9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: bernd.edlinger at hotmail dot de

the following test cases fail on i686-*:
g++.dg/ext/mv2.C
g++.dg/ext/mv5.C
g++.dg/ext/mv12.C

The code is OK on -O0, -O1, but fails on -O2 and -O3.

The problem seems to be that for multiversioned functions 
an internal dispatcher function is generated by
ix86_generate_version_dispatcher_body(), which is being inlined in -O2
and above.

But the inlined function does no longer call the target-specific function.
Instead the return value is the address of the target-specific function.

[Bug libstdc++/58104] std::call_once appears to fail on standard code

[redi at gcc dot gnu.org]

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

--- Comment #1 from Jonathan Wakely  ---
Works for me.

Are you using the -pthread flag?

You haven't actually said what fails, what fails to execute?

[Bug libstdc++/58104] New: std::call_once appears to fail on standard code

[barto at visionpro dot com]

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

Bug ID: 58104
   Summary: std::call_once appears to fail on standard code
   Product: gcc
   Version: 4.8.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: barto at visionpro dot com

When using std::call_once the code on Linux(gcc 4.7.0) or MacOS (gcc 4.7.3 or
4.8.1) fails to execute

562_ /opt/local/bin/gcc-mp-4.8 -v
Using built-in specs.
COLLECT_GCC=/opt/local/bin/gcc-mp-4.8
COLLECT_LTO_WRAPPER=/opt/local/libexec/gcc/x86_64-apple-darwin12/4.8.1/lto-wrapper
Target: x86_64-apple-darwin12
Configured with: ../gcc-4.8.1/configure --prefix=/opt/local
--build=x86_64-apple-darwin12
--enable-languages=c,c++,objc,obj-c++,lto,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 --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.1_1+universal'
Thread model: posix
gcc version 4.8.1 (MacPorts gcc48 4.8.1_1+universal) 

The code that fails is taken directly from the c++ documentation site:

http://en.cppreference.com/w/cpp/thread/call_once

#include 
#include 
#include 

std::once_flag flag;

void do_once()
{
std::call_once(flag, [](){ std::cout << "Called once" << std::endl; });
}

int main()
{
std::thread t1(do_once);
std::thread t2(do_once);
std::thread t3(do_once);
std::thread t4(do_once);

t1.join();
t2.join();
t3.join();
t4.join();
}

The bug appears in the call to call_once (thanks for detail from Jeremy
Huddleston Sequoia on the MacPorts mailing list for the assembly trace)

__once_proxy is just looking up some other function (__once_call) using
__emutls_get_address and executing it (makes sense based on the name).
__emutls_get_address is returning 3 in this instance, so something looks wrong
with emutls:

(lldb) disassemble -n __once_proxy
libstdc++.6.dylib`__once_proxy:
  0x1000e974e:  pushq  %rbp
  0x1000e974f:  movq   %rsp, %rbp
  0x1000e9752:  leaq   463719(%rip), %rdi; __emutls_v._ZSt11
_ZSt11__once_call
  0x1000e9759:  callq  0x100101880   ;
libstdc++.6.dylib.__TEXT.__text + 602364
-> 0x1000e975e:  movq   (%rax), %rax
  0x1000e9761:  callq  *%rax
  0x1000e9763:  popq   %rbp
  0x1000e9764:  ret
(lldb) disassemble -s 0x100101880
libstdc++.6.dylib`__emutls_get_address:
...
(lldb) register read
General Purpose Registers:
  rax = 0x0003
...

Further this has been shown to fail on 4.7 [gcc version 4.7.3 (MacPorts gcc47
4.7.3_1+universal)]
and in the development build for gcc 4.9 (again through Jeremy)

If this is a configuration issue, what configuration flag is required to make
the feature work?

What versions of the Mac/Linux version of gcc have been shown to work?

[Bug fortran/55057] [OOP] wrong result with abstract type

[janus at gcc dot gnu.org]

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

--- Comment #9 from janus at gcc dot gnu.org ---
(In reply to janus from comment #8)
> (In reply to Dominique d'Humieres from comment #7)
> > It has been fixed between revisions 194721 and 195140.
> 
> I can confirm that it is fixed on trunk, so let's close it!
> 
> Btw, it even works for me with:
> 
> gcc version 4.8.1 20130806 [gcc-4_8-branch revision 201525] (SUSE Linux)

... and, without testing, I assume it also works with the 4.8.0 release. This
assumption also matches Dominique's revision range (the 4.8 branch was created
only at r196696).

[Bug fortran/55057] [OOP] wrong result with abstract type

[janus at gcc dot gnu.org]

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

janus at gcc dot gnu.org changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |FIXED

--- Comment #8 from janus at gcc dot gnu.org ---
(In reply to Dominique d'Humieres from comment #7)
> It has been fixed between revisions 194721 and 195140.

I can confirm that it is fixed on trunk, so let's close it!

Btw, it even works for me with:

gcc version 4.8.1 20130806 [gcc-4_8-branch revision 201525] (SUSE Linux)

[Bug fortran/51160] [OOP] Memory leak with abstract type

[janus at gcc dot gnu.org]

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

janus at gcc dot gnu.org changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |FIXED

--- Comment #2 from janus at gcc dot gnu.org ---
(In reply to Tobias Burnus from comment #1)
> I think your issue has nothing to do with abstract types but rather with
> working with polymorphic data ("CLASS").
> 
> I think the issue is that "r"'s "u" component in "sub" is not freed at the
> end, which would be a duplicate of PR 46321.

Correct. And now that polymorphic deallocation is implemented, also the memory
leak is gone: The dump shows that the _final procedure is called, and also
valgrind reports a clean memory footprint:

==5457== HEAP SUMMARY:
==5457== in use at exit: 0 bytes in 0 blocks
==5457==   total heap usage: 423 allocs, 423 frees, 58,341 bytes allocated
==5457== 
==5457== All heap blocks were freed -- no leaks are possible

[Bug fortran/46321] [OOP] Polymorphic deallocation

[janus at gcc dot gnu.org]

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

janus at gcc dot gnu.org changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |FIXED

--- Comment #8 from janus at gcc dot gnu.org ---
Indeed all the items from comment 1 to 3 seems to be handled. Below is a test
case, whose dump shows a _final call being created for all of them.

The only exception is realloc-on-assignment, which is not implemented yet for
CLASS variables, but there is PR 43366 to track that.

Therefore this PR can be closed, I think.



program p

type t
end type t

type u
  class(t), allocatable :: c
end type

class(t), allocatable :: a,b
type(u), allocatable :: uu
integer :: i
character(len=100) :: str

allocate(a,b,uu)

! (1) explicit deallocation
deallocate(a)

! (4) STAT and ERRMSG
deallocate(a,stat=i,errmsg=str)
if (i/=0) print *,i,str

! (5) dealloc of comp.
deallocate(uu)

! (6) move_alloc
call move_alloc(b,a)

contains

  subroutine out (x)
! (2) intent(out)
class(t), intent(out) :: x
  end subroutine

  subroutine sub ()
! (3) out of scope
class(t), allocatable :: local
allocate(local)
  end subroutine

end

[Bug fortran/43366] [OOP][F08] Intrinsic assign to polymorphic variable

[janus at gcc dot gnu.org]

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

Bug 43366 depends on bug 46321, which changed state.

Bug 46321 Summary: [OOP] Polymorphic deallocation
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46321

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |FIXED

[Bug c/58103] Error in handling of command line parameters in main(int argc, char *argv[]), in case of ???..?

[redi at gcc dot gnu.org]

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

--- Comment #5 from Jonathan Wakely  ---
This has nothing to do with GCC anyway.

[Bug target/57431] ICE in simplify_const_unary_operation vld1_dup_s64/vst1_s64

[rearnsha at gcc dot gnu.org]

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

Richard Earnshaw  changed:

   What|Removed |Added

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

--- Comment #2 from Richard Earnshaw  ---
Fixed on trunk with:

PR target/57431
* arm/neon.md (neon_vld1_dupdi): New expand pattern.
(neon_vld1_dup VD iterator): Iterate over VD not VDX.

Committed to trunk as revision r201599.

[Bug target/56979] ICE in output_operand: invalid operand for code 'P'

[rearnsha at gcc dot gnu.org]

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

--- Comment #6 from Richard Earnshaw  ---
Fixed with

PR target/56979
* arm.c (aapcs_vfp_allocate): Decompose the argument if the
suggested mode for the assignment isn't compatible with the
registers required.


On Trunk: r201598.

[Bug libstdc++/56193] ios_base should replace operator void* with explicit operator bool in C++11 onwards.

[david.abdurachmanov at gmail dot com]

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

David Abdurachmanov  changed:

   What|Removed |Added

 CC||david.abdurachmanov at gmail 
dot c
   ||om

--- Comment #7 from David Abdurachmanov  
---
Ping.

@Paolo, any ETA for this entering a trunk?

[Bug c/58103] Error in handling of command line parameters in main(int argc, char *argv[]), in case of ???..?

[heinz.dob...@fh-hagenberg.at]

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

--- Comment #4 from heinz.dob...@fh-hagenberg.at ---
Thanks, maybe some other person has an idea for this problem ;-)
H

-Original Message-
From: mpolacek at gcc dot gnu.org [mailto:gcc-bugzi...@gcc.gnu.org] 
Sent: Donnerstag, 08. August 2013 13:57
To: heinz.dob...@gmx.at
Subject: *** GMX Spamverdacht *** [Bug c/58103] Error in handling of command
line parameters in main(int argc, char *argv[]), in case of ???..?

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

--- Comment #3 from Marek Polacek  --- Sorry, I
don't know neither Microsoft compiler nor Windows enough to answer that.

--
You are receiving this mail because:
You reported the bug.

[Bug c/58103] Error in handling of command line parameters in main(int argc, char *argv[]), in case of ???..?

[mpolacek at gcc dot gnu.org]

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

--- Comment #3 from Marek Polacek  ---
Sorry, I don't know neither Microsoft compiler nor Windows enough to answer
that.

[Bug c/58103] Error in handling of command line parameters in main(int argc, char *argv[]), in case of ???..?

[heinz.dob...@fh-hagenberg.at]

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

--- Comment #2 from heinz.dob...@fh-hagenberg.at ---
Hello Marek!

Thank you for your fast response.

BUT: Why does it work when I compile this C program with, e.g., the Microsoft C
compiler (cl).

By the way: "echo ???" prints "???" (Windows).

Best regards
Heinz 



-Original Message-
From: mpolacek at gcc dot gnu.org [mailto:gcc-bugzi...@gcc.gnu.org] 
Sent: Donnerstag, 08. August 2013 13:40
To: heinz.dob...@gmx.at
Subject: *** GMX Spamverdacht *** [Bug c/58103] Error in handling of command
line parameters in main(int argc, char *argv[]), in case of ???..?

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

Marek Polacek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 CC||mpolacek at gcc dot gnu.org
 Resolution|--- |INVALID

--- Comment #1 from Marek Polacek  --- Eh, that is
just shell globbing patterns expanding ?s to file names in current directory.
Try "echo ???".

--
You are receiving this mail because:
You reported the bug.

[Bug c/58103] Error in handling of command line parameters in main(int argc, char *argv[]), in case of ???..?

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 CC||mpolacek at gcc dot gnu.org
 Resolution|--- |INVALID

--- Comment #1 from Marek Polacek  ---
Eh, that is just shell globbing patterns expanding ?s to file names in current
directory.
Try "echo ???".

[Bug rtl-optimization/58048] [4.8/4.9 Regression] internal compiler error: Max. number of generated reload insns per insn is achieved (90)

[bernd.edlinger at hotmail dot de]

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

Bernd Edlinger  changed:

   What|Removed |Added

 CC||bernd.edlinger at hotmail dot 
de

--- Comment #8 from Bernd Edlinger  ---
I see the same error with recent 4.9 i686-pc-linux-gnu in the following
test case:

gcc -O2 -msse -mno-avx -S testsuite/gcc.target/i386/intrinsics_4.c
intrinsics_4.c: In function 'foo':
intrinsics_4.c:14:1: internal compiler error: Max. number of generated reload
insns per insn is achieved (90)

 }
 ^
0x849e4c3 lra_constraints(bool)
../../gcc-4.9-20130728/gcc/lra-constraints.c:3724
0x849136c lra(_IO_FILE*)
../../gcc-4.9-20130728/gcc/lra.c:2319
0x8456beb do_reload
../../gcc-4.9-20130728/gcc/ira.c:4689
0x8456beb rest_of_handle_reload
../../gcc-4.9-20130728/gcc/ira.c:4801
Please submit a full bug report,
with preprocessed source if appropriate.

[Bug c/58103] New: Error in handling of command line parameters in main(int argc, char *argv[]), in case of ???..?

[heinz.dobler at gmx dot at]

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

Bug ID: 58103
   Summary: Error in handling of command line parameters in
main(int argc, char *argv[]), in case of ???..?
   Product: gcc
   Version: 4.8.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: heinz.dobler at gmx dot at

Created attachment 30624
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=30624&action=edit
compile and execute with command line a.exe ??? or a.out ???

There is an error in the handling of command line parameters for the main
function:

  int main(int argc, char *argv[]) { printf("%s", argv[1]); ... }

The arguments argc and argv have invalid values when the executable is called
with command line parameters consisting of at least three question marks, e.g.:

a.exe ??? 

or 

a.out ???

The more question marks, the more interesting the results. My program lists
directory names.

[Bug regression/58084] FAIL: gcc.dg/torture/pr8081.c -O2 -flto -fno-use-linker-plugin -flto-partition=none (internal compiler error)

[ramana at gcc dot gnu.org]

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

Ramana Radhakrishnan  changed:

   What|Removed |Added

   Keywords||ice-on-valid-code
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2013-08-08
 CC||ramana at gcc dot gnu.org
 Ever confirmed|0   |1

[Bug c++/54080] [C++11] g++ crashes when compiling the following file

[paolo.carlini at oracle dot com]

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

Paolo Carlini  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
   Assignee|unassigned at gcc dot gnu.org  |paolo.carlini at oracle 
dot com

--- Comment #2 from Paolo Carlini  ---
On it.

[Bug go/57194] go binaries give "no debug info in ELF executable errno -1"

[cickumqt at gmail dot com]

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

Christopher Meng  changed:

   What|Removed |Added

 CC||cickumqt at gmail dot com

--- Comment #3 from Christopher Meng  ---
+1.

I'm building snowbox(go program), and also it threw out such errors after
running.

[Bug target/58065] ARM MALLOC_ABI_ALIGNMENT is wrong

[ramana at gcc dot gnu.org]

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

Ramana Radhakrishnan  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |FIXED

--- Comment #8 from Ramana Radhakrishnan  ---
Fixed by http://gcc.gnu.org/ml/gcc-cvs/2013-08/msg00197.html

[Bug fortran/58099] [4.8/4.9 Regression] [F03] over-zealous procedure-pointer error checking

[janus at gcc dot gnu.org]

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

--- Comment #12 from janus at gcc dot gnu.org ---
(In reply to Tobias Burnus from comment #10)
> (In reply to janus from comment #7)
> > The following patch makes the error go away, but (as expected) causes a
> > failure of proc_ptr_result_8.f90 in the testsuite ...
> > -  if (!gfc_compare_interfaces (s2, s1, name, 0, 1,
> > -  err, sizeof(err), NULL, NULL))
> > -   {
> > - gfc_error ("Interface mismatch in procedure pointer assignment "
> > -"at %L: %s", &rvalue->where, err);
> > - return false;
> > -   }
> 
> 
> Doesn't that remove too much? I had expected some special case for PURE,
> while checking otherwise that the interface matches.

No, I don't think it removes too much. It seems that the other parts of
'gfc_compare_interfaces' are already symmetrized appropriately, expect for the
check on the result characteristics.


> Side note: The following compiles but should give an error as the interface
> doesn't match. (If one swaps the pure, it does and should compile warning
> free.)
> 
> subroutine foo()
> end
> 
> interface
>   pure subroutine foo()
>   end subroutine foo
> end interface
> call foo()
> end

Well, it does give the expected warning with the patch:

  pure subroutine foo()
 1
Warning: Interface mismatch in global procedure 'foo' at (1): Mismatch in PURE
attribute

[Bug fortran/58099] [4.8/4.9 Regression] [F03] over-zealous procedure-pointer error checking

[burnus at gcc dot gnu.org]

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

--- Comment #11 from Tobias Burnus  ---
I just saw that Janus has already posted a patch:
http://gcc.gnu.org/ml/fortran/2013-08/msg00026.html , which is probably
sufficient for 4.8. But for 4.9 [at least as follow up], see my previous
remarks (comment 10).

[Bug fortran/58099] [4.8/4.9 Regression] [F03] over-zealous procedure-pointer error checking

[burnus at gcc dot gnu.org]

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

Tobias Burnus  changed:

   What|Removed |Added

 CC||burnus at gcc dot gnu.org

--- Comment #10 from Tobias Burnus  ---
(In reply to janus from comment #7)
> The following patch makes the error go away, but (as expected) causes a
> failure of proc_ptr_result_8.f90 in the testsuite ...
> -  if (!gfc_compare_interfaces (s2, s1, name, 0, 1,
> -err, sizeof(err), NULL, NULL))
> - {
> -   gfc_error ("Interface mismatch in procedure pointer assignment "
> -  "at %L: %s", &rvalue->where, err);
> -   return false;
> - }


Doesn't that remove too much? I had expected some special case for PURE, while
checking otherwise that the interface matches. (Except for the case where the
proc-pointer only has an implicit interface like for "procedure(real)", unless
some characteristic of the RHS requires an explicit interface.)

* * *

Side note: The following compiles but should give an error as the interface
doesn't match. (If one swaps the pure, it does and should compile warning
free.)

subroutine foo()
end

interface
  pure subroutine foo()
  end subroutine foo
end interface
call foo()
end