[Bug fortran/60378] New: ICE on attempt to print null of derived type with unlimited polymorphic component

[vladimir.fuka at gmail dot com]

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

Bug ID: 60378
   Summary: ICE on attempt to print null of derived type with
unlimited polymorphic component
   Product: gcc
   Version: 4.8.3
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: vladimir.fuka at gmail dot com

type refptr
class(*), allocatable :: data
  end type

  type(refptr),pointer :: x

  print *,null(mold=x)
end

gfortran null.f90 
null.f90: In function ‘MAIN__’:
null.f90:7:0: internal compiler error: Bad IO basetype (7)
   print *,null(mold=x)
 ^
0x5e456b transfer_expr
../../gcc-4.8-20131003/gcc/fortran/trans-io.c:2185
0x5e4422 transfer_expr
../../gcc-4.8-20131003/gcc/fortran/trans-io.c:2179
0x5e76e5 gfc_trans_transfer(gfc_code*)
../../gcc-4.8-20131003/gcc/fortran/trans-io.c:2312
0x5a7177 trans_code
../../gcc-4.8-20131003/gcc/fortran/trans.c:1625
0x5e55d7 build_dt
../../gcc-4.8-20131003/gcc/fortran/trans-io.c:1835
0x5a7197 trans_code
../../gcc-4.8-20131003/gcc/fortran/trans.c:1597
0x5c4812 gfc_generate_function_code(gfc_namespace*)
../../gcc-4.8-20131003/gcc/fortran/trans-decl.c:5397
0x568490 translate_all_program_units
../../gcc-4.8-20131003/gcc/fortran/parse.c:4474
0x568490 gfc_parse_file()
../../gcc-4.8-20131003/gcc/fortran/parse.c:4688
0x5a3845 gfc_be_parse_file
../../gcc-4.8-20131003/gcc/fortran/f95-lang.c:189
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.

[Bug c++/56438] [4.8 regression] ICE in value_dependent_expression_p, at cp/pt.c:19551

[trippels at gcc dot gnu.org]

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

Markus Trippelsdorf  changed:

   What|Removed |Added

 CC||trippels at gcc dot gnu.org

--- Comment #5 from Markus Trippelsdorf  ---
What about the following testcase:

template  struct A {
  void m_fn1(int p1) {
int *a;
while (p1 && *static_cast(static_cast(a)))
  ;
  }
};

shouldn't this compile?

[Bug c++/56438] [4.8 regression] ICE in value_dependent_expression_p, at cp/pt.c:19551

[trippels at gcc dot gnu.org]

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

--- Comment #6 from Markus Trippelsdorf  ---
Sorry, wrong bug.

[Bug c++/50025] [DR 1288] C++0x initialization syntax doesn't work for class members of reference type

[ville.voutilainen at gmail dot com]

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

Ville Voutilainen  changed:

   What|Removed |Added

 CC||ville.voutilainen at gmail dot 
com

--- Comment #14 from Ville Voutilainen  ---
This bug seems to be fixed with the current trunk. Both the example
in the original report and similar examples compile correctly, like

std::string& f() {static std::string s; return s;}
int main()
{
std::string& ri{f()};
}

and

int& f() {static int i = 42; return i;}


int main()
{
int& ri{f()};
}

Please close as resolved.

[Bug c++/60379] New: [4.9 Regression] pugixml build failure caused by r207001

[trippels at gcc dot gnu.org]

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

Bug ID: 60379
   Summary: [4.9 Regression] pugixml build failure caused by
r207001
   Product: gcc
   Version: 4.9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: trippels at gcc dot gnu.org
CC: jason at gcc dot gnu.org

/usr/bin/g++  -flto=4 -march=native -O2 -Dpugixml_EXPORTS  -DNDEBUG
-march=native -O2 -pipe  -fPIC   -o
CMakeFiles/pugixml.dir/var/tmp/portage/dev-libs/pugixml-1.4/work/pugix
ml-1.4/src/pugixml.cpp.o -c
/var/tmp/portage/dev-libs/pugixml-1.4/work/pugixml-1.4/src/pugixml.cpp
/var/tmp/portage/dev-libs/pugixml-1.4/work/pugixml-1.4/src/pugixml.cpp: In
static member function ‘static typename Traits::value_type
pugi::impl::{anonymous}::utf_decoder::decode_utf8_block(const uint8_t*, size_t, typename
Traits::value_type)’:
/var/tmp/portage/dev-libs/pugixml-1.4/work/pugixml-1.4/src/pugixml.cpp:892:90:
error: a cast to a type other than an integral or enumeration type cannot
appear in a constant-
expression
   while (size >= 4 && (*static_cast(static_cast(data)) & 0x80808080) == 0)


markus@x4 tmp % cat test.ii
template  struct A {
  void m_fn1(int p1) {
int *a;
while (p1 && *static_cast(static_cast(a)))
  ;
  }
};

markus@x4 tmp % g++ -c test.ii
test.ii: In member function ‘void A< >::m_fn1(int)’:
test.ii:4:15: error: a cast to a type other than an integral or enumeration
type cannot appear in a constant-expression
 while (p1 && *static_cast(static_cast(a)))
   ^

Started with r207001.

[Bug target/60071] [4.9 Regression] [SH] internal compiler error: in final_scan_insn, at final.c:2963

[olegendo at gcc dot gnu.org]

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

--- Comment #8 from Oleg Endo  ---
Author: olegendo
Date: Sat Mar  1 13:16:37 2014
New Revision: 208242

URL: http://gcc.gnu.org/viewcvs?rev=208242&root=gcc&view=rev
Log:
PR target/60071
* config/sh/sh.md (*mov_t_msb_neg): Split into ...
(*mov_t_msb_neg_negc): ... this new insn.

PR target/60071
* gcc.c-torture/compile/pr60071.c: New.


Added:
trunk/gcc/testsuite/gcc.c-torture/compile/pr60071.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/sh/sh.md
trunk/gcc/testsuite/ChangeLog

[Bug fortran/60370] TRANSPOSE on rhs of allocatable array assignment gives error with -fcheck=bounds

[janus at gcc dot gnu.org]

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

janus at gcc dot gnu.org changed:

   What|Removed |Added

   Keywords||diagnostic, wrong-code
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2014-03-01
 CC||janus at gcc dot gnu.org
Summary|TRANSPOSE on rhs of |TRANSPOSE on rhs of
   |allocatable array   |allocatable array
   |assignment gives bounds |assignment gives error with
   |error   |-fcheck=bounds
 Ever confirmed|0   |1

--- Comment #1 from janus at gcc dot gnu.org ---
With 4.7/4.8/trunk I get on x86_64-unknown-linux-gnu:

At line 10 of file c0.f90
Fortran runtime error: Array bound mismatch for dimension 1 of array 'b' (0/5)


With 4.6 I get:

At line 10 of file c0.f90
Fortran runtime error: Array bound mismatch for dimension 1 of array 'b'
(140735200374865/5)

(with large random numbers)

[Bug c++/58845] [4.8/4.9 Regression] Operator || and && broken for vectors

[jason at gcc dot gnu.org]

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

Jason Merrill  changed:

   What|Removed |Added

 CC||jason at gcc dot gnu.org

--- Comment #15 from Jason Merrill  ---
(In reply to Richard Biener from comment #5)
>  (v1 != { 0, 0, ... }) & (v2 != { 0, 0, ... })

FWIW this seems to be what clang does, without any kind of sequence point.

I'm not sure why fixing this would need to wait for stage 1; it looks to me
like your patch shouldn't affect the behavior of anything that currently works.
 I suppose figuring out what semantics we want is the important part.

I'm going to go ahead and fix the ICE to get the regression out of the way.

[Bug fortran/60378] ICE on attempt to print null of derived type with unlimited polymorphic component

[janus at gcc dot gnu.org]

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

janus at gcc dot gnu.org changed:

   What|Removed |Added

 CC||janus at gcc dot gnu.org

--- Comment #1 from janus at gcc dot gnu.org ---
I can confirm the ICE with 4.8, but trunk gives:

  print *,null(mold=x)
  1
Error: Invalid context for NULL () intrinsic at (1)


which I guess is correct.

[Bug c++/58845] [4.8/4.9 Regression] Operator || and && broken for vectors

[jason at gcc dot gnu.org]

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

--- Comment #16 from Jason Merrill  ---
Author: jason
Date: Sat Mar  1 14:14:25 2014
New Revision: 208243

URL: http://gcc.gnu.org/viewcvs?rev=208243&root=gcc&view=rev
Log:
PR c++/58845
* typeck.c (cp_build_binary_op): Sorry on vector&&vector.

Added:
trunk/gcc/testsuite/g++.dg/ext/vector27.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/typeck.c

[Bug target/60071] [4.9 Regression] [SH] internal compiler error: in final_scan_insn, at final.c:2963

[olegendo at gcc dot gnu.org]

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

Oleg Endo  changed:

   What|Removed |Added

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

--- Comment #9 from Oleg Endo  ---
Fixed on trunk (4.9).

[Bug target/60111] [SH] ICE compiling Newlib

[olegendo at gcc dot gnu.org]

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

--- Comment #2 from Oleg Endo  ---
In gen_ashift the assert
gcc_assert (satisfies_constraint_P27 (n_rtx));

fires, which means that the requested shift amount is not 1, 2, 8 or 16.

In gen_shifty_hi_op the function gen_ashift is invoked with the shift amount
values taken from the ext_ashl_lshr_seq table, which contains the allowed shift
amounts only.
I don't see a problem in sh.c.  Maybe it's a indeed a problem of the host
compiler.

[Bug debug/60380] New: [C++11] ICE: in gen_type_die_with_usage with -g and template instantiation

[bcmpinc at hotmail dot com]

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

Bug ID: 60380
   Summary: [C++11] ICE: in gen_type_die_with_usage with -g and
template instantiation
   Product: gcc
   Version: 4.8.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: debug
  Assignee: unassigned at gcc dot gnu.org
  Reporter: bcmpinc at hotmail dot com

Created attachment 32237
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=32237&action=edit
A minimal testcase triggering the ICE

GCC crashes with an ICE, when trying to generate the debug information of a
template class that contains a function that cannot be instantiated due to
substitution failure.

A minimal testcase and compiler output are attached. The testcase was compiled
with:

g++ -v -save-temps -std=c++11 -g testcase.cpp 2> output.txt

[Bug c++/58845] [4.8/4.9 Regression] Operator || and && broken for vectors

[glisse at gcc dot gnu.org]

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

--- Comment #17 from Marc Glisse  ---
(In reply to Jason Merrill from comment #15)
> (In reply to Richard Biener from comment #5)
> >  (v1 != { 0, 0, ... }) & (v2 != { 0, 0, ... })
> 
> FWIW this seems to be what clang does, without any kind of sequence point.

Yes, and that's what OpenCL says, but since we have already started
diverging...

> I suppose figuring out what semantics we want is the important part.

Well, I am ok with the semantics of my patch (explained in comment #14) ;-)
(I would probably be ok with other versions as well though)

For the implementation, I have a slight preference for the #if 1 version in the
patch, but I am not sure if it is better (3 lines are unnecessary in the #else
version, so they both have the same size).

Also, some error messages could be surprising (talk about '==' when the program
uses '!'), but that's not the only place in the compiler where it happens.

> I'm going to go ahead and fix the ICE to get the regression out of the way.

Thanks!

[Bug debug/60380] [C++11] ICE: in gen_type_die_with_usage with -g and template instantiation

[bcmpinc at hotmail dot com]

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

--- Comment #1 from Bauke Conijn  ---
Created attachment 32238
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=32238&action=edit
Compiler output

[Bug debug/60380] [C++11] ICE: in gen_type_die_with_usage with -g and template instantiation

[bcmpinc at hotmail dot com]

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

--- Comment #2 from Bauke Conijn  ---
Bug 53756 is possibly related.

[Bug fortran/60370] TRANSPOSE on rhs of allocatable array assignment gives error with -fcheck=bounds

[anlauf at gmx dot de]

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

Harald Anlauf  changed:

   What|Removed |Added

 CC||anlauf at gmx dot de

--- Comment #2 from Harald Anlauf  ---
PR52162 might be related.  Running the code under comment #0 under
valgrind, I get:

==31023== Memcheck, a memory error detector
==31023== Copyright (C) 2002-2010, and GNU GPL'd, by Julian Seward et al.
==31023== Using Valgrind-3.6.1 and LibVEX; rerun with -h for copyright info
==31023== Command: ./a.out
==31023== 
==31023== Conditional jump or move depends on uninitialised value(s)
==31023==at 0x8049D22: MAIN__ (pr60370.f90:10)
==31023==by 0x804A16E: main (pr60370.f90:12)
==31023== 
==31023== Conditional jump or move depends on uninitialised value(s)
==31023==at 0x8049D59: MAIN__ (pr60370.f90:10)
==31023==by 0x804A16E: main (pr60370.f90:12)
==31023== 
==31023== Conditional jump or move depends on uninitialised value(s)
==31023==at 0x8049D90: MAIN__ (pr60370.f90:10)
==31023==by 0x804A16E: main (pr60370.f90:12)
==31023== 
==31023== Conditional jump or move depends on uninitialised value(s)
==31023==at 0x8049DC7: MAIN__ (pr60370.f90:10)
==31023==by 0x804A16E: main (pr60370.f90:12)
==31023== 
==31023== Conditional jump or move depends on uninitialised value(s)
==31023==at 0x8049E02: MAIN__ (pr60370.f90:10)
==31023==by 0x804A16E: main (pr60370.f90:12)
==31023== 
At line 10 of file pr60370.f90
Fortran runtime error: ==31023== Conditional jump or move depends on
uninitialised value(s)

etc.

[Bug c++/50025] [DR 1288] C++0x initialization syntax doesn't work for class members of reference type

[3dw4rd at verizon dot net]

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

--- Comment #15 from Ed Smith-Rowland <3dw4rd at verizon dot net> ---
I agree.  My examples are working.

Unfortunately, my account seems to not have the permissions to close a bug.  I
am a maintainer.

Any ideas how I can get such permissions set?


Now if only I can remember what libstdc++ ctor I had to have one paren init
amongst all the other brace inits that annoyed me enough to post this error!
;-)

[Bug c++/50025] [DR 1288] C++0x initialization syntax doesn't work for class members of reference type

[3dw4rd at verizon dot net]

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

--- Comment #16 from Ed Smith-Rowland <3dw4rd at verizon dot net> ---
Sorry for the noise.  I reported a dupe not this bug.

My question on permissions still stands though.

[Bug c++/50025] [DR 1288] C++0x initialization syntax doesn't work for class members of reference type

[glisse at gcc dot gnu.org]

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

--- Comment #17 from Marc Glisse  ---
(In reply to Ed Smith-Rowland from comment #15)
> Unfortunately, my account seems to not have the permissions to close a bug. 
> I am a maintainer.
> 
> Any ideas how I can get such permissions set?

You need to log in with an @gcc.gnu.org email address.

[Bug fortran/60378] ICE on attempt to print null of derived type with unlimited polymorphic component

[kargl at gcc dot gnu.org]

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

kargl at gcc dot gnu.org changed:

   What|Removed |Added

 CC||kargl at gcc dot gnu.org

--- Comment #2 from kargl at gcc dot gnu.org ---
(In reply to janus from comment #1)
> I can confirm the ICE with 4.8, but trunk gives:
> 
>   print *,null(mold=x)
>   1
> Error: Invalid context for NULL () intrinsic at (1)
> 
> 
> which I guess is correct.

According to F2008 (above Note 9.33), "If an output item is
a pointer, it shall be associated with a target and data are
transferred from the target to the file."

Given that NULL() is used to disassociated a point, I would 
say that the error message is correct.

[Bug fortran/60370] TRANSPOSE on rhs of allocatable array assignment gives error with -fcheck=bounds

[mikael at gcc dot gnu.org]

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

Mikael Morin  changed:

   What|Removed |Added

 CC||mikael at gcc dot gnu.org

--- Comment #3 from Mikael Morin  ---
The array reallocation code must come before the bound checking code, but after
the loop bounds evaluation code.  However, at the time of reallocation
generation the two last codes have already been put in one single block.

The following doesn't work because the array reallocation code uses the loop
bounds so reallocation can't come before loop bounds evaluation.


diff --git a/gcc/fortran/trans-expr.c b/gcc/fortran/trans-expr.c
index 1e156ff..00b1459 100644
--- a/gcc/fortran/trans-expr.c
+++ b/gcc/fortran/trans-expr.c
@@ -8044,7 +8044,7 @@ gfc_trans_assignment_1 (gfc_expr * expr1, gfc_expr *
expr2, bool init_flag,
  ompws_flags &= ~OMPWS_SCALARIZER_WS;
  tmp = gfc_alloc_allocatable_for_assignment (&loop, expr1, expr2);
  if (tmp != NULL_TREE)
-   gfc_add_expr_to_block (&loop.code[expr1->rank - 1], tmp);
+   gfc_prepend_expr_to_block (&loop.pre, tmp);
}

   /* Generate the copying loops.  */

[Bug c++/2316] g++ fails to overload on language linkage

[harald at gigawatt dot nl]

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

Harald van Dijk  changed:

   What|Removed |Added

 CC||harald at gigawatt dot nl

--- Comment #48 from Harald van Dijk  ---
(In reply to Marc Glisse from comment #39)
> Created attachment 26237 [details]
> remember linkage of a function type (5)

I've been experimenting with this (although updated to more recent GCC), and
one issue I see, functionality-wise, is what happens when an extern "C"
function declaration is followed by a function definition without extern "C"
being specified:

extern "C" {
typedef void (*fpt)();
void f();
}
fpt x = f;
void f() { }
fpt y = f;

The initialisation of x is correctly silently accepted, but the initialisation
of y warns about an invalid conversion.

As I understand the standard, if the first declaration specifies language
linkage, that language linkage is remembered, even if later declarations omit
it. The name f does keep C linkage (as seen by nm), but its type loses it.

Note: it is possible that I made a mistake when updating to newer GCC.

[Bug c++/58845] [4.8/4.9 Regression] Operator || and && broken for vectors

[jason at gcc dot gnu.org]

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

--- Comment #18 from Jason Merrill  ---
Author: jason
Date: Sat Mar  1 18:44:25 2014
New Revision: 208246

URL: http://gcc.gnu.org/viewcvs?rev=208246&root=gcc&view=rev
Log:
PR c++/58845
* typeck.c (cp_build_binary_op): Sorry on vector&&vector.

Added:
branches/gcc-4_8-branch/gcc/testsuite/g++.dg/ext/vector27.C
Modified:
branches/gcc-4_8-branch/gcc/cp/ChangeLog
branches/gcc-4_8-branch/gcc/cp/typeck.c

[Bug c++/60182] g++ segfault within template expansion using "using" aliasing

[jason at gcc dot gnu.org]

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

--- Comment #5 from Jason Merrill  ---
Author: jason
Date: Sat Mar  1 18:43:30 2014
New Revision: 208245

URL: http://gcc.gnu.org/viewcvs?rev=208245&root=gcc&view=rev
Log:
PR c++/60182
* pt.c (unify): Ignore alias templates when deducing a template
template parameter.

Added:
branches/gcc-4_8-branch/gcc/testsuite/g++.dg/cpp0x/alias-decl-41.C
Modified:
branches/gcc-4_8-branch/gcc/cp/ChangeLog
branches/gcc-4_8-branch/gcc/cp/pt.c

[Bug c++/60146] [4.8 Regression] ICE when compiling this code with -fopenmp

[jason at gcc dot gnu.org]

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

--- Comment #7 from Jason Merrill  ---
Author: jason
Date: Sat Mar  1 18:43:24 2014
New Revision: 208244

URL: http://gcc.gnu.org/viewcvs?rev=208244&root=gcc&view=rev
Log:
PR c++/60146
* pt.c (tsubst_omp_for_iterator): Don't let substitution of the
DECL_EXPR initialize a non-class iterator.


Conflicts:
gcc/cp/pt.c

Added:
branches/gcc-4_8-branch/gcc/testsuite/g++.dg/gomp/for-20.C
Modified:
branches/gcc-4_8-branch/gcc/cp/ChangeLog
branches/gcc-4_8-branch/gcc/cp/pt.c

[Bug c++/58845] Operator || and && broken for vectors

[jason at gcc dot gnu.org]

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

Jason Merrill  changed:

   What|Removed |Added

   Keywords|ice-on-invalid-code |rejects-valid
   Priority|P2  |P3
   Target Milestone|4.8.3   |---
Summary|[4.8/4.9 Regression]|Operator || and && broken
   |Operator || and && broken   |for vectors
   |for vectors |

--- Comment #19 from Jason Merrill  ---
No longer a regression.

[Bug c++/2316] g++ fails to overload on language linkage

[glisse at gcc dot gnu.org]

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

--- Comment #49 from Marc Glisse  ---
(In reply to Harald van Dijk from comment #48)
> I've been experimenting with this (although updated to more recent GCC), and
> one issue I see, functionality-wise, is what happens when an extern "C"
> function declaration is followed by a function definition without extern "C"
> being specified:

The examples in [dcl.link] seem to agree with your interpretation. It is likely
that I missed several cases like this one. As you can see, I haven't worked on
this in more than 2 years, and I don't think I'll work on it again any time
soon, so feel free to take over (and don't hesitate to consider large pieces of
my patch as nonsense). Fixing this particular issue should not be too hard,
there must be a place in the compiler that merges a number of properties from
the early declaration into the definition, and we need to add extern "C" to
that list.

[Bug c++/60182] g++ segfault within template expansion using "using" aliasing

[jason at gcc dot gnu.org]

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

Jason Merrill  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
  Known to work||4.8.3
 Resolution|--- |FIXED
   Target Milestone|4.7.4   |4.8.3
  Known to fail|4.8.3   |

--- Comment #6 from Jason Merrill  ---
Fixed for 4.8.3 as well.

[Bug c++/60146] [4.8 Regression] ICE when compiling this code with -fopenmp

[jason at gcc dot gnu.org]

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

Jason Merrill  changed:

   What|Removed |Added

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

--- Comment #8 from Jason Merrill  ---
Fixed for 4.8.3.

[Bug c++/60379] [4.9 Regression] pugixml build failure caused by r207001

[jason at gcc dot gnu.org]

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

Jason Merrill  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2014-03-01
   Assignee|unassigned at gcc dot gnu.org  |jason at gcc dot gnu.org
 Ever confirmed|0   |1

[Bug fortran/60370] TRANSPOSE on rhs of allocatable array assignment gives error with -fcheck=bounds

[mikael at gcc dot gnu.org]

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

--- Comment #4 from Mikael Morin  ---
Created attachment 32239
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=32239&action=edit
Tentative patch moving realloc code before bound checking

This patch doesn't work, so it may not be a code ordering issue after all.

[Bug c++/60379] [4.9 Regression] pugixml build failure caused by r207001

[jason at gcc dot gnu.org]

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

--- Comment #1 from Jason Merrill  ---
Author: jason
Date: Sat Mar  1 19:40:33 2014
New Revision: 208247

URL: http://gcc.gnu.org/viewcvs?rev=208247&root=gcc&view=rev
Log:
PR c++/60379
* semantics.c (begin_maybe_infinite_loop): Use
fold_non_dependent_expr_sfinae.

Added:
trunk/gcc/testsuite/g++.dg/template/loop1.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/semantics.c

[Bug fortran/60378] ICE on attempt to print null of derived type with unlimited polymorphic component

[janus at gcc dot gnu.org]

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

janus at gcc dot gnu.org changed:

   What|Removed |Added

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

--- Comment #3 from janus at gcc dot gnu.org ---
Ok, so let's close this, since it's fixed on trunk.

[Bug c++/50025] [DR 1288] C++0x initialization syntax doesn't work for class members of reference type

[emsr at gcc dot gnu.org]

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

emsr at gcc dot gnu.org changed:

   What|Removed |Added

 CC||emsr at gcc dot gnu.org

--- Comment #18 from emsr at gcc dot gnu.org ---
Created attachment 32240
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=32240&action=edit
This is a test case for c++/50025.

This just has simple classes with various reference member and verifies that
using brace-initialization is accepted.  I put it under g++.dg/cpp0x.

Would anyone like more test cases?

If this passes on x86_64-linux I think I'll close this with the test case
patch.

OK?

[Bug fortran/60341] [4.7/4.8/4.9 Regression] ICE compiling Nonmem 6.2.0

[mikael at gcc dot gnu.org]

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

Mikael Morin  changed:

   What|Removed |Added

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

--- Comment #9 from Mikael Morin  ---
I'm taking care of this.

[Bug c++/60379] [4.9 Regression] pugixml build failure caused by r207001

[jason at gcc dot gnu.org]

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

Jason Merrill  changed:

   What|Removed |Added

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

--- Comment #2 from Jason Merrill  ---
Fixed.

[Bug c++/50025] [DR 1288] C++0x initialization syntax doesn't work for class members of reference type

[jason at gcc dot gnu.org]

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

--- Comment #19 from Jason Merrill  ---
Sounds good.

[Bug fortran/60341] [4.7/4.8/4.9 Regression] ICE compiling Nonmem 6.2.0

[mikael at gcc dot gnu.org]

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

--- Comment #10 from Mikael Morin  ---
Author: mikael
Date: Sat Mar  1 21:14:54 2014
New Revision: 208249

URL: http://gcc.gnu.org/viewcvs?rev=208249&root=gcc&view=rev
Log:
fortran/
PR fortran/60341
* frontend-passes.c (optimize_comparison): Guard two union
accesses with the corresponding tag checks.

testsuite/
PR fortran/60341
* gfortran.dg/str_comp_optimize_1.f90: New test.


Added:
trunk/gcc/testsuite/gfortran.dg/str_comp_optimize_1.f90
Modified:
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/frontend-passes.c
trunk/gcc/testsuite/ChangeLog

[Bug middle-end/60381] New: [4.9 Regression] ICE: in vt_expand_var_loc_chain, at var-tracking.c:8245

[danglin at gcc dot gnu.org]

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

Bug ID: 60381
   Summary: [4.9 Regression] ICE: in vt_expand_var_loc_chain, at
var-tracking.c:8245
   Product: gcc
   Version: 4.9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
  Assignee: unassigned at gcc dot gnu.org
  Reporter: danglin at gcc dot gnu.org
CC: aoliva at gcc dot gnu.org
  Host: hppa-unknown-linux-gnu
Target: hppa-unknown-linux-gnu
 Build: hppa-unknown-linux-gnu

Created attachment 32241
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=32241&action=edit
Preprocessed source

/home/dave/gnu/gcc/objdir/./gcc/xgcc -B/home/dave/gnu/gcc/objdir/./gcc/
-B/home/
dave/opt/gnu/gcc/gcc-4.9/hppa-linux-gnu/bin/
-B/home/dave/opt/gnu/gcc/gcc-4.9/hppa-linux-gnu/lib/ -isystem
/home/dave/opt/gnu/gcc/gcc-4.9/hppa-linux-gnu/include -isystem
/home/dave/opt/gnu/gcc/gcc-4.9/hppa-linux-gnu/sys-include-g -O2 -O
2  -g -O2 -DIN_GCC-W -Wall -Wwrite-strings -Wcast-qual -Wno-format
-Wstrict-
prototypes -Wmissing-prototypes -Wold-style-definition  -isystem ./include  
-fPIC -DELF=1 -DLINUX=1 -g -DIN_LIBGCC2 -fbuilding-libgcc -fno-stack-protector 
 -fPIC -DELF=1 -DLINUX=1 -I. -I. -I../.././gcc -I../../../gcc/libgcc
-I../../../gcc
/libgcc/. -I../../../gcc/libgcc/../gcc -I../../../gcc/libgcc/../include 
-DHAVE_
CC_TLS  -o _divdc3.o -MT _divdc3.o -MD -MP -MF _divdc3.dep -DL_divdc3 -c
../../.
./gcc/libgcc/libgcc2.c -fvisibility=hidden -DHIDE_EXPORTS
../../../gcc/libgcc/libgcc2.c: In function ‘__muldc3’:
../../../gcc/libgcc/libgcc2.c:2001:1: internal compiler error: in
vt_expand_var_
loc_chain, at var-tracking.c:8245
 }
0xd07623 vt_expand_var_loc_chain
../../gcc/gcc/var-tracking.c:8245
0xd0823b vt_expand_loc_callback
../../gcc/gcc/var-tracking.c:8441
0x3caa57 cselib_expand_value_rtx_1
../../gcc/gcc/cselib.c:1692
0x3cacdb cselib_expand_value_rtx_1
../../gcc/gcc/cselib.c:1730
0x3ca46f cselib_expand_value_rtx_cb(rtx_def*, bitmap_head*, int, rtx_def*
(*)(rtx_def*, bitmap_head*, int, void*), void*)
../../gcc/gcc/cselib.c:1539
0xd0775f vt_expand_var_loc_chain
../../gcc/gcc/var-tracking.c:8279
0xd0823b vt_expand_loc_callback
../../gcc/gcc/var-tracking.c:8441
0x3caa57 cselib_expand_value_rtx_1
../../gcc/gcc/cselib.c:1692
0x3cacdb cselib_expand_value_rtx_1
../../gcc/gcc/cselib.c:1730
0x3ca46f cselib_expand_value_rtx_cb(rtx_def*, bitmap_head*, int, rtx_def*
(*)(rtx_def*, bitmap_head*, int, void*), void*)
../../gcc/gcc/cselib.c:1539
0xd0775f vt_expand_var_loc_chain
../../gcc/gcc/var-tracking.c:8279
0xd0823b vt_expand_loc_callback
../../gcc/gcc/var-tracking.c:8441
0x3caa57 cselib_expand_value_rtx_1
../../gcc/gcc/cselib.c:1692
0x3ca46f cselib_expand_value_rtx_cb(rtx_def*, bitmap_head*, int, rtx_def*
(*)(rtx_def*, bitmap_head*, int, void*), void*)
../../gcc/gcc/cselib.c:1539
0xd0775f vt_expand_var_loc_chain
../../gcc/gcc/var-tracking.c:8279
0xd0880b vt_expand_1pvar
../../gcc/gcc/var-tracking.c:8554
0xd08b0f emit_note_insn_var_location(variable_def**, emit_note_data_def*)
../../gcc/gcc/var-tracking.c:8608
0xd116df void hash_table::traverse_noresize(emit_note_data_def*)
../../gcc/gcc/hash-table.h:928
0xd105e7 void hash_table::traverse(emit_note_data_def*)
../../gcc/gcc/hash-table.h:950
0xd0a46f emit_notes_for_changes
../../gcc/gcc/var-tracking.c:8970
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.
make[3]: *** [_muldc3.o] Error 1

Introduced in revision 208220.

[Bug c++/60377] [c++1y] ICE with invalid function parameter in conjunction with auto parameter

[abutcher at gcc dot gnu.org]

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

--- Comment #1 from Adam Butcher  ---
Author: abutcher
Date: Sat Mar  1 21:28:18 2014
New Revision: 208250

URL: http://gcc.gnu.org/viewcvs?rev=208250&root=gcc&view=rev
Log:
Fix PR c++/60377.

PR c++/60377
* parser.c (cp_parser_parameter_declaration_clause): Unwind generic
function scope on parse error in function parameter list.

PR c++/60377
* g++.dg/cpp1y/pr60377.C: New testcase.

Added:
trunk/gcc/testsuite/g++.dg/cpp1y/pr60377.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/parser.c
trunk/gcc/testsuite/ChangeLog

[Bug middle-end/60381] [4.9 Regression] ICE: in vt_expand_var_loc_chain, at var-tracking.c:8245

[danglin at gcc dot gnu.org]

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

--- Comment #1 from John David Anglin  ---
(gdb) r
Starting program: /home/dave/gnu/gcc/objdir/hppa-linux-gnu/libgcc/../../gcc/cc1
-fpreprocessed libgcc2.i -quiet -dumpbase libgcc2.c -auxbase-strip _divdc3.o -g
-g -g -O2 -O2 -O2 -Wextra -Wall -Wwrite-strings -Wcast-qual -Wformat=0
-Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition -version
-fbuilding-libgcc -fno-stack-protector -fPIC -fvisibility=hidden -o libgcc2.s
GNU C (GCC) version 4.9.0 20140228 (experimental) [trunk revision 208220]
(hppa-linux-gnu)
compiled by GNU C version 4.6.4, GMP version 5.1.3, MPFR version 3.1.2-p3,
MPC version 1.0.1
GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096
GNU C (GCC) version 4.9.0 20140228 (experimental) [trunk revision 208220]
(hppa-linux-gnu)
compiled by GNU C version 4.6.4, GMP version 5.1.3, MPFR version 3.1.2-p3,
MPC version 1.0.1
GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096
Compiler executable checksum: e5ddc5eadc758a9e6fcf473bee448b45

Breakpoint 1, vt_expand_var_loc_chain (var=0x14df4d0, regs=0x14817ac, 
data=0xfaf02d4c, pendrecp=0xfaf03610) at ../../gcc/gcc/var-tracking.c:8245
8245  gcc_checking_assert (cselib_preserved_value_p (val));
(gdb) p val
$1 = (cselib_val *) 0x14bce80
(gdb) p *val
$2 = {hash = 7, uid = 7, val_rtx = 0x14ddda0, locs = 0x0, addr_list = 0x0, 
  next_containing_mem = 0x0}
(gdb) p debug_rtx (val->val_rtx)
(value/f/i:SI 7:7 @0x14ddda0/0x14bce80)
$3 = void

[Bug c++/58567] [4.8 Regression] ICE with invalid loop variable in template using openmp

[reichelt at gcc dot gnu.org]

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

Volker Reichelt  changed:

   What|Removed |Added

   Target Milestone|4.9.0   |4.8.3

--- Comment #6 from Volker Reichelt  ---
Now also fixed on the 4.8 branch for 4.8.3.
Probably due to Jason's patch for PR60146.

[Bug tree-optimization/60382] New: ICE on valid code at -O3 on x86_64-linux-gnu (in vect_create_epilog_for_reduction, at tree-vect-loop.c:4352)

[su at cs dot ucdavis.edu]

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

Bug ID: 60382
   Summary: ICE on valid code at -O3 on x86_64-linux-gnu (in
vect_create_epilog_for_reduction, at
tree-vect-loop.c:4352)
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: su at cs dot ucdavis.edu

The following code causes an ICE when compiled with the current gcc trunk at
-O3 on x86_64-linux-gnu (in both 32-bit and 64-bit modes). 

It also seems to affect the current 4.8 branch, but not GCC 4.8.2. 

$ gcc-trunk -v
Using built-in specs.
COLLECT_GCC=gcc-trunk
COLLECT_LTO_WRAPPER=/usr/local/gcc-trunk/libexec/gcc/x86_64-unknown-linux-gnu/4.9.0/lto-wrapper
Target: x86_64-unknown-linux-gnu
Configured with: ../gcc-trunk/configure --prefix=/usr/local/gcc-trunk
--enable-languages=c,c++ --disable-werror --enable-multilib
Thread model: posix
gcc version 4.9.0 20140301 (experimental) [trunk revision 208241] (GCC) 
$ 
$ gcc-trunk -O2 small.c; a.out
$ gcc-4.8.2 -O3 small.c; a.out
$ 
$ gcc-trunk -O3 small.c
small.c: In function ‘foo’:
small.c:4:1: internal compiler error: in vect_create_epilog_for_reduction, at
tree-vect-loop.c:4495
 foo ()
 ^
0xb66aa1 vect_create_epilog_for_reduction
../../gcc-trunk/gcc/tree-vect-loop.c:4493
0xb64c04 vectorizable_reduction(gimple_statement_base*, gimple_stmt_iterator*,
gimple_statement_base**, _slp_tree*)
../../gcc-trunk/gcc/tree-vect-loop.c:5344
0xb5656a vect_transform_stmt(gimple_statement_base*, gimple_stmt_iterator*,
bool*, _slp_tree*, _slp_instance*)
../../gcc-trunk/gcc/tree-vect-stmts.c:7226
0xb5acee vect_transform_loop(_loop_vec_info*)
../../gcc-trunk/gcc/tree-vect-loop.c:6054
0xb78f6b vectorize_loops()
../../gcc-trunk/gcc/tree-vectorizer.c:476
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See <http://gcc.gnu.org/bugs.html> for instructions.
$ 


---


int a, b, c, e, f; 

void
foo ()
{
  for (b = 0; b < 3; b++)
if (e)
  {
for (c = 0; c < 4; c++)
  {
if (b)
  continue;
f = 1;
for (a = 0; a < 2; a++)
  f |= 1; 
  }
for (;;) 
  ;
  }
}

int
main ()
{
  foo (); 
  return 0;
}

[Bug c++/60383] New: [4.8 Regression] ICE with invalid template specialization

[reichelt at gcc dot gnu.org]

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

Bug ID: 60383
   Summary: [4.8 Regression] ICE with invalid template
specialization
   Product: gcc
   Version: 4.9.0
Status: UNCONFIRMED
  Keywords: error-recovery, ice-on-invalid-code
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: reichelt at gcc dot gnu.org

The following invalid testcase triggers an ICE on trunk:

==
template struct A
{
  template struct B
  {
template struct B {};
  };
};

A<0>::B b;
==

bug.cc:5:33: error: specialization of 'template >
template struct A< >::B' must appear at namespace scope
 template struct B {};
 ^
bug.cc:5:33: internal compiler error: in retrieve_specialization, at
cp/pt.c:1039
0x6067b0 retrieve_specialization
../../gcc/gcc/cp/pt.c:1036
0x62ff67 tsubst_decl
../../gcc/gcc/cp/pt.c:10351
0x61ecdf tsubst(tree_node*, tree_node*, int, tree_node*)
../../gcc/gcc/cp/pt.c:11489
0x63f2f1 most_specialized_class
../../gcc/gcc/cp/pt.c:18832
0x64ecf9 instantiate_class_template_1
../../gcc/gcc/cp/pt.c:8867
0x64ecf9 instantiate_class_template(tree_node*)
../../gcc/gcc/cp/pt.c:9399
0x6e1d83 complete_type(tree_node*)
../../gcc/gcc/cp/typeck.c:134
0x5c8e58 start_decl_1(tree_node*, bool)
../../gcc/gcc/cp/decl.c:4719
0x5f1ef7 start_decl(cp_declarator const*, cp_decl_specifier_seq*, int,
tree_node*, tree_node*, tree_node**)
../../gcc/gcc/cp/decl.c:4682
0x6ce2be cp_parser_init_declarator
../../gcc/gcc/cp/parser.c:16684
0x6cfd49 cp_parser_simple_declaration
../../gcc/gcc/cp/parser.c:11205
0x6b3003 cp_parser_block_declaration
../../gcc/gcc/cp/parser.c:11086
0x6da2d2 cp_parser_declaration
../../gcc/gcc/cp/parser.c:10983
0x6d8fc8 cp_parser_declaration_seq_opt
../../gcc/gcc/cp/parser.c:10869
0x6da87a cp_parser_translation_unit
../../gcc/gcc/cp/parser.c:4014
0x6da87a c_parse_file()
../../gcc/gcc/cp/parser.c:31590
0x7fa103 c_common_parse_file()
../../gcc/gcc/c-family/c-opts.c:1060
Please submit a full bug report, [etc.]

[Bug c++/60383] [4.8 Regression] ICE with invalid template specialization

[reichelt at gcc dot gnu.org]

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

Volker Reichelt  changed:

   What|Removed |Added

  Known to work||4.5.0, 4.6.0, 4.7.0, 4.8.0
   Target Milestone|--- |4.9.0
  Known to fail||4.9.0

[Bug target/58897] Improve 128/64 division

[glisse at gcc dot gnu.org]

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

--- Comment #1 from Marc Glisse  ---
Untested, but this shows what the 128/64 division could look like (with obvious
variants for mod and divmod). I don't really know how to get gcc to generate
anything like that though. I have seen udivmodtidi3 in s390 but that seems to
return (ql,r) packed in an __int128, not what I want. And gcc doesn't show
ul->ux as a zero_extend and forgets extremely fast the REG_EQUAL note on the
call to __udivti3, so I can't rely on combine.

typedef unsigned __int128 ux;
typedef unsigned long ul;
#define udiv_qrnnd(q, r, n1, n0, dx) \
  __asm__ ("divq %4" : "=a" (q), "=d" (r) \
  : "0" ((ul)(n0)), "1" ((ul)(n1)), "rm" ((ul)(dx)))
ux div128by64(ux a, ul b){
  ul ah = a >> 64;
  ul al = a;
  ul qh, ql, r1, r;
  qh=ah/b; r1=ah%b;
  udiv_qrnnd(ql,r,r1,al,b);
  return (ux)qh << 64 | ql;
}

/*
a=ah*2^64+al
ah=qh*b+r1
a=qh*2^64*b+r1*2^64+al
r1*2^64+al<2^64*b
r1*2^64+al=ql*b+r
a=(qh*2^64+ql)*b+r
*/

[Bug c++/53492] [4.7/4.8/4.9 Regression] ICE in retrieve_specialization, at cp/pt.c:985

[reichelt at gcc dot gnu.org]

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

Volker Reichelt  changed:

   What|Removed |Added

   Keywords||accepts-invalid
   Last reconfirmed|2012-05-26 00:00:00 |2014-03-01
 CC||reichelt at gcc dot gnu.org
   Target Milestone|--- |4.7.4
Summary|internal compiler error: in |[4.7/4.8/4.9 Regression]
   |retrieve_specialization, at |ICE in
   |cp/pt.c:985 |retrieve_specialization, at
   ||cp/pt.c:985

--- Comment #4 from Volker Reichelt  ---
Here's an even simpler testcase:

=
template struct A
{
  template struct B;
};

template<> template struct A::B
{
  B(int) {}
};

A::B b;
=

It crashes since GCC 4.0.0, but was correctly rejected before.
So this qualifies as a regression.

A slightly modified and still invalid testcase also crashes since GCC 4.0.0
but was wrongly accepted before:

=
template struct A
{
  template struct B;
};

template<> template struct A::B
{
  B() {}
};

A::B b;
=

Another variation is wrongly accepted since at least GCC 3.2:

=
template struct A
{
  template struct B;
};

template<> template struct A::B {};

A::B b;
=

[Bug c++/50025] [DR 1288] C++0x initialization syntax doesn't work for class members of reference type

[emsr at gcc dot gnu.org]

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

--- Comment #20 from emsr at gcc dot gnu.org ---
Author: emsr
Date: Sat Mar  1 22:51:25 2014
New Revision: 208251

URL: http://gcc.gnu.org/viewcvs?rev=208251&root=gcc&view=rev
Log:
2014-03-01  Edward Smith-Rowland  <3dw...@verizon.net>

PR c++/50025
* g++.dg/cpp0x/pr50025.C: New.


Added:
trunk/gcc/testsuite/g++.dg/cpp0x/pr50025.C
Modified:
trunk/gcc/testsuite/ChangeLog

[Bug c++/50025] [DR 1288] C++0x initialization syntax doesn't work for class members of reference type

[emsr at gcc dot gnu.org]

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

emsr at gcc dot gnu.org changed:

   What|Removed |Added

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

--- Comment #21 from emsr at gcc dot gnu.org ---
Fixed.

[Bug c++/60384] New: [4.9 Regression] [c++1y] ICE with invalid typedef

[reichelt at gcc dot gnu.org]

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

Bug ID: 60384
   Summary: [4.9 Regression] [c++1y] ICE with invalid typedef
   Product: gcc
   Version: 4.9.0
Status: UNCONFIRMED
  Keywords: error-recovery, ice-on-invalid-code
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: reichelt at gcc dot gnu.org

The following invalid testcase (compiled with "-std=c++1y")
triggers an ICE on trunk:


template int foo();

struct A
{
  typedef auto foo<>();
};


bug.cc:5:22: error: typedef declared 'auto'
   typedef auto foo<>();
  ^
bug.cc:5:22: internal compiler error: tree check: expected identifier_node,
have template_id_expr in push_class_level_binding_1, at cp/name-lookup.c:3172
0xdc0f54 tree_check_failed(tree_node const*, char const*, int, char const*,
...)
../../gcc/gcc/tree.c:9192
0x784196 tree_check
../../gcc/gcc/tree.h:2709
0x784196 push_class_level_binding_1
../../gcc/gcc/cp/name-lookup.c:3172
0x784196 push_class_level_binding(tree_node*, tree_node*)
../../gcc/gcc/cp/name-lookup.c:3281
0x784339 pushdecl_class_level(tree_node*)
../../gcc/gcc/cp/name-lookup.c:3013
0x7345bf finish_member_declaration(tree_node*)
../../gcc/gcc/cp/semantics.c:2870
0x6ac95f cp_parser_member_declaration
../../gcc/gcc/cp/parser.c:20531
0x6afa84 cp_parser_member_specification_opt
../../gcc/gcc/cp/parser.c:20029
0x6afa84 cp_parser_class_specifier_1
../../gcc/gcc/cp/parser.c:19263
0x6afa84 cp_parser_class_specifier
../../gcc/gcc/cp/parser.c:19490
0x6afa84 cp_parser_type_specifier
../../gcc/gcc/cp/parser.c:14305
0x6c8fb0 cp_parser_decl_specifier_seq
../../gcc/gcc/cp/parser.c:11547
0x6cfb69 cp_parser_simple_declaration
../../gcc/gcc/cp/parser.c:11137
0x6b3003 cp_parser_block_declaration
../../gcc/gcc/cp/parser.c:11086
0x6da2d2 cp_parser_declaration
../../gcc/gcc/cp/parser.c:10983
0x6d8fc8 cp_parser_declaration_seq_opt
../../gcc/gcc/cp/parser.c:10869
0x6da87a cp_parser_translation_unit
../../gcc/gcc/cp/parser.c:4014
0x6da87a c_parse_file()
../../gcc/gcc/cp/parser.c:31590
0x7fa103 c_common_parse_file()
../../gcc/gcc/c-family/c-opts.c:1060
Please submit a full bug report, [etc.]

[Bug c++/60384] [4.9 Regression] [c++1y] ICE with invalid typedef

[reichelt at gcc dot gnu.org]

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

Volker Reichelt  changed:

   What|Removed |Added

  Known to work||4.8.0
   Target Milestone|--- |4.9.0
  Known to fail||4.9.0

[Bug fortran/60128] [4.8/4.9 Regression] Wrong ouput using en edit descriptor

[burnus at gcc dot gnu.org]

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

Tobias Burnus  changed:

   What|Removed |Added

 CC||burnus at gcc dot gnu.org

--- Comment #8 from Tobias Burnus  ---
(In reply to Dominique d'Humieres from comment #2)
> This likely due to r185433. This fixed by the following patch
...
(In reply to Dominique d'Humieres from comment #7)
> The following patch fixes the issues reported in comment 6

Dominique, Jerry: What's the status of those patch set? Can this be wrapped up
as patch for GCC 4.9? If so, it should be done soon.

[Bug fortran/60128] [4.8/4.9 Regression] Wrong ouput using en edit descriptor

[jvdelisle at gcc dot gnu.org]

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

--- Comment #9 from Jerry DeLisle  ---
I have reviewed and tested the patch from comment #7 on x86-64 with -m32 and
-m64 and I think its ready. Dominique mentioned to possibly add a volatile. I
have not tested on the other platforms.

I can commit as soon as I get the go signal.

[Bug c++/60385] New: confused by earlier errors, bailing out

[vanyacpp at gmail dot com]

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

Bug ID: 60385
   Summary: confused by earlier errors, bailing out
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: vanyacpp at gmail dot com

float foo4()
{}

namespace foo4 
{
struct bar6 
{
friend wchar_t bar1();
};
}

GCC 4.7.3

[Bug ipa/60306] [4.9 Regression] Incorrect devirtualization "pure virtual method called"

[hubicka at gcc dot gnu.org]

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

--- Comment #9 from Jan Hubicka  ---
OK, this is what I am testing for mainline now:
Index: ipa-prop.c
===
--- ipa-prop.c  (revision 208247)
+++ ipa-prop.c  (working copy)
@@ -572,7 +572,12 @@ static bool
 stmt_may_be_vtbl_ptr_store (gimple stmt)
 {
   if (is_gimple_call (stmt))
-return false;
+{
+  return ((gimple_call_lhs (stmt)
+  && AGGREGATE_TYPE_P (TREE_TYPE (gimple_call_lhs (stmt
+ || (gimple_call_fndecl (stmt)
+ && DECL_CXX_CONSTRUCTOR_P (gimple_call_fndecl (stmt;
+}
   else if (gimple_clobber_p (stmt))
 return false;
   else if (is_gimple_assign (stmt))

This will make us to punt on about every ctor sequence except case where
everything got early inlined.  I hope to get some firefox numbers - I don't
expecct it to be that bad. ipa-devirt made us less dependent on type change
detection and type change detection was never too strong anyway.

other option I did not mention is to simply revert:

2013-12-14   Jan Hubicka  

PR middle-end/58477
* ipa-prop.c (stmt_may_be_vtbl_ptr_store): Skip clobbers.

this change made the bug to trigger: by punting on all clobbers one can not mix
construction and destruction within the loop for automatic vars.

I spent some time playing with this and I think those are only ones that
matters. It seems that most of checks for dynamic type change for function
parameters are not that useful based on Jason's comment that once you get a
non-pod built you can not in-place new it to something else. Because we don't
track heap allocated objects the type is given by the type of decl the instance
lives in.

Reverting that patch seems however rather symptomatic fix.  This code is on my
TODO to rework and integrate into ipa-devirt for next stage1 anyway.

[Bug ipa/58721] [4.9 Regression] The subroutine perdida is no longer inlined in fatigue.f90

[burnus at gcc dot gnu.org]

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

--- Comment #18 from Tobias Burnus  ---
(In reply to Tobias Burnus from comment #16)
> Request for assistance/comment patch for gfortran:
> http://gcc.gnu.org/ml/gcc-patches/2013-12/msg01034.html

(In reply to Jan Hubicka from comment #17)
> Created attachment 31517 [details] Patch to extend __builtin_expect

Updated RFC patch,based on the extend-__builtin_expect patch:
http://gcc.gnu.org/ml/gcc-patches/2014-03/msg00043.html