[Bug c/57409] PIE (-fPIE -pie) prevents any malloc on Solaris 10 sparc

[jullien at eligis dot com]

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

--- Comment #2 from Christian Jullien  ---
Thanks for your quick reply yet it is not totally satisfactory.

1) if gcc does not support pie on solaris 10 sparc (I can accept that), gcc
toolchain should detect this and protest (from ./configure) if PIE can't be
used on a given platform. Using PIE flag should make gcc return an error "PIE
no supported on this platform"

2) at the same time, Todd Miller (sudo developer) was able to use PIE on a very
similar machine (see
http://www.sudo.ws/pipermail/sudo-users/2013-May/005195.html) using gcc 4.8. It
looks there is a way to make gcc work with PIE. This is configure duty to find
this way and/or advice that a configure option is missing in order to support
PIE.

3) I also may have an incorrect ./configure options I'll be glad to fix and
test

Christian

[Bug rtl-optimization/57410] New: [4.9 Regression] ICE: in emit_spill_move, at lra-constraints.c:863 with -fpeel-loops and uninitialised variable

[zsojka at seznam dot cz]

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

Bug ID: 57410
   Summary: [4.9 Regression] ICE: in emit_spill_move, at
lra-constraints.c:863 with -fpeel-loops and
uninitialised variable
   Product: gcc
   Version: 4.9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: rtl-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: zsojka at seznam dot cz

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

Compiler output:
$ gcc -O -fpeel-loops testcase.c 
testcase.c: In function 'foo':
testcase.c:9:1: internal compiler error: in emit_spill_move, at
lra-constraints.c:863
 }
 ^
0x8f5567 emit_spill_move
/mnt/svn/gcc-trunk/gcc/lra-constraints.c:862
0x8feb0d curr_insn_transform
/mnt/svn/gcc-trunk/gcc/lra-constraints.c:3033
0x8ffc94 lra_constraints(bool)
/mnt/svn/gcc-trunk/gcc/lra-constraints.c:3785
0x8ee8a3 lra(_IO_FILE*)
/mnt/svn/gcc-trunk/gcc/lra.c:2278
0x8a1c78 do_reload
/mnt/svn/gcc-trunk/gcc/ira.c:4641
0x8a1c78 rest_of_handle_reload
/mnt/svn/gcc-trunk/gcc/ira.c:4753
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.

$ gcc -v
Using built-in specs.
COLLECT_GCC=/mnt/svn/gcc-trunk/binary-latest/bin/gcc
COLLECT_LTO_WRAPPER=/mnt/svn/gcc-trunk/binary-199312-lto-fortran-checking-yes-rtl-df/libexec/gcc/x86_64-unknown-linux-gnu/4.9.0/lto-wrapper
Target: x86_64-unknown-linux-gnu
Configured with: /mnt/svn/gcc-trunk//configure --enable-checking=yes,rtl,df
--enable-languages=c,c++,lto,fortran
--prefix=/mnt/svn/gcc-trunk/binary-199312-lto-fortran-checking-yes-rtl-df/
--without-cloog --without-ppl
Thread model: posix
gcc version 4.9.0 20130524 (experimental) (GCC) 

Tested revisions:
r199312 - fail
4.8 r198018 - OK

[Bug c/57409] PIE doesn't work with GNU binutils on SPARC/Solaris

[ebotcazou at gcc dot gnu.org]

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

Eric Botcazou  changed:

   What|Removed |Added

 Status|RESOLVED|REOPENED
   Last reconfirmed||2013-05-25
 Resolution|INVALID |---
Summary|PIE (-fPIE -pie) prevents   |PIE doesn't work with GNU
   |any malloc on Solaris 10|binutils on SPARC/Solaris
   |sparc   |
 Ever confirmed|0   |1
   Severity|major   |enhancement

--- Comment #3 from Eric Botcazou  ---
> 1) if gcc does not support pie on solaris 10 sparc (I can accept that), gcc
> toolchain should detect this and protest (from ./configure) if PIE can't be
> used on a given platform. Using PIE flag should make gcc return an error
> "PIE no supported on this platform"

Maybe, but the manual is very clear:

`-pie'
 Produce a position independent executable on targets that support
 it.  For predictable results, you must also specify the same set
 of options used for compilation (`-fpie', `-fPIE', or model
 suboptions) when you specify this linker option.

so one could argue that it's up to the user to check that it works on a given
platform.

> 2) at the same time, Todd Miller (sudo developer) was able to use PIE on a
> very similar machine (see
> http://www.sudo.ws/pipermail/sudo-users/2013-May/005195.html) using gcc 4.8.
> It looks there is a way to make gcc work with PIE.

He's using the Sun tools and you're using the GNU binutils, so this may
primarily be a binutils issue.  Does it work with the Sun tools on your
machine?

[Bug target/12081] Gcc can't be compiled with -mregparm=3

[mikpe at it dot uu.se]

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

Mikael Pettersson  changed:

   What|Removed |Added

 CC||mikpe at it dot uu.se

--- Comment #20 from Mikael Pettersson  ---
Created attachment 30188
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=30188&action=edit
fix up conversion in tilepro_expand_builtin, delete unused 11-arity stuff

Looking through the patch I noticed that the conversion in
tilepro_expand_builtin was broken (icode was lost).  Grepping around I also
noticed that nothing used GEN_FCN11 (or is that used by the out-of-tree
OpenRISC port?)  This add-on fixes those two issues.

[Bug target/57118] g++.dg/debug/* tests fail on MIPS due to micromips checkin, scan-assembler pattern needs update

[rsandifo at gcc dot gnu.org]

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

rsandifo at gcc dot gnu.org  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 CC||rsandifo at gcc dot gnu.org
 Resolution|--- |FIXED

--- Comment #1 from rsandifo at gcc dot gnu.org  
---
Fixed by:

2013-05-21  Graham Stott  

* lib/scanasm.exp (dg-function-on-line): Make MIPS targets match
.set (no)?micromips

[Bug target/56021] HAVE_STBLIB_H and HAVE_LIMITS_H not defined. Can't build gcc 3.2.1

[rsandifo at gcc dot gnu.org]

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

rsandifo at gcc dot gnu.org  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 CC||rsandifo at gcc dot gnu.org
 Resolution|--- |WONTFIX

--- Comment #3 from rsandifo at gcc dot gnu.org  
---
As others have said, this is way too old, sorry.

[Bug lto/57334] ICE: in input_gimple_stmt, at gimple-streamer-in.c:287

[dimhen at gmail dot com]

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

--- Comment #2 from Dmitry G. Dyachenko  ---
gcc-4.8:
PASS:
196672 (pre-4.8.0)
199240 gcc (GCC) 4.8.1 20130523 (prerelease)

gcc-4.9:
PASS 198354
FAIL 199000, 199239

simlified testcase
$ cat a.i 
void foo ()
{
}

void bar ()
{
   return; // trigger error
}

$ cat b.i
static
void bar ()
{
}

$ cat main.ii 
extern "C" void baz ();
main ()
{
baz ();
return 0;
}

extern void foo();
void baz ()
{
foo ();
}

[Bug tree-optimization/57411] New: [4.9 Regression] ICE: verify_ssa failed: definition in block 4 does not dominate use in block 11 with -fno-tree-dce -ftree-vectorize

[zsojka at seznam dot cz]

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

Bug ID: 57411
   Summary: [4.9 Regression] ICE: verify_ssa failed: definition in
block 4 does not dominate use in block 11 with
-fno-tree-dce -ftree-vectorize
   Product: gcc
   Version: 4.9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: zsojka at seznam dot cz

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

Compiler output:
$ gcc -O -fno-tree-dce -ftree-vectorize testcase.C
testcase.C: In function 'void test01(int)':
testcase.C:15:1: error: definition in block 4 does not dominate use in block 11
 test01 (int equal)
 ^
for SSA_NAME: .MEM_44 in statement:
.MEM_1 = PHI <.MEM_44(11), .MEM_5(12)>
PHI argument
.MEM_44
for PHI node
.MEM_1 = PHI <.MEM_44(11), .MEM_5(12)>
testcase.C:15:1: internal compiler error: verify_ssa failed
0xd63bc9 verify_ssa(bool)
/mnt/svn/gcc-trunk/gcc/tree-ssa.c:1046
0xaf4b91 execute_function_todo
/mnt/svn/gcc-trunk/gcc/passes.c:1970
0xaf54e7 execute_todo
/mnt/svn/gcc-trunk/gcc/passes.c:2002
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.

$ gcc -v  
Using built-in specs.
COLLECT_GCC=/mnt/svn/gcc-trunk/binary-latest/bin/gcc
COLLECT_LTO_WRAPPER=/mnt/svn/gcc-trunk/binary-199312-lto-fortran-checking-yes-rtl-df/libexec/gcc/x86_64-unknown-linux-gnu/4.9.0/lto-wrapper
Target: x86_64-unknown-linux-gnu
Configured with: /mnt/svn/gcc-trunk//configure --enable-checking=yes,rtl,df
--enable-languages=c,c++,lto,fortran
--prefix=/mnt/svn/gcc-trunk/binary-199312-lto-fortran-checking-yes-rtl-df/
--without-cloog --without-ppl
Thread model: posix
gcc version 4.9.0 20130524 (experimental) (GCC) 

Tested revisions:
r199312 - fail
4.8 r198018 - OK

[Bug target/55876] internal compiler error: in gen_rtx_SUBREG, at emit-rtl.c:776

[rsandifo at gcc dot gnu.org]

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

rsandifo at gcc dot gnu.org  changed:

   What|Removed |Added

 CC||rsandifo at gcc dot gnu.org

--- Comment #6 from rsandifo at gcc dot gnu.org  
---
Patch applied in the 4.8 timeframe.  Thanks Tom.

[Bug c/57409] implement PIE support on Solaris

[ebotcazou at gcc dot gnu.org]

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

Eric Botcazou  changed:

   What|Removed |Added

Summary|PIE doesn't work with GNU   |implement PIE support on
   |binutils on SPARC/Solaris   |Solaris

--- Comment #4 from Eric Botcazou  ---
OK, in fact -pie is simply a no-op with the Sun linker.

[Bug middle-end/57412] New: [4.9 Regression] ICE: in verify_loop_structure, at cfgloop.c:1647: loop 1's latch does not have an edge to its header with -fopenmp -fipa-pure-const

[zsojka at seznam dot cz]

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

Bug ID: 57412
   Summary: [4.9 Regression] ICE: in verify_loop_structure, at
cfgloop.c:1647: loop 1's latch does not have an edge
to its header with -fopenmp -fipa-pure-const
   Product: gcc
   Version: 4.9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
  Assignee: unassigned at gcc dot gnu.org
  Reporter: zsojka at seznam dot cz

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

Compiler output:
$ gcc -fopenmp -fipa-pure-const testcase.C 
testcase.C: In function '':
testcase.C:8:1: error: loop 1's latch does not have an edge to its header
 }
 ^
testcase.C:8:1: internal compiler error: in verify_loop_structure, at
cfgloop.c:1647
0x8513ae verify_loop_structure()
/mnt/svn/gcc-trunk/gcc/cfgloop.c:1647
0xa7e928 loop_optimizer_init(unsigned int)
/mnt/svn/gcc-trunk/gcc/loop-init.c:110
0x12fb799 analyze_function
/mnt/svn/gcc-trunk/gcc/ipa-pure-const.c:786
0x12fbe69 generate_summary
/mnt/svn/gcc-trunk/gcc/ipa-pure-const.c:929
0xaf70de execute_ipa_summary_passes(ipa_opt_pass_d*)
/mnt/svn/gcc-trunk/gcc/passes.c:2136
0x872db0 ipa_passes
/mnt/svn/gcc-trunk/gcc/cgraphunit.c:1903
0x872db0 compile()
/mnt/svn/gcc-trunk/gcc/cgraphunit.c:1999
0x872fe9 finalize_compilation_unit()
/mnt/svn/gcc-trunk/gcc/cgraphunit.c:2127
0x685040 cp_write_global_declarations()
/mnt/svn/gcc-trunk/gcc/cp/decl2.c:4327
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.

$ gcc -v  
Using built-in specs.
COLLECT_GCC=/mnt/svn/gcc-trunk/binary-latest/bin/gcc
COLLECT_LTO_WRAPPER=/mnt/svn/gcc-trunk/binary-199312-lto-fortran-checking-yes-rtl-df/libexec/gcc/x86_64-unknown-linux-gnu/4.9.0/lto-wrapper
Target: x86_64-unknown-linux-gnu
Configured with: /mnt/svn/gcc-trunk//configure --enable-checking=yes,rtl,df
--enable-languages=c,c++,lto,fortran
--prefix=/mnt/svn/gcc-trunk/binary-199312-lto-fortran-checking-yes-rtl-df/
--without-cloog --without-ppl
Thread model: posix
gcc version 4.9.0 20130524 (experimental) (GCC) 

Tested revisions:
r199312 - fail
4.8 r198018 - OK

[Bug c++/25666] Bad diagnostic for templated destructor as friend

[paolo.carlini at oracle dot com]

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

Paolo Carlini  changed:

   What|Removed |Added

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

--- Comment #3 from Paolo Carlini  ---
Fixed for 4.9.0.

[Bug target/55876] internal compiler error: in gen_rtx_SUBREG, at emit-rtl.c:776

[vries at gcc dot gnu.org]

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

vries at gcc dot gnu.org changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |FIXED
   Assignee|unassigned at gcc dot gnu.org  |vries at gcc dot gnu.org

--- Comment #7 from vries at gcc dot gnu.org ---
Marking fixed

[Bug c++/57408] lambda, Variable length arrays, thread, internal compiler error: in expand_expr_real_1, at expr.c:9327

[paolo.carlini at oracle dot com]

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

--- Comment #1 from Paolo Carlini  ---
I'm not at all sure this is a C++ front-end issue.

[Bug c++/47765] Wrong template deduction

[paolo.carlini at oracle dot com]

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

--- Comment #7 from Paolo Carlini  ---
Do we have a DR # for this issue?

[Bug c/57409] implement PIE support on Solaris

[jullien at eligis dot com]

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

--- Comment #5 from Christian Jullien  ---
Thanks,
now all is clear to me.

I see different possible solutions:

1) gcc toolchain detects that it is using a linker that does not support pie
and issue a error "unsupported flag" when we try to use pie

2) enter a binutils bug report asking to do a nop when it receives pie flags
for a platform that does not support it (as does solaris standard ld)

3) Ask Todd to check if pie is working from configure script.

Of course 3) will only fix sudo and no other packages trying to use pie.

What do you prefer?

[Bug target/55777] Inlining nomips16 function into mips16 function can result in undefined builtins

[rsandifo at gcc dot gnu.org]

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

rsandifo at gcc dot gnu.org  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2013-05-25
 CC||rsandifo at gcc dot gnu.org
   Assignee|unassigned at gcc dot gnu.org  |rsandifo at gcc dot 
gnu.org
 Ever confirmed|0   |1

--- Comment #2 from rsandifo at gcc dot gnu.org  
---
Testing a patch.

[Bug lto/57334] ICE: in input_gimple_stmt, at gimple-streamer-in.c:287

[dimhen at gmail dot com]

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

--- Comment #3 from Dmitry G. Dyachenko  ---
(In reply to Richard Biener from comment #1)
> I've seen this ICE before I think.
> 
>   else if (code == GIMPLE_LABEL)
> gcc_assert (emit_label_in_global_context_p (gimple_label_label (stmt))
> || DECL_CONTEXT (gimple_label_label (stmt)) == fn->decl);

Sorry, i cant find nothing appropriate in bugzilla to mark this one as
DUPLICATE

[Bug c++/49433] internal compiler error: in write_builtin_type, at cp/mangle.c:2167

[paolo.carlini at oracle dot com]

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

Paolo Carlini  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |DUPLICATE

--- Comment #3 from Paolo Carlini  ---
I'm pretty sure it's a Dup, otherwise, if the issue persists, please re-open,
thanks.

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

[Bug lto/51432] [4.6 regression] ICE in -flto -std=c++0x -g with cross-compiler

[paolo.carlini at oracle dot com]

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

Paolo Carlini  changed:

   What|Removed |Added

 CC||philb at gnu dot org

--- Comment #7 from Paolo Carlini  ---
*** Bug 49433 has been marked as a duplicate of this bug. ***

[Bug target/12081] Gcc can't be compiled with -mregparm=3

[mikpe at it dot uu.se]

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

--- Comment #21 from Mikael Pettersson  ---
(In reply to Mikael Pettersson from comment #20)
> Grepping around I also
> noticed that nothing used GEN_FCN11 (or is that used by the out-of-tree
> OpenRISC port?)  This add-on fixes those two issues.

i386/sync.md appears to generate code that needs the 11-arity version; consider
that part of the fixup patch revoked.

[Bug c++/47765] Wrong template deduction

[daniel.kruegler at googlemail dot com]

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

--- Comment #8 from Daniel Krügler  ---
(In reply to Paolo Carlini from comment #7)
> Do we have a DR # for this issue?

It seems to me that this is

http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_active.html#1391

submitted by Jason with a simplified form of the example discussed here.

[Bug testsuite/57413] New: FAIL: gcc.dg/debug/dwarf2/discriminator.c scan-assembler on x86_64-apple-darwin10

[dominiq at lps dot ens.fr]

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

Bug ID: 57413
   Summary: FAIL: gcc.dg/debug/dwarf2/discriminator.c
scan-assembler on x86_64-apple-darwin10
   Product: gcc
   Version: 4.9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: testsuite
  Assignee: unassigned at gcc dot gnu.org
  Reporter: dominiq at lps dot ens.fr
CC: dehao at google dot com
  Host: x86_64-apple-darwin10
Target: x86_64-apple-darwin10
 Build: x86_64-apple-darwin10

Created attachment 30191
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=30191&action=edit
Generated assembly

The test gcc.dg/debug/dwarf2/discriminator.c fails on x86_64-apple-darwin10 for
both -m32 and -m64:

FAIL: gcc.dg/debug/dwarf2/discriminator.c scan-assembler loc [0-9] 9 [0-9](
is_stmt [0-9])?\\n
FAIL: gcc.dg/debug/dwarf2/discriminator.c scan-assembler loc [0-9] 9 [0-9](
is_stmt [0-9])? discriminator 2\\n
FAIL: gcc.dg/debug/dwarf2/discriminator.c scan-assembler loc [0-9] 9 [0-9](
is_stmt [0-9])? discriminator 1\\n

I attach the assembly produced by

/opt/gcc/build_w/gcc/xgcc -B/opt/gcc/build_w/gcc/
/opt/gcc/work/gcc/testsuite/gcc.dg/debug/dwarf2/discriminator.c
-fno-diagnostics-show-caret -fdiagnostics-color=never -O0 -gdwarf-2 -S

GCC is configured with: 
../work/configure --prefix=/opt/gcc/gcc4.9w
--enable-languages=c,c++,fortran,objc,obj-c++,java,ada,lto --with-gmp=/opt/mp
--with-system-zlib --with-isl=/opt/mp --enable-lto --enable-plugin

[Bug libgcc/57405] Using printf in signal handler with alternate stack generates a SIGSEGV

[harald at gigawatt dot nl]

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

Harald van Dijk  changed:

   What|Removed |Added

 CC||harald at gigawatt dot nl

--- Comment #5 from Harald van Dijk  ---
Turn on warnings. This has nothing to do with calling printf inside a signal
handler, this is because no declaration of strsignal is provided, so strsignal
is implicitly declared as returning int instead of char *. You're on a 64-bit
system where they don't have the same size, so this breaks badly. Appropriate
warnings for this get enabled even in GCC 4.4 with -Wall.

[Bug middle-end/57366] gcc.dg/lto/attr-weakref-1 FAILs

[dominiq at lps dot ens.fr]

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

--- Comment #11 from Dominique d'Humieres  ---
I see the same failures on x86_64-apple-darwin10. With the patch in comment #9,
I still get

FAIL: gcc.dg/lto/attr-weakref-1
c_lto_attr-weakref-1_0.o-c_lto_attr-weakref-1_2.o link, -O0 -flto
-flto-partition=none 
FAIL: gcc.dg/lto/attr-weakref-1
c_lto_attr-weakref-1_0.o-c_lto_attr-weakref-1_2.o link, -O2 -flto
-flto-partition=none 
FAIL: gcc.dg/lto/attr-weakref-1
c_lto_attr-weakref-1_0.o-c_lto_attr-weakref-1_2.o link, -O0 -flto
-flto-partition=1to1  (internal compiler error)

compared to

FAIL: gcc.dg/lto/attr-weakref-1
c_lto_attr-weakref-1_0.o-c_lto_attr-weakref-1_2.o link, -O0 -flto
-flto-partition=none 
FAIL: gcc.dg/lto/attr-weakref-1
c_lto_attr-weakref-1_0.o-c_lto_attr-weakref-1_2.o link, -O2 -flto
-flto-partition=none 
FAIL: gcc.dg/lto/attr-weakref-1
c_lto_attr-weakref-1_0.o-c_lto_attr-weakref-1_2.o link, -O0 -flto
-flto-partition=1to1  (internal compiler error)
FAIL: gcc.dg/lto/attr-weakref-1
c_lto_attr-weakref-1_0.o-c_lto_attr-weakref-1_2.o link, -O2 -flto
-flto-partition=1to1 
FAIL: gcc.dg/lto/attr-weakref-1
c_lto_attr-weakref-1_0.o-c_lto_attr-weakref-1_2.o link, -O0 -flto 
FAIL: gcc.dg/lto/attr-weakref-1
c_lto_attr-weakref-1_0.o-c_lto_attr-weakref-1_2.o link, -O2 -flto

without the patch. The ICE is

/opt/gcc/work/gcc/testsuite/gcc.dg/lto/attr-weakref-1_0.c: In function
'callmealias':
/opt/gcc/work/gcc/testsuite/gcc.dg/lto/attr-weakref-1_0.c:9:1: internal
compiler error: in ultimate_transparent_alias_target, at varasm.c:2288

with/without the patch.

[Bug c/57409] implement PIE support or reject -pie option

[ebotcazou at gcc dot gnu.org]

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

Eric Botcazou  changed:

   What|Removed |Added

Summary|implement PIE support on|implement PIE support or
   |Solaris |reject -pie option

--- Comment #6 from Eric Botcazou  ---
> I see different possible solutions:
> 
> 1) gcc toolchain detects that it is using a linker that does not support pie
> and issue a error "unsupported flag" when we try to use pie
> 
> 2) enter a binutils bug report asking to do a nop when it receives pie flags
> for a platform that does not support it (as does solaris standard ld)
> 
> 3) Ask Todd to check if pie is working from configure script.
> 
> Of course 3) will only fix sudo and no other packages trying to use pie.
> 
> What do you prefer?

No strong opinion, but PIE is essentially a Linux thing so it shouldn't be
enabled by default everywhere (unless you really know what you are doing).

The failure mode could admittedly be improved though, so let's record that.

[Bug c++/52427] [C++11] problem with defaulted copy constructor and -O

[paolo.carlini at oracle dot com]

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

Paolo Carlini  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
  Known to work||4.7.2, 4.8.0, 4.9.0
 Resolution|--- |FIXED
   Target Milestone|--- |4.7.2

--- Comment #2 from Paolo Carlini  ---
This is fixed. If you can still see something wrong please re-open, thanks.

[Bug c/57409] implement PIE support or reject -pie option

[jullien at eligis dot com]

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

--- Comment #7 from Christian Jullien  ---
Thanks for your time on this issue Eric.

My preference goes to PIE failure detection when gcc is bootstrapped and gcc
complains when -pie is set on an unsupported platform.

You can do whatever you want with this bug report, unless you ask me a
question, I will no more comment on this issue. All is clear to me.

Christian

[Bug c++/52377] C++11 non-static initializers in unions are not used

[paolo.carlini at oracle dot com]

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

Paolo Carlini  changed:

   What|Removed |Added

   Priority|P3  |P2
 CC||jason at gcc dot gnu.org

--- Comment #2 from Paolo Carlini  ---
A rather annoying wrong code, it seems. I'm adding Jason in CC.

[Bug c++/52216] [C++11] Wrong exception deduction for some forms of placement new

[paolo.carlini at oracle dot com]

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

Paolo Carlini  changed:

   What|Removed |Added

Summary|[C++11][noexcept] Wrong |[C++11] Wrong exception
   |exception deduction for |deduction for some forms of
   |some forms of placement new |placement new

--- Comment #3 from Paolo Carlini  ---
Daniel, do we have a number?

[Bug c++/47765] [Core/1391] Wrong template deduction

[paolo.carlini at oracle dot com]

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

Paolo Carlini  changed:

   What|Removed |Added

Summary|Wrong template deduction|[Core/1391] Wrong template
   ||deduction

--- Comment #9 from Paolo Carlini  ---
Ah, nice. Thanks.

[Bug c++/57388] [C++11] ICE when function types with ref-qualifiers meet other function types

[daniel.kruegler at googlemail dot com]

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

--- Comment #3 from Daniel Krügler  ---
Extending std::is_function in regard to ref-qualified functions will depend on
that issue. I haven't found a way to get around these ICEs in the (updated)
test cases.

[Bug c++/57388] [C++11] ICE when function types with ref-qualifiers meet other function types

[paolo.carlini at oracle dot com]

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

--- Comment #4 from Paolo Carlini  ---
I see Daniel. Jason is already on it.

[Bug c++/52216] [C++11] Wrong exception deduction for some forms of placement new

[daniel.kruegler at googlemail dot com]

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

--- Comment #4 from Daniel Krügler  ---
(In reply to Paolo Carlini from comment #3)

It seems that this is CWG 1465 and it will be resolved by

http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_active.html#1351

It seems that this bug entry is fixed now for gcc 4.9 (looks as if 1351 has
already been implemented - at least partially), both test codes behave now as
expected.

[Bug c++/52216] [C++11] Wrong exception deduction for some forms of placement new

[paolo.carlini at oracle dot com]

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

--- Comment #5 from Paolo Carlini  ---
Of course, for sure we do have now bad_array_new_length, many commits by Jason
and others in this area. Let me double check, I'm thinking adding the testcase
maybe, and closing the issue. Thanks again!

[Bug c++/52216] [C++11] Wrong exception deduction for some forms of placement new

[daniel.kruegler at googlemail dot com]

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

--- Comment #6 from Daniel Krügler  ---
(In reply to Paolo Carlini from comment #5)

It would be great to have these test cases added.

[Bug c++/52216] [C++11] Wrong exception deduction for some forms of placement new

[paolo.carlini at oracle dot com]

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

Paolo Carlini  changed:

   What|Removed |Added

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

--- Comment #7 from Paolo Carlini  ---
Closing as fixed then. I added only the first testcase, because we already have
the second (cpp0x/bad_array_new2.C)

[Bug c++/57414] New: Internal Compiler error when using std::mutex

[r...@ramses-pyramidenbau.de]

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

Bug ID: 57414
   Summary: Internal Compiler error when using std::mutex
   Product: gcc
   Version: 4.7.3
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: r...@ramses-pyramidenbau.de

Created attachment 30192
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=30192&action=edit
Main.ii

Hi,

This is the Code i tried to compile:
(main.cpp)

#include 
#include 

class Foo {
private:
std::mutex _mutex;
};

int main(void) {
  auto i = std::make_shared( Foo() );
}

Compiled with:
g++ -save-temps -v -o out main.cpp -std=c++11 2> foo

I got an internal compiler error.

Compiler's Output:
http://pastebin.com/UcvkzrnC

main.ii is attached.

Thanks in advance!

[Bug c++/57414] Internal Compiler error when using std::mutex

[paolo.carlini at oracle dot com]

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

Paolo Carlini  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 CC|r...@ramses-pyramidenbau.de |
 Resolution|--- |INVALID

--- Comment #1 from Paolo Carlini  ---
On FSF GCC this issue can't be reproduced, the snippet is simply rejected.
Please report it to your vendor.

[Bug c++/57408] lambda, Variable length arrays, thread, internal compiler error: in expand_expr_real_1, at expr.c:9327

[daniel.kruegler at googlemail dot com]

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

Daniel Krügler  changed:

   What|Removed |Added

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

--- Comment #2 from Daniel Krügler  ---
First attempt so simplify (and to get rid of some library dependencies):

//-
#include 

struct Impl_base
{
  virtual ~Impl_base(){}
  virtual void run() = 0;
};

template
  struct Impl : public Impl_base
  {
Callable func;
Impl(Callable f) : func(f) { }
void run() { func(); }
  };

template
  void
  make_routine(Callable&& f)
  {
new Impl(static_cast(f));
  }

template
void make(Callable&& f)
  {
make_routine(std::__bind_simple(f));
  }

extern void use(float);

int main(){
int y = 2;
float fa[2][y]; // compiles fine if y were 2 hard-coded instead
fa[0][0]=0.8;
fa[0][1]=1.8;
auto fx=[&](){
for(int c=0; c<2; c++){ // compiles fine if c<2 were c<1 instead
use(fa[0][c]);
}
};
make(fx); //error (1*)
}
//-

causes the same error (using gcc 4.9.0 20130519 (experimental)):

"main.cpp||In function 'int main()':|
main.cpp|34|warning: ISO C++ forbids variable length array 'fa' [-Wvla]|
main.cpp||In member function 'void Impl::run() [with Callable =
std::_Bind_simple()>]':|
main.cpp|39|warning: '' is used uninitialized in this function
[-Wuninitialized]|
|34|note: '' was declared here|
main.cpp|39|internal compiler error: in expand_expr_real_1, at expr.c:9361|
"

[Bug c++/57408] lambda, Variable length arrays, thread, internal compiler error: in expand_expr_real_1, at expr.c:9327

[daniel.kruegler at googlemail dot com]

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

--- Comment #3 from Daniel Krügler  ---
Further simplification down to a library-free test case:

//--
template
  struct Impl
  {
Callable func;
Impl(Callable f) : func(f) { }
virtual void run() { func(); }
  };

template
void call(Callable f)
  {
Impl(f).run();
  }

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

int main(){
int y = 2;
float fa[2][y]; // compiles fine if y were 2 hard-coded instead
fa[0][0]=0.8;
fa[0][1]=1.8;
auto fx=[&](){
for(int c=0; c<2; c++){ // compiles fine if c<2 were c<1 instead
printf("use me", fa[0][c]);
}
};
call(fx); //error (1*)
}
//--

It seems relevant, that there is a virtual function that invokes the lambda
closure and that fa[0][c] is odr-used within the closure call expression.

[Bug c++/57415] New: [4.9 Regression] New PPC testsuite failure C++ compound literarl expr unimplemented

[dje at gcc dot gnu.org]

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

Bug ID: 57415
   Summary: [4.9 Regression] New PPC testsuite failure C++
compound literarl expr unimplemented
   Product: gcc
   Version: 4.9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: dje at gcc dot gnu.org

/tmp/20130524/gcc/testsuite/g++2/../../xg++
-B/tmp/20130524/gcc/testsuite/g++2/../../
/nasfarm/dje/src/src/gcc/testsuite/g++.dg/ext/altivec-cell-2.C 
-fno-diagnostics-show-caret -fdiagnostics-color=never  -nostdinc++
-I/tmp/20130524/powerpc-ibm-aix7.1.0.0/libstdc++-v3/include/powerpc-ibm-aix7.1.0.0
-I/tmp/20130524/powerpc-ibm-aix7.1.0.0/libstdc++-v3/include
-I/nasfarm/dje/src/src/libstdc++-v3/libsupc++
-I/nasfarm/dje/src/src/libstdc++-v3/include/backward
-I/nasfarm/dje/src/src/libstdc++-v3/testsuite/util -fmessage-length=0
-std=gnu++98 -maltivec  -S  -o altivec-cell-2.s(timeout = 300)
/nasfarm/dje/src/src/gcc/testsuite/g++.dg/ext/altivec-cell-2.C: In function
'int
 g(__vector(8) short int, int)':
/nasfarm/dje/src/src/gcc/testsuite/g++.dg/ext/altivec-cell-2.C:41:27: sorry,
unimplemented: unexpected AST of kind compound_literal_expr
/nasfarm/dje/src/src/gcc/testsuite/g++.dg/ext/altivec-cell-2.C:41:27: internal
compiler error: in potential_constant_expression_1, at cp/semantics.c:8936

[Bug c++/57415] [4.9 Regression] New PPC testsuite failure C++ compound literarl expr unimplemented

[dje at gcc dot gnu.org]

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

David Edelsohn  changed:

   What|Removed |Added

 Target||powerpc*-*-*
 Status|UNCONFIRMED |NEW
   Keywords||ice-on-valid-code
   Last reconfirmed||2013-05-25
 CC||jason at gcc dot gnu.org,
   ||paolo.carlini at oracle dot com
   Host||powerpc*-*-*
 Ever confirmed|0   |1
  Build||powerpc*-*-*

--- Comment #1 from David Edelsohn  ---
Another new failures with the constants change

[Bug c++/52768] cannot resolve address of function template with empty template argument list

[paolo.carlini at oracle dot com]

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

Paolo Carlini  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
  Known to work||4.8.0, 4.9.0
 Resolution|--- |FIXED
   Target Milestone|--- |4.8.0

--- Comment #5 from Paolo Carlini  ---
This is fixed in 4.8.0.

[Bug target/55777] Inlining nomips16 function into mips16 function can result in undefined builtins

[rsandifo at gcc dot gnu.org]

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

rsandifo at gcc dot gnu.org  changed:

   What|Removed |Added

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

--- Comment #3 from rsandifo at gcc dot gnu.org  
---
Fixed on trunk.

[Bug rtl-optimization/53916] [mips16] divide operation compiled result incorrect with GCC-4.6.3 '-O2' option

[rsandifo at gcc dot gnu.org]

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

rsandifo at gcc dot gnu.org  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 CC||rsandifo at gcc dot gnu.org
 Resolution|--- |FIXED

--- Comment #2 from rsandifo at gcc dot gnu.org  
---
Thanks for the report.  As you say, the bug was fixed in the 4.7 timeframe.
The fix was rather invasive and probably wouldn't be safe to backport to 4.6.

I'm therefore going to treat this bug report as being about the poor
quality of the code produced by 4.7.  This was actually an unintended
consequence of same the fix.

I've just applied a patch to allow the same division to be used once
again for both results:

  http://gcc.gnu.org/ml/gcc-patches/2013-05/msg01568.html

Here too I don't think it's suitable for a backport.  The earliest
candidate would be 4.8.2, but it seems too risky for what by then
would be a relatively mature branch.

[Bug c++/57416] New: internal compiler error: in gimple_expand_cfg, at cfgexpand.c:4575

[FBergemann at web dot de]

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

Bug ID: 57416
   Summary: internal compiler error: in gimple_expand_cfg, at
cfgexpand.c:4575
   Product: gcc
   Version: 4.8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: FBergemann at web dot de

Created attachment 30193
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=30193&action=edit
test program main.cpp compiled in eclipse with -std=c++11

while experimenting with
http://www.drdobbs.com/cpp/access-data-items-in-ancestor-stack-fram/240155450 i
got this error here:

 Build of configuration Debug for project RetainRecall 

make all 
Building file: ../main.cpp
Invoking: GCC C++ Compiler
/opt/gcc-4.8.0/bin/g++ -O0 -g3 -Wall -c -fmessage-length=0 -std=c++11 -MMD -MP
-MF"main.d" -MT"main.d" -o "main.o" "../main.cpp"
../main.cpp: In constructor ‘constexpr func1(PARENTDATA&) [with PARENTDATA =
Nothing]::Data::Data()’:
../main.cpp:43:9: internal compiler error: in gimple_expand_cfg, at
cfgexpand.c:4575
  struct Data
 ^
0x655603 gimple_expand_cfg
../../gcc/cfgexpand.c:4575
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.
make: *** [main.o] Error 1

 Build Finished 

[Bug target/56564] movdqa on possibly-8-byte-aligned struct with -O3

[sandra at codesourcery dot com]

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

Sandra Loosemore  changed:

   What|Removed |Added

 CC||sandra at codesourcery dot com

--- Comment #11 from Sandra Loosemore  ---
This affects at least PowerPC, too, which implements DATA_ALIGNMENT to add
additional alignment beyond that specified by the ABI.

Isn't TYPE_ALIGN already supposed to return the ABI-mandated alignment for
objects of a given type?  The documentation for DATA_ALIGNMENT already suggests
that its purpose is to add additional alignment for optimization purposes and I
suspect other targets may be using it that way, too.  Perhaps what's needed
here is more careful monitoring of the places where DATA_ALIGNMENT is being
used, rather than splitting it into two macros or adding an argument to control
the two uses.  Or at least, we'd have to clarify how the requirements for the
ABI-conforming use of DATA_ALIGNMENT differ from what TYPE_ALIGN is supposed to
do.

It seems to me that DATA_ALIGNMENT's original purpose was to add additional
alignment on variable definitions, and IIUC the problem now is either that it
is being used in other contexts or that its intended use is not taking into
account common, weak, and/or comdat definitions where the linker may substitute
a less-aligned definition from another compilation unit.  

Also, somebody should check whether vect_can_force_dr_alignment_p in
tree-vect-data-refs.c is catching all the cases it needs to for ABI
conformance.

[Bug c++/57416] internal compiler error: in gimple_expand_cfg, at cfgexpand.c:4575

[daniel.kruegler at googlemail dot com]

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

Daniel Krügler  changed:

   What|Removed |Added

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

--- Comment #1 from Daniel Krügler  ---
In the gcc 4.9.0 trunk I see no ICE, only a compiler error. Of-course ICEs need
to be fixed, but I think the example code is notvalid C++11, because the
initialization of the member of the local classes Data odr-use the function
parameter p_parent_data according to 9.8 p1:

"[..] Declarations in a local class shall not odr-use (3.2) a variable with
automatic storage duration from an enclosing scope."

[Bug c++/57416] internal compiler error: in gimple_expand_cfg, at cfgexpand.c:4575

[FBergemann at web dot de]

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

--- Comment #2 from Frank Bergemann  ---
Created attachment 30194
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=30194&action=edit
fixed version of test program - compilation works now

Hi Daniel,

thanks for the hint! - i was not aware of this rule.
Attached a new version of test program, which doesn't have this problem
anymore.

best regards,
Frank

[Bug target/56564] movdqa on possibly-8-byte-aligned struct with -O3

[jakub at gcc dot gnu.org]

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

--- Comment #12 from Jakub Jelinek  ---
Maybe it was original DATA_ALIGNMENT purpose, but it certainly serves for both
right now, which is wrong, we need one for ABI mandated stuff and one for
optimization stuff beyond, where optimization alignment can be used if it can
be proved that we'll bind to the optimized decl, but ABI has to be used
otherwise.

E.g. x86_64 ABI says that certain arrays are aligned that and that way, it is
certainly something beyond what TYPE_ALIGN provides (changing TYPE_ALIGN of the
arrays would affect layout of structures, but that is wrong).

[Bug c++/57416] internal compiler error: in gimple_expand_cfg, at cfgexpand.c:4575

[FBergemann at web dot de]

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

Frank Bergemann  changed:

   What|Removed |Added

  Attachment #30194|0   |1
is obsolete||

--- Comment #3 from Frank Bergemann  ---
Created attachment 30195
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=30195&action=edit
fixed version of test program - compilation works now

missed to fix another location of invalid code - sorry
\Frank

[Bug c++/57416] internal compiler error: in gimple_expand_cfg, at cfgexpand.c:4575

[daniel.kruegler at googlemail dot com]

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

--- Comment #4 from Daniel Krügler  ---
If you remove the still existing member initializer in func1, does the ICE
still exist? (On 4.9 after removal of that initializer I could compile and run
the program). Are all the compiler flags necessary to reproduce the ICE, or
will e.g. the combination of -Wall -std=c++11 suffice to produce the ICE?

[Bug c++/57416] internal compiler error: in gimple_expand_cfg, at cfgexpand.c:4575

[daniel.kruegler at googlemail dot com]

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

--- Comment #5 from Daniel Krügler  ---
(In reply to Daniel Krügler from comment #4)
We had a clash here, but except for my first observation the remaining
questions are still relevant.

[Bug rtl-optimization/57417] New: hang on volatile int array

[su at cs dot ucdavis.edu]

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

Bug ID: 57417
   Summary: hang on volatile int array
   Product: gcc
   Version: 4.9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: rtl-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: su at cs dot ucdavis.edu

The following code causes gcc trunk (and the 4.7 & 4.8 branches) to hang at -O1
or above. This seems to be different from 57381, but perhaps related.

$ gcc-trunk -v
Target: x86_64-unknown-linux-gnu
gcc version 4.9.0 20130525 (experimental) [trunk revision 199323] (GCC)
$ gcc-trunk -m32 -O0 -c small.c
$ gcc-trunk -m32 -O1 -c small.c
^C
$ cat small.c
int a, b, c;

void foo ()
{
  volatile int d[1];
  b = 0;
  for (;; a--)
c = (int)&d[b];
}

[Bug c/57418] New: Another verify_ssa failure

[dcb314 at hotmail dot com]

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

Bug ID: 57418
   Summary: Another verify_ssa failure
   Product: gcc
   Version: 4.9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: dcb314 at hotmail dot com

I just out the source code from bug report # 49926 on the compiler
from 24 May 2013.

[dcb@localhost testsuite]$ ~/gcc/results/bin/gcc -c -g -O2 
gcc.dg/vect/pr49926.c
[dcb@localhost testsuite]$ ~/gcc/results/bin/gcc -c -g -O3 
gcc.dg/vect/pr49926.c
gcc.dg/vect/pr49926.c: In function ‘foo’:
gcc.dg/vect/pr49926.c:7:1: error: definition in block 7 follows the use
 foo (unsigned int x, int y, int z, int *w)
 ^
for SSA_NAME: y_48 in statement:
# DEBUG D#1 => y_48 & a.1_56
gcc.dg/vect/pr49926.c:7:1: internal compiler error: verify_ssa failed
0xa70ff9 verify_ssa(bool)
../../src/trunk/gcc/tree-ssa.c:1046
0x8517b1 execute_function_todo
../../src/trunk/gcc/passes.c:1970
0x852107 execute_todo
../../src/trunk/gcc/passes.c:2002
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++/57388] [C++11] ICE when function types with ref-qualifiers meet other function types

[jason at gcc dot gnu.org]

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

Jason Merrill  changed:

   What|Removed |Added

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

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

[Bug c++/57416] internal compiler error: in gimple_expand_cfg, at cfgexpand.c:4575

[FBergemann at web dot de]

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

--- Comment #6 from Frank Bergemann  ---
the error depends on optimization level.
-O0 has the problem
-O1, -02, -03 do not have the problem.
For those i get - even for the original buggy code:

make all 
Building file: ../main.cpp
Invoking: GCC C++ Compiler
/opt/gcc-4.8.0/bin/g++ -O1 -g3 -Wall -c -std=c++11 -MMD -MP -MF"main.d"
-MT"main.d" -o "main.o" "../main.cpp"
../main.cpp: In function ‘void func3(PARENTDATA&) [with PARENTDATA =
func2(PARENTDATA&) [with PARENTDATA = func1(PARENTDATA&) [with PARENTDATA =
Nothing]::Data]::Data]’:
../main.cpp:23:47: warning: ‘p_parent_data’ may be used uninitialized in this
function [-Wmaybe-uninitialized]
  std::cout << "parent_data.parent_data.x = "  <<
data.parent_data.parent_data.x << std::endl;
   ^
../main.cpp: In function ‘void func2(PARENTDATA&) [with PARENTDATA =
func1(PARENTDATA&) [with PARENTDATA = Nothing]::Data]’:
../main.cpp:29:9: warning: ‘p_parent_data’ is used uninitialized in this
function [-Wuninitialized]
Finished building: ../main.cpp

Building target: RetainRecallOld
Invoking: GCC C++ Linker
/opt/gcc-4.8.0/bin/g++  -o "RetainRecallOld"  ./main.o   
  struct Data
 ^
../main.cpp: In function ‘void func1(PARENTDATA&) [with PARENTDATA = Nothing]’:
../main.cpp:43:9: warning: ‘p_parent_data’ is used uninitialized in this
function [-Wuninitialized]
  struct Data
 ^
Finished building target: RetainRecallOld


 Build Finished 

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

[bdavis at gcc dot gnu.org]

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

Bud Davis  changed:

   What|Removed |Added

 CC||bdavis at gcc dot gnu.org

--- Comment #2 from Bud Davis  ---
Need a reduced test case.
The smallest sequence of valid code that reproduces the problem.
5 to 10 lines is idea.  If possible.